Repeating Snort alerts



  • 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).



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



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



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



  • 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."



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



  • @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!



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



  • 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).



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



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


Locked