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

    Repeating Snort alerts

    Scheduled Pinned Locked Moved pfSense Packages
    11 Posts 5 Posters 6.9k Views
    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.
    • E
      EGr
      last edited by

      A few weeks ago I installed Snort 2.9.2.3 pkg v. 2.5.2. Every time I check, it appears that most of the alerts are of the following types:

      (http_inspect) UNKNOWN METHOD
      (http_inspect) INVALID CONTENT-LENGTH OR CHUNK SIZE
      (http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
      (http_inspect) HTTP RESPONSE GZIP DECOMPRESSION FAILED

      Sometimes these alerts repeat within seconds of the last one. I have a feeling this might be a problem with the way Snort is configured, but I'm not entirely sure. Is it safe to suppress these? If these are legitimate issues, I will look into fixing them; but right now, I'm not 100% certain what they are (or what is causing them).

      1 Reply Last reply Reply Quote 0
      • B
        Brak
        last edited by

        These could be easily be false positives.

        I had these showing up for Apple App Store and YouTube traffic. Both would seemingly work until all of the IPs the services used eventually triggered a ban.

        See what's actually getting blocked.

        1 Reply Last reply Reply Quote 0
        • J
          joshfokis
          last edited by

          yes you want to investigate the type of traffic that is causing the alerts basic checking of the ips in whois site should be fine.

          1 Reply Last reply Reply Quote 0
          • E
            EGr
            last edited by

            @Brak:

            These could be easily be false positives.

            I had these showing up for Apple App Store and YouTube traffic. Both would seemingly work until all of the IPs the services used eventually triggered a ban.

            See what's actually getting blocked.

            It looks like there are slightly over 1000 different IP addresses for the alarms I previously mentioned. They are being caused by traffic from/to Level3, Qwest, Akami, Google, Ebay, and other (non-threatening) hosts. All of the IPs hitting my WAN interface with one of the alarms is listed here: http://dl.dropbox.com/u/15125541/ips.txt. I'm assuming that it is safe to suppress these, but what is the best way to do so? Thanks for the help everyone.

            1 Reply Last reply Reply Quote 0
            • J
              joshfokis
              last edited by

              I am not that good with snort just yet but I think the best option would be to whitelist the IPs so it wont alert on the rules. I haven't played with this long enough to say if that is a feature. Other than that it is more just typical internet "white noise."

              1 Reply Last reply Reply Quote 0
              • M
                moe2006
                last edited by

                Just tune the preprocessors… I have tuned my preprocessors by unchecking, for example http_inspect in the configuration and added following lines in "Advanced configuration pass through":

                
                    preprocessor http_inspect: \
                        global iis_unicode_map unicode.map 1252
                
                    preprocessor http_inspect_server: \
                        server default profile all ports { 80 } \
                        no_alerts
                
                

                Dont forget to restart the interface and be aware of syntax errors here, snort wont start otherwise.

                More options to tune http_inspect and others can be found here: http://manual.snort.org/node17.html#SECTION00326000000000000000.

                Okay, the no_alerts option for http_inspect seems risky, but the function of http_inspect is still turned on and rules can use this preprocessor to detect attacks. http_inspect alerts have been always false alerts due to browsing on websites, so i decided to turn it off.

                1 Reply Last reply Reply Quote 0
                • E
                  EGr
                  last edited by

                  @moe2006:

                  Just tune the preprocessors… I have tuned my preprocessors by unchecking, for example http_inspect in the configuration and added following lines in "Advanced configuration pass through":

                      
                      preprocessor http_inspect: \
                          global iis_unicode_map unicode.map 1252
                  
                      preprocessor http_inspect_server: \
                          server default profile all ports { 80 } \
                          no_alerts
                  
                  

                  Dont forget to restart the interface and be aware of syntax errors here, snort wont start otherwise.

                  More options to tune http_inspect and others can be found here: http://manual.snort.org/node17.html#SECTION00326000000000000000.

                  Okay, the no_alerts option for http_inspect seems risky, but the function of http_inspect is still turned on and rules can use this preprocessor to detect attacks. http_inspect alerts have been always false alerts due to browsing on websites, so i decided to turn it off.

                  Okay, thanks. I'll have to look into it a little bit more. I don't really understand much about the preprocessor, so I'll have to do some reading on that. Once I understand that, this will probably all make more sense.

                  Also, where do I go to change the configuration? Thanks!

                  1 Reply Last reply Reply Quote 0
                  • E
                    EGr
                    last edited by

                    @moe2006:

                    Just tune the preprocessors… I have tuned my preprocessors by unchecking, for example http_inspect in the configuration and added following lines in "Advanced configuration pass through":

                        
                        preprocessor http_inspect: \
                            global iis_unicode_map unicode.map 1252
                    
                        preprocessor http_inspect_server: \
                            server default profile all ports { 80 } \
                            no_alerts
                    
                    

                    Dont forget to restart the interface and be aware of syntax errors here, snort wont start otherwise.

                    More options to tune http_inspect and others can be found here: http://manual.snort.org/node17.html#SECTION00326000000000000000.

                    Okay, the no_alerts option for http_inspect seems risky, but the function of http_inspect is still turned on and rules can use this preprocessor to detect attacks. http_inspect alerts have been always false alerts due to browsing on websites, so i decided to turn it off.

                    So I finally got a chance to look at my snort.conf file and this is what I currently have:

                    preprocessor http_inspect: global iis_unicode_map unicode.map 1252 compress_depth 65535 decompress_depth 65535
                    preprocessor http_inspect_server: server default \
                        http_methods { GET POST PUT SEARCH MKCOL COPY MOVE LOCK UNLOCK NOTIFY POLL BCOPY BDELETE BMOVE LINK UNLINK OPTIONS HEAD DELETE TRACE TRACK CONNECT SOURCE SUBSCRIBE UNSUBSCR
                    IBE PROPFIND PROPPATCH BPROPFIND BPROPPATCH RPC_CONNECT PROXY_SUCCESS BITS_POST CCM_POST SMS_POST RPC_IN_DATA RPC_OUT_DATA RPC_ECHO_DATA } \
                        chunk_length 500000 \
                        server_flow_depth 0 \
                        client_flow_depth 0 \
                        post_depth 65495 \
                        oversize_dir_length 500 \
                        max_header_length 750 \
                        max_headers 100 \
                        max_spaces 0 \
                        small_chunk_length { 10 5 } \
                        ports { 80 81 311 591 593 901 1220 1414 1830 2301 2381 2809 3128 3702 4343 5250 7001 7145 7510 7777 7779 8000 8008 8014 8028 8080 8088 8118 8123 8180 8181 8243 8280 8800 88
                    88 8899 9080 9090 9091 9443 9999 11371 55555 } \
                        non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \
                        enable_cookie \
                        extended_response_inspection \
                        inspect_gzip \
                        normalize_utf \
                        unlimited_decompress \
                        normalize_javascript \
                        apache_whitespace no \
                        ascii no \
                        bare_byte no \
                        directory no \
                        double_decode no \
                        iis_backslash no \
                        iis_delimiter no \
                        iis_unicode no \
                        multi_slash no \
                        utf_8 no \
                        u_encode yes \
                        webroot no
                    
                    

                    Obviously, I have a lot more options set, and want to confirm if I really need them all. I'm going to look into these options more and try to determine how I should tune it. If there is anything glaringly incorrect, please let me know. Thanks again for the help.

                    1 Reply Last reply Reply Quote 0
                    • E
                      EGr
                      last edited by

                      I adjusted my preprocessor to the following, but I'm still getting INVALID CONTENT-LENGTH OR CHUNK SIZE, UNKNOWN METHOD, NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE, and HTTP RESPONSE GZIP DECOMPRESSION FAILED (so far). Does anyone have any ideas what could cause these? I'm thinking u_encode might be able to be disabled, but I don't see anything about it on the page about preprocessors. Also, I'm really unsure why GZIP is still alerting, since I removed the option form the preprocessors settings:

                      
                      preprocessor http_inspect: global iis_unicode_map unicode.map 1252 compress_depth 65535 decompress_depth 65535
                      preprocessor http_inspect_server: server default \
                          http_methods { GET POST PUT SEARCH MKCOL COPY MOVE LOCK UNLOCK NOTIFY POLL BCOPY BDELETE BMOVE LINK UNLINK OPTIONS HEAD DELETE TRACE TRACK CONNECT SOURCE SUBSCRIBE UNSUBSCR
                      IBE PROPFIND PROPPATCH BPROPFIND BPROPPATCH RPC_CONNECT PROXY_SUCCESS BITS_POST CCM_POST SMS_POST RPC_IN_DATA RPC_OUT_DATA RPC_ECHO_DATA } \
                          oversize_dir_length 500 \
                          ports { 80 81 311 591 593 901 1220 1414 1830 2301 2381 2809 3128 3702 4343 5250 7001 7145 7510 7777 7779 8000 8008 8014 8028 8080 8088 8118 8123 8180 8181 8243 8280 8800 88
                      88 8899 9080 9090 9091 9443 9999 11371 55555 } \
                          non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \
                          extended_response_inspection \
                          normalize_utf \
                          normalize_javascript \
                          ascii no \
                          bare_byte no \
                          directory no \
                          double_decode no \
                          iis_backslash no \
                          iis_delimiter no \
                          iis_unicode no \
                          multi_slash no \
                          utf_8 no \
                          u_encode yes \
                          webroot no
                      
                      

                      I should probably mention that the GZIP alerts are high numbered ports (ex: 58608 or 60172).

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

                        Just suppress the alert (that's what I did). Joel Esler (who is 'responsible for the detection created for Snort' and works at Sourcefire) says that disabling this alert will not produce any additional cost savings (at least in the case of 'MESSAGE WITH INVALID CONTENT-LENGTH OR CHUNK SIZE' and, I assume, all preprocessor type alerts.  Read the whole thread (or at least the preceding and first messages in it) for more details.

                        1 Reply Last reply Reply Quote 0
                        • E
                          EGr
                          last edited by

                          @Seb:

                          Just suppress the alert (that's what I did). Joel Esler (who is 'responsible for the detection created for Snort' and works at Sourcefire) says that disabling this alert will not produce any additional cost savings (at least in the case of 'MESSAGE WITH INVALID CONTENT-LENGTH OR CHUNK SIZE' and, I assume, all preprocessor type alerts.  Read the whole thread (or at least the preceding and first messages in it) for more details.

                          I suppressed the "MESSAGE WITH…" alerts, and will probably be suppressing the remaining http_inspect alerts. I cleared the logs, and will check them later tonight, thanks.

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