Date: Sun, 25 Feb 2001 12:13:18 +0000 From: Marc Rogers <marcr@closed-networks.com> To: freebsd-security@FreeBSD.ORG Subject: Re: /etc/rc.firewall fixes Message-ID: <5.0.2.1.0.20010225114958.00b10858@pop3.demon.co.uk> In-Reply-To: <3A982224.893F76AF@gorean.org> References: <200102202005.f1KK5kv83619@medusa.kfu.com> <3A93A9CC.BC1D39FB@algroup.co.uk> <3A93C2FB.3E160997@ocsinternet.com> <3A94AE05.965BC5E4@gorean.org> <3A9526AA.19D00D47@ocsinternet.com> <3A954152.C7887C3@gor.com> <3A97A4E6.C53ECF27@algroup.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
At 13:05 24/02/2001 -0800, Doug Barton wrote:
>Adam Laurie wrote:
> >
> > Doug Barton wrote:
> > >
> > > Mikel King wrote:
> > > >
> > > > rc.conf.local and rc.local weree deprecated around the release of 4.x.
> > >
> > > Don't be silly. Both are fully supported, and there is no
> plan to remove
> > > support at any time in the future (and I will vigorously oppose any
> plan to
> > > do so). The only thing that has actually changed is that the system no
> > > longer ships with an rc.local file installed.
> >
> > so what's the point in putting it in there instead of rc.conf then?
>
> The original question I responded to suggested putting the
> settings for
>rc.firewall into a whole new conf file. My point was that there were
>already several locations that would be more appropriate.
>
>Doug
I agree. This thread seems to have gotten sidetracked.
Im still going to chuck in my two-pence worth though....
"Typically, the /usr/local/etc/rc.d mechanism is used instead of rc.local
these days but if you do want to use rc.local, /etc/rc still supports
it. In this case, rc.local should source /etc/rc.conf and contain
additional custom startup code for your system."
- /usr/bin/man
"The file /etc/rc.conf.local is used to override settings in /etc/rc.conf
for historical reasons."
- /usr/bin/man
If my interpretation of that is correct, then rc.local and
rc.conf.local have been left in to support people with existing setups so
they don't have to move to the preferred rc.d mechanism immediately. The
simple fact that they have been left in for historical reasons &
alternative newer mechanisms suggested means to me that they have been
depreciated. Thats just my interpretation though.
Also, and more importantly rc.local / rc.conf.local / rc.d are there
for "local" configurations. What we are discussing here is a potential
commit to all FreeBSD configurations and as such would be far more
appropriately placed within the rc.conf mechanism.
anyway thats my two-pence worth on that.
I would like to see configuration code for ipfw AND ipfilter placed into
rc.conf (and thus ipnat as well as natd). Anyway I wont hold my breath for
a commit.
By the way keeping state on UDP connections is a bad idea. UDP is
stateless. Tyring to make it otherwise opens you up to all kinds of abuse......
"Held UDP state is timed out, as is TCP state for entries added which do
not have the SYN flag set. If an entry is created with the SYN flag set,
any subsequent matching packet which doesn't have this flag set (ie a
SYN-ACK) will cause it to be "timeless" (actually, the timeout defaults to
5 days), until either a FIN or RST is seen"
-http://coombs.anu.edu.au/~avalon/examples.html#packetstate
Marc
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?5.0.2.1.0.20010225114958.00b10858>