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-07 14:12:35
|
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... > > > 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 |
|
From: Victor J. <vi...@nk...> - 2004-07-07 12:33:55
|
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... 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 |
|
From: Victor J. <vi...@nk...> - 2004-07-07 12:11:22
|
On Tuesday 06 July 2004 23:00, William Metcalf wrote: > 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) > > The default is 8mb for every 30 seconds, I actually think that this is a > little low snort_inline and snort are no longer lightweight. I set mine to > 32mb and left the default timeout to 30 seconds. Okay, so i guess the difference with iptables is that snort_inline also stores the payload in memory right? I assume the memcap usage is also determined by the number of connections. Is there a maximum? Should more connections mean a higher memcap setting? Regards, 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: Geffrey V. [MINAG] <gve...@mi...> - 2004-07-06 20:06:04
|
> 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) What about memcap? is possible to display the connection state table of stream4? Regards, Geffrey |
|
From: Victor J. <vi...@nk...> - 2004-07-06 18:08:40
|
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: Victor J. <vi...@nk...> - 2004-07-06 16:41:51
|
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: Victor J. <vi...@nk...> - 2004-07-06 15:56:16
|
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: Rob M. <ro...@ho...> - 2004-07-06 12:45:35
|
> 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 > 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? Rob |
|
From: Victor J. <vi...@nk...> - 2004-07-06 11:39:56
|
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 |
|
From: Brian J. <te...@ja...> - 2004-07-06 10:59:22
|
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? 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? regards, Brian >List, > I uploaded 2.1.3b which should fix the compilation problems some of >you were having. > I've also added two statically compiled binaries: standard, >with-mysql. > > >Hopes this helps. > >Rob ------------------------------------------------------- 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: Cesar F. F. <ces...@t-...> - 2004-07-05 14:09:05
|
help sno...@li... escribi=F3 el 03/07/2004= 10:21:42 p.m.: > Send Snort-inline-users mailing list submissions to > sno...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > or, via email, send a message with subject or body 'help' to > sno...@li... > > You can reach the person managing the list at > sno...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Snort-inline-users digest..." > > > Today's Topics: > > 1. released 2.1.3b (Rob McMillen) > > --__--__-- > > Message: 1 > Date: Sat, 3 Jul 2004 09:22:34 -0500 (EST) > From: Rob McMillen <ro...@ho...> > Reply-To: Rob McMillen <ro...@ho...> > To: sno...@li... > Subject: [Snort-inline-users] released 2.1.3b > > List, > I uploaded 2.1.3b which should fix the compilation problems some = of > you were having. > I've also added two statically compiled binaries: standard, > with-mysql. > > > Hopes this helps. > > Rob > > > > --__--__-- > > _______________________________________________ > Snort-inline-users mailing list > Sno...@li... > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > > End of Snort-inline-users Digest > ForwardSourceID:NT0001476E = |
|
From: Rob M. <ro...@ho...> - 2004-07-03 13:35:14
|
List,
I uploaded 2.1.3b which should fix the compilation problems some of
you were having.
I've also added two statically compiled binaries: standard,
with-mysql.
Hopes this helps.
Rob
|
|
From: James A. P. <ja...@pc...> - 2004-07-02 18:54:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Victor Julien wrote: | On Friday 02 July 2004 16:37, James A. Pattie wrote: | |>Victor Julien wrote: |>| On Thursday 01 July 2004 21:56, Geffrey Velasquez [MINAG] wrote: |>|>Excelent! your script always have on top the ESTABLISHED and RELATED |>|>states. I would like to see your frontend. |> |>I don't know what happend the last time, but I was letting you guys know |>about my iptables web frontend for the PCXFirewall project that supports |>snort-inline. It isn't as finegrained on the ESTABLISHED,RELATED -j QUEUE |>code, but you can limit what services initially are forced to -j QUEUE. |> |>you can get it at http://pcxfirewall.sf.net/ | | | Do you support something special from snort-inline or just the QUEUE target | (like me)? It would be cool to manage the snort-rules from the same tool as | the iptables rules, but i think that's fairly complex... I just support the QUEUE target and I have flags to know I'm in a bridged scenario. | | Also, how do you handle the snort_inline logs? My tool converts the iptables | logs from syslog into a human-readable file, i'm thinking about integrating | the snort_inline-fast file with that. However, is there a way to see what the | action was in the snort-inline log? (without changing all individual rules) I usually run an instance of snort logging to db and then access via acid_lab interface. Though it will be nice to start using the snort-inline w/ db support so I don't have to keep updating multiple rule sets, etc. and can get rid of the log file per-se. | | Something like this: | 06/27-11:26:58.883422 [**] [1:721:7] VIRUS OUTBOUND bad file attachment [**] | [Classification: A suspicious filename was detected] [Priority: 2] {TCP} | 192.168.0.167:33581 -> 192.168.0.102:25 [snort-inline action: DROP] | | That would be handy. yes that would be nice to see what action it took. - -- James A. Pattie ja...@pc... Linux -- SysAdmin / Programmer Xperience, Inc. http://www.pcxperience.com/ http://www.xperienceinc.com/ http://www.pcxperience.org/ GPG Key Available at http://www.pcxperience.com/gpgkeys/james.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA5a90tUXjwPIRLVERArhfAJ4tjLB3ZBhJUIRHHP1h0DwZuBtdSwCgmQei 6uwGuCrzDUTt6QKNOuBRfjE= =gLJq -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. |
|
From: Victor J. <vi...@nk...> - 2004-07-02 15:24:19
|
On Friday 02 July 2004 16:37, James A. Pattie wrote: > Victor Julien wrote: > | On Thursday 01 July 2004 21:56, Geffrey Velasquez [MINAG] wrote: > |>Excelent! your script always have on top the ESTABLISHED and RELATED > |>states. I would like to see your frontend. > > I don't know what happend the last time, but I was letting you guys know > about my iptables web frontend for the PCXFirewall project that supports > snort-inline. It isn't as finegrained on the ESTABLISHED,RELATED -j QUEUE > code, but you can limit what services initially are forced to -j QUEUE. > > you can get it at http://pcxfirewall.sf.net/ Do you support something special from snort-inline or just the QUEUE target (like me)? It would be cool to manage the snort-rules from the same tool as the iptables rules, but i think that's fairly complex... Also, how do you handle the snort_inline logs? My tool converts the iptables logs from syslog into a human-readable file, i'm thinking about integrating the snort_inline-fast file with that. However, is there a way to see what the action was in the snort-inline log? (without changing all individual rules) Something like this: 06/27-11:26:58.883422 [**] [1:721:7] VIRUS OUTBOUND bad file attachment [**] [Classification: A suspicious filename was detected] [Priority: 2] {TCP} 192.168.0.167:33581 -> 192.168.0.102:25 [snort-inline action: DROP] That would be handy. Regards, Victor |
|
From: James A. P. <ja...@pc...> - 2004-07-02 14:37:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Victor Julien wrote: | On Thursday 01 July 2004 21:56, Geffrey Velasquez [MINAG] wrote: | |>Excelent! your script always have on top the ESTABLISHED and RELATED |>states. I would like to see your frontend. | I don't know what happend the last time, but I was letting you guys know about my iptables web frontend for the PCXFirewall project that supports snort-inline. It isn't as finegrained on the ESTABLISHED,RELATED -j QUEUE code, but you can limit what services initially are forced to -j QUEUE. you can get it at http://pcxfirewall.sf.net/ - -- James A. Pattie ja...@pc... Linux -- SysAdmin / Programmer Xperience, Inc. http://www.pcxperience.com/ http://www.xperienceinc.com/ http://www.pcxperience.org/ GPG Key Available at http://www.pcxperience.com/gpgkeys/james.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA5XMetUXjwPIRLVERAmznAJ9Q2NHkVOVmHy2ypKhL2J1rtzahvACg7ZKn SLBqmeLQmXKlP1PaLBHZ0GM= =+7AN -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. |
|
From: Victor J. <vi...@nk...> - 2004-07-02 12:44:15
|
On Thursday 01 July 2004 22:28, Geffrey Velasquez [MINAG] wrote: > > On Thursday 01 July 2004 21:56, Geffrey Velasquez [MINAG] wrote: > > > Excelent! your script always have on top the ESTABLISHED and RELATED > > > states. I would like to see your frontend. > > > > It's not yet released, i'm in the process of registering a project > > with sourceforge. I think after my holiday i release it... 1 month > > or so? > > Excellent, I need to do something like this... (web based) maybe I could > help or grab some code from your proyect (if it is GPLd). It's not webbased... it is basicly split in two... a middle piece which=20 converts humanly readably rules to iptables rules and a frontend in ncurses= =2E=20 I am now writing a networkserver and a friend is writing a graphical =20 java-client, so it can be administered from windoze... > > > > Another question (I'm new), I was testing with an Apache behind an > > > Iptables/Snort Inline Firewall, only with web-*.rules activated and > > > trigger some cgi attacks, the attempt is droped, but the Apache web > > > server dont knows that the connection was dropped and maybe could lead > > > in DOS attack. How are you considering this case? > > > > I' not sure if the entire connection is dropped or just the > > dangerous packets... (i'm also new to snort_inline ;-) Maybe you > > could use reject for this? > > Only bad packets, it seems, but is still possible a DOS attack, for examp= le > worms like the well remembered NIMDA and RED CODE. > > Reading the documentation, snort_inline: drop, reject and sdrop tells > iptables to DROP the packet, only reset send TCP reset (maybe using > flexresp)... but I dont test it yet. > Also the conection must be releases form the connection state table under > DOS attacks... I think that if snort_inline tells iptables that it has dropped or rejected= a=20 connection it will be removed from the state table as well. But 'm not=20 sure... Regards, Victor > > > Regards, > > Victor > > > > > Regards, > > > Geffrey Vel=E1squez > > > > > > > > > ---------- Original Message ----------- > > > From: Victor Julien <vi...@nk...> > > > To: sno...@li... > > > Sent: Thu, 1 Jul 2004 21:33:25 +0200 > > > Subject: Re: [Snort-inline-users] using snort_inline for selected > > > traffic only (was: help with setting up iptables for use with > > > snort_inline) > > > > > > > Good question. Not much i think. :-) > > > > > > > > The reason i do it like this, is that the iptables frontend i'm > > > > writing creates the ESTABLISHED,RELATED first, and then based on a > > > > rulesfile the specific individual rules. So then i have only two > > > > RELATED,ESTABLISHED rules per chain (on top of course) for optimal > > > > performance. The frontend then dynamicly creates mangle, nat and > > > > filterrules. > > > > > > > > The way you do it i would have to create an ESTABLISHED,RELATED for > > > > every service/rule i want to QUEUE. > > > > > > > > But for this example you are absolutely right! > > > > > > > > Regards, > > > > Victor > > > > > > > > Updated example: > > > > > > > > Question: I want to handle only selected traffic with snort_inline > > > > > > > > Answer: > > > > Say you want only stmp traffic to be handled by snort_inline, but > > > > not pop3. > > > > > > > > # the ESTABLISHED,RELATED for smtp > > > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp - > > > > -dport 25 -j QUEUE > > > > # the ESTABLISHED,RELATED for the rest > > > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > > > > > # the initial rules > > > > iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > > > > iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCE= PT > > > > > > > > Question: I can now handle selected traffic, but i'm having troubles > > > > with protocols witch use protocol handlers in iptables, like ftp. > > > > > > > > Answer: for this you need the 'helper' module. Say you want only ftp > > > > traffic to be handled by snort_inline, but not http. > > > > > > > > # the ESTABLISHED,RELATED for the helper ftp > > > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m helper = =2D- > > > > helper "ftp" -j QUEUE > > > > # the ESTABLISHED,RELATED for ftp connection on port 21 > > > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp -- > > > > dport 21 -j QUEUE > > > > # the ESTABLISHED,RELATED for the rest > > > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > > > > > iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j QUEUE > > > > iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT > > > > > > > > The difference here is helper module which makes sure that the > > > > connections that are handled by the ftp conntrack helper are also > > > > send to the queue. > > > > > > > > On Thursday 01 July 2004 21:14, Geffrey Velasquez [MINAG] wrote: > > > > > Hi Victor, and what is the difference with this?: > > > > > > > > > > 1. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp > > > > > --dport 25 -j QUEUE > > > > > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j > > > > > ACCEPT 3. iptables -A FORWARD -p tcp --dport 25 -m state --state > > > > > NEW -j QUEUE 4. iptables -A FORWARD -p tcp --dport 110 -m state > > > > > --state NEW -j ACCEP > > > > > > > > > > > > > > > Saludos, > > > > > Geffrey Vel=E1squez > > > > > Cel.: 9722-2705 > > > > > > > > > > ---------- Original Message ----------- > > > > > From: Victor Julien <vi...@nk...> > > > > > To: sno...@li... > > > > > Sent: Thu, 1 Jul 2004 19:53:28 +0200 > > > > > Subject: [Snort-inline-users] using snort_inline for selected > > > > > traffic only (was: help with setting up iptables for use with > > > > > snort_inline) > > > > > > > > > > > Hi list, > > > > > > > > > > > > I found the answer to my question (with the kind help of Antony > > > > > > Stone of the Netfilter list). I'd like share it with you so > > > > > > others can use it as well. I've written it in the snort_inline > > > > > > faq format, so if you think it's usefull please include it in > > > > > > you're faq! > > > > > > > > > > > > Regards, > > > > > > Victor > > > > > > > > > > > > Question: I want to handle only selected traffic with > > > > > > snort_inline > > > > > > > > > > > > Answer: You can the MARK target in iptables for this. Say you > > > > > > want only stmp traffic to be handled by snort_inline, but not > > > > > > pop3. > > > > > > > > > > > > 1. iptables -t mangle -A FORWARD -p tcp --dport 25 -j MARK > > > > > > --set- mark 0x1 > > > > > > > > > > > > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m > > > > > > mark - -mark 0x1 -j QUEUE > > > > > > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j > > > > > > ACCEPT > > > > > > > > > > > > 4. iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j > > > > > > QUEUE 5. iptables -A FORWARD -p tcp --dport 110 -m state --state > > > > > > NEW -j ACCEPT > > > > > > > > > > > > Pop3 traffic is now first accepted in rule 5, and after that > > > > > > handled by rule > > > > > > 3. > > > > > > > > > > > > The smtp traffic is now first QUEUE'd by rule 4, after that > > > > > > marked in rule 1 so it can be picked up by the 2nd rule. > > > > > > > > > > > > Question: I can now handle selected traffic, but i'm having > > > > > > troubles with protocols witch use protocol handlers in iptables, > > > > > > like ftp. > > > > > > > > > > > > Answer: for this you need the 'helper' module. Say you want only > > > > > > ftp traffic to be handled by snort_inline, but not http. > > > > > > > > > > > > 1. iptables -t mangle -A FORWARD -p tcp --dport 21 -j MARK > > > > > > --set- mark 0x1 > > > > > > 2. iptables -t mangle -A FORWARD -m helper --helper "ftp" -j > > > > > > MARK -- set-mark 0x1 > > > > > > > > > > > > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m > > > > > > mark - -mark 0x1 -j QUEUE > > > > > > 4. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j > > > > > > ACCEPT > > > > > > > > > > > > 5. iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j > > > > > > QUEUE 6. iptables -A FORWARD -p tcp --dport 80 -m state --state > > > > > > NEW -j ACCEPT > > > > > > > > > > > > The difference here is the second rule which makes sure that the > > > > > > connections that are handled by the ftp conntrack helper are al= so > > > > > > send to the queue. > > > > > > > > > > > > ------------------------------------------------------- > > > > > > 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 ------- > > > > > > > > ------------------------------------------------------- > > > > 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 ------- > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > > ------- End of Original Message ------- |
|
From: Victor J. <vi...@nk...> - 2004-07-02 12:33:26
|
On Friday 02 July 2004 01:19, Rob McMillen wrote: > Great! I'll add it to the FAQ. > > Rob Hi Rob, Please make sure that you use the updated rules after my conversation with Geffrey Velasquez. Those rules are much clearer and simpler, i think. It snort_inline meant for this use? I seem to have some troubles with imap and msn. Could that be because i have different iptables rules with the -j QUEUE target? Regards, Victor |
|
From: Kamal A. <kam...@ya...> - 2004-07-02 04:12:54
|
Hi, Is it possible to install snort-inline where one ethernet port is receiving traffic coming in, and the other ethernet port sending filtered traffic inside the VLAN. I would appreciate any hints/suggestions. Thanks, -Kamal. |
|
From: Josh B. <jos...@li...> - 2004-07-02 02:54:27
|
Assuming snort_inline is sitting in between the web server and the nessus server, you need to use: iptables -A FORWARD -j QUEUE The ipnut chain is only for packets destined to the interface of the iptables machine, the forward target is for traffic actually passing through the firewall. Also, make sure you are starting snort_inline with the -Q switch. > Hi friends, I'm new to snort_inline. > > I downloaded the current binary version of snort_inline, I'm using the > configuration files included in the tarball, I converted the alert rules > to > drop rules using the convert.sh script, and I'm using the default > snort_inline.conf > > I loaded the ip_queue module and configure a simple iptables rule: > > iptables -A INPUT -j QUEUE > > In the snort_inline host I have a test web server (apache) and I run a > nessus > scan against it, the snort logs show the attacks, but it seems not to be > dropped becauseare also present in the apache logs. > What could be wrong? the rules files were changed by drop instead of alert > and > all the variables are configured as "any". > > Another question? I need to configure the host as a bridge? is it > neccesary? > > > Regards, > 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 > Thanks, Josh Berry, CISSP CTO, VP of Product Development LinkNet-Solutions 469-831-8543 jos...@li... |
|
From: James A. P. <ja...@pc...> - 2004-07-01 23:18:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Geffrey Velasquez [MINAG] wrote: | Excelent! your script always have on top the ESTABLISHED and RELATED states. I | would like to see your frontend. | for another IPTables web frontend that supports snort-inline you might want to checkout the PCXFirewall project at http://pcxfirewall.sf.net/ I don't support as fine grained control on the ESTABLISHED,RELATED -j QUEUE, but you can limit what paths are forced to go through the QUEUE initially. As long as snort-inline doesn't have a rule that will drop your traffic it won't harm it to go through the QUEUE, it just might not be as fast though. :) - -- James A. Pattie ja...@pc... Linux -- SysAdmin / Programmer Xperience, Inc. http://www.pcxperience.com/ http://www.xperienceinc.com/ http://www.pcxperience.org/ GPG Key Available at http://www.pcxperience.com/gpgkeys/james.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA5JustUXjwPIRLVERAuEyAJ42/DM1JVXpYOEuUxXUYafH1It8cACghg/P ZxENsOwpumf1d3yKtZYcg5Y= =U3s2 -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. |
|
From: Rob M. <ro...@ho...> - 2004-07-01 22:31:54
|
Great! I'll add it to the FAQ. Rob On Thu, 1 Jul 2004, Victor Julien wrote: > Date: Thu, 1 Jul 2004 19:53:28 +0200 > From: Victor Julien <vi...@nk...> > To: sno...@li... > Subject: [Snort-inline-users] using snort_inline for selected traffic > only (was: help with setting up iptables for use with snort_inline) >=20 > Hi list, >=20 > I found the answer to my question (with the kind help of Antony Stone of = the=20 > Netfilter list). I'd like share it with you so others can use it as well.= =20 > I've written it in the snort_inline faq format, so if you think it's usef= ull=20 > please include it in you're faq! >=20 > Regards, > Victor >=20 > Question: I want to handle only selected traffic with snort_inline >=20 > Answer: You can the MARK target in iptables for this. Say you want only s= tmp=20 > traffic to be handled by snort_inline, but not pop3. >=20 > 1. iptables -t mangle -A FORWARD =A0-p tcp --dport 25 -j MARK --set-mark = 0x1 >=20 > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m mark --mar= k 0x1=20 > -j QUEUE > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT >=20 > 4. iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > 5. iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCEPT >=20 > Pop3 traffic is now first accepted in rule 5, and after that handled by r= ule=20 > 3. >=20 > The smtp traffic is now first QUEUE'd by rule 4, after that marked in rul= e 1=20 > so it can be picked up by the 2nd rule. >=20 >=20 > Question: I can now handle selected traffic, but i'm having troubles with= =20 > protocols witch use protocol handlers in iptables, like ftp. >=20 > Answer: for this you need the 'helper' module. Say you want only ftp traf= fic=20 > to be handled by snort_inline, but not http. >=20 > 1. iptables -t mangle -A FORWARD =A0-p tcp --dport 21 -j MARK --set-mark = 0x1 > 2. iptables -t mangle -A FORWARD =A0-m helper --helper "ftp" -j MARK --se= t-mark=20 > 0x1 >=20 > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m mark --mar= k 0x1=20 > -j QUEUE > 4. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT >=20 > 5. iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j QUEUE > 6. iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT >=20 > The difference here is the second rule which makes sure that the connecti= ons=20 > that are handled by the ftp conntrack helper are also send to the queue. >=20 >=20 > ------------------------------------------------------- > 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 >=20 |
|
From: Geffrey V. [MINAG] <gve...@mi...> - 2004-07-01 20:29:19
|
> On Thursday 01 July 2004 21:56, Geffrey Velasquez [MINAG] wrote: > > Excelent! your script always have on top the ESTABLISHED and RELATED > > states. I would like to see your frontend. > > It's not yet released, i'm in the process of registering a project > with sourceforge. I think after my holiday i release it... 1 month > or so? Excellent, I need to do something like this... (web based) maybe I could help or grab some code from your proyect (if it is GPLd). > > Another question (I'm new), I was testing with an Apache behind an > > Iptables/Snort Inline Firewall, only with web-*.rules activated and trigger > > some cgi attacks, the attempt is droped, but the Apache web server dont > > knows that the connection was dropped and maybe could lead in DOS attack. > > How are you considering this case? > > I' not sure if the entire connection is dropped or just the > dangerous packets... (i'm also new to snort_inline ;-) Maybe you > could use reject for this? Only bad packets, it seems, but is still possible a DOS attack, for example worms like the well remembered NIMDA and RED CODE. Reading the documentation, snort_inline: drop, reject and sdrop tells iptables to DROP the packet, only reset send TCP reset (maybe using flexresp)... but I dont test it yet. Also the conection must be releases form the connection state table under DOS attacks... > Regards, > Victor > > > > > > > > > Regards, > > Geffrey Velásquez > > > > > > ---------- Original Message ----------- > > From: Victor Julien <vi...@nk...> > > To: sno...@li... > > Sent: Thu, 1 Jul 2004 21:33:25 +0200 > > Subject: Re: [Snort-inline-users] using snort_inline for selected traffic > > only (was: help with setting up iptables for use with snort_inline) > > > > > Good question. Not much i think. :-) > > > > > > The reason i do it like this, is that the iptables frontend i'm > > > writing creates the ESTABLISHED,RELATED first, and then based on a > > > rulesfile the specific individual rules. So then i have only two > > > RELATED,ESTABLISHED rules per chain (on top of course) for optimal > > > performance. The frontend then dynamicly creates mangle, nat and > > > filterrules. > > > > > > The way you do it i would have to create an ESTABLISHED,RELATED for > > > every service/rule i want to QUEUE. > > > > > > But for this example you are absolutely right! > > > > > > Regards, > > > Victor > > > > > > Updated example: > > > > > > Question: I want to handle only selected traffic with snort_inline > > > > > > Answer: > > > Say you want only stmp traffic to be handled by snort_inline, but > > > not pop3. > > > > > > # the ESTABLISHED,RELATED for smtp > > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp - > > > -dport 25 -j QUEUE > > > # the ESTABLISHED,RELATED for the rest > > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > > > # the initial rules > > > iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > > > iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCEPT > > > > > > Question: I can now handle selected traffic, but i'm having troubles > > > with protocols witch use protocol handlers in iptables, like ftp. > > > > > > Answer: for this you need the 'helper' module. Say you want only ftp > > > traffic to be handled by snort_inline, but not http. > > > > > > # the ESTABLISHED,RELATED for the helper ftp > > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m helper -- > > > helper "ftp" -j QUEUE > > > # the ESTABLISHED,RELATED for ftp connection on port 21 > > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp -- > > > dport 21 -j QUEUE > > > # the ESTABLISHED,RELATED for the rest > > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > > > iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j QUEUE > > > iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT > > > > > > The difference here is helper module which makes sure that the > > > connections that are handled by the ftp conntrack helper are also > > > send to the queue. > > > > > > On Thursday 01 July 2004 21:14, Geffrey Velasquez [MINAG] wrote: > > > > Hi Victor, and what is the difference with this?: > > > > > > > > 1. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp > > > > --dport 25 -j QUEUE > > > > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > 3. iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > > > > 4. iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCEP > > > > > > > > > > > > Saludos, > > > > Geffrey Velásquez > > > > Cel.: 9722-2705 > > > > > > > > ---------- Original Message ----------- > > > > From: Victor Julien <vi...@nk...> > > > > To: sno...@li... > > > > Sent: Thu, 1 Jul 2004 19:53:28 +0200 > > > > Subject: [Snort-inline-users] using snort_inline for selected traffic > > > > only (was: help with setting up iptables for use with snort_inline) > > > > > > > > > Hi list, > > > > > > > > > > I found the answer to my question (with the kind help of Antony > > > > > Stone of the Netfilter list). I'd like share it with you so others > > > > > can use it as well. I've written it in the snort_inline faq format, > > > > > so if you think it's usefull please include it in you're faq! > > > > > > > > > > Regards, > > > > > Victor > > > > > > > > > > Question: I want to handle only selected traffic with snort_inline > > > > > > > > > > Answer: You can the MARK target in iptables for this. Say you want > > > > > only stmp traffic to be handled by snort_inline, but not pop3. > > > > > > > > > > 1. iptables -t mangle -A FORWARD -p tcp --dport 25 -j MARK --set- > > > > > mark 0x1 > > > > > > > > > > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m mark - > > > > > -mark 0x1 -j QUEUE > > > > > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > > > > > > > 4. iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j > > > > > QUEUE 5. iptables -A FORWARD -p tcp --dport 110 -m state --state NEW > > > > > -j ACCEPT > > > > > > > > > > Pop3 traffic is now first accepted in rule 5, and after that handled > > > > > by rule > > > > > 3. > > > > > > > > > > The smtp traffic is now first QUEUE'd by rule 4, after that marked > > > > > in rule 1 so it can be picked up by the 2nd rule. > > > > > > > > > > Question: I can now handle selected traffic, but i'm having troubles > > > > > with protocols witch use protocol handlers in iptables, like ftp. > > > > > > > > > > Answer: for this you need the 'helper' module. Say you want only ftp > > > > > traffic to be handled by snort_inline, but not http. > > > > > > > > > > 1. iptables -t mangle -A FORWARD -p tcp --dport 21 -j MARK --set- > > > > > mark 0x1 > > > > > 2. iptables -t mangle -A FORWARD -m helper --helper "ftp" -j MARK -- > > > > > set-mark 0x1 > > > > > > > > > > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m mark - > > > > > -mark 0x1 -j QUEUE > > > > > 4. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > > > > > > > 5. iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j > > > > > QUEUE 6. iptables -A FORWARD -p tcp --dport 80 -m state --state NEW > > > > > -j ACCEPT > > > > > > > > > > The difference here is the second rule which makes sure that the > > > > > connections that are handled by the ftp conntrack helper are also > > > > > send to the queue. > > > > > > > > > > ------------------------------------------------------- > > > > > 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 ------- > > > > > > ------------------------------------------------------- > > > 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 ------- > > > > > > > > ------------------------------------------------------- > > 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 ------- End of Original Message ------- |
|
From: Victor J. <vi...@nk...> - 2004-07-01 20:06:57
|
On Thursday 01 July 2004 21:56, Geffrey Velasquez [MINAG] wrote: > Excelent! your script always have on top the ESTABLISHED and RELATED > states. I would like to see your frontend. It's not yet released, i'm in the process of registering a project with=20 sourceforge. I think after my holiday i release it... 1 month or so? > Another question (I'm new), I was testing with an Apache behind an > Iptables/Snort Inline Firewall, only with web-*.rules activated and trigg= er > some cgi attacks, the attempt is droped, but the Apache web server dont > knows that the connection was dropped and maybe could lead in DOS attack. > How are you considering this case? I' not sure if the entire connection is dropped or just the dangerous=20 packets... (i'm also new to snort_inline ;-) Maybe you could use reject for= =20 this? Regards, Victor > > > > Regards, > Geffrey Vel=E1squez > > > ---------- Original Message ----------- > From: Victor Julien <vi...@nk...> > To: sno...@li... > Sent: Thu, 1 Jul 2004 21:33:25 +0200 > Subject: Re: [Snort-inline-users] using snort_inline for selected traffic > only (was: help with setting up iptables for use with snort_inline) > > > Good question. Not much i think. :-) > > > > The reason i do it like this, is that the iptables frontend i'm > > writing creates the ESTABLISHED,RELATED first, and then based on a > > rulesfile the specific individual rules. So then i have only two > > RELATED,ESTABLISHED rules per chain (on top of course) for optimal > > performance. The frontend then dynamicly creates mangle, nat and > > filterrules. > > > > The way you do it i would have to create an ESTABLISHED,RELATED for > > every service/rule i want to QUEUE. > > > > But for this example you are absolutely right! > > > > Regards, > > Victor > > > > Updated example: > > > > Question: I want to handle only selected traffic with snort_inline > > > > Answer: > > Say you want only stmp traffic to be handled by snort_inline, but > > not pop3. > > > > # the ESTABLISHED,RELATED for smtp > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp - > > -dport 25 -j QUEUE > > # the ESTABLISHED,RELATED for the rest > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > # the initial rules > > iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > > iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCEPT > > > > Question: I can now handle selected traffic, but i'm having troubles > > with protocols witch use protocol handlers in iptables, like ftp. > > > > Answer: for this you need the 'helper' module. Say you want only ftp > > traffic to be handled by snort_inline, but not http. > > > > # the ESTABLISHED,RELATED for the helper ftp > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m helper -- > > helper "ftp" -j QUEUE > > # the ESTABLISHED,RELATED for ftp connection on port 21 > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp -- > > dport 21 -j QUEUE > > # the ESTABLISHED,RELATED for the rest > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j QUEUE > > iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT > > > > The difference here is helper module which makes sure that the > > connections that are handled by the ftp conntrack helper are also > > send to the queue. > > > > On Thursday 01 July 2004 21:14, Geffrey Velasquez [MINAG] wrote: > > > Hi Victor, and what is the difference with this?: > > > > > > 1. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp > > > --dport 25 -j QUEUE > > > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > 3. iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > > > 4. iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACC= EP > > > > > > > > > Saludos, > > > Geffrey Vel=E1squez > > > Cel.: 9722-2705 > > > > > > ---------- Original Message ----------- > > > From: Victor Julien <vi...@nk...> > > > To: sno...@li... > > > Sent: Thu, 1 Jul 2004 19:53:28 +0200 > > > Subject: [Snort-inline-users] using snort_inline for selected traffic > > > only (was: help with setting up iptables for use with snort_inline) > > > > > > > Hi list, > > > > > > > > I found the answer to my question (with the kind help of Antony > > > > Stone of the Netfilter list). I'd like share it with you so others > > > > can use it as well. I've written it in the snort_inline faq format, > > > > so if you think it's usefull please include it in you're faq! > > > > > > > > Regards, > > > > Victor > > > > > > > > Question: I want to handle only selected traffic with snort_inline > > > > > > > > Answer: You can the MARK target in iptables for this. Say you want > > > > only stmp traffic to be handled by snort_inline, but not pop3. > > > > > > > > 1. iptables -t mangle -A FORWARD -p tcp --dport 25 -j MARK --set- > > > > mark 0x1 > > > > > > > > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m mark= - > > > > -mark 0x1 -j QUEUE > > > > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCE= PT > > > > > > > > 4. iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j > > > > QUEUE 5. iptables -A FORWARD -p tcp --dport 110 -m state --state NEW > > > > -j ACCEPT > > > > > > > > Pop3 traffic is now first accepted in rule 5, and after that handled > > > > by rule > > > > 3. > > > > > > > > The smtp traffic is now first QUEUE'd by rule 4, after that marked > > > > in rule 1 so it can be picked up by the 2nd rule. > > > > > > > > Question: I can now handle selected traffic, but i'm having troubles > > > > with protocols witch use protocol handlers in iptables, like ftp. > > > > > > > > Answer: for this you need the 'helper' module. Say you want only ftp > > > > traffic to be handled by snort_inline, but not http. > > > > > > > > 1. iptables -t mangle -A FORWARD -p tcp --dport 21 -j MARK --set- > > > > mark 0x1 > > > > 2. iptables -t mangle -A FORWARD -m helper --helper "ftp" -j MARK = =2D- > > > > set-mark 0x1 > > > > > > > > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m mark= - > > > > -mark 0x1 -j QUEUE > > > > 4. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCE= PT > > > > > > > > 5. iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j > > > > QUEUE 6. iptables -A FORWARD -p tcp --dport 80 -m state --state NEW > > > > -j ACCEPT > > > > > > > > The difference here is the second rule which makes sure that the > > > > connections that are handled by the ftp conntrack helper are also > > > > send to the queue. > > > > > > > > ------------------------------------------------------- > > > > 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 ------- > > > > ------------------------------------------------------- > > 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 ------- > > > > ------------------------------------------------------- > 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: Geffrey V. [MINAG] <gve...@mi...> - 2004-07-01 19:56:52
|
Excelent! your script always have on top the ESTABLISHED and RELATED states. I would like to see your frontend. Another question (I'm new), I was testing with an Apache behind an Iptables/Snort Inline Firewall, only with web-*.rules activated and trigger some cgi attacks, the attempt is droped, but the Apache web server dont knows that the connection was dropped and maybe could lead in DOS attack. How are you considering this case? Regards, Geffrey Velásquez ---------- Original Message ----------- From: Victor Julien <vi...@nk...> To: sno...@li... Sent: Thu, 1 Jul 2004 21:33:25 +0200 Subject: Re: [Snort-inline-users] using snort_inline for selected traffic only (was: help with setting up iptables for use with snort_inline) > Good question. Not much i think. :-) > > The reason i do it like this, is that the iptables frontend i'm > writing creates the ESTABLISHED,RELATED first, and then based on a > rulesfile the specific individual rules. So then i have only two > RELATED,ESTABLISHED rules per chain (on top of course) for optimal > performance. The frontend then dynamicly creates mangle, nat and filterrules. > > The way you do it i would have to create an ESTABLISHED,RELATED for > every service/rule i want to QUEUE. > > But for this example you are absolutely right! > > Regards, > Victor > > Updated example: > > Question: I want to handle only selected traffic with snort_inline > > Answer: > Say you want only stmp traffic to be handled by snort_inline, but > not pop3. > > # the ESTABLISHED,RELATED for smtp > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp - > -dport 25 -j QUEUE > # the ESTABLISHED,RELATED for the rest > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > # the initial rules > iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCEPT > > Question: I can now handle selected traffic, but i'm having troubles > with protocols witch use protocol handlers in iptables, like ftp. > > Answer: for this you need the 'helper' module. Say you want only ftp > traffic to be handled by snort_inline, but not http. > > # the ESTABLISHED,RELATED for the helper ftp > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m helper -- > helper "ftp" -j QUEUE > # the ESTABLISHED,RELATED for ftp connection on port 21 > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp -- > dport 21 -j QUEUE > # the ESTABLISHED,RELATED for the rest > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j QUEUE > iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT > > The difference here is helper module which makes sure that the > connections that are handled by the ftp conntrack helper are also > send to the queue. > > On Thursday 01 July 2004 21:14, Geffrey Velasquez [MINAG] wrote: > > Hi Victor, and what is the difference with this?: > > > > 1. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp --dport > > 25 -j QUEUE > > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > 3. iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > > 4. iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCEP > > > > > > Saludos, > > Geffrey Velásquez > > Cel.: 9722-2705 > > > > ---------- Original Message ----------- > > From: Victor Julien <vi...@nk...> > > To: sno...@li... > > Sent: Thu, 1 Jul 2004 19:53:28 +0200 > > Subject: [Snort-inline-users] using snort_inline for selected traffic only > > (was: help with setting up iptables for use with snort_inline) > > > > > Hi list, > > > > > > I found the answer to my question (with the kind help of Antony > > > Stone of the Netfilter list). I'd like share it with you so others > > > can use it as well. I've written it in the snort_inline faq format, > > > so if you think it's usefull please include it in you're faq! > > > > > > Regards, > > > Victor > > > > > > Question: I want to handle only selected traffic with snort_inline > > > > > > Answer: You can the MARK target in iptables for this. Say you want > > > only stmp traffic to be handled by snort_inline, but not pop3. > > > > > > 1. iptables -t mangle -A FORWARD -p tcp --dport 25 -j MARK --set- > > > mark 0x1 > > > > > > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m mark - > > > -mark 0x1 -j QUEUE > > > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > > > 4. iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > > > 5. iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCEPT > > > > > > Pop3 traffic is now first accepted in rule 5, and after that handled > > > by rule > > > 3. > > > > > > The smtp traffic is now first QUEUE'd by rule 4, after that marked > > > in rule 1 so it can be picked up by the 2nd rule. > > > > > > Question: I can now handle selected traffic, but i'm having troubles > > > with protocols witch use protocol handlers in iptables, like ftp. > > > > > > Answer: for this you need the 'helper' module. Say you want only ftp > > > traffic to be handled by snort_inline, but not http. > > > > > > 1. iptables -t mangle -A FORWARD -p tcp --dport 21 -j MARK --set- > > > mark 0x1 > > > 2. iptables -t mangle -A FORWARD -m helper --helper "ftp" -j MARK -- > > > set-mark 0x1 > > > > > > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m mark - > > > -mark 0x1 -j QUEUE > > > 4. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > > > 5. iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j QUEUE > > > 6. iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT > > > > > > The difference here is the second rule which makes sure that the > > > connections that are handled by the ftp conntrack helper are also > > > send to the queue. > > > > > > ------------------------------------------------------- > > > 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 ------- > > ------------------------------------------------------- > 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 ------- |
|
From: Victor J. <vi...@nk...> - 2004-07-01 19:33:34
|
Good question. Not much i think. :-) The reason i do it like this, is that the iptables frontend i'm writing=20 creates the ESTABLISHED,RELATED first, and then based on a rulesfile the=20 specific individual rules. So then i have only two RELATED,ESTABLISHED rule= s=20 per chain (on top of course) for optimal performance. The frontend then=20 dynamicly creates mangle, nat and filterrules. The way you do it i would have to create an ESTABLISHED,RELATED for every=20 service/rule i want to QUEUE. But for this example you are absolutely right! Regards, Victor Updated example: Question: I want to handle only selected traffic with snort_inline Answer:=20 Say you want only stmp traffic to be handled by snort_inline, but not pop3. # the ESTABLISHED,RELATED for smtp iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp --dport 25 = =2Dj=20 QUEUE # the ESTABLISHED,RELATED for the rest iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # the initial rules iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCEPT Question: I can now handle selected traffic, but i'm having troubles with=20 protocols witch use protocol handlers in iptables, like ftp. Answer: for this you need the 'helper' module. Say you want only ftp traffi= c=20 to be handled by snort_inline, but not http. # the ESTABLISHED,RELATED for the helper ftp iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m helper --helper= =20 "ftp" -j QUEUE # the ESTABLISHED,RELATED for ftp connection on port 21 iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp --dport 21= -j=20 QUEUE # the ESTABLISHED,RELATED for the rest iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j QUEUE iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT The difference here is helper module which makes sure that the connections= =20 that are handled by the ftp conntrack helper are also send to the queue. On Thursday 01 July 2004 21:14, Geffrey Velasquez [MINAG] wrote: > Hi Victor, and what is the difference with this?: > > 1. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -p tcp --dport > 25 -j QUEUE > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > 3. iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > 4. iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCEP > > > Saludos, > Geffrey Vel=E1squez > Cel.: 9722-2705 > > ---------- Original Message ----------- > From: Victor Julien <vi...@nk...> > To: sno...@li... > Sent: Thu, 1 Jul 2004 19:53:28 +0200 > Subject: [Snort-inline-users] using snort_inline for selected traffic only > (was: help with setting up iptables for use with snort_inline) > > > Hi list, > > > > I found the answer to my question (with the kind help of Antony > > Stone of the Netfilter list). I'd like share it with you so others > > can use it as well. I've written it in the snort_inline faq format, > > so if you think it's usefull please include it in you're faq! > > > > Regards, > > Victor > > > > Question: I want to handle only selected traffic with snort_inline > > > > Answer: You can the MARK target in iptables for this. Say you want > > only stmp traffic to be handled by snort_inline, but not pop3. > > > > 1. iptables -t mangle -A FORWARD -p tcp --dport 25 -j MARK --set- > > mark 0x1 > > > > 2. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m mark - > > -mark 0x1 -j QUEUE > > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > 4. iptables -A FORWARD -p tcp --dport 25 -m state --state NEW -j QUEUE > > 5. iptables -A FORWARD -p tcp --dport 110 -m state --state NEW -j ACCEPT > > > > Pop3 traffic is now first accepted in rule 5, and after that handled > > by rule > > 3. > > > > The smtp traffic is now first QUEUE'd by rule 4, after that marked > > in rule 1 so it can be picked up by the 2nd rule. > > > > Question: I can now handle selected traffic, but i'm having troubles > > with protocols witch use protocol handlers in iptables, like ftp. > > > > Answer: for this you need the 'helper' module. Say you want only ftp > > traffic to be handled by snort_inline, but not http. > > > > 1. iptables -t mangle -A FORWARD -p tcp --dport 21 -j MARK --set- > > mark 0x1 > > 2. iptables -t mangle -A FORWARD -m helper --helper "ftp" -j MARK -- > > set-mark 0x1 > > > > 3. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -m mark - > > -mark 0x1 -j QUEUE > > 4. iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > > > 5. iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j QUEUE > > 6. iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT > > > > The difference here is the second rule which makes sure that the > > connections that are handled by the ftp conntrack helper are also > > send to the queue. > > > > ------------------------------------------------------- > > 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 ------- |
133 messages has been excluded from this view by a project administrator.
