I’ve been blogging about things related to me moving my blog not a new server and hosting in Amazon Web Services (AWS). So far I’ve liked the environment a lot, although I’ve had some issues with AWS terminology their documentation is extensive and usually very clear, which helps a lot.
One of my main concerns has been securing my server. I’ve always been a bit paranoid in this regard, but I think this is more of a feature than a bug in my personality so today I making a long post on the basics steps one can take to Harden/Secure your Linux (Debian) server.
NOTE: Most things apply to other Linux distributions but you may have to check the commands to match your distribution.
Server Security 101
Some points to consider
- Identify your attack surface: This step may seem trivial or obvious but properly identifying the attack surface can help you decide what you need to secure. Make a list of the services, daemons, etc that need network access (SSH, HTTP, SFTP, NFS, etc) In my case I’m running a blogging Web Server and I use
- Research for guides to secure your distribution: This step is crucial since distributions may have different ways of working and having a guide tailored for this can help. For Debian you can find the guides in here
- Before rolling changes make a backup: Making changes to your current set up will need testing before using in production, be sure to have backups ready.
Lets get this done!
An intelligent partition scheme depends on how the machine is used. (From Debian Guide)
- Any directory tree which a user has write permissions to, such as e.g. /home, /tmp and /var/tmp/, should be on a separate partition. This reduces the risk of a user DoS by filling up your “/” mount point and rendering the system unusable (Note: this is not strictly true, since there is always some space reserved for root which a normal user cannot fill), and it also prevents hardlink attacks. 1
- Any partition which can fluctuate, e.g. /var (especially /var/log) should also be on a separate partition. On a Debian system, you should create /var a little bit bigger than on other systems, because downloaded packages (the apt cache) are stored in /var/cache/apt/archives.
• From a security point of view, it makes sense to try to move static data to its own partition, and then mount that partition read-only.
In Linux you can force the file system to mount a partition with some restrictions. Those restrictions can be used on a mount command as option or on the
Note that some mount options are filesystem specific. The most common options are:
I’ll enumerate the ones we will focus on. (Click here for a more complete list)
noexec– Disallow execution of binaries on the filesystem.
ro– Mount the filesystem read-only.
rw– Mount the filesystem read-write.
nouser– Allow only root to mount the filesystem.
nodev– Don’t interpret block special devices on the filesystem.
nosuid– Block the operation of suid, and sgid bits.
defaults– the default mount options for the filesystem to be used. The default options for
For example I have a partition I use whose only purpose is to store backups, hence it has no need for most options. Here it’s how it looks
/dev/xvdf /serverBackups ext3 rw,relatime,errors=continue,nosuid,noexec 0 0
This tells the system to mount:
- Device: /dev/xvdf/
- Mount Point: /serverBackups
- FileSystem: ext3
- Options: rw,relatime,errors=continue,nosuid,noexec
- The last 0 zeros tell the system not to use dump for backups and not to check them with fsck.
Your set up depends on how you use or like your system.
Sample Partion Scheme
- /tmp – Set nodev,nosuid,noexec
- /home – Set nosuid, and nodev with disk quota option
- /usr – Set option nodev
- /var/log – Set nodev,nosuid,noexec
For more information on
/etc/fstab check this.
This days almost all flavors of Linux have SSH included and on by default. SSH allows you to connect and administer your server remotely in a secure way. Still you can further increase the security of your server by tweaking the configuration.
To make the changes just open the configuration file and reload/restart the service(when your done)
I recommend you open the file and check if the directive already exists before attempting the change.
Configuration Files and Port
On most systems you can find SSH files in here
- /etc/ssh/sshd_config – OpenSSH server configuration file.
- /etc/ssh/ssh_config – OpenSSH client configuration file.
The default port is
- SSH default port : TCP 22
Configuration Changes (Server file /etc/ssh/sshd_config )
Use SSH 2 Only
SSH protocol version 1 (SSH-1) has man-in-the-middle attacks problems and security vulnerabilities. SSH-1 is obsolete and should be avoided at all cost. To force ssh to use protocol 2 add this.
This is the default in Debian 7 😉
Limit Users Access
By default all users have SSH access. This may pose a security risk for accounts that don’t need this.
You can black list (DenyUsers) or white list (AllowUsers) users using this directives:
AllowUsers bob thomas jorge
DenyUsers mark daniel alan
You can do the same for groups
AllowGroups admins techSupport
DenyGroups mortalUsers ftpOnly
Disable root Login via SSH
To be honest this point is debatable I don’t see any reason to login directly as root. As a matter of fact I don’t even remember my root password! is a BIG password, so I disallow root login and I log in with my own account. Then I do sudo to gain root level access. This also make sure you get full auditing information about who ran privileged commands on the system via sudo.
Use Strong SSH Passwords
The importance of a good password should be obvious to any IT professional, if not go read about brute force, rainbow tables and all that stuff.
Use PAM to enforce good quality passwords
A pluggable authentication module (PAM) is a mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface (API). It allows programs that rely on authentication to be written independently of the underlying authentication scheme.
PAM is standard this days, so lets use it to force good quality passwords (this applies to all users but root)
First lets install Cracklib
admin@var-log-it:~$ sudo apt-get install libpam-cracklib
On Debian you do
admin@var-log-it:~$ sudo vim /etc/pam.d/common-password
RedHat, CentOS and others use
admin@var-log-it:~$ sudo vim /etc/pam.d/system-auth
Here is my default configuration, but you can tweak it
It allows 3 password retrys, minimum password lenght is 12, can reuse 6 characters of old password, forces at least 2 digits and 2 other characters (symbols)
password requisite pam_cracklib.so retry=3 minlen=12 difok=6 dcredit=2 ocredit=2
- retry=# : Le the user retry password input # times before returning error
- minlen=#: minimum length allowed for an account password is set to 10 characters. This is the minimum simplicity count for a good password. And you are allowed only 2 times using retry option.
- difok=#: How many characters can be the same in the new password relative to the old. User will see error – BAD PASSWORD: is too similar to the old one
The following options allow you to control the ‘unsimplicity’ of the password.
- dcredit=N : Digits characters
- ucredit=N : Upper characters
- lcredit=N : Lower characters
- ocredit=N : Other characters
On Debian you have to enable it.
Lastly dont forget to enable PAM for ssh
admin@var-log-it:~$ sudo vim /etc/ssh/sshd_config
Add this to the file
After the changes are doen dont forget to reload the SSH daemon
admin@var-log-it:~$ sudo /etc/init.d/sshd reload
Stop Using Passwords…wait what? Use Keys instead
We already enforce good quality passwords, but typing long complex passwords becomes a burden rapidly. Instead why dont you use
Public Key Based Authentication
I wont go into details about this one but theres a great article in here
Then go to ssh config file
admin@var-log-it:~$ sudo vim /etc/ssh/sshd_config
And set this
PasswordAuthentication no RSAAuthentication yes PubkeyAuthentication yes
Those are just a few of the steps to take. I will cover more over the upcoming days.
See ya and have fun hacking around! 😉