topic Re: Signature 1330 causes packet drops in Network Security

Signature 1330 causes packet drops

alex.dersch — Sun, 10 Mar 2019 12:16:52 GMT

Hello Members,

i see in my IPS-NME module a hign number of packet drops because of the following signatures:

1330-17: TCP segment out of state order

1330-12: TCP segment is out of order.

the targets and the attacers are internal hosts.

are these signatures triggered because of not propper configured policies or is this an indicator for problems in the internal network.

thanks for your inputs.

regards

alex

Re: Signature 1330 causes packet drops

Siddharth Chandrachud — Sat, 26 Feb 2011 22:22:07 GMT

Hi Alex,

All signatures in the 1330 range belong to the Normaliser Engine.

A. So in nutshell below are is a brief description of IP Fragment and TCP normalisation and why we use in the IPS:

http://www.cisco.com/en/US/docs/security/ips/7.0/configuration/guide/cli/cli_signature_engines.html#wp1014834

B. If you are seeing 1330-17 or 1330-12 it means there might asymmetrical traffic flow in the network.

Or maybe the virtual sensor is not seeing both sides of the TCP connection and only seeing half connection.

Examples of this is traffic coming into the IPS via a interface assigned to virtual sensor A.

The return traffic enters the IPS via interface which is assigned to virtual sensor B.

So both virtual sensors only see half connection each, causing the normaliser signatures to fire.

So the normaliser signatures firing is a function of how traffic is flowing through your network, or how the IPS is seeing it at the virtual sensor level.

C. You can put the IPS in assymetrical mode and see it makes a difference.

Different modes and description:

http://www.cisco.com/en/US/docs/security/ips/7.0/configuration/guide/cli/cli_virtual_sensors.html#wp1034136

Hopt this helps.

Sid Chandrachud

Re: Signature 1330 causes packet drops

alex.dersch — Sun, 27 Feb 2011 11:53:01 GMT

Hello Sid,

thanks for your answer. I learned that most of packets where the Signature 1330 triggers are packets from the IPS module to the IPS Express Manager. I added wireshark dump to the case.

That's really odd, i ran a traceroute from the IPS Manager to the IPS Module and vice versa and the flow look ok to me.

Trace from the IPS module to the IPS Manager

# trace 10.0.128.5
traceroute to 10.0.128.5 (10.0.128.5), 4 hops max, 40 byte packets
1 172.16.1.9 (172.16.1.9) 1.479 ms 1.327 ms 1.275 ms
2 172.16.1.1 (172.16.1.1) 3.616 ms 2.952 ms 1.907 ms
3 10.89.27.10 (10.89.27.10) 2.288 ms 2.044 ms 2.136 ms
4 10.89.27.21 (10.89.27.21) 8.106 ms 9.148 ms 8.266 ms
#

return path

C:\Users\Administrator.NOS-POC>tracert 172.16.1.11

Tracing route to 172.16.1.11 over a maximum of 30 hops

1    <1 ms    <1 ms    <1 ms 10.0.128.1
2     2 ms     3 ms     2 ms 172.16.2.1
3     1 ms     1 ms     1 ms 10.89.27.22
4     9 ms     9 ms     9 ms 10.89.27.9
5     8 ms     8 ms     8 ms 172.16.1.6
6     8 ms     8 ms     8 ms 172.16.1.11

Trace complete.

trace from the IPS module's gateway

#traceroute vrf CENTRAL 10.0.128.5 source 172.16.1.9

Type escape sequence to abort.
Tracing the route to 10.0.128.5

1 172.16.1.1 0 msec 0 msec 0 msec
2 10.89.27.10 0 msec 0 msec 4 msec
3 10.89.27.21 8 msec 8 msec 8 msec
4 172.16.2.6 8 msec 8 msec 4 msec
5 10.0.128.5 4 msec 4 msec 4 msec

what make me wonder is that the IPS module doesn't show hops further than 4 hops.

regards

alex