Date: Wed, 6 Oct 1999 22:40:25 -0400 From: "Patrick Bihan-Faou" <patrick-fl-security@mindstep.com> To: "Thomas Keusch" <thomas@visionaire.ping.de> Cc: <freebsd-security@FreeBSD.ORG> Subject: Re: default rc.firewall Message-ID: <008901bf106d$4f227080$190aa8c0@local.mindstep.com> References: <007b01bf0f43$1a125de0$190aa8c0@local.mindstep.com> <19991006223750.A2232@dante.visionaire.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently this message did not make it to the list...
(this is resent with the permission of Thomas).
----- Original Message -----
From: Thomas Keusch <thomas@visionaire.ping.de>
To: Patrick Bihan-Faou <patrick@mindstep.com>
Cc: US FreeBSD Security Mailing List <freebsd-security@freebsd.org>
Sent: Wednesday, October 06, 1999 4:37 PM
Subject: Re: default rc.firewall
On Tue, Oct 05, 1999 at 11:05:46AM -0400, Patrick Bihan-Faou wrote:
Ha Patrick,
> This message is about the appropriatness of the current rc.firewall
script.
> I would like to have as many suggestions as possible...
> On that note, I don't really like the fact that you have to modify the
> "rc.firewall" script to set up even a "simple" firewall. I worked a bit on
a
> new version of the "rc.firewall" script that takes all its configuration
> from variables that you set in rc.conf. I guess that the script does not
> qualify as simple anymore, but I think this is a bit cleaner. A couple of
> examples:
I think this is generally a good idea, but there come a few ideas to mind
where you have no choice but to edit rc.firewall anyway.
> We are using (like many other I guess) FreeBSD as a NAT gateway on a
> cable-modem connection. I modified the rc.firewall script to use variables
> such as:
>
> firewall_public_if="vr0"
> firewall_private_if="ed0"
> firewall_allow_active_ftp="YES"
> firewall_allow_incoming_tcp="80,21,20"
> firewall_allow_incoming_tcp_log="22"
>
> And it sets up the proper rules:
>
> ipfw add allow tcp from any to any 20 setup in recv $oif
> ipfw add allow tcp from any to $oip 80,21,20 setup in recv $oif
> ipfw add allow log tcp from any to $oip 22 setup in recv $oif
>
> Where $oif, $oip etc are recovered automatically from ifconfig.
This IMHO is a good solution if there is exactly *one* inside and
*one* outside interface.
If one has a setup with more internal/external interfaces, given
your implementation above, one needs to edit the rc script nevertheless.
I don't know if there is a way to implement some robustness concerning
such issues without making rc.firewall overwhelmingly complex.
Besides that, I think there is a limit in the number of ports you can
pass to ipfw (I think it's around 10) (I can't check right now, as I'm
in Linux now), so if one sets firewall_allow_incoming_tcp to
"1,3,5,7,9,11,13,15,17,19,21,23,25,28" it would have to be split and
several ipfw commands would have to be executed.
This problem would have to be dealt with, either in ipfw or in rc.firewall.
So, basically, to adress these two problems within rc.firewall, the script
would get very complex and confusing, and maybe harder to maintain.
Another point is, if the script becomes that complex, newbies lose an
important (local) resource of information on how to use ipfw, as I think it
would be very hard to understand some given ipfw commands if you don't
understand the context in which they are executed.
> The other advantage is that when we get a new IP address through DHCP
from
> our cable provider, we only need to re-run the rc.firewall script and all
> the rules are updated to match the new IP address.
Though I have a static IP, I have to admit that this would be a pretty
useful feature. :-)
> I still need to clean up a few issues with my rc.firewall script, but
> overall I believe that it would be a great enhancement to the current
> distribution.
> Any thoughts ?
I have not reached anything near mastery in shell scripting, but if it is
possible to work around the issues mentioned above without have rc.firewall
beyond 1 Meg in size, I think this would a great improvement over the
current
situation, well worth to think about.
--
thomas. .powered.by.debian/linux.
.served.by.FreeBSD.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008901bf106d$4f227080$190aa8c0>