[Snort-devel] Bug in src/dynamic-preprocessors/ftptelnet/snort_ftptelnet.c

Reinoud Koornstra sockstat at ...445...
Thu Sep 12 14:55:48 EDT 2013


Because when printing the p->dsize of the packets, every so many i saw these sizes with:

 

2144, 16222, 17376 and 17670

 

I can find no explanation other than that these are reassembled stream packets?


 



Date: Thu, 12 Sep 2013 14:33:00 -0400
Subject: Re: [Snort-devel] Bug in src/dynamic-preprocessors/ftptelnet/snort_ftptelnet.c
From: rcombs at ...402...
To: sockstat at ...445...
CC: snort-devel at lists.sourceforge.net


Why are you expecting 17k?




On Thu, Sep 12, 2013 at 2:20 PM, Reinoud Koornstra <sockstat at ...445...> wrote:



Even with the config below I didn't get the reassembled packets (17k).
I guess the only way might be to try active ftp?
 




From: sockstat at ...445...
To: rcombs at ...402...
Date: Thu, 12 Sep 2013 18:10:35 +0000
CC: snort-devel at lists.sourceforge.net 


Subject: Re: [Snort-devel] Bug in src/dynamic-preprocessors/ftptelnet/snort_ftptelnet.c


I instrumented the Detect function in detect.c to print out the data size of the packet.
p->dsize is what i used and that way i saw the reassembled packets.
Upon your advice i changed my config to this:
 
# Target-Based stateful inspection/stream reassembly.  For more inforation, see README.stream5
preprocessor stream5_global: track_tcp yes, \
   track_udp yes, \
   track_icmp no, \
   max_tcp 262144, \
   max_udp 131072, \
   max_active_responses 2, \
   min_response_seconds 5, \
   prune_log_max 0, \
   memcap 536870912, \
   show_rebuilt_packets
preprocessor stream5_tcp: policy windows, detect_anomalies, require_3whs 180, max_queued_bytes 0, max_queued_segs 0,\
   overlap_limit 10, small_segments 3 bytes 150, timeout 180, \
    ports client 21 22 23 25 42 53 70 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 all

I did passive ftp which used random ftp data ports.
I'll give this a try right away, does this look correct so far?
 



Date: Thu, 12 Sep 2013 13:37:22 -0400
Subject: Re: [Snort-devel] Bug in src/dynamic-preprocessors/ftptelnet/snort_ftptelnet.c
From: rcombs at ...402...
To: sockstat at ...445...
CC: snort-devel at lists.sourceforge.net



The point of ignore_data_chan is to identify data channels to turn off reassembly and inspection for better performance on the assumption that there is nothing worth looking at in the file, directory listing, etc.  If you need to inspect that, you want "ignore_data_chan no" AND the appropriate ports / services configured in stream5.  Since the data channel may be on port 20 or may be elsewhere, try setting "stream5_tcp: ports both all" to see if you can get the reassembly you are looking for.

Also, how are you checking for reassembly?  Nominally, the reassembly will be different for ftp than http.  You may only reassembled segments of 2*1460 or whatever.  You can set "stream5_global: show_rebuilt_packets.







On Thu, Sep 12, 2013 at 12:46 PM, Reinoud Koornstra <sockstat at ...445...> wrote:



Hi,
 
The code looked correct to me too, but didn't work the way i hoped for.
What I was trying to achieve is to get a stream reassembly for ftp like it's done for http and other protocol.
Every 4 al more full mtu packets I saw that snort reassembled some packet content together to a big packet of 17k bytes.
It doesn't do this for ftp, stream reassembly doesn't seem to work there.
I thought it was due to my inability to get identity open data channel going as everytime when snort starts it said it was not active, even though i had
ignore_data_chan no in my ftp config as you can see below.
With this argument, identify open data channel still wouldn't be on and i instrumented the code to see.
Even with this argument if (!strcasecmp("yes", pcToken)) doesn't trigger and doesn't match.
In the current code with ignore_data_chan is set to no, ServerConf->data_chan is set to 0.
 
Also, is stream reassembly happening with ftp-data packets like with http etc?
I never see packets of 17k being formed and inspected by snort like it does with http.
Thanks,
 
Reinoud.
 
 
# FTP / Telnet normalization and anomaly detection.  For more information, see README.ftptelnet
preprocessor ftp_telnet: global inspection_type stateful encrypted_traffic no check_encrypted
preprocessor ftp_telnet_protocol: telnet \
    ayt_attack_thresh 20 \
    normalize ports { 23 } \
    detect_anomalies
preprocessor ftp_telnet_protocol: ftp server default \
    def_max_param_len 100 \
    ports { 21 2100 3535 } \
    telnet_cmds yes \
    ignore_telnet_erase_cmds yes \
    ignore_data_chan no \
    ftp_cmds { ABOR ACCT ADAT ALLO APPE AUTH CCC CDUP } \
    ftp_cmds { CEL CLNT CMD CONF CWD DELE ENC EPRT } \
    ftp_cmds { EPSV ESTA ESTP FEAT HELP LANG LIST LPRT } \
    ftp_cmds { LPSV MACB MAIL M DTM MIC MKD MLSD MLST } \
    ftp_cmds { MODE NLST NOOP OPTS PASS PASV PBSZ PORT } \
    ftp_cmds { PROT PWD QUIT REIN REST RETR RMD RNFR } \
    ftp_cmds { RNTO SDUP SITE SIZE SMNT STAT STOR STOU } \
    ftp_cmds { STRU SYST TEST TYPE USER XCUP XCRC XCWD } \
    ftp_cmds { XMAS XMD5 XMKD XPWD XRCP XRMD XRSQ XSEM } \
    ftp_cmds { XSEN XSHA1 XSHA256 } \
    alt_max_param_len 0 { ABOR CCC CDUP ESTA FEAT LPSV NOOP PASV PWD QUIT REIN STOU SYST XCUP XPWD } \
    alt_max_param_len 200 { ALLO APPE CMD HELP NLST RETR RNFR STOR STOU XMKD } \
    alt_max_param_len 256 { CWD RNTO } \
    alt_max_param_len 400 { PORT } \
    alt_max_param_len 512 { SIZE } \
    chk_str_fmt { ACCT ADAT ALLO APPE AUTH CEL CLNT CMD } \
    chk_str_fmt { CONF CWD DELE ENC EPRT EPSV ESTP HELP } \
    chk_str_fmt { LANG LIST LPRT MACB MAIL MDTM MIC MKD } \
    chk_str_fmt { MLSD MLST MODE NLST OPTS PASS PBSZ PORT } \
    chk_str_fmt { PROT REST RETR RMD RNFR RNTO SDUP SITE } \
    chk_str_fmt { SIZE SMNT STAT STOR STRU TEST TYPE USER } \
    chk_str_fmt { XCRC XCWD XMAS XMD5 XMKD XRCP XRMD XRSQ } \
    chk_str_fmt { XSEM XSEN XSHA1 XSHA256 } \
    cmd_validity ALLO < int [ char R int ] > \
    cmd_validity EPSV < [ { char 12 | char A char L char L } ] > \
    cmd_validity MACB < string > \
    cmd_validity MDTM < [ date nnnnnnnnnnnnnn[.n[n[n]]] ] string > \
    cmd_validity MODE < char ASBCZ > \
    cmd_validity PORT < host_port > \
    cmd_validity PROT < char CSEP > \
    cmd_validity STRU < char FRPO [ string ] > \
    cmd_validity TYPE < { char AE [ char NTC ] | char I | char L [ number ] } >
preprocessor ftp_telnet_protocol: ftp client default \


 




Date: Thu, 12 Sep 2013 11:09:33 -0400
Subject: Re: [Snort-devel] Bug in src/dynamic-preprocessors/ftptelnet/snort_ftptelnet.c
From: rcombs at ...402...
To: sockstat at ...445...
CC: snort-devel at lists.sourceforge.net







Hi.  That code looks correct w/o patching.  strncasecmp(a,b) returns zero if a matches b.

I'm not clear on the issue that you are having.  What is your ftp configuration and what are you trying to do?


Let me know and we'll try to get it figured out.


Thanks
Russ





On Thu, Sep 12, 2013 at 3:30 AM, Reinoud Koornstra <sockstat at ...445...> wrote:



Hi Everyone,
 
I've been struggeling with trying to get trying to active this option Identify open data channels.
Even with the parameter ignore_data_chan no, it wouldn't activate.
After some instrumentation I found that we were turning it off because of a comparison that didn't go right.
Even with ignore_data_chan set to no, we'd still come in the else if which wasn't correct.
Here's a fix to the problem:
 
---- src/dynamic-preprocessors/ftptelnet/snort_ftptelnet.c.orig 2013-09-12 00:17:29.301433818 -0700
+++ src/dynamic-preprocessors/ftptelnet/snort_ftptelnet.c 2013-09-12 00:21:54.441437865 -0700
@@ -1403,11 +1403,11 @@
                                          confOption);
         return FTPP_FATAL_ERR;
     }
-    if (!strcasecmp("yes", pcToken))
+    if (strncmp("yes", pcToken, 3) != 0)
     {
         ServerConf->data_chan = 1;
     }
-    else if (!strcasecmp("no", pcToken))
+    else if (strncmp("no", pcToken, 2) != 0)
     {
         if (ServerConf->data_chan == 1)
         {
 
Thanks,
 
Reinoud.

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
Snort-devel mailing list
Snort-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!



------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________ Snort-devel mailing list Snort-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/snort-devel Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel Please visit http://blog.snort.org for the latest news about Snort!
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130912/081b4708/attachment.html>


More information about the Snort-devel mailing list