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

[Snort-inline-users] clamav - priority?

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

Hi,

Snort(inline) does a great job with prioritizing attacks -
but spp_clamav does not put priority on anything. This kind
of breaks many of the reporting tools. I was wondering if
there might be a way to just make all clamav alerts show as
priority 1 so things like snort_report, snorter and the
like, will put them at the top?

thanks
Kat

Re: [Snort-inline-users] preprocessor: http_inspect could drop packets?

[[Minag] <gve...@mi...>]

William,


> Ummmmm do you really want http_inspect to drop packets?=20

Really no. I was worried because I have many fp's from this preprocessor =
in
the IDS (only Snort, not Inline) and I will setup Snort-Inline on the Fir=
ewall
and I dont want to drop this fp's

I have=20
> experienced a large number of fp's from this preproc. But the answer=20
> is yes it can, you have to Call InlineDrop() from inline.h for=20
> Packet *p where the condition you want to check against is met.=20


Thanks for the reference.


> Will this ever be a standard for snort_inline probably not. I hope I=20
> didn't sound to short with you, or anybody on the list. This is day=20
> 5 without a cigarette and after 10 years of smoking(yes I'm only 24)=20
> I'm finding that I'm a tad bit irritable these days.
>=20
> Regards,
>=20

Thank you again, take care of your health.


Regards,
Geffrey

> Will
> "Geffrey Vel=E1squez [Minag]" <gve...@mi...>
>=20
> "Geffrey Vel=E1squez [Minag]" <gve...@mi...>=20
> Sent by: sno...@li...
>=20
> 01/04/2005 04:10 PM
>=20
> To =20
> sno...@li...
>=20
> cc
>=20
> Subject =20
> [Snort-inline-users] preprocessor: http_inspect could drop packets?
>=20
> Hi friends,
>=20
> I want to know if the http_inspect could drop packets, and in=20
> general any preprocessor.
>=20
> Regards,
> Geffrey Velasquez
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users
------- End of Original Message -------

[Snort-inline-users] preprocessor: http_inspect could drop packets?

[[Minag] <gve...@mi...>]

Hi friends,

I want to know if the http_inspect could drop packets, and in general any
preprocessor.  


Regards,
Geffrey Velasquez

Re: [Snort-inline-users] IPFW FreeBSD 4.10 invisible bridge

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

On Tue, 4 Jan 2005, Alex Dupre wrote:

> Nick Rogness wrote:
>>> The bridging part itself is working fine, until I divert the packets to 
>>> snort.  The one command 'ipfw add divert 6666 all from any to any' (6666 
>>> being the port I put snort on) causes a complete loss of throughput.
>
> ipfw divert action (like forward and tee) cannot be used on bridged packets.

 	That's right, I do recall hearing about this.  Funny how the
 	divert(4) man page doesn't mention anything about this.  Do you
 	know if it is possible on FreeBSD 5.X branch?


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

Re: [Snort-inline-users] IPFW FreeBSD 4.10 invisible bridge

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

On Tue, 4 Jan 2005, Christopher Black wrote:

> On Mon, 2005-01-03 at 19:44, Nick Rogness wrote:
>> On Mon, 3 Jan 2005, Christopher Black wrote:
>>
>>> On Mon, 2005-01-03 at 14:55, Nick Rogness wrote:
>>>> On Mon, 3 Jan 2005, Christopher Black wrote:
>>>>
>>>>> List,
>>>>>
>>>>> I'm running freebsd 4.10 on a system configured with no IPs, briding
>>>>> between two interfaces.  The network works fine if diverting is
>>>>> disabled, but when packets are diverted to snort_inline, snort never
>>>>> appears to recieve them.  Has anyone seen this before?
>>>>
>>>>  	What is the output of:
>>>>
>>>>  	root# sysctl net.link.ether.bridge.ipfw
>>>>
>>>>
>>>> Nick Rogness <ni...@ro...>
>>>> -
>>>>    How many people here have telekenetic powers? Raise my hand.
>>>>    				-Emo Philips
>>>
>>> bash-2.05b# sysctl -a | grep net.link.ether.bridge
>>> net.link.ether.bridge_cfg: sis0,sis1
>>> net.link.ether.bridge: 1
>>> net.link.ether.bridge_ipfw: 1
>>> ...
>>>
>>> The bridging part itself is working fine, until I divert the packets to
>>> snort.  The one command 'ipfw add divert 6666 all from any to any' (6666
>>> being the port I put snort on) causes a complete loss of throughput.
>>> Snort is never receiving them as debug statements in the main loop of
>>> inline.c report.  Is there a special bridging (as opposed to inline)
>>> mode to enable?
>>
>>  	No, snort_inline is unaware of anything in the lower layers, e.g.
>>  	bridging vs routing.  The divert socket is just a socket, not much
>>  	different than a standard TCP socket.
>>
>>  	I've never done briding+IPFW before on FreeBSD.  What happens if
>>  	you divert to say natd as a test?  Is this on FreeBSD 5.3 again?
>>
>
> This was on FreeBSD 4.10.  Since I'm under a fairly tight deadline, I
> had to revert to just doing NAT on that box.  I will try this out later
> though.  Is there a special way to create a divert socket from a
> userland application to just test to see what's hitting the socket?

 	Yes.  You can simply take the code out of any standard divert
 	userland app (such as tcpmssd or natd) and use it to read/write
 	without changing the packet.

 	I'm putting together a set of test tools to do this.

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

Re: [Snort-inline-users] IPFW FreeBSD 4.10 invisible bridge

[Christopher B. <bla...@um...>]

On Mon, 2005-01-03 at 19:44, Nick Rogness wrote:
> On Mon, 3 Jan 2005, Christopher Black wrote:
>=20
> > On Mon, 2005-01-03 at 14:55, Nick Rogness wrote:
> >> On Mon, 3 Jan 2005, Christopher Black wrote:
> >>
> >>> List,
> >>>
> >>> I'm running freebsd 4.10 on a system configured with no IPs, briding
> >>> between two interfaces.  The network works fine if diverting is
> >>> disabled, but when packets are diverted to snort_inline, snort never
> >>> appears to recieve them.  Has anyone seen this before?
> >>
> >>  	What is the output of:
> >>
> >>  	root# sysctl net.link.ether.bridge.ipfw
> >>
> >>
> >> Nick Rogness <ni...@ro...>
> >> -
> >>    How many people here have telekenetic powers? Raise my hand.
> >>    				-Emo Philips
> >
> > bash-2.05b# sysctl -a | grep net.link.ether.bridge
> > net.link.ether.bridge_cfg: sis0,sis1
> > net.link.ether.bridge: 1
> > net.link.ether.bridge_ipfw: 1
> > ...
> >
> > The bridging part itself is working fine, until I divert the packets to=
=20
> > snort.  The one command 'ipfw add divert 6666 all from any to any' (666=
6=20
> > being the port I put snort on) causes a complete loss of throughput.=20
> > Snort is never receiving them as debug statements in the main loop of=20
> > inline.c report.  Is there a special bridging (as opposed to inline)=20
> > mode to enable?
>=20
>  	No, snort_inline is unaware of anything in the lower layers, e.g.
>  	bridging vs routing.  The divert socket is just a socket, not much
>  	different than a standard TCP socket.
>=20
>  	I've never done briding+IPFW before on FreeBSD.  What happens if
>  	you divert to say natd as a test?  Is this on FreeBSD 5.3 again?
>=20
> Nick Rogness <ni...@ro...>
> -
>    How many people here have telekenetic powers? Raise my hand.
>    				-Emo Philips

This was on FreeBSD 4.10.  Since I'm under a fairly tight deadline, I
had to revert to just doing NAT on that box.  I will try this out later
though.  Is there a special way to create a divert socket from a
userland application to just test to see what's hitting the socket?
--=20
Christopher Black <bla...@um...>

Re: [Snort-inline-users] compile error with FreeBSD5.3

[Christopher B. <bla...@um...>]

the snort.h.patch file will correct the compile error you see below. 
However, you probably won't be able to pass any packets, because they
will fail the IP Header checksum.  decode.c.patch will "fix" that. 
inline.c.patch will prevent it from segfaulting on a "reject" ruleset,
because it changes all rejects to drops.

It's not pretty, but it's working for me.  Best of luck!

On Mon, 2005-01-03 at 21:55, Mike Dunigan wrote:
> Tried compiling snort_inline-2.2.0a,
> snort_inline-2.2.0, and snort_inline-2.2.0-RC1 all on
> FreeBSD5.3.
> 
> I'm using ./configure --enable-ipfw and with all 3
> vers of snort-inline it's freezing at the same spot
> with the same error:
> 
> Making all in parser
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../src
> -I../src/sfutil  -I../src/output-plugins
> -I../src/detection-plugins -I../src/preprocessors
> -I../src/preprocessors/flow
> -I../src/preprocessors/portscan 
> -I../src/preprocessors/flow/int-snort 
> -I../src/preprocessors/HttpInspect/include  
> -I/usr/local/include -I/usr/local/include  -g -O2
> -Wall -DGIDS -DIPFW -DLIBNET_BSDISH_OS
> -DLIBNET_BSD_BYTE_SWAP -DHAVE_SOCKADDR_SA_LEN
> -DLIBNET_LIL_ENDIAN -c `test -f 'decode.c' || echo
> './'`decode.c
> decode.c: In function `DecodeIP':
> decode.c:2008: error: structure has no member named
> `log_bad_checksums'
> decode.c: In function `DecodeTCP':
> decode.c:2395: error: structure has no member named
> `log_bad_checksums'
> decode.c: In function `DecodeUDP':
> decode.c:2588: error: structure has no member named
> `log_bad_checksums'
> decode.c: In function `DecodeICMP':
> decode.c:2777: error: structure has no member named
> `log_bad_checksums'
> *** Error code 1
> 
> Tried checking decode.c at the lines mentioned, but I
> don't understand the code well enough to fix
> whatever's catching it. Any fixes?
> 
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Jazz up your holiday email with celebrity designs. Learn more. 
> http://celebrity.mail.yahoo.com
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users
-- 
Christopher Black <bla...@um...>

Re: [Snort-inline-users] IPFW FreeBSD 4.10 invisible bridge

[Christopher B. <bla...@um...>]

On Tue, 2005-01-04 at 03:16, Alex Dupre wrote:
> Nick Rogness wrote:
> >> The bridging part itself is working fine, until I divert the packets=20
> >> to snort.  The one command 'ipfw add divert 6666 all from any to any'=20
> >> (6666 being the port I put snort on) causes a complete loss of=20
> >> throughput.
>=20
> ipfw divert action (like forward and tee) cannot be used on bridged packe=
ts.
>=20
> --
> Alex Dupre

That explains a lot.  I seem to recall seeing invisible bridges running
snort_inline before, so I assume it's possible with IPTables?
--=20
Christopher Black <bla...@um...>

[Snort-inline-users] compile error with FreeBSD5.3

[Mike D. <mbd...@ya...>]

Tried compiling snort_inline-2.2.0a,
snort_inline-2.2.0, and snort_inline-2.2.0-RC1 all on
FreeBSD5.3.

I'm using ./configure --enable-ipfw and with all 3
vers of snort-inline it's freezing at the same spot
with the same error:

Making all in parser
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../src
-I../src/sfutil  -I../src/output-plugins
-I../src/detection-plugins -I../src/preprocessors
-I../src/preprocessors/flow
-I../src/preprocessors/portscan 
-I../src/preprocessors/flow/int-snort 
-I../src/preprocessors/HttpInspect/include  
-I/usr/local/include -I/usr/local/include  -g -O2
-Wall -DGIDS -DIPFW -DLIBNET_BSDISH_OS
-DLIBNET_BSD_BYTE_SWAP -DHAVE_SOCKADDR_SA_LEN
-DLIBNET_LIL_ENDIAN -c `test -f 'decode.c' || echo
'./'`decode.c
decode.c: In function `DecodeIP':
decode.c:2008: error: structure has no member named
`log_bad_checksums'
decode.c: In function `DecodeTCP':
decode.c:2395: error: structure has no member named
`log_bad_checksums'
decode.c: In function `DecodeUDP':
decode.c:2588: error: structure has no member named
`log_bad_checksums'
decode.c: In function `DecodeICMP':
decode.c:2777: error: structure has no member named
`log_bad_checksums'
*** Error code 1

Tried checking decode.c at the lines mentioned, but I
don't understand the code well enough to fix
whatever's catching it. Any fixes?



		
__________________________________ 
Do you Yahoo!? 
Jazz up your holiday email with celebrity designs. Learn more. 
http://celebrity.mail.yahoo.com

Re: [Snort-inline-users] IPFW FreeBSD 4.10 invisible bridge

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

On Mon, 3 Jan 2005, Christopher Black wrote:

> On Mon, 2005-01-03 at 14:55, Nick Rogness wrote:
>> On Mon, 3 Jan 2005, Christopher Black wrote:
>>
>>> List,
>>>
>>> I'm running freebsd 4.10 on a system configured with no IPs, briding
>>> between two interfaces.  The network works fine if diverting is
>>> disabled, but when packets are diverted to snort_inline, snort never
>>> appears to recieve them.  Has anyone seen this before?
>>
>>  	What is the output of:
>>
>>  	root# sysctl net.link.ether.bridge.ipfw
>>
>>
>> Nick Rogness <ni...@ro...>
>> -
>>    How many people here have telekenetic powers? Raise my hand.
>>    				-Emo Philips
>
> bash-2.05b# sysctl -a | grep net.link.ether.bridge
> net.link.ether.bridge_cfg: sis0,sis1
> net.link.ether.bridge: 1
> net.link.ether.bridge_ipfw: 1
> ...
>
> The bridging part itself is working fine, until I divert the packets to 
> snort.  The one command 'ipfw add divert 6666 all from any to any' (6666 
> being the port I put snort on) causes a complete loss of throughput. 
> Snort is never receiving them as debug statements in the main loop of 
> inline.c report.  Is there a special bridging (as opposed to inline) 
> mode to enable?

 	No, snort_inline is unaware of anything in the lower layers, e.g.
 	bridging vs routing.  The divert socket is just a socket, not much
 	different than a standard TCP socket.

 	I've never done briding+IPFW before on FreeBSD.  What happens if
 	you divert to say natd as a test?  Is this on FreeBSD 5.3 again?

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

Re: [Snort-inline-users] IPFW FreeBSD 4.10 invisible bridge

[Christopher B. <bla...@um...>]

On Mon, 2005-01-03 at 14:55, Nick Rogness wrote:
> On Mon, 3 Jan 2005, Christopher Black wrote:
>=20
> > List,
> >
> > I'm running freebsd 4.10 on a system configured with no IPs, briding=20
> > between two interfaces.  The network works fine if diverting is=20
> > disabled, but when packets are diverted to snort_inline, snort never=20
> > appears to recieve them.  Has anyone seen this before?
>=20
>  	What is the output of:
>=20
>  	root# sysctl net.link.ether.bridge.ipfw
>=20
>=20
> Nick Rogness <ni...@ro...>
> -
>    How many people here have telekenetic powers? Raise my hand.
>    				-Emo Philips

bash-2.05b# sysctl -a | grep net.link.ether.bridge
net.link.ether.bridge_cfg: sis0,sis1
net.link.ether.bridge: 1
net.link.ether.bridge_ipfw: 1
...

The bridging part itself is working fine, until I divert the packets to
snort.  The one command 'ipfw add divert 6666 all from any to any' (6666
being the port I put snort on) causes a complete loss of throughput.=20
Snort is never receiving them as debug statements in the main loop of
inline.c report.  Is there a special bridging (as opposed to inline)
mode to enable?

--=20
Christopher Black <bla...@um...>

Re: [Snort-inline-users] IPFW FreeBSD 4.10 invisible bridge

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

On Mon, 3 Jan 2005, Christopher Black wrote:

> List,
>
> I'm running freebsd 4.10 on a system configured with no IPs, briding 
> between two interfaces.  The network works fine if diverting is 
> disabled, but when packets are diverted to snort_inline, snort never 
> appears to recieve them.  Has anyone seen this before?

 	What is the output of:

 	root# sysctl net.link.ether.bridge.ipfw


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

[Snort-inline-users] IPFW FreeBSD 4.10 invisible bridge

[Christopher B. <bla...@um...>]

List,

I'm running freebsd 4.10 on a system configured with no IPs, briding
between two interfaces.  The network works fine if diverting is
disabled, but when packets are diverted to snort_inline, snort never
appears to recieve them.  Has anyone seen this before?

-- 
Christopher Black <bla...@um...>

RE: [Snort-inline-users] IpTables IPQ error message

[Gould, S. <sg...@go...>]

Thank you Will.  I did some more investigating with some good and bad
results.

The ip_queue_maxlen value doesn't seem to respect changes made in my
build of Red Hat Enterprise Linux.  Looks like a fix was included in
RHEL 3 Update 4 though. =20

After more digging I found some other values that I could tune that
might help, and low and behold the problem is fixed.  I'll still patch
what I have to so I can modify the ip_queue_maxlen. =20

I changed about 4 or 5 other things and when I narrow down exactly which
one or ones it was that fixed I'll post for the lists.

Thanks again for the point I the right direction.

Scott
-----Original Message-----
From: Will Metcalf [mailto:wil...@gm...]=20
Sent: Thursday, December 30, 2004 11:55 PM
To: Gould, Scott
Cc: sno...@li...
Subject: Re: [Snort-inline-users] IpTables IPQ error message

Sounds like a busy inline sensor try the following.....

echo 2048 > /proc/sys/net/ipv4/ip_queue_maxlen

Regards,

Will


On Thu, 30 Dec 2004 17:21:36 -0500, Gould, Scott <sg...@go...>
wrote:
> Anyone ever seen this:
> =20
> IpqLoop: : Failed to receive netlink message: No buffer space
available
> One of my inline sensors was spitting this out in it's process log.
> =20
> Scott
>

Re: [Snort-inline-users] Freebsd and IPFW and IP header checksums

[Christopher B. <bla...@um...>]

Nick Rogness wrote:
> On Thu, 30 Dec 2004, Christopher Black wrote:
> 
>> Well, I've included patches I've generated so far.  The snort.h patch is
>> required to compile, decode.c is required for it to not drop every
>> packet, and inline.c adds a (commented out) ugly fix for the segfault,
>> and two debug statements demonstrating the problem.  All patches were
>> created outside the top-level snort_inline-2.2.0a directory.
>>
>> A rule triggering a "reject" will segfault the program.  I have traced
>> it to inline.c, roughly line 398 (400 after my patch).  Printing the
>> value once returns the same value as printing it anywhere prior in the
>> execution chain.  Printing it again returns 0 and a segfault.  My C
>> skills aren't up to par I guess, because I'm stumped here.
> 
> 
>>
>> [root@mobilebeast1 blackchr]# gdb /usr/local/bin/snort_inline
>> snort_inline.core
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you
>> are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for
>> details.
>> This GDB was configured as "i386-marcel-freebsd"...
>> Core was generated by `snort_inline'.
>> Program terminated with signal 11, Segmentation fault.
>> Reading symbols from /usr/local/lib/libpcre.so.0...done.
>> Loaded symbols for /usr/local/lib/libpcre.so.0
>> Reading symbols from /usr/lib/libpcap.so.3...done.
>> Loaded symbols for /usr/lib/libpcap.so.3
>> Reading symbols from /lib/libm.so.3...done.
>> Loaded symbols for /lib/libm.so.3
>> Reading symbols from /lib/libc.so.5...done.
>> Loaded symbols for /lib/libc.so.5
>> Reading symbols from /libexec/ld-elf.so.1...done.
>> Loaded symbols for /libexec/ld-elf.so.1
>> #0  0x0806224d in HandlePacket () at inline.c:400
>> 400         iph->ip_src.s_addr = tmpP->iph->ip_dst.s_addr;
>> (gdb)
>>
>> Is there any more info I can provide?
> 
> 
>     - What do your ipfw rules look like?
> 
>     I'll see if I can track down this issue.  I'm amazed it even runs
>     in FreeBSD 5.X at all.  I'll have to get a FreeBSD 5.3 box up and
>     running.
> 
> Nick Rogness <ni...@ro...>
> -
>   How many people here have telekenetic powers? Raise my hand.
>                   -Emo Philips
> 

IPFW rules just forward everything to the queue:
ipfw add divert 6666 all from any to any
ipfw add allow all from any to any

It has some issues, but it runs.  One important issue is that the 
checksum calculation for the IP header fails on EVERY packet.  I have no 
idea why, so all I did was remove the InlineDrop() call when it failed 
the check.

Re: [Snort-inline-users] Freebsd and IPFW and IP header checksums

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

On Thu, 30 Dec 2004, Christopher Black wrote:

> Well, I've included patches I've generated so far.  The snort.h patch is
> required to compile, decode.c is required for it to not drop every
> packet, and inline.c adds a (commented out) ugly fix for the segfault,
> and two debug statements demonstrating the problem.  All patches were
> created outside the top-level snort_inline-2.2.0a directory.
>
> A rule triggering a "reject" will segfault the program.  I have traced
> it to inline.c, roughly line 398 (400 after my patch).  Printing the
> value once returns the same value as printing it anywhere prior in the
> execution chain.  Printing it again returns 0 and a segfault.  My C
> skills aren't up to par I guess, because I'm stumped here.

>
> [root@mobilebeast1 blackchr]# gdb /usr/local/bin/snort_inline
> snort_inline.core
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i386-marcel-freebsd"...
> Core was generated by `snort_inline'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/local/lib/libpcre.so.0...done.
> Loaded symbols for /usr/local/lib/libpcre.so.0
> Reading symbols from /usr/lib/libpcap.so.3...done.
> Loaded symbols for /usr/lib/libpcap.so.3
> Reading symbols from /lib/libm.so.3...done.
> Loaded symbols for /lib/libm.so.3
> Reading symbols from /lib/libc.so.5...done.
> Loaded symbols for /lib/libc.so.5
> Reading symbols from /libexec/ld-elf.so.1...done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0  0x0806224d in HandlePacket () at inline.c:400
> 400         iph->ip_src.s_addr = tmpP->iph->ip_dst.s_addr;
> (gdb)
>
> Is there any more info I can provide?

 	- What do your ipfw rules look like?

 	I'll see if I can track down this issue.  I'm amazed it even runs
 	in FreeBSD 5.X at all.  I'll have to get a FreeBSD 5.3 box up and
 	running.

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

Re: [Snort-inline-users] Snort-inline setup for a single computer (no-nat, no-bridge)

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

Try changing your -j ACCEPT rules to -j QUEUE the only caveot is that
snort_inline needs to see both sides of the conversation to do it's
job properly so you would need rules like the following.

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth0 -j QUEUE
iptables -A OUTPUT -i eth0 -j QUEUE

Even though you are using APF you should be able to get a list of the
current iptables rules for INPUT FORWARD and OUTPUT by doing the
following.

iptables -L

Regards,

Will

On Fri, 31 Dec 2004 10:55:19 +0100, phpMiX (snort) <sn...@ph...> wrote:
> After the latest PHP/phpBB related worms I would like to use snort-inline to
> prevent problems in the future. I believe this is a must these days. And
> snort-inline is great, for what I've been reading (a lot, I think).
> 
> I'm running RHEL 3 and I've been using APF and BFD (www.rfxnetworks.com).
> I've been also using Snort in IDS mode with ACID for some time now.
> 
> Now, I've been able to install the kernel-source package, iptables-devel,
> libnet 1.0.2a and snort 2.3.0RC2 compiled with the --enable-inline option.
> Tested and it works! However, it is still running in IDS mode.
> 
> I downloaded the rc.firewall script from honeynet.org and I've been trying
> to understand how do I need to change it to suit my needs. I do not need to
> do NAT nor act as Bridge. My computer is connected to just one interface
> (eth0), the net. Also, I still need to use APF, since it's easier to
> customize than iptables. TBH, I feel somehow lost when trying to figure out
> iptables seriously.
> 
> Probably I need to setup the ip_queue chains to allow snort-inline do its
> own job, but I also need to keep all the iptable settings APF builds when
> it's started. ...or maybe I can't use APF+BFD anymore when using
> snort-inline?
> 
> Please, can anyone help me?
> 
> Thanks a lot in advance ...and happy new year! :-)
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users
>

[Snort-inline-users] Snort-inline setup for a single computer (no-nat, no-bridge)

[phpMiX \(snort\) <sn...@ph...>]

After the latest PHP/phpBB related worms I would like to use snort-inline to
prevent problems in the future. I believe this is a must these days. And
snort-inline is great, for what I've been reading (a lot, I think).

I'm running RHEL 3 and I've been using APF and BFD (www.rfxnetworks.com).
I've been also using Snort in IDS mode with ACID for some time now.

Now, I've been able to install the kernel-source package, iptables-devel,
libnet 1.0.2a and snort 2.3.0RC2 compiled with the --enable-inline option.
Tested and it works! However, it is still running in IDS mode.

I downloaded the rc.firewall script from honeynet.org and I've been trying
to understand how do I need to change it to suit my needs. I do not need to
do NAT nor act as Bridge. My computer is connected to just one interface
(eth0), the net. Also, I still need to use APF, since it's easier to
customize than iptables. TBH, I feel somehow lost when trying to figure out
iptables seriously.

Probably I need to setup the ip_queue chains to allow snort-inline do its
own job, but I also need to keep all the iptable settings APF builds when
it's started. ...or maybe I can't use APF+BFD anymore when using
snort-inline?

Please, can anyone help me?

Thanks a lot in advance ...and happy new year! :-)

Re: [Snort-inline-users] IpTables IPQ error message

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

Sounds like a busy inline sensor try the following.....

echo 2048 > /proc/sys/net/ipv4/ip_queue_maxlen

Regards,

Will


On Thu, 30 Dec 2004 17:21:36 -0500, Gould, Scott <sg...@go...> wrote:
> Anyone ever seen this:
>  
> IpqLoop: : Failed to receive netlink message: No buffer space available
> One of my inline sensors was spitting this out in it's process log.
>  
> Scott
>

[Snort-inline-users] IpTables IPQ error message

[Gould, S. <sg...@go...>]

Anyone ever seen this:
=20
IpqLoop: : Failed to receive netlink message: No buffer space available

One of my inline sensors was spitting this out in it's process log.
<mailto:sno...@li...>=20
=20
Scott
=20

[Snort-inline-users] ClamAV patch against 2.3.0RC2

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

I have created a diff for the clamav preproc against 2.3.0RC2.  The
only new feature Victor Julien and I added was a dbreload-time as an
argument to clamav via snort.conf.  This way we don't have to sighup
snort if we update the clamav viri database.  We also made a small 
change to configure.in to deal with the 0.80 api. You may have to run
autoreconf -f to get configure to pickup the changes made to
configure.in

From snort.conf......

# ClamAV virusscanning preprocessor   
# 
# This preprocessor will scan the data in the packets for virusses.
# See README.clamav for details and limitations.
#
# Available options (comma delimited):              
# 
#   ports: a space delimited list of ports that will be scanned.
#     all: all ports
#     n  : single port to be scanned
#     !n : not scan port n (to be used with 'all'   
#
#   toclientonly: scan only the traffic to the client (tcp only)
#   toserveronly: scan only the traffic to the server (tcp only)
#
#   action-drop : drop the infected packet (snort_inline only)
#   action-reset: reset the connection (snort_inline only)
# 
#   dbdir: path to the clamav definitions directory.
#
#   dbreload-time: Amount of time in seconds to wait before checking
the db for new virus sigs
# 
# Example:
# preprocessor clamav: ports all !22 !443, toclientonly, dbdir
/usr/share/clamav, dbreload-time 43200
# 

Download:

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

MD5SUM:

8c61230c12469ddf0d2cc6422d912e56

Regards,

Will

Re: [Snort-inline-users] Freebsd and IPFW and IP header checksums

[Christopher B. <bla...@um...>]

Well, I've included patches I've generated so far.  The snort.h patch is
required to compile, decode.c is required for it to not drop every
packet, and inline.c adds a (commented out) ugly fix for the segfault,
and two debug statements demonstrating the problem.  All patches were
created outside the top-level snort_inline-2.2.0a directory.

A rule triggering a "reject" will segfault the program.  I have traced
it to inline.c, roughly line 398 (400 after my patch).  Printing the
value once returns the same value as printing it anywhere prior in the
execution chain.  Printing it again returns 0 and a segfault.  My C
skills aren't up to par I guess, because I'm stumped here.

[root@mobilebeast1 blackchr]# gdb /usr/local/bin/snort_inline
snort_inline.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `snort_inline'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libpcre.so.0...done.
Loaded symbols for /usr/local/lib/libpcre.so.0
Reading symbols from /usr/lib/libpcap.so.3...done.
Loaded symbols for /usr/lib/libpcap.so.3
Reading symbols from /lib/libm.so.3...done.
Loaded symbols for /lib/libm.so.3
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0806224d in HandlePacket () at inline.c:400
400         iph->ip_src.s_addr = tmpP->iph->ip_dst.s_addr;
(gdb)

Is there any more info I can provide?

On Thu, 2004-12-30 at 09:00, William Metcalf wrote:
> We always welcome patches, send me a diff I'll look it over and if
> everything is cool I'll include it in 2.3.0.
> 
> Regards,
> 
> Will
> Inactive hide details for Christopher Black
> <bla...@um...>Christopher Black <bla...@um...>
> 
> 
>                                 Christopher Black <bla...@um...>
>                                 Sent by: sno...@li...
>                                 
>                                 12/30/2004 07:53 AM
>                         
>                 
>         
> 
>                To
> 
> sno...@li...
> 
>                cc
> 
> 
>           Subject
> 
> Re:
> [Snort-inline-users] Freebsd and IPFW and IP header checksums
> 
> 
> Ahhh, what a way to join the list.  I am using snort_inline 2.2.0a,
> and
> the information below is still accurate.  However, I didn't realize
> the
> test.rules set was modifying both DNS and ICMP packets.  Commenting
> out
> those rules, snort_inline is working just as it should.
> 
> Would it be useful to produce diff patches for my changes for
> snort_inline 2.2.0a on FreeBSD 5.3?
> 
> On Thu, 2004-12-30 at 08:38, Christopher Black wrote:
> > Hello list,
> > 
> > I am using snort_inline on FreeBSD 5.3 with IPFW, and after fixing
> the
> > following (line 184 used to be in the ndef block) in snort.h:
> > 
> >     179 #ifndef IPFW
> >     180     char layer2_resets;
> >     181     u_char enet_src[6];
> >     182 #endif
> >     183 #ifdef IPFW
> >     184     char log_bad_checksums;
> >     185     int divert_port;
> >     186 #endif /* USE IPFW DIVERT socket instead of IPtables */
> > 
> > It will compile, but drops every packet.  I traced that back to
> checking
> > the IP header checksum, and based on the comment leading that block
> > (that the check is mostly unneeded), I just commented out the line
> to
> > call InlineDrop().  Now it's not dropping the packet there, but
> still
> > seems to be dropping it somewhere.
> > 
> > Has anyone else run into and/or fixed this?  I will continue
> hunting,
> > but look forward to your input!
> -- 
> Christopher Black <bla...@um...>
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Snort-inline-users mailing list
> Sno...@li...
> https://lists.sourceforge.net/lists/listinfo/snort-inline-users
-- 
Christopher Black <bla...@um...>

Re: [Snort-inline-users] Freebsd and IPFW and IP header checksums

[Christopher B. <bla...@um...>]

Ahhh, what a way to join the list.  I am using snort_inline 2.2.0a, and
the information below is still accurate.  However, I didn't realize the
test.rules set was modifying both DNS and ICMP packets.  Commenting out
those rules, snort_inline is working just as it should.

Would it be useful to produce diff patches for my changes for
snort_inline 2.2.0a on FreeBSD 5.3?

On Thu, 2004-12-30 at 08:38, Christopher Black wrote:
> Hello list,
> 
> I am using snort_inline on FreeBSD 5.3 with IPFW, and after fixing the
> following (line 184 used to be in the ndef block) in snort.h:
> 
>     179 #ifndef IPFW
>     180     char layer2_resets;
>     181     u_char enet_src[6];
>     182 #endif
>     183 #ifdef IPFW
>     184     char log_bad_checksums;
>     185     int divert_port;
>     186 #endif /* USE IPFW DIVERT socket instead of IPtables */
> 
> It will compile, but drops every packet.  I traced that back to checking
> the IP header checksum, and based on the comment leading that block
> (that the check is mostly unneeded), I just commented out the line to
> call InlineDrop().  Now it's not dropping the packet there, but still
> seems to be dropping it somewhere.
> 
> Has anyone else run into and/or fixed this?  I will continue hunting,
> but look forward to your input!
-- 
Christopher Black <bla...@um...>

[Snort-inline-users] Freebsd and IPFW and IP header checksums

[Christopher B. <bla...@um...>]

Hello list,

I am using snort_inline on FreeBSD 5.3 with IPFW, and after fixing the
following (line 184 used to be in the ndef block) in snort.h:

    179 #ifndef IPFW
    180     char layer2_resets;
    181     u_char enet_src[6];
    182 #endif
    183 #ifdef IPFW
    184     char log_bad_checksums;
    185     int divert_port;
    186 #endif /* USE IPFW DIVERT socket instead of IPtables */

It will compile, but drops every packet.  I traced that back to checking
the IP header checksum, and based on the comment leading that block
(that the check is mostly unneeded), I just commented out the line to
call InlineDrop().  Now it's not dropping the packet there, but still
seems to be dropping it somewhere.

Has anyone else run into and/or fixed this?  I will continue hunting,
but look forward to your input!
-- 
Christopher Black <bla...@um...>

Re: [Snort-inline-users] snort with snort_inline and clamav

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

On Wed, 29 Dec 2004, Will Metcalf wrote:

>> With snort 2.3RC2, I thought it had the snort_inline code rolled in. 
>> Therefore I would assume clamav support. However, no matter what I can 
>> get it to build with clamav. On the same system, snort_inline 2.2.0a 
>> builds with clamav and works flawlessly.
>
> They decided they didn't want the clamav stuff in normal snort.  I'll 
> release a patch this weekend for clamav only against 2.3.0.  As soon as 
> Victor and I can find enough time finish up snort_inline-2.3.0 we will 
> release it with clamav+stickydrop+stream4inline.  Unfortunately Victor 
> and I both have full-time jobs and while we would like to work on 
> snort_inline all the time we there just aren't enough hours in a day.


 	I should have some pretty good documentation for
 	FreeBSD+snort_inline ready at some point here in the near future.
 	What format should I be creating these documents in?

 	Last I checked the code still works, but probably won't work on
 	the FreeBSD 5.X branch.  I'll try to get a patch ready for that
 	too.

 	I would also like to submit the snort_inline code to the FreeBSD
 	Ports Collection.  There already exists a snort port, but I would
 	like to get snort_inline split out of the main snort FreeBSD port.
 	Of course, I need your permission for such a thing.


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