Tag Archives: Secure Your Linux Host Series

Even more SSH – Great Article on /dev/random

Quick update to Part 2 of the AoIS Secure Your Linux Host Series on SSH.

I noticed a great article today on  Xavier Mertens/dev/random blog (which by the way has several great posts that have caught my eye…), on SSH tunneling -> “Keep an Eye on SSH Forwarding“.

In addition to providing a solid introudction to SSH Port Forwarding Xavier also discusses:

  • Using SSH as a SOCKS Proxy via the SSH Server
  • Logging port forwarding
  • Restricting  ports that can be forwarded

Check it out.

Cheers, Erik

Advertisements

Secure Your Linux Host – Part 3: Why A Host Firewall ?

This post is going to focus on building and applying a Host Firewall using the IPTables functionality that is built into Linux. (If you are already lost, try googling “securing linux with IPTables”, and check out the resources section below.)

Please note: This Secure Your Linux Host series is very hands-on.  The tools and tips that will enable you to use a Host Firewall are coming, but let’s lay the foundation for using them first…

What is a Host Firewall?

When the concept of Firewall is mentioned, the most common meaning that comes to mind is a network services control between networks. Over 90% of the information that you can find on Firewalls is targeted at people who want to protect systems on one network (such as their corporate or home LAN) from systems on another network (generally the internet), while permitting a list of known services to be accessed by one network from the other. There are in fact several effective strategies for using Network Firewalls as boundaries between networks, or network segments.  For a detailed introduction (or tune up) on this subject, please refer to the NIST document in the resources section below, or click here for a great SANS introduction.

A Host Firewall is different in that it exists to protect and control access to a single system from all others. Common scenarios a Host Firewall is well suited to address:

  • Host is in direct contact with the Internet (or other hostile network)
  • Host is located in a DMZ
  • Host cannot trust systems on its network segment
  • Host has high control expectations due to legal, regulatory, audit, or risk requirements

If you have servers that are hosted in a data center or directly connected to a broadband/DSL connection and, as a result, are in direct contact with the internet, then I highly recommend configuring a Host Firewall. Systems that are in this situation will be attacked from other systems all over the globe all of the time. There are so many attackers who are running probing scans across the entire network space of the Internet that you will get scanned. The recent log information that I supplied on http scans and ssh password attempts is an example of how any host (no matter how insignificant) will be regularly attacked.

dmz_conceptual OK –  so what if the host is behind a firewall in a DMZ with other hosts (such as the www and SMTP, hosts in this illustration)? Most DMZ networks do not provide protection against attacks from other “peer” hosts in the DMZ. The problem that this presents is that, in the event that one host in the DMZ becomes exploited, then it can be used to probe and attack all of the hosts in the DMZ. Even worse, if a single host in the DMZ falls prey to a Worm or other self-propagating threat, then all similar hosts in the DMZ can be rapidly infected.

The “Host cannot trust systems on its network segment” argument for a Host Firewall is almost identical to the DMZ argument. Why provide access to services on the box to systems that do not need them?

The last point is about high-risk or highly-regulated systems. The rules on a Host Firewall are much simpler to review and understand (but perhaps not manage) than the rule set on a network boundary Firewall. This can have two major  advantages. First, it can make it much easier to provide complete and frequent reviews of the Firewall rule set. Second, it can remove confusion, limit scope, and simplify formal audits of the network access that the given Host has.

Isn’t Linux Secure by Default?

Many Linux distributions and commercial operating systems advertise that they ship in a “fail safe” or at least “start safe” mode; let’s assume that to be the case. When you install any operating system, the first thing you do is start installing software and applications. With each application that you install, you may be exposing services to the network.

With a Host Firewall, you will know precisely what services you are and are not exposing. As you know from Part 1, I run a Mail Transfer Agent so that email to root, events, etc. is in fact delivered to an email account I actually use. Running a Host Firewall dramatically raises my confidence that I am not a SPAM relay – sure, I think I configured the MTA properly… But with the Host Firewall I know that only services on my host (via 127.0.0.1) can send email. Running a LAMP server provides a very similar situation. With the Host Firewall in place, I know that MySQL isn’t accessible on its native ports to the world.

So, What is the Downside?

The reason that more systems are not running a Host Firewall is a lack of management tools. If you have a small number of hosts that you are administrating, then adding and managing a Host Firewall is not much work at all. But, if you have a hundred servers with a mix of operating systems, split into several data centers, suddenly managing Host Firewalls is not only a nightmare but may be causing more operational risk than is acceptable.

Every modern operating system (Linux, Unix-*, Windows, System/Z, openBSD, etc.) comes with a built in Host Firewall capability. What is needed is tooling that enables both centralized management and harmonization with network boundary Firewalls. (Unfortunately, I won’t be able to provide that in this series!)  The vendors with the best management of the network boundary Firewalls tend to be the manufacturers of those Firewalls, and they would be the most logical group to expand their existing management capabilities into the Host Firewall space. But, I do not think that anyone has developed a revenue model to justify that as worth the investment. (Hope springs eternal!)

What’s Next?

In the next installment, I am going to walk through the actual artofinfosec.com Firewall. (No B.S. “Security Through Obscurity” here!) And then in the following segment, I am going to discuss tools for monitoring and adding countermeasures to the Host Firewall.

Resources

  • Securing Linux Systems With Host-Based Firewalls Implemented With Linux iptables (htmlpdf)

This is a great introduction to building a Host Firewall. (The html site version seems like a paraphrase of the Sun Blueprint document pdf.) It is a resource that I return to time and again. The firewall example provided here includes full egress control, and the article walks the reader through the firewall step-by-step. The description is for a very controlled Host Firewall, so controlled that I in fact found myself moving to a simpler implementation.

  • NIST: Guidelines on Firewalls and Firewall Policy (pdf)

The NIST documentation (as usual) provides a great 360-degree medium-depth introduction to the topic. If you currently, or are about to, manage firewalls as part of your network security function, then read this guide!

Cheers, Erik

More SSH Anyone ?

Two Quick updates to Part 2 of the AoIS Secure Your Linux Host Series on SSH.

Interesting Series by ISS X-Force on SSH

Just this morning I ran across a three part series on SSH published last year in IBM’s Internet Security Systems X-Force Threat Insight in the following issues:

X-Force expresses a slightly different set of concerns, and solutions. One topic that I did not touch on was the use of ssh agents for the management of sessions. Part 3 (June) is almost entirely focused on that.

Logwatch Samples

One of the great things about the script kiddies is they are keep testing your security for you ! 😉 Below is a mash-up and edit-down of the last few days of ssh related itms from my logwatch logs. Logwatch really has become one of my favorite tools. I don’t have tons of attacks on my servers, but there is always enough activity in the logs to let me know that the controls and countermeasures are up and running. After installing fail2ban, I always have some activity in 24 hour period of time. 

And a tip for the paranoid – if you have Failed logins and Illegal users but no fail2ban activity – then fail2ban has stopped running (or worse…).

——————— fail2ban-messages Begin ————————
Banned services with Fail2Ban:
Bans:Unbans  
ssh: [ 6:6 ]  
ssh: [ 4:7 ]  
ssh: [ 6:5 ]
ssh: [ 5:3 ]
———————- fail2ban-messages End ————————-

——————— SSHD Begin ————————
Failed logins from:
75.xxx.109.82 (75-xxx-109-82-Indianapolis.hfc.comcastbusiness.net): 1 time
79.xxx.248.27 (host27-xxx-static.38-79-b.business.telecomitalia.it): 1 time
200.xxx.209.156 (dedint-200-xx-209-156.mexdf.axtel.net): 3 times
59.xxx.92.26: 6 times
88.xxx.16.23 (…): 7 times
119.xxx.154.57: 6 times
203.xxx.198.3 (…): 6 times

Illegal users from:
60.xxx.249.90 (…): 3 times
75.xxx.109.82 (…): 3 times
79.xxx.248.27 (…): 3 times
200.xxx.209.156 (…): 2 times
202.xxx.28.244 (…): 3 times
85.xxx.133.177: 4 times
193.xxx.161.136: 4 times
———————- SSHD End ————————-

Cheers, Erik

Secure Your Linux Host – Part 2: Secure SSH

SSH is the preferred (perhaps de facto) remote login service for all things UNIX. The old-school remote login was telnet. But telnet was completely insecure.  Not only was the confidentiality of the session not protected, but the password wasn’t protected at all – not weak protection – no protection.

Trinity hacking ssh with nmap in ReloadedAnd so SSH (aka Secure Shell was developed)… But it has not been without its failings. There are two “flavors” for SSH: Protocol 1 and 2.  Protocol 1 turned out to have pretty serious design flaws. The hack of SSH using the Protocol 1 weaknesses was featured in the movie Matrix Reloaded. So, by 2003, the flaws and the script kiddie attack were understood well enough to have the Wachowski Brothers immortalize them.

Another concern to watch out for is that SSH has port-forwarding capabilities built into it. So, it can be used to circumvent web proxies and pierce firewalls.

All in all though, SSH is very powerful and can be a very secure way to remotely access either the shell or (via port forwarding) the services on your host.

For additional information on SSH’s port-forwarding capabilities:

Be aware that SSH is part of a family of related utilities; check out SCP, too.

Configuration

After installing the SSH server (perhaps: apt-get install openssh-server), you will want to turn your attention to the configuration file /etc/ssh/sshd_config

Here are a few settings to consider:

Protocol 2
PermitRootLogin no
Compression yes
PermitTunnel yes
Ciphers aes256-cbc,aes256-ctr,aes128-cbc,aes192-cbc,aes128-ctr
MACS hmac-sha1,hmac-sha1-96
Banner /etc/issue.net

  1. The “Protocol” setting should not include “Protocol 1”. It’s broken; don’t use it.
  2. PermitRootLogin should never be “yes” (so, of course that is the default !). The best option here is “no”, but if you need or want to have direct remote root access (perhaps as a rescue account), then the “nopwd” option is better than “yes”. The nopwd option will force you to set up and use a certificate to authenticate access.
  3. Unless your host’s CPU is straining to keep up, turn on compression. Turn it on especially if you are ever using a slow network connection (and who isn’t).
  4. If you are not going to access services remotely using SSH as sort of a micro-VPN, then set this to “off”.  Because I use the tunneling feature, I have it turned on.
  5. OK; I work and consult on cryptographic controls, so I restrict SSH to the FIPS 140-2 acceptable encryption algorithms.
  6. Likewise, I restrict the Message Authentication Codes (MACS) to stronger hashes.
  7. Some jurisdictions seem to not consider hacking a crime unless you explicitly forbid unauthorized access, so I use a banner.

Sample Banner

It seems that (at least at one point in the history of law & the internet) systems which did not have a login banner prohibiting unauthorized use may have had difficulty punishing those that abused their systems. (Of course, it is pretty hard to do so anyway, but…) Here is the login banner that I use:
* - - - - - - - W A R N I N G - - - - - - - - - - W A R N I N G - - - - - - - *
*                                                                             *
* The use of this system is restricted to authorized users. All information   *
* and communications on this system are subject to review, monitoring and     *
* recording at any time, without notice or permission.                        *
*                                                                             *
* Unauthorized access or use shall be subject to prosecution.                 *
*                                                                             *
* - - - - - - - W A R N I N G - - - - - - - - - - W A R N I N G - - - - - - - *

Account Penetration Countermeasures

Within hours of establishing an internet accessible host running SSH, your logs will start to show failed attempts to log into root and other accounts. Here is a sample from a recent Log Watch report:

--------------------- SSHD Begin ------------------------
Failed logins from:
58.222.11.2: 6 times
211.156.193.131: 1 time
Illegal users from:
60.31.195.66: 3 times
203.188.159.61: 1 time
211.156.193.131: 3 times
Users logging in through sshd:
myaccount name:
xx.xx.xxx.xx: 3 times
---------------------- SSHD End -------------------------

One of the most effective controls against password guessing attacks is locking out accounts after a predetermined and limited number of password attempts. This has a tendency to turn out to be a “three strikes and you’re out” rule.

The problem with applying such a policy with a remote service, like SSH, as opposed to your desktop login/password, is that blocking the password guessing attack becomes a Denial of Service attack. Any known (or guessed) login ID on the remote machine will end up being locked out due to the remote attacks.

Enter Fail2ban: Rather than lock out the account, Fail2ban blocks the IP address. Fail2ban will monitor your logs, and when it detects login or password failures that are coming from a particular host, it blocks future access (to either that service or your entire machine) from that host for a period of time. (Oh, and you may notice I said blocks access to the “service”, and not “SSH” – that’s because Fail2ban can detect and block Brute Force Password attacks against SSH, apache, mail servers, and so on…)

How to Forge has a great article on setting up Fail2ban – Preventing Brute Force Attacks With Fail2ban – check it out.

One tweak for now. As I tend to use certificate authentication with SSH (next topic), I rarely am logging in with a password. As a result, I tend to use a bantime that is long, ranging from a few hours on up. Three guesses every few hours really slows down a Brute Force Attack! Also, check out the ignoreip option, which can be used to make sure that at least one host doesn’t get locked out. (You can lock yourself out with Fail2ban… I have done it…)

SSH Certificate Based Authentication Considerations

Secure Shell offers the ability to use certificate based authentication with a self-signed certificate. There are two ways you might consider using this:

  1. With a password protecting the private key
  2. With no password required

Please note: When you establish certificate based authentication with SSH, you will generate a public/private key pair on your local computer. The public key will only be copied up to the server which you wish to access. The private key always stays on your local computer.

During the process of generating the private and public key pair, you will be asked if you want to password protect the private key. Some things to consider:

  • Will this ID be used for automated functional access ?

If you are creating the certificate based authentication so that a service can access data or run commands on the remote machine, then you will not want to password protect the local file. (If you do, you will end up including the password in the scripts anyway, so what would be the point?)

Personally, I have backup scripts which either pull data or snapshots on a regular basis. Google “rsync via ssh” for tips on this, or “remote commands with ssh” for tips and ideas. (Also, I may cover my obsessive compulsive backups in a later post.)

  • This ID will be used for a rescue account

In this case the certificate is usually created to avoid password expiration requirements. If it is a rescue account, it often logs into root. Any time you use certificate access for root, the private key should be password protected. Rescue accounts are often stored on centralized “jump boxes” and are expected to only be used during a declared emergency of some kind (such as full system lockout due to a password miss-synchronization.)

These private keys should always be password protected.

If someone has access to backups or disk images of the jump box, or otherwise gets access to your .ssh directory, and you have not password protected the private key, then they own the account (e.g., they can use the public/private key pair from any box).

  • Convenient remote logons…

The most common use of certificate based authentication for SSH is in fact to log you into the remote box without having to type passwords. (I do this, too…) But there are a few things to think about (these are all good general recommendations, but I consider them requirements when using an automated login…)

  1. Automatic login should never be used on a high-privilege account (e.g., root)
  2. If those accounts have sudo privileges, sudo should require a password
  3. A new certificate (public and private key pair) should be created for each machine you want to access the remote server from (e.g., desktop, laptop, etc.).  Do not reuse the same files.
  4. The certificate should be replaced occasionally (perhaps every 6 months).
  5. Use a large key and use the RSA algorithm option (e.g., ssh-keygen -b 3608 -t rsa)

SSH Certificate Based Authentication Instructions

So, without further ado… Let’s set up a Certificate for authentication.

Part 1 – From the client (e.g. your workstation, etc…)

First, confirm that you can generate a key.

$ ssh-keygen --help

The options that are going to be of interest are:

  • -b bits  Number of bits in the key to create
  • -t type  Specify type of key to create

DSA type keys, you will note, have a key length of exactly 1024. As a result, I choose RSA with a long key. My recommendation is that you take 2048 as a minimum length. I am pretty paranoid, and I have a strong background in cryptography, but I have never used a key longer than 4096.

The longer the key, the more math the computer must perform while establishing the session. After the session is established, then one of the block-ciphers discussed above performs all of the crypto. If you are making a key for a slow device (like a PDA) or a microcontroller based device, then use a shorter key length. Regardless, actually changing the keys regularly is a more secure practice than making a large one that is never changed.

$ ssh-keygen -b 3608 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/erikheidt/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/erikheidt/.ssh/id_rsa.
Your public key has been saved in /Users/erikheidt/.ssh/id_rsa.pub.
The key fingerprint is:
43:69:d8:8e:c4:af:f8:8b:5a:2d:db:75:91:fd:06:be erikheidt@Trinity.local
The key's randomart image is:
+--[ RSA 3608]----+
|                 |
|     . o .       |
|      + =        |
|     . *   o     |
|      . S o o    |
|     o . . o o   |
|    + o . . . o  |
|   . * . .   o   |
|  ..o +.    E    |
+-----------------+

Now, make sure your .ssh directory is secured properly…

$ chmod 700 ~/.ssh

Next, you need to copy the public key (only) to the server or remote host you wish to login to.

$ cd ~/.ssh

$ scp id_rsa.pub YourUser@Hostname

Now we have copied the file up to the server….

Part 2 – On the Server or remote host….

Logon to the target system (probably using a password) and then set things up on that end…

$ ssh YourUser@Hostname

$ mkdir .ssh
$ chmod 700 .ssh
$ cat id_rsa.pub >> ~/.ssh/authorized_keys

Done ! Your next login should use certificate based authentication !

I hope this posting on SSH was useful.

Cheers, Erik

Being Probed for phpMyAdmin ?

In Secure Your Linux Host – Part 1 I recommended using Log Watch to keep an eye on what may be happening with your host. Well, today’s review of my own Log Watch indicates that I am being probed for phpMyAdmin. (Someone wants to abuse my database…)

Here is a sample from the log:

401 Unauthorized
/admin/mysql/main.php: 1 Time(s)
/admin/php-my-admin/main.php: 1 Time(s)
/admin/php-myadmin/main.php: 1 Time(s)
/admin/phpMyAdmin-2.2.3/main.php: 1 Time(s)
/admin/phpMyAdmin-2.2.6/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.4/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.5-pl1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.5-rc1/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.5-rc2/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.5/main.php: 1 Time(s)
/admin/phpMyAdmin-2.5.6-rc1/main.php: 1 Time(s)

Now I have seen activity like this before, but I thought this provided a good example of the increased awareness that scanning through the Log Watch report can provide.

This also provides some solid data in support of having some other controls in place if you are in fact running phpMyAdmin (or even MySQL). Most of the time the passwords that are used to access the content of databases are not used by humans – they are stored in the properties files of the applications that are using the database.

Ok, So Your Logs are Letting You Know What is Being Probed, Now What ?

This awareness allows you to make sure that you are adequately protecting that which is being attacked.  In this case, I already have controls in place to manage this risk. Let’s discuss them.

Lock Down Web Access to Administrative Tools

phpMyAdmin (usually) requires a password (more on that in a second), but you can also add an additional layer of security to your web-based administrative services by adding authentication at the http server itself.

Apache has a nice tutorial: Authentication, Authorization and Access Control

If you run web-based administrative tools, you may wish to lock down the web paths that contain them. In addition to providing a first line of defense, this will reduce the information available to attackers during the reconnaissance portion of their attacks.

If you lock down “mywebsite.com/admin” as described in the Apache How-To above, and you have additional directories under this “mywebsite.com/admin/phpMyAdmin” and “mywebsite.com/admin/keys2Kingdom” , they will not be visible to the attacker (until they guess the password…).

Confirm Strong Passwords

Functional IDs (also called service accounts) are used for application to application (e.g. wordpress to MySQL) authentication, and are (and should be) only handled by humans during installation and maintenance activities. Functional IDs should be long, very random, and not contain words or memorable substrings. (Functional accounts often do not have password retry limits, which heightens the importance of the strength of the password.)

I sometimes use the GRC Strong Password Generator (ah yeah, my ow site gotentropy.artofinfosec.com is down right now…). You can also generate strong passwords using openSSL from the Linux command line:

openssl rand -base64 60

In both cases I prefer to cut and paste a long substring of 40 to 50 characters  (dropping a few characters off both ends, especially the “==” base64 termination marker from the openssl command), and then adding a few characters of my own.

Now, I would never expect an application user to type a 40+ character password. But for a Functional ID – why not ? The root MySql and all db user’s ID should be very complex and long, especially if the host is internet accessible. (If you are using phpMyAdmin, it has a very good password generator included in the “Add User” functionality.)

We will be discussing other ways to protect password based systems from remote attacks in “Secure Your Linux Host – Part 2″… Out soon…

Cheers, Erik

( Part of the Secure Your Linux Host series…)

Secure Your Linux Host – Part 1: Foundations…

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’.

Foundations

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’
To: root

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.

Cheers, Erik