From: Victor J. <vi...@nk...> - 2004-07-07 17:47:21
|
On Tuesday 06 July 2004 20:24, William Metcalf wrote: > 431942 is the absolute time-out for a session in iptables, i.e. is up, > active, and constantly talking. It shouldn't be to difficult to implement > logging of dropped packets, I would do it but I'm stressed for time as it > is. If you feel like implementing this go for it. Hi William, I still don't really understand the difference between the 5 days timeout in iptables and the 30sec-to-2min timeout of snort_inline. Or are those two not comparable? I do appreciate the fact that the short timeout prevents excessive memory usage, but the difference is really, really big. Can you elaborate some more on this subject (or point me to some docs?)? Thanx! Victor > > Regards, > > Will > > > > Victor Julien > <vi...@nk...> > To > 07/06/2004 01:07 William Metcalf > PM <Wil...@kc...> > cc > sno...@li...urceforg > e.net > Subject > Re: [Snort-inline-users] msn > messenger problem > > On Tuesday 06 July 2004 19:51, William Metcalf wrote: > > The default time out for a session is 120 seconds for iptables. If you > > set > > > this in stream4 I would up the amount of memory you allocate for it. As > > far as logging out-of-session packets, there isn't a mechanism in snort > > or > > > snort_inline to do this, if you are troubleshooting, you can enable the > > stream4 debug. This can be accomplished compiling with --enable-debug > > and > > > then export SNORT_DEBUG=8192 prior to starting snort_inline. > > Hmm, i thought the default tcp session timeout in iptables was something > like > 5 days... > > from my /proc/net/ip_conntrack: > > tcp 6 431942 ESTABLISHED src=192.168.0.167 dst=207.46.107.7 > sport=35693 > dport=1863 src=207.46.107.7 dst=192.168.0.167 sport=1863 dport=35693 > [ASSURED] use=1 > > The counter of 431942 is the session timeout right? > > Okay, i set the timeout to 120 seconds now, so now i have increase the > memcap? > Can you give a rule of thumb for how high it should be... (for x number of > connections, you need a memcap of y bytes) > > Wouldn't it be an interesting feature to be able to log those packets for > snort_inline (guess not for snort), because if snort_inline makes dissions > as > a firewall, thus dropping packets, i want to know why... > > If you run a firewall and connections are dropped (thus the users are > complaining to you), but you don't know why i think it's an administrators > nightmare... > > Would that difficult to implement, i'm a moderate c-programmer, so i could > give it a shot... > > (would you (or anyone else) even be interested in such a feature?) > > Regards, > Victor > > > Regards, > > > > Will > > > > > > > > Victor Julien > > <vi...@nk...> > > To > > > 07/06/2004 11:41 > > sno...@li...urceforg > > > AM e.net > > cc > > > William Metcalf > > <Wil...@kc...> > > Subject > > > Re: [Snort-inline-users] msn > > messenger problem > > > > On Tuesday 06 July 2004 18:16, William Metcalf wrote: > > > Increasing the time-out should be fine, gaim must implement it's MSN > > > function differently than the windows messenger client. If no data is > > > received for x seconds in a TCP conversation the session is pruned in > > > stream4, this is the same way that a stateful firewall works. If data > > is > > > > received out-of session it is dropped, unless it is trying to > > initialize > > > a > > > > > new session i.e. a packet with the SYN flag set. > > > > Okay, so the only drawback is that stream4 will take some more memory > > because > > of this? > > > > Is this the same type of timeout that iptables uses in the state table? > > Iptables uses timeouts of days, not seconds if i recall correctly. > > > > Final question: why doesn't snort log the packets that are out of > > session? > > > Or: > > how can i make snort log them? > > > > Thanks for your help! > > > > Regards, > > Victor > > > > > Regards, > > > > > > Will > > > > > > > > > > > > Victor Julien > > > <vi...@nk...> > > > > To > > > > > 07/06/2004 10:55 > > > > sno...@li...urceforg > > > > > AM e.net > > > > cc > > > > > William Metcalf > > > <Wil...@kc...> > > > > Subject > > > > > Re: [Snort-inline-users] msn > > > messenger problem > > > > > > On Tuesday 06 July 2004 15:34, William Metcalf wrote: > > > > That's odd, try disabling the flow preproc as it is not yet supported > > > > in > > > > > > snort_inline. I don't have any problem with msn and the stream4 > > > > preproc. > > > > > The flow preprocessor was not the problem. I disabled it, but the > > > connection > > > was still lost after some time. > > > > > > Increasing the timeout for the stream4 prepoc from the default 30 sec > > to > > > 60 > > > > > sec seems to be the solution. > > > > > > Can you explain to me what this does? Can it be a security risk? DoS? > > > > > > Regards, > > > Victor > > > > > > > Regards, > > > > > > > > Will > > > > > > > > > > > > > > > > Victor Julien > > > > <vi...@nk...> > > > > Sent by: > > > > > > To > > > > > > > snort-inline-user William Metcalf > > > > s-...@li...u <Wil...@kc...> > > > > rceforge.net > > > > > > cc > > > > > > sno...@li...urceforg > > > > > > > e.net > > > > 07/06/2004 06:39 > > > > > > Subject > > > > > > > AM Re: [Snort-inline-users] msn > > > > messenger problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi William, > > > > > > > > Thanx for your reply. > > > > > > > > On Tuesday 06 July 2004 06:32, you wrote: > > > > > Look through your logs, there are certian rules that detect > > > > > > msn-messenger > > > > > > > > logon attemtps, if you have converted all rules to drop messenger > > > > would > > > > > > > stop working. > > > > > > > > My logs don't show anything about msn messenger. So if snort_inline > > is > > > > > blocking msn in some way, it does so without telling me. I also tried > > > > > > aMsn > > > > > > > and Gaim and the same thing happens. > > > > > > > > I got this when running Gaim in debug mode: > > > > > > > > <snipped entire login procedure> > > > > msn: C: PNG > > > > msn: S: QNG 41 > > > > msn: C: PNG > > > > msn: S: QNG 46 > > > > msn: C: PNG > > > > msn: S: QNG 44 > > > > msn: C: PNG > > > > msn: S: QNG 40 > > > > msn: C: PNG > > > > msn: S: QNG 40 > > > > msn: C: PNG > > > > msn: S: QNG 43 > > > > msn: C: PNG > > > > msn: S: QNG 42 > > > > msn: C: PNG > > > > msn: S: QNG 47 > > > > > > > > I think 'C' is the client. It does some kind of keep-a-live i think. > > > > > > After > > > > > > > a > > > > 'PNG' (ping?) the server responds everytime. Then without notice or > > > > message, > > > > the server stops responding, and finally disconnects. > > > > > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > msn: C: PNG > > > > account: Disconnecting account 0x8198ae0 > > > > connection: Disconnecting connection 0x82ba848 > > > > server: removing NOP > > > > > > > > I get no message what-so-ever in any log (snort, iptables, syslog). > > > > > > > > Could this have something to do with: > > > > 1. preprocessor flow > > > > 2. preprocessor stream4 > > > > 3. preprocessor stream4_reassemble > > > > > > > > Maybe some internal time-out in snort_inline? > > > > > > > > Note that i don't have this problem when only iptables handles msn > > > > (with > > > > > -j > > > > > > > ACCEPT). > > > > > > > > Regards, > > > > Victor > > > > > > > > > Regards, > > > > > > > > > > Will > > > > > > > > > > packescrubber:/etc/snort# grep MSN * > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > > message"; flow:established; content:"MSG "; depth:4; > > > > > content:"Content-Type|3A|"; nocase; content:"text/plain"; > > distance:1; > > > > > > classtype:policy-violation; sid:540; rev:11;) > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > file > > > > > > > > > transfer request"; flow:established; content:"MSG "; depth:4; > > > > > content:"Content-Type|3A|"; distance:0; nocase; > > > > > content:"text/x-msmsgsinvite"; distance:0; nocase; > > > > > content:"Application-Name|3A|"; content:"File Transfer"; > > distance:0; > > > > > > nocase; classtype:policy-violation; sid:1986; rev:4;) > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > file > > > > > > > > > transfer accept"; flow:established; content:"MSG "; depth:4; > > > > > content:"Content-Type|3A|"; nocase; content:"text/x-msmsgsinvite"; > > > > > distance:0; content:"Invitation-Command|3A|"; content:"ACCEPT"; > > > > > > > > distance:1; > > > > > > > > > classtype:policy-violation; sid:1988; rev:3;) > > > > > chat.rules:drop tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > file > > > > > > > > > transfer reject"; flow:established; content:"MSG "; depth:4; > > > > > content:"Content-Type|3A|"; nocase; content:"text/x-msmsgsinvite"; > > > > > distance:0; content:"Invitation-Command|3A|"; content:"CANCEL"; > > > > > > > > distance:0; > > > > > > > > > content:"Cancel-Code|3A|"; nocase; content:"REJECT"; distance:0; > > > > > > nocase; > > > > > > > > classtype:policy-violation; sid:1989; rev:4;) > > > > > chat.rules:drop tcp $HOME_NET any -> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > user > > > > > > > > > search"; flow:to_server,established; content:"CAL "; depth:4; > > nocase; > > > > > > classtype:policy-violation; sid:1990; rev:1;) > > > > > chat.rules:drop tcp $HOME_NET any -> $EXTERNAL_NET 1863 (msg:"CHAT > > > > MSN > > > > > > > login attempt"; flow:to_server,established; content:"USR "; > > depth:4; > > > > > > nocase; content:" TWN "; distance:1; nocase; > > > > > > classtype:policy-violation; > > > > > > > > sid:1991; rev:1;) > > > > > sid-msg.map:540 || CHAT MSN message > > > > > sid-msg.map:1986 || CHAT MSN file transfer request > > > > > sid-msg.map:1988 || CHAT MSN file transfer accept > > > > > sid-msg.map:1989 || CHAT MSN file transfer reject > > > > > sid-msg.map:1990 || CHAT MSN user search > > > > > sid-msg.map:1991 || CHAT MSN login attempt > > > > > > > > > > > > > > > > > > > > Victor Julien > > > > > <vi...@nk...> > > > > > Sent by: > > > > > > > > To > > > > > > > > > snort-inline-user > > > > > > > > sno...@li...urceforg > > > > > > > > > s-...@li...u e.net > > > > > rceforge.net > > > > > > > > cc > > > > > > > > > > > > Subject > > > > > > > > > 07/01/2004 02:00 [Snort-inline-users] msn > > > > > > messenger > > > > > > > > PM problem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I 'm testing snort_inline to filter my outgoing traffic. Http, > > ftp, > > > > pop3 > > > > > > > > work > > > > > fine so far, however msn-messenger does not. I'm using Kopete (kde > > > > > > 3.2.2, > > > > > > > > debian-testing) with msn-plugin. The plugin just dies after some 5 > > > > > > > > minutes > > > > > > > > > or > > > > > so. This does not happen when msn works just with iptables. Is > > there > > > > any > > > > > > > > known problem with msn and snort_inline? > > > > > > > > > > Regards, > > > > > Victor > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > > digital self defense, top technical experts, no vendor pitches, > > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > > _______________________________________________ > > > > > Snort-inline-users mailing list > > > > > Sno...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > > digital self defense, top technical experts, no vendor pitches, > > > > unmatched networking opportunities. Visit www.blackhat.com > > > > _______________________________________________ > > > > Snort-inline-users mailing list > > > > Sno...@li... > > > > https://lists.sourceforge.net/lists/listinfo/snort-inline-users |