Link to home
Start Free TrialLog in
Avatar of Nhat Hoang
Nhat Hoang

asked on

Some default rules of Snort are not correct?

Hi All,

I have just built a cluster of web server behind pfsense a few days ago. As the snort log and alerts, I recognized that it seems to be wrong with some default rules of category "preprocessor.rules" as below:
- 119      4    not-suspicious    none    HI_CLIENT_BARE_BYTE
- 120      3    unknown    none    HI_SERVER_NO_CONTLEN
- 120      8    unknown    none    HI_CLISRV_MSG_SIZE_EXCEPTION
- 137      1    bad-unknown    none    SSL_INVALID_CLIENT_HELLO
I'm not sure if I'm correct or not. So I create this topic to ask for your help and experience: which rules are wrong? Do you have any collection of WAN rules for web server, FTP server, etc...
Avatar of skullnobrains
skullnobrains

"it seems to be wrong" ---> what do you expect ? what did you get instead ?

if i understand properly the above rules, they look fine to me. you need to block the corresponding traffic, but you probably should not be warned a night because they are likely to trigger a lot.

i'm unsure HI_SERVER_NO_CONTLEN is meaningful but then hardly believe you'd use a web server that does not always provide the content length. but it might break custom software with poorly designed builtin http servers implementing web APIs for example.
Avatar of Nhat Hoang

ASKER

Hi skullnobrains,
I tried to reach our website from some computer with different networks, locations. And sometimes they (the PCs) cannot reach the website, and after checking the Blocked list of Snort, the public IP address of those PCs were blocked by Snort. That's why I said that it seems to be wrong with those rules...
does it say in the log these specific rules have anything to do with it ? can i see an extract from the log ?

i assume the 2nd col is the number of hits and the first the rule number ?

note that some of these rules will trigger on network issues and possibly on fragmented packets as well.

btw i see little value in these rules. they are quite useless with a reverse proxy and not very meaningful anyway. it seems sensible to block the rest of the connections when such rules trigger because the request probably won't work anyway but blacklisting the ip is a bit too much
HI_CLIENT_BARE_BYTE
will trigger if you neglect to encode your URLs on your own site links or if the remote side is doing something it should not.
in many cases the url might work nevertheless.

HI_SERVER_NO_CONTLEN
is most likely triggered by split packets. if that is a case, it is a false positive indeed, but this means your MTU is probably too high on the server.

i looked this one on the internet but apparently snort expects all headers to be sent in a single write. this is often the case but not always : packets may be split and some servers send headers one at a time line by line.


HI_CLISRV_MSG_SIZE_EXCEPTION
consequence of the above, i guess

SSL_INVALID_CLIENT_HELLO
no idea about that. split packets would cause this issue likely but many other things as well. you'd need a capture file to debug.

why do you want to use snort in the first place ?
feedback ?
This question needs an answer!
Become an EE member today
7 DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.