Tips and Toys for the Hardworking Admin

Harden SSH to pesky dictionary attacks, make X Window work harder and squeeze a little extra from that commodity WAP.

By Carla Schroder | Posted Oct 4, 2005
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Welcome to today's installment of More Tips and Tricks For Hardworking Admins, the finest and freshest collection of mini-howtos on the Web. Today we'll do dynamic blocking of SSH server attacks, run nested window managers, and take a peek at hacking the Linksys WRTG54.

DenyHosts
Anytime you open up port 22 for SSH you'll see, within minutes, bales of bogus login attempts from leet haxx0rs trying to break in. (Check your authentication logfiles, usually /var/log/auth.log or /var/log/secure.) These are usually automated dictionary attacks that try both logins and passwords from prefab databases. They're stupid, they're lame, and I really really wish there were an easy way to reach out and touch these idiots. Forcefully.

There are a number of ways to deal with this. One is always use strong passwords, which you should do in any case, and restrict which users are allowed SSH access. Another is to restrict access to a limited set of IPs, and chuck the rest at the firewall. Some howtos advocate putting SSHD on a different port, like TCP/222. (Check /etc/services to find un-assigned ports.)

I favor not letting attackers ever get to a login prompt. There are two ways to do this:

  1. Use cryptographic keys instead of login/passwords. You may put a passphrase on your keys and use the Keychain utility to handle multiple keys and logins, or you may leave the passphrase off entirely. This is helpful for restarting mailservers and such, since they will not have to wait for a passphrase to start up. See The (Practically) Ultimate OpenSSH/Keychain Howto to learn how to do this.
  2. Use the excellent DenyHosts utility. DenyHosts is a nifty Python script that monitors authentication logs for signs of brute-force login attacks, then writes the offending IPs to /etc/hosts.deny. All you need to make it go is Python, which is standard on most Linuxes.
DenyHosts is pretty simple – you may either set it to watch for SSH attacks only, or all bogus remote login attempts on all services. First, list allowed IPs and hostnames in /etc/hosts.allow. The main configuration file is /etc/denyhosts.cfg. Here is an example configuration that you can copy, making sure that the filepaths are appropriate for your system. All directories except the lockfile, which is created by DenyHosts, need to already be in place.

WORK_DIR = /var/denyhosts/data
SECURE_LOG = /var/log/auth.log
HOSTS_DENY = /etc/hosts.deny
PURGE_DENY = 3d
BLOCK_SERVICE = ALL
DENY_THRESHOLD_INVALID = 5
DENY_THRESHOLD_VALID = 5
DENY_THRESHOLD_ROOT = 1
LOCK_FILE = /tmp/denyhosts.lock
HOSTNAME_LOOKUP=YES
SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS=YES
AGE_RESET_VALID=1d
AGE_RESET_ROOT=25d
AGE_RESET_INVALID=
DAEMON_PURGE = 1h
DAEMON_SLEEP = 30s
DAEMON_LOG_TIME_FORMAT = %b %d %H:%M:%S

Now run DenyHosts in daemon mode:

# denyhosts.py --daemon

Let's take a look at what it's going to do. PURGE_DENY = 3d means delete all blocked addresses after three days. Your /etc/hosts.deny can grow very large, so old entries should be purged periodically.

DENY_THRESHOLD_INVALID = 2 means login attempts on non-existent accounts get two chances. DENY_THRESHOLD_VALID = 5 means login attempts on legitimate accounts get five chances. DENY_THRESHOLD_ROOT = 1 gives root logins one chance. You should login as an unprivileged user anyway, then su or sudo if you need rootly powers.

HOSTNAME_LOOKUP can be disabled if it slows things down too much.

SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS should be set to YES, then monitor your DenyHosts reports to see if this is useful. It tattles about suspicious behavior perpetrated by hosts in /etc/hosts.allow, which may or may not be useful.

AGE_RESET_VALID=1d lets allowed users login after one day, if they went all fat-fingered and got locked out. AGE_RESET_INVALID= means invalid blocked users are never reset.

Included in the DenyHosts tarball is a startup script, daemon-control-dist. Stick this in /etc/init.d to get the usual start-stop-restart and boot options. Be sure to edit the first three variables - DENYHOSTS_BIN, DENYHOSTS_LOCK, and DENYHOSTS_CFG for your system.

You'll find explanations for all the other options in denyhosts.cfg-dist in the tarball, and in the DenyHosts FAQ.

Xnest: Many Computers in One
The X Window System is extremely flexible, so much so that a person could while away many a happy hour exploring everything that it can do. Xnest is an X server and client all in one, and it comes with both XFree86 and X.org. It lets you run nested X sessions. For example, suppose you have both KDE and IceWM installed, and for whatever reason – curiosity? research? you want to run them side-by-side. Maybe you like to do certain tasks in certain window managers, and want them all available at the same time. Maybe you need to compare and evaluate. Maybe you're walking through some troubleshooting over the phone, and need to duplicate the user's environment. Whatever the reason, XNest makes it possible.

Suppose you're running KDE. Open a command shell and start up Xnest:

$ Xnest -ac :1 &

Now you have a boring blank screen with an X cursor, titled "Xnest". Next, open an X terminal. Go to a command shell in your original desktop and type

$ xterm -display :1

This brings up an X terminal in your new Xnest window. In this X terminal type the following command to start IceWM:

$ icewm -display :1

Now you can start new Xnest windows from inside both KDE and IceWM, and run any window managers that you have installed. To start another Xnest bump the display number up a notch:

$ Xnest -ac :2

And start new windows managers in -display :2, and so on and on until you have exhausted your system resources.

You won't be able to copy and paste between Xnest sessions, unfortunately. Each one is an independent session, just as if you were operating separate computers. Xnest comes with most Linux distributions; check your distribution package repositories to find it.

Hacking the Linksys WRT54G/GS
Do you ever look at your little blue Linksys box and think "If only I could hack that to suit my own needs. It's small, it's power-efficient, and it's cute. I'm tired of re-purposing big old clunky PCs as router/firewall/wireless access points. Sure, they do the job, but it's like converting a barn door into a skateboard." Thanks to the endless ingenuity of tirelessly toiling hacker geeks, you can. All you need is OpenWRT. OpenWRT is more than a fancy GPL firmware; it's a complete embedded Linux distribution. So you can go far beyond the original capabilities of your little blue box and run your favorite Linux networking software, like Snort, Asterisk, SSH, dnsmasq, PPPoE, OpenVPN, tftp, and httpd. It supports WEP and WPA. It will bridge and route.

OpenWRT is not limited to the Linksys WRT54G/GS. It works on all manner of similar routers, like the ASUS WL-300G and WL-500G, Siemens Gigaset SE505, Motorola WR850G, and Buffalo Airstation WLA-G54/S. The authors of OpenWRT are still calling it experimental, but it works pretty darn well. Watch this space for a tutorial in the next few weeks. Or visit OpenWRT and get started now.

Resources

  • DenyHosts
  • OpenWRT
  • The Linux Cookbook has many great recipes on running X Window, like multi-head displays, Xnest, remote X tunneling over SSH, using different login managers, starting up in text or graphical mode, and running X and consoles simultaneously.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter