[8099] in bugtraq
CERT: IN-98.04
daemon@ATHENA.MIT.EDU (Darren Reed)
Fri Oct 2 00:25:41 1998
Date: Fri, 2 Oct 1998 13:28:31 +1000
Reply-To: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
X-To: Darren Reed <avalon@cheops.anu.edu.au>
To: BUGTRAQ@NETSPACE.ORG
In the latest CERT report http://www.cert.org/incident_notes/IN-98.04.html
(for some reason it's not provieded as a text file in the ftp directories)
it mentiones host identification using TCP connection characteristics as
the means to achieve this. Another possible method is to look at ICMP
replies to various packets (AUUG '98, "Remote Operating System
Identification" - Anthony Osborne) - can't they all just "get it right" ?!
Defending against the ICMP variation isn't too hard, but I'm not sure it
could be successfully done for TCP if you aren't using a proxy firewall
with real proxy agents (all you give away is information about it) for all
TCP connections.
Another point of interest in the latest "IN", is "slow scans". Some 5 or
so years ago I made a somewhat lame (by current standards) effort at writing
a program to log all tcp connection activity on a LAN, log that information
and then analyze it. The key is keeping a long history. If, for example,
you have over 2 months have had a packet targetted at every TCP port from 1
to 1024, then I'd wager the likelihood of that being a complete scan as very
high. It's the sort of thing you'd _expect_ an IDS to be already capable of
doing. The key to this really is you have to ignore the source IP addresses
(well, maybe excluding those which you know 100% to be non-compromised) and
just aggregate results based on destination ip/port numbers.
Darren
