[SSHd] Limiting access from authorized IP's

Paul Schmehl pauls at utdallas.edu
Fri Apr 18 14:53:50 UTC 2008

--On Friday, April 18, 2008 19:14:49 +1000 Gary Newcombe 
<gary at pattersonsoftware.com> wrote:
> ssh is part of the base system, not an installed port (by default anyway) so
> you won't see it with pkg_info which will only list installed packages. The
> config file is /etc/ssh/sshd_config.
> To limit connections, you should be using the firewall. I do use hosts.allow
> too, but the firewall is your primary defence.

I see this statement all the time, and I wonder why.  What does a firewall on 
an individual host accomplish?

I have maintained publicly available servers for a small hobby domain for 
almost ten years now.  Initially, I bought in to this logic and ran a firewall. 
(At that time we only had one server.)  What it cost me was CPU and memory. 
What it gained me was nothing.  I turned it off.  I have never run a firewall 
on a publicly available host since.

Firewalls are for preventing access to running services.  By definition, if you 
are running a service, you want it to be accessed.  So firewalls are 
self-defeating or completely useless at the host level **unless** you don't 
know what you're doing.  For an enterprise they make a great deal of sense.  No 
matter what a user inside your network might do, you can prevent access by 
simply not allowing traffic on that port.

For an individual host it makes a great deal more sense to only run those 
services you intend to use ***and keep them up to date and properly 
configured***.  If you're running syslogd on 514/tcp (because it installs that 
way be default) and you're not running a syslogd server, then that is an error 
on your part [1].  If you're running cupsd listening on 631/tcp, but you're not 
running a print server, then that's an error [2].

Secondly, for those services that you *must* have publicly available, research 
what protections are available (e.g. mod_security for apache, hosts.allow for 
other services.)

Read the man pages.  Learn to lock down your box properly.  Then, spend your 
time and attention on the services that *are* exposed (because they have to be) 
and make sure you have those fully patched and properly configured.  ****Never, 
ever, ever, run a service that you do not intend to use and have it listening 
on a port!****  Those are the doors hackers use to get in.

Firewalls are too often crutches for people that don't want to learn how to 
properly maintain a host.

If *everyone* knew how to properly configure and maintain a host, even 
enterprise firewalls would be completely unnecessary.

To the OP, you *must* run sshd to remotely access your box.  There are several 
things you can (and should) do.

1) Don't allow root logins (that is now the default configuration)
2) Only allow protocol 2 (now also the default)
3) Consider not allowing any logins and requiring cert exchange instead [3]
4) Consider using ChallengeResponseAuthentication (see [3])
5) Consider running sshd on a different port [4]
6) Consider using /etc/hosts.allow to restrict access

[1] # grep syslogd /etc/rc.conf
# sockstat | grep syslogd
root     syslogd    850   4  dgram  /var/run/log
root     syslogd    850   5  dgram  /var/run/logpriv
root     syslogd    850   6  udp4         *:*

[2] # grep -i LISTEN /usr/local/etc/cups/cupsd.conf
# Only listen for connections from the local machine.  Use unix sockets and 
disable ip completely when possible.
#Listen localhost:631
Listen /var/run/cups.sock
# sockstat | grep cupsd
root     cupsd      6208  3  stream /var/run/cups.sock
root     cupsd      6208  4  udp4   *:631                 *:*

(If anyone knows how to disable the udp port as well, let me know.)

[3] man (5) sshd_config - see AuthorizedKeysFile, 

[4] # grep sshd /etc/defaults/rc.conf
sshd_enable="NO"                # Enable sshd
sshd_program="/usr/sbin/sshd"   # path to sshd, if you want a different one.
sshd_flags=""                   # Additional flags for sshd.
man (8) sshd -p port flag

Paul Schmehl (pauls at utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas

More information about the freebsd-questions mailing list