From owner-freebsd-questions@FreeBSD.ORG Wed Apr 18 19:32:26 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7ED716A403 for ; Wed, 18 Apr 2007 19:32:26 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from mail.potentialtech.com (internet.potentialtech.com [66.167.251.6]) by mx1.freebsd.org (Postfix) with ESMTP id A72C913C45A for ; Wed, 18 Apr 2007 19:32:26 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from vanquish.pgh.priv.collaborativefusion.com (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.potentialtech.com (Postfix) with ESMTP id E9B57EBC7A; Wed, 18 Apr 2007 15:32:25 -0400 (EDT) Date: Wed, 18 Apr 2007 15:32:24 -0400 From: Bill Moran To: Kevin Hunter Message-Id: <20070418153224.ee867438.wmoran@potentialtech.com> In-Reply-To: References: <669BB85F-59F2-4DDE-ADAA-0111A0E85967@earlham.edu> <20070418144246.bab7d6d5.wmoran@potentialtech.com> X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Questions , Randy Schultz Subject: Re: program/binary ip filtering 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: Wed, 18 Apr 2007 19:32:26 -0000 In response to Kevin Hunter : > At 2:42p -0400 18 Apr 2007, Bill Moran wrote: > >> We are in the process of setting up a bastion host. One of the > >> things we'd like to do is to filter packets not only at the ip > >> layer, but by what program is listening on a particular port. Is > >> this a possibility? > > > > Are you saying that you want to have the packet filter check to see > > what application is listening on a particular port, then allow/deny > > access based on the name of the application? > > Exactly. > > > Do you not have control over what is run on this system? > > So perhaps our specific example might be prudent: > > kevin $: ssh bastion > bastion $: ssh internalserver > > > Relevant part of log: > > Apr 18 09:35:23 kappia ipmon[405]: 09:35:22.695348 fxp0 \ > @0:4 b internalserver,22 -> bastion,53136 PR tcp \ > len 20 52 -AS IN > > It's blocking because we are dropping all packets not destined for > port 22. Since ssh /from/ the bastion picks a random high port, it's > dropping all the return packets to that random high port. Your packet filter rules are wrong. Without knowing what product you're using, I can't say the exact way to fix it, but the generally rule is that you either need to write stateful rules (so that the initial connection creates a state that is then used to allow traffic in both directions) or you need to create two rules -- one to allow traffic out, the other to allow traffic in. Stateful filtering is generally considered to be more secure, but you then have concerns about properly maintaining state tables, which can be a problem on very busy servers. However, the problem you're describing now seems to be a completely different problem from the one described in the previous email. It's possible that I've misunderstood both of them. > How have others handled this type of scenario, where a hardening of a > bastion host has been desired/necessary? Again (unless I'm misunderstanding) through properly written filter rules. The current trend seems to be toward using stateful filtering. > > However, you might be able to accomplish this by using a pf table, > > then having a secondary script update the table based on the output > > of sockstat or some other similar hack. > > We did not know about this utility. We'll check out your idea. > Thank you for the pointer. We'll let the list know how it > goes. :-) (Of course, if there's a standard, cut and dry solution, > that'd be ideal!) -- Bill Moran http://www.potentialtech.com