DenyHosts protects your servers by parsing your ssh log for failed attempts at ssh login. The log where this is recorded varies by distribution. On Red Hat it is /var/log/secure and /var/log/auth.log on Mandrake. You should have one of these log files on your system

DenyHosts works by monitoring these logs for failed ssh login attempts. It also tracks which user accounts are targeted. When it finds a repeated failures from the same IP address it inserts these into your /etc/hosts.deny file effectively blocking the offending crackers.

Like any security measure this one can be shored up by implementing complementary measures. These would include disallowing root logins, using a port number other than 22 and disabling password logins. All of these can be set in your /etc/ssh/sshd_config file. Your ssh daemon must be restarted after making these changes.

You can download DenyHosts here.
-j

Sure it’s secure, probably above and beyond most home networks. I use iptables as my firewall. Connections from the internet are directed to a particular machine based on the inbound port. SSH connections from the outside are directed to one machine so that you must be able to get to that machine to reach the rest of the network. My web server uses standard apache security. Seems reasonably secure for a home network. Maybe.

After all I’m not a millionaire. I don’t have other people’s confidential information on my network. I’m not the FAA or a bank. No one in their right mind would try and extort money from me based on the information contained on my network. Besides, what little I could give them wouldn’t make it worth their time. However these justifications just don’t give me a warm and fuzzy feeling inside.

Crackers don’t necessarily just want those things. Sometimes it is just vandalism by tearing up someone’s machine. Or they may want to use a machine to setup a DOS attack. It could be that they want to use the mail server as a mail relay for spam. Whatever it is I don’t want to have to take the time to clean up after them. After all if they can break into the networks listed in the article it would seem rather arrogant of me to think that they couldn’t break into mine.

The question then becomes what to do to make it more secure. Below I’ve created a scope sheet of sorts of work that needs to be done.

1. Disallow ssh root logins
2. Disallow su to root except for certain users
3. Disallow internal ssh logins to any machine on the network. These logins must come from the “jump” machine

What else can I do? I’ll give that some thought. If you have suggestions post them in the comments. It is always interesting to hear how other people secure their networks above and beyond the norms.

In my next post I’ll describe the changes that I’ve made based on the scope of work above.

-j

Ok let’s take it from the top. I had Ubuntuserver 7.0.4 installed as my WebDAV secure server, my son’s baseball team’s website, samba and so on. I run this server headless and without a gui. Note here that the normal install is without a gui and is touted loudly by the folks who develop ubuntuserver. This is all well and good.

Lately it’s been on my mind to look into and install a collaboration suite. Having searched around I finally landed on Zimbra.

After reading the documentation I see that Zimbra is certified on Ubuntu 8.04 LTS. Ok, well this is as good of a time to upgrade as any. This is where the fun (read stupidity) begins.

I ssh into my server as normal. I do all of the pre-distribution upgrade stuff, reboot and begin the distribution upgrade. The first thing I get is a message saying something to the effect of “We do not recommend using SSH while you upgrade. If you lose a connection it is difficult to recover.” Ok. I’m not doing this over a WAN link but on my local LAN. I haven’t had any network outages since I don’t know when, the sun is shining so no power outages looming. Things are looking good.

The upgrade proceeds smoothly. On several occasions I am asked if I want to replace any of my configuration files. This include the sshd configuration file. On all of these I take the default which is “Do not replace, I want to keep the configuration file that I am currently using” . That’s paraphrased but that is what it meant.

The distribution upgrade finishes. I get a nice message saying everything went well and asking me if I want to reboot. Of course I do. I type y and off we go. After waiting the appropriate amount of time I try to SSH back in. I am pretty excited at this point about getting my Zimbra install started.

Uhoh. No such luck. The dreaded “ssh: connect to host 10.10.15.105 port 22: Connection refused” message. What?!? Are you kidding me? No way. I try pinging the server. Yep, network came back ok. I try again. Nope. And several times after that. Now I’m writing this rant.

You see, here is why I think this is stupid. The server installs without a gui. That implies that no one is going to use this for a workstation. If no one is going to use it for a workstation, why then, should it have a monitor on it? If it doesn’t have a monitor on it, why would you not want someone to upgrade using SSH? Would the Ubuntuserver people prefer telnet instead? If the upgrade process is smart enough to know that you are upgrading over SSH then why not start SSHD on the reboot? If that is in fact the problem since I haven’t dragged a monitor over there to see.

I made a decision not long ago not to scrap my Ubuntuserver in favor of CentOS. I am starting to regret that decision. You see there is at least one other annoyance with Ubuntusever that I don’t find appealing either. This is the fact that they have decided that using an inittab is old fashioned or something. While this doesn’t have much affect on a server, at least one not running a gui, have you tried to boot into runlevel 3 lately? It’s not nearly as easy as it is with a GRUB boot loader where you can edit it, type in 3, hit enter and b and boot to runlevel 3.

Ok, I’m done. Next free time that I have I’m putting CentOS on there (as soon as I drag a monitor to the server and get SSHD started that is).

-j