From owner-freebsd-questions@FreeBSD.ORG Fri Apr 18 19:37:52 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 38FB6106566C for ; Fri, 18 Apr 2008 19:37:52 +0000 (UTC) (envelope-from fbsd.questions@rachie.is-a-geek.net) Received: from snoogles.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id B97468FC1A for ; Fri, 18 Apr 2008 19:37:51 +0000 (UTC) (envelope-from fbsd.questions@rachie.is-a-geek.net) Received: from localhost (localhost [127.0.0.1]) by snoogles.rachie.is-a-geek.net (Postfix) with ESMTP id B07761CC91; Fri, 18 Apr 2008 11:37:49 -0800 (AKDT) From: Mel To: freebsd-questions@freebsd.org Date: Fri, 18 Apr 2008 21:37:45 +0200 User-Agent: KMail/1.9.7 References: <2tng04doovnmtkr7or9kfkb596fgjfoj1c@4ax.com> <200804182030.57588.fbsd.questions@rachie.is-a-geek.net> <4BCB6B9718ABAC4774F5506E@utd65257.utdallas.edu> In-Reply-To: <4BCB6B9718ABAC4774F5506E@utd65257.utdallas.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804182137.47157.fbsd.questions@rachie.is-a-geek.net> Cc: Paul Schmehl 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 19:37:52 -0000 On Friday 18 April 2008 20:53:37 Paul Schmehl wrote: > --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. Well, I don't particularly like someone using my bandwidth to find out if I changed my mailserver config to such that I would now be an open relay, every 10-20 minutes for weeks on end, so I want it to be over with at the TCP level, not at the daemon level. Individual hosts are exactly the target for these scans. Same with the webserver, there are a great number of requests that seperate a scan from a legitimate user. > >> 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. In a targetted scenario, this is correct. However, scans precede the attack and one example I gave with grok, you can limit the chances that the attacker gets the information he needs to exploit the bug he's looking for. > Furthermore, if the host is compromised, the firewall is one of the > first things that will be disabled. That would require root. So there's something else wrong in the chain, or it is one of those unfortunate services that run as root. > > 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**. I'm curious which those are. > > >> [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. Well, since sshd_enable is set to no, I assumed inetd would be where you've started it. -- Mel Problem with today's modular software: they start with the modules and never get to the software part.