Zeltus

Up to now, I’ve been mildly amused at the attempts of script-kiddies to break into one of my servers. I’ve no idea why they are targetting that one specific server – it’s an important one to me but then, all my servers have that category. What with my regime of backups and replication, it’s a particularly easy one for me to rebuild.

Not that it will ever come to that. I do use strong passwords.

Nevertheless, I think it’s reached a stage where I have better things to do than watch my logs autorotate. Like the majority of my Systems Administration peers, I’ve decided to opt for the superior protection of RSA or DSA keys, rather than rely on passwords.

A few pre-requisites. I only access this server via ssh. All other services are turned off. So the script-kiddies were always on to a hiding to nothing anyway. I access the box mostly from a Windoze workstation – so I use PuTTY for command line access and WinSCP for file transfer.

The beauty of this is that I can use the extremely easy PuTTYgen to create my public key/private key pairs.

PuTTYgen allows me to create both the Public & the Private keys that I need for this hardening exercise. The Private key I hide away in a safe location on my workstation. I like to use Truecrypt volumes or similar schemes for this side of things. The Public key needs to be moved to my server. Sometimes this is the hardest bit to achieve! But in this case, I already have sshd running, albeit with password access, so I can use WinSCP to get the key across.

Under FreeBSD (and pretty much most other main-stream distros) the key is in ~/.ssh and is called authorized_keys. As I only have the one key all I need to do is rename the Public key accordingly and then [IMPORTANT]set it’s permissions to 644[/IMPORTANT]

Now, to enable key-based authentication, I need something like the following in the system /etc/ssh/sshd_config file.

Protocol 2
PermitRootLogin without-password
PasswordAuthentication no
ChallengeResponseAuthentication no
ClientAliveInterval 60
ClientAliveCountMax 30
UsePAM no
AllowUsers user1 user2 user3 user4 user5
DenyUsers root {all other userids in /etc/passwd}
Port 12345

1. Force use of SSH 2 – much more secure.
2. Don’t allow passwordless root logins. In fact, I don’t allow root to login at all – see DenyUsers.
3. Don’t allow passwords at all. For anybody. It’s all keyfiles for this server.
4. I don’t use skey type authentication. You probably don’t either.
5. Lines 5 & 6 – stop non-responding connections from clogging up the system.
6. These will timeout and closedown any such attempts.
7. PAM can bypass ssh login settings. Unless this line is set.
8. The next two lines only allow those users specified to use ssh to login. Everyone else is banned. In particular, root.
9. In fact, DenyUsers has precedence over AllowUsers. So be a bit careful about overlaps.
10. Finally, some obscurity to back up my security – use a non-standard Port.

A few notes before re-starting the sshd daemon, which will activate all this.

It might be an idea to open up Telnet access just while this is being tested. A small mistake here can lock you out of your server until a friendly, local SysAdmin can get at the server and correct the errors for you. Très embarassing! Telnet means you can fix your own mistakes. Just don’t forget to turn it off again when you’re happy with your ssh set-up.

As I have said, I use PuTTY for CLI access and WinSCP for file transfer. All I have to do is amend these to use the keyfiles and the ports I have specified and as far as my perception of things is, I just log in as before (umm, I suppose I do have to type in a rather longer passphrase rather than a password – but that’s the only change I see)

So, in order of security, more or less, I have

• Obscurity – I use a non-standard Port. If a script-kiddie does discover it, I can change it quite easily.
• If the Black Hat does discover the Port I am using, he then has to work out what userids are allowed to login
• …at which point he has the problem of cracking a very powerful asymmetric key mechanism. If that’s you, the NSA want to hear from you!
• I also have numerous rules set up in the TCP Wrappers’ hosts.allow file. So there is plenty of scope to trip up there and have the connection aborted
• And finally, I use Packet Filter combined with sshguard-pf just in case.

If there is any overkill in here I don’t really care. It’s all pretty easy to set up and in the few days I have been running this configuration, my logs have reported that hacking attempts have dropped from several thousand attempts per day to a big, fat zero.

Technorati Tags: authentication, freebsd, hardening, password, security, ssh, sshd