Basic sshd hardening

[anomie]

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:

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.

[BuSerD]

Well though out and presented in an easy to follow manner. Thanks for a great post.

[vermaden]

You may also run SSH on a custom port (for example Port 50522).

[bigb89]

Originally Posted by vermaden

You may also run SSH on a custom port (for example Port 50522).

Yes, I agree with vermaden. It really helps if you change the default ssh port number. Since almost anyone trying to brute force the machine, will be trying the default port, but if that person doesn't know your ssh port number, then there's not much left to do.

[vermaden]

Originally Posted by bigb89

Yes, I agree with vermaden. It really helps if you change the default ssh port number. Since almost anyone trying to brute force the machine, will be trying the default port, but if that person doesn't know your ssh port number, then there's not much left to do.

You can also use nmap to scan all 1-65536 ports of any server, which will tell you what you run on what port.

[BSDfan666]

Originally Posted by vermaden

You can also use nmap to scan all 1-65536 ports of any server, which will tell you what you run on what port.

I'm sure that poster was aware of this, but, scanning all the ports on a host takes a lot of time... most "brute force" script kiddies that search for SSH on a rage.. typically only attempt port 22.

Now, if someone was targeting you alone... then sure, they could find it, but at the same time it would lower the amount of automated brute forces. (i.e: polluted logs.).

[vermaden]

Originally Posted by BSDfan666

I'm sure that poster was aware of this, but, scanning all the ports on a host takes a lot of time... most "brute force" script kiddies that search for SSH on a rage.. typically only attempt port 22.

Yeah, port other then 22 makes a lot less useless junk in ssh logs

[bigb89]

Originally Posted by vermaden

You can also use nmap to scan all 1-65536 ports of any server, which will tell you what you run on what port.

Correct me if I'm wrong. But you can use the firewall to block scans and pings to your computer.

[vermaden]

Originally Posted by bigb89

Correct me if I'm wrong. But you can use the firewall to block scans and pings to your computer.

Yes, it is possible to block only nmap packets with specific SYN or ACK flags, if you google for that you will find whole howtos how to do that.

[harisman]

Additionally to the anomie post it is *invaluable* to install denyhosts scripts, especial if it necessary for you to open the ssh service to the public internet.

It is available from the ports: /usr/ports/security/denyhosts

It blocks ssh user dictionary probes or other evil actions using tcpwrappers

I personally have configured the denyhosts to use my pf firewall as well ,that populates a related table with the attacker's IPs.

I am very satisfied with denyhosts, it blocks daily dozen of attackers.

[dewarrn1]

I'm having trouble disabling password login on a new box. I'd like to make it public key-only, but having little luck. I've posted my ssh_config at http://pastebin.com/ma14d820. Any ideas? Thanks.

[robbak]

You don't seem to have disabled KbdInteractiveAuthentication. Maybe you could try adding that.

[dewarrn1]

And I'm an idiot. /etc/sshd_config, not /etc/ssh_config. Sorry to bother.