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: Victor J. <vi...@nk...> - 2004-07-09 10:55:51
|
On Friday 09 July 2004 09:45, Victor Julien wrote: > On Friday 09 July 2004 03:04, William Metcalf wrote: > > >I'm no snort expert, nor a snort_inline expert, nor a expert programmer, > > > > but > > > > >my question is: what would you gain by writing your own preproc? Can you > > >point problems in the current one that are so big they can't be fixed? > > > > The way that stream4 deals with data now is not really ideal for an > > inline device. We could cut a lot of fat out stream4 with the checks for > > picking up sessions midstream as this shouldn't ever happen except during > > the initialization of the plug-in. In addition separating out the > > session time-out and storing of packets in memory will be difficult while > > keeping the stream4 preproc working while not in inline mode. Rob has > > amazingly been able to do this up to this point : -) > > I have several ideas. Since snort_inline is dependant on Netfilter, can't > we in some way use the Netfilter connection-tracking? Maybe with some > extension of conntrack or a modification of libipq? We don't have to > re-invent the wheel, right? Sorry to follow up on myself, but if in iptables you mark NEW connections 0x1 and ESTABLISHED/RELATED connections 0x2, and manage to in some way communicate this trough the QUEUE target to snort_inline (not sure if this is possible), then you can use the iptables conntrack, right? Then it would be possible to pick up sessions midstream because iptables tells you they are valid (by setting the mark to 0x2)... and then the timeout of 30 sec to 2 minutes would make sense again, because we can pickup sessions midstream again. Iptables would then send NEW connections with mark 0x1 so in snort_inline we can then inspect the packet. See if it is a synner... this way we can still detect portscans. So a new connection with MARK 0x1 would have have the syn-flag, otherwise its a scan or something. A packet which enters midstream would contain the 0x2 mark (set by iptables), so we know it is not a scan, and we can accept it and create a session for it again! How does this sound to you guys? Regards, Victor > > Maybe we want (yes we, i would like to help you ;-) the same timeout values > netfilter uses. They make sense in normal use. This would present a > challenge because of the much larger memory use of stream4. But maybe we > can store the data of sessions that are inactive for a few minutes on disk? > > Can we think of something to write the state table to disk so it can > survive a sighup (for applying new settings) or even a program restart > (they seem to be identical right now (see below)). If you are in a > corporate environment, you can't afford to lose sessions of your users if > you apply a new rule or a configuration change. > > <snip> > > > Don't quote me on this, as I'm not sure if snort still reacts the same > > way to a kill -HUP, but in the past it didn't just re-read the config > > files, it used exec argv which completely tore down snort and restarted. > > You're right, I just didn't look right! I was really tired yesterday (in a > few days i'm going on my holiday, i really deserved it! ;-) > > Regards, > Victor > > > Regards, > > > > Will > > > > > > > > > > > > > > > > Victor Julien > > <vi...@nk...> > > > > To 07/08/2004 07:13 William Metcalf > > PM <Wil...@kc...> > > > > cc sno...@li...urceforg e.net, > > > > sno...@li...ur ceforge.net > > > > Subject Re: [Snort-inline-users] [PATCH] fix restart function called > > after a SigHUP > > > > On Friday 09 July 2004 01:59, William Metcalf wrote: > > > The more requests that come in, it's getting conceptually harder to > > > meet them modding the stream4 that comes with vanilla snort. I guess > > > I've > > > > found > > > > > my research project for my cert, I'll start rewriting stream4 as a > > > > separate > > > > > preproc for snort_inline. What do you guy's think about this? > > > > I'm no snort expert, nor a snort_inline expert, nor a expert programmer, > > but > > my question is: what would you gain by writing your own preproc? Can you > > point problems in the current one that are so big they can't be fixed? > > > > > If this is cool with everyone, just send me what you would like to see. > > > > As > > > > > far as reassembly goes how long do you think we should store packets in > > > > memory from the stream? What is a good length to keep state? > > > > I would like to be able to walk away from my ssh session for a few hours, > > and > > still not lose my session (and i really know people that act this way! =) > > > > But Will, can you explain me something? When snort_inline receives a > > sighup > > > > the Restart() function is called, which in its turn runs through the > > PluginRestartList to execute the restart function of the specific > > preproc, right? If i'm not mistaken, for stream4 this the > > Stream4RestartFunction(). However in that function (starting on line 3509 > > of spp_stream4.c) i can find > > no reason for the state table to flush... so where is flushed (if at > > all)? > > > > > Rob, would you be > > > alright with this? > > > > > > Regards, > > > > > > Will > > > > Regards, > > Victor > > > > PS. what kind of cert is that? > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Snort-inline-users mailing list > Sno...@li... > https://lists.sourceforge.net/lists/listinfo/snort-inline-users |
|
From: Victor J. <vi...@nk...> - 2004-07-09 08:55:09
|
If i see it correct, the code on line 357 can only be reached if pv.interface is already NULL... On Friday 09 July 2004 09:50, William Metcalf wrote: > I forgot that you are trying to do NAT mode... The error comes out of > plugbase.c why it thinks you have yet to specify an interface i'm not sure. > Just for grins try changing line 357 in spo_database.c from > > if (InlineMode()) > > to > > if((InlineMode()) && (pv.interface = NULL)) > > I'm not sure what difference this will make as via the command line > switches you sent you are specifying an interface and the original if > statement is only called if escapedinterface can't be filled by what you > specified on the command line but give it a shot anyway. > > Regards, > > Will |
|
From: William M. <Wil...@kc...> - 2004-07-09 07:50:34
|
I forgot that you are trying to do NAT mode... The error comes out of plugbase.c why it thinks you have yet to specify an interface i'm not s= ure. Just for grins try changing line 357 in spo_database.c from if (InlineMode()) to if((InlineMode()) && (pv.interface =3D NULL)) I'm not sure what difference this will make as via the command line switches you sent you are specifying an interface and the original if statement is only called if escapedinterface can't be filled by what yo= u specified on the command line but give it a shot anyway. Regards, Will= |
|
From: Victor J. <vi...@nk...> - 2004-07-09 07:45:31
|
On Friday 09 July 2004 03:04, William Metcalf wrote: > >I'm no snort expert, nor a snort_inline expert, nor a expert programmer, > > but > > >my question is: what would you gain by writing your own preproc? Can you > >point problems in the current one that are so big they can't be fixed? > > The way that stream4 deals with data now is not really ideal for an inline > device. We could cut a lot of fat out stream4 with the checks for picking > up sessions midstream as this shouldn't ever happen except during the > initialization of the plug-in. In addition separating out the session > time-out and storing of packets in memory will be difficult while keeping > the stream4 preproc working while not in inline mode. Rob has amazingly > been able to do this up to this point : -) I have several ideas. Since snort_inline is dependant on Netfilter, can't we in some way use the Netfilter connection-tracking? Maybe with some extension of conntrack or a modification of libipq? We don't have to re-invent the wheel, right? Maybe we want (yes we, i would like to help you ;-) the same timeout values netfilter uses. They make sense in normal use. This would present a challenge because of the much larger memory use of stream4. But maybe we can store the data of sessions that are inactive for a few minutes on disk? Can we think of something to write the state table to disk so it can survive a sighup (for applying new settings) or even a program restart (they seem to be identical right now (see below)). If you are in a corporate environment, you can't afford to lose sessions of your users if you apply a new rule or a configuration change. <snip> > > Don't quote me on this, as I'm not sure if snort still reacts the same way > to a kill -HUP, but in the past it didn't just re-read the config files, it > used exec argv which completely tore down snort and restarted. You're right, I just didn't look right! I was really tired yesterday (in a few days i'm going on my holiday, i really deserved it! ;-) Regards, Victor > > Regards, > > Will > > > > > > > > Victor Julien > <vi...@nk...> > To > 07/08/2004 07:13 William Metcalf > PM <Wil...@kc...> > cc > sno...@li...urceforg > e.net, > sno...@li...ur > ceforge.net > Subject > Re: [Snort-inline-users] [PATCH] > fix restart function called after a > SigHUP > > On Friday 09 July 2004 01:59, William Metcalf wrote: > > The more requests that come in, it's getting conceptually harder to meet > > them modding the stream4 that comes with vanilla snort. I guess I've > > found > > > my research project for my cert, I'll start rewriting stream4 as a > > separate > > > preproc for snort_inline. What do you guy's think about this? > > I'm no snort expert, nor a snort_inline expert, nor a expert programmer, > but > my question is: what would you gain by writing your own preproc? Can you > point problems in the current one that are so big they can't be fixed? > > > If this is cool with everyone, just send me what you would like to see. > > As > > > far as reassembly goes how long do you think we should store packets in > > memory from the stream? What is a good length to keep state? > > I would like to be able to walk away from my ssh session for a few hours, > and > still not lose my session (and i really know people that act this way! =) > > But Will, can you explain me something? When snort_inline receives a sighup > > the Restart() function is called, which in its turn runs through the > PluginRestartList to execute the restart function of the specific preproc, > right? If i'm not mistaken, for stream4 this the Stream4RestartFunction(). > However in that function (starting on line 3509 of spp_stream4.c) i can > find > no reason for the state table to flush... so where is flushed (if at all)? > > > Rob, would you be > > alright with this? > > > > Regards, > > > > Will > > Regards, > Victor > > PS. what kind of cert is that? |
|
From: Cliff M. <cl...@un...> - 2004-07-09 06:21:25
|
I am using 2.1.3b. Cliff On Jul 8, 2004, at 11:17 PM, William Metcalf wrote: > Which version of snort_inline are you using? > > Regards, > > Will |
|
From: William M. <Wil...@kc...> - 2004-07-09 06:17:52
|
Which version of snort_inline are you using? Regards, Will |
|
From: Cliff M. <cl...@un...> - 2004-07-09 05:48:37
|
Will, When I run it this way I get the following error: Interface is NULL. Name may not be unique for the host Cliff On Jul 8, 2004, at 10:42 PM, William Metcalf wrote: > try > ./snort_inline -Q -c /etc/snort_inline/snort_inline.conf > > Regards, > > Will |
|
From: William M. <Wil...@kc...> - 2004-07-09 05:42:22
|
try ./snort_inline -Q -c /etc/snort_inline/snort_inline.conf Regards, Will |
|
From: Cliff M. <cl...@un...> - 2004-07-09 03:40:32
|
Thanks, I finally have snort_inline functioning correctly. Now I am=20 trying to log to an external mysql server. I am using the following=20 options to start snort_inline: snort_inline -Q -i eth0 -I -c /etc/snort_inline/snort_inline.conf This does not receive any errors, but also does not route the packets=20= for some reason. When I take the mysql line out of the config file,=20 snort_inline works and routes packets: output database: log, mysql, user=3Dsnort host=3Dxx.xx.xx.xx = password=3Dxxxx=20 dbname=3Dsnort_db I ran ./configure --with mysql and can successfully log into that=20 database remotely from the snort_inline box using the supplied user and=20= password. Also, when I do not specify the interface, I receive this=20 error: Interface is NULL. Name may not be unique for the host I have also tried using "inline" for the interface. Any ideas? Cliff On Jun 30, 2004, at 11:42 AM, William Metcalf wrote: > modprobe ip_queue > -j QUEUE > not > -j -QUEUE > > Regards, > > Will > <image.tiff>Cliff Massey <cl...@un...> > > > > > Cliff Massey <cl...@un...> > Sent by: sno...@li... > > 06/30/2004 01:21 PM > > <image.tiff> > > To > <image.tiff> > sno...@li... > > <image.tiff> > > cc > <image.tiff> > sno...@li... > > <image.tiff> > > Subject > <image.tiff> > Re: [Snort-inline-users] Basic Questions > > <image.tiff><image.tiff> > Thanks for the tip, When i try -j -QUEUE. I recieve the error no such > chain/rule by that name. I can see the module loaded using insmod. Do=20= > I > need to set up a new rule for this? > > On Jun 30, 2004, at 11:12 AM, William Metcalf wrote: > > > Here is an e-mail I sent to the list a while ago regarding using > > snort_inline in NAT mode, There is an overabundance of QUEUE > > statements, but it will give you some idea of what to do. > > > > > > > > =A0It shouldn"t be all that difficult, If you already have a nat > > firewall, > > =A0just change the target in your rules from -j ACCEPT to -j QUEUE. > > =A0Using the > > =A0QUEUE target snort-inline will look at the traffic. =A0If it is = good=20 > it > > will > > =A0pass it, if it is bad it will drop it. =A0Or let"s assume that = you=20 > have > > a > > =A0linux box with two interfaces and you want it to be an ips = router. > > =A0Lets > > =A0also assume that eth0 is int of the network you want to protect = and > > eth1 is > > =A0the interface you have plugged into an untrusted network (cable=20= > modem > > =A0etc.....) =A0Something like the iptables script below should=20 > suffice. =A0I > > =A0might have some redundant QUEUE targets, but I wrote and tested=20= > this > > in > > =A0fifteen minutes. =A0It was dropping bad traffic like a champ. =A0I= =20 > didn"t > > =A0include any icmp statements, so if you want ping you will have = to=20 > add > > it > > =A0yourself. > > > > =A0iptables -F INPUT > > =A0iptables -F FORWARD > > =A0iptables -F OUTPUT > > =A0iptables -t nat -F PREROUTING > > =A0iptables -t nat -F POSTROUTING > > =A0iptables -P INPUT DROP > > =A0iptables -P FORWARD DROP > > =A0iptables -P OUTPUT ACCEPT > > =A0# Enable IP forwarding > > =A0echo "1" > /proc/sys/net/ipv4/ip_forward > > =A0echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route > > =A0echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects > > =A0echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects > > =A0echo "1" > /proc/sys/net/ipv4/tcp_syncookies > > =A0#INPUT > > =A0#Let firewall talk to itself > > =A0iptables -A INPUT -i lo -m state --state NEW -j ACCEPT > > =A0#Allow traffic initiated from this box back in and check for=20 > nastiness > > =A0iptables -A INPUT -m state --state RELATED,ESTABLISHED -j QUEUE > > =A0#Set up the FORWARD table for NAT > > =A0iptables -A FORWARD -i eth0 -o eth1 -j QUEUE > > =A0iptables -A FORWARD -i eth1 -m state --state RELATED,ESTABLISHED = -j > > QUEUE > > =A0#Setup the NAT rule > > =A0iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE > > > > =A0Regards, > > > > =A0Will > > > > > > <image.tiff>Cliff Massey <cl...@un...> > > > > > > > > > > Cliff Massey <cl...@un...> > > Sent by: sno...@li... > > > > 06/30/2004 01:04 PM > > > > <image.tiff> > > > > To > > <image.tiff> > > Rob McMillen <ro...@ho...> > > > > <image.tiff> > > > > cc > > <image.tiff> > > sno...@li... > > > > <image.tiff> > > > > Subject > > <image.tiff> > > Re: [Snort-inline-users] Basic Questions > > > > <image.tiff><image.tiff> > > I'm using Fedora Core 2. As far as sending packets to snort_inline, > > =A0that I'm not quite sure how to do. I read the README, but it = really > > =A0doesn't explain the inline part too well.. What is the best way = to=20 > do > > =A0that? With a QUEUE chain? > > > > =A0=A0Cliff > > > > =A0On Jun 30, 2004, at 5:18 AM, Rob McMillen wrote: > > > > =A0> What linux distro are you using? =A0How are you sending = packets to > > =A0> snort_inline? > > =A0> > > =A0> Rob > > =A0> > > =A0> On Wed, 30 Jun 2004, Cliff Massey wrote: > > =A0> > > =A0>> Date: Wed, 30 Jun 2004 00:35:51 -0700 > > =A0>> From: Cliff Massey <cl...@un...> > > =A0>> To: sno...@li... > > =A0>> Subject: [Snort-inline-users] Basic Questions > > =A0>> > > =A0>> > > =A0>> =A0 Hi, > > =A0>> > > =A0>> =A0 I was wondering if it is possible to get snort_inline to = work > > with > > =A0>> my > > =A0>> current configuration. I'm using the linux 2.6 kernel & = iptables > > with > > =A0>> a > > =A0>> basic nat setup between two interfaces. =A0I can pickup = alerts=20 > when > > =A0>> running it in sniffer mode, although I can't when running in = ids > > mode. > > =A0>> The ip_queue module is loading correctly as I don't receive = an > > error > > =A0>> when using the -Q option. > > =A0>> > > =A0>> =A0 Any help would be appreciated. > > =A0>> > > =A0>> =A0 Cliff Massey > > =A0>> > > =A0>> > > =A0>> > > =A0>> > > =A0>> ------------------------------------------------------- > > =A0>> This SF.Net email sponsored by Black Hat Briefings & = Training. > > =A0>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > =A0>> digital self defense, top technical experts, no vendor = pitches, > > =A0>> unmatched networking opportunities. Visit www.blackhat.com > > =A0>> _______________________________________________ > > =A0>> Snort-inline-users mailing list > > =A0>> Sno...@li... > > =A0>> = https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > =A0>> > > =A0> > > =A0> > > =A0> ------------------------------------------------------- > > =A0> This SF.Net email sponsored by Black Hat Briefings & Training. > > =A0> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > =A0> digital self defense, top technical experts, no vendor = pitches, > > =A0> unmatched networking opportunities. Visit www.blackhat.com > > =A0> _______________________________________________ > > =A0> Snort-inline-users mailing list > > =A0> Sno...@li... > > =A0> = https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > =A0> > > > > > > > > =A0------------------------------------------------------- > > =A0This SF.Net email sponsored by Black Hat Briefings & Training. > > =A0Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > =A0digital self defense, top technical experts, no vendor pitches, > > =A0unmatched networking opportunities. Visit www.blackhat.com > > =A0_______________________________________________ > > =A0Snort-inline-users mailing list > > =A0S...@li... > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > > > > > |
|
From: Victor J. <vi...@nk...> - 2004-07-09 00:13:29
|
On Friday 09 July 2004 01:59, William Metcalf wrote: > The more requests that come in, it's getting conceptually harder to meet > them modding the stream4 that comes with vanilla snort. I guess I've found > my research project for my cert, I'll start rewriting stream4 as a separate > preproc for snort_inline. What do you guy's think about this? I'm no snort expert, nor a snort_inline expert, nor a expert programmer, but my question is: what would you gain by writing your own preproc? Can you point problems in the current one that are so big they can't be fixed? > If this is cool with everyone, just send me what you would like to see. As > far as reassembly goes how long do you think we should store packets in memory from the stream? What is a good length to keep state? I would like to be able to walk away from my ssh session for a few hours, and still not lose my session (and i really know people that act this way! =) But Will, can you explain me something? When snort_inline receives a sighup the Restart() function is called, which in its turn runs through the PluginRestartList to execute the restart function of the specific preproc, right? If i'm not mistaken, for stream4 this the Stream4RestartFunction(). However in that function (starting on line 3509 of spp_stream4.c) i can find no reason for the state table to flush... so where is flushed (if at all)? > Rob, would you be > alright with this? > > Regards, > > Will Regards, Victor PS. what kind of cert is that? |
|
From: William M. <Wil...@kc...> - 2004-07-08 23:59:35
|
The more requests that come in, it's getting conceptually harder to mee= t them modding the stream4 that comes with vanilla snort. I guess I've f= ound my research project for my cert, I'll start rewriting stream4 as a sepa= rate preproc for snort_inline. What do you guy's think about this? If thi= s is cool with everyone, just send me what you would like to see. As far as= reassembly goes how long do you think we should store packets in memory= from the stream? What is a good length to keep state? Rob, would you= be alright with this? Regards, Will= |
|
From: Victor J. <vi...@nk...> - 2004-07-08 21:43:22
|
Hi List, After reading this post in the list archives: kill -HUP snort_inline (http://sourceforge.net/mailarchive/forum.php?thread_id=4035437&forum_id=32933) I decided to take a look a the sighup code. I proved to be very simple. I just copied the snort_inline specific pieces of code from CleanExit(int exit_val) to Restart(), both in snort.c Attached is the patch against 2.1.3b. It seems to work, i saw only one problem. With the stream4 preproc all states are flushed, basicly terminating all current connections... so i guess there needs to be some mechanism that makes sure the state table survives the restart. Any ideas? Will? Regards, Victor |
|
From: Victor J. <vi...@nk...> - 2004-07-07 20:33:55
|
On Wednesday 07 July 2004 21:48, William Metcalf wrote: > Read up on the entries in /proc/sys/net/ipv4/netfilter/, and then see if > you understand. > I think i understand what they mean. I think they say that once a tcp connection is established, that connection is remembered for 432000 seconds. So in theory there can be 431998 seconds between two packets. But i also observe on my own pc that the counter is reset to 432000 every time a packet is processed by the conntrack. But here i have a real life example. I just logged in on an linux machine at my work using ssh trough my snort_inline firewall. Timeout in stream4 is 2 minutes. So when i don't type anything in my ssh session for 3 minutes, the session gets dropped. Not that you're told in ssh, it just gets unresponsive, and times out after a _long_ time. I'm just wondering if this behaviour is what you want from a firewall... (especially if the firewall doesn't log these drops ;-) Regards, Victor > Regards, > > Will > > > > Victor Julien > <vi...@nk...> > To > 07/07/2004 01:55 William Metcalf > PM <Wil...@kc...> > cc > sno...@li...urceforg > e.net, > sno...@li...ur > ceforge.net > Subject > Re: [Snort-inline-users] msn > messenger problem > > > > > > > > > > > Hey Will, > > Thanks for your quick reply! > > On Wednesday 07 July 2004 20:25, William Metcalf wrote: > > These are two different time-outs. The five day time out is a session > > that > > > is actively talking for five days straight. Let's say you are going to > > transfer a file that was 1tb over a 56k connection. This would more than > > likely take more than five day's. Let's say what ever you used to > > transfer the file used the same tcp session for the transfer. After five > > days this transfer would be dropped because the session would be open for > > to long. The 30 second time-out is the last time a packet was last sent > > using a tcp session. So if you start up a tcp session with a three-way > > handshake and keep the session open and send a packet in an incrementing > > manner every 10 20 30 40 50 60 70 seconds the last packet would never > > make > > > it because the session timed-out and was pruned. > > I believe this is not correct. If a tcp session is ESTABLISHED, the timeout > in > iptables (just like in snort_inline) is reset every time the session > processes a packet. For instance my connection to the msn server never gets > > below 431930 (or so) seconds, and after that resets to 431999. Only if a > connection is gone, but was not closed properly i see it really timeout. > > So basicly, based on this i still see no principal difference between the > two, > and i still wonder why the difference is so big. I can see that for snort > it > makes no real difference. It can pickup connections after they started (i > believe), but for snort_inline, acting as a firewall i wonder if > connections > aren't dropped way to fast. > > Furthermore, shouldn't connections that timeout be reset instead of > dropped? > > Regards, > Victor > > > Regards, > > > > Will > > > > > > > > Victor Julien > > <vi...@nk...> > > Sent by: > > To > > > snort-inline-user William Metcalf > > s-...@li...u <Wil...@kc...> > > rceforge.net > > cc > > sno...@li...urceforg > > > e.net > > 07/07/2004 12:47 > > Subject > > > PM Re: [Snort-inline-users] msn > > messenger problem > > > > On Tuesday 06 July 2004 20:24, William Metcalf wrote: > > > 431942 is the absolute time-out for a session in iptables, i.e. is up, > > > active, and constantly talking. It shouldn't be to difficult to > > > > implement > > > > > logging of dropped packets, I would do it but I'm stressed for time as > > it > > > > is. If you feel like implementing this go for it. > > > > Hi William, > > > > I still don't really understand the difference between the 5 days timeout > > in > > iptables and the 30sec-to-2min timeout of snort_inline. Or are those two > > not > > comparable? I do appreciate the fact that the short timeout prevents > > excessive memory usage, but the difference is really, really big. Can you > > elaborate some more on this subject (or point me to some docs?)? > > > > Thanx! > > > > Victor > > > > > Regards, > > > > > > Will > > > > > > > > > > > > Victor Julien > > > <vi...@nk...> > > > > To > > > > > 07/06/2004 01:07 William Metcalf > > > PM <Wil...@kc...> > > > > cc > > > > sno...@li...urceforg > > > > > e.net > > > > Subject > > > > > Re: [Snort-inline-users] msn > > > messenger problem > > > > > > On Tuesday 06 July 2004 19:51, William Metcalf wrote: > > > > The default time out for a session is 120 seconds for iptables. If > > you > > > > set > > > > > > > this in stream4 I would up the amount of memory you allocate for it. > > > > As > > > > > > far as logging out-of-session packets, there isn't a mechanism in > > snort > > > > or > > > > > > > snort_inline to do this, if you are troubleshooting, you can enable > > the > > > > > stream4 debug. This can be accomplished compiling with > > --enable-debug > > > > and > > > > > > > then export SNORT_DEBUG=8192 prior to starting snort_inline. > > > > > > Hmm, i thought the default tcp session timeout in iptables was > > something > > > > like > > > 5 days... > > > > > > from my /proc/net/ip_conntrack: > > > > > > tcp 6 431942 ESTABLISHED src=192.168.0.167 dst=207.46.107.7 > > > sport=35693 > > > dport=1863 src=207.46.107.7 dst=192.168.0.167 sport=1863 dport=35693 > > > [ASSURED] use=1 > > > > > > The counter of 431942 is the session timeout right? > > > > > > Okay, i set the timeout to 120 seconds now, so now i have increase the > > > memcap? > > > Can you give a rule of thumb for how high it should be... (for x number > > > > of > > > > > connections, you need a memcap of y bytes) > > > > > > Wouldn't it be an interesting feature to be able to log those packets > > for > > > > snort_inline (guess not for snort), because if snort_inline makes > > > > dissions > > > > > as > > > a firewall, thus dropping packets, i want to know why... > > > > > > If you run a firewall and connections are dropped (thus the users are > > > complaining to you), but you don't know why i think it's an > > > > administrators > > > > > nightmare... > > > > > > Would that difficult to implement, i'm a moderate c-programmer, so i > > > > could > > > > > give it a shot... > > > > > > (would you (or anyone else) even be interested in such a feature?) > > > > > > Regards, > > > Victor > > > > > > > Regards, > > > > > > > > Will > > > > > > > > > > > > > > > > Victor Julien > > > > <vi...@nk...> > > > > > > To > > > > > > > 07/06/2004 11:41 > > > > > > sno...@li...urceforg > > > > > > > AM e.net > > > > > > cc > > > > > > > William Metcalf > > > > <Wil...@kc...> > > > > > > Subject > > > > > > > Re: [Snort-inline-users] msn > > > > messenger problem > > > > > > > > On Tuesday 06 July 2004 18:16, William Metcalf wrote: > > > > > Increasing the time-out should be fine, gaim must implement it's > > MSN > > > > > > function differently than the windows messenger client. If no data > > > > is > > > > > > > received for x seconds in a TCP conversation the session is pruned > > > > in > > > > > > > stream4, this is the same way that a stateful firewall works. If > > > > data > > > > > is > > > > > > > > received out-of session it is dropped, unless it is trying to > > > > > > initialize > > > > > > > a > > > > > > > > > new session i.e. a packet with the SYN flag set. > > > > > > > > Okay, so the only drawback is that stream4 will take some more memory > > > > because > > > > of this? > > > > > > > > Is this the same type of timeout that iptables uses in the state > > table? > > > > > Iptables uses timeouts of days, not seconds if i recall correctly. > > > > > > > > Final question: why doesn't snort log the packets that are out of > > > > > > session? > > > > > > > Or: > > > > how can i make snort log them? > > > > > > > > Thanks for your help! > > > > > > > > Regards, > > > > Victor > > > > > > > > > Regards, > > > > > > > > > > Will > > > > > > > > > > > > > > > > > > > > Victor Julien > > > > > <vi...@nk...> > > > > > > > > To > > > > > > > > > 07/06/2004 10:55 > > > > > > > > sno...@li...urceforg > > > > > > > > > AM e.net > > > > > > > > cc > > > > > > > > > William Metcalf > > > > > <Wil...@kc...> > > > > > > > > Subject > > > > > > > > > Re: [Snort-inline-users] msn > > > > > messenger problem > > > > > > > > > > On Tuesday 06 July 2004 15:34, William Metcalf wrote: > > > > > > That's odd, try disabling the flow preproc as it is not yet > > > > supported > > > > > > in > > > > > > > > > > snort_inline. I don't have any problem with msn and the stream4 > > > > > > > > preproc. > > > > > > > > > The flow preprocessor was not the problem. I disabled it, but the > > > > > connection > > > > > was still lost after some time. > > > > > > > > > > Increasing the timeout for the stream4 prepoc from the default 30 > > sec > > > > to > > > > > > > 60 > > > > > > > > > sec seems to be the solution. > > > > > > > > > > Can you explain to me what this does? Can it be a security risk? > > DoS? > > > > > > Regards, > > > > > Victor > > > > > > > > > > > Regards, > > > > > > > > > > > > Will > > > > > > > > > > > > > > > > > > > > > > > > Victor Julien > > > > > > <vi...@nk...> > > > > > > Sent by: > > > > > > > > > > To > > > > > > > > > > > snort-inline-user William Metcalf > > > > > > s-...@li...u <Wil...@kc...> > > > > > > rceforge.net > > > > > > > > > > cc > > > > > > > > > > sno...@li...urceforg > > > > > > > > > > > e.net > > > > > > 07/06/2004 06:39 > > > > > > > > > > Subject > > > > > > > > > > > AM Re: [Snort-inline-users] > > msn > > > > > > > messenger problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi William, > > > > > > > > > > > > Thanx for your reply. > > > > > > > > > > > > On Tuesday 06 July 2004 06:32, you wrote: > > > > > > > Look through your logs, there are certian rules that detect > > > > > > > > > > msn-messenger > > > > > > > > > > > > logon attemtps, if you have converted all rules to drop > > messenger > > > > > would > > > > > > > > > > > stop working. > > > > > > > > > > > > My logs don't show anything about msn messenger. So if > > snort_inline > > > > is > > > > > > > > > blocking msn in some way, it does so without telling me. I also > > > > tried > > > > > > > aMsn > > > > > > > > > > > and Gaim and the same thing happens. > > > > > > > > > > > > I got this when running Gaim in debug mode: > > > > > > > > > > > > <snipped entire login procedure> > > > > > > msn: C: PNG > > > > > > msn: S: QNG 41 > > > > > > msn: C: PNG > > > > > > msn: S: QNG 46 > > > > > > msn: C: PNG > > > > > > msn: S: QNG 44 > > > > > > msn: C: PNG > > > > > > msn: S: QNG 40 > > > > > > msn: C: PNG > > > > > > msn: S: QNG 40 > > > > > > msn: C: PNG > > > > > > msn: S: QNG 43 > > > > > > msn: C: PNG > > > > > > msn: S: QNG 42 > > > > > > msn: C: PNG > > > > > > msn: S: QNG 47 > > > > > > > > > > > > I think 'C' is the client. It does some kind of keep-a-live i > > > > think. > > > > > > > After > > > > > > > > > > > a > > > > > > 'PNG' (ping?) the server responds everytime. Then without notice > > or > > > > > > > message, > > > > > > the server stops responding, and finally disconnects. > > > > > > > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > msn: C: PNG > > > > > > account: Disconnecting account 0x8198ae0 > > > > > > connection: Disconnecting connection 0x82ba848 > > > > > > server: removing NOP > > > > > > > > > > > > I get no message what-so-ever in any log (snort, iptables, > > syslog). > > > > > > > Could this have something to do with: > > > > > > 1. preprocessor flow > > > > > > 2. preprocessor stream4 > > > > > > 3. preprocessor stream4_reassemble > > > > > > > > > > > > Maybe some internal time-out in snort_inline? > > > > > > > > > > > > Note that i don't have this problem when only iptables handles > > msn > > > > > (with > > > > > > > > > -j > > > > > > > > > > > ACCEPT). > > > > > > > > > > > > Regards, > > > > > > Victor > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Will > > > > > > > > > > > > > > packescrubber:/etc/snort# grep MSN * > > > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 > > > > (msg:"CHAT > > > > > > MSN > > > > > > > > > > > message"; flow:established; content:"MSG "; depth:4; > > > > > > > content:"Content-Type|3A|"; nocase; content:"text/plain"; > > > > > > distance:1; > > > > > > > > > > classtype:policy-violation; sid:540; rev:11;) > > > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 > > > > (msg:"CHAT > > > > > > MSN > > > > > > > > > > file > > > > > > > > > > > > > transfer request"; flow:established; content:"MSG "; depth:4; > > > > > > > content:"Content-Type|3A|"; distance:0; nocase; > > > > > > > content:"text/x-msmsgsinvite"; distance:0; nocase; > > > > > > > content:"Application-Name|3A|"; content:"File Transfer"; > > > > > > distance:0; > > > > > > > > > > nocase; classtype:policy-violation; sid:1986; rev:4;) > > > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 > > > > (msg:"CHAT > > > > > > MSN > > > > > > > > > > file > > > > > > > > > > > > > transfer accept"; flow:established; content:"MSG "; depth:4; > > > > > > > content:"Content-Type|3A|"; nocase; > > > > content:"text/x-msmsgsinvite"; > > > > > > > > > distance:0; content:"Invitation-Command|3A|"; content:"ACCEPT"; > > > > > > > > > > > > distance:1; > > > > > > > > > > > > > classtype:policy-violation; sid:1988; rev:3;) > > > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 > > > > (msg:"CHAT > > > > > > MSN > > > > > > > > > > file > > > > > > > > > > > > > transfer reject"; flow:established; content:"MSG "; depth:4; > > > > > > > content:"Content-Type|3A|"; nocase; > > > > content:"text/x-msmsgsinvite"; > > > > > > > > > distance:0; content:"Invitation-Command|3A|"; content:"CANCEL"; > > > > > > > > > > > > distance:0; > > > > > > > > > > > > > content:"Cancel-Code|3A|"; nocase; content:"REJECT"; > > distance:0; > > > > > > nocase; > > > > > > > > > > > > classtype:policy-violation; sid:1989; rev:4;) > > > > > > > chat.rules:drop tcp $HOME_NET any -> $EXTERNAL_NET 1863 > > > > (msg:"CHAT > > > > > > MSN > > > > > > > > > > user > > > > > > > > > > > > > search"; flow:to_server,established; content:"CAL "; depth:4; > > > > > > nocase; > > > > > > > > > > classtype:policy-violation; sid:1990; rev:1;) > > > > > > > chat.rules:drop tcp $HOME_NET any -> $EXTERNAL_NET 1863 > > > > (msg:"CHAT > > > > > > MSN > > > > > > > > > > > login attempt"; flow:to_server,established; content:"USR "; > > > > > > depth:4; > > > > > > > > > > nocase; content:" TWN "; distance:1; nocase; > > > > > > > > > > classtype:policy-violation; > > > > > > > > > > > > sid:1991; rev:1;) > > > > > > > sid-msg.map:540 || CHAT MSN message > > > > > > > sid-msg.map:1986 || CHAT MSN file transfer request > > > > > > > sid-msg.map:1988 || CHAT MSN file transfer accept > > > > > > > sid-msg.map:1989 || CHAT MSN file transfer reject > > > > > > > sid-msg.map:1990 || CHAT MSN user search > > > > > > > sid-msg.map:1991 || CHAT MSN login attempt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Victor Julien > > > > > > > <vi...@nk...> > > > > > > > Sent by: > > > > > > > > > > > > To > > > > > > > > > > > > > snort-inline-user > > > > > > > > > > > > sno...@li...urceforg > > > > > > > > > > > > > s-...@li...u e.net > > > > > > > rceforge.net > > > > > > > > > > > > cc > > > > > > > > > > > > > > > > > > Subject > > > > > > > > > > > > > 07/01/2004 02:00 [Snort-inline-users] msn > > > > > > > > > > messenger > > > > > > > > > > > > PM problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I 'm testing snort_inline to filter my outgoing traffic. Http, > > > > > > ftp, > > > > > > > > pop3 > > > > > > > > > > > > work > > > > > > > fine so far, however msn-messenger does not. I'm using Kopete > > > > (kde > > > > > > > 3.2.2, > > > > > > > > > > > > debian-testing) with msn-plugin. The plugin just dies after > > some > > > 5 > > > > > > > > minutes > > > > > > > > > > > > > or > > > > > > > so. This does not happen when msn works just with iptables. Is > > > > > > there > > > > > > > > any > > > > > > > > > > > > known problem with msn and snort_inline? > > > > > > > > > > > > > > Regards, > > > > > > > Victor > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > > > > digital self defense, top technical experts, no vendor pitches, > > > > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > > > > _______________________________________________ > > > > > > > Snort-inline-users mailing list > > > > > > > Sno...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > > > > > > > > > > > ------------------------------------------------------- > > > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > > > digital self defense, top technical experts, no vendor pitches, > > > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > > > _______________________________________________ > > > > > > Snort-inline-users mailing list > > > > > > Sno...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > > > ------------------------------------------------------- > > This SF.Net email sponsored by Black Hat Briefings & Training. > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > digital self defense, top technical experts, no vendor pitches, > > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > > Snort-inline-users mailing list > > Sno...@li... > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users |
|
From: William M. <Wil...@kc...> - 2004-07-07 19:54:33
|
Read up on the entries in /proc/sys/net/ipv4/netfilter/, and then see if you understand. Regards, Will |
|
From: Victor J. <vi...@nk...> - 2004-07-07 18:55:32
|
Hey Will, Thanks for your quick reply! On Wednesday 07 July 2004 20:25, William Metcalf wrote: > These are two different time-outs. The five day time out is a session that > is actively talking for five days straight. Let's say you are going to > transfer a file that was 1tb over a 56k connection. This would more than > likely take more than five day's. Let's say what ever you used to > transfer the file used the same tcp session for the transfer. After five > days this transfer would be dropped because the session would be open for > to long. The 30 second time-out is the last time a packet was last sent > using a tcp session. So if you start up a tcp session with a three-way > handshake and keep the session open and send a packet in an incrementing > manner every 10 20 30 40 50 60 70 seconds the last packet would never make > it because the session timed-out and was pruned. I believe this is not correct. If a tcp session is ESTABLISHED, the timeout in iptables (just like in snort_inline) is reset every time the session processes a packet. For instance my connection to the msn server never gets below 431930 (or so) seconds, and after that resets to 431999. Only if a connection is gone, but was not closed properly i see it really timeout. So basicly, based on this i still see no principal difference between the two, and i still wonder why the difference is so big. I can see that for snort it makes no real difference. It can pickup connections after they started (i believe), but for snort_inline, acting as a firewall i wonder if connections aren't dropped way to fast. Furthermore, shouldn't connections that timeout be reset instead of dropped? Regards, Victor > > Regards, > > Will > > > > Victor Julien > <vi...@nk...> > Sent by: To > snort-inline-user William Metcalf > s-...@li...u <Wil...@kc...> > rceforge.net cc > sno...@li...urceforg > e.net > 07/07/2004 12:47 Subject > PM Re: [Snort-inline-users] msn > messenger problem > > On Tuesday 06 July 2004 20:24, William Metcalf wrote: > > 431942 is the absolute time-out for a session in iptables, i.e. is up, > > active, and constantly talking. It shouldn't be to difficult to > > implement > > > logging of dropped packets, I would do it but I'm stressed for time as it > > is. If you feel like implementing this go for it. > > Hi William, > > I still don't really understand the difference between the 5 days timeout > in > iptables and the 30sec-to-2min timeout of snort_inline. Or are those two > not > comparable? I do appreciate the fact that the short timeout prevents > excessive memory usage, but the difference is really, really big. Can you > elaborate some more on this subject (or point me to some docs?)? > > Thanx! > > Victor > > > Regards, > > > > Will > > > > > > > > Victor Julien > > <vi...@nk...> > > To > > > 07/06/2004 01:07 William Metcalf > > PM <Wil...@kc...> > > cc > > sno...@li...urceforg > > > e.net > > Subject > > > Re: [Snort-inline-users] msn > > messenger problem > > > > On Tuesday 06 July 2004 19:51, William Metcalf wrote: > > > The default time out for a session is 120 seconds for iptables. If you > > > > set > > > > > this in stream4 I would up the amount of memory you allocate for it. > > As > > > > far as logging out-of-session packets, there isn't a mechanism in snort > > > > or > > > > > snort_inline to do this, if you are troubleshooting, you can enable the > > > stream4 debug. This can be accomplished compiling with --enable-debug > > > > and > > > > > then export SNORT_DEBUG=8192 prior to starting snort_inline. > > > > Hmm, i thought the default tcp session timeout in iptables was something > > like > > 5 days... > > > > from my /proc/net/ip_conntrack: > > > > tcp 6 431942 ESTABLISHED src=192.168.0.167 dst=207.46.107.7 > > sport=35693 > > dport=1863 src=207.46.107.7 dst=192.168.0.167 sport=1863 dport=35693 > > [ASSURED] use=1 > > > > The counter of 431942 is the session timeout right? > > > > Okay, i set the timeout to 120 seconds now, so now i have increase the > > memcap? > > Can you give a rule of thumb for how high it should be... (for x number > > of > > > connections, you need a memcap of y bytes) > > > > Wouldn't it be an interesting feature to be able to log those packets for > > snort_inline (guess not for snort), because if snort_inline makes > > dissions > > > as > > a firewall, thus dropping packets, i want to know why... > > > > If you run a firewall and connections are dropped (thus the users are > > complaining to you), but you don't know why i think it's an > > administrators > > > nightmare... > > > > Would that difficult to implement, i'm a moderate c-programmer, so i > > could > > > give it a shot... > > > > (would you (or anyone else) even be interested in such a feature?) > > > > Regards, > > Victor > > > > > Regards, > > > > > > Will > > > > > > > > > > > > Victor Julien > > > <vi...@nk...> > > > > To > > > > > 07/06/2004 11:41 > > > > sno...@li...urceforg > > > > > AM e.net > > > > cc > > > > > William Metcalf > > > <Wil...@kc...> > > > > Subject > > > > > Re: [Snort-inline-users] msn > > > messenger problem > > > > > > On Tuesday 06 July 2004 18:16, William Metcalf wrote: > > > > Increasing the time-out should be fine, gaim must implement it's MSN > > > > function differently than the windows messenger client. If no data > > is > > > > > received for x seconds in a TCP conversation the session is pruned > > in > > > > > stream4, this is the same way that a stateful firewall works. If > > data > > > is > > > > > > received out-of session it is dropped, unless it is trying to > > > > initialize > > > > > a > > > > > > > new session i.e. a packet with the SYN flag set. > > > > > > Okay, so the only drawback is that stream4 will take some more memory > > > because > > > of this? > > > > > > Is this the same type of timeout that iptables uses in the state table? > > > Iptables uses timeouts of days, not seconds if i recall correctly. > > > > > > Final question: why doesn't snort log the packets that are out of > > > > session? > > > > > Or: > > > how can i make snort log them? > > > > > > Thanks for your help! > > > > > > Regards, > > > Victor > > > > > > > Regards, > > > > > > > > Will > > > > > > > > > > > > > > > > Victor Julien > > > > <vi...@nk...> > > > > > > To > > > > > > > 07/06/2004 10:55 > > > > > > sno...@li...urceforg > > > > > > > AM e.net > > > > > > cc > > > > > > > William Metcalf > > > > <Wil...@kc...> > > > > > > Subject > > > > > > > Re: [Snort-inline-users] msn > > > > messenger problem > > > > > > > > On Tuesday 06 July 2004 15:34, William Metcalf wrote: > > > > > That's odd, try disabling the flow preproc as it is not yet > > supported > > > > in > > > > > > > > snort_inline. I don't have any problem with msn and the stream4 > > > > > > preproc. > > > > > > > The flow preprocessor was not the problem. I disabled it, but the > > > > connection > > > > was still lost after some time. > > > > > > > > Increasing the timeout for the stream4 prepoc from the default 30 sec > > > > to > > > > > 60 > > > > > > > sec seems to be the solution. > > > > > > > > Can you explain to me what this does? Can it be a security risk? DoS? > > > > > > > > Regards, > > > > Victor > > > > > > > > > Regards, > > > > > > > > > > Will > > > > > > > > > > > > > > > > > > > > Victor Julien > > > > > <vi...@nk...> > > > > > Sent by: > > > > > > > > To > > > > > > > > > snort-inline-user William Metcalf > > > > > s-...@li...u <Wil...@kc...> > > > > > rceforge.net > > > > > > > > cc > > > > > > > > sno...@li...urceforg > > > > > > > > > e.net > > > > > 07/06/2004 06:39 > > > > > > > > Subject > > > > > > > > > AM Re: [Snort-inline-users] msn > > > > > messenger problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi William, > > > > > > > > > > Thanx for your reply. > > > > > > > > > > On Tuesday 06 July 2004 06:32, you wrote: > > > > > > Look through your logs, there are certian rules that detect > > > > > > > > msn-messenger > > > > > > > > > > logon attemtps, if you have converted all rules to drop messenger > > > > > > would > > > > > > > > > stop working. > > > > > > > > > > My logs don't show anything about msn messenger. So if snort_inline > > > > is > > > > > > > blocking msn in some way, it does so without telling me. I also > > tried > > > > > aMsn > > > > > > > > > and Gaim and the same thing happens. > > > > > > > > > > I got this when running Gaim in debug mode: > > > > > > > > > > <snipped entire login procedure> > > > > > msn: C: PNG > > > > > msn: S: QNG 41 > > > > > msn: C: PNG > > > > > msn: S: QNG 46 > > > > > msn: C: PNG > > > > > msn: S: QNG 44 > > > > > msn: C: PNG > > > > > msn: S: QNG 40 > > > > > msn: C: PNG > > > > > msn: S: QNG 40 > > > > > msn: C: PNG > > > > > msn: S: QNG 43 > > > > > msn: C: PNG > > > > > msn: S: QNG 42 > > > > > msn: C: PNG > > > > > msn: S: QNG 47 > > > > > > > > > > I think 'C' is the client. It does some kind of keep-a-live i > > think. > > > > > After > > > > > > > > > a > > > > > 'PNG' (ping?) the server responds everytime. Then without notice or > > > > > message, > > > > > the server stops responding, and finally disconnects. > > > > > > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > msn: C: PNG > > > > > account: Disconnecting account 0x8198ae0 > > > > > connection: Disconnecting connection 0x82ba848 > > > > > server: removing NOP > > > > > > > > > > I get no message what-so-ever in any log (snort, iptables, syslog). > > > > > > > > > > Could this have something to do with: > > > > > 1. preprocessor flow > > > > > 2. preprocessor stream4 > > > > > 3. preprocessor stream4_reassemble > > > > > > > > > > Maybe some internal time-out in snort_inline? > > > > > > > > > > Note that i don't have this problem when only iptables handles msn > > > > > > (with > > > > > > > -j > > > > > > > > > ACCEPT). > > > > > > > > > > Regards, > > > > > Victor > > > > > > > > > > > Regards, > > > > > > > > > > > > Will > > > > > > > > > > > > packescrubber:/etc/snort# grep MSN * > > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 > > (msg:"CHAT > > > > MSN > > > > > > > > > message"; flow:established; content:"MSG "; depth:4; > > > > > > content:"Content-Type|3A|"; nocase; content:"text/plain"; > > > > distance:1; > > > > > > > > classtype:policy-violation; sid:540; rev:11;) > > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 > > (msg:"CHAT > > > > MSN > > > > > > > > file > > > > > > > > > > > transfer request"; flow:established; content:"MSG "; depth:4; > > > > > > content:"Content-Type|3A|"; distance:0; nocase; > > > > > > content:"text/x-msmsgsinvite"; distance:0; nocase; > > > > > > content:"Application-Name|3A|"; content:"File Transfer"; > > > > distance:0; > > > > > > > > nocase; classtype:policy-violation; sid:1986; rev:4;) > > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 > > (msg:"CHAT > > > > MSN > > > > > > > > file > > > > > > > > > > > transfer accept"; flow:established; content:"MSG "; depth:4; > > > > > > content:"Content-Type|3A|"; nocase; > > content:"text/x-msmsgsinvite"; > > > > > > > distance:0; content:"Invitation-Command|3A|"; content:"ACCEPT"; > > > > > > > > > > distance:1; > > > > > > > > > > > classtype:policy-violation; sid:1988; rev:3;) > > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 > > (msg:"CHAT > > > > MSN > > > > > > > > file > > > > > > > > > > > transfer reject"; flow:established; content:"MSG "; depth:4; > > > > > > content:"Content-Type|3A|"; nocase; > > content:"text/x-msmsgsinvite"; > > > > > > > distance:0; content:"Invitation-Command|3A|"; content:"CANCEL"; > > > > > > > > > > distance:0; > > > > > > > > > > > content:"Cancel-Code|3A|"; nocase; content:"REJECT"; distance:0; > > > > > > > > nocase; > > > > > > > > > > classtype:policy-violation; sid:1989; rev:4;) > > > > > > chat.rules:drop tcp $HOME_NET any -> $EXTERNAL_NET 1863 > > (msg:"CHAT > > > > MSN > > > > > > > > user > > > > > > > > > > > search"; flow:to_server,established; content:"CAL "; depth:4; > > > > nocase; > > > > > > > > classtype:policy-violation; sid:1990; rev:1;) > > > > > > chat.rules:drop tcp $HOME_NET any -> $EXTERNAL_NET 1863 > > (msg:"CHAT > > > > MSN > > > > > > > > > login attempt"; flow:to_server,established; content:"USR "; > > > > depth:4; > > > > > > > > nocase; content:" TWN "; distance:1; nocase; > > > > > > > > classtype:policy-violation; > > > > > > > > > > sid:1991; rev:1;) > > > > > > sid-msg.map:540 || CHAT MSN message > > > > > > sid-msg.map:1986 || CHAT MSN file transfer request > > > > > > sid-msg.map:1988 || CHAT MSN file transfer accept > > > > > > sid-msg.map:1989 || CHAT MSN file transfer reject > > > > > > sid-msg.map:1990 || CHAT MSN user search > > > > > > sid-msg.map:1991 || CHAT MSN login attempt > > > > > > > > > > > > > > > > > > > > > > > > Victor Julien > > > > > > <vi...@nk...> > > > > > > Sent by: > > > > > > > > > > To > > > > > > > > > > > snort-inline-user > > > > > > > > > > sno...@li...urceforg > > > > > > > > > > > s-...@li...u e.net > > > > > > rceforge.net > > > > > > > > > > cc > > > > > > > > > > > > > > > Subject > > > > > > > > > > > 07/01/2004 02:00 [Snort-inline-users] msn > > > > > > > > messenger > > > > > > > > > > PM problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > I 'm testing snort_inline to filter my outgoing traffic. Http, > > > > ftp, > > > > > > pop3 > > > > > > > > > > work > > > > > > fine so far, however msn-messenger does not. I'm using Kopete > > (kde > > > > > 3.2.2, > > > > > > > > > > debian-testing) with msn-plugin. The plugin just dies after some > > 5 > > > > > > minutes > > > > > > > > > > > or > > > > > > so. This does not happen when msn works just with iptables. Is > > > > there > > > > > > any > > > > > > > > > > known problem with msn and snort_inline? > > > > > > > > > > > > Regards, > > > > > > Victor > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > > > digital self defense, top technical experts, no vendor pitches, > > > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > > > _______________________________________________ > > > > > > Snort-inline-users mailing list > > > > > > Sno...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > > digital self defense, top technical experts, no vendor pitches, > > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > > _______________________________________________ > > > > > Snort-inline-users mailing list > > > > > Sno...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Snort-inline-users mailing list > Sno...@li... > https://lists.sourceforge.net/lists/listinfo/snort-inline-users |
|
From: Victor J. <vi...@nk...> - 2004-07-07 17:47:21
|
On Tuesday 06 July 2004 20:24, William Metcalf wrote: > 431942 is the absolute time-out for a session in iptables, i.e. is up, > active, and constantly talking. It shouldn't be to difficult to implement > logging of dropped packets, I would do it but I'm stressed for time as it > is. If you feel like implementing this go for it. Hi William, I still don't really understand the difference between the 5 days timeout in iptables and the 30sec-to-2min timeout of snort_inline. Or are those two not comparable? I do appreciate the fact that the short timeout prevents excessive memory usage, but the difference is really, really big. Can you elaborate some more on this subject (or point me to some docs?)? Thanx! Victor > > Regards, > > Will > > > > Victor Julien > <vi...@nk...> > To > 07/06/2004 01:07 William Metcalf > PM <Wil...@kc...> > cc > sno...@li...urceforg > e.net > Subject > Re: [Snort-inline-users] msn > messenger problem > > On Tuesday 06 July 2004 19:51, William Metcalf wrote: > > The default time out for a session is 120 seconds for iptables. If you > > set > > > this in stream4 I would up the amount of memory you allocate for it. As > > far as logging out-of-session packets, there isn't a mechanism in snort > > or > > > snort_inline to do this, if you are troubleshooting, you can enable the > > stream4 debug. This can be accomplished compiling with --enable-debug > > and > > > then export SNORT_DEBUG=8192 prior to starting snort_inline. > > Hmm, i thought the default tcp session timeout in iptables was something > like > 5 days... > > from my /proc/net/ip_conntrack: > > tcp 6 431942 ESTABLISHED src=192.168.0.167 dst=207.46.107.7 > sport=35693 > dport=1863 src=207.46.107.7 dst=192.168.0.167 sport=1863 dport=35693 > [ASSURED] use=1 > > The counter of 431942 is the session timeout right? > > Okay, i set the timeout to 120 seconds now, so now i have increase the > memcap? > Can you give a rule of thumb for how high it should be... (for x number of > connections, you need a memcap of y bytes) > > Wouldn't it be an interesting feature to be able to log those packets for > snort_inline (guess not for snort), because if snort_inline makes dissions > as > a firewall, thus dropping packets, i want to know why... > > If you run a firewall and connections are dropped (thus the users are > complaining to you), but you don't know why i think it's an administrators > nightmare... > > Would that difficult to implement, i'm a moderate c-programmer, so i could > give it a shot... > > (would you (or anyone else) even be interested in such a feature?) > > Regards, > Victor > > > Regards, > > > > Will > > > > > > > > Victor Julien > > <vi...@nk...> > > To > > > 07/06/2004 11:41 > > sno...@li...urceforg > > > AM e.net > > cc > > > William Metcalf > > <Wil...@kc...> > > Subject > > > Re: [Snort-inline-users] msn > > messenger problem > > > > On Tuesday 06 July 2004 18:16, William Metcalf wrote: > > > Increasing the time-out should be fine, gaim must implement it's MSN > > > function differently than the windows messenger client. If no data is > > > received for x seconds in a TCP conversation the session is pruned in > > > stream4, this is the same way that a stateful firewall works. If data > > is > > > > received out-of session it is dropped, unless it is trying to > > initialize > > > a > > > > > new session i.e. a packet with the SYN flag set. > > > > Okay, so the only drawback is that stream4 will take some more memory > > because > > of this? > > > > Is this the same type of timeout that iptables uses in the state table? > > Iptables uses timeouts of days, not seconds if i recall correctly. > > > > Final question: why doesn't snort log the packets that are out of > > session? > > > Or: > > how can i make snort log them? > > > > Thanks for your help! > > > > Regards, > > Victor > > > > > Regards, > > > > > > Will > > > > > > > > > > > > Victor Julien > > > <vi...@nk...> > > > > To > > > > > 07/06/2004 10:55 > > > > sno...@li...urceforg > > > > > AM e.net > > > > cc > > > > > William Metcalf > > > <Wil...@kc...> > > > > Subject > > > > > Re: [Snort-inline-users] msn > > > messenger problem > > > > > > On Tuesday 06 July 2004 15:34, William Metcalf wrote: > > > > That's odd, try disabling the flow preproc as it is not yet supported > > > > in > > > > > > snort_inline. I don't have any problem with msn and the stream4 > > > > preproc. > > > > > The flow preprocessor was not the problem. I disabled it, but the > > > connection > > > was still lost after some time. > > > > > > Increasing the timeout for the stream4 prepoc from the default 30 sec > > to > > > 60 > > > > > sec seems to be the solution. > > > > > > Can you explain to me what this does? Can it be a security risk? DoS? > > > > > > Regards, > > > Victor > > > > > > > Regards, > > > > > > > > Will > > > > > > > > > > > > > > > > Victor Julien > > > > <vi...@nk...> > > > > Sent by: > > > > > > To > > > > > > > snort-inline-user William Metcalf > > > > s-...@li...u <Wil...@kc...> > > > > rceforge.net > > > > > > cc > > > > > > sno...@li...urceforg > > > > > > > e.net > > > > 07/06/2004 06:39 > > > > > > Subject > > > > > > > AM Re: [Snort-inline-users] msn > > > > messenger problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi William, > > > > > > > > Thanx for your reply. > > > > > > > > On Tuesday 06 July 2004 06:32, you wrote: > > > > > Look through your logs, there are certian rules that detect > > > > > > msn-messenger > > > > > > > > logon attemtps, if you have converted all rules to drop messenger > > > > would > > > > > > > stop working. > > > > > > > > My logs don't show anything about msn messenger. So if snort_inline > > is > > > > > blocking msn in some way, it does so without telling me. I also tried > > > > > > aMsn > > > > > > > and Gaim and the same thing happens. > > > > > > > > I got this when running Gaim in debug mode: > > > > > > > > <snipped entire login procedure> > > > > msn: C: PNG > > > > msn: S: QNG 41 > > > > msn: C: PNG > > > > msn: S: QNG 46 > > > > msn: C: PNG > > > > msn: S: QNG 44 > > > > msn: C: PNG > > > > msn: S: QNG 40 > > > > msn: C: PNG > > > > msn: S: QNG 40 > > > > msn: C: PNG > > > > msn: S: QNG 43 > > > > msn: C: PNG > > > > msn: S: QNG 42 > > > > msn: C: PNG > > > > msn: S: QNG 47 > > > > > > > > I think 'C' is the client. It does some kind of keep-a-live i think. > > > > > > After > > > > > > > a > > > > 'PNG' (ping?) the server responds everytime. Then without notice or > > > > message, > > > > the server stops responding, and finally disconnects. > > > > > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > account: Disconnecting account 0x8198ae0 > > > > connection: Disconnecting connection 0x82ba848 > > > > server: removing NOP > > > > > > > > I get no message what-so-ever in any log (snort, iptables, syslog). > > > > > > > > Could this have something to do with: > > > > 1. preprocessor flow > > > > 2. preprocessor stream4 > > > > 3. preprocessor stream4_reassemble > > > > > > > > Maybe some internal time-out in snort_inline? > > > > > > > > Note that i don't have this problem when only iptables handles msn > > > > (with > > > > > -j > > > > > > > ACCEPT). > > > > > > > > Regards, > > > > Victor > > > > > > > > > Regards, > > > > > > > > > > Will > > > > > > > > > > packescrubber:/etc/snort# grep MSN * > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > > message"; flow:established; content:"MSG "; depth:4; > > > > > content:"Content-Type|3A|"; nocase; content:"text/plain"; > > distance:1; > > > > > > classtype:policy-violation; sid:540; rev:11;) > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > file > > > > > > > > > transfer request"; flow:established; content:"MSG "; depth:4; > > > > > content:"Content-Type|3A|"; distance:0; nocase; > > > > > content:"text/x-msmsgsinvite"; distance:0; nocase; > > > > > content:"Application-Name|3A|"; content:"File Transfer"; > > distance:0; > > > > > > nocase; classtype:policy-violation; sid:1986; rev:4;) > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > file > > > > > > > > > transfer accept"; flow:established; content:"MSG "; depth:4; > > > > > content:"Content-Type|3A|"; nocase; content:"text/x-msmsgsinvite"; > > > > > distance:0; content:"Invitation-Command|3A|"; content:"ACCEPT"; > > > > > > > > distance:1; > > > > > > > > > classtype:policy-violation; sid:1988; rev:3;) > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > file > > > > > > > > > transfer reject"; flow:established; content:"MSG "; depth:4; > > > > > content:"Content-Type|3A|"; nocase; content:"text/x-msmsgsinvite"; > > > > > distance:0; content:"Invitation-Command|3A|"; content:"CANCEL"; > > > > > > > > distance:0; > > > > > > > > > content:"Cancel-Code|3A|"; nocase; content:"REJECT"; distance:0; > > > > > > nocase; > > > > > > > > classtype:policy-violation; sid:1989; rev:4;) > > > > > chat.rules:drop tcp $HOME_NET any -> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > user > > > > > > > > > search"; flow:to_server,established; content:"CAL "; depth:4; > > nocase; > > > > > > classtype:policy-violation; sid:1990; rev:1;) > > > > > chat.rules:drop tcp $HOME_NET any -> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > > login attempt"; flow:to_server,established; content:"USR "; > > depth:4; > > > > > > nocase; content:" TWN "; distance:1; nocase; > > > > > > classtype:policy-violation; > > > > > > > > sid:1991; rev:1;) > > > > > sid-msg.map:540 || CHAT MSN message > > > > > sid-msg.map:1986 || CHAT MSN file transfer request > > > > > sid-msg.map:1988 || CHAT MSN file transfer accept > > > > > sid-msg.map:1989 || CHAT MSN file transfer reject > > > > > sid-msg.map:1990 || CHAT MSN user search > > > > > sid-msg.map:1991 || CHAT MSN login attempt > > > > > > > > > > > > > > > > > > > > Victor Julien > > > > > <vi...@nk...> > > > > > Sent by: > > > > > > > > To > > > > > > > > > snort-inline-user > > > > > > > > sno...@li...urceforg > > > > > > > > > s-...@li...u e.net > > > > > rceforge.net > > > > > > > > cc > > > > > > > > > > > > Subject > > > > > > > > > 07/01/2004 02:00 [Snort-inline-users] msn > > > > > > messenger > > > > > > > > PM problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I 'm testing snort_inline to filter my outgoing traffic. Http, > > ftp, > > > > pop3 > > > > > > > > work > > > > > fine so far, however msn-messenger does not. I'm using Kopete (kde > > > > > > 3.2.2, > > > > > > > > debian-testing) with msn-plugin. The plugin just dies after some 5 > > > > > > > > minutes > > > > > > > > > or > > > > > so. This does not happen when msn works just with iptables. Is > > there > > > > any > > > > > > > > known problem with msn and snort_inline? > > > > > > > > > > Regards, > > > > > Victor > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > > digital self defense, top technical experts, no vendor pitches, > > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > > _______________________________________________ > > > > > Snort-inline-users mailing list > > > > > Sno...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > digital self defense, top technical experts, no vendor pitches, > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > _______________________________________________ > > > > Snort-inline-users mailing list > > > > Sno...@li... > > > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users |
|
From: Brian J. <te...@ja...> - 2004-07-07 16:18:12
|
>> Two questions, firstly how does one extract the binary from the mysql.gz >> file, my ususual efforts with tar did not work so I moved the file to >> Windows and did it Winzip? > >simply use gunzip on the file. It is not tar'ed. > >i.e. gunzip mysql.gz Thanks for that. I am now better educated > >> Secondly when I try to run the extracted ./snort_inline-2.1.3b-mysql file I >> get a segmentation fault. I have tried this on three Linux boxes one of >> which was a current snort sensor box using mysql(Fedora Core 1)? >> Any clues anyone? > >How are you running it? What is your snort_inline.conf? I am not even getting that far, it fails with the 'Segmentation fault' when I run snort_inline with no configuration file but just '-V'. My steps are:- 1) Download and check MD5 - All checks out Ok 2) gunzip the snort_inline-2.1.3b-mysql.gz file the resulting file size is 3410313 3) chmod the result to add execute capability 4) ./snort_inline-2.1.3b-mysql -V which gives the Segmentation fault. > >Rob regards, Brian |
|
From: Victor J. <vi...@nk...> - 2004-07-07 16:14:15
|
Hey Will, I was thinking about implementing this myself, however i will be on a holiday the next two weeks, so i guess i will be to late by then ;-) However i was wondering how you want to implement this. Which log facility do you plan to use? What information do you plan to log? date- time, src_ip: src_port -> dst_ip:dst_port, tcp flags, action? Something like this? Regards, Victor On Wednesday 07 July 2004 16:49, William Metcalf wrote: > This is correct, if stream4 does not have a session for packet p and the > SYN flag is not set it will be dropped. I'll try to add in the log_drops > option to stream4 if I have time, but it might be a couple of days. > > Regards, > > Will > > > > Victor Julien > <vi...@nk...> > Sent by: To > snort-inline-user "Geffrey Velasquez [MINAG]" > s-...@li...u <gve...@mi...> > rceforge.net cc > sno...@li...urceforg > e.net > 07/07/2004 09:27 Subject > AM Re: [Snort-inline-users] logging of > timed out connections in stream4 > > > > > > > > > > > On Wednesday 07 July 2004 16:17, Geffrey Velasquez [MINAG] wrote: > > <snip> > > > > Why? The snort_inline-fast file normally logs the reasons for > > > dropping a connection... > > > > I'm using ACID, this log could be stored in the ACID DB? I prefer a > > simple > > > log file and alerts in the ACID DB... but maybe we could change that or > > maybe I'm wrong... > > Well, when looking at the code, i came under the impression that the > timeout > is not the only trigger for dropping the connection at this point in the > code. 'Connections' which don't start with a syn bit (aka scans) could also > > match... but i'm not sure about this, so maybe the author of it (Rob?) > could > clear this issue up? > > > > > > My idea would be to make the logging an option for the stream4 > > > > > preproc, with the default being not logging. > > > > > > > > > > Something like this: > > > > > preprocessor stream4: disable_evasion_alerts, detect_scans, timeout > > > > > 120, log_drops > > <snip> > > Regards, > Victor > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Snort-inline-users mailing list > Sno...@li... > https://lists.sourceforge.net/lists/listinfo/snort-inline-users |
|
From: Victor J. <vi...@nk...> - 2004-07-07 16:03:32
|
On Wednesday 07 July 2004 17:45, Geffrey Vel=E1squez wrote: > Victor Julien escribi=F3: > >On Wednesday 07 July 2004 17:07, Geffrey Vel=E1squez wrote: > > > ><snip> > > > >>>>Victor, we are using the stateful inspection with Netfilter/Iptables, > >>>>and maybe we could disable the stream4 preprocessor, what is your > >>>>opinion. Maybe we could do some test with tools like stick and inject > >>>>packets in both scenarios, with stream4 enabled and disabled and rely > >>>> on Netfilter stateful inspection... > >>> > >>>Ehhhh...... Now i'm confused about the use of the stream4 > >>> preprocessor... is it 'only' a stateful inspection engine? I guess in > >>> that case we wouldn't need it when using Netfilter stateful > >>> inspection... or does it have other advantages (oh well, i guess you > >>> want to test just that!) > >>> > >>>Will all rules work as they should when the stream4 preproc is disable= d, > >>>and we rely on iptables for the stateful inspection? > >>> > >>>Victor > >> > >>Stream4 for session tracking, scan detections and other anomalyes. > > > >I was under the impression (correct me if i'm wrong) that the stream4 > > preproc is also used to reconstruct a connection so we can inspect data > > that is spread over multiple packets and fragments. How would this work > > when using the iptables stateful inspection? Or am i missing the point > > here? > > > >Regards, > >Victor > > stream4 does session reassenbly (reassenbles the tcp stream) also frag2 > does packet reassenbly but it is disable in the default > snort_inline.conf : > > # Done by IPTables. Iptables assembles fragments when we use connection > # tracking; therefore, we don't have to use frag2 > # preprocessor frag2 > > The answer is above, and... maybe we must evaluate if we could avoid > stream4 Based on what William Metcalf just wrote, i think we can't. It would mean w= e=20 could miss alerts, which would mean less security... > > Geffrey > > >------------------------------------------------------- > >This SF.Net email sponsored by Black Hat Briefings & Training. > >Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > >digital self defense, top technical experts, no vendor pitches, > >unmatched networking opportunities. Visit www.blackhat.com > >_______________________________________________ > >Snort-inline-users mailing list > >Sno...@li... > >https://lists.sourceforge.net/lists/listinfo/snort-inline-users |
|
From: Victor J. <vi...@nk...> - 2004-07-07 16:01:49
|
On Wednesday 07 July 2004 17:40, William Metcalf wrote: > iptables handles fragment reassembly, the reassembly portion of stream4 > will not work without stream4 enabled. So yes you would miss alerts, need > to look at reassembly and see if they have changed the way that the uber > packet is constructed. Thanks for the reminder : - ) So basicly, for optimal security, it's not a question wether to use stream4= &=20 stream4_reassebly or not. For optimal security we want to use it. Correct? > > Regards, > > Will > > > > Victor Julien > <vi...@nk...> > Sent by: To > snort-inline-user Geffrey Vel=E1squez > s-...@li...u <gve...@mi...> > rceforge.net cc > sno...@li...urceforg > e.net > 07/07/2004 10:16 Subject > AM Re: [Snort-inline-users] logging of > timed out connections in stream4 > > > > > > > > > > > On Wednesday 07 July 2004 17:07, Geffrey Vel=E1squez wrote: > > <snip> > > > >>Victor, we are using the stateful inspection with Netfilter/Iptables, > > >>and maybe we could disable the stream4 preprocessor, what is your > > >>opinion. Maybe we could do some test with tools like stick and inject > > >>packets in both scenarios, with stream4 enabled and disabled and rely > > on > > > >>Netfilter stateful inspection... > > > > > >Ehhhh...... Now i'm confused about the use of the stream4 > > preprocessor... > > > > is it 'only' a stateful inspection engine? I guess in that case we > > > wouldn't need it when using Netfilter stateful inspection... or does = it > > > have other advantages (oh well, i guess you want to test just that!) > > > > > >Will all rules work as they should when the stream4 preproc is disable= d, > > > and we rely on iptables for the stateful inspection? > > > > > >Victor > > > > Stream4 for session tracking, scan detections and other anomalyes. > > I was under the impression (correct me if i'm wrong) that the stream4 > preproc > is also used to reconstruct a connection so we can inspect data that is > spread over multiple packets and fragments. How would this work when using > the iptables stateful inspection? Or am i missing the point here? > > Regards, > Victor > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Snort-inline-users mailing list > Sno...@li... > https://lists.sourceforge.net/lists/listinfo/snort-inline-users |
|
From: <gve...@mi...> - 2004-07-07 15:45:33
|
Victor Julien escribió: >On Wednesday 07 July 2004 17:07, Geffrey Velásquez wrote: > ><snip> > > > >>>>Victor, we are using the stateful inspection with Netfilter/Iptables, >>>>and maybe we could disable the stream4 preprocessor, what is your >>>>opinion. Maybe we could do some test with tools like stick and inject >>>>packets in both scenarios, with stream4 enabled and disabled and rely on >>>>Netfilter stateful inspection... >>>> >>>> >>>Ehhhh...... Now i'm confused about the use of the stream4 preprocessor... >>>is it 'only' a stateful inspection engine? I guess in that case we >>>wouldn't need it when using Netfilter stateful inspection... or does it >>>have other advantages (oh well, i guess you want to test just that!) >>> >>>Will all rules work as they should when the stream4 preproc is disabled, >>>and we rely on iptables for the stateful inspection? >>> >>>Victor >>> >>> >>Stream4 for session tracking, scan detections and other anomalyes. >> >> > >I was under the impression (correct me if i'm wrong) that the stream4 preproc >is also used to reconstruct a connection so we can inspect data that is >spread over multiple packets and fragments. How would this work when using >the iptables stateful inspection? Or am i missing the point here? > >Regards, >Victor > > stream4 does session reassenbly (reassenbles the tcp stream) also frag2 does packet reassenbly but it is disable in the default snort_inline.conf : # Done by IPTables. Iptables assembles fragments when we use connection # tracking; therefore, we don't have to use frag2 # preprocessor frag2 The answer is above, and... maybe we must evaluate if we could avoid stream4 Geffrey > > >------------------------------------------------------- >This SF.Net email sponsored by Black Hat Briefings & Training. >Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >digital self defense, top technical experts, no vendor pitches, >unmatched networking opportunities. Visit www.blackhat.com >_______________________________________________ >Snort-inline-users mailing list >Sno...@li... >https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > |
|
From: Victor J. <vi...@nk...> - 2004-07-07 15:17:06
|
On Wednesday 07 July 2004 17:07, Geffrey Vel=E1squez wrote: <snip> > >>Victor, we are using the stateful inspection with Netfilter/Iptables, > >>and maybe we could disable the stream4 preprocessor, what is your > >>opinion. Maybe we could do some test with tools like stick and inject > >>packets in both scenarios, with stream4 enabled and disabled and rely on > >>Netfilter stateful inspection... > > > >Ehhhh...... Now i'm confused about the use of the stream4 preprocessor... > > is it 'only' a stateful inspection engine? I guess in that case we > > wouldn't need it when using Netfilter stateful inspection... or does it > > have other advantages (oh well, i guess you want to test just that!) > > > >Will all rules work as they should when the stream4 preproc is disabled, > > and we rely on iptables for the stateful inspection? > > > >Victor > > Stream4 for session tracking, scan detections and other anomalyes. I was under the impression (correct me if i'm wrong) that the stream4 prepr= oc=20 is also used to reconstruct a connection so we can inspect data that is=20 spread over multiple packets and fragments. How would this work when using= =20 the iptables stateful inspection? Or am i missing the point here? Regards, Victor |
|
From: Victor J. <vi...@nk...> - 2004-07-07 14:47:28
|
On Wednesday 07 July 2004 16:38, Geffrey Vel=E1squez wrote: > Victor Julien escribi=F3: > >On Wednesday 07 July 2004 16:17, Geffrey Velasquez [MINAG] wrote: > > > ><snip> > > > >>>Why? The snort_inline-fast file normally logs the reasons for > >>>dropping a connection... > >> > >>I'm using ACID, this log could be stored in the ACID DB? I prefer a > >> simple log file and alerts in the ACID DB... but maybe we could change > >> that or maybe I'm wrong... > > > >Well, when looking at the code, i came under the impression that the > > timeout is not the only trigger for dropping the connection at this poi= nt > > in the code. 'Connections' which don't start with a syn bit (aka scans) > > could also match... but i'm not sure about this, so maybe the author of > > it (Rob?) could clear this issue up? > > Victor, we are using the stateful inspection with Netfilter/Iptables, > and maybe we could disable the stream4 preprocessor, what is your > opinion. Maybe we could do some test with tools like stick and inject > packets in both scenarios, with stream4 enabled and disabled and rely on > Netfilter stateful inspection... Ehhhh...... Now i'm confused about the use of the stream4 preprocessor... i= s=20 it 'only' a stateful inspection engine? I guess in that case we wouldn't ne= ed=20 it when using Netfilter stateful inspection... or does it have other=20 advantages (oh well, i guess you want to test just that!) Will all rules work as they should when the stream4 preproc is disabled, an= d=20 we rely on iptables for the stateful inspection? Victor > > >>>>>My idea would be to make the logging an option for the stream4 > >>>>>preproc, with the default being not logging. > >>>>> > >>>>>Something like this: > >>>>>preprocessor stream4: disable_evasion_alerts, detect_scans, timeout > >>>>>120, log_drops > > > ><snip> > > > >Regards, > >Victor > > Regards. > Geffrey |
|
From: Victor J. <vi...@nk...> - 2004-07-07 14:27:51
|
On Wednesday 07 July 2004 16:17, Geffrey Velasquez [MINAG] wrote: <snip> > > > > Why? The snort_inline-fast file normally logs the reasons for > > dropping a connection... > > I'm using ACID, this log could be stored in the ACID DB? I prefer a simple > log file and alerts in the ACID DB... but maybe we could change that or > maybe I'm wrong... Well, when looking at the code, i came under the impression that the timeout is not the only trigger for dropping the connection at this point in the code. 'Connections' which don't start with a syn bit (aka scans) could also match... but i'm not sure about this, so maybe the author of it (Rob?) could clear this issue up? > > > > > My idea would be to make the logging an option for the stream4 > > > > preproc, with the default being not logging. > > > > > > > > Something like this: > > > > preprocessor stream4: disable_evasion_alerts, detect_scans, timeout > > > > 120, log_drops > > > > <snip> Regards, Victor |
|
From: Geffrey V. [MINAG] <gve...@mi...> - 2004-07-07 14:18:01
|
---------- Original Message ----------- From: Victor Julien <vi...@nk...> To: "Geffrey Velasquez [MINAG]" <gve...@mi...> Cc: sno...@li... Sent: Wed, 7 Jul 2004 16:12:16 +0200 Subject: Re: [Snort-inline-users] logging of timed out connections in stream4 > Hi Geffrey, > > On Wednesday 07 July 2004 16:07, Geffrey Velasquez [MINAG] wrote: > > ---------- Original Message ----------- > > From: Victor Julien <vi...@nk...> > > To: sno...@li... > > Sent: Wed, 7 Jul 2004 14:33:46 +0200 > > Subject: [Snort-inline-users] logging of timed out connections in stream4 > > > > > Hi list, > > > > > > After some discussions earlier on this list i came to the conclusion > > > that it would be nice to log dropped connections in the stream4 > > > preprocessor that are dropped because of timeouts in the stream4 > > > preprocessor. > > > > > > I noticed myself that if the timeout value for the stream4 > > > preprocessor is too low some services, like msn, won't work > > > correctly. And altough it can be solved by increasing the timeout > > > value i think a firewall should be able to log all drop-decisions. > > > > > > So i looked at the stream4.c from snort_inline 2.1.3a and noticed > > > that if a session is not found ((ssn = GetSession) == NULL), and the > > > packet is not a syn-packet, the packet is dropped using InlineDrop() > > > on line 1759. So i guess i could add some (optional) logging > > > function right there, correct? > > > > > > Any ideas how this should be logged? In sessions.log? Or syslog? Or > > > snort_inline-fast? Or... > > > > Could be in a file called sessions.log, not in the snort_inline-fast. > > Why? The snort_inline-fast file normally logs the reasons for > dropping a connection... > I'm using ACID, this log could be stored in the ACID DB? I prefer a simple log file and alerts in the ACID DB... but maybe we could change that or maybe I'm wrong... > > > > > My idea would be to make the logging an option for the stream4 > > > preproc, with the default being not logging. > > > > > > Something like this: > > > preprocessor stream4: disable_evasion_alerts, detect_scans, timeout > > > 120, log_drops > > > > > > Regards, > > > Victor > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > digital self defense, top technical experts, no vendor pitches, > > > unmatched networking opportunities. Visit www.blackhat.com > > > _______________________________________________ > > > Snort-inline-users mailing list > > > Sno...@li... > > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > > > ------- End of Original Message ------- > > > > > > Regards, > > Geffrey > > Regards, > Victor ------- End of Original Message ------- |
133 messages has been excluded from this view by a project administrator.
