Re: Intrusion detection question.

Michel Arboi wrote:
>
> "Daniel Swan" <swan_daniel_at_my-Deja.com> writes:
>
> > The best example is a source port of 61000-650096 (Possible linux
> > masquerading box)
>
> Well, a masquerading Linux box will announce its OS like this, but a
> BSD with IP Filter could mimick it:
> map ppp0 10.0.0.0/8 -> ppp0/32 portmap tcp/udp 61000:65095
>
> > I am wondering if there are any other rules of
> > thumb, or even a canonical list of what we can tell from source
> > port.
>
> A couple of ideas:
> - are there different allocation algorithms for source ports?
> e.g., first free port above 1023, or random free port above 1023...
> - when will a TCP port be reused once the connection is closed?

well.. doesn't help for OS detection, but you can often assume that a
source port <1024 points to a scanner running as root. (quite obvious
I'd think, tho there are tools to allow non root to use those ports as
well ;-) A source port >1023 however does in no way mean that the
scanner did not run as root.

I used this once to alert a company of a possible root compromise on one
of their mail relays. I was receiving scans from low source ports on
that machine, looking at it turned out that it was some companies mail
relay. Contacting the admin of that server turned out that he knew
little about scanners, and wasn't running one on that machine. This led
to the conclusion that someone else most likely had root access to the
machine (which indeed turned out to be the case)

Anyway, as Daniel pointed out, there are ways to maniplate this, and
ipf/ipnat allow for mimicing the behavior of other operating systems and
stacks, so reliability is likely to be quite low against those people
who are the most dangerous for your system. Not a reason to not do this,
but a reason to assume that it will moist likely not give correct
information about scans from the more dangerous sources.
This can however also be used by you to make it harder to detect what
you are running.

I still question the usefullness of this all, tho a scan may be the
start of an intrucion, often it is not, and I think it is hard to use it
for intrucion detection without getting many more alerts then you really
want to have. I don't doubt the usefullness of logging scans tho, but
triggering intrucion detection on it is imho likely to cause you a lot
of work on things that are not real intruciuons. So far at least scan
logs have often pointed me to other hosts that were compromised, while
they so far never helped me to detect intrucion on my own system
(something else did ;-)

If I want to use ip trafic to determine intrucions I would first start
to define 'normal' trafic (on levels 3 and up), and instead of logging
scans, I would log and trigger on actual packet content when it is found
to be too different from 'normal' trafic. The resdult would be that you
are alerted of possible intrucions and also of (valid) ways to use your
service that you were not aware of.

-- 
Bart van Leeuwen