From owner-freebsd-questions@FreeBSD.ORG Fri Apr 18 14:53:50 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5313E106566B for ; Fri, 18 Apr 2008 14:53:50 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp3.utdallas.edu (smtp3.utdallas.edu [129.110.10.49]) by mx1.freebsd.org (Postfix) with ESMTP id 1CBA58FC22 for ; Fri, 18 Apr 2008 14:53:50 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from utd65257.utdallas.edu (utd65257.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTP id 835CD6550E; Fri, 18 Apr 2008 09:53:49 -0500 (CDT) Date: Fri, 18 Apr 2008 09:53:49 -0500 From: Paul Schmehl To: Gary Newcombe , freebsd-questions@freebsd.org Message-ID: <1EBA9459C137D287EEE2560D@utd65257.utdallas.edu> In-Reply-To: <20080418191449.212f43d3.gary@pattersonsoftware.com> References: <2tng04doovnmtkr7or9kfkb596fgjfoj1c@4ax.com> <20080418191449.212f43d3.gary@pattersonsoftware.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Re: [SSHd] Limiting access from authorized IP's X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2008 14:53:50 -0000 --On Friday, April 18, 2008 19:14:49 +1000 Gary Newcombe 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 (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/