--On Friday, April 18, 2008 19:14:49 +1000 Gary Newcombe <[EMAIL PROTECTED]> 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, ChallengeResponseAuthentication

[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 ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to