[Snort-users] file_inspect holds blocked files into its memory until snort stops

Al Lewis (allewi) allewi at cisco.com
Mon Sep 25 06:18:22 EDT 2017


Hello,

As a test do you see the same results when you run snort inline with afpacket?


Albert Lewis
ENGINEER.SOFTWARE ENGINEERING
SOURCEfire, Inc. now part of Cisco
Email: allewi at cisco.com<mailto:allewi at cisco.com>

From: Snort-users <snort-users-bounces at lists.snort.org<mailto:snort-users-bounces at lists.snort.org>> on behalf of Berkay Koyutürk <berkay.koyuturk at labrisnetworks.com<mailto:berkay.koyuturk at labrisnetworks.com>>
Date: Monday, September 25, 2017 at 6:14 AM
To: "snort-users at lists.snort.org<mailto:snort-users at lists.snort.org>" <snort-users at lists.snort.org<mailto:snort-users at lists.snort.org>>
Subject: Re: [Snort-users] file_inspect holds blocked files into its memory until snort stops

Hello again,

An update to my question. I think problem is network packets or other preprocessors that handling them. When I run snort in passive mode it catches all of my blacklisted files, seen below I have downloaded 50 files with the size of 7 bytes and snort caught 50 of them:

Total files processed:             50
Total files data processed:        350       bytes
Total files buffered:              50
Total files released:              50
Total files freed:                 0
Total files captured:              50
Total files within one packet:     50
Total buffers allocated:           50
Total buffers freed:               0
Total buffers released:            50
Maximum file buffers used:         1
Total buffers free errors:         0
Total buffers release errors:      0
Total memcap failures:             0
Total memcap failures at reserve:  0
Total reserve failures:            0
Total file capture size min:       0
Total file capture size max:       0
Total capture max before reserve:  0
Total file signature max:          0
Maximum buffers can allocate:      15994
Number of buffers in use:          0
Number of buffers in free list:    15944
Number of buffers in release list: 50

But when I switch from passive to inline daq nfq, It starts that inconsistency again. Here is the result of 50 same files I tried to download when snort is inline mode:

Total files processed:             50
Total files data processed:        350       bytes
Total files buffered:              50
Total files released:              2
Total files freed:                 48
Total files captured:              2
Total files within one packet:     2
Total buffers allocated:           50
Total buffers freed:               48
Total buffers released:            2
Maximum file buffers used:         1
Total buffers free errors:         0
Total buffers release errors:      0
Total memcap failures:             0
Total memcap failures at reserve:  0
Total reserve failures:            0
Total file capture size min:       0
Total file capture size max:       0
Total capture max before reserve:  0
Total file signature max:          0
Maximum buffers can allocate:      15994
Number of buffers in use:          0
Number of buffers in free list:    15992
Number of buffers in release list: 2

Snort only caught 2 of them and freed other 48. There are no info about these exit stats either so I don't know what freeing files means. With these results I thought other preprocessors might be the reason for it so my normalize,frag3,strem5,and http_inspect preprocessors configurations looks like this:

===========================

preprocessor normalize_ip4
preprocessor normalize_tcp: ips ecn stream
preprocessor normalize_icmp4
preprocessor normalize_ip6
preprocessor normalize_icmp6

============================

preprocessor frag3_global: max_frags 65536
preprocessor frag3_engine: policy windows detect_anomalies overlap_limit 10 min_fragment_length 100 timeout 180

======================================

preprocessor stream5_global: track_tcp yes, \
   track_udp yes, \
   track_icmp no, \
   max_tcp 262144, \
   memcap 1073741824, \
   max_udp 131072, \
   max_active_responses 2, \
   min_response_seconds 5
preprocessor stream5_tcp: policy windows, \
   detect_anomalies, require_3whs 180, \
   overlap_limit 10, small_segments 3 bytes 150, timeout 180, \
    ports client 21 22 23 25 42 53 79 109 110 111 113 119 135 136 137 139 143 \
        161 445 513 514 587 593 691 1433 1521 1741 2100 3306 6070 6665 6666 6667 6668 6669 \
        7000 8181 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779, \
    ports both 80 81 311 383 443 465 563 591 593 636 901 989 992 993 994 995 1220 1414 1830 2301 2381 2809 3037 3128 3702 4343 4848 5250 6988 7907 7000 7001 7144 7145 7510 7802 7777 7779 \
        7801 7900 7901 7902 7903 7904 7905 7906 7908 7909 7910 7911 7912 7913 7914 7915 7916 \
        7917 7918 7919 7920 8000 8008 8014 8028 8080 8085 8088 8090 8118 8123 8180 8243 8280 8300 8800 8888 8899 9000 9060 9080 9090 9091 9443 9999 11371 34443 34444 41080 50002 55555
preprocessor stream5_udp: timeout 180

=========================================

preprocessor http_inspect: global iis_unicode_map unicode.map 1252 compress_depth 65535 decompress_depth 65535 memcap 503979776
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 UNSUBSCRIBE 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 200 \
    small_chunk_length { 10 5 } \
    ports { 80 81 311 383 591 593 901 1220 1414 1741 1830 2301 2381 2809 3037 3128 3702 4343 4848 5250 6988 7000 7001 7144 7145 7510 7777 7779 8000 8008 8014 8028 8080 8085 8088 8090 8118 8123 8180 8181 8243 8280 8300 8800 8888 8899 9000 9060 9080 9090 9091 9443 9999 11371 34443 34444 41080 50002 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

=======================================

Once again I am running Snort's latest version which is 2.9.9.0 and daq nfq inline mode. And I want to run it in inline mode so passive mode is not a solution for me. I am still can't figuring it out why snort behaves like that and need some help for this.

Thanks for help.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20170925/6ed737ed/attachment.html>


More information about the Snort-users mailing list