suse@xxxxxx wrote:
How to prevent flushing /tmp? What can be done to secure a system and prevent unwanted actions to be done?Quoting John Richard Moser <nigelenki@xxxxxxxxxxx>:| Keep creating hardlinks until /tmp runs out of space or out of inodes. nr_inodes= is your friend. | Ext2/3 allow ~65000 hardlinks per file, ReiserFS allows ~2billion, so | flooding /tmp isn't a problem. Quotas don't help either since the | attacker doesn't own the file. The only thing that helps are special | hardening patches (OpenWall, GRSec) or special permission patches | (SELinux, RSBAC), but not everybody uses them. | | This attack can be truly annoying since it fills up /tmp and may keep | Apache from working. But with your setup (/tmp on tmpfs) it will bring | the server to a grinding halt where you can't even login remotely to fix | the server (assuming you don't have physical access). | | nordi | you raise interesting points. We should clip these issues off at the source.While this discussion of how to flood /tmp is interesting, it's also rather silly. Does anyone really allow any critical services to get anywhere near /tmp these days? The idea of a single area where everything writes to probably sounded great twenty years ago, but these days, each critical service gets own sandbox to play in and never the twain shall meet. If someone were to somehow overflow /tmp on any of my servers, the only impact would be a note in the syslog... Using /tmp for anything that matters is just asking for trouble... PS: Mounting /usr read-only would be fine if you only managed one or two servers. When you manage two dozen, it quickly becomes too much of a pain in the ass when you have security patches for those read-only files. Mount /usr remotely on all of them from a single source and patching that is a great theory until you realize that a single problem can wipe out your whole machine room...
1) Secure /tmp in /etc/fstab, e.g. /tmp = hda6: /dev/hda6 /tmp ext2 rw,nosuid,nodev,noexec 1 2 other sources: http://www.webhostgear.com/34.html This doesn't prevent /tmp from beeing flushed, but secures it a littlebit. 2) Limit users rights: man limits.conf This even doesn't prevent /tmp beeing flushed, but limits users right, if shellaccess is needed. 3) Set shell to /bin/false for FTP only users /etc/passwd userxy [...] /bin/false This prevents from logging in and doing funny tings. Normally a webserver account only needs ftp access or secure with ssl enhanced ftp. FTP-Server with ssl enhancement: http://sourceforge.net/projects/wzdftpd/ http://sourceforge.net/projects/indiftpd/ Or install secure bash without shell, e.g.: http://www.air.rzeszow.pl/bash-2.05b-secure/ 4) Use secumod to prevent creation of sym- and hardlinks. There are other kernelpatches/-modules out there doing the same. This prevents /tmp to be flushed with symlinks. 5) Further protection: set quota for tmp (this is no symlink protection, but limits user's space on tmp) 6) Run daily scripts as cron-job for /tmp or run logout-scripts. Examples should be found with google: http://www.cs.arizona.edu/computer.help/policy/DIGITAL_unix/AA-PS2HD-TET1_html/uc8.html Maybe you change attributes of the fs (chattr/capbits ...) so the unwanted action cannot be done. This attribute you don't see with ls command. lsattr lists the attributes set. Example for chattr: http://www.theparallax.org/security/linux/chattr.html (only in german - damn) Be careful with this, because this settings even are set for root (e.g. to disallow root to do things). It is even possible to lockout root and give rights compareable to "root" to different users. This makes problems administrating systems and running services, depending on how far you go. 7) If you program your own php-scripts for your webserver look for secure programmingstyle and secure your php.ini. 8) On the webserverside disable "follow symlinks" option (this may lead to other security-issues). No system can be made 100% secure, but this helps making it a little bit more difficult for malicious people to alter your system. Philippe -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@xxxxxxxx Security-related bug reports go to security@xxxxxxx, not here