snort-inline-users — The goal of this list is to help users debug/use snort_inline

[Snort-inline-users] release of snort_inline-2.2.0-RC1

[William M. <Wil...@kc...>]

List,

The snort_inline team Rob, Victor, and I have decided to make
snort_inline-2.2.0 available as a release candidate.  snort_inline-2.2.=
0
will first be released with "RC" status due to the large number of chan=
ges
we have made in this version.  We have included the following features =
in
snort_inline-2.2.0-RC1:

Added iptables state support via marks in stream4
Added ClamAV preprocessor code, enable clamav: --enable-clamav in
./configure (disabled by default)
Changed default behavior of checksum_mode to drop packets with bad
checksums.  Can log dropped packets via "log" in config checksum.
Added the ability to send resets out of a physical device via layer2res=
ets
(disabled by default)

Please consult doc/README.INLINE, doc/README.clamav, and
etc/snort_inline.conf for more information on these new features.

As always, feedback, patches, and comments are welcome.

You can find the source at http://snort-inline.sf.net/download.html

Regards,

Will=

Re: [Snort-inline-users] Acquisition plugins

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

Hi Nate,

Snort_inline needs to get it's packets from the Packet Filter of the OS. For 
Linux/iptables this is done through the QUEUE target. As far as i know this 
is considerably slower than snort+pcap. But we need the underlying 
packetfilter to do the actual dropping for us. For Snort_inline, i don't 
really know what the bottleneck is, but can you describe your setup and 
problems?

Regards,
Victor

On Wednesday 08 September 2004 22:07, Nathaniel Haggard wrote:
> This quote from Snort 2.0 Intrusion Detection by Brain Caswell
> published by syngress leads me to believe that there is such a thing
> as acquisition plugins: "The Snort 2.0 architecture allows for what
> are called 'acquisition plug-ins.' These plug-ins allow a developer to
> write a specific packet-capture network card driver for a particular
> operating system (Linux), and this plug-in would provide Snort with
> packet capture at much higher speeds."
>
> I'm interested in "much higher speeds" such as 350MB+ does anyone have
> any information on these plugins such as where to get them or how to
> start developing such a plugin?
>
> Thanks,
> Nate
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users

[Snort-inline-users] Acquisition plugins

[Nathaniel H. <nat...@gm...>]

This quote from Snort 2.0 Intrusion Detection by Brain Caswell
published by syngress leads me to believe that there is such a thing
as acquisition plugins: "The Snort 2.0 architecture allows for what
are called 'acquisition plug-ins.' These plug-ins allow a developer to
write a specific packet-capture network card driver for a particular
operating system (Linux), and this plug-in would provide Snort with
packet capture at much higher speeds."

I'm interested in "much higher speeds" such as 350MB+ does anyone have
any information on these plugins such as where to get them or how to
start developing such a plugin?

Thanks,
Nate

Re: [Snort-inline-users] snort_inline on Hp-ux? (was: Re: Snort-inline-users digest, Vol 1 #222 - 1 msg)

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

Hi Prabu,

I don't know if it can work, but a quick search in Google tells me Hp-ux is 
using IPFW, which Snort_inline supports. So i would say, give it a go and 
post errors, problems or success stories to the snort_inline-users 
mailinglist. We will try to assist you where possible.

Be sure to use ./configure --enable-ipfw when building...

If someone knows that this can't work for some reason, please correct me!

Regards,
Victor

On Friday 03 September 2004 07:49, prabu wrote:
> Hi Folks,
>        i have been playing with snort for a while.I am running snort on my
> HP-ux box.I am curious to work on snort-inline.But,I guess it works only on
> linux machines.I want to know whether snort-inline can be build on HP-UX?.
> Cheers,
> Prabu.S
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.747 / Virus Database: 499 - Release Date: 9/1/2004
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users

[Snort-inline-users] Re: Snort-inline-users digest, Vol 1 #222 - 1 msg

[prabu <pra...@ho...>]

Hi Folks,
       i have been playing with snort for a while.I am running snort on my
HP-ux box.I am curious to work on snort-inline.But,I guess it works only on
linux machines.I want to know whether snort-inline can be build on HP-UX?.
Cheers,
Prabu.S


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.747 / Virus Database: 499 - Release Date: 9/1/2004

[Snort-inline-users] [ANNOUNCE/PATCH] layer2 resets a.k.a. Reject in Bridge-mode

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

Hi List,

Those of you running Snort_inline in bridge-mode are stuck with dropping bad 
traffic, while we, the cool NAT-dudes, can use resets as well. William 
decided that this needed to be changed, so we've written a patch for this.

The attached patch will add layer2 resets to Snort_inline. Before you all 
start to cheer two important notes:

1. currently it only works on Linux/Iptables. It should be fairly easy to 
support IPFW as well, and if someone wants to work on this, we will support 
you where we can.

2. Iptables gives us only the source-macaddress of a packet. This means that 
we cannot just use the destination mac from the packet as the source mac of 
the reset-packet. 
Implications? Two again:

A. If an attacker can see the macaddress of the reset-packet, he will notice             
that it didn't came from the box he was communicating with. _And_ he will get  
the mac of your (stealthy) Snort_inline box.

B. If you have a switch that has fixed ip/mac combinations, our packets will 
be dropped.

So we added an option to the configfile where you can supply the macaddress 
snort_inline should use to send resets. This will not solve issue B, but will 
at least keep the macaddress of the snort_inline box secret.

Layer2 resets are off by default, and can be enabled by an option in the 
configfile:

config layer2resets

tells snort_inline to use layer2 rests and uses the mac address of the bridge 
as the source mac in the packet.

config layer2resets: 00:06:76:DD:5F:E3

will tell snort_inline to use layer2 resets and uses the src mac of 
00:06:76:DD:5F:E3 in the reset packet.

So with those remarks in mind, please start testing the resets. The credits 
for the patch go to William, as he did the bulk of the work! All hail 
William! :-)

We will be very happy to answer your questions!

Regards,
Victor

Re: [Snort-inline-users] Changing maintainer and future plans

[<ka...@ez...>]

On Wed, 1 Sep 2004 09:20:59 -0500
 William Metcalf <Wil...@kc...> wrote:
>
>
>
>
>
>List,
>
>I know things have been pretty quiet on the list lately.


You know - some people simply don't say it enough.
Snort_inline and the snort team TOTALLY ROCK!!!! 

Everyone involved with this project, from the originators
to the newest team members need to be really proud of the
efforts that put forth on on such a foundational product
such as snort/snort_inline.  

A personal thanks to all involved!!!!

regards
Kat

[Snort-inline-users] Changing maintainer and future plans

[William M. <Wil...@kc...>]

List,

I know things have been pretty quiet on the list lately. But I assure y=
ou,
we have been very busy working on snort_inline and evaluating the
snort_inline code that is being integrated into the snort-2.3 source
branch. That's right, you heard it here first: snort-2.3 will have
snort_inline functionality built into it. Rob, Victor and I will be
maintaining and supporting it.  We will still maintain snort_inline as =
a
separate project and use it as vehicle for bleeding-edge functionality =
and
honey net-specific features.

There will be a change to the snort_inline hierarchy. I take over as th=
e
lead developer on the snort_inline project because of Rob's busy schedu=
le.
Victor Julien will be my right-hand man and second in command. Victor i=
s a
gifted programmer, and everything we have been working on lately has be=
en a
team effort between the two of us.

We should release snort_inline-2.2.0 shortly, and we hope it will have =
the
option added in to perform resets via a physical device rather than a r=
aw
socket. In other words, this is for all of you running snort_inline acr=
oss
a bridge in stealth mode, or with no IP address assigned to the bridge
interface. You will still be able to send resets to the offending clien=
t.

Don't hesitate to e-mail Rob, Victor or me with any questions, concerns=
 or
comments.

Regards,

Will=

[Snort-inline-users] patch against snort-2.2.0 everything included from rel3+ClamAV patch

[William M. <Wil...@kc...>]

Small update.......

https://sourceforge.net/tracker/index.php?func=detail&aid=1012679&group_id=78497&atid=553469

This has everything rel3 did+ the ClamAV preproc stuff

Regards,

Will

[Snort-inline-users] diff is too big even bziped

[William M. <Wil...@kc...>]

The diff is too big to post to the list even gziped.  I will create a clam
only diff this weekend and post to this list, in the meantime if anybody
wants the diff just send me an e-mail and I would be more than happy to
send it you.

Regards,

Will

[Snort-inline-users] ClamAV+stream4 iptables state+ sighup patch for snort-2.2.0

[William M. <Wil...@kc...>]

Alright,

Coming in an e-mail following this is a diff for snort_inline-2.2.0 +
ClamAV preproc+ iptables state +sighup.  Once again Victor Julien did t=
he
majority of the work on this preproc, and deserves a thank you from all=

that find use for it.  On to the preproc, you can enable the ClamAV
preprocessor by running ./configure --enable-clamav.  You can specify t=
he
include directory by doing ./configure --enable-clamav
---with-clamav-includes=3DDIR if clamav.h can't be found by the configu=
re or
if the dbdir can't be found you may specify with configure by ./configu=
re
--enable-clamav --with-clamav-defdir=3DDIR.  You must have clamav and
clamav.h available we do not provide it in the patch.

Onto the preprocessor configuration options:

turn on clamav by going into snort_inline.conf

preprocessor clamav

This turns on the defaults for clamav which are to listen on ports 21 2=
5 80
81 110 119 139 445 143
uses the default database location of /var/lib/clamav unless another db=
dir
was specified at ./configure
Alerts are written to alert logs no packets are rejected or dropped.

options are

preprocessor clamav:  ports {portlist separated by " "}, {flow can be
toclientonly or toserveronly or defaults to both} {action can be
action-drop or  action-reset otherwise default to writing to alert
file},{dbdir}

so

preprocessor clamav: ports all !25 !443 !22, action-reset


will turn on clamav will listen for virus activity on all ports except =
25
443 22 and send a reset and drop the packet if a virus is detected.


preprocessor clamav: ports 139 445 21, toclientonly, action-drop, dbdir=

/var/lib2/clamav

will turn on clamav, will listen for virus activity on ports 129 445 21=

will only watch traffic that flows to the client, will drop the packet,=

sets the virus-sig database path to /var/lib2/clamav


Will try to put together some better documentation...... but either way=

here is the patch

depending on OS some may need to run the following command before runni=
ng
configure otherwise it will not configure properly.

libtoolize -f && aclocal && autoheader && automake && autoconf=

Re: [Snort-inline-users] snort_inline-2.2.0 let's try that again patch

[Josh B. <jos...@li...>]

Have Victor's patches and the stream4 patches for tracking state been
added to the main snort-inline2.1.3b source?  Or do I still need to
download and run the patch?

>
>
>
>
> Let's try that again, this should compile cleanly no matter what version
> of
> gcc you have : -), ummmmm actually I'll be surprised if the last diff
> compiled for anyone.  My apologies.... it was late and I was working on
> three hours of sleep.
>
> Regards,
>
> Will
>
> (See attached file: snort_inline-2.2.0rel3.diff.gz)

Re: [Snort-inline-users] snort_inline patch against snort 2.2.0

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

On Thu, 12 Aug 2004, William Metcalf wrote:

>
> If I remember correctly just Freebsd and ipfw.

 	Yes, just FreeBSD with ipfw (through a divert socket).
 	Although, probably need to investigate moving that interface
 	through a FreeBSD Netgraph module...will look into that.

[SNIP]
>
> On Thursday 12 August 2004 06:21, William Metcalf wrote:
>> List,
>>
>> For all of you early adopters out there, I know that Rob is busy with
> other
>> honeynet.org stuff.  So for all of you who can't wait,  have created a
> diff
>> against snort-2.2.0 included the iptstate stuff+ Victors sighup patch.
>> Also added a missing #ifdef GIDS #ifndef IPFW for all you bsd users out
> just curious, as i thoougt it only works with linux, so my question: does
> snort_inline work with openbsd pf?
>>
>> Regards,
>>
>> Will
>>
>
> buzz
>

Nick Rogness <ni...@ro...>
-
   How many people here have telekenetic powers? Raise my hand.
   				-Emo Philips

[Snort-inline-users] snort-2.2.0 patch

[William M. <Wil...@kc...>]

Sorry guy's looks like I made the same parser.c error again with the hard
returns in the DEBUG statements.....  Will fix tonight, send new patch....

Regards,

Will

Re: [Snort-inline-users] snort_inline patch against snort 2.2.0

[buzz <rei...@fh...>]

On Thursday 12 August 2004 06:21, William Metcalf wrote:
> List,
>
> For all of you early adopters out there, I know that Rob is busy with other
> honeynet.org stuff.  So for all of you who can't wait,  have created a diff
> against snort-2.2.0 included the iptstate stuff+ Victors sighup patch.
> Also added a missing #ifdef GIDS #ifndef IPFW for all you bsd users out
just curious, as i thoougt it only works with linux, so my question: does 
snort_inline work with openbsd pf?
>
> Regards,
>
> Will
>

buzz

[Snort-inline-users] Re: Stream4 Iptables State Patch against snort_inline-2.1.3b

[Rob M. <ro...@ho...>]

Gents,
     This is awesome.  Great work!

Rob

On Mon, 9 Aug 2004, William Metcalf wrote:

> Date: Mon, 9 Aug 2004 19:52:15 -0500
> From: William Metcalf <Wil...@kc...>
> To: sno...@li...
> Cc: vi...@nk..., ro...@ho...
> Subject: Stream4 Iptables State Patch against snort_inline-2.1.3b
> 
>
>
>
>
>
> List,
>
> I have attached the patch that Victor Julien and I have been so diligently
> working on (at the disgust of our significant others) to get iptables state
> matching into stream4. We have added new options to the stream4 preproc
> that will allow you to use iptables marks to track iptables state, and pass
> this information to stream4.  What does this mean???  Even if a session is
> pruned in stream4 and is still a valid tcp session stream4 will create a
> new session for it, mark it as established which will force fpdetect to
> take a look at it.  So some quick examples from README.INLINE are below,
> this shouldn't affect you BSD users out there as it will only add these
> features if running linux+iptables due to #ifdef GIDS #ifndef IPFW
> statements. In addition Victor and I are working on a ClamAV preprocessor
> for snort/snort_inline which uses a clamav c function to send specified
> traffic that passes through snort/snort_inline to a virus checker.  We have
> the preprocessor working, we just have to add some configure options for
> lclamav and the virus defs directory.  Would anybody like to see a
> snort_inline 2.2.0 RC with the clamav preproc and stream4 iptables state?
>
> Regards,
>
> Will
> (See attached file: stream4iptstatefinal.diff)
>
> *******************************************************************************************************
> In addition we can now track tcp state through the iptables --set-mark
> command
> this makes it possible to use stream4 and not drop valid tcp sessions in
> which
> data might not be sent for long periods of time.  In addition this will fix
> the
> problem prunning sessions and fpdetct not matching on attacks because of a
> midstream
> session flag set in a valid tcp session.example,
>
> iptables -t mangle -A FORWARD -p tcp --syn -m state --state NEW --dport 80
> -j MARK --set-mark 1
> iptables -t mangle -A FORWARD -p tcp --syn -m state --state NEW --dport 23
> -j MARK --set-mark 2
> iptables -t mangle -A FORWARD -p tcp --syn -m state --state NEW --dport 445
> -j MARK --set-mark 3
> iptables -t mangle -A FORWARD -p tcp --syn -m state --state NEW --dport 25
> -j MARK --set-mark 4
> iptables -t mangle -A FORWARD -p tcp --syn -m state --state NEW --dport
> 6667 -j MARK --set-mark 5
> iptables -t mangle -A FORWARD -p tcp -m state --state ESTABLISHED -j MARK
> --set-mark 6
> iptables -I FORWARD -m mark --mark 1 -j QUEUE
> iptables -I FORWARD -m mark --mark 2 -j QUEUE
> iptables -I FORWARD -m mark --mark 3 -j QUEUE
> iptables -I FORWARD -m mark --mark 4 -j QUEUE
> iptables -I FORWARD -m mark --mark 5 -j QUEUE
> iptables -I FORWARD -m mark --mark 6 -j QUEUE
> iptables -I FORWARD -p udp -j QUEUE
> iptables -I FORWARD -p icmp -j QUEUE
>
> we can then tell stream4 to look for a mark or a range of marks for
> new,related, and established traffic.
> example of what would be used for the iptables rules above.
>
> preprocessor stream4: disable_evasion_alerts,iptablesnewmark
> 1-5,iptablesestmark 6,forceiptstate
>
> This tells stream4 to create a new session for any new session with the
> marks 1-5 and deal with the data as
> it normally would and create a new session if there is not one for packets
> with a mark of 6 and set the session
> flags as established.  forceiptstate tells stream4 that if a packet does
> not have one of our marks to drop it.
>
> The really easy version......
> iptables -t mangle -A FORWARD -p tcp --syn -m state --state NEW -j MARK
> --set-mark 1
> iptables -t mangle -A FORWARD -p tcp --syn -m state --state ESTABLISHED -j
> MARK --set-mark 2
> iptables -A FORWARD -j QUEUE
>
> preprocessor stream4:
> disable_evasion_alerts,iptablesnewmark,iptablesestmark,forceiptstate
>
> the iptablesnewmark defaults to 1 and the iptablesestmark defaults to 2.
> **********************************************************************************************************

Re: [Snort-inline-users] snort_inline looses packets from QUEUE (was: Disappearing packets)

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

On Monday 09 August 2004 16:12, you wrote:
> increasing the timeout "fixed" it
>

Good! I will ask William when we will release the patch!

Regards,
Victor


> i will try the patch this evening when its not that warm in my room


>
>
> thx
> Markus

Re: [Snort-inline-users] snort_inline looses packets from QUEUE (was: Disappearing packets)

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

On Sunday 08 August 2004 10:15, Markus Koetter wrote:
> hi snorters
>
> i can reproduce this bug, so i think it should be mentioned
> setup is
>
> debian unstable,
> 2.4.20-gentoo-r5
> iptables v1.2.11
> snort_inline 2.13b
>
> snort is compiled from src und uses mysql as db backend
>
> i removed all other rulessets from snort_inline.conf and the only one
> running in local.rules is
>
> alert tcp $HOME_NET any -> $EXTERNAL_NET any \
> (\
>        msg: "irc tagged session ";\
>        content: "NICK"; \
>        nocase;\
>        pcre:"/^NICK\.*/i";\
>        classtype: bad-unknown ;\
> #       resp:rst_snd;\
>        sid:1000011;\
>        tag: session, 12, seconds;\
>        rev:4;\
> )
>
> the database plugin has wrong information about tagged packets, but
> thats not the real problem here
>
> as one can imagine reading the rule is meant to tag irc traffic
>
> iptables -A OUTPUT -p tcp --dport 6667 -j QUEUE
> iptables -A INPUT -p tcp --sport 6667 -j QUEUE
>
> these rules do the work
>
> now we goto some ircnet and wait
> we use the box running snort_inline to connect using irssi or some
> other chat client
>
> we can spend some time checking if tagging the first 12 seconds
> worked, and it worked, as mentioned before the database plugin does
> not set the right SID and msg, but it loggs the packet
>
> after ~20 min irssi is unable to send to the irc server, and the irc
> server is unable to send to me
> irssi's lagmeter powers up and after 300 seconds it will reconnect
> because it guesses the server has a pingtimeout
> snort_inline`s console shows that the ircnet sended us that we had the
> pingtimeout
>
> if irssis lagmeter is arounf 200 seconds, we can try a
> iptables -F
> to flush the QUEUE
> and we wont get disconnectet
>
> please try this on your own box, it works with me
>
> here i went to some large channel in quakenet to get a constant (spam)
> msg stream
> i started ethereal on some other box in my hubbed network and waited
> for my pingtimeout
>
> ->
> marks stuff the snort_inline host sends
>
> <-
> marks stuff the snort_inline host receives
>
> -> PING online1.no.quakenet.org
>
> <- :online1.no.quakenet.org PONG online1.no.quakenet.org
>
> :online1.no.quakenet.org
>
> -> PING :online1.no.quakenet.org
> ...
> ...
> -> ERROR :Closing Link: privmsg by online1.no.quakenet.org (Ping timeout)
>
> as one can see he _got_ the packet
> but snort_inline lost it somewhere
>
> now i will try this
>
> alert tcp $HOME_NET any -> $EXTERNAL_NET any \
> (\
>        msg: "irc tagged session ";\
>        content: "NICK"; \
>        nocase;\
>        pcre:"/^NICK\.*/i";\
>        classtype: bad-unknown ;\
> #       resp:rst_snd;\
>        sid:1000011;\
>        tag: session, 12, seconds;\
>        rev:4;\
> )
>
> alert tcp $HOME_NET any -> $EXTERNAL_NET any \
> (\
>        msg: "irc PING";\
>        content: "PING"; \
>        nocase;\
>        classtype: bad-unknown ;\
> #       resp:rst_snd;\
>        sid:1000012;\
>        tag: session, 12, seconds;\
>        rev:1;\
> )
>
> alert tcp $HOME_NET any -> $EXTERNAL_NET any \
> (\
>        msg: "irc PONG";\
>        content: "PONG"; \
>        nocase;\
>        classtype: bad-unknown ;\
>        sid:1000013;\
>        rev:1;\
> )
>
> iptables -A OUTPUT -p tcp --dport 6667 -j QUEUE
> iptables -A INPUT -p tcp --sport 6667 -j QUEUE
>
> i know the 2 new rules are not that exact, but it will fit here
>
> i goto #musik in quakenet and
> #findscrim in gamesurge
>
> #musik is quite idle this time,
> #findscrim is some shiny color spam, i never understood what this
> channel is used for, but it works for this case, he has instant
> traffic
>
> quakenet #musik performs this way
>
> this is what ethereal gets
> the gline is a shiny mark i guess
> ....
>
> -> PING port80c.se.quakenet.org
> <- :port80c.se.quakenet.org PONG port80c.se.quakenet.org
>
> :port80c.se.quakenet.org
>
> <- :Carny_Mailbox!~geh...@pD... JOIN :#musik
> <- :[Che]!~Ch...@DM... JOIN :#musik
> <- :freddy`!fr...@su... QUIT :G-lined
> <- :RM`Aussie!Au...@Ma... PRIVMSG #musik :.ACTION is
> back after 1d10h54m: auto-away after 120m idle.
>
> -> PING port80c.se.quakenet.org
> <- :port80c.se.quakenet.org PONG port80c.se.quakenet.org
>
> :port80c.se.quakenet.org
>
> <- :NDA|aKi`off!tropi@212.12.122.11 NICK :NDA|aKi
> <- PING :port80c.se.quakenet.org
> <- :NoFVHar!~xpapr@81.215.5.120 JOIN :#musik
> <- :NoFVHar!~xpapr@81.215.5.120 QUIT :Signed off
> <- ERROR :Closing Link: privmsg by port80c.se.quakenet.org (Ping timeout)
>
> the irssi client on the snort_inline box gets this
> ....
>
> 09:34 -!- freddy` [fr...@su...] has quit [G-lined]
> 09:35  * RM`Aussie is back after 1d10h54m: auto-away after 120m idle
> *** reconnect due to 300 sec server timeout
>
> as one can see the irssi client lacks the JOIN and QUIT,
> so the irssi app never got these lines, even ethreal showed us they were
> on the line
>
> gamesurge with #findscrim as spamchannel did not suffer any
> disconnect, dont ask my why
>
> and try
> iptables -F
> if your irssi lagmeters is growing up
> irssi will get the "missing lines" and lag will go away
>
> the new PING PONG rules show that snort_inline got the PINGs we sended
> and the PINGs the Server sended, but it does not show up any PONG
> before we get disconnectet ...
>
>
> Nathaniel Haggard wrote "drop rules"
> he described the same problem
>
>
>
> i guess there are 2 possibilities,
> - ip_queue bug
> - snort_inline bug

I'm not sure this is the problem, but try to increase the stream4 timeout in 
snort_inline.conf. It defaults to 30 seconds which caused my msn-connections 
to fail. This is a known problem in snort_inline and we (William Metcalf and 
myself) are preparing a patch to fix this...

In the meantime try to set the timeout for Stream4 to a few minutes...

Hope this helps,

Regards,
Victor

>
> the funny thing is if i flush the iptables, the application gets the data
> so this seems a snort_inline problem
>
> Markus
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users

[Snort-inline-users] snort_inline looses packets from QUEUE (was: Disappearing packets)

[Markus K. <mko...@gm...>]

hi snorters

i can reproduce this bug, so i think it should be mentioned
setup is

debian unstable,
2.4.20-gentoo-r5
iptables v1.2.11
snort_inline 2.13b

snort is compiled from src und uses mysql as db backend

i removed all other rulessets from snort_inline.conf and the only one running in
local.rules is

alert tcp $HOME_NET any -> $EXTERNAL_NET any \
(\
       msg: "irc tagged session ";\
       content: "NICK"; \
       nocase;\
       pcre:"/^NICK\.*/i";\
       classtype: bad-unknown ;\
#       resp:rst_snd;\
       sid:1000011;\
       tag: session, 12, seconds;\
       rev:4;\
)

the database plugin has wrong information about tagged packets, but
thats not the real problem here

as one can imagine reading the rule is meant to tag irc traffic

iptables -A OUTPUT -p tcp --dport 6667 -j QUEUE
iptables -A INPUT -p tcp --sport 6667 -j QUEUE

these rules do the work

now we goto some ircnet and wait
we use the box running snort_inline to connect using irssi or some
other chat client

we can spend some time checking if tagging the first 12 seconds
worked, and it worked, as mentioned before the database plugin does
not set the right SID and msg, but it loggs the packet

after ~20 min irssi is unable to send to the irc server, and the irc
server is unable to send to me
irssi's lagmeter powers up and after 300 seconds it will reconnect
because it guesses the server has a pingtimeout
snort_inline`s console shows that the ircnet sended us that we had the
pingtimeout

if irssis lagmeter is arounf 200 seconds, we can try a
iptables -F
to flush the QUEUE
and we wont get disconnectet

please try this on your own box, it works with me

here i went to some large channel in quakenet to get a constant (spam)
msg stream
i started ethereal on some other box in my hubbed network and waited
for my pingtimeout

->
marks stuff the snort_inline host sends

<-
marks stuff the snort_inline host receives

-> PING online1.no.quakenet.org

<- :online1.no.quakenet.org PONG online1.no.quakenet.org
:online1.no.quakenet.org

-> PING :online1.no.quakenet.org
...
...
-> ERROR :Closing Link: privmsg by online1.no.quakenet.org (Ping timeout)

as one can see he _got_ the packet
but snort_inline lost it somewhere

now i will try this

alert tcp $HOME_NET any -> $EXTERNAL_NET any \
(\
       msg: "irc tagged session ";\
       content: "NICK"; \
       nocase;\
       pcre:"/^NICK\.*/i";\
       classtype: bad-unknown ;\
#       resp:rst_snd;\
       sid:1000011;\
       tag: session, 12, seconds;\
       rev:4;\
)

alert tcp $HOME_NET any -> $EXTERNAL_NET any \
(\
       msg: "irc PING";\
       content: "PING"; \
       nocase;\
       classtype: bad-unknown ;\
#       resp:rst_snd;\
       sid:1000012;\
       tag: session, 12, seconds;\
       rev:1;\
)

alert tcp $HOME_NET any -> $EXTERNAL_NET any \
(\
       msg: "irc PONG";\
       content: "PONG"; \
       nocase;\
       classtype: bad-unknown ;\
       sid:1000013;\
       rev:1;\
)

iptables -A OUTPUT -p tcp --dport 6667 -j QUEUE
iptables -A INPUT -p tcp --sport 6667 -j QUEUE

i know the 2 new rules are not that exact, but it will fit here

i goto #musik in quakenet and
#findscrim in gamesurge

#musik is quite idle this time,
#findscrim is some shiny color spam, i never understood what this
channel is used for, but it works for this case, he has instant
traffic

quakenet #musik performs this way

this is what ethereal gets
the gline is a shiny mark i guess
....

-> PING port80c.se.quakenet.org
<- :port80c.se.quakenet.org PONG port80c.se.quakenet.org
:port80c.se.quakenet.org
<- :Carny_Mailbox!~geh...@pD... JOIN :#musik
<- :[Che]!~Ch...@DM... JOIN :#musik
<- :freddy`!fr...@su... QUIT :G-lined
<- :RM`Aussie!Au...@Ma... PRIVMSG #musik :.ACTION is
back after 1d10h54m: auto-away after 120m idle.

-> PING port80c.se.quakenet.org
<- :port80c.se.quakenet.org PONG port80c.se.quakenet.org
:port80c.se.quakenet.org
<- :NDA|aKi`off!tropi@212.12.122.11 NICK :NDA|aKi
<- PING :port80c.se.quakenet.org
<- :NoFVHar!~xpapr@81.215.5.120 JOIN :#musik
<- :NoFVHar!~xpapr@81.215.5.120 QUIT :Signed off
<- ERROR :Closing Link: privmsg by port80c.se.quakenet.org (Ping timeout)

the irssi client on the snort_inline box gets this
....

09:34 -!- freddy` [fr...@su...] has quit [G-lined]
09:35  * RM`Aussie is back after 1d10h54m: auto-away after 120m idle
*** reconnect due to 300 sec server timeout

as one can see the irssi client lacks the JOIN and QUIT,
so the irssi app never got these lines, even ethreal showed us they were
on the line

gamesurge with #findscrim as spamchannel did not suffer any
disconnect, dont ask my why

and try
iptables -F
if your irssi lagmeters is growing up
irssi will get the "missing lines" and lag will go away

the new PING PONG rules show that snort_inline got the PINGs we sended
and the PINGs the Server sended, but it does not show up any PONG
before we get disconnectet ...


Nathaniel Haggard wrote "drop rules"
he described the same problem



i guess there are 2 possibilities,
- ip_queue bug
- snort_inline bug

the funny thing is if i flush the iptables, the application gets the data
so this seems a snort_inline problem

Markus

[Snort-inline-users] Fw: prevent high cpu usage with snort_inline?

[Gabriele G. <gab...@vo...>]

 Hello list.

 I would want to know as i can make in order not to make to very work   the cpu of the machine with snort_inline. 
 I have as the cpu high percentage goes, when i take via ftp of the rows  from the linux machine with snort_inline over. I have tried to to set    up a syntax as "$SNORT not port 21 and not port 20 -U -X -d -D -Q -c     /usr/local/etc/snort_inline.conf -w -A full -b -e -k all -i $INTERFACE   -l $DIR/$DATE" in order to avoid the control of these doors but it does  not work, other ways are?
 
 Even with the use in the rules of the "PASS tcp any any -> $syntax.." ?
 
 thanks in advance.
 
 G.

-- 
             

Re: [Snort-inline-users] Re: Disappearing packets? (resolved -> unresolved -> resolved)

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

Don't know about Will, but it sounds good to me.

Stream4 can only work properly if it sees all packets belonging to a 
connection.

Regards,
Victor

On Tuesday 03 August 2004 20:02, Peter K. Lee wrote:
> Hi Will,
>
> The problem was that when I had this rule in iptables:
>
> iptables -t filter -A INPUT -j QUEUE (sending all incoming packets to be
> handled by snort_inline)
>
> An INCOMING TCP connection request (SYN) to the box is handled w/o any
> problems.
>
> However if a connection request originated from the box itself, (i.e.
> OUTGOING to Google), via a telnet google.com 80 or such, then the
> INCOMING TCP response packet to the box gets dropped by stream4 module
> in snort.
>
> I'm not sure how stream4 works, but by how you describe it:
>
>  a normal tcp conversation should have not problem with this as every
> SYN packet we receive we create a new session for. Every packet we
> receive following this in a tcp conversation has a session in stream4
> and therefore is not dropped.
>
> I'm guessing that stream4 never sees a SYN packet because it was never
> sent to snort_inline via the QUEUE target.  The initial SYN packet just
> went straight to Google.com, and the only thing that stream4 sees is the
> (SYN ACK?) or some response making it seem like it was a stateless data
> packet coming back into the machine.
>
> So, if I understand correctly, stream4 will drop it, and it's doing what
> it's supposed to do.
>
> In that case, I guess the *proper* solution is to also feed:
>
> iptables -t filter -A OUTPUT -j QUEUE (sending all outgoing packets to
> be handled by snort_inline)
>
> so that stream4 module of snort can keep proper state and become usable.
>
> Does that sound right?
>
> -Peter
>
> On Tue, 2004-08-03 at 08:26, William Metcalf wrote:
> > I'm really not sure I understand the problem your having, maybe some
> > additional clarification would help. As far as the drop in stream4
> > preproc goes, this drop only occurs when data is sent after a stream4
> > session has been pruned, or some one is trying to send a stateless
> > attack i.e snot/stick attack, or if you have a poorly implemented
> > protocol that does not have keep-alives built-in and does not send
> > data every so often (currently working on a fix for this) a normal tcp
> > conversation should have not problem with this as every SYN packet we
> > receive we create a new session for. Every packet we receive following
> > this in a tcp conversation has a session in stream4 and therefore is
> > not dropped.
> >
> > Regards,
> >
> > Will
> > Inactive hide details for Peter"Peter K. Lee" <sa...@co...>
> >
> >
> >                                 "Peter K. Lee" <sa...@co...>
> >                                 Sent by:
> > sno...@li...
> >
> >                                 08/02/2004 06:59 PM
> >
> >
> >
> >
> >                To
> >
> > sno...@li...
> >
> >                cc
> >
> >
> >           Subject
> >
> > [Snort-inline-users] Re: Disappearing packets? (resolved -> unresolved ->
> > resolved)
> >
> >
> > I *think* this is the proper resolution...
> >
> > I don't know whether this is by design, or it is a bug, but I tracked
> > down the problem to be located in 'stream4' preprocessor of the snort
> > system.
> >
> > For the connection cases as I illustrated in the beginning, the
> > stream4
> > preprocessor issues a 'drop' (since snort_inline changes probably
> > included modifying the preprocessor from 'alert' mode to 'drop' mode).
> >
> > There seems to be some additional functions in that module that were
> > added by 'snort_inline', but I have not delved into figuring out what
> > they do.  Only thing I know is that, for whatever reason, it ALWAYS
> > drops incoming 'response' packets, as well as FORWARD packets.
> >
> > My tentative solution is to comment out the module altogether...
> >
> > Does anyone have better idea about this phenomenon?
> >
> > -Peter
> >
> > p.s. this should conclude my unnecessary soliloquy...
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by OSTG. Have you noticed the changes
> > on
> > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> > one more big change to announce. We are now OSTG- Open Source
> > Technology
> > Group. Come see the changes on the new OSTG site. www.ostg.com
> > _______________________________________________
> > Snort-inline-users mailing list
> > Sno...@li...
> > https://lists.sourceforge.net/lists/listinfo/snort-inline-users
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users

Re: [Snort-inline-users] Re: Disappearing packets? (resolved -> unresolved -> resolved)

[Peter K. L. <sa...@co...>]

Hi Will,

The problem was that when I had this rule in iptables:

iptables -t filter -A INPUT -j QUEUE (sending all incoming packets to be
handled by snort_inline)

An INCOMING TCP connection request (SYN) to the box is handled w/o any
problems.

However if a connection request originated from the box itself, (i.e.
OUTGOING to Google), via a telnet google.com 80 or such, then the
INCOMING TCP response packet to the box gets dropped by stream4 module
in snort.

I'm not sure how stream4 works, but by how you describe it:

 a normal tcp conversation should have not problem with this as every
SYN packet we receive we create a new session for. Every packet we
receive following this in a tcp conversation has a session in stream4
and therefore is not dropped.

I'm guessing that stream4 never sees a SYN packet because it was never
sent to snort_inline via the QUEUE target.  The initial SYN packet just
went straight to Google.com, and the only thing that stream4 sees is the
(SYN ACK?) or some response making it seem like it was a stateless data
packet coming back into the machine.

So, if I understand correctly, stream4 will drop it, and it's doing what
it's supposed to do.

In that case, I guess the *proper* solution is to also feed:

iptables -t filter -A OUTPUT -j QUEUE (sending all outgoing packets to
be handled by snort_inline)

so that stream4 module of snort can keep proper state and become usable.

Does that sound right?

-Peter



On Tue, 2004-08-03 at 08:26, William Metcalf wrote:
> I'm really not sure I understand the problem your having, maybe some
> additional clarification would help. As far as the drop in stream4
> preproc goes, this drop only occurs when data is sent after a stream4
> session has been pruned, or some one is trying to send a stateless
> attack i.e snot/stick attack, or if you have a poorly implemented
> protocol that does not have keep-alives built-in and does not send
> data every so often (currently working on a fix for this) a normal tcp
> conversation should have not problem with this as every SYN packet we
> receive we create a new session for. Every packet we receive following
> this in a tcp conversation has a session in stream4 and therefore is
> not dropped.
> 
> Regards,
> 
> Will
> Inactive hide details for Peter"Peter K. Lee" <sa...@co...>
> 
> 
>                                 "Peter K. Lee" <sa...@co...>
>                                 Sent by: sno...@li...
>                                 
>                                 08/02/2004 06:59 PM
>                         
>                 
>         
> 
>                To
> 
> sno...@li...
> 
>                cc
> 
> 
>           Subject
> 
> [Snort-inline-users] Re: Disappearing packets? (resolved -> unresolved -> resolved)
> 
> 
> I *think* this is the proper resolution...
> 
> I don't know whether this is by design, or it is a bug, but I tracked
> down the problem to be located in 'stream4' preprocessor of the snort
> system.
> 
> For the connection cases as I illustrated in the beginning, the
> stream4
> preprocessor issues a 'drop' (since snort_inline changes probably
> included modifying the preprocessor from 'alert' mode to 'drop' mode).
> 
> There seems to be some additional functions in that module that were
> added by 'snort_inline', but I have not delved into figuring out what
> they do.  Only thing I know is that, for whatever reason, it ALWAYS
> drops incoming 'response' packets, as well as FORWARD packets.
> 
> My tentative solution is to comment out the module altogether...
> 
> Does anyone have better idea about this phenomenon?
> 
> -Peter
> 
> p.s. this should conclude my unnecessary soliloquy...
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes
> on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users
> 

[Snort-inline-users] Re: Disappearing packets? (resolved -> unresolved -> resolved)

[Peter K. L. <sa...@co...>]

I *think* this is the proper resolution...

I don't know whether this is by design, or it is a bug, but I tracked
down the problem to be located in 'stream4' preprocessor of the snort
system.

For the connection cases as I illustrated in the beginning, the stream4
preprocessor issues a 'drop' (since snort_inline changes probably
included modifying the preprocessor from 'alert' mode to 'drop' mode).

There seems to be some additional functions in that module that were
added by 'snort_inline', but I have not delved into figuring out what
they do.  Only thing I know is that, for whatever reason, it ALWAYS
drops incoming 'response' packets, as well as FORWARD packets.

My tentative solution is to comment out the module altogether...

Does anyone have better idea about this phenomenon?

-Peter

p.s. this should conclude my unnecessary soliloquy...

[Snort-inline-users] Re: Disappearing packets? (resolved -> unresolved)

[Peter K. L. <sa...@co...>]

Crap, in excitement I forgot that there was an instance of my ipq test
code (all accept) running in the background on one of the virtual
workspace...

I'm back to square one.  My apologies for the premature 'resolution'
note! :)

-Peter

[Snort-inline-users] Re: Disappearing packets? (resolved)

[Peter K. L. <sa...@co...>]

I found out a solution, although I have no idea why it works.

Since I just couldn't understand what was going on, I started crawling
around the packet traversal code specific to snort_inline and found that
it's really just a simple abstraction layer to pulling data off of
libipq.

So I copy & pasted the test code in libipq manpage, compiled and ran in
place of snort_inline with all packets set to NF_ACCEPT.

Well, it looked like there was nothing wrong with kernel or libipq or
iptables since using the same test FORWARD iptables rule, the data
packets didn't disappear.

After a brief look at the snort_inline portion of snort, it wasn't doing
anything too different than the code in the manpage so I started to
question snort.

I was running snort_inline with -i set to eth0, switching it back and
forth between eth0 and eth1 based on which direction I wanted the
snort_inline to analyze.

But, when I removed that piece altogether, it all began to work.

I suppose libipq does not care which interface the target QUEUE comes
from, as long as it's in the QUEUE the requestor can get access to it.

Perhaps the -i flag has more relevance just for 'snort' when it is
running the signature analysis of the data, and somehow sets the status
to be 'silently drop' by default when *some* internal state doesn't
match up?  even if there is NO rule for it to take such action?

I have no idea... but w/o it everything seems to be happy.

-Peter