Monday, October 19, 2015

List of Linux System Hardening Resources

My recent post about how quickly newly commissioned Linux systems can be attacked and possibly compromised led to a bunch of e-mail queries about resources which explain how to lock down a variety of Linux distributions. Most such guides are distribution specific because, while the basic principles are always the same, there are significant differences between distributions and even versions of the same distribution that make writing a generic guide difficult at best.

I did compile a list which I added to the comments. However, based on the number of questions I've received I thought it would be best to publish the list as a blog post, something people could easily find and bookmark, with some additions to what I originally posted. I've limited this list to distributions commonly used in businesses (large and small), academia, and in non-profits. I have not included specialized distributions, including those designed for use by security professionals. Most of these distributions also are excellent choices for personal use.

Red Hat Enterprise Linux / Centos / Scientific Linux / Springdale Linux




Wednesday, October 7, 2015

Linux Security: Lock Down a New System Immediately

PCWorld recently published an article about Linux botnets launching DDoS attacks. The attackers find and exploit poorly secured Linux systems. Some Linux users have a fairly cavalier attitude about security, assuming the supposedly superior design of the OS somehow protects them. It doesn't. Now that Chromebooks outsell Windows laptops and Amdroid devices are ubiquitous the days when Linux was a secondary target for malware are long gone. Linux' prominence in both the server room and on consumer devices make it a prime target.

How quickly will a newly commissioned system be attacked? Here's my recent experience. I did a build of a webserver with CentOS 7.1 and Drupal 8. That went smoothly. Then I installed all the latest patches. On to configuring and hardening the server. The first time I issued a su command to allow me to configure sudo I got a message about failed logins. I looked at the logs and sure enough, someone was already trying to break in with a scripted brute force attack. I immediately configured ssh to disallow root login and to disconnect after three failed attempts. That slowed but did not stop the attacks. OK, I checked the IP address they were coming from, knowing full well it might be spoofed, and found the owner was a French ISP. To satisfy my curiosity I put in a temorary firewall rule to disallow that IP range and the attack stopped and did not resume. So... either the IP address was not spoofed and some script kiddie was trying to break in from their actual connection or else the attack came through a proxy server with an IP address in that range. Cute.

Anyway, I finished my usual tasks for hardening a server and Apache, uploaded my backed up files and put them in the appropriate places with the appropriate permissions. My idea of hardening Apache includes both mod_evasive and mod_security with a current rule set. My idea of securing a server includes blocking pretty much all inbound connections not needed by either the web server, software used on the website or SSH.

I should also add that IP address blocking, up to and including geolocking, is generally not an effective defense. Knowledgeable hackers use proxies. Many change their apparent IP addresses frequently. Blocking IPs, even at the firewall level, is a lot like playing Whac-a-Mole. The attack simply continues from a different IP in short order. The brute force attacks I'm still experiencing are trying to login as root and since remote root logins are disabled that simply won't work. However, the excess traffic to my server continues and there is relatively little I can do about it.

How long between my rebuild and the start of the attacks? A few minutes. Such is life on the Internet today. The first thing anyone should do with a new system, any system, is lock it down.