Hi ,
I've made a security checklist for my linux server (it runs in an Enterprise Environment).
What do you think? Do I miss something?




General Security Policies/Procedures

1. Use strong passwords (min. 6 chars, no dictionary words)
2. Eliminate unused accounts, delete well-known accounts that are not needed
3. Make sure default file protections for newly created files do not allow group/world read/write access by using a "umask" value of 022, 027, or 077, especially on the root account
4. Set appropriate file permissions on all files
5. Do not allow direct root login
6. Write-protect the "root" account's startup files and home directory
7. Do not place the current directory (".") in your (especially root's) search path
8. Do not use root account on a regular basis
9. Do not allow set-user-id or set-group-id shell scripts on the system
10. Do not mount remote filesystems with root rw access from the local system. ro access would be enough.
11. Set the "sticky" bit on any world-writable directories
12. Ensure the appropriate permission modes are set on devices in the /dev directory
13. Install an antivirus software and an IDS. Update daily the virus definitions and IDS definitions.
Ex: - ClamAV
- SNORT
- TrimWire
14. Implement a firewall (IPTABLES)
15. Monitor the firewall and its logs
16. Make backups and test them
17. Check your systems for unauthorized use of a network monitoring program
18. Allow SSH access only from a pool of IPs, and from a group of users. Do not allow root login.
19. Install latest patches
20. Verify the digital signature of every installing program or patch
21. Only a list of knows computers should be allowed to access the network and communicate with the servers (L2 authentication)
22. Bios password for the server
23. Physical access should be restricted to the server area


Regular Tasks

24. Audit account security on regular basis with tools like cops
25. Check logs on regular basis (every day). Logging all services and send summary on mail.
26. chkrootkit on a regular basis
27. Check for disk usage
28. Check for ports running
29. Examine the /etc/passwd file and search for 0 UID
30. Check for running services and close unneeded services
31. Check the system for altered binaries
32. Check all "nonstandard" set-user-id and set-group-id programs for security
find / -user root -perm -4000
find / -group kmem -perm -2000
33. receives security bulletins and notes from organizations like CIAC and CERT

Pretty comprehensive list. Does this server have a cdrom? If so, the only thing I saw not listed was to remove the drive/change boot device order in the bios.

You are right.
I forgot about the cdrom.

is it posible to monitor users files there use or browse and execute?
i know you can check failed logins, i am interested if you can check failed executive or other access.
i think vms does, surely *nix should.

Another question, is it possible to disable login for users after failed logins , failed executive and view(conf files etc...) attemps automatically ?


i guess anything is possible..

I see you mentioned 'restrict physical access' to the server area. However, not knowing exactly what that means in your situation, don't forget that if you have LILO installed, it needs to be made readable only to root [chmod 600 /etc/lilo.conf] and chattr +i /etc/lilo.conf. Also use a password in LILO by adding password=password.

If it is not password protected, any user can gain root access through physically shutting down/rebooting the system and entering

[label] init=/bin/sh (bringing the system up in 'rescue mode')
mount -oremount [root partition] (mounting the system as root)

If you password protect LILO and leave it readable to others, the file contains the password in plain text, making password protection pointless.

I'm sure you know this already as you are obviously familiar with Linux and security but thought I would mention it nonetheless.

If not of help to you, then perhaps someone else.

you are right. Having the boot loader password protected is very important.

Good advice !

By default, linux does not allow SUID shell scripts. Binaries are allowed, SUID scripts will not run.

--Shade

if you are using a password on your server's bootloader then if the server is rebooted you'll be driving across town to the office to type-in the boot password... IMHO, the recommended thing to do as far as the bootloader on a server is concerned is simply to make sure it doesn't prompt - this way a person wouldn't be able to do stupid stuff by entering parameters, like boot into runlevel 1, for example...

lastcomm and acctcom is a good solution to monitor users executed commands.

if a user tries to execute a command she/he knows he cannot access more than once, is it possible to log them out and disable there account automatically?