Iplementing a firewall after-the-fact

[Troels Arvin]

On Wed, 01 Dec 2004 16:55:44 -0800, Howard B Owen wrote:

> A
> packet filter can often let you know when someone port scans your
> system.

True. And there was a time when I would closely monitor for suspicious
probes, but I've abandoned that "hobby": What security do I gain from
knowing that someone is trying to do something which is basically not
dangarous (like trying to access a port on which nothing listens)?

> Secondly, in the case where a service must listen on a port, but
> wants to restrict access by source IP, a packet filter can protect you
> from attacks against the server launched from the banned networks.

That's true: If the application itself doesn't offer a way to restrict by
IP or network, then packet filtering is a handy alternative (which I also
use in some cases). Also, some software doesn't allow you to specify which
interfaces to listen to, and in that case, iptables is also nice.

> Of course, firewalls
> themselves can get pretty complicated, too.

Exactly. And the netfilter software _is_ still software, meaning that it
can contain bugs - bugs that will even run in kernel space. There haven't
been any seriously ugly security bugs in the netfilter code yet, but the
code _could_ contain security problems in itself. That's another reason
why I strive to obtain installations which don't need packet filtering.

> Another thing you can try is a cron or at
> job that runs 'service iptables stop' at a designated interval after you
> implement your rules.

Yes, that's a handy trick. Thanks to you and Alexander for pointing that
out.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark