thomas lakofski <[EMAIL PROTECTED]> writes: [snip, `get a good firewall'] > > > how does this stop the scanner from identifying open ports? > > > > Why is a port open to a scanner's IP#, if not in order to be used? > > good point. what we're trying to do here though is heuristically (or more > simplistically) isolate port scans and stop them from being successful -- > well this is the portsentry principle of operation. ie noone has any > business connecting to 111/tcp or 27374/tcp over the Internet, so presume > that they are up to no good and block 'em...
Here portsentry is still the lesser option. I know the options I'm suggesting, and admit that when I run a webserver, the only packets that won't hit port 80/tcp are those flagged as `INVALID' in iptables. Ditto ssh, for most intents & purposes (there are boxes where it's a lot tighter, of course). It sounds like what you want is bad-behaviour-detection *within* the fact that a given port has to be `mostly open' rather than `mostly closed'. That behaviour is going to be far more varied than `oh rats, they sent an Xmas-tree packet to the port, quick, block them in the firewall'. You can, and do, get misbehaviour such as Nimda without any TCP- or IP-level manglings. Personally, I go for a) DROP-by-default firewall with stateful filtering in iptables; b) such ports that are wide open (22, 80, 53/udp... whatever) are still behind the protection of `INVALID'; c) such services that listen on the open ports are as secured as possible - latest versions, no extra apache modules, the whole 9 yards of BIND security, libsafe, etc; d) fwlogwatch to mail me firewall alerts every night; e) snort to keep an eye on what tricks people are playing with those few services that are open; f) AIDE to mail me filesystem changes every night. It's pretty rarely that I see any abuse that gets as far down the chain as to deserve human intervention. ~Tim -- Newton and Adam, lost and found, |[EMAIL PROTECTED] The apple must fall to the ground |http://spodzone.org.uk/
