Re: 'mirror' with iptables
thomas lakofski <email@example.com> 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,
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
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.
Newton and Adam, lost and found, |firstname.lastname@example.org
The apple must fall to the ground |http://spodzone.org.uk/