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

Russ rucombs at cisco.com
Wed Sep 27 07:31:23 EDT 2017


It would help if you sent all the shutdown counts for your NFQ passive 
and inline tests.

On 9/27/17 3:49 AM, Berkay Koyutürk wrote:
>
> 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.
>>
>
>
>
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.snort.org
> Go to this URL to change user options or unsubscribe:
> https://lists.snort.org/mailman/listinfo/snort-users
>
> Please visit http://blog.snort.org to stay current on all the latest Snort news!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20170927/5eda4725/attachment.html>


More information about the Snort-users mailing list