snort-inline-users

[Snort-inline-users] Preprocessors and states

[Pieter V. <pv...@ab...>]

Hi,

Thanks for all helpful info. I've got snort up and running in inline 
mode, tested it with sneeze and all seems to work.

But I still  got a question : currently only packets with state new 
(only for INPUT and FORWARD not for OUTPUT) which are accepted by 
iptables are send to snort_inline in my setup

But what about detection and state? As I understood it the preprocessors 
allow tracking state for IP, TCP,.. by keeping a cache for a certain 
period. And also I suppose some rules match with specific strings not 
necesseraly in the first packet of a connection?

I suppose the defragmentation checks are unneccesary as iptables will 
execute defragmentation before it is checked by its own rules. Or is 
this not true?


So basicly my question is are the preprocessors still working when only 
new packets are checked and is it a good idea to only check new packets?


kind regards,
Pieter
Able


-- 
Pieter Vanmeerbeek
R&D Engineer
---------------------------------------------------
Able N.V.                    Tel: +32(0)15 50.44.00
Dellingstraat 28b            Fax: +32(0)15.50.44.09
B-2800 Mechelen
http://www.axsguard.com     http://www.doITsafe.net

    aXs GUARD - internet communication appliance
---------------------------------------------------

--
NEW: aXs GUARD hands-on Trainings v.7.0 
more info at http://www.axsguard.com/indextraining.htm

aXs GUARD has completed security and anti-virus checks on this e-mail
(http://www.axsguard.com)
---------------------------------------------------
Able NV: ond.nr 0457.938.087

Re: [Snort-inline-users] Preprocessors and states

[Will M. <wil...@gm...>]

> But what about detection and state? As I understood it the preprocessors
> allow tracking state for IP, TCP,.. by keeping a cache for a certain
> period. And also I suppose some rules match with specific strings not
> necesseraly in the first packet of a connection?

yeah this is true

> I suppose the defragmentation checks are unneccesary as iptables will
> execute defragmentation before it is checked by its own rules. Or is
> this not true?

As long as you are tracking state.....


> So basicly my question is are the preprocessors still working when only
> new packets are checked and is it a good idea to only check new packets?

No it is not a good idea, you need to send RELATED,ESTABLISHED traffic
as well. State NEW is only valid for the first packet in a connection.
 Your going to miss a lot of traffic, actually there really shouldn't
be data in your first syn so the only reason sneeze worked is because
you did not use the --syn flag along with your state NEW rule in
iptables, or you are not passing enforce_state to stream4

Regards,

Will

Re: [Snort-inline-users] Preprocessors and states

[Pieter V. <pv...@ab...>]

>No it is not a good idea, you need to send RELATED,ESTABLISHED traffic
>as well. State NEW is only valid for the first packet in a connection.
> Your going to miss a lot of traffic, actually there really shouldn't
>be data in your first syn so the only reason sneeze worked is because
>you did not use the --syn flag along with your state NEW rule in
>iptables, or you are not passing enforce_state to stream4
>
>Regards,
>
>Will
>
>  
>

I tested it with ICMP rules so no sync present ;)

Ok, so I better send all traffic through snort-inline.
But then I get a higher load due to kernel- userland transits.

So I'm searching for an alternative way of performing IPS with snort. I 
checked the snort docs again and found some alert target rules, i.e. 
react and resp post detection rule options, also allow blocking by snort 
(i.e. IPS funcitonality). Using these statements allow using snort 
normally.  Are there any other ways to perform IPS with snort?

What are the pros and contras of using snort-inline and using snort 
normally with the react and resp detection rules? The docs already 
indicate that react and resp rules will not be usefull for UDP traffic.

kind regards,
Pieter
Able

--
NEW: aXs GUARD hands-on Trainings v.7.0 
more info at http://www.axsguard.com/indextraining.htm

aXs GUARD has completed security and anti-virus checks on this e-mail
(http://www.axsguard.com)
---------------------------------------------------
Able NV: ond.nr 0457.938.087

Re: [Snort-inline-users] Preprocessors and states

[Nick R. <ni...@ro...>]

>
> I tested it with ICMP rules so no sync present ;)
>
> Ok, so I better send all traffic through snort-inline.
> But then I get a higher load due to kernel- userland transits.

   Because snort & snort_inline are userland apps, there is no way to
avoid the kernel-userland overhead.  There are ways to reduce it, but
not eliminate the basic fact that snort resides in userland.

One would have to move snort into a kernel module to avoid this.  I don't
know if there is a project underway to accomplish this, but most people
say it is not a good idea.  I think, if it does happen, it moves from
being a software tool to a "network appliance".

>
> So I'm searching for an alternative way of performing IPS with snort. I
> checked the snort docs again and found some alert target rules, i.e.
> react and resp post detection rule options, also allow blocking by snort
> (i.e. IPS funcitonality). Using these statements allow using snort
> normally.  Are there any other ways to perform IPS with snort?
>

  The best (current) way to implement IPS with snort is snort_inline. 
There are several reasons for this (IMHO):

    1) Snort_inline is "inline" with the traffic instead of being a post
processor engine.  This gives you the ability to react to packets and
insure they are not accidentally missed.  Packets could leak into your
network with regular snort if you are not careful.

    2) Flex-Response does give you some similar functionality as
snort_inline, but it is not the same thing.

    3)  You can do some interesting things with snort_inline that are not
possible with snort, because traffic is not inline, such as altering
traffic, etc.

    4) snort_inline is being actively developed and maintained as an IPS. 
snort_inline is ment to function as an IPS, snort is ment to function
as an IDS.

> What are the pros and contras of using snort-inline and using snort
> normally with the react and resp detection rules? The docs already
> indicate that react and resp rules will not be usefull for UDP traffic.

   The difference is snort is reading from the ethernet and snort_inline
from a higher layer, i.e. It is all relative to what you are trying to
accomplish.  In some cases,snort will be better and in other cases
snort_inline will be better.

   Regular snort sees all traffic, regardless of whether it needs to or
not.  With snort_inline, selective traffic can be inspected via the
firewall.

  Just my opinion.
Nick Rogness <ni...@ro...>

Re: [Snort-inline-users] Preprocessors and states

[Victor J. <vi...@nk...>]

> So basicly my question is are the preprocessors still working when only 
> new packets are checked and is it a good idea to only check new packets?

No, because one of the things snort and snort_inline do is check the 
payload of your connections against the signatures of known attacks. The 
syn-packet in a tcp connection will have no data, or just a very limited 
ammount when compared to the entire connection. So i would very highly 
recommend you to send all packets of a connection to snort_inline.

Regards,
Victor

Re: [Snort-inline-users] Preprocessors and states

[Pieter V. <pv...@ab...>]

OK, so in both cases it's a userland app. I checked the processor load 
and memory load in both scenarios. There seems to be no big difference.

I was wondering what the actual difference between inline drop and 
flex-response is? As I understood it well in both scenarios the 
connections is closed so no packets will traverse to the network only 
with flex-response the first and maybe a small number of packets will be 
send to the network as with snort-inline no packets will reach the 
network as snort flex-response is  actually a copy of the packet send to 
the network diverted to userland.

I also experienced some downsides with snort-inline :
- adding an extra rule to iptables requires a hup to snort-inline to 
allow packets to traverse ( imagine an ssh session in which a firewall 
rule was added ; ok solution is not to let ssh traverse inline for ssh)

- access to the machine is not possible untill snort-inline is started

- suppose snort-inline crashes for some mysterious reason ( example due 
high load and high memory usage) no traffic will be possible, same 
example with ssh which can also be solved by not sending ssh through 
inline.


However not sending some traffic though snort)inline seems as clumbsy 
solution to me. Is there another solutions to these problems?


kind regards,
Pieter


Nick Rogness wrote:

>>I tested it with ICMP rules so no sync present ;)
>>
>>Ok, so I better send all traffic through snort-inline.
>>But then I get a higher load due to kernel- userland transits.
>>    
>>
>
>   Because snort & snort_inline are userland apps, there is no way to
>avoid the kernel-userland overhead.  There are ways to reduce it, but
>not eliminate the basic fact that snort resides in userland.
>
>One would have to move snort into a kernel module to avoid this.  I don't
>know if there is a project underway to accomplish this, but most people
>say it is not a good idea.  I think, if it does happen, it moves from
>being a software tool to a "network appliance".
>
>  
>
>>So I'm searching for an alternative way of performing IPS with snort. I
>>checked the snort docs again and found some alert target rules, i.e.
>>react and resp post detection rule options, also allow blocking by snort
>>(i.e. IPS funcitonality). Using these statements allow using snort
>>normally.  Are there any other ways to perform IPS with snort?
>>
>>    
>>
>
>  The best (current) way to implement IPS with snort is snort_inline. 
>There are several reasons for this (IMHO):
>
>    1) Snort_inline is "inline" with the traffic instead of being a post
>processor engine.  This gives you the ability to react to packets and
>insure they are not accidentally missed.  Packets could leak into your
>network with regular snort if you are not careful.
>
>    2) Flex-Response does give you some similar functionality as
>snort_inline, but it is not the same thing.
>
>    3)  You can do some interesting things with snort_inline that are not
>possible with snort, because traffic is not inline, such as altering
>traffic, etc.
>
>    4) snort_inline is being actively developed and maintained as an IPS. 
>snort_inline is ment to function as an IPS, snort is ment to function
>as an IDS.
>
>  
>
>>What are the pros and contras of using snort-inline and using snort
>>normally with the react and resp detection rules? The docs already
>>indicate that react and resp rules will not be usefull for UDP traffic.
>>    
>>
>
>   The difference is snort is reading from the ethernet and snort_inline
>from a higher layer, i.e. It is all relative to what you are trying to
>accomplish.  In some cases,snort will be better and in other cases
>snort_inline will be better.
>
>   Regular snort sees all traffic, regardless of whether it needs to or
>not.  With snort_inline, selective traffic can be inspected via the
>firewall.
>
>  Just my opinion.
>Nick Rogness <ni...@ro...>
>
>
>  
>

--
NEW: aXs GUARD hands-on Trainings v.7.0 
more info at http://www.axsguard.com/indextraining.htm

aXs GUARD has completed security and anti-virus checks on this e-mail
(http://www.axsguard.com)
---------------------------------------------------
Able NV: ond.nr 0457.938.087

Re: [Snort-inline-users] Preprocessors and states

[Victor J. <vi...@nk...>]

Pieter Vanmeerbeek wrote:
> OK, so in both cases it's a userland app. I checked the processor load 
> and memory load in both scenarios. There seems to be no big difference.
> 
> I was wondering what the actual difference between inline drop and 
> flex-response is? As I understood it well in both scenarios the 
> connections is closed so no packets will traverse to the network only 
> with flex-response the first and maybe a small number of packets will be 
> send to the network as with snort-inline no packets will reach the 
> network as snort flex-response is  actually a copy of the packet send to 
> the network diverted to userland.

In your worst-case scenario, the few packets that will slip through 
while flexresp tries to tear down the connection, can complete the attack.

> 
> I also experienced some downsides with snort-inline :
> - adding an extra rule to iptables requires a hup to snort-inline to 
> allow packets to traverse ( imagine an ssh session in which a firewall 
> rule was added ; ok solution is not to let ssh traverse inline for ssh)

When adding _iptables_ rules? I cannot reproduce this and it doesn't 
make much sense to me. Snort_inline just listens to the queue, not to 
specific iptables rules.

> - access to the machine is not possible untill snort-inline is started

True. Personally, i don't use snort_inline for ssh from trusted ipaddresses.

> - suppose snort-inline crashes for some mysterious reason ( example due 
> high load and high memory usage) no traffic will be possible, same 
> example with ssh which can also be solved by not sending ssh through 
> inline.

True, however in some cases i can imagine that this is still what you 
prefer. If someone can attack snort_inline so it crashes, maybe a DoS is 
a lesser evil than 'unprotected' access. But i admit this won't be 
acceptable to many.

> 
> However not sending some traffic though snort)inline seems as clumbsy 
> solution to me. Is there another solutions to these problems?

You could see to have some sort of watchdog that can start snort_inline 
if it died.

Also, but this is for the future, the NFQUEUE work currently done at 
netfilter could be interesting, because if will allow you to run 
multiple instances of snort_inline, for example one for http, one for 
mail, etc. This might slightly reduce the risk, allthough it won't be 
gone completely.

Regards,
Victor

Re: [Snort-inline-users] Preprocessors and states

[Will M. <wil...@gm...>]

On 8/5/05, Pieter Vanmeerbeek <pv...@ab...> wrote:
> OK, so in both cases it's a userland app. I checked the processor load
> and memory load in both scenarios. There seems to be no big difference.
>=20
> I was wondering what the actual difference between inline drop and
> flex-response is? As I understood it well in both scenarios the
> connections is closed so no packets will traverse to the network only
> with flex-response the first and maybe a small number of packets will be
> send to the network as with snort-inline no packets will reach the
> network as snort flex-response is  actually a copy of the packet send to
> the network diverted to userland.



> I also experienced some downsides with snort-inline :
> - adding an extra rule to iptables requires a hup to snort-inline to
> allow packets to traverse ( imagine an ssh session in which a firewall
> rule was added ; ok solution is not to let ssh traverse inline for ssh)
>=20
> - access to the machine is not possible untill snort-inline is started

This is not true, you just have to add your rule before your QUEUE rules.

> - suppose snort-inline crashes for some mysterious reason ( example due
> high load and high memory usage) no traffic will be possible, same
> example with ssh which can also be solved by not sending ssh through
> inline.
>=20

I use a simple script to check and make sure snort_inline is running
if it isn't it is started starts it.

#!/bin/sh
ps -ef | grep snort_inline | grep -v grep >> /dev/null ||
/etc/init.d/snortd start
=20
> However not sending some traffic though snort)inline seems as clumbsy
> solution to me. Is there another solutions to these problems?
>=20
>=20
> kind regards,
> Pieter
>=20
>=20
> Nick Rogness wrote:
>=20
> >>I tested it with ICMP rules so no sync present ;)
> >>
> >>Ok, so I better send all traffic through snort-inline.
> >>But then I get a higher load due to kernel- userland transits.
> >>
> >>
> >
> >   Because snort & snort_inline are userland apps, there is no way to
> >avoid the kernel-userland overhead.  There are ways to reduce it, but
> >not eliminate the basic fact that snort resides in userland.
> >
> >One would have to move snort into a kernel module to avoid this.  I don'=
t
> >know if there is a project underway to accomplish this, but most people
> >say it is not a good idea.  I think, if it does happen, it moves from
> >being a software tool to a "network appliance".
> >
> >
> >
> >>So I'm searching for an alternative way of performing IPS with snort. I
> >>checked the snort docs again and found some alert target rules, i.e.
> >>react and resp post detection rule options, also allow blocking by snor=
t
> >>(i.e. IPS funcitonality). Using these statements allow using snort
> >>normally.  Are there any other ways to perform IPS with snort?
> >>
> >>
> >>
> >
> >  The best (current) way to implement IPS with snort is snort_inline.
> >There are several reasons for this (IMHO):
> >
> >    1) Snort_inline is "inline" with the traffic instead of being a post
> >processor engine.  This gives you the ability to react to packets and
> >insure they are not accidentally missed.  Packets could leak into your
> >network with regular snort if you are not careful.
> >
> >    2) Flex-Response does give you some similar functionality as
> >snort_inline, but it is not the same thing.
> >
> >    3)  You can do some interesting things with snort_inline that are no=
t
> >possible with snort, because traffic is not inline, such as altering
> >traffic, etc.
> >
> >    4) snort_inline is being actively developed and maintained as an IPS=
.
> >snort_inline is ment to function as an IPS, snort is ment to function
> >as an IDS.
> >
> >
> >
> >>What are the pros and contras of using snort-inline and using snort
> >>normally with the react and resp detection rules? The docs already
> >>indicate that react and resp rules will not be usefull for UDP traffic.
> >>
> >>
> >
> >   The difference is snort is reading from the ethernet and snort_inline
> >from a higher layer, i.e. It is all relative to what you are trying to
> >accomplish.  In some cases,snort will be better and in other cases
> >snort_inline will be better.
> >
> >   Regular snort sees all traffic, regardless of whether it needs to or
> >not.  With snort_inline, selective traffic can be inspected via the
> >firewall.
> >
> >  Just my opinion.
> >Nick Rogness <ni...@ro...>
> >
> >
> >
> >
>=20
> --
> NEW: aXs GUARD hands-on Trainings v.7.0
> more info at http://www.axsguard.com/indextraining.htm
>=20
> aXs GUARD has completed security and anti-virus checks on this e-mail
> (http://www.axsguard.com)
> ---------------------------------------------------
> Able NV: ond.nr 0457.938.087
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users
>