--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
syslogd_flags="-b 127.0.0.1"
# sockstat | grep syslogd
root syslogd 850 4 dgram /var/run/log
root syslogd 850 5 dgram /var/run/logpriv
root syslogd 850 6 udp4 127.0.0.1:514 *:*
[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
http://www.utdallas.edu/ir/security/
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
