-   Slackware (
-   -   Slackware hardening guide (

tangle 03-09-2005 01:52 PM

Slackware hardening guide
I found this guide quite a while ago.

It is a couple years old and some things have changed. I have used it as a guide to harden a few servers.

I have been thinking about upgrading it for Slackware 10.0 and/or 10.1. There are somethings in it that I do not understand. So, when I get a rough draft done. Is there anyone here willing to look it over and give me feed back or make corrections?

I have a real rough draft right now and I just need to clean it up. So I can post it on the web by the weekend.

jxi 03-09-2005 02:24 PM

i'll be glad to review it as I'm currently working on a slack equivelent of the CIS RH9 system hardening document (found at:)

Genesee 03-09-2005 03:46 PM

you can post it here, and then as a linux answer when it's done. or you can do it as a wiki article (, and post a link to it here - there are lots of people here to help edit.

tangle 03-11-2005 08:55 PM

I threw together the rough draft. It is here:

jxi 03-14-2005 09:47 PM

first, my disclaimer: I'm not a sysadmin or my any means an expert. I'm learning linux (like a lot of us here at LQ)

regarding the changes to /etc/rc.d startup scripts: in most cases the lines targeted for commenting out aren't going to do anything if the specified service doesn't have an executable
/etc/rc.d/rc.SOMESERVICE. E.g., in /etc/rc.d/rc.S the reference to isapnp (mine starts on line 192 btw)
needs (line 193) a /etc/rc.d/rc.isapnp with the execute bit(s) set. Could you accomplish a lot of these changes by simply chmod -x rc.SOMESERVICE? Wouldn't that be like chkconfig in redhattish distros?

viz: in rh i might say `chkconfig --level 35 xinetd off` which would simply remove the links with names like /etc/rc3.d/S56xinetd /etc/rc5.....

that way you minimize the chance of some typo in your init scripts: leave them as close to the original as possible.

exceptions to this : rc.S - continue to comment out writing over motd (line 283 in my 10.1 install)
rc.M - apm (it looks for [ -x /usr/sbin/apmd ])
rc.M - atd ( [ -x /usr/sbin/atd ] )
...(you could also chmod -x those binaries but it would be a pain to keep track of)

the cis benchmark guide mentioned above recommends also disabling gpm . i'm not sure why it's a risk.

rc.inet2: (reference to line 20) instead of commenting out mounting of nfs (and samba at line 49) you can just ensure that the nfs (and smbfs) mounts in /etc/fstab are commented out (or don't exist at all).

all these are just suggestions. if the proper permissions / immutable attributes are set in /etc/rc.d I don't think the above is necessarily insecure (if someone can get in and change the permissions back to
executable they could do a lot more besides...)

Just one more thought here (perhaps along the line of making it more n00b friendly):
even though at the beginning of the original document there is sufficient warning and a reminder to 'make a backup of anything ...important' chances are some will launch right in without doing a backup. you might have a script at the beginning that would explicitly reference all possibly targeted files
e.g. for F in /etc/password /etc/shadow /etc/hosts.allow....... do cp -v $F $F-preHardN
I can post the ones I used with slack 10.1 recently but they won't contain everything referenced here.
(that's straight from the CIS benchmark document. Bastille, as another example, does it automatically, saving the original of each changed file in /var/log/Bastillerevert/backup/...)

finally, I wish you all success in completing your document :)


All times are GMT -5. The time now is 01:05 AM.