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

Berkay Koyutürk berkay.koyuturk at labrisnetworks.com
Wed Sep 27 03:49:58 EDT 2017


Hello Al,

Afpacket worked as intented. I tried to download 10 files -same 7 byte 
file which i used for nfq- and it blocked all of them as exit stats below:

*Total files processed:             10 **
**Total files data processed:        70        bytes **
**Total files buffered:              10 **
**Total files released:              10 **
**Total files freed:                 0 **
**Total files captured:              10 **
**Total files within one packet:     10 **
**Total buffers allocated:           10 **
**Total buffers freed:               0 **
**Total buffers released:            10 **
**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:    15984 **
**Number of buffers in release list: 10 **
**=============================*


But afpacket is not what the topology I want to use snort for. So looks 
like nfq is my main problem again. Why nfq is not working as I intended ?


On 25-09-2017 13:18, Al Lewis (allewi) wrote:
> Hello,
>
> As a test do you see the same results when you run snort inline with 
> afpacket?
>
>
> *Albert Lewis*
>
> ENGINEER.SOFTWARE ENGINEERING
>
> SOURCE*fire*, 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/20170927/ac929efe/attachment.html>


More information about the Snort-users mailing list