Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    IDS/IPS
    3
    7
    20.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sstretchh
      last edited by

      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
      ![invalid_client HELLO.JPG](/public/imported_attachments/1/invalid_client HELLO.JPG)
      ![invalid_client HELLO.JPG_thumb](/public/imported_attachments/1/invalid_client HELLO.JPG_thumb)

      1 Reply Last reply Reply Quote 0
      • bmeeksB
        bmeeks
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • S
          sstretchh
          last edited by

          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
          
          1 Reply Last reply Reply Quote 0
          • S
            sstretchh
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • bmeeksB
              bmeeks
              last edited by

              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

              1 Reply Last reply Reply Quote 1
              • S
                Snailkhan
                last edited by

                @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.

                ![ssl invalied client hello after serer hello detected.png](/public/imported_attachments/1/ssl invalied client hello after serer hello detected.png)
                ![ssl invalied client hello after serer hello detected.png_thumb](/public/imported_attachments/1/ssl invalied client hello after serer hello detected.png_thumb)

                1 Reply Last reply Reply Quote 0
                • bmeeksB
                  bmeeks
                  last edited by

                  @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

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.