Secure Your Linux Host – Part 1: Foundations…January 5, 2009
Bot-net masters, phishers, spammers, hackers, etc., all need insecure hosts on the internet that they can find, break into, and bend to their will. I was in a meeting one day with a very frustrated retail banking executive who wanted to know who was providing all of the computers, all over the globe, to the phishing and spamming teams that were attacking his bank’s on-line services. The bad news that I had to give him was that the root causes of the problem were people not taking security basics seriously – basics like patching their systems promptly, and using strong passwords.
The most shocking statistics that come up over and over again in the Information Security and Risk Management research:
- 75% of Data Loss events involve an insider
- 75% of the insider’s actions were negligent and not self-serving or malicious
This means that over half (56%) of Data Loss events would not have been but for incompetent or naive personnel.
As an Information Security professional, I have no delusions that the internet underground is going to someday run out of computers susceptible to the script kiddie attacks that are dependent on weak security practices, but I do believe you can protect your host – if you choose to. So I decided to kick off this series on AoIS, from one Linux enthusiast to another. Oh, and FYI, currently I am running Ubuntu as my ‘distribution of the moment’.
The low-hanging fruit in securing your host is all pretty basic stuff. Here is the list:
- Set the root password to something very long and complex
- Forbid remote access to root (Part 2 will cover this for ssh)
- Update and patch your host early and often
- Set-up Mail Transfer Agent (MTA), and forward root’s email…
- Install Log Watch
Complex Root Passwords
Ok – you would think that this has been beaten into the ground, but the data shows that there are lots of systems which (1) allow remote root access and (2) aren’t using very hard-to-guess passwords.
- Set a long and complex password
- Stay tuned for properly secured remote access with SSH (part 2)
Of course, this should include not just root but also accounts with root-like privileges (e.g., can run sudo). Many attacks on privileged accounts make assumptions about account names. Set up a personalized account on the host, and then grant sudo privileges. (Oh, and “admin” is a great name for that account, but your name will work just fine. It seems that the attack scripts don’t yet troll the public information about the box for names yet…)
Early and often?
The first thing I do after I install and boot a new host is update it.
# apt-get update
# apt-get upgrade
No brainer there…
I use the following variation in a Cron job to regularly update all of the packages on the box. There are a few tutorials on applying only the security patches, but I choose to go ahead and update all packages.
su --login --command 'apt-get update -qq; apt-get upgrade -q -y; exit'
The -q and -qq flags suppress messages, shortening the output. The Cron facility will automatically forward that output to the root user. The -y option tells apt-get to assume a Yes answer for any of the questions.
The “su –login –command” provides context to the command so that it can operate properly (and this results in the “stdin: is not a tty” notice below…).
This results in an email from Cron that looks somthing like this:
From: Cron Daemon
Date: Tue, Dec 23
Subject: Cron su –login –command ‘apt-get update -qq; apt-get upgrade -q -y; exit’
stdin: is not a tty
Reading package lists…
Building dependency tree…
Reading state information…
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
So, how often? Automated beats manually. A Weekly scheduled task is so much better than the ‘intention to log in routinely and update the box’. You have to balance the risks associated with the update itself interfering with the services the box provides against the risks of not having up-to-date patches .
One thing that is critical -> if you are using automated patch updates, you need to either get emails with the update output or log this data to a fixed location. In the event that one of these updates causes you a problem, you want to know exactly where to look to aid in your trouble-shooting.
Set-up Mail Transfer Agent (MTA)
System services will send email to root whenever something isn’t right. So, unless you are going to do some very agressive log monitoring, getting those messages forwarded to your actual email box will be invaluable. Not just from a security perspective, but also to understand the operational integrity (aka health) of the system.
Unfortunately, details of properly setting up a Mail Transfer Agent are beyond the scope of what I can explore in a blog posting. For our purposes, the goals are:
- Set-up an MTA that will work with your ISP/hosting provider
- Configure .forward file for the root account
- Make sure the MTA is NOT an “open relay”
I use Postfix in a pretty trivial configuration. If you research the “install postfix” on Google, it will at first seem like you are embarking on a complex journey. Not so. Those posts are directed toward people who want to set up complete email solutions. The only goal from a security and operational awareness point of view is that email messages that get sent to root get forwarded to you, the system admin. To accomplish that, the steps should go something like:
- Install Postfix
- Select either “Internet Site” or “Smart Host”
- Continue through the configuration wizard
(and of course, the devil is in the details of that last step…)
Install Log Watch
# apt-get install logwatch
Now that you have the required facilities to have email sent from your host, install Logwatch. The default installation on Ubuntu will automatically send a daily email with tons of useful information, including:
- Summaries of the logs of utilities and services (postfix, httpd, etc.)
- PAM unix authentication attempts and failures
- SSH session activity
- Uses of the SUDO command
- Disk space levels
After a few days, you will be able to scan through the email in a few seconds and understand that your host is operating normally. And of course, if you detect any problems, having a few of these emails to look back through for changes is also very valuable.
Well, the fundamentals are never super exciting. But these steps will put you well on your way to securing and hardening your host. In part 2, properly configuring and hardening SSH will be discussed.