TCP Window scaling in Snort_inline

The TCP window field in the TCP header is only 16 bits, so the maximum window size it can handle is only 64kb. A long time ago this was enough, but nowadays it isn’t, by far. Luckily, this is something the window scaling option fixes. Window scaling is very common these days. Your pc or laptop probably uses it by default. Snort’s stream4 however, does not support it. This means that when tracking and reassembling streams, Snort for most connections has no idea about what data is in window and which is out of window. To make matters worse, the packets that are in window when using wscaling, but appear out of window when the wscaling is not accounted for, are never used in the reassembly process. This makes Snort evadable.

One of the goals when creating the stream4inline modifications, was to be able to drop on all TCP anomalies stream4 detects. For this support for window scaling was added to Stream4, so Snort_inline would be able to drop out of window packets. There is however a big problem with window scaling. With window scaling the TCP window possibly increases to a maximum of 1GB (with the maximum wscale value of 14). Stream4 would thus theoretically have to queue up to 1GB of packet data, per stream. While this is something that is unlikely to happen during normal connections, it is possible. This could then be used by an attacker to attack Snort_inline itself.

To prevent this, I added an option to stream4inline that allows the administrator to set a maximum allowable wscale setting. Any higher setting will be normalized away. In these cases the packet is modified and the wscale lowered to the maximum that is allowed. The hosts talking to each other then think the other accepts only the lower wscale and accepts that setting. This can however have some unexpected consequences. If the link that Snort_inline deals with is high speed, high latency or both, setting the wscale value to low can result in serious performance degradation. Connections that are (way) slower than usual is how this issue shows. In these cases the wscale value needs to be increased.

The default value of Snort_inline 2.6.1.5 is a wscale of 2, which is quite low but works fine on my home DSL connection. To change the setting add ‘norm_wscale_max 5’ to your stream4 configuration line. This will allow for a wscale of up to 5. The maximum value is 14. I’d be interested in what values people use on what types and speeds of lines, so please let me know! We can use it to suggest values in the docs or to set a less insane default value šŸ™‚

18 thoughts on “TCP Window scaling in Snort_inline

  1. Hello, i have received from snortattack that you will appreciate a testing of stream4 parameters in snort_inline. I have this function configuration:

    Scenario:
    Dell SC1435, AMD DualCOre 2.8ghz, 1GB Ram, HDD SATA
    Fedora Core 7
    Snort_inline 2.6.1.5
    Internet Access: 10MBps

    Defafult configuration:
    with the default configuration o Stream4 processor the IPS crash with a lot off message “out-of byte” in the stream4 preprocessor.

    Working configuration:

    preprocessor stream4: disable_evasion_alerts,
    memcap 268435456,
    stream4inline,
    max_ooo_bytes 40000,
    max_ooo_pkts 40,
    max_seq_holes 16
    enforce_state drop,
    norm_wscale_max 10,
    truncate
    timeout 3600,
    window_size 14000
    max_sessions 65536
    large_packet_performance
    state_protection

    preprocessor stream4_reassemble: serveronly,
    favor_new,
    ports 80 25 110 445,
    emergency_ports 80 25 110 445

    The system up time with this configuration: 2 day’s
    Good performance

    Any suggestion please?

    Sorry for my english ..-)

    Best regards

    Luca Bassi

  2. Thank you for your response Luca. When you said ‘IPS crash’ did you mean snort_inline actually crashed? With a segmentation fault? Or did it get slow? Can you describe the symptoms?

    The max_seq_holes of 16 seems high to me. It suggests you have a lot of packetloss, either on the line or in the Snort_inline processing. However with the hardware you have, there should be no problem in dealing with a 10mbits line for Snort_inline…

  3. I have resolved a problem with a mail server on netware with 5 Mibit/s of average bandwidth putting norm_wscale_max at 5. šŸ™‚

  4. Yeah! Great! Good work! The connection speed of my box is like before (without snort_inline working) and I can do tests seriously šŸ™‚ Now you must only solve the performance “problem” with clamav preprocessor šŸ™‚ With antivirus option actived the cpu works at 100% all the time (p3 500 mhz slot1 ). Thanks a lot for your work šŸ™‚

  5. As far as I can see there are two ways of speeding up Snort_inline + clamav.

    1. Make sure spp_clamav processes *only* the traffic you really want to inspect for virusses. Do this with the to_server/to_client options and with the ports.

    2. Make sure spp_clamav uses less signatures to scan the traffic with. I want to have a look myself at this as well. Since spp_clamav cannot detect all types of virusses because it doesn’t unpack/decode the data, the signatures that are unable to match are just overhead. Maybe it’s possible to change the virus definition files to remove them…

  6. Hello Victor, thank you for your response… With this configuration, using nfqueue and clamav-0.91 i have solved my problem. About your question: yes snort_inline was crashed with a segmention fault.

    Actualy snort_inline.conf:

    max_sessions 32768,
    memcap 104857600,
    stream4inline,
    enforce_state,
    norm_wscale_max 7,
    max_ooo_pkts 15,
    max_ooo_bytes 64000,
    max_seq_holes 8,
    # disable_norm_wscale_alerts yes,
    # disable_ooo_alerts yes,
    # truncate,
    # timeout 3600,
    window_size 14000

    Only sometimes i receive normalization alert.

    Thank you

    Luca

  7. No, you can’t say it like that. A higher latency also is also a reason to set the window scaling higher.

    But please note that in recent version of Snort_inline this option is gone because it was not working as expected.

  8. I am interested in the code difference after you add two options to the stream4 preprocessor. Would please offer me the exact code that implements modifying tcp window scale?

    Thank you.

  9. Would you please offer me the exact code that implements modifying tcp window scale or can you figure out which part in spp_stream4.c is about the two options?

    Thank you Victor.

  10. Stream4 65 revision nornalizes the wscale of option in tcp header while stream4 69 revision normalizes the window size of tcp header. What if we add an option in the configure file. When the cpu is busy, we just normalize the wscale of syn packets because only syn packets of three handshake have the wscale option work. Then we dont have to modify all packets in a steam.

    Will it work?

  11. Lower the wscales of the client and server just make the stream slow, but the connection still remains. Right?
    Does the window size tell another host how much space the sender has to receive the packets?
    Sorry for my poor commen sense.

  12. The connection remains, but no data is sent over it anymore. In the post I linked to I described why that makes sense and why the window scaling normalization is broken and should not be used. The concept is just flawed.

  13. Hi Victor:

    When we normalize the window for a stream, the stream becomes slow because the window size is smaller, but the connection remains. This case is different than the former normalizing the wscale.

    Is my understanding right?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s