bootscripts

dagmar at speakeasy.net dagmar at speakeasy.net
Sun Sep 29 15:41:14 PDT 2002


On Sun, 29 Sep 2002, Henning Rohde wrote:

> Hi Dagmar,
> hi everybody else,
>
> dagmar at speakeasy.net wrote:
> > On Thu, 26 Sep 2002, Henning Rohde wrote:
> > ...
> >> But in privcate discussion I was convinced that it would be helpful to
> >> provide a suggestion about the _number_ of the symlinks: immedately after
> >> the creation / before the deletion of the [last/first] network interface.
> >>
> > ...
> > Firewall rules need to be able to put into place _before_ any network
> > initialization happens per RFC ...
>
> yes, you're right, they should be to be that.
>
> But I've seen a number of boxes where the $admin wanted them to do some
> (automatic) communication _before_ the firewalling-rules denied especially
> that kind of communication. Please do not argue about any sillyness of this
> kind of setup, I'd just like to be open for it.

Hey, it's not like they can rearrange symlinks to suit themselves.  I just
think it would be bad judgment to pre-configure the system for this kind
of vulnerability, especially when there's an RFC about how hosts which
function as routers should behave.  (although the honest truth about it is
that these provisions were not so much security provisions as they are
measures to prevent martian and other alien types of traffic from screwing
up routing gateways)

> BTW: as long as we consider a "virgin" box, with no services running that
> could be reached via network, to be _un_vulnerable there should be no
> window for an attack as long as firewalling is started before any service.
>
> We might argue on syslogd still running when firewalling is turned off:
> setups might exist where only the DMZ-server are, via firewalling rules,
> allowed to log to a log-server [e.g., printing them immedately to paper].
> There could be a tiny window, after firewalling was turned off while syslog
> is still running, for sending malicious packets the log-server.

The network interfaces should _already be down_ before the firewalling
would be turned off--which is why unless it's just a ruse before
proceeding back _up_ through another runlevel, there's no real point in
disabling the firewalling rules.  Thus, no window of this type should be
available.

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message



More information about the blfs-dev mailing list