topic Re: IPS sensor 4260 blocking ISA trafiic in Network Security

IPS sensor 4260 blocking ISA trafiic

dragnia_s — Sun, 10 Mar 2019 11:23:40 GMT

Hello,

I recently installed a 4260 IPS sensor. It is used to inspect traffic between a ISA server and the LAN. The ISA is formed from 3 real servers in NLB.

Each server is connected to 2 switches through 4 cables 2 in each switch, one in the internet VLAN and one in the IPS VLAN.

For some reason when i inspect the traffic it blocks the ISA traffic. No signature seems to be triggered but the traffic from the ISA server stops.

When i capture packets on the vs0 sensor i don't see any traffic from the ISA server for 5 to 10 min and after that it starts again to function.

The IPS inspects on two redundant pairs traffic that travels from the LAN to the ISA.

The IPS versionn is 6.1 E2

Any ideeas on what is causing this?

Thank you!

Re: IPS sensor 4260 blocking ISA trafiic

attmidsteam — Fri, 28 Nov 2008 15:06:21 GMT

There are a number of signatures in the 13xx series which have actions of deny or modify packet inline without a produce alert action. It is possible these are firing (silently).

Have you tried looking at 'sh stat denied-attackers' to see if those IPs are being blocked? Also, you can look at 'sh stat virtual-sensor' in the "SigEvent Preliminary Stage Statistics" & "SigEvent Action Override Stage Statistics" areas. Those will tell you which sigs are firing and which actions are being taken. Watch for "deny-packet-inline" & "deny-attacker-inline" to increment.

Re: IPS sensor 4260 blocking ISA trafiic

dragnia_s — Fri, 28 Nov 2008 15:55:09 GMT

Thanks for the answer!

I have enabled alert sending for every signature that did something to the traffic. but nothing was triggered that denied any attackers.

I will use the commands you gave to further troubleshoot.

Do you know what could cause a 3737/0 signature with a calculated risk of 95% to droppedPacket, deniedFlow, tcpOneWayResetSent when in the signature actions is just alert and the VS0 should just drop packets when the risk is above 90 % ?

Thak you

Re: IPS sensor 4260 blocking ISA trafiic

attmidsteam — Fri, 28 Nov 2008 16:04:12 GMT

You are being hit with the default option of the the Event Action Override feature. It adds a 'Deny Packet Inline' action to any signature with a risk of 90-100. Type 'setup' on the sensor, do you see a section like this?

service event-action-rules rules0

overrides

override-item-status Enabled

risk-rating-range 90-100

exit

Re: IPS sensor 4260 blocking ISA trafiic

dragnia_s — Fri, 28 Nov 2008 16:28:49 GMT

Yes,

the event action override feature is on. But it should just dey packet inline not do a tcpOneWayResetSent or does deny packet inline will trigger all of these actions droppedPacket, deniedFlow, tcpOneWayResetSent.

I added an exception for this rule for any attacker that tries this attack on the ISA IP but it didn't help.

Is 'setup' the right command to view this? I mostly use the IDM and it shows the event action overide for risk rating above 90% to drop.

Re: IPS sensor 4260 blocking ISA trafiic

attmidsteam — Fri, 28 Nov 2008 16:41:00 GMT

I can't help you with IDM as we usually use CSM to manage our sensors (many hundreds). You could disable the event action override and see what happens.

(via CLI)

conf t

service event-action-rules rules0

overrides deny-packet-inline

override-item-status Disabled

exit

(yes)

exit

Re: IPS sensor 4260 blocking ISA trafiic

dragnia_s — Thu, 11 Dec 2008 09:05:13 GMT

Hi,

i figured it out,

the traffic was asymmetric, the same packets were entering on the diffrent pairs because of the Spanning Tree but the ISA was answering just once,

This happened when the evasion protection mode was set as strict:

strict-If a packet is missed for any reason, all packets after the missed packet are not

processed

I configured the sensor to expect asymmetric traffic, not strict

service analysis-engine

virtual-sensor vs0

inline-TCP-evasion-protection-mode asymmetric

and everything worked fine.

Because the ISA was configured in NLB broadcast mode we couldnt stop the packets from being doubled and sent to the second pair. So finaly I redesigned the network and only one pair is used.

thanks for the help!