Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
749
Views
0
Helpful
11
Replies

IDS Stopping FTP

jodilovell
Level 1
Level 1

‎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?

Labels:
0 Helpful
11 Replies 11

jekrauss
Level 1
Level 1

‎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

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

0 Helpful

jodilovell
Level 1
Level 1
In response to jekrauss

‎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.

0 Helpful

jekrauss
Level 1
Level 1
In response to jodilovell

‎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

0 Helpful

jodilovell
Level 1
Level 1
In response to jekrauss

‎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.

0 Helpful

jekrauss
Level 1
Level 1
In response to jodilovell

‎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

0 Helpful

jodilovell
Level 1
Level 1
In response to jekrauss

‎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.

0 Helpful

howard.cisco
Level 1
Level 1
In response to jodilovell

‎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

0 Helpful

jodilovell
Level 1
Level 1
In response to howard.cisco

‎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?

0 Helpful

raymond.eringaard
Level 1
Level 1

‎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.

0 Helpful

jodilovell
Level 1
Level 1
In response to raymond.eringaard

‎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.

0 Helpful

jodilovell
Level 1
Level 1

‎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.

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents