View Single Post
  #1   (View Single Post)  
Old 2nd May 2008
anomie's Avatar
anomie anomie is offline
Local
 
Join Date: Apr 2008
Location: Texas
Posts: 445
Default 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:
  1. Using a packet filtering firewall (examples: PF, IPFW).
  2. Using hosts.allow (the tcp wrappers access list).
  3. Using sshd's AllowUsers directive with the form user@host.

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:
Quote:
In some jurisdictions, sending a warning message before authenti- cation may be relevant for getting legal protection.
The key here is understanding the laws and policies that apply to you, your organization, your country, etc. The banner text, which we'll put in an example file called /etc/ssh-banner, might read something like: "Unauthorized use of this computer and its resources is prohibited. By logging in to this computer, you agree that... etc." (But that is for you to determine.)

Example: "Banner /etc/ssh-banner"

Monitor and react to problems
Security is an ongoing process. It's crucial that you:
  • Review your logs regularly.
  • Review your system email regularly.
  • Stay current with security updates to OpenSSH.

-----------------------------------------

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 03:18 PM.
Reply With Quote