Re: [Snort-inline-users] msn messenger problem

[Victor J. <vi...@nk...>]

Hey Will,

Thanks for your quick reply!

On Wednesday 07 July 2004 20:25, William Metcalf wrote:
> These are two different time-outs.  The five day time out is a session that
> is actively talking for five days straight.  Let's say you are going to
> transfer a file that was 1tb over a 56k connection.  This would more than
> likely take more than five day's.  Let's say what ever  you used to
> transfer the file used the same tcp session for the transfer.  After five
> days this transfer would be dropped because the session would be open for
> to long.  The 30 second time-out is the last time a packet was last sent
> using a tcp session.  So if you start up a tcp session with a three-way
> handshake and keep the session open and send a packet in an incrementing
> manner every 10 20 30 40 50 60 70 seconds the last packet would never make
> it because the session timed-out and was pruned.

I believe this is not correct. If a tcp session is ESTABLISHED, the timeout in 
iptables (just like in snort_inline) is reset every time the session 
processes a packet. For instance my connection to the msn server never gets 
below 431930 (or so) seconds, and after that resets to 431999. Only if a 
connection is gone, but was not closed properly i see it really timeout.

So basicly, based on this i still see no principal difference between the two, 
and i still wonder why the difference is so big. I can see that for snort it 
makes no real difference. It can pickup connections after they started (i 
believe), but for snort_inline, acting as a firewall i wonder if connections 
aren't dropped way to fast.

Furthermore, shouldn't connections that timeout be reset instead of dropped?

Regards,
Victor

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