Nmap Announce mailing list archives
Re: Intrusion detection question.
From: Bart van Leeuwen <bart () ixori demon nl>
Date: Thu, 10 Feb 2000 18:39:51 +0100
Michel Arboi wrote:
"Daniel Swan" <swan_daniel () 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:65095I 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
Current thread:
- Re: Intrusion detection question., (continued)
- Re: Intrusion detection question. Jose Nazario (Feb 10)
- fooling nmap Bep Verberk (Feb 10)
- Re: fooling nmap Lance Spitzner (Feb 10)
- Re: fooling nmap CyberPsychotic (Feb 11)
- Re: fooling nmap Vanja Hrustic (Feb 11)
- Re: fooling nmap The Cyberiad (Feb 11)
- Re: Intrusion detection question. Tomi Ollila (Feb 10)
- Re: Intrusion detection question. Michel Arboi (Feb 14)
- Re: Intrusion detection question. Tomi Ollila (Feb 21)