Re: Start up scripts
Henry Hollenberg speed@barney.iamerica.net
On Thu, 5 Mar 1998, Michael Meskes wrote:
> > what in the world is this construct? ": > /etc/mtab"
>
> Create an empty /etc/mtab.
What is the meaning of the ":", I can't find it in my O'reilly bash book
used this way.
> Wait a moment. We cannot remove module loading. We will need them for ip
> masquerading stuff.
IP masquerade can't be compiled into the kernel?
> Why? If you have no nfs filesystem in /etc/fstab this does no harm. If an
> intruder can change /etc/fstab though he/she can change teh boot script,
> too.
Slash and burn!, just kidding, but seriously the mindset i'm using:
Firewall Rule #1: If it's not needed get rid of it.
Because, it's just one more thing the hacker has to fix before they can
pull off an exploit....this takes them __time__.....which gives you some
more time to catch them via logs, tripwire etc.
Now you may argue that this particular situation has no concievable
exploit.....but I'd rather remove it now (if it's not needed for firewall
operation) than come back in 6 months and go "Oooooohhhhh, that's an
intresting exploit, I'd have never thought of that in a million
years....it...it's "inconcievable"!. If we leave these commands in place
then it just becomes a matter of the cracker getting the binaries they run
back in place and forcing a reboot. If you put your firewall systems on
an abcd keyboard monitor switch, and once running smoothly unplug them
from the keyboard and monitor....guess what happens when they force the
reboot....if you leave the bios at default the system hangs on reboot.
The network goes dead and here comes the Sys-Admin....pop in the CD-ROM or
floppy run tripwire...."BUSTED". Since they've had to patch up even the
start-up scripts to pull off their exploit it ought to be easy to see that
things are amiss even with a cursory examination. Of course there are
lot's more detection issues to be covered....I think Hubert is working on
that.
Now, I understand people being protective of the startup scripts....it's
reaching pretty deep into the guts of the system....but it is a valid area
to "clean up". If you never turn it on you don't have to worry about
protecting it. Personally I'm a pack-rat, hate to get rid of anything or
remove anything from my disk, but I'm trying to be discplined for this
exercise.
So, if it's not needed, and I don't think it is, why not just ditch it.
>
> > %%%% REMOVE: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > /etc/init.d/modules---->modutils No modules, custom kernel.
>
> No, that doesn't work as some modules cannot be build into the kernel.
Which modules are essential for firewall operation but cannot be compiled
into the kernel?
In my reading several have pointed out that you want no modules on a
secure system....just a cleaned up, custom kernel.
>
> > /etc/init.d/kerneld Ditto.
> > /etc/init.d/gpm Don't need a mouse on firewall.
> > /etc/init.d/lpd Don't need a printer on firewall.
> > /etc/init.d/ppp If ppp-needed=False.
> > /etc/init.d/netstd_nfs No NFS.
> > /etc/init.d/netstd_misc Don't need rwho or boot server.
> > %%%%% END REMOVE %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> Agreed on the rest. Although neither netstd script hurts with the correct
> configuration. I'd like to keep files of other packages untouched as much as
> possible since it makes upgrading so much easier.
>
> > Can't /usr/sbin/initd run stand-alone?
> >
> > I figure we need keep /usr/sbin/initd to invoke smtp services for
> > connection requests to port 25.
>
> I take it you're talking about inetd. But it's not needed for email at all.
> Just start your MTA as daemon. and inetd doesn't know about it at all.
> However, this prevents you from using tcp-wrapper on port 25.
Yeah, I've been wondering if we should use tcp-wrappers....if it would add
anything.....oh yeah, sorry for the typo, I did mean inetd not
initd....such lazy, insolent fingers. It's a wonder I get anything done
at all :-).
So I guess if tcpwrappers is an option we'll leave inetd in for now and
just comment out portmapper.
hgh
--
E-mail the word "unsubscribe" to debian-firewall-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? e-mail to listmaster@debian.org .
Reply to: