ClueNet is looking for a new Chief Technical Admin. More information here.

Shellsnet:SN Admin ServerSecurity

From ClueWiki

Jump to: navigation, search

Important Note: This is a backed up copy of what existed on Shellsnet's old wiki.

This article is a part of the ShellsNet Old Wiki Backup index

Do not modify this page!




This page lists essential security precautions that admins should take when setting up a shell server.

  • Notes about this document
    • This document is intended as a suppliment, NOT as a replacement, for other documents. You have to read it WITH the documents in the 'links' section.
    • This document is geared to shell server admins only.
    • This document is ONLY a list of condensed notes about *some* of the important things shell admins should do for their security. IT IS NOT A COMPLETE LIST.
  • Pre-install
    • Operating Systems
      • Choose a system that is made for servers. "desktop" distros like Mandrake and Redhat typically make poor server operating systems due to their insecurity and reliance on the GUI.
      • For newer admins : Debian, or possibly Gentoo [note: anyone considered [SELinux]?
      • For more experienced admins : [[Shellsnet_Backup_Old_OpenBSD%252FFreeBSD|OpenBSD/FreeBSD]][[Shellsnet_Backup_Old_SN_Admin_ServerSecurity%252FSlackware|/Slackware]]
      • The first group have good power, and good ease of use. The second group may have more power, but are defianately harder to admin. [note : someone should write a pros/cons for each os -- Done. Pros And Cons]
      • In general, go with the version which is stable, not devel, becuase it has regular updates but new holes aren't found all the time.
      • If you don't go with the up-to-date version, make sure you apply ALL patches.
      • Whatever OS you use, subscribe to its official mailing list so you're notified of new patches/exploits, etc.
    • Policy
      • There are some either/or choices in system administration, for example : do you allow users to compile/run their own programs? Your answer to this question will dramatically effect your subsequent security policy. Some of these questions are :
        • What services you run (e.g, do you allow remote mail access via IMAP/POP? Compiling? How about user websites? With what features?)
        • If your services are default-allow (e.g. users can use X unless you say they can't) or default-deny (users have to get prior permission to use X)
        • You should consider these questions before you install, to avoid having to reinstall later to get a different setup.
      • In general, I (<censored>) suggest going with the MOST secure default configuration to start with, becuase once a system is set up it's much easier to make it less secure then more secure!
  • During-install
    • Partitioning
      • Make sure you seperate all the user-writable areas of your disk from the not user-writable areas.
      • Set all the user-writable areas noexec, or at the very least, nosuid.
      • Consider symlinking /var/tmp to /tmp and so on to eliminate duplicate areas for easier control.
      • Consider moving things like /var/mail to /var/spool/mail to keep all user-writable areas on /var/ under /var/spool
    • Base System config
      • Limit root logins to console or via su - don't run any daemons until you've got the base system secure.
      • limits.conf/login.conf/ulimits/umask
        • Set good ulimits for your users. TEST them yourself, sometimes they have side-effects.
        • Pick a umask for your users and one for yourself - be careful about your umask when you're installing software!
      • adduser.conf / custom adduser script
        • Fix your adduser.conf
        • Consider a custom script to add users... you may need one to make sure everything (like their quotas, sshkey and webdir) is set up.
      • chmod for files
        • Find and eliminate as many suid/sgid files as is safe
        • Find logfiles, chmod them, and fix any scripts that create them with loose permissions (like logrotate)
        • Find executables that give system info, like netstat, and stop users running them if you like. FreeBSD has a security.bsd.see_other_uids sysctl that you can set to 1 to prevent users from viewing anything but their own open files and processes. There are also patches that do the same thing for OpenBSD systems.
      • kernel config / modules / capabilities
        • Consider removing module capability from kernel to prevent LKM rootkits
        • sysctl settings, if you have them, need checking
        • consider your securelevel (BSD)
        • consider patching your kernel with something like grsec (linux)
      • Quotas (filesystem:filesize/inodes)
        • Make sure all users have quotas for all filesystems, even the ones they're not meant to be able to write to, so that even if they find a way, having a 1 block quota stops them.
        • Create a quota template user and then use edquota -p in your new user script to make sure all users get a quota on creation.
      • Shells
        • Consider limiting your users to one, secure shell, to ease management.
        • Lock up everything to do with .bash_history variables in both login and non-login shells. Consider using chattr/chflags to make it append-only.
        • Check ulimits again, they really matter.
        • Consider providing some built-in aliases to help new users.
      • Logging user commands
        • Consider pa, the BSD process accounting system, if you can use it.
        • Otherwise, consider the 'snoopy' package, which logs all user commands.
        • Consider the size of the logs you'll end up with.....
    • Daemons
      • sshd
        • Use skey, instead of passwords, for user logins if possible.
        • Deny root logins, empty passwords, and ssh protocol 1.
        • Limit concurrent unauthenticated sessions (MaxStartups), and time out idle sessions (ClientAlive*)
        • Use sftp (built into sshd) to replace ftpd.
        • Use "Banner" to display a warning banner to users before they log in which gives you legal grounds to prosecute crackers [information]
      • httpd
        • Use suphp.
        • Use suexec.
        • Use php's safe_mode's open_basedir, OR chroot your entire apache install, OR put your Apache installation in a jail (FreeBSD).
        • Use logging (for access as well as errors).
        • Use mod_security, and TEST your config of this module.
        • Check your file permissions, quotas, etc on UserDir space.
        • Check that mail sent as httpd shows the user sending it, not just www.
        • Make sure you turn allow_url_fopen off in your php.ini
        • Consider disabling some PHP functions (phpinfo(), etc)
      • smtpd
        • Pick a secure mailer. Postfix, Qmail, and exim are good bets. Avoid sendmail.
        • Chroot the mailer if possible.
        • Check your file/device/network permissions relavant to the mailer.
        • Make certain that your mailer is NOT an open relay. If you want to allow relaying, make sure you authenticate users (SASL)
        • Consider using TLS, especially if you are allowing relaying
        • Use dnsbls to filter spam (spamhaus.net, sorbs, etc)
        • Make sure the mailer notifies you of errors.
        • Make sure you configure root@, postmaster@, etc aliases correctly
        • Consider mail quotas, spam filtering and an alias to send mail to all users on your system
      • identd
        • pidentd is suggested for new admins, oidentd for more advanced admins.
        • Whatever identd you use, it must always return true usernames. pidentd does this by default, Oidentd requires 'deny' for all keywords in /etc/oidentd.conf
        • Make sure your identd logs, you can pick up a lot of interesting stuff (like outgoing floods, glines, or broken bots) this way.
      • IDS
        • Consider tripwire or AIDE to help you detect intruders.
      • Blacklist
        • Do not install telnetd (use sshd instead)
        • Do not install ftpd (use sftp in sshd instead)
        • Do not, in general, have any form of unencrypted network login.
    • Firewall / Network
      • Remember to default deny/drop.
      • Remember to consider something like portsentry, scanlogd, or OBSD's PF's Overload feature, to detect packet attacks.
      • Remember to write rules for outgoing connections made by users.
      • Get a static IP with rdns from your ISP if possible. Many network services limit access by those without rdns (e.g. some mailservers do this).
      • There are other benefits to having a static IP, it allows you to use SSL certs to encrypt access to your website (for example, for phpmyadmin access...)
    • Other programs
      • Logsentry
        • Install, run hourly, make sure you set the ignores to filter out junk so that you get only the stuff you have the patience to read.
      • Update Manager (e.g. cron-apt)
        • Install, make sure you run this at least daily.
      • CRON / AT
        • Consider making a cron.allow (or cron.deny) and only adding trusted users to the allow list. The same goes for at.
        • If you're not going to use, for example, 'at', then remove it from the system. Better safe then sorry.
      • Custom Monitoring Scripts
        • Various admins (e.g. <censored>) have written custom-made packages of shell admin tools, limiting memory, cron, network, etc usage per-user. Ask if interested.
        • Google for tools others have written, often, there are existing tools for things admins want done.
    • Hardening
      • Consider a hardening package like, for example, Bastille, or debian's 'harden' package.
      • Be aware that some of these packages make bad suggestions.... for example, 'harden' doesn't like 'identd', and identd is VITAL for a shell server.
      • Try to understand both why the packages make the reccomandations they do, and also why they make mistakes, to improve your understanding of security.
  • Post-install
    • Lock-down
      • Use systrace/strace/securelevels/etc to lock your system into the clean, post install state, to limit future changes.
      • Consider making some filesystems (like /bin?) read-only at this point.
      • In general - look to do things that lock up the server and which can only be circumvented by gaining root, changing files AND rebooting - so you'll notice any intrusion.
    • Maintenance
      • Update your OS to new versions after they've been tested for a month or two.
      • Make sure most of the maintenance (e.g. software upgrades) is done automatically (e.g. via apt-get update)
    • Backups
      • Use something like rsync for regular, automatic, backups to another machine.
      • In general, you'll want to backup config files and similar important but small files first.
  • Links
Retrieved from "http://www.cluenet.org/wiki/index.php/Shellsnet:SN_Admin_ServerSecurity"
Personal tools
Server information
Useless