10-11-2002 01:23 AM - edited 03-09-2019 12:38 AM
Good day.
I'm sitting with a problem where IDS on our perimeter router is stopping ftp. When I debug IP PACKET I get "IP: s=x.x.x.x(Ethernet0/0), d=y.y.y.y(Serial0/0), len 112, dropped by inspect". Here is my Serial config:
interface Serial0/0
bandwidth 256
ip address <>
no ip redirects
no ip proxy-arp
ip audit BATE_IDS in
no ip mroute-cache
fair-queue 64 256 0
down-when-looped
And that's it. I just want basic IDS nothing fancy. I haven't configured any CBAC or other firewalling so why is FTP being dropped?
Any ideas?
10-11-2002 04:20 AM
How have you configured your ids? You've shown the interface configuration, but not the global configuration, so we can't tell what your IDS is configured to do.
If you do:
show ip audit statistics, does it show evidence that your router thinks it is experiencing an ftp attack?
What action have you configured for your ids when it experiences an attack? i.e. alarm, drop, reset?
What do your ids sysylogs show?
Suggested plan-of-action:
1) Review your ip audit syslogs and your show ip audit statistics. This should tell you if the router thinks it's under attack
2) Change your IDS action to alarm only, if necessary to further isolate whether a perceived ftp attack is the issue
3) If you have eliminated those possibilities, then it is possible that you are encountering automatically enabled global thresholds for CBAC which provide DoS protection. If you exceed the default global thresholds, your router will start dropping packets. Further details regarding this scenario are included below.
HTH
Jeff
Troubleshooting global thresholds:
If you do a "show ip inspect config", you will see the default settings. For instance:
INET-3600#sh ip inspect config
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [400:500] connections
max-incomplete sessions thresholds are [400:500]
max-incomplete tcp connections per host is 50. Block-time 0 minute.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
dns-timeout is 5 sec
INET-3600#
If you do "show ip inspect stat" (hidden command), you will see whether or not you have exceeded the default thresholds. If you have ip audit trail configured, then you may see syslogs referring to "getting aggressive." If so, you will need to tune the global threshold settings in order to meet your needs.
Here's a link for further reference:
Configuring Global Timeouts and Thresholds
10-11-2002 04:50 AM
I have had to remove the IDS from the serial interface to let the FTP work for now but here is a "show ip audit statistics":
Signature audit statistics [process switch:fast switch]
signature 2000 packets audited: [2:2001]
signature 2001 packets audited: [4:115541]
signature 2002 packets audited: [1:2]
signature 2004 packets audited: [874:6507]
signature 2005 packets audited: [48:1025]
signature 2151 packets audited: [0:2]
signature 3041 packets audited: [0:63]
Interfaces configured for audit 0
Session creations since subsystem startup or last reset 24982
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [207:53:20]
Last session created 03:21:40
Last statistic reset never
Here is the Audit config in the global section:
ip audit name BATE_IDS info action alarm
ip audit name BATE_IDS attack action alarm drop reset
I didn't think it was the IDS stopping the FTP because nothing showed up in the logs. Just the normal host unreachable and echo reply signitures. But only when I do the debug ip packet do I see the "dropped by inspect" message.
10-11-2002 05:08 AM
Okay, it doesn't appear that ids is causing the problem.
The debug ip packet message regarding ip inspect is a CBAC message.
Do you have ANY lines in your config that include:
ip inspect?
Also, the original error message you provided appears to be truncated. Can you please recheck and see if you have more details?
Thanks/Jeff
10-11-2002 05:23 AM
Ok I haven't done anything with the CBAC. I wanted to keep this simple (maybe this is my problem). So here is the config and the debug packet message:
version 12.1
no service single-slot-reload-enable
service nagle
no service pad
service tcp-keepalives-in
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
logging buffered 16000 debugging
!
clock timezone SAST 2
ip subnet-zero
no ip source-route
ip cef
no ip domain-lookup
!
no ip bootp server
ip audit attack action alarm drop reset
ip audit notify log
ip audit po max-events 100
ip audit name BATE_IDS info action alarm
ip audit name BATE_IDS attack action alarm drop reset
!
!
!
interface Ethernet0/0
description Link to LAN
ip address <>
no ip redirects
no ip mroute-cache
!
interface Serial0/0
bandwidth 256
ip address <>
no ip redirects
no ip proxy-arp
ip audit BATE_IDS in
no ip mroute-cache
fair-queue 64 256 0
down-when-looped
!
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0/0
no ip http server
!
logging facility syslog
logging source-interface Ethernet0/0
DEBUG PACKET:
016240: *Apr 2 00:58:38.182 SAST: IP: s=196.36.8.4 (Serial0/0), d=196.36.135.4 (Ethernet0/0), g=196.36.135.4, len 56, forward
016241: *Apr 2 00:58:38.186 SAST: TCP src=28278, dst=21, seq=3935878320, ack=3673811094, win=16513 ACK PSH
016242: *Apr 2 00:58:38.186 SAST: IP: s=196.36.135.4 (Ethernet0/0), d=196.36.8.4 (Serial0/0), len 112, dropped by inspect
016243: *Apr 2 00:58:38.190 SAST: TCP src=21, dst=28278, seq=3673811094, ack=3935878336, win=16544 ACK PSH
016244: *Apr 2 00:58:38.687 SAST: IP: s=196.36.135.4 (Ethernet0/0), d=196.36.8.4 (Serial0/0), len 112, dropped by inspect
016245: *Apr 2 00:58:38.687 SAST: TCP src=21, dst=27694, seq=3932450123, ack=3900357085, win=16544 ACK PSH FIN
Thanks for the help.
10-11-2002 08:44 AM
Hmmm....that's interesting.
Please disable the drop and reset for the IDS attack rule and see if that stops it.
Also, what were the results of the show ip inspect statistics and show ip inspect config?
If addressing the above issues doesn't resolve the issue for you, you may be running into a bug. I've searched for bugs with the symptoms you're seeing, but don't see anything directly related.
You might try upgrading to the latest image in the train you're in (there are several ftp related bugs in 12.1, that are resolved in 12.1(14) and higher).
If that doesn't take care of it for you, please open a TAC case.
Regards,
Jeff
10-13-2002 11:00 PM
Ok I've disabled the DROP and RESET on the ATTACK event but when I debug ip packets I still get the following error:
016353: *Apr 4 22:45:04.723 SAST: IP: s=196.36.135.4 (Ethernet0/0), d=139.92.221.203 (Serial0/0), len 74, dropped by inspect
016354: *Apr 4 22:45:04.723 SAST: TCP src=21, dst=2663, seq=1147896394, ack=2508015252, win=17486 ACK PSH
I had just recently put the AUDIT back on the interface so the stats are going to be fresh. Here are the outputs from the show ip inspect stat and config:
Interfaces configured for inspection 0
Session creations since subsystem startup or last reset 25012
Current session counts (estab/half-open/terminating) [2:0:0]
Maxever session counts (estab/half-open/terminating) [207:53:20]
Last session created 00:01:08
Last statistic reset never
Last session creation rate 0
Last half-open session total 0
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [400:500] connections
max-incomplete sessions thresholds are [400:500]
max-incomplete tcp connections per host is 50. Block-time 0 minute.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
dns-timeout is 5 sec
Ok the FTP server is on the LAN here and the FTP is being initiated from the Internet, have I got the Audit rule on the right interfaces and in the right Direction? I'm running 12.1.16 IOS.
10-22-2002 11:59 PM
I have encountered the same problem for an ISP customer.
Has this problem been resolved ?
I am most interested in the result
10-23-2002 05:07 AM
I put an access-list on the IP AUDIT command denying the IDS from checking traffic to the FTP server IP address. This has worked:
ip audit name BATE_IDS info list 50 action alarm
!
access-list 50 deny x.x.x.x
But this is stoping the IDS from checking the validity of the traffic going to the FTP server.
Any comments?
10-23-2002 04:24 AM
I could be way off the spot here, but it sounds a lot like passive FTP problems, in passive each FTP command triggers a new source TCP from the client which will kill or freeze your ftp session, because the filter device will see it as an illegal session. it´s a problem with many firewalls, might be the same for your IDS system.
The only solution is to use a different FTP-server or tell clients to disable passive FTP use.
10-23-2002 05:12 AM
What happens with the FTP is that you are prompted for the Username, you enter it and the connection hangs. You don't get prompted for a password.
The people accessing this FTP server are using a DOS prompt FTP, not a GUI ftp client like CUTE FTP. If you look at the DEBUG IP PACKET output you see the same TCP port numbers over and over so it's not randomly opening new ports:
016609: *Apr 14 04:40:35.235 SAST: IP: s=196.8.104.27 (Serial0/0), d=196.36.135.4 (Ethernet0/0), g=196.36.135.4, len 48, forward
016610: *Apr 14 04:40:35.235 SAST: TCP src=62882, dst=21, seq=1503032484, ack=0, win=16384 SYN
016611: *Apr 14 04:40:35.295 SAST: IP: s=196.8.104.27 (Serial0/0), d=196.36.135.4 (Ethernet0/0), g=196.36.135.4, len 56, forward
016612: *Apr 14 04:40:35.295 SAST: TCP src=62882, dst=21, seq=1503032485, ack=2042300045, win=17473 ACK PSH
016613: *Apr 14 04:40:35.299 SAST: IP: s=196.36.135.4 (Ethernet0/0), d=196.8.104.27 (Serial0/0), len 112, dropped by inspect
016614: *Apr 14 04:40:35.299 SAST: TCP src=21, dst=62882, seq=2042300045, ack=1503032501, win=17504 ACK PSH
016615: *Apr 14 04:40:37.731 SAST: IP: s=196.36.135.4 (Ethernet0/0), d=196.8.104.27 (Serial0/0), len 112, dropped by inspect
016616: *Apr 14 04:40:37.735 SAST: TCP src=21, dst=62882, seq=2042300045, ack=1503032501, win=17504 ACK PSH
016617: *Apr 14 04:40:38.501 SAST: IP: s=196.36.135.4 (Ethernet0/0), d=196.8.104.27 (Serial0/0), len 40, dropped by inspect
016618: *Apr 14 04:40:38.501 SAST: TCP src=21, dst=62882, seq=2042300117, ack=1503032501, win=17504 ACK
016619: *Apr 14 04:40:42.764 SAST: IP: s=196.36.135.4 (Ethernet0/0), d=196.8.104.27 (Serial0/0), len 112, dropped by inspect
016620: *Apr 14 04:40:42.764 SAST: TCP src=21, dst=62882, seq=2042300045, ack=1503032501, win=17504 ACK PSH
016621: *Apr 14 04:40:45.047 SAST: IP: s=196.36.135.4 (Ethernet0/0), d=196.8.104.27 (Serial0/0), len 40, dropped by inspect
016622: *Apr 14 04:40:45.047 SAST: TCP src=21, dst=62882, seq=2042300117, ack=1503032501, win=17504 ACK
016623: *Apr 14 04:40:52.828 SAST: IP: s=196.36.135.4 (Ethernet0/0), d=196.8.104.27 (Serial0/0), len 112, dropped by inspect
016624: *Apr 14 04:40:52.828 SAST: TCP src=21, dst=62882, seq=2042300045, ack=1503032501, win=17504 ACK PSH
016625: *Apr 14 04:40:58.169 SAST: IP: s=196.36.135.4 (Ethernet0/0), d=196.8.104.27 (Serial0/0), len 40, dropped by inspect
016626: *Apr 14 04:40:58.169 SAST: TCP src=21, dst=62882, seq=2042300117, ack=1503032501, win=17504 ACK.
Thanks for the comments.
10-23-2002 05:30 AM
Problem solved!!!
BUG ID: CSCdx00867:
Symptoms: A user may not be able to make a control connection to an FTP
server and may receive a return acknowledge/push (ack/push) message as part of
the initial 3-way handshake.
Conditions: This symptom is observed on a Cisco router that is configured
with Context-Based Access Control (CBAC).
Workaround: There is no workaround.
If you look at the DEBUG IP PACKET there is an ack/psh:016611: *Apr 14 04:40:35.295 SAST: IP: s=196.8.104.27 (Serial0/0), d=196.36.135.4 (Ethernet0/0), g=196.36.135.4, len 56, forward
016612: *Apr 14 04:40:35.295 SAST: TCP src=62882, dst=21, seq=1503032485, ack=2042300045, win=17473 ACK PSH
So there we have it. Problem resolved in IOS version 12.2.12.
Thank you to everyone for the comments. Every little bit helps.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide