Locking down your server
Update: I just thought about binding to a specific address to help prevent others from being able to ssh into a server. This is similar to changing the port except that there are a limited number of ports, you could bind to xf1er.domain.com and it would be forever before someone was able to brute force the address alone unless the DNS servers allowed zone transfers. The best solution is to probably use a dedicated IP address for ssh, one that nothing else is using and that nothing can resolve to. The reason is that say you had set ListenAddress to xf1er.domain.com if that resolves to the same IP as domain.com or www.domain.com it will still let you ssh in. It is not like setting the address for a particular site in Apache, where it will actually need to match the domain name.
Recently someone on the SoCal LinuxUsers mailing list was asking for information, a checklist or sorts on procedures to lock down your Linux box when putting it on the big bad internet. I will probably collect a lot more of these and make a real checklist, but this will get you started. Note that some of the configuration directives for OpenSSH are already set by default, I prefer to make the change in the config file anyway to ensure those things are set. You never know when an error might occur in an update and something could have been maliciously changed in the code or an accident happened.
- Install and Configure DenyHosts
DenyHosts will add hosts to your /etc/hosts.deny file based on criteria you set and if you like it can download a file which is updated with hosts currently violating DenyHosts policies on other machines. For a lot of services you have to run them in xinetd or inetd for TCP wrappers to work, without TCP wrappers being involved in the daemon hosts.deny/hosts.allow will do nothing for you. The alternative to xinetd and inetd being involved is support for the libwrap library, which most OpenSSH packages have built in when compiled. You can check if a daemon has libwrap support by following the guide on ducea.com ((How to find out if a daemon was build with TCP Wrappers support)).
All about Linux has a good post explaining how to use TCP wrappers to secure Linux ((All about Linux: Using TCP Wrappers to secure Linux)).
- Remove root access via ssh
You really shouldn’t be logging in as root anyway, but there are times when ’sudo command‘ just is annoying. If you really don’t need the audit trail ’sudo su’ will give you root access, but that should only be used when you have a large numbers of commands that need to be run as root and when you don’t need the audit trail. You should never give someone the opportunity to brute force your root password, so adding this to /etc/ssh/sshd_config will disallow root from ever logging in through ssh.
PermitRootLogin no - Set LoginGraceTime and MaxAuthTries
These are good to add, but I feel with a lot of other things we are doing they aren’t a must.
LoginGraceTime The server disconnects after this time if the user has not suc- cessfully logged in. If the value is 0, there is no time limit. The default is 120 seconds. MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6.LoginGraceTime 2m MaxAuthTries 3 - Set MaxStartups
Prevent the number of concurrent unauthenticated connections, this would slow down a brute force attack
MaxStartups Specifies the maximum number of concurrent unauthenticated con- nections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime ex- pires for a connection. The default is 10.MaxStartups 3 - Set PermitEmptyPasswords
It isn’t impossible for there to be a user with a blank password, mistakes happen, but this will prevent someone from logging in with that user.
PermitEmptyPasswords no - Set AllowUsers/AllowGroups in sshd_config
By specifying what users are allowed to connect you are locking down the possibility of a successful brute force or dictionary attack on ssh, but this also helps prevent system access via a known internal username/password that really doesn’t need access via ssh. An example would be if you had a user that services were running under and had permissions to certain things, but nobody really needed to directly login as that user. So you can now add a user, say ‘johndoe’ to AllowUsers and give him the password to another user say ’sysadmin’, who happens to have the ability to sudo commands. You have now just made it so that an attacker would have to gain access to two accounts to run a sudo command as the sysadmin user. There are of course other things that an attacker could do to gain root/sudo access, but this is creating another layer of protection. If you use the AllowGroups method you can have a group of users that can access the server via ssh, and just add and remove users as you need to without having to update and reload the sshd_config.
When specifying AllowUsers you can have a single username or a username and host.
AllowUsers johndoe janedoe@10.10.10.1Specifying addresses will really help to secure who can login and where they can login from. For my Endian box at home I have a user account linked to an IP address at work and separate non-privileged user with the IP address of a remote VPS. I also have it linked to two IP addresses that are local to the machine. You may ask why go through the trouble, but what this does for me is it allows me to login directly from my desktop and laptop while at home, and from my laptop while I am at work, but if I am at a remote location, say a friends house, I must first login to a VPS. As we add a few more configuration changes to locking down the machine you will see how when these are combined it really helps prevent someone accessing the machine.
- Turn on Public Key authentication for ssh
The article I wrote for this was moved to this site, the title is SSH Public Key Authentication ((SSH Public Key Authentication))
- Configure the firewall
I avoid setting up mail as much as I can so my firewall rules are pretty limited. I block drop all traffic except traffic on ports 22, 80 and 443. If I have anything else running on the inside I access it using tunnels
- Setup remote logging via syslogd
If you have another server you can setup remote logging via syslogd or its variants. The benefit of this is that if a machine was compromised the attacker would then have to compromise the server receiving the logs to remove the entries showing his attack on the machine.
- Install Logwatch
Install and enable logwatch and set it to the highest level of detail. This will send you an email with login attempts, denyhost log entries, and a lot of good system information. If someone breaks in the logs will be useless if they are good, but it is nice to receive an email letting you know what people are attempting to do and what is going on.
- Setup various password rules.
Ubuntu has a guide regarding user management ((User Management)), which will tell you how to setup password length rules and password expiration rules.
- Check for rootkits
Two really good tools for checking rootkits and some other various things on systems are chkrootkit and rkhunter. I prefer rkhunter.
There are tons of articles on securing systems all over the internet and I recommend you do some research on more methods of locking down a server it would be very hard for me to list everything you should/could do. Intrusion detection, setting up jails, and so much more will help you secure your system, but don’t forget about the physical access to machines. If someone has physical access to a machine they will most likely gain access to the system if they know what they are doing.
