×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

IDS Stopping FTP

Unanswered Question
Oct 11th, 2002
User Badges:

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jekrauss Fri, 10/11/2002 - 04:20
User Badges:

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

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/ftrafwl/scfcbac.htm#xtocid27



jodilovell Fri, 10/11/2002 - 04:50
User Badges:

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.

jekrauss Fri, 10/11/2002 - 05:08
User Badges:

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

jodilovell Fri, 10/11/2002 - 05:23
User Badges:

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.

jekrauss Fri, 10/11/2002 - 08:44
User Badges:

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


jodilovell Sun, 10/13/2002 - 23:00
User Badges:

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.


jodilovell Wed, 10/23/2002 - 05:07
User Badges:

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?

raymond.eringaa... Wed, 10/23/2002 - 04:24
User Badges:

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.

jodilovell Wed, 10/23/2002 - 05:12
User Badges:

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.

jodilovell Wed, 10/23/2002 - 05:30
User Badges:

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.


Actions

This Discussion