Securing SuSE Linux 7.3
Hello! It's my duty to set up an internet server with SuSE Linux 7.3. I want to ensure that it is as secure as possible. First thing was of course thinking of not to use SuSE Linux but instead install a little Linux From Scratch system (www.linuxfromscratch.org) with only a few files really needed to run a webserver. But then I am be sure if ColdFusion and some other applications/programs/modules would run correctly. So the decision was SuSE Linux 7.3 for x86. Dual PIII 1,13GHz, 1GB ECC SD-RAM, 2x 17GB SCSI ... First I installed 7.3 minimal (but I took around 200MB space, a lot for a minimal installation I think) + ProFTP, Sendmail, MySQL, Apache, PHP, Perl, SuSE Firewall2, harden_suse. What I did to secure the system: 1. run harden_suse with all options enabled. 2. compiled new kernel 2.4.18 with LIDS (lids.org) support. 3. secured all directories readonly except /dev, /var, /tmp, /proc 4. denied files like /etc/shadow except for su, login, proftp, sshd readonly 5. secured .bash_history, /var/log/firewall, /var/log/messages as append only 6. disabled capabilities like mknod, rawio ... And to keep track of what is going on: 1. weekly mail with all important logfiles 2. lids provides a port scan detector and to send a mail to me, if something is goning wrong in the system. Is this enough to avoid crackers to change my system? I know, that nothing is nearly 100% secure, but I think if no one (root included) can change system files it should be quite secure also if some breaks into the system and gets root privileges. I think If I'll always install the newest SuSE security updates the system would be only a few days unsaved. If then someone would break into, s/he could not damage that much, I hope. Best regards, Thomas
On May 21, Thomas Föcking
I think If I'll always install the newest SuSE security updates the system would be only a few days unsaved. If then someone would break into, s/he could not damage that much, I hope. Do you mean the time difference between the public announcement of the vulnerability and the patch release, or the time difference between patch release and patch installation? To keep the latter short, you should use fou4s (fou4s.gaugusch.at).
And there is one thing you didn't mention in your original posting: Backup!! You also didn't tell us, which services you are offering. Web only? User authentication? SMTP/POP/IMAP? ... Every service that is used to authenticate users should use encryption (SSL/TLS). regards, Markus -- _____________________________ /"\ Markus Gaugusch ICQ 11374583 \ / ASCII Ribbon Campaign markus@gaugusch.at X Against HTML Mail / \
* Thomas Föcking wrote on Tue, May 21, 2002 at 16:45 +0200:
But then I am be sure if ColdFusion
Do you trust this as secure?
2. compiled new kernel 2.4.18 with LIDS (lids.org) support.
I do not know what LIDS does exactly but I think it was a good idea to use it ;)
3. secured all directories readonly except /dev, /var, /tmp, /proc
Does lids prevents the chmod call? Usually root can open files anyway AFAIK, does LIDS prevents this?
4. denied files like /etc/shadow except for su, login, proftp, sshd readonly
How does this work? Matching based on binary name? What happens when doing a execl("/tmp/evil", "/bin/login", "params")? What happens when having a evil /tmp/login or so?
5. secured .bash_history, /var/log/firewall, /var/log/messages as append only
Does bash handle append-only history files correctly?
And to keep track of what is going on: 1. weekly mail with all important logfiles
weekly? Usually attackers clean up logs after breaking in...
2. lids provides a port scan detector and to send a mail to me, if something is goning wrong in the system.
port scan --> email? I think you'll get a lot of mail :)
Is this enough to avoid crackers to change my system?
If this host is not networked, it's suffcient. Otherwise, it is not secure of course, since it's never secure.
I know, that nothing is nearly 100% secure, but I think if no one (root included) can change system files it should be quite secure also if some breaks into the system and gets root privileges.
Yes, but with www-run (or whatever) priviledges he/she may get interesting information, for instance HTTP passwords and such, and who knows what other tricks are possible. You're right, it is not 100% secure. But it's more secure than many other systems :).
I think If I'll always install the newest SuSE security updates the system would be only a few days unsaved. If then someone would break into, s/he could not damage that much, I hope.
Theoretically she/he can, with a nice rootkit (I don't know if there are some for LIDS protected systems available) your system is lost. If you don't notice that it is compromised it doesn't help if you install a security update afterwards. But if you have good tape backups of the user data an successfull attack is not a big problem, only unpaid work... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
3. secured all directories readonly except /dev, /var, /tmp, /proc
Does lids prevents the chmod call? Usually root can open files anyway AFAIK, does LIDS prevents this?
chmod on files and directories in readonly protected directories is not possible.
4. denied files like /etc/shadow except for su, login, proftp, sshd readonly
How does this work? Matching based on binary name? What happens when doing a execl("/tmp/evil", "/bin/login", "params")? What happens when having a evil /tmp/login or so?
Read the lids faq and you know that this would not work. You once create a file with rules. In the rules there are no path or file names, but the inodes of them. So if /bin/login wants to access /etc/shadow lids (of course the kernel) checks if the inode (once saved from shadow) is allowed to access the inode (once saved from login). So if the inode changes (e.g. update of login) then this list must be updated else login would not be allowed to access shadow anymore, becuase the inode is not the same as in the list.
5. secured .bash_history, /var/log/firewall, /var/log/messages as append only
Does bash handle append-only history files correctly?
Yes. First the bash stores your history in memory but on exit it appends the history to your current .bash_history. And if bash would try to overwrite it, it could not to this... The same with the log files.
And to keep track of what is going on: 1. weekly mail with all important logfiles
weekly? Usually attackers clean up logs after breaking in...
They can't! log files are append only. Only once a week the log files a cleared by a program that has this privilege. (but first sent to me of course; and archived as tar.bz2)
Theoretically she/he can, with a nice rootkit (I don't know if there are some for LIDS protected systems available) your system is lost.
No one - root included - can install any programs. Again: The whole filesystem (/ /sbin, /bin, /opt. /usr/ ...) is ReadOnly. If I want to install a security patch, I cannot do this of course. I must first disable the lids protection for my console. (with a very long and strong encrypted password which is stored in a part of the filesystem that also root cannot access. like it works with the /etc/shadow) Regards, Thomas
participants (3)
-
Markus Gaugusch -
Steffen Dettmer -
Thomas Föcking