another ra oddity...

[Carter Bullard]

Hey Russell,
   So I now rarely use the 'dst' or 'src' indications,
since this has caused me to miss some unexpected network
events.  Especially since many firewalls are misconfigured,
allowing incoming TCP connections with a source port of 23
to get in.  Filters like:

    ((src address local && dst port 23) ||
            (dst address local and src port 23))

or

  !((dst address local and dst port 23) ||
            (src address local $ src port 23))

appear to work for the most part, but, as we know, are
not good at all.  People tend to generate this type of
filter when they are trying to quickly fix a connectivity
problem and they've only got filter expressions in routers
to work with.

   And many an intrusion detector builder forget to go after
the most common and simple human filter errors, as they are
wrapped up in the complexity of solving the hard problems,
forgetting about the simple ones.  I would put reverse port use
way up front on any intrusion detection module.   

   This makes using raconnections() important.
If I'm looking for telnets in a whole days worth of logs, I would
run raconnections() with a filter of "tcp and port 23" on all the
files and then spit that output to whatever analyzer I've got.
Be conscience to put the files in time order on the command line.
Not critical, but can be important.

Carter




> -----Original Message-----
> From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
> Sent: Tuesday, October 05, 1999 9:57 PM
> To: Bullard, Carter [NYPAR:DS46-I:EXCH]
> Subject: Re: RE: another ra oddity...
> 
> 
> 
> On Tue, 5 Oct 1999 17:51:23 -0700 Carter Bullard 
> <cbullard at nortelnetworks.com> wrote:
> 
> > Hey Russell,
> >    This is unavoidable.  What is happening is the flow idle timer
> > is reached and argus() times out the flow sometime after your #2
> > report.  Then when the flow kicks back in the, first packet seen
> > is going in the opposite direction.  But since we didn't see a SYN
> > or a SYN_ACK, we don't know who the source is.  In this case
> > we use the first packet encountered to define the scr and
> > dst for the flow.
> 
> Thanks for the explaination.
> 
> Ah, I see, it is only 120 seconds (ttcptimeout), I thought it was 900.
> 
> That also explains some other things I have notice before when I have 
> been looking at logs of telnet sessions to hacked machines -- they 
> often don't have termination record.  I can't simply do a 
> 'dst port 23'.
> 
> Cheers, Russell.
> 
> 
>