Re: Relationship between snort and ipchains and security strategies

[John Sage <jsage () finchhaven com>]

Steven:

Steven () heimann com au wrote:

> I am sorry if the following rambles and sounds naive.  I am trying to
> improve our security and am still trying to get my head around the
> different strategies and how they work together.  In the past I have relied
> on blocking everything except essential sevices and trying to keep those
> exposed services reasonably up to date to avoid known vulnerabilities.  It
> doesn't seem that this is enough any more.
>
> I am looking at what sort of automated response I can make to things like
> CodeRed.  Although we were never vulnerable to this particular attack it is
> these sorts of probes to services that I must have open that are really the
> problem.  I would like to go a little further than just logging the
> attempts via Snort.
>
> I have fiddled with Guardian for a while and it now seems to be working.
> (Well at least it is adding deny rules to ipchains)  I am a little confused
> though because even if an ip address is blocked snort still seems to log
> WEB-IIS cmd.exe access attempts from that address.  Either I have broken my
> ipchains setup or perhaps snort gets to see the packets before ipchains
> does.  ( I had to modify my ipchains setup to get it to work with Guardian
> so it is quite possible I have broken something. )


Ultimately, IMHO, blocking attacks by IP address will not be an 
effective security method: there are simply too many attacking IP's to 
be blocked.

Using Code Red as an example, I was keeping track of tcp:80 probes for 
the first four-five days of the current Code Red go-round. I have a 
spreadsheet of probes that's over 1800 lines deep, and there's almost no 
duplication in source IP addresses.. and that was up to about August 6..

And the probes are continuing right this moment as I type this, and it's 
- what? - August 19.

I'm seeing 130-160 a day...

I think your methodology wants to focus on protecting services, and 
guarding against new exploits.


> I have been looking at the documentaion on Snort but I couldn't find
> anything about how it and ipchains integrate with the ip stack.
> (Understanding the source is beyond my abilities.)  Could someone please
> briefly explain how snort does this and how this would relate to ipchains.
> i.e. Does snort get the packet before ipchains or is my setup wrong?


I can't say from technical knowledge which gets to see packets "before" 
one or the other, but from pratical use, snort and ipchains both see 
problematic packets.

For example, minutes ago a presumable initial probe by a Code 
Red-infected box for an open port 80:

ipchains:

Aug 19 20:07:52 greatwall kernel: Packet log: input DENY ppp0 PROTO=6 
12.82.129.116:1038 12.82.129.38:80 L=48 S=0x00 I=45720 F=0x4000 T=127 
SYN (#58)

snort:

[**] [1:0:0] TCP to 80 http [**]
08/19-20:07:52.007712 12.82.129.116:1038 -> 12.82.129.38:80
TCP TTL:127 TOS:0x0 ID:45720 IpLen:20 DgmLen:48 DF
******S* Seq: 0xA47C86A4  Ack: 0x0  Win: 0x2238  TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK


> Guardian is not like Portsentry as it works by examining Snort logs.  I
> understand that Portsentry is able to respond to probes quickly enough that
> the attacker does not even get a response to their first probe.  Guardian
> seems to monitor the portsentry log once each second.  This may mean that
> the attacker has opened up the vulnerability before Guardian has responded.
> I have shot myself in the foot several times in the past with Portsentry.
> A simple attempt to attach to a port does not necessarily signify bad
> intent.  Portsentry is useless if the only open ports are those which need
> to be open for public services.  At least Snort rules generally try to
> identify the intent of the probe so blocking ip's based on Snort may not be
> so likely to cause problems.


Portsentry certainly has it's place; it's running on my firewall, but it 
hasn't gone off for seven or eight months. ipchains is doing the bulk of 
the work; snort is giving me detail about the variety of what's come in.

To me portsentry is not a primary line of defense. It's more of a last 
resort, something that's always running, even when my ipchains rules are 
restarting, for example.

> I have just recompiled Snort to enable FlexResp.  I have not yet modified
> any rules to try to reset connections.  The doco refers to it as alpha code
> only.  Does anyone use it on production servers?  It seems that FlexResp in
> connection with something like Guardian may be a useful combination.  Is
> anyone else using Guardian?  The ipchains code in v1.3 seemed to be broken.
>
> My logs are full of repeated CodeRed attempts.  I would like to be informed
> once so I know what is going on and then have that ip blocked for say a
> week so my logs are useable.


Forget about blocking IP's; protect necessary services and understand 
new exploits.

My small opinion.


> Am I heading down a useful path?  Where could I find some information on
> what strategies others are using?
>
> regards
> Steven


Just some thoughts..

..I'm hope others will weigh in.

- John

--
John Sage
FinchHaven, Vashon Island, WA, USA
http://www.finchhaven.com/
mailto:jsage () finchhaven com
"The web is so, like, five minutes ago..."


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