From owner-freebsd-questions@FreeBSD.ORG Wed Apr 18 19:57:54 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 CB6BC16A408 for ; Wed, 18 Apr 2007 19:57:54 +0000 (UTC) (envelope-from hunteke@earlham.edu) Received: from sipala.earlham.edu (sipala.earlham.edu [159.28.1.75]) by mx1.freebsd.org (Postfix) with ESMTP id 4A11B13C45D for ; Wed, 18 Apr 2007 19:57:54 +0000 (UTC) (envelope-from hunteke@earlham.edu) Received: from [159.28.7.5] (ec454.lly.earlham.edu [159.28.7.5]) (authenticated bits=0) by sipala.earlham.edu (8.13.6/8.13.6) with ESMTP id l3IJvr96007458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Apr 2007 15:57:53 -0400 (EDT) X-Authentication-Warning: sipala.earlham.edu: Host ec454.lly.earlham.edu [159.28.7.5] claimed to be [159.28.7.5] In-Reply-To: <22C0F9E3-6A59-4164-94DD-8F0677C3E37D@mac.com> References: <669BB85F-59F2-4DDE-ADAA-0111A0E85967@earlham.edu> <20070418144246.bab7d6d5.wmoran@potentialtech.com> <22C0F9E3-6A59-4164-94DD-8F0677C3E37D@mac.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <563741EE-3A65-438C-8D75-AD8A4B7A12DD@earlham.edu> Content-Transfer-Encoding: 7bit From: Kevin Hunter Date: Wed, 18 Apr 2007 15:57:03 -0400 To: Chuck Swiger X-Mailer: Apple Mail (2.752.3) 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:57:54 -0000 At 3:46p -0400 18 Apr 2007, Chuck Swiger wrote: > On Apr 18, 2007, at 12:17 PM, Kevin Hunter wrote: >> At 2:42p -0400 18 Apr 2007, Bill Moran wrote: >>> 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. > > You should consider just how difficult it is to rename a malicious > program to, say, "ssh" in order to get around such checking. > (Answer: trivial.) If you really want to control traffic in this > fashion, you should look towards what the industry calls "deep > packet inspection" or mandatory usage of proxies for all permitted > protocols, instead. Hrm. I was assuming that if I got into the nitty gritty, I could do more than just check the name of the binary, but perhaps not? Thanks for the warning. >>> Do you not have control over what is run on this system? >> >> So perhaps our specific example might be prudent: [snip] >> 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. >> >> How have others handled this type of scenario, where a hardening >> of a bastion host has been desired/necessary? > > The main approaches are to use a stateful firewall ruleset, to > explicitly permit return traffic via additional rules, or to simply > permit established connections through. These options are arranged > in rough order of how secure they are. I have been given to understand that this approach does not lend itself to fine-tuning down the road, if such -- for /some/ reason -- were needed. . . .? > I suspect that you are encountering a steep learning curve, You are /probably/ (read: definitely) correct. I am. :-) > and that some additional reading will help you make much better > decisions about how to configure a firewall. > > Consider getting either or both of: > > "Building Internet Firewalls", ISBN-10: 1565928717 > http://www.oreilly.com/catalog/fire2/ > > "Firewalls and Internet Security: Repelling the Wily Hacker", > ISBN-10: 020163466X > http://www.aw-bc.com/catalog/academic/product/0,1144,020163466X, > 00.html Will look into those. Thank you again. Kevin