On Thu, 2004-12-02 at 10:21 +0100, Troels Arvin wrote: > 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. Create the logging rules first you can probably verify almost everything but connection tracking with just the logging rules. I have been using that cron trick forever, but don't forget to remove it :-) I usually add two, one stops it every 3-5 minutes and another every 30 minutes. Cron mail is most helpful in these types of situations as well. Ted -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
