DaemonForums  

Go Back   DaemonForums > Miscellaneous > Guides

Guides All Guides and HOWTO's.

Reply
 
Thread Tools Display Modes
  #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
  #2   (View Single Post)  
Old 27th August 2008
BuSerD's Avatar
BuSerD BuSerD is offline
Real Name: Alejandro
Noob In Training
 
Join Date: Aug 2008
Location: Houston, TX
Posts: 14
Default

Well though out and presented in an easy to follow manner. Thanks for a great post.
Reply With Quote
  #3   (View Single Post)  
Old 28th August 2008
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

You may also run SSH on a custom port (for example Port 50522).
__________________
religions, worst damnation of mankind
"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds

Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.
vermaden's: links resources deviantart spreadbsd
Reply With Quote
  #4   (View Single Post)  
Old 30th August 2008
bigb89 bigb89 is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 69
Default

Quote:
Originally Posted by vermaden View Post
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.
Reply With Quote
  #5   (View Single Post)  
Old 30th August 2008
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

Quote:
Originally Posted by bigb89 View Post
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.
__________________
religions, worst damnation of mankind
"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds

Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.
vermaden's: links resources deviantart spreadbsd
Reply With Quote
  #6   (View Single Post)  
Old 30th August 2008
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Banned
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Default

Quote:
Originally Posted by vermaden View Post
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.).
Reply With Quote
  #7   (View Single Post)  
Old 30th August 2008
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

Quote:
Originally Posted by BSDfan666 View Post
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
__________________
religions, worst damnation of mankind
"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds

Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.
vermaden's: links resources deviantart spreadbsd
Reply With Quote
  #8   (View Single Post)  
Old 30th August 2008
bigb89 bigb89 is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 69
Default

Quote:
Originally Posted by vermaden View Post
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.
Reply With Quote
  #9   (View Single Post)  
Old 31st August 2008
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

Quote:
Originally Posted by bigb89 View Post
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.
__________________
religions, worst damnation of mankind
"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds

Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.
vermaden's: links resources deviantart spreadbsd
Reply With Quote
Old 31st August 2008
harisman's Avatar
harisman harisman is offline
Fdisk Soldier
 
Join Date: May 2008
Location: Hellas (Greece)
Posts: 66
Default

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.
Reply With Quote
Old 12th September 2008
dewarrn1 dewarrn1 is offline
Port Guard
 
Join Date: May 2008
Posts: 11
Default

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.
Reply With Quote
Old 12th September 2008
robbak's Avatar
robbak robbak is offline
Real Name: Robert Backhaus
VPN Cryptographer
 
Join Date: May 2008
Location: North Queensland, Australia
Posts: 366
Default

You don't seem to have disabled KbdInteractiveAuthentication. Maybe you could try adding that.
__________________
The only dumb question is a question not asked.
The only dumb answer is an answer not given.
Reply With Quote
Old 12th September 2008
dewarrn1 dewarrn1 is offline
Port Guard
 
Join Date: May 2008
Posts: 11
Default

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

Tags
harden, secure, sshd, sshd_config

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Basic networking fail. diw OpenBSD General 13 31st March 2009 09:29 AM
Basic Perl arrays question stukov Programming 12 18th November 2008 08:44 PM
Hardening FreeBSD cajunman4life FreeBSD Security 53 7th October 2008 12:06 PM
need some basic help on ifconfig daemon-dd FreeBSD General 4 29th July 2008 03:21 PM
Can I use this link for hardening FreeBSD 7 mfaridi FreeBSD Security 1 9th July 2008 07:35 AM


All times are GMT. The time now is 12:58 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick