While I couldn't agree more with the hardening advice, I think you may be overlooking some benefits of packet filtering that you can't get by just tightening down a system. The first is awareness of probes. A packet filter can often let you know when someone port scans your system. 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. Source address spoofing subverts all protections based on filtering source IP equally, of course. This is a special case of the generic mistrust of complex software that traditional firewalls, whether packet filters or proxies, are intended to embody. Of course, firewalls themselves can get pretty complicated, too. I also agree that implementing a firewall remotely, without an alternate form of access, such as a serial console, is extremely risky, but here are a couple of things that could reduce the risk. At least in recent versions of Red Hat (I'm basing this on RHEL3) , the ability to power-cycle the box would also allow you to escape from a blown firewall configuration. The rules won't be permanent until you run 'service iptables save'. (It's not there by default, but if the variable 'IPTABLES_SAVE_ON_STOP is set to "yes" in /etc/sysconfig/iptables-config, then 'service iptables stop' will also save the rules, so beware.) 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. As long as there is no problem with that job, it should allow you to automatically recover from an accidental lockout. Good luck! On Wed, 2004-12-01 at 16:09, Troels Arvin wrote: > On Wed, 01 Dec 2004 15:38:34 -0800, Eric Wagar wrote: > > > Is there a safe way to implement a firewall (ipchains/iptables) after > > the fact? After the fact being after I have already deployed the system > > at a remote site? > > Remote playing with packet filters is tricky, because you - obviously - > face the risk of shutting yourself out. I have tried that situation > myself, and I have seen others trapped in it. > > > I only have ports 21, 22, 25, 80, and 8080 needing to be public, with 53 > > needing to be open to the subnet. Everything else needs to be turned > > "off" or filtered. > > I believe it's better and safer to simply clean+tighten up the system: > > 1. Uninstall unneeded software. > 2. Close down unneeded network daemons which - for some > reason - cannot be uninstalled. > 3. Upgrade remaining software if security > bugfixes have been released. > 4. Use a command like > netstat -naep | grep -v '^unix' | egrep '(LISTEN|udp)' > to identify what might still be running+listening > on the network. > 5. Limit remaining daemons to only listen on the "lo" > (and possibly other) interface(s), where possible. > 6. Look at what users/privileges the remaining daemons are > running as/with and see if it's possible and relevant > to tighten up. > 7. Consider running (some of the) remaining daemons in > a chroot'ed environment. > > By now, ipchains/iptables could very well be unneeded (and thus candidates > for deletion, per rule 1), because all that's listening really should be > available, so packet filtering is waste of clock cycles and just another > error-potential. > > When I say "better and safer", it's because such a methology leads to > simpler/leaner setups, less resources being used by unneeded software, and > less software to keep updated. > > In the case of port 53 where you want it open to a specific subnet: BIND > can easily be configured for such needs, through its "listen-on" and/or > "listen-on-v6" configuration options. -- Howard Owen RHCE, Linux Architect "Even if you are on the right IBM Global Services - Cisco Linux track, you'll get run over if you howen@xxxxxxxxx +1-650-218-2216 just sit there." - Will Rogers -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
