2821 IPS Problem

Unanswered Question
Jun 2nd, 2010

We have a 2821 that is blocking telnet among other things (windows password changes) (setup new account on windowws) when we have an ip ips XXXX in or out statment on a sub interface/vlan.....if we remove the statment everything works replace it and it breaks. The logs shows servral of these:

Jun  2 06:18:21.668 est: %IPS-4-SIGNATURE: Sig:6055 Subsig:2 Sev:100 DNS Inverse Query Buffer Overflow [10.129.14.76:53 -> 10.105.248.2:52279] VRF:NONE RiskRating:100.....anyone know how I could test to see what is going on?

Thanks

James

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Scott Fringer Wed, 06/02/2010 - 11:34

James;

  What version of IOS is running on your 2821?

  Are there any other signature events in the router's log?

  You can monitor IPS signature  events by issuing:

sh ip sdee events

  This requires that IPS notifications via SDEE be enabled.  You can also get a summary of IPS activity by issuing:

sh ip ips stat

  Is the traffic being impacted the same traffic indicated by the signature (6055/2) you supplied?

Scott

JamesBrockman Wed, 06/02/2010 - 11:49

James;

  What version of IOS is running on your 2821?  (C2800NM-ADVENTERPRISEK9-M), Version 15.1(1)T

  Are there any other signature events in the router's log? Some like this:

May 29 02:15:06.633 est: %IPS-4-SIGNATURE: Sig:5605 Subsig:0 Sev:25 Windows Account Locked [10.105.248.117:1038 -> 10.129.14.7:139] VRF:NONE RiskRating:21
May 28 13:38:10.838 est: %IPS-3-SIG_UPDATE_REQUIRED: IOS IPS requires a signature update package to be loaded

Some other stuff but it was expected...links going up and down

  You can monitor IPS signature  events by issuing:

sh ip sdee events  it only shows this:

40: 02:15:06 est May 29 2010  ALERT   Sig ID     5605:0  Windows Account Locked
  41: 06:18:19 est May 29 2010  ALERT   Sig ID     6055:2  DNS Inverse Query Buffer Overflow
  42: 06:18:19 est May 29 2010  ALERT   Sig ID     6055:2  DNS Inverse Query Buffer Overflow

  This requires that IPS notifications via SDEE be enabled.  You can also get a summary of IPS activity by issuing:

sh ip ips stat it shows

show ip ips stat
Signature statistics [process switch:fast switch]
  signature 5605:0: packets checked [0:5] alarmed [0:5] dropped [0:0]
  signature 3124:0: packets checked [0:1] alarmed [0:1] dropped [0:0]
  signature 6055:2: packets checked [0:64] alarmed [0:64] dropped [0:0]
Interfaces configured for ips 5
Session creations since subsystem startup or last reset 563699
Current session counts (estab/half-open/terminating) [134126:85004:0]
Maxever session counts (estab/half-open/terminating) [134131:85012:8]
Last session created 00:00:58
Last statistic reset never
TCP reassembly statistics
  received 908 packets out-of-order; dropped 12
  peak memory usage 39 KB; current usage: 0 KB
  peak queue length 16

  Is the traffic being impacted the same traffic indicated by the signature (6055/2) you supplied? I'm not so sure....it just seems strange that if we remove the statment from the interface everything works....when we put it back it stops...we've tried removing and reloading then replacing the sigs....downloading the sigs again then reloading....this blocks traffic from one vlan to another only....it worked for 3 weeks then the power went out 2 weeks ago and after that we have had this problem.....if  I had to guess the problem was there and the unexpected reload just triggered it....

Thanks for your help

I'm really stuck on this one...

'

James

Scott Fringer Wed, 06/02/2010 - 12:07

James;

  From the output provided, the traffic impact is not from the signatures that are firing (none have taken a drop action).

  One thing to note with IOS IPS, once it is enabled some of the underlying firewall functionality is enabled to provide some protection from DoS attacks.  You may need to tune these parameters as outlined in this document:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6634/prod_white_paper0900aecd8062acfb.html

  specifically the section titled,"Understanding the Inspection Threshold Values".

  There appears to be an issue with out-of-order traffic arriving and being dropped:

TCP reassembly statistics
received 908 packets out-of-order; dropped 12

Scott

JamesBrockman Thu, 06/03/2010 - 03:34

OK ..

I can see where this might be a problem......look at this:

#show ip inspect stat

Packet inspection statistics [process switch:fast switch]

tcp packets: [62594:7893336]

udp packets: [8:1161529]

icmp packets: [3383:1134178]

http packets: [17:1206216]

ftp packets: [0:89209]

Interfaces configured for inspection 14

Session creations since subsystem startup or last reset 812333

Current session counts (estab/half-open/terminating) [39:20:0]

Maxever session counts (estab/half-open/terminating) [114:92:4]

Last session created 00:00:00

Last statistic reset never Last session creation rate 121

Maxever session creation rate 322

Last half-open session total 20

TCP reassembly statistics

received 147 packets out-of-order; dropped 0

peak memory usage 39 KB;

current usage: 0 KB

peak queue length 16

So I have a few questions......why would removing the ip ips statements from the interface stop this? I'm not second guessing you just trying to get a better understanding of what's going on....Does having the ip ips enabled on an interface enable the firewall on that interface? I thought the ip inspect rules were on all of the time is that not true??? Could I test this by removing the ip inspect rules? And if it allows the traffic I could adjust the max incomplete-high values?

Thanks again for your help

James

Scott Fringer Thu, 06/03/2010 - 04:10

James;

  I do not work directly with the firewall feature set, but from my understanding if you are not enabling the firewall features specifically, enabling the IPS feature set will enable (but not expose) the firewall thresholds.  You should be able to adjust the necessary thresholds to achieve a balance for your environment.

  Disabling the IPS feature, will in turn remove the firewall thresholds as well.

Scott

JamesBrockman Thu, 06/03/2010 - 04:24

I think I get it now....I'll adjust the IP Inspect "number of connections" and see if that solves the issue....just another side note....I could replacate this at will....add the ip ips statment and it doesn't work...take it out it does...would that mean that just the one telnet session would push it over the limit? Everything else seemed to be ok....on another subnet the same issue with logging into a domain for the first time or changing your passwword but not an issue if you have logged in before Blue=tested by another person....but the same fix works...again thanks for your help....I'll let you know how it goes...

James

Actions

This Discussion

Related Content