Basic sshd hardening
Running sshd to allow remote system access is a necessity for many of us. Because pwned *nix boxes are highly prized possessions, you'll want to take extra care in keeping nasty folks out.
What follows is a brief list of beginner-oriented tips on hardening sshd. (Note that some of this advice may already be implemented by your OS by default.) All directive examples will of course apply to your /etc/ssh/sshd_config file, and changes to that file only take effect after sshd is reloaded/restarted. The manpages for sshd(8) and sshd_config(5) are available on your system with plenty of additional info.
Disable Protocol 1
Unless it is absolutely required, you should disable it such that your config reads "Protocol 2" (not "Protocol 1" or "Protocol 2,1"). Why? Protocol 1 has known exploits.
Do not allow direct root logins
Simply put: everyone knows root exists on the system, so it will be a popular target for brute force attacks. The config directive should read "PermitRootLogin no".
Utilize the AllowUsers or AllowGroups directives
It's likely that not all users (shell users or otherwise) on your system require ssh access. By using one of these directives, you take advantage of a 'deny by default' policy by only letting those you specifically allow to ssh in.
Example: "AllowUsers tom jerry bill"
Implement a strategy to restrict access at the IP level
It is usually (not always) unnecessary to have your sshd daemon available to connections from all over the world. If you have clients who require ssh access only from Los Angeles, then it would be silly to be also accepting connections from, e.g., China.
Restricting access at the IP level can be achieved in (at least!) three ways:
Consider locking down authentication mechanisms
The idea here is that if you are not going to be using an authentication method, it wouldn't hurt to shut it off. (See the sshd_config(5) manpages, and your /etc/ssh/sshd_config file; search for 'Authentication' to see its various forms.)
Do you require only password authentication? Then, in most cases, you should probably use the directives "UsePAM yes" and "ChallengeResponseAuthentication yes". For all other authentication methods, use "no".
If you require a higher level of security, and circumstances allow its implementation, also consider using only PubkeyAuthentication. (Don't forget to turn the other authentications methods off once it's set up properly.) This will render brute force / password guessing attempts over ssh useless.
Consider listening on only relevant interfaces, for relevant traffic
By default on many OSes, sshd will listen on all active interfaces for both IPv4 and IPv6 traffic. You might consider limiting this if you really only require ssh access on a certain interface. If you will not be using IPv6 in the foreseeable future, it probably wouldn't hurt to turn that access off as well.
Example: "ListenAddress 10.0.20.55"
Example: "AddressFamily inet"
Consider implementing a usage banner
Directly from the sshd_config(5) manpages:
Example: "Banner /etc/ssh-banner"
Monitor and react to problems
Security is an ongoing process. It's crucial that you:
Hopefully these tips will be helpful in getting you on your way to a more secure sshd environment. Stay safe and stay happy.
Kill your t.v.
Last edited by anomie; 2nd May 2008 at 04:18 PM.
|harden, secure, sshd, sshd_config|
|Thread||Thread Starter||Forum||Replies||Last Post|
|Basic networking fail.||diw||OpenBSD General||13||31st March 2009 10:29 AM|
|Basic Perl arrays question||stukov||Programming||12||18th November 2008 08:44 PM|
|Hardening FreeBSD||cajunman4life||FreeBSD Security||53||7th October 2008 01:06 PM|
|need some basic help on ifconfig||daemon-dd||FreeBSD General||4||29th July 2008 04:21 PM|
|Can I use this link for hardening FreeBSD 7||mfaridi||FreeBSD Security||1||9th July 2008 08:35 AM|