From owner-freebsd-questions@FreeBSD.ORG Fri Apr 18 18:53:38 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 3C5DD106566B for ; Fri, 18 Apr 2008 18:53:38 +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 18AFA8FC0C for ; Fri, 18 Apr 2008 18:53:38 +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 CB31F65510 for ; Fri, 18 Apr 2008 13:53:37 -0500 (CDT) Date: Fri, 18 Apr 2008 13:53:37 -0500 From: Paul Schmehl To: freebsd-questions@freebsd.org Message-ID: <4BCB6B9718ABAC4774F5506E@utd65257.utdallas.edu> In-Reply-To: <200804182030.57588.fbsd.questions@rachie.is-a-geek.net> References: <2tng04doovnmtkr7or9kfkb596fgjfoj1c@4ax.com> <20080418191449.212f43d3.gary@pattersonsoftware.com> <1EBA9459C137D287EEE2560D@utd65257.utdallas.edu> <200804182030.57588.fbsd.questions@rachie.is-a-geek.net> 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 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 18:53:38 -0000 --On Friday, April 18, 2008 20:30:53 +0200 Mel wrote: > On Friday 18 April 2008 16:53:49 Paul Schmehl wrote: > >> Firewalls are for preventing access to running services. By definition, if >> you are running a service, you want it to be accessed. > > That's your assumption. > First of all, firewalls are for preventing unwanted connections, this is not > necessarily the same as access to running services. > Prime examples: cable modem and windows hosts broadcast spam on an ISP's > network, ping floods. User scans [1], vulnerability scans, open relay > scanners, spammers fall into running services category. > They don't fall into the category of services that you authorized or approved of. Keep in mind, we're talking about *hosts*, individual workstations if you will, not enterprises. > >> 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***. > > It is an illusion to think that the patch always comes before the exposure. It's a worse illusion to believe the firewall is going to help. If the service is exposed and compromised, the firewall wouldn't be blocking it anyway. Furthermore, if the host is compromised, the firewall is one of the first things that will be disabled. > Secondly, pending the ammount of services you offer, this can be a full task > and especially for the "hobby" category, it is more time-efficient to shut > off any unauthorized traffic to begin with. > Say, some webapp allows uploading a file and executing it. It is then quite > easy to add a daemon to your server, that you have not configured. With a > firewall in default block mode, this daemon does not receive connections. > Even when the patch is released before exposure, you could be, say sleeping > and it can be too late. For some this is paranoia, for others common sense. > Again, the firewall is providing a false sense of security in exactly the scenario you propose. Where do you think hacker's daemons are running these days? **On the ports that you can't close on the firewall**. > >> [4] # grep sshd /etc/defaults/rc.conf >> sshd_enable="NO" # Enable sshd > > No? Surely you're not using inetd? I haven't used inetd in years. I'm not sure why you think I would be. -- Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/