Securing Debian Configuration checklist

• 
  Limit physical access and booting capabilities
  
  
  
  • 
    Enable BIOS password
    
  
  
  • 
    Disable floppy booting
    
  
  
  • 
    Set a LILO or GRUB password (/etc/lilo.conf or
    /boot/grub/menu.lst, respectively); check that the LILO or GRUB
    configuration file is read-protected.
    
  
  
  • 
    Disallow MBR floppy booting back door by overwriting the MBR (maybe not?)
    
  
  
  
  


• 
  Partitioning
  
  
  
  • 
    Separate user-writable data, non-system data, and rapidly changing run-time
    data to their own partitions
    
  
  
  • 
    Set nosuid,noexec,nodev mount options in /etc/fstab
    on ext2 partitions such as /tmp
    
  
  
  
  


• 
  Password hygiene and login security
  
  
  
  • 
    Set a good root password
    
  
  
  • 
    Enable password shadowing and MD5
    
  
  
  • 
    Install and use PAM
    
    
    
    • 
      Add MD5 support to PAM and make sure that (generally speaking) entries in
      /etc/pam.d/ files which grant access to the machine have the
      second field in the pam.d file set to "requisite" or
      "required".
      
    
    
    • 
      Tweak /etc/pam.d/login so as to only permit local root logins.
      
    
    
    • 
      Also mark authorized tty:s in /etc/security/access.conf and
      generally set up this file to limit root logins as much as possible.
      
    
    
    • 
      Add pam_limits.so if you want to set per-user limits
      
    
    
    • 
      Tweak /etc/pam.d/passwd: set minimum length of passwords higher (6
      characters maybe) and enable md5
      
    
    
    • 
      Add group wheel to /etc/group if desired; add pam_wheel.so
      group=wheel entry to /etc/pam.d/su
      
    
    
    • 
      For custom per-user controls, use pam_listfile.so entries where appropriate
      
    
    
    • 
      Have an /etc/pam.d/other file and set it up with tight security
      
    
    
    
    
  
  
  • 
    Set up limits in /etc/security/limits.conf (note that
    /etc/limits is not used if you are using PAM)
    
  
  
  • 
    Tighten up /etc/login.defs; also, if you enabled MD5 and/or PAM,
    make sure you make the corresponding changes here, too
    
  
  
  • 
    Disable root ftp access in /etc/ftpusers
    
  
  
  • 
    Disable network root login; use su(1) or sudo(1).
    (consider installing sudo)
    
  
  
  • 
    Use PAM to enforce additional constraints on logins?
    
  
  
  
  


• 
  Other local security issues
  
  
  
  • 
    Kernel tweaks
    
  
  
  • 
    Kernel patches
    
  
  
  • 
    Tighten up logfile permissions (/var/log/{last,fail}log, Apache
    logs)
    
  
  
  • 
    Verify that setuid checking is enabled in /etc/checksecurity.conf
    
  
  
  • 
    Consider making some log files append-only and configuration files immutable
    using chattr (ext2 filesystems only)
    
  
  
  • 
    Set up file integrity . Install debsums
    
  
  
  • 
    Consider replacing locate with slocate
    
  
  
  • 
    Log everything to a local printer?
    
  
  

  
  

  • 
    Burn your configuration on a bootable CD and boot off that?
    
  
  
  • 
    Disable kernel modules?
    
  
  
  
  


• 
  Limit network access
  
  
  
  • 
    Install and configure ssh (suggest PermitRootLogin No in
    /etc/ssh, PermitEmptyPasswords No; note other suggestions in text
    also)
    
  
  
  • 
    Consider disabling or removing in.telnetd
    
  
  
  • 
    Generally, disable gratuitous services in /etc/inetd.conf using
    update-inetd --disable (or disable inetd altogether, or use a
    replacement such as xinetd or rlinetd)
    
  
  
  • 
    Disable other gratuitous network services; mail, ftp, DNS, www etc should not
    be running if you do not need them and monitor them regularly.
    
  
  
  • 
    For those services which you do need, do not just use the most common programs,
    look for more secure versions shipped with Debian (or from other sources).
    Whatever you end up running, make sure you understand the risks.
    
  
  
  • 
    Set up chroot jails for outside users and daemons.
    
  
  
  • 
    Configure firewall and tcpwrappers (i.e. hosts_access(5)); note
    trick for /etc/hosts.deny in text
    
  
  
  • 
    If you run ftp, set up your ftpd server to always run chrooted to the user's
    home directory
    
  
  
  • 
    If you run X, disable xhost authentication and go with ssh instead; better yet,
    disable remote X if you can (add -nolisten tcp to the X command line and turn
    off XDMCP in /etc/X11/xdm/xdm-config by setting the requestPort to
    0)
    
  
  
  • 
    Disable outside access to printers
    
  
  
  • 
    Tunnel any IMAP or POP sessions through SSL or ssh; install stunnel if you want
    to provide this service to remote mail users
    
  
  
  • 
    Set up a loghost and configure other machines to send logs to this host
    (/etc/syslog.conf)
    
  
  
  • 
    Secure BIND, Sendmail, and other complex daemons (run in a chroot jail; run as
    a non-root pseudo-user)
    
  
  
  • 
    Install snort or a similar logging tool.
    
  
  
  • 
    Do without NIS and RPC if you can (disable portmap).
    
  
  
  
  






• 
  Policy issues
  
  
  
  • 
    Educate users about the whys and hows of your policies. When you have
    prohibited something which is regularly available on other systems, provide
    documentation which explains how to accomplish similar results using other,
    more secure means.
    
  
  
  • 
    Prohibit use of protocols which use cleartext passwords (telnet, rsh and
    friends; ftp, imap, http, ...).
    
  
  
  • 
    Prohibit programs which use SVGAlib.
    
  
  
  • 
    Use disk quotas.
    
  
  
  
  


• 
  Keep informed about security issues
  
  
  
  • 
    Subscribe to security mailing lists
    
  
  
  • 
    Subscribe to security updates -- add to /etc/apt/sources.list an
    entry (or entries) for http://security.debian.org/debian-security
    
  
  
  • 
    Also remember to periodically run apt-get update ; apt-get upgrade
    (perhaps install as a cron job?).
    
  
  
  
  

10 Steps to Securing you Server

So many people are getting their own dedicated servers but are completely clueless about security. Usually they leave it up to the company where they purchase it or hire someone. That's fine but make sure you have these 10 items covered.

1) Use a Firewall
Make absolutely sure that your server has a firewall running all the time. A firewall is like a screen door to your porch. It blocks out flies, rodents and other pests but you can still walk out and use your BBQ. If someone ever were to get into your server, which is very very likely, the first thing they're going to try and do is upload something to start a daemon or their own service like an IRC server or use a port to launch attacks to other systems. A firewall with egress and ingress protection can stop both incoming and outgoing attacks even when you're not aware of it. I recommend using APF on Linux systems or TinyFirewall on Windows Servers. These are software firewalls so there's no extra monthly cost like a hardware firewall. For very busy systems a hardware firewall is recommended so it takes the burden off your system CPU/RAM and resources to do the work.

Know what ports are open and why, know how to block and unblock an IP. These are basic things you need to understand in the daily security of your system. If someone from an IP begins a brute force attack you want to know how to stop them, right away. Installing APF Firewall, Preventing Brute Force Attacks, Installing KISS Firewall

2) Update your kernel and OS
Make sure your server is using current, updated software. Use the stable version which has been tested more than any beta and update as soon as possible. An old kernel can lead to an easy target for your server. If you're not sure then ask your provider for the latest update.

3) Monitor Logs
Do you know what logs record which activities? How often are they updated and rotated?
LogWatch is a great tool to email you the daily reports of your systems activity of anything it determines unusual, EG repeated failed logins. Besides using this you should check your logs manually to see what’s up. Tail –f /var/log/messages and view your Apache logs as well. Apache Log Files Explained

4) Backups
I still never understand why no one backs up their data yet you spend hundreds of hours working on your website or application then you absolutely must have a second hard drive for backups or use a remote back up system or a combination of these. Second Hard Drive Means Life or Death

5) Limit Access to a Minimum
Do not give users more access than the absolute minimum they require. Never give them shell access, restrict file access to a bare minimum and leave other services turned off by default until specifically requested and you determine that its safe to do so.

6) Lock down PHP and use Mod_Security with Apache
PHP is actually a large security risk but there are a few things to do to help lock it down. CGI has Suexec,which helps runs proccesess as the user and PHP has something similar called PHPSuexec but there are a few downfalls. You should also use open_base directory protection, have safe_mode on system wide, turn off register_globals, enable_dl and allow_url_open to help lock things down further.

You can use server wide protection with mod_security, a web server filter that can watch all requests to see if they match a rule and react by logging, denying the request or other programs. I highly recommend this on Apache based servers and can be extremely useful in blocking attacks and stopping hackers before they do any damage. Securing Safe Mode , Installing Mod_Security

7) Lock /tmp /var/tmp and /dev/shm partitions
On Linux each partition can have certain access restrictions. Since /tmp /var/tmp and /dev/shm are world writable directories they’re often home to uploads, sessions storage and hacker executables. Since anyone can read-write-excute anything from these directories it becomes a major security concern. With /etc/fstab however you can limit what can be done in these locations. If you see defaults beside the /tmp line remove it and replace it with noexec,nosuid this will stop any executables from being allowed to run. Do the same for /dev/shm and make /var/tmp and shortcut (symbolic link) to /tmp. Securing Your TMP Partition

8) Intrusion Detection System (IDS)
An intrusion detection system or IDS is like a burglar alarm on your server. It keeps a record of which files were changed when and alerts you of anything new or altered. This is critical because hackers usually try to replace binary applications like ps, top, netstat and others. This means when you run this new version of ps or top to see processes running they make it so it actually HIDES their hacker software, even though its running it won’t show up. Some IDS systems include TripWire, Snort and AIDE. Installing Chkrootkit

9) Review Processes Running and Remove Extra Software
You can’t protect a system if you don’t know what’s on it. If a hacker adds an extra process that you see in PS but you wouldn’t notice if you didn’t know what should be there usually. Know what runs on your system and why which user. How does Perl or Apache run, under which user? You can check your processes usually with top or ps auxfww which gives you a tree view. Check these every time you login to your server. Getting started with Shell (SSH) , Common Shell Commands

10) Keep an Eye on the Servers Performance
Know what speed your server is running at and how much bandwidth it uses on a daily basis. If an attacker compromises your system and you don’t know you’ll probably notice the system responding slowly or using a lot of bandwidth. If you don’t know what your system is usually like how will you notice something out of the ordinary. This is all common sense but some people never bother to check until they ask their provider after a system has been slow for 2 weeks – it’s usually to late then. Server Loads Explained

Knowing your system makes you one step ahead of an intruder. Check it often and ask an expert if you’re ever over your head. There are MANY other things you can and should do to ensure your server is secure but these are a few basics that everyone should use.