Friday, June 22, 2007

Unix Administration (II): Security (B)

Here's the second step of securing our college server as mentioned in the first article (II - A). I try to construct a suitable security policy using the lovely and completely flexible PAM configuration files. I assume that the reader have previous experiences with PAM, if not, please look at this very well-written and official PAM guide.


--> First step is to modify the common-{auth, account, password, session} files since they are included in all specific programs PAM files.

01- Don't accept NULL passwords in any program by removing the nullok option:
In /etc/
pamd.d/common-auth file:
auth required pam_unix.so

02- Disallow root logins from anywhere (pam.d/su will be modified not to include common-auth):
emptying the /etc/securetty
:
$ : > /etc/securetty
In /etc/pam.d/common-auth:

auth requisite pam_securetty.so

Note: Emptying the securetty file without adding the above line will have no effect.

03- Let only users set on /etc/security/access.conf be able to login (assuming they already passed the above stacked rules).
In /etc/security/access.conf:
# Accept `root' and `ahmed' logins only (till the system go mainstream)

+:root:ALL
+:ahmed:ALL

-:ALL:ALL
In /etc/pam.d/common-account:
account required pam_access.so

04- Enable large passwords (> 8) by using MD5. Also let user chosen passwords
be tested by cracklib which checks user desired passwords against dictionaries and other common password patterns.
$ #
Several dictionaries to be used by cracklib
$ apt-get install wbritish wamerican wfrench wdutch
$ # cracklib installation. If PAM rules are set without it, no passwords could be changed!
$ apt-get install cracklib2

$ # Install the pam_cracklib module
$ apt-get install libpam-cracklib

Add the PAM rules to satisfy the following conditions in desired passwords:
a- Minimum difference between a new and old password = 4
b- Minimum length = 12
c- Prompt user at most 4 times before running with error

d- At least 2 digits, 2 upper case letters, 2 lower case ones and 2 other (!#$...) letters
In /etc/pam.d/common-password:

password required pam_cracklib.so retry=4 minlen=12 difok=4 \ dcredit=-2 ucredit=-2 lcredit=-2 ocredit=-2
password required pam_unix.so use_authtok md5

Note: The use_authtok directive is necessary to hand over the password
from the previous module

05- Many programs use $TMPDIR for storing temporary files. Not all of them are good at securing the permissions of those files. PAM tmpdir module sets $TMPDIR and $TMP for PAM sessions to /tmp/user/[uid]. Permissions are tight since /tmp/user is only read/write by root. /tmp/user/[uid] is only {read, write, execut}able by that user.This leads to an extra layer of security, making symlink attacks and other /tmp based attacks harder or impossible.
$ apt-get install libpam-tmpdir

in /etc/pam.d/common-session:
session optional pam_tmpdir.so

06- UMASK usage in login.conf is discouraged cause it catches only entries made through login, while setting umask in shell rc files will catch also logins through su, cron, ssh but not other shells. At the same time, using shell rc to set umask won't catch entries which user uses non-shell executables in place of login shell, like the ppp daemon. To solve all of this ambiguity and redundancy problems, it's best to use the pam_umask PAM module.

$ apt-get install libpam-umask
In /etc/pam.d/common-session:
session optional pam_umask.so umask=007

--------------------

--> Second step is to modify the pam.d/others file. if a PAM-aware service exists with no specific PAM file, the `other' file will be used. This file will deny all services but issue a warning in the logs to the sleeping admin! ( not my type, right ? ;) )

$ : > /etc/pamd.d/other
In /etc/pam.d/other:
auth required pam_deny.so
auth required pam_warn.so

account required pam_deny.so
account required pam_warn.so

password required pam_deny.so
password required pam_warn.so
session required pam_deny.so
session required pam_warn.so


--------------------

--> Third step is to modify the PAM files related to each PAM-aware app as follows:

1- Login, ssh:

01- Remove System details from login/ssh screens

In /etc/pam.d/login:
session optional pam_motd.so motd=/etc/motd
$ cat > /etc/motd.tail

If any problem is found, contact Ahmed S. Darwish - the server admin - at darwish.07 gmail com
Thanks
^D

$ # /etc/motd is a symbolic link for /var/run/motd
$ sed -i 's#uname -snrvm > /var/run/motd#: > /var/run/motd/#' /etc/init.d/bootmisc.sh
$ cat > /etc/issue

Faculity of Computer Science and Information Unix Lab
^D
In /etc/pam.d/login:
auth required pam_issue.so issue=/etc/issue

02- Passwd:
Above customized defaults in common-password are enough.


03- su:
01- Let root be able to do "su" to anything
auth sufficient pam_rootok.so


02- Let the group "wheel" (gid = 0) be the only group allowd to invoke a
`su' to root.
$ groupadd wheel && usermod -G wheel ahmed
In /etc/pam.d/su:
auth required pam_wheel.so use_uid


03- Don't use the customized defaults found in common-auth since it does not allow root logins. If it's included, as in the out of the box configuration, you won't be able to access root by any means (except by using init=/bin/sh as a kernel parameter).
$ sed -i 's/@include common-auth/#@include common-auth/' /etc/pam.d/su

$ echo "auth required pam_unix.so" >> /etc/pamd.d/su


I hope you found this article interesting.

To Be Continued ...

1 comments:

Michael Kropat said...

Very helpful article. This will probably become my default procedure for setting up PAM.

For limited purpose, stripped down servers, PAM is one of the key areas I try to lock down (along with root or otherwise privileged daemons, and setuid binaries).