Menu
▾
▴
snort-inline-users — The goal of this list is to help users debug/use snort_inline
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(15) |
Jun
(23) |
Jul
(54) |
Aug
(20) |
Sep
(18) |
Oct
(19) |
Nov
(36) |
Dec
(30) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(48) |
Feb
(16) |
Mar
(36) |
Apr
(36) |
May
(45) |
Jun
(47) |
Jul
(93) |
Aug
(29) |
Sep
(28) |
Oct
(42) |
Nov
(45) |
Dec
(53) |
| 2005 |
Jan
(62) |
Feb
(51) |
Mar
(65) |
Apr
(28) |
May
(57) |
Jun
(23) |
Jul
(24) |
Aug
(72) |
Sep
(16) |
Oct
(53) |
Nov
(53) |
Dec
(3) |
| 2006 |
Jan
(56) |
Feb
(6) |
Mar
(15) |
Apr
(14) |
May
(35) |
Jun
(57) |
Jul
(35) |
Aug
(7) |
Sep
(22) |
Oct
(16) |
Nov
(18) |
Dec
(9) |
| 2007 |
Jan
(8) |
Feb
(3) |
Mar
(11) |
Apr
(35) |
May
(6) |
Jun
(10) |
Jul
(26) |
Aug
(4) |
Sep
|
Oct
(29) |
Nov
|
Dec
(7) |
| 2008 |
Jan
(1) |
Feb
(2) |
Mar
(2) |
Apr
(13) |
May
(8) |
Jun
(3) |
Jul
(19) |
Aug
(20) |
Sep
(6) |
Oct
(5) |
Nov
|
Dec
(4) |
| 2009 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(10) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
|
Dec
(5) |
| 2010 |
Jan
(10) |
Feb
(10) |
Mar
(2) |
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Murugavel T. <tmu...@gm...> - 2005-01-18 05:56:03
|
hi Will As you said both the instance will get traffic right. I can specify the segment in snort.conf file to process only specified traffic . Any suggestion welcome. Regards T.Murugavelu On Mon, 17 Jan 2005 10:02:05 -0600, Will Metcalf <wil...@gm...> wrote: > > We've seen on our firewall, that in bridging mode if stream4 preprocessor is > > enabled, when we ssh from outside network to internal network, packets are > > lost and ssh never connects. Disabling stream4 preprocessor fixed the > > problem. > > This true only if you are using 2.2.0 and you have not configured > state tracking via iptables marks. It doesn't matter if you are in > bridging mode or not. The other solution is to up the timeout in > stream4. > > What Murugavel is suggesting is that he run multiple instances of > snort_inline to save resources. This will not work, one reason being > is that only one process is allowed to hook into ip_queue. The second > reason being, is that even if you were allowed to hook another > snort_inline process into ip_queue both of your instances of > snort_inline would be seeing the exact same traffic. > > Regards, > > Will > > Regards, > > Will > > > On Mon, 17 Jan 2005 00:54:57 -0600, Pawel Czarnota <pc...@ui...> wrote: > > We've seen on our firewall, that in bridging mode if stream4 preprocessor is > > enabled, when we ssh from outside network to internal network, packets are > > lost and ssh never connects. Disabling stream4 preprocessor fixed the > > problem. > > > > Pawel Czarnota > > BIS Network Support Graduate Assistant > > Office of Business and Financial Services > > pc...@ui... > > ACM SIGSAC Leader > > http://cs.uic.edu/~pczarno1 > > University of Illinois at Chicago > > ----- Original Message ----- > > From: William Metcalf > > To: Murugavel Thiruvengadam > > Cc: sno...@li... > > Sent: Monday, January 10, 2005 10:51 AM > > Subject: Re: [Snort-inline-users] snort-inline Packet Drops!!! > > > > > > > > You could try to set ip_queue_maxlen 2048, what NICs do you have in the > > server? > > > > Regards, > > > > Will > > Murugavel Thiruvengadam <tmu...@gm...> > > > > > > Murugavel Thiruvengadam <tmu...@gm...> > > Sent by: sno...@li... > > > > 01/10/2005 09:50 AM > > Please respond to > > Murugavel Thiruvengadam <tmu...@gm...> > > > > To > > sno...@li... > > > > cc > > > > Subject > > [Snort-inline-users] snort-inline Packet Drops!!! > > > > Hi > > > > We have implemented snort-inline 2.2.0 in our place. > > > > Kernel version 2.4.18-3 > > > > Aprox. 53Mbps of Traffic flowing thro that box . it is connected via > > fibre cable. > > > > suddenly it we are getting packet drop and latency in other two side. > > > > if we flush the iptables rules . I meant by pass the snort-inline .. > > we are not getting any errors. > > > > Even We removed all snort ruels also we are getting the same problem. > > > > right now the ip_queue_maxlen 1024 > > > > ip_conntrack_max 1410065407 > > > > > > Any suggestion welcome. > > > > We have dual Xeon processor with 1gb ram. > > > > I have checked the load also it is .50 only. > > > > > > There is no error in messages > > > > is it possible to split traffic into multiple instances of snort-inline? > > > > will it work any suggestion welcome > > > > > > Regards > > velu > > > > > > ------------------------------------------------------- > > 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 > > > > > -- Regards Muruga>>----le> "Success comes to the person who does today" |
|
From: Will M. <wil...@gm...> - 2005-01-17 17:32:09
|
The answer is yes. The way that state protection is implemented is a little different in 2.2.0a than in 2.3.0. Which version are you using? Regards, Will On Mon, 17 Jan 2005 12:28:53 -0500, Adayadil Thomas <ada...@gm...> wrote: > Hi all, > > I have a question regarding snort inline project -- > > Does the snort inline have stream4 working ? I checked the > snort_inline.conf and saw that > stream4 preprocessor line was uncommented. > > Thanks a lot for your time > > ------------------------------------------------------- > 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 > |
|
From: Adayadil T. <ada...@gm...> - 2005-01-17 17:28:56
|
Hi all, I have a question regarding snort inline project -- Does the snort inline have stream4 working ? I checked the snort_inline.conf and saw that stream4 preprocessor line was uncommented. Thanks a lot for your time |
|
From: Will M. <wil...@gm...> - 2005-01-17 16:42:10
|
Yeah, its just a source forge cvs server so.... http://sourceforge.net/cvs/?group_id=78497 cvs -d:pserver:ano...@cv...:/cvsroot/snort-inline login cvs -z3 -d:pserver:ano...@cv...:/cvsroot/snort-inline co -P modulename On Mon, 17 Jan 2005 09:15:41 -0700 (MST), Nick Rogness <ni...@ro...> wrote: > On Mon, 17 Jan 2005, Will Metcalf wrote: > > > I'll update CVS later today. Resets are always sent to the source of > > the attack. > > What is the cvs server? Is it an annon server or ? > > > > > > Regards, > > > > Will > > > > > > On Sun, 16 Jan 2005 21:32:54 -0700 (MST), Nick Rogness <ni...@ro...> 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? > >>> > >> > >> I found the bug in the code. Is there a cvs tree I can checkout > >> so I can send diffs against your current snapshot? > >> > >> Also, has anyone checked to see if the TCP reset (RejectSocket) > >> code actually sends TCP resets? Which direction and to whom are > >> they suppose to be sent? > >> > >> > >> Nick Rogness <ni...@ro...> > >> - > >> How many people here have telekenetic powers? Raise my hand. > >> -Emo Philips > >> > >> ------------------------------------------------------- > >> 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 > >> > > > > Nick Rogness <ni...@ro...> > - > How many people here have telekenetic powers? Raise my hand. > -Emo Philips > > |
|
From: Nick R. <ni...@ro...> - 2005-01-17 16:19:16
|
On Mon, 17 Jan 2005, Will Metcalf wrote: > I'll update CVS later today. Resets are always sent to the source of > the attack. What is the cvs server? Is it an annon server or ? > > Regards, > > Will > > > On Sun, 16 Jan 2005 21:32:54 -0700 (MST), Nick Rogness <ni...@ro...> 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? >>> >> >> I found the bug in the code. Is there a cvs tree I can checkout >> so I can send diffs against your current snapshot? >> >> Also, has anyone checked to see if the TCP reset (RejectSocket) >> code actually sends TCP resets? Which direction and to whom are >> they suppose to be sent? >> >> >> Nick Rogness <ni...@ro...> >> - >> How many people here have telekenetic powers? Raise my hand. >> -Emo Philips >> >> ------------------------------------------------------- >> 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 >> > Nick Rogness <ni...@ro...> - How many people here have telekenetic powers? Raise my hand. -Emo Philips |
|
From: Will M. <wil...@gm...> - 2005-01-17 16:04:40
|
I'll update CVS later today. Resets are always sent to the source of the attack. Regards, Will On Sun, 16 Jan 2005 21:32:54 -0700 (MST), Nick Rogness <ni...@ro...> 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? > > > > I found the bug in the code. Is there a cvs tree I can checkout > so I can send diffs against your current snapshot? > > Also, has anyone checked to see if the TCP reset (RejectSocket) > code actually sends TCP resets? Which direction and to whom are > they suppose to be sent? > > > Nick Rogness <ni...@ro...> > - > How many people here have telekenetic powers? Raise my hand. > -Emo Philips > > ------------------------------------------------------- > 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 > |
|
From: Will M. <wil...@gm...> - 2005-01-17 16:02:13
|
> We've seen on our firewall, that in bridging mode if stream4 preprocessor is > enabled, when we ssh from outside network to internal network, packets are > lost and ssh never connects. Disabling stream4 preprocessor fixed the > problem. This true only if you are using 2.2.0 and you have not configured state tracking via iptables marks. It doesn't matter if you are in bridging mode or not. The other solution is to up the timeout in stream4. What Murugavel is suggesting is that he run multiple instances of snort_inline to save resources. This will not work, one reason being is that only one process is allowed to hook into ip_queue. The second reason being, is that even if you were allowed to hook another snort_inline process into ip_queue both of your instances of snort_inline would be seeing the exact same traffic. Regards, Will Regards, Will On Mon, 17 Jan 2005 00:54:57 -0600, Pawel Czarnota <pc...@ui...> wrote: > We've seen on our firewall, that in bridging mode if stream4 preprocessor is > enabled, when we ssh from outside network to internal network, packets are > lost and ssh never connects. Disabling stream4 preprocessor fixed the > problem. > > Pawel Czarnota > BIS Network Support Graduate Assistant > Office of Business and Financial Services > pc...@ui... > ACM SIGSAC Leader > http://cs.uic.edu/~pczarno1 > University of Illinois at Chicago > ----- Original Message ----- > From: William Metcalf > To: Murugavel Thiruvengadam > Cc: sno...@li... > Sent: Monday, January 10, 2005 10:51 AM > Subject: Re: [Snort-inline-users] snort-inline Packet Drops!!! > > > > You could try to set ip_queue_maxlen 2048, what NICs do you have in the > server? > > Regards, > > Will > Murugavel Thiruvengadam <tmu...@gm...> > > > Murugavel Thiruvengadam <tmu...@gm...> > Sent by: sno...@li... > > 01/10/2005 09:50 AM > Please respond to > Murugavel Thiruvengadam <tmu...@gm...> > > To > sno...@li... > > cc > > Subject > [Snort-inline-users] snort-inline Packet Drops!!! > > Hi > > We have implemented snort-inline 2.2.0 in our place. > > Kernel version 2.4.18-3 > > Aprox. 53Mbps of Traffic flowing thro that box . it is connected via > fibre cable. > > suddenly it we are getting packet drop and latency in other two side. > > if we flush the iptables rules . I meant by pass the snort-inline .. > we are not getting any errors. > > Even We removed all snort ruels also we are getting the same problem. > > right now the ip_queue_maxlen 1024 > > ip_conntrack_max 1410065407 > > > Any suggestion welcome. > > We have dual Xeon processor with 1gb ram. > > I have checked the load also it is .50 only. > > > There is no error in messages > > is it possible to split traffic into multiple instances of snort-inline? > > will it work any suggestion welcome > > > Regards > velu > > > ------------------------------------------------------- > 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 > > |
|
From: Nick R. <ni...@ro...> - 2005-01-17 04:36:41
|
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? > I found the bug in the code. Is there a cvs tree I can checkout so I can send diffs against your current snapshot? Also, has anyone checked to see if the TCP reset (RejectSocket) code actually sends TCP resets? Which direction and to whom are they suppose to be sent? Nick Rogness <ni...@ro...> - How many people here have telekenetic powers? Raise my hand. -Emo Philips |
|
From: Miguel A. <mar...@gm...> - 2005-01-12 14:53:23
|
Hi, i need to write a rule to replace a character to another. i have this.. alert tcp any 1863 -> any any (msg:"aviso"); flow:established; content:"CAL"; depth:4; replace "XX2"; ..... this rule works fine, but, now i need a rule like: if found "CAL" replace the characters at the position 14 of the packet by "john" My problem is to replace on another position, not the characters where the condition was found. I hope you can understand my english. thanks. Miguel Arrighi |
|
From: Murugavel T. <tmu...@gm...> - 2005-01-12 06:50:21
|
HI We are trying to run multiple instances . internet ----- snort-inline---- Internal Network Snort-inline box has 2 fibre card which is running in bridge mode. Our objective is to make use of other CPUs and increase the performance. 2 insatnce running with different network segment. We are not getting any error message like 16. Any suggestion welcome. Regards velu On Tue, 11 Jan 2005 10:21:41 -0600, William Metcalf <Wil...@kc...> wrote: > > > Multiple interface should be OK, i.e. multiple bridges, because even if you > are Queueing from multiple interfaces, all of the traffic is going to the > same QUEUE target in iptables. He was talking about running multiple > instances of snort_inline trying to hook into the ip_queue module which will > not work. If you start up multiple instances of snort_inline you will > receive an error message 16 indicating that another application already has > control of the QUEUE. > > Regards, > > Will > Jason <sec...@br...> > > > > Jason <sec...@br...> > > 01/11/2005 02:01 AM > > > To > William Metcalf <Wil...@kc...> > > > cc > Murugavel Thiruvengadam <tmu...@gm...>, "Dale L. Handy P.E." > <dh...@ni...>, sno...@li..., > sno...@li... > > > Subject > Re: [Snort-inline-users] snort-inline Packet Drops!!! > > Do you know if any testing has been done with multiple interfaces? I > would think that the bridging code would handle sending the packet out > the correct interface after snort-inline has decided it is ok and puts > it back into the queue. > > ?? > > William Metcalf wrote: > > You cannot run multiple instances of snort-inline, only one instance is > > allowed to hook into ip_queue. > > > > Regards, > > > > Will > > -- Regards Muruga>>----le> "Success comes to the person who does today" |
|
From: Jason <sec...@br...> - 2005-01-11 08:02:06
|
Do you know if any testing has been done with multiple interfaces? I would think that the bridging code would handle sending the packet out the correct interface after snort-inline has decided it is ok and puts it back into the queue. ?? William Metcalf wrote: > You cannot run multiple instances of snort-inline, only one instance is > allowed to hook into ip_queue. > > Regards, > > Will |
|
From: Murugavel T. <tmu...@gm...> - 2005-01-11 06:45:14
|
Hi I have Intel NAC 7771F Firbre Card, Rules Used iptables -A -t mangle FORWARD -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m state --state NEW -j MARK --set-mark 0x1 iptables -A -t mangle FORWARD -p tcp -m state --state ESTABLISHED -j MARK --set-mark 0x2 iptables -A FORWARD -j QUEUE What about multiple instance? Anybody tried snort-inline with multiple instances. Previouse we used NAt table thats why we incresed the ip_conntrack_max Regards murugavel On Mon, 10 Jan 2005 13:13:34 -0700, Dale L. Handy P.E. <dh...@ni...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Is there a reason you set "ip_conntrack_max 1410065407"? That has the > potential to use 3+ GB of RAM! > > Murugavel Thiruvengadam wrote: > | Hi > | > | We have implemented snort-inline 2.2.0 in our place. > | > | Kernel version 2.4.18-3 > | > | Aprox. 53Mbps of Traffic flowing thro that box . it is connected via > | fibre cable. > | > | suddenly it we are getting packet drop and latency in other two side. > | > | if we flush the iptables rules . I meant by pass the snort-inline .. > | we are not getting any errors. > | > | Even We removed all snort ruels also we are getting the same problem. > | > | right now the ip_queue_maxlen 1024 > | > | ip_conntrack_max 1410065407 > | > | > | Any suggestion welcome. > | > | We have dual Xeon processor with 1gb ram. > | > | I have checked the load also it is .50 only. > | > | > | There is no error in messages > | > | is it possible to split traffic into multiple instances of snort-inline? > | > | will it work any suggestion welcome > | > | > | Regards > | velu > | > | > | ------------------------------------------------------- > | 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 > | > | > > - -- > "The trouble with doing something right the first time > ~ is that nobody appreciates how difficult it was." > > - -- Dale L. Handy, P.E. > ~ dh...@ni... > ~ http://www.nitrosecuity.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFB4uHuJkJUIoExvsURAp6xAJ0ffNE4vGSRJa/ulhO/Z4N3FBC4pQCdF4Ig > 3bQobfSF2vip1km5wbUoWTQ= > =hhsv > -----END PGP SIGNATURE----- > > -- Regards Muruga>>----le> "Success comes to the person who does today" |
|
From: Esler, J. - C. <joe...@rc...> - 2005-01-10 18:41:49
|
Bien, ask a Snort question. -----Original Message----- From: sno...@li... = [mailto:sno...@li...] On Behalf Of = jose Manuel A.V. Sent: Monday, January 10, 2005 12:27 PM To: sno...@li... Subject: [Snort-inline-users] hola hola como estan _________________________________________________________________ MSN Amor: busca tu =BD naranja http://latam.msn.com/amor/ ------------------------------------------------------- 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 |
|
From: jose M. A.V. <jos...@ho...> - 2005-01-10 17:28:18
|
hola como estan _________________________________________________________________ MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/ |
|
From: Murugavel T. <tmu...@gm...> - 2005-01-10 15:50:18
|
Hi We have implemented snort-inline 2.2.0 in our place. Kernel version 2.4.18-3 Aprox. 53Mbps of Traffic flowing thro that box . it is connected via fibre cable. suddenly it we are getting packet drop and latency in other two side. if we flush the iptables rules . I meant by pass the snort-inline .. we are not getting any errors. Even We removed all snort ruels also we are getting the same problem. right now the ip_queue_maxlen 1024 ip_conntrack_max 1410065407 Any suggestion welcome. We have dual Xeon processor with 1gb ram. I have checked the load also it is .50 only. There is no error in messages is it possible to split traffic into multiple instances of snort-inline? will it work any suggestion welcome Regards velu |
|
From: Chris <lis...@fr...> - 2005-01-10 09:54:38
|
Hello, I am getting an error compiling arpd on Fedora Core 2. After "make" I get the following error. I appreciate any help. gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/local/include -I/usr/local/include -I/usr/local/include -c arpd.c arpd.c: In function `arpd_send': arpd.c:268: warning: concatenation of string literals with __FUNCTION__ is deprecated arpd.c: In function `arpd_lookup': arpd.c:285: warning: concatenation of string literals with __FUNCTION__ is deprecated arpd.c:294: warning: concatenation of string literals with __FUNCTION__ is deprecated arpd.c:297: warning: concatenation of string literals with __FUNCTION__ is deprecated arpd.c: In function `arpd_recv_cb': arpd.c:426: warning: concatenation of string literals with __FUNCTION__ is deprecated gcc -I/usr/local/include -o arpd arpd.o -L/usr/local/lib -ldnet -L/usr/local/lib -levent -lpcap -L/usr/local/lib -ldnet arpd.o(.text+0x135a): In function `terminate_handler': : undefined reference to `event_gotsig' arpd.o(.text+0x15b3): In function `main': : undefined reference to `event_sigcb' collect2: ld returned 1 exit status make: *** [arpd] Error 1 -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
|
From: Victor J. <vi...@nk...> - 2005-01-10 09:27:24
|
Hi Thanasin, The clamav preprocessor might be a bottleneck. Can you try to disable it and see if the throughput increases? I believe the Clamav-scanning is very cpu-intensive... Regards, Victor > i've use MRTG to graph my network traffic and the snmp show my bridge > interface's speed only 10 Mbps while my NICs are 100 Mbps. > > Is this the real speed that i should get ? > That's why i'm not sure that it will cause bottle neck problem or not. > > Regard, > Thanasin Jitkaew > >>>Running snort-inline with bridge mode will drop my traffic from 100 to >>>10Mbps ? >> >> latency is directly relational to the speed of your hardware and the >> amount of network traffic passing through the inline box. So, the >> answer to your question is that it depends. Passing through ip_queue >> will not automatically drop your connection to 10mbs. >> >> Regards, >> >> Will >> >> On Sun, 9 Jan 2005 23:28:51 +0700 (ICT), tha...@gb... >> <tha...@gb...> wrote: >>> i have installed snort-inline with clamav support to protect my network >>> from anomally things and it's work terrific for me :) >>> >>> the computer that i installed snort-inline is running in bridge mode. >>> >>> i've a question about running in bridge mode. >>> >>> Running snort-inline with bridge mode will drop my traffic from 100 to >>> 10Mbps ? >>> >>> if the answer is "yes". What should i do to prevent bottle neck problem >>> that will happen ? >>> >>> Thank you in advance. >>> >>> Thanasin Jitkaew >>> >>> ------------------------------------------------------- >>> 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 >>> >> >> >> ------------------------------------------------------- >> 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 >> > > > > > ------------------------------------------------------- > 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 > |
|
From: Nick R. <ni...@ro...> - 2005-01-10 07:08:41
|
On Tue, 4 Jan 2005, Christopher Black wrote: >> 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...> > > 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? For simply printing packets received by a divert socket, a simple C userland program: http://freebsd.rogness.net/tools/ipprint/ipprint.c Nick Rogness <ni...@ro...> - How many people here have telekenetic powers? Raise my hand. -Emo Philips |
|
From: Will M. <wil...@gm...> - 2005-01-10 04:52:32
|
No that isn't the speed you should be getting, you should be able to operate at 10 or 100 mb depending on what your network supports. Regards, Will On Mon, 10 Jan 2005 09:47:37 +0700 (ICT), tha...@gb... <tha...@gb...> wrote: > i've use MRTG to graph my network traffic and the snmp show my bridge > interface's speed only 10 Mbps while my NICs are 100 Mbps. > > Is this the real speed that i should get ? > That's why i'm not sure that it will cause bottle neck problem or not. > > Regard, > Thanasin Jitkaew > > >>Running snort-inline with bridge mode will drop my traffic from 100 to > >>10Mbps ? > > > > latency is directly relational to the speed of your hardware and the > > amount of network traffic passing through the inline box. So, the > > answer to your question is that it depends. Passing through ip_queue > > will not automatically drop your connection to 10mbs. > > > > Regards, > > > > Will > > > > On Sun, 9 Jan 2005 23:28:51 +0700 (ICT), tha...@gb... > > <tha...@gb...> wrote: > >> i have installed snort-inline with clamav support to protect my network > >> from anomally things and it's work terrific for me :) > >> > >> the computer that i installed snort-inline is running in bridge mode. > >> > >> i've a question about running in bridge mode. > >> > >> Running snort-inline with bridge mode will drop my traffic from 100 to > >> 10Mbps ? > >> > >> if the answer is "yes". What should i do to prevent bottle neck problem > >> that will happen ? > >> > >> Thank you in advance. > >> > >> Thanasin Jitkaew > >> > >> ------------------------------------------------------- > >> 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 > >> > > > > > > ------------------------------------------------------- > > 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 > > > > > ------------------------------------------------------- > 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 > |
|
From: <tha...@gb...> - 2005-01-10 02:56:00
|
i've use MRTG to graph my network traffic and the snmp show my bridge interface's speed only 10 Mbps while my NICs are 100 Mbps. Is this the real speed that i should get ? That's why i'm not sure that it will cause bottle neck problem or not. Regard, Thanasin Jitkaew >>Running snort-inline with bridge mode will drop my traffic from 100 to >>10Mbps ? > > latency is directly relational to the speed of your hardware and the > amount of network traffic passing through the inline box. So, the > answer to your question is that it depends. Passing through ip_queue > will not automatically drop your connection to 10mbs. > > Regards, > > Will > > On Sun, 9 Jan 2005 23:28:51 +0700 (ICT), tha...@gb... > <tha...@gb...> wrote: >> i have installed snort-inline with clamav support to protect my network >> from anomally things and it's work terrific for me :) >> >> the computer that i installed snort-inline is running in bridge mode. >> >> i've a question about running in bridge mode. >> >> Running snort-inline with bridge mode will drop my traffic from 100 to >> 10Mbps ? >> >> if the answer is "yes". What should i do to prevent bottle neck problem >> that will happen ? >> >> Thank you in advance. >> >> Thanasin Jitkaew >> >> ------------------------------------------------------- >> 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 >> > > > ------------------------------------------------------- > 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 > |
|
From: Will M. <wil...@gm...> - 2005-01-09 18:16:54
|
>Running snort-inline with bridge mode will drop my traffic from 100 to >10Mbps ? latency is directly relational to the speed of your hardware and the amount of network traffic passing through the inline box. So, the answer to your question is that it depends. Passing through ip_queue will not automatically drop your connection to 10mbs. Regards, Will On Sun, 9 Jan 2005 23:28:51 +0700 (ICT), tha...@gb... <tha...@gb...> wrote: > i have installed snort-inline with clamav support to protect my network > from anomally things and it's work terrific for me :) > > the computer that i installed snort-inline is running in bridge mode. > > i've a question about running in bridge mode. > > Running snort-inline with bridge mode will drop my traffic from 100 to > 10Mbps ? > > if the answer is "yes". What should i do to prevent bottle neck problem > that will happen ? > > Thank you in advance. > > Thanasin Jitkaew > > ------------------------------------------------------- > 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 > |
|
From: <tha...@gb...> - 2005-01-09 16:37:15
|
i have installed snort-inline with clamav support to protect my network from anomally things and it's work terrific for me :) the computer that i installed snort-inline is running in bridge mode. i've a question about running in bridge mode. Running snort-inline with bridge mode will drop my traffic from 100 to 10Mbps ? if the answer is "yes". What should i do to prevent bottle neck problem that will happen ? Thank you in advance. Thanasin Jitkaew |
|
From: mdpeters <mic...@la...> - 2005-01-06 12:21:56
|
Is there a solid way to determine if a transparent bridge is working? It =
seems as though one could just sniff traffic on one side of the bridge =
while injecting on the other side. I can see traffic entering the =
Snort-inline box but it never get through. How can I verify it works or =
should I pose that question to another group?
On the Snort-inline side, I can get the rules to log all traffic using =
this:
alert tcp $HOME_NET any <> $EXTERNAL_NET any (msg: "test tcp =
connections";)
alert udp $HOME_NET any <> $EXTERNAL_NET any (msg: "test udp =
connections";)
alert icmp $HOME_NET any <> $EXTERNAL_NET any (msg: "test icmp
connections";)
I see things getting logged. What I don't have is anything getting =
through to the other side. This box should just transparently bridge =
the traffic through but I'm at a loss why it is not at the moment. When =
I change the rules, they react accordingly. This is what I do know so =
far.
++++++++++++++++++++++++++++++++++++++++
#/sbin/lsmod
Module Size Used by
ipt_state 5504 2
ip_conntrack 30348 1 ipt_state
ipv6 214624 16
iptable_filter 6016 1
ip_tables 18048 2 ipt_state,iptable_filter
bridge 32024 0
ip_queue 11672 0
autofs4 15488 0
sunrpc 110280 1
e1000 73356 0
e100 30852 0
mii 7552 1 e100
sg 32288 0
microcode 10400 0
dm_mod 37536 0
button 8472 0
battery 10892 0
asus_acpi 12440 0
ac 7308 0
ext3 108136 2
jbd 50328 1 ext3
ata_piix 9348 3
libata 33536 1 ata_piix,[permanent]
sd_mod 20352 4
scsi_mod 97224 3 sg,libata,sd_mod
++++++++++++++++++++++++++++++++++++++++
var HOME_NET is the same network that the inline interfaces are =
bridging.
var HOME_NET 69.76.125.118/27
var EXTERNAL_NET any
var SMTP_SERVERS any
var TELNET_SERVERS any
var HTTP_SERVERS any
var SQL_SERVERS any
var HTTP_PORTS 80
var SHELLCODE_PORTS !80
var ORACLE_PORTS 1521
config checksum_mode: none
var RULE_PATH /opt/snort-inline/rules/ips
config layer2resets: 00:04:23:AD:ED:BA
preprocessor flow: stats_interval 0 hash 2
preprocessor stream4: =
disable_evasion_alerts,iptablesnewmark,iptablesestmark,forceiptstate
preprocessor stream4_reassemble: both
# preprocessor clamav: ports all !22 !443, toclientonly, dbdir =
/usr/share/clamav
preprocessor http_inspect: global iis_unicode_map unicode.map 1252
preprocessor http_inspect_server: server default profile all ports { 80 =
8080 8180 } oversize_dir_length 500
preprocessor rpc_decode: 111 32771
preprocessor bo
preprocessor telnet_decode
output alert_full: snort-inline-full
output alert_fast: snort-inline-fast
output alert_syslog: LOG_AUTH LOG_ALERT
output database: alert, mysql, user=3Dsomeuser password=3Dsomepassword =
dbname=3Dsnort host=3Dlocalhost sensor_name=3DIPS
output log_tcpdump: tcpdump.log
include ips-classification.config
include ips-reference.config
include $RULE_PATH/ips.rules
++++++++++++++++++++++++++++++++++++++++
This is my bridge setup:
/sbin/modprobe ip_queue
/sbin/ifconfig eth1 0.0.0.0
/sbin/ifconfig eth2 0.0.0.0
/usr/local/sbin/brctl addbr br0
/usr/local/sbin/brctl addif br0 eth1
/usr/local/sbin/brctl addif br0 eth2
/sbin/ifconfig br0 up
/usr/local/sbin/brctl stp br0 off
/usr/local/sbin/iptables -F FORWARD
/usr/local/sbin/iptables -A FORWARD -j QUEUE
/sbin/ifconfig br0 0.0.0.0 -arp
++++++++++++++++++++++++++++++++++++++++
This is what my iptables setup looks like.
/usr/local/sbin/iptables -P FORWARD DROP
/usr/local/sbin/iptables -A FORWARD -p tcp --syn -m state --state NEW -j
QUEUE
/usr/local/sbin/iptables -A FORWARD -p tcp -m state --state
RELATED,ESTABLISHED -j QUEUE
/usr/local/sbin/iptables -A FORWARD -p udp -j QUEUE
/usr/local/sbin/iptables -A FORWARD -p icmp -j QUEUE
#/usr/local/sbin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
QUEUE all -- anywhere anywhere
QUEUE tcp -- anywhere anywhere tcp
flags:SYN,RST,ACK/SYN state NEW
QUEUE tcp -- anywhere anywhere state
RELATED,ESTABLISHED
QUEUE udp -- anywhere anywhere
QUEUE icmp -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
++++++++++++++++++++++++++++++++++++++++
Kernel linux-2.6.5-1.358, Fedora Core 2.
++++++++++++++++++++++++++++++++++++++++
# /sbin/ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:11:11:50:EE:D2
inet addr:172.16.200.211 Bcast:172.16.255.255 =
Mask:255.255.0.0
inet6 addr: fe80::211:11ff:fe50:eed2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:77160 errors:5 dropped:0 overruns:0 frame:5
TX packets:38287 errors:0 dropped:0 overruns:0 carrier:3
collisions:2126 txqueuelen:1000
RX bytes:7950909 (7.5 Mb) TX bytes:14485654 (13.8 Mb)
eth1 Link encap:Ethernet HWaddr 00:04:23:AD:ED:BA
inet6 addr: fe80::204:23ff:fead:edba/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:413 errors:0 dropped:0 overruns:0 frame:0
TX packets:673 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:31654 (30.9 Kb) TX bytes:71099 (69.4 Kb)
Base address:0xc800 Memory:ff8c0000-ff8e0000
eth2 Link encap:Ethernet HWaddr 00:04:23:AD:ED:BB
inet6 addr: fe80::204:23ff:fead:edbb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10067 errors:0 dropped:0 overruns:0 frame:0
TX packets:190 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:741428 (724.0 Kb) TX bytes:16514 (16.1 Kb)
Base address:0xcc00 Memory:ff8e0000-ff900000
eth3 Link encap:Ethernet HWaddr 00:04:23:AD:ED:D6
inet6 addr: fe80::204:23ff:fead:edd6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:398 (398.0 b)
Base address:0xc000 Memory:ff780000-ff7a0000
eth4 Link encap:Ethernet HWaddr 00:04:23:AD:ED:D7
inet6 addr: fe80::204:23ff:fead:edd7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1429283 errors:1835 dropped:0 overruns:0 frame:1835
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:307722248 (293.4 Mb) TX bytes:398 (398.0 b)
Base address:0xc400 Memory:ff7a0000-ff7c0000
eth5 Link encap:Ethernet HWaddr 00:04:23:AD:ED:A8
inet6 addr: fe80::204:23ff:fead:eda8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:164 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11008 (10.7 Kb) TX bytes:398 (398.0 b)
Base address:0xb800 Memory:ff640000-ff660000
eth6 Link encap:Ethernet HWaddr 00:04:23:AD:ED:A9
inet6 addr: fe80::204:23ff:fead:eda9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9078 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:898198 (877.1 Kb) TX bytes:398 (398.0 b)
Base address:0xbc00 Memory:ff660000-ff680000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:107 errors:0 dropped:0 overruns:0 frame:0
TX packets:107 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:14503 (14.1 Kb) TX bytes:14503 (14.1 Kb)
br0 Link encap:Ethernet HWaddr 00:04:23:AD:ED:BA
inet6 addr: fe80::204:23ff:fead:edba/64 Scope:Link
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:9861 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:506916 (495.0 Kb) TX bytes:210 (210.0 b)
sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
++++++++++++++++++++++++++++++++++++++++
Am I missing something? What about a crossover cable between the =
firewall ethernet interface and the snort-inline ethernet interface? The =
MAC address for "config layer2resets: 00:04:23:AD:ED:BA" is the same as =
ETH1 and BR0. I'm not sure if that should be changed?
Thanks,
Michael |
|
From: Nick R. <ni...@ro...> - 2005-01-05 19:23:28
|
On Wed, 5 Jan 2005, Alex Dupre wrote: > Nick Rogness wrote: >> 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? > > No, it's not possibile and I don't think it'll change in future. hmm, I wonder if we could use some combination of netgraph modules to make this work instead. THe code would have to be changed, but it may be an option in the future. Nick Rogness <ni...@ro...> - How many people here have telekenetic powers? Raise my hand. -Emo Philips |
|
From: Will M. <wil...@gm...> - 2005-01-05 14:01:02
|
We will look into this for the 2.3.0 release of snort_inline. Regards, Will On Wed, 05 Jan 2005 07:29:40 -0500, ka...@ez... <ka...@ez...> wrote: > 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 > > ------------------------------------------------------- > 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 > |
133 messages has been excluded from this view by a project administrator.
