Snort Sig - (spp_ssl) Invalid Client HELLO after Server HELLO Detected

[sstretchh]

I am new to setting up pfSense. I have been working on setting up snort and pfBlockerNG to help reduce the  hits snort gets

right now I have snort in monitor only and I keep getting the below alert. Should I block this alert ? See attached screen shot

(spp_ssl) Invalid Client HELLO after Server HELLO Detected

[bmeeks]

Yes, this is an old false-positive.  Some SSL clients don't meticulously follow all the RFC standards.  I have that rule disabled in my rule set.

Bill

[sstretchh]

ahhh ok so I should add it to my sppression list ? from another forum below is what I have in it so far

#(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
suppress gen_id 120, sig_id 3

#(http_inspect) HTTP RESPONSE GZIP DECOMPRESSION FAILED
suppress gen_id 120, sig_id 6

#(http_inspect) INVALID CONTENT-LENGTH OR CHUNK SIZE
suppress gen_id 120, sig_id 8

#(http_inspect) DOUBLE DECODING ATTACK
suppress gen_id 119, sig_id 2

#(http_inspect) JAVASCRIPT WHITESPACES EXCEEDS MAX ALLOWED
suppress gen_id 120, sig_id 10

#(http_inspect) IIS UNICODE CODEPOINT ENCODING
suppress gen_id 119, sig_id 7

#(http_inspect) JAVASCRIPT OBFUSCATION LEVELS EXCEEDS 1
suppress gen_id 120, sig_id 9

#(http_inspect) BARE BYTE UNICODE ENCODING
suppress gen_id 119, sig_id 4

#(http_inspect) UNKNOWN METHOD
suppress gen_id 119, sig_id 31

#(http_inspect) MULTIPLE ENCODINGS WITHIN JAVASCRIPT OBFUSCATED DATA
suppress gen_id 120, sig_id 11

#(http_inspect) HTTP RESPONSE HAS UTF CHARSET WHICH FAILED TO NORMALIZE
suppress gen_id 120, sig_id 4

#FILE-IMAGE Directshow GIF logical width overflow attempt
suppress gen_id 1, sig_id 27525

#(http_inspect) UNESCAPED SPACE IN HTTP URI
suppress gen_id 119, sig_id 33

#PROTOCOL-DNS TMG Firewall Client long host entry exploit attempt
suppress gen_id 3, sig_id 19187

[sstretchh]

Is there a good place to go for me to read what I should start out with for alerts that are false positives that I should suppress off the bat ?

I am getting a lot of the below

(http_inspect) UNKNOWN METHOD

(http_inspect) DOUBLE DECODING ATTACK

(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE

(http_inspect) INVALID CONTENT-LENGTH OR CHUNK SIZE

[bmeeks]

For the SSL HELLO rule, I would just disable it.  On the ALERTS tab, click the red X beside the rule GID:SID in the far right column.  When a rule is disabled, Snort will not even inspect traffic against it and thus save those CPU cycles.  When just suppressed, the rule is still evaluated but it just does not generate any alerts (so wasted CPU cycles unless you are doing filtered suppression as in only suppressing for certain IP addresses, for example).

A ton of the HTTP_INSPECT preprocessor rules are prone to false positives.  There is a recommended list on the forum here in a thread from a while back that shows which of these most folks disable.  Google can be your friend in determining what some of the rules are trying to do.

Bill

[Snailkhan]

@bmeeks:

Yes, this is an old false-positive.  Some SSL clients don't meticulously follow all the RFC standards.  I have that rule disabled in my rule set.

Bill

i am also receiving these alerts but the source address is the wan address of my pfsense assigned via ppoe one of the destination ip belongs to akamai technologies..

and others cannot resolve.


[bmeeks]

@Snailkhan:

i am also receiving these alerts but the source address is the wan address of my pfsense assigned via ppoe one of the destination ip belongs to akamai technologies..

and others cannot resolve.

If you run Snort or Suricata on the WAN interface only, then you can not see your internal LAN IP addresses in alerts because the Snort daemon sees everything after the outbound NAT rules are applied (and before incoming traffic is "un-NAT'd").  For this reason, many home users prefer to run Snort or Suricata on the LAN interface.  Here, the IP addresses are seen pre-NAT when outbound and post-NAT when inbound.  This makes it easy to identify internal hosts.

Bill