Re: Iplementing a firewall after-the-fact

[Seth Shoemaker <sshoemaker perfectorder com>]

Another thing with Bind is that in Version 9, they added something called "Views" and with them you can say that certain IP's can see this view and nothing else can.  They are very helpful (especially if you don't want people outside seeing your internal host names if they have external addresses).

Seth Shoemaker

----- Original Message -----
From: Troels Arvin <troels arvin dk>
Date: Wednesday, December 1, 2004 7:09 pm
Subject: Re: Iplementing a firewall after-the-fact

> 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 
> candidatesfor deletion, per rule 1), because all that's listening 
> really should be
> available, so packet filtering is waste of clock cycles and just 
> anothererror-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.
> 
> -- 
> Greetings from Troels Arvin, Copenhagen, Denmark
> 
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list redhat com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
> 

begin:vcard
n:Shoemaker;Seth
fn:Seth Shoemaker 
tel;cell:717-571-2603
tel;work:717-796-1936 x270
url:http://www.perfectorder.com
org:Perfect Order, Inc;
adr:;;1300 Bent Creek Blvd.;Mechanicsburg;Pennsylvania;17050;USA
version:2.1
email;internet:sshoemaker perfectorder com
title:Support Engineer
end:vcard