Firewall Script Required for bootscripts

Nathan Coulson conathan at conet.dyndns.org
Tue Mar 23 17:57:48 PST 2004


> On Tue, 2004-03-23 at 19:13, Nathan Coulson wrote:
>> I know someone here was working on a firewall bootscript, and I wanted
>> to
>> see what was done.
>>
>> The lfs bootscripts 2.0.0 are almost ready to go,  and curious if I
>> should
>> leave them how they are, or add them in.  [These bootscripts will be
>> used
>> for LFS 5.1].
>
> I wouldn't worry about it for LFS/BLFS unless you want to try to
> integrate it into the book's instructions.  I'll synch up the versions I
> have over here with any changes that might have occurred to those book's
> scripts so they're as similar as possible.  There's only a few minor
> changes that would be needed to trigger loading a monolithic firewall
> script, and I'll get with you about what little that entails later this
> week.  At the moment, everything I've been doing checks the
> FIREWALL_SCRIPT variable with the assumption that if a monolithic
> firewall script is being used, it'll be set in /etc/sysconfig/network.
>
> When this is _not_ set, (it could be an empty script) what I've been
> integrating assumes it's got free reign to do as it likes with respect
> to any and all firewall rules.  Services it's working for at the moment
> include sshd, named, squid, and nessusd (which flat out needs to be made
> sgid if a mostly-closed firewall ruleset is in place), which are four
> nice basic types of network services that I'm using as my test cases.
> Samba is going to wind up requiring me to change the permit_* deny_*
> functions considerably just because of it's unique
> same-portnum-to-same-portnum communication, and I've been avoiding
> binding rules to IP address until I can think completely through what
> happens when a DHCP-managed host has it's IP change.  At the moment I
> think I'm going with "most daemons break when this happens anyway, so
> it's moot" but I'm hoping inspiration will strike.
> --

Alright, I'll send out 2.0.0, and perhaps 2.0.1 when you believe you are
done.



More information about the hlfs-dev mailing list