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

Question

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

Answer 1

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.