Signature 1330-X: TCP segment out of order - what does it mean?

Unanswered Question
Apr 20th, 2009

Hi,

on a customer's site, on one of their IPS, I get a lot of sig 1330 alerts, mainly those two:

1330-12: TCP segment is out of order. If the signature status is set to disabled, the packet will be passed to all engines that are not stream based.

This signature will not produce an alert in promiscuous mode regardless of the signature status.

1330-17: TCP segment out of state order. If a packet in a stream causes this signature to produce an alert, processing will cease for that stream. This signature will not produce an alert in promiscuous mode regardless of the signature status

I'm not sure how to interpret these alerts correctly and/or how to troubleshoot further. Does anyone have an idea?

Thanks a lot,

Florian

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
marcabal Mon, 04/20/2009 - 06:40

Is your sensor monitoring more than one network segment?

If so then these alarms are common when a TCP connection crosses both networks and gets seen twice by the sensor.

This can confuse the sensor's tracking of the connection.

A common scenario is to have the sensor monitor both the Inside network or a firewall as well as the DMZ. When an internal user connects to the company's web server the traffic gets seen by the sensor both on the Inside network and in the DMZ. The sensor tries to put the packets from both networks together in order to try and monitor it as a single connection. Because the packets get modified by the firewall it often results in inconsitency between traffic on the 2 sides and causes the sensor to be confused about the connection.

The good news is that if this is your problem, then there are 2 easy workarounds.

1) If your sensor supports virtual sensors, then create a second virtual sensor. Assign one network to default vs0, and assign the other network to the new virtual sensor. This way each virtual sensor sees traffic on just one of the networks and won't become confused.

2) If your sensor does not support additional virtual sensors, or you've used up all 4 virtual sensors, then there is a configuration option within the virtual sensor configuration itself:

Inline TCP Session Tracking Mode

By default it is set to Virtual Sensor which is why it tries to put together packets from both networks to try and look at is a single connection and gets confused.

BUT it can also be set to Interface and Vlan. This configuration allows the virtual sensor to treat the traffic on each network independantly. The connection on the first network will be monitored independant of the connection on the second network. This will prevent the virtual sensor from getting confused.

The above is just my guess at what is going on in your network based on what we've seen on other networks. If this doesn't address the reason for the signature triggerings, then please respond back with more information about your network.

It is possible that these could be a hacker trying to avoid detection by the sensor, but more likely something in your deployment is confusing the sensor.

Florian Pressler Mon, 04/20/2009 - 06:52

Hi marcabal,

thanks a lot for your response. Unluckily, your scenario doesn't match the setup at the customers site. We are just monitoring traffic which is being passed between two segments of the networks. But I think I understand which scenario you are referring to and why it happens then.

So far, I have asked the customer to find out (I'm not on site now)

1) if the problem occurs regularly all the time or rather in "bursts"

2) when watching the problematic IPs, is the some kind of legality which connects them (so are those coming from the same subnets, or a only a few "special" IPs affected)

I hope this will point us to the real problem, but at the moment I'm not really sure what I'll do with the information once I have it.

Regards,

Florian

Actions

This Discussion