TCP Reassembly Mode on IDS Sensors

[kurtpatzer]

Hello,

I'm looking for a more detailed description of the 2 TCP reassembly mode options on Cisco IDS Sensors (strict vs loose). I've searched the CCO. The sensor command line reference simply lists the 2 options with no descriptions. Same for IDS MC users guide. The IDM user guide has this tidbit:

Select the mode of reassembly in the TCP Reassemble Mode list box:

• strict—If a packet is missed for any reason, all packets after the missed packet

are be processed.

• loose—Use in environments where packets might be dropped.

Can someone in the know elaborate? It sounds like Strict means keep trying to do stream reassembly even if a packet is missed, while Loose says stop trying to do reassembly on any stream where a packet is missed. Is this correct?

What are the ramifications? Obviously there are all sorts of evasion strategies to use if TCP stream reassembly stops. Why would I ever select loose?

Thanks,

KEP

[travis-dennis_2]

If memory serves the box takes a performance hit when "Strict" is used. It also in my opinion makes the box a target for DoS attack by means of locking up the resources trying to reassemble packets and thus allowing an actual attack to go undetected. The settings out of the box would most definatly allow this but if you tune your sensor correclty and monitor your environment actively you can greatly diminish this as a possibility. You might want to use Loose until you have your sensor tuned if you think you are getting active attempts to get in and not just the usual script-kiddies scanning a million ip address every nano-second from mom's laptop. Noone can really tell you which way is best in my humble opinion. So much depends on your envirnment and the variables present there. The 3 rules in Real Estate are "Location, Location, Location". The 3 rules in IDS are "Monitor, Monitor, Monitor" If you Monitor and then tune properly according to your enviornment you can stop darn near anything dead.

Here is a link on this.

http://www.cisco.com/en/US/products/sw/cscowork/ps3990/products_user_guide_chapter09186a008018d974.html#754655

Anyone else wanna chime in?

Please remember to rate all replies

[marcabal]

I think you pretty much understand the differences. The sensor will always try to do TCP Session Reassembly. When it receives data it will wait for the corresponding ACK from the other side before analyzing the data (to avoid IDS evasion scenarios).

The difference is what happens when the ACK is not received within the timeout period. In Strict mode the sensor stops watching that TCP Stream. In Loose mode the sensor goes ahead and continues to analyze the TCP Stream,

When should you use which setting?

In some setups the sensor may not receive all of the packets, in which case Loose Reassembly may be necessary to keep the sensor analyzing as much as possible. This can happen with a span port on the switch, where the span port is monitoring several source ports. You can have short bursts that cause the switch's buffers on the span port to fill up and a few packets get lost by the switch and never make it to the sensor for analysis.

Or you may have situations where short bursts may go above the performance level of the sensor and the sensor looses a few packets.

In most cases, however, Strict Reassembly would be the suggested method.

In later versions you may also see a third option. I believe it may be called "assymetric". This can be used in situations where the sensor only sees one direction of the traffic. In this mode the sensor will never wait for the ACKs because it only sees the packets going in on direction and will never see the corresponding ACK.

This is often used in networks where inbound traffic goes though one set of routers/switches being monitored by the sensor, and outbound traffic goes though a second set of routers/switches not being monitored by the sensor.

This setting is not recommended, and is prone to false positives as well as false negatives (alarm not firing for a real attack). It should only be used when there is no other option for monitoring the traffic.

[kurtpatzer]

Actually I think I had it completely backwards! If I read your reply correctly, strict mode says if the sensor misses a packet, stop doing TCP stream reassembly. Where loose mode says keep trying as hard as you can. Is this correct? The IDM Users Guide quote that I used obviously is not a complete sentence. I thought it was missing one word (to) but it was really missing 2 words (not to). Here's how I'd reword it:

strict—If a packet is missed for any reason, all packets after the missed packet are "NOT TO" be processed.

Do I have it correct now?

One good answer leads to several new questions:

1) You mentioned ACKs a bunch, which originally had me thinking about the 3 way handshake inspection. That's really a completely separate topic on whether we start doing stream reassembly or not on a particlar connection. With it checked, you are immune to stick & snot type crafted TCP packet flooding attacks, but you loose reassembly on connections that existed prior to the sensor's daemons initializing.

But what you really meant was the sensor sees an ACK for bytes that it never saw transmitted. That's when it knows it missed a packet. Correct?

2) From what I now understand: Strict means give up if a packet is missed & Loose says to keep trying as hard as you can... It seems loose provides stronger protection. The only reason I could see not to use loose would be if the sensor doesn't have the horsepower to keep up. In that case I should see 993 alarms. So, I'd use loose if I don't receive 993 alarms. Is there a flaw in my logic?

3) While I understand from a network topology standpoint when assymetric routing can occur, I don't understand this setting on the sensor. I'm guessing it is like "1 direction strict". If the mode was loose, it wouldn't matter if the flow was assymetric - it would still do the best that it could seeing exactly half the traffic. So I'm thinking it's keep processing in a strict fashion until you see the sequence number bump more than it should (indicating a missed packet) & hence stop auditing the connection at that point. Correct?

4) Do you know when assymetric was introduced?

5) And last question: I assumed 993 meant the sensor captured a packet, but had to throw it away without processing due to receive buffer overflow. Will you get a 993 alarm if a packet is missed and the sensor figures that out because it sees an ack for bytes that it hasn't processed? That would be a neat & impressive trick. But based on discussion above it might be the case.

Thanks for the help!

KEP

[marcabal]

Yes you have it correct now. I didn't catch the incorrect wording in the IDM doc. Thank you for pointing it out.

As for your other questions:

For #1

Also understand that with 3 Way HandShake turned off but Strict Reassembly turned On you will still receive some immunity to stick and snot on the management side, but still be overworked on the sensor side. You won't get the extra alarms that stick and snot try to cause which keeps your management station happy. But stick and snot could still take up memory resources as the sensor starts tracking all these sessions that it is seeing only the packet of. The sensor will see the packet and track it as a new connection, but eventually times out since it never receives an ACK for it and throws the packet away never alarming on it.

As for the ACKs discussion:

What I meant was what would happen when the sensor did not see the corresponding ACK. The sensor thinks a hacker tried inserting packets that never made it to the server, and so to prevent false alarms on these packets the sensor ignores them.

But in the case you mention where the sensor may miss a few packets and see a later ACK, then in Strict Mode it stops monitoring the connection. In Loose Mode the sensor will still go ahead and monitor the portion of the connection it did see (there was a bug in this that was fixed in one of the 4.1 service packs a few months ago).

For #2

So long as 3 Way HandShake is turned On, or else you lose all stick and snot protection.

Loose also leaves you vulnerable to a few additional IDS evasion techniques where hackers will inject packets with later sequence numbers to confuse the snesor. In Strict the sensor ignores them, but in Loose the sensor eventually timesout and could wind up analyzing them.

The only other time, is when the switch itself may dropping the packets instead of the sensor. There will be no 993 alarms here because it is the switch not the sensor dropping the packets.

On the switch you would look for errors, collisions, or overruns on the switch port.

For #3

No, the big difference between Loose and Assymetric is that Assymetric doesn't wait for the ACKs so as soon as the packet comes in it begins processing. In Loose mode the sensor will wait for the ACK before processing. What this provides is the ability for the sensor to also reorder incoming packets while it waits for the ACK. It is possible that the client sends several packets before the server ACKs and may even have to do resends because of packets getting lost en route. With Assymetric if a later sequence packet comes in we start processing it, and if an earlier sequence then follows (because of a retransmission) we just have to ignore it because the sensor has already jumped ahead in the stream. But with Loose the later sequence packet gets put in a buffer. The server doesn't ACK it because the earlier sequence packet was lost en route so the client resends the packet. When the sensor sees the resend it is able to put the packets in order and when the ACK finally comes it analyzes the packets in order.

Because of this assymetric is even more prone to false positive and false negative alarms than either Loose or Strict.

The other issue we found is that our Loose code requires at least one packet from the other side to work, so we had to create the Assymetric option for situations where you never even see the other side of the traffic.

For #4

I think it was in 4.1(1) but I am not sure.

For #5

No the 993 alarms only happen when the driver captures the packet but sensorapp is unable to analyze the packet before the driver overwrites the packet with newer packets.

The 993 alarm won't fire if gaps are seen in the sequences of TCP Streams.

[kurtpatzer]

Thanks - this was great info.

Other than we both need to learn to spell asymmetric :)

It's a real brain workout to think through the strengths and weaknesses of any particular IDS processing stance. Since none are infallible, I guess we should invest in multiple sensors for any given network and have each configured with different sensing properties!