Iplementing a firewall after-the-fact

[Howard B Owen]

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 at cisco.com   +1-650-218-2216  just sit there." - Will Rogers