Re: FTP passive data transfer FP's and flowbits

[Kungu Panda <kungupanda () gmail com>]

This looks close to what I would like and I am certainly going to test it
out.

However, turning off all inspection seems like a large price to pay.  What
would be awesome is if the preprocessor would set a flowbit or snort rule
keyword for the data-channel flow indicating that the data-channel flow was
ftp.  This keyword/flowbit then could be used on a per-rule basis.

There are plenty of instances where inspecting inside the data-channel
communications with a rule is necessary.

K.Panda





On Tue, Jan 11, 2011 at 5:39 PM, Jason Brvenik <jasonb () sourcefire com>wrote:

> I believe what you are looking for already exists. The configuration
> parameter is
>
> * ignore_data_chan yes/no *
> When set to "yes", causes the FTP preprocessor to force the rest of snort
> to ignore the FTP data channel connections. NO INSPECTION other than state
> (preprocessor AND rules) will be performed on that data channel. It can
> be turned on to improve performance -- especially with respect to large
> file transfers from a trusted source -- by ignoring traffic. If your rule
> set includes virus-type rules, it is recommended that this option not be
> used.
>
> more detail and options are available in doc/README.ftptelnet or
>
> http://cvs.snort.org/viewcvs.cgi/snort/doc/README.ftptelnet?rev=1.10&content-type=text/vnd.viewcvs-markup
>
> If you are already using the parameter and still having issues it
> could be related to packet loss, how is utilization on your sensor, do
> you have notable packet loss?
>
> On Tue, Jan 11, 2011 at 12:11 PM, Kungu Panda <kungupanda () gmail com>
> wrote:
> > The thrust of my original inquiry missed the mark.  Trying again:
> >
> > The root of the problem/issue lies in the fact that FTP has a control
> > channel (on port 21/tcp) *and* dynamic data-channels that are completely
> > independent from the control channel.  For example:
> >     10.0.0.1:23121  <-->  172.168.1.1:21  *ftp control-channel*
> >     10.0.0.1:23125  <-->  172.168.1.1:4561  *ftp data-channel*, entirely
> > separate tcp flow from the control-channel*
> >
> > Snort, as far as I can tell, has no ability to track/associate a ftp
> > control-channel with a ftp data-channel.  This results in ftp
> data-channel
> > communications being treated as completely independent tcp flows, when
> they
> > are actually part of a larger ftp session being controlled by the
> > control-channel.  The dynamically-assigned high-ports used by the ftp
> > data-channels and the binary data within the ftp data-channel transfer
> > *constantly* false-positive trigger on snort rules.
> >
> > What I would very much like is the ability for snort to associate the ftp
> > data-channels with the control-channel.  Once this association has been
> > established having the ability to leverage using a snort rule keyword or
> > flowbit to modify the snort rule behavior so that, on a per-rule basis,
> > rules can be set to ignore or trigger on ftp dataflows.
> >
> > The capability to associated ftp control-channels and ftp data-channels
> is
> > widely used in firewalls.  The firewall only needs a rule to permit the
> > 21/tcp FTP control-channel and all subsequent dynamically-allocated
> > high-port FTP data-channels are permitted.
> >
> > I don't have any problem with the ftp/telnet preprocessor which works
> just
> > fine.
> >
> > Does that help clarify?
> > K.Panda
> >
> >
> >
> >
> > On Tue, Jan 11, 2011 at 2:48 PM, Joel Esler <jesler () sourcefire com>
> wrote:
> > > Okay, so let me ask you guys.  What can we do (Snort) to make it better?
> > > Joel
> > >
> > > On Mon, Jan 10, 2011 at 8:54 PM, Martin Holste <mcholste () gmail com>
> wrote:
> > > > I've never found the alerts generated by the FTP preproc to be helpful
> > > > for anything other than a heartbeat to prove Snort is up and sniffing
> > > > traffic.  I recently started to suppress all from that gen_id.  I'm
> > > > strongly considering doing the same for the SSL preproc.  The amount
> > > > of resources it takes to investigate each false positive is not worth
> > > > the off-chance that you will be the one to discover a
> > > > never-before-seen new FTP/telnet hack.
> > > >
> > > > On Mon, Jan 10, 2011 at 1:19 PM, Kungu Panda <kungupanda () gmail com>
> > > > wrote:
> > > > > I am experiencing a large number of false-positive alerts generated
> > > > > from ftp
> > > > > sessions; specifically ftp data sessions tripping alerts on binary
> > > > > transfers.
> > > > >
> > > > > Any recommendations on associating an ftp command channel with an ftp
> > > > > passive data-channel which, of course, occur on ports from the
> command
> > > > > channel?  Association for use with snort flowbits to identify ftp
> > > > > sessions
> > > > > and eliminate FPs on troublesome rules. . .
> > > > >
> > > > > Thanks,
> > > > > K.Panda
> ------------------------------------------------------------------------------
> > > > > Gaining the trust of online customers is vital for the success of any
> > > > > company
> > > > > that requires sensitive data to be transmitted over the Web.   Learn
> > > > > how to
> > > > > best implement a security strategy that keeps consumers' information
> > > > > secure
> > > > > and instills the confidence they need to proceed with transactions.
> > > > > http://p.sf.net/sfu/oracle-sfdevnl
> > > > > _______________________________________________
> > > > > Snort-users mailing list
> > > > > Snort-users () lists sourceforge net
> > > > > Go to this URL to change user options or unsubscribe:
> > > > > https://lists.sourceforge.net/lists/listinfo/snort-users
> > > > > Snort-users list archive:
> > > > > http://www.geocrawler.com/redir-sf.php3?list=snort-users
> ------------------------------------------------------------------------------
> > > > Gaining the trust of online customers is vital for the success of any
> > > > company
> > > > that requires sensitive data to be transmitted over the Web.   Learn
> how
> > > > to
> > > > best implement a security strategy that keeps consumers' information
> > > > secure
> > > > and instills the confidence they need to proceed with transactions.
> > > > http://p.sf.net/sfu/oracle-sfdevnl
> > > > _______________________________________________
> > > > Snort-users mailing list
> > > > Snort-users () lists sourceforge net
> > > > Go to this URL to change user options or unsubscribe:
> > > > https://lists.sourceforge.net/lists/listinfo/snort-users
> > > > Snort-users list archive:
> > > > http://www.geocrawler.com/redir-sf.php3?list=snort-users
> > >
> > >
> > >
> > > --
> > > Joel Esler
> > > Skype:eslerjoel
> > > http://blog.snort.org
> ------------------------------------------------------------------------------
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users () lists sourceforge net
> > Go to this URL to change user options or unsubscribe:
> > https://lists.sourceforge.net/lists/listinfo/snort-users
> > Snort-users list archive:
> > http://www.geocrawler.com/redir-sf.php3?list=snort-users
>
>
>
> --
> Regards,
>
> Jason.
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users