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 🙂
Inliniac 
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
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…
I have resolved a problem with a mail server on netware with 5 Mibit/s of average bandwidth putting norm_wscale_max at 5. 🙂
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 🙂
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…
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
norm_wscale_max 2 means for line 2mbps ? norm_wscale_max 10 for 10mpbs ? any idea of this ?
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.
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.
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.
What high speed links will snort_inline perform badly when it deal with? 10M? 20M?
See here and here for the current implementation.
Wrt the speeds, it all depends on the hardware you use. It’s hard to make general statements about that…
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?
No, please see this post. The wscale normalization principle is just flawed.
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.
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.
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?
Yes, that is correct.