Protecting Linux against automated attackers

As many systems administrators will tell you, attacks from automated login scripts specifically targeting common account names with weak passwords have become a substantial threat to system security, especially via SSH (a popular program that allows remote users to log in to a Linux computer and execute commands locally). Here are some common-sense rules to follow that can greatly improve security, as well as several scripts to cut down on the computing resources wasted by these attacks.

Brute-force attackers use so-called dictionary attacks, attempting many different login/password combinations in an attempt to hit on one that matches. In most cases, these scripts use a pre-programmed “dictionary” of often-used account names (such as www, admin, test, or guest). These scripts then attempt common passwords (often just the name of the account or an empty string). When one attempt fails, the script continues on, attempting other entries in its dictionary, until it has exhausted every pair (which can total hundreds of login attempts).

One of the most popular scripts attackers have employed has been the “haita” script, often paired with a fast port scanner. The port scanner first scans blocks of IP addresses, checking for an open SSH port (22). When the scanner finds a potential target, it stores the address in a database for later. Usually within a few hours of the initial scan, the brute-force script will begin attempting dictionary attacks on each of the IP addresses within this database. Once it finds a successful login/password combination, the script alerts a human operator and hands off login access to the machine. This attacker can then log into the breached system and employ it for his own nefarious purposes.

What happens once a computer system has been compromised? According to many systems administrators, attackers first use the compromised box to begin additional attacks on other computer systems, attempting to gain access to even more machines. Many of these systems are employed as “zombies,” used to deliver hundreds of thousands of spam emails to unsuspecting inboxes. Or, if the compromised system particularly juicy, the attacker may install a keystroke logger to capture passwords for bank accounts and other information. The attacker may also attempt to gather company information, perhaps for blackmail purposes.

How to protect yourself

With so many attacks occurring on a daily basis — even to everyday home users — how can you protect yourself?

• Always choose good passwords. A good password is one that is not easy to guess, has both numbers and letters in it, and is usually more than six characters long. Also, use different passwords for different accounts; that way, if one password is ever compromised, you can decrease the fallout.
• Disable SSH access unless you really need it. If you must have it, try to set up restricted access lists, denying every IP address that’s not on your list. This isn’t always feasible, which is why the scripts listed in this article are so useful.
• Disable root logins via SSH. There are few reasons why this should be turned on in the first place, so make sure it’s off. In addition, you can specify which users are allowed to log into the system via SSH with the AllowUsers option (followed by a list of user name patterns, separated by spaces).
• Regularly update your system’s software. If it’s ever compromised, you’ll be able to reduce the effectiveness of rootkits and other privilege-escalation software by eliminating known security vulnerabilities.

Creating a strong password

Many people have created rules for strong passwords, and different organizations have different policies regarding strong passwords. Following these seven common-sense rules can go a long way toward preventing even determined attackers from guessing their way into your account: Do not use dictionary words. Do not use names. Do not use dates. Do not use the same password elsewhere. Do mix upper-lower case. Do use at least six characters. Do change your password now and then. These rules, along with other helpful information regarding Linux passwords, can be found in the Linux.com article “CLI Magic: passwd and passwords“.

In addition to the basic practices above, several programs exist to help reduce the number of attacks against your computer systems. These scripts are designed to look for brute-force attackers and automatically ban them after a certain number of attempts in a specified window of time.

Daemon Shield

Daemon Shield is a small Python script that is started at boot time and continuously monitors a syslog file (usually /var/log/messages) for login attempts (including SSH, FTP, and other services). The configuration file specifies the amount of time to wait between processing the syslog file for changes (a greater interval can improve performance), the number of acceptable attempts within a specified period of time, and what to do if an address is found that violates this policy.

In general, the script has some good features (such as the ability to block an address for a specified period of time). It uses iptables to handle the blocklist (which, when combined with an iptables firewall-type rule set, gives administrators good control over the network security of their computer system). However, Daemon Shield suffers greatly when parsing long syslog files; it may not block an address until many attempts into the attack (or until after the attack is complete). Having a good log-rolling policy for your syslog file is crucial to getting the best performance out of Daemon Shield.

Once the software is installed, you’ll need to configure it for your installation. First, make sure you have an /etc/sysconfig/iptables file (some distributions, notably Mandriva, do not create this file by default). Iptables can generate this file automatically. Under Red Hat, you can try:

service iptables save

Under Mandrake and several other distributions, use the iptables-save program if it’s available in your PATH:

iptables-save

Once you’ve created the /etc/sysconfig/iptables file, configure it to begin using the Daemon Shield rules. According to the Daemon Shield install file:

Add the following line to the list of iptables chains:

:Kiddies - [0:0]

Then add the following lines to the end of the file:

-A Kiddies -j LOG --log-level info --log-prefix "Dropped IP: " -m limit --limit
-A Kiddies -j DROP

These options instruct iptables to consult the auto-generated Daemon Shield block list before allowing each TCP connection (remember that Daemon Shield can monitor login attempts for services other than just SSH).

Now that iptables is configured to use the Daemon Shield service, the next step is to begin editing the Daemon Shield configuration file, /usr/local/etc/daemonshield.conf, to suit your installation. I found working with the configuration file to be confusing. For instance, the syntax of the ignorestring option, which allows you to set Daemon Shield to automatically ignore any logins made from the specified set of IP addresses or ranges, is certainly a little confusing. Here’s the entry I used to automatically ignore (and thereby always allow) addresses originating from 10.*.*.* and 192.168.*.* networks:

ignorestring=10.d{1,3}.d{1,3}.d{1,3} 192.168.d{1,3}.d{1,3}

I then edited the set of commands relating to the time intervals that Daemon Shield uses. First, I adjusted the expireblocktime option, which is the length of time an IP address should be blocked from attempting to log into the system after Daemon Shield has determined it to be a brute-force attacker. I used the value 180 (in minutes, so three hours), which seemed like a reasonable amount of time: not too long that a false-positive means complete lockout, but long enough that brute-forcers will likely move on. If you wish to block the address indefinitely, then you can set expireblocktime to 0.

Next set the logwatchinterval, which specifies the length of time (in seconds) that Daemon Shield should wait between checking the log file for changes (it accomplishes this by periodically stating the log file and comparing its filesize). This is a low-resource operation, though logwatchinterval should still be set to a reasonable length of time (I left the default of five seconds). In addition to this option, there is logprocessdelay, which specifies the length of time to wait between the initial time when the log was determined to have changed and the time when Daemon Shield opens the log to find potential dictionary attacks. It’s probably best to leave this as a very low number.

The next option is watchwindow. Daemon Shield stats at the tail end of the log file and works its way up to earlier entries, with its upper threshold being the current time minus watchwindow (in seconds). This reduces the overhead for Daemon Shield, so it doesn’t have to crawl through every single entry in the log file. Unfortunately, if a brute-force attacker is attempting logins over a very long period of time (say only a few times an hour), then Daemon Shield could potentially miss the attacks. Luckily, I have never seen this happen. Instead, the dictionary attack scripts seem to try all their combinations as quickly as possible before moving on. I left the default at one hour (3,600 seconds).

Attackers’ weapons

Attackers employ a variety of tools in their attempts to gain control over unprotected Linux boxes, including: Fast port scanner There are many programs that are designed to find open ports on thousands of computers as quickly as possible, and they are often used for legitimate purposes. Usually, they work by sending a simple message to a server on the port in question (for instance, the SSH port) and waiting for a response. A scanner can attempt connections to hundreds of machines simultaneously, thus speeding up the process of finding the potential targets for a dictionary attack script. Dictionary attack script This program is actually quite simple: it understands just enough of the SSH protocol to attempt login and password combinations, which it reads from a simple database file. It tries each login/password pair on the target machine. If one combination works, the script records the success in a separate database and notifies the human operator, who can then follow up with a rootkit script. Rootkit A rootkit is a catchall term for a pre-packaged script that exploits a known weakness on a computer. For instance, if a bug is discovered in the Linux kernel that can be exploited to gain elevated privileges (even root access), an attacker may attempt that exploit on an unpatched system to gain full control over the computer. In many cases, however, attackers do not even need a rootkit: As long as they have access to their compromised system, they can run spam-sending software to send millions of emails, or use the compromised system as a staging area to launch additional attacks, hiding their true identity.

A related option to the watchwindow is the recentwindow. The idea is that for an attacker to qualify for the block list, it must have perpetrated at least one attack within the recentwindow time period. This option seeks to restrict Daemon Shield to blocking only current attacks, and not ones that occurred recently (but are not currently ongoing). This option can be tricky: the default is set to 240 (seconds), so an attacker must have attempted a login within the last two minutes in order for it to qualify for blocking. However, the attacker could have attempted any number of attacks within the last watchwindow seconds, all of which must be summed together by Daemon Shield to determine if the IP address is a candidate for blocking.

Finally, Daemon Shield can send email reports whenever it blocks or unblocks IP addresses. It can also enable and disable other services — default checks by Daemon Shield include SSH, FTP, Telnet, and even PAM.

Once Daemon Shield has been installed and configured, it’s time to start checking for attackers. Under Mandriva and most other distributions, you can start Daemon Shield simply by going to /etc/init.d and running:

./daemonshield start

Additionally, the make install script should take the steps necessary to ensure Daemon Shield is started at boot. If you’re having trouble getting the daemon to start (or if it’s not starting automatically when the system is started), consult the INSTALL file in the daemonshield-X.X.X directory.

BlockHosts

BlockHosts, another script written in Python, is easier to set up, maintain, and configure. The idea behind BlockHosts is to continuously scan a syslog file for SSHD failed login attempts, and add the IP addresses listed there (after a predetermined number of attempts have been exceeded) to the system’s /etc/hosts.deny file — a different approach from that of Daemon Shield, which uses iptables to block connection attempts.

After installing the software, run the included setup script (as described in the INSTALL file). The setup script copies and installs all of the necessary BlockHosts files to their proper locations:

python setup.py install -force

If you get an error message about missing a Makefile (python2.4/config/Makefile, for instance), then you probably don’t have the Python developer tools installed (under Mandriva and Debian, it’s named python-dev), so you must install this missing software before continuing.

Once you have the BlockHosts script installed, begin configuration by editing the /etc/blockhosts.cfg file with your favorite text editor. BlockHosts comes with a default configuration file with all options commented out. Edit this file and uncomment each line suitable for your installation. All of the options are well-documented in the comments, and can be uncommented by removing the “#” at the beginning of each line.

Once your configuration file is ready, the next step is to prepare the /etc/hosts.deny (or /etc/hosts.allow, depending on your installation) for BlockHosts by copying the following lines (in their entirety) to your hosts.{deny|allow} file:


#---- BlockHosts Additions
#---- BlockHosts Additions
sshd:ALL:spawn (/usr/bin/blockhosts.py --verbose >> /var/log/blockhosts.log 2>&1 )&:allow
proftpd:ALL: spawn (/usr/bin/blockhosts.py --verbose >> /var/log/blockhosts.log 2>&1 )&:allow

These instructions tell the system to automatically run (spawn) the BlockHosts script (/usr/bin/blockhosts.py) each time a user attempts to connect to your system via either SSH or ProFTP. The script will then determine if the connecting host should be allowed access or be blocked.

Once you have completed these steps, can begin watching for dictionary attacks. Each blocked address will be added to your hosts.{deny|allow} file and prevented from accessing your machine for the specified length of time (specified by AGE_THRESHOLD in the /etc/blockhosts.cfg file).

sshdfilter

Numerous other scripts are available to perform tasks similar to those of the two detailed above. One such promising script is sshdfilter, which blocks dictionary attackers using iptables, and is very efficient in how it detects them. The sshdfilter script starts the SSHD service itself, and instructs SSHD to output all log details to stdout (which is then captured by sshdfilter). In this way, the script can detect attacks as they happen, in real time, and significantly reduces the overhead involved in searching for offenders.

Unfortunately, the sshdfilter script is more complex to set up and install than the Daemon Shield software, partly because the author has made distribution-specific installation files that failed for my (non-included) Mandriva system. Out-of-the-box configurations include Red Hat 7.3 and 9.0, Fedora Core 3, and Debian 3.1. Details exist for users who want to attempt an install on an unsupported system, though they appear to be highly platform-specific.

Employing the basic practices and scripts above, you can harden your Linux machine against many of the dictionary SSH attacks that plague Linux systems today. Keeping your system’s software up to date goes a long way toward protecting yourself against many common security vulnerabilities that automated scripts attempt to take advantage of. Don’t let your system be the jumping-off point for spam, additional system attacks, or even blackmail — protect yourself with these practices today.

Ryan Twomey is a co-founder of Draconis Software, which offers a free personal edition of its commercial server monitoring software.