Date: Wed, 18 Apr 2007 15:57:03 -0400 From: Kevin Hunter <hunteke@earlham.edu> To: Chuck Swiger <cswiger@mac.com> Cc: FreeBSD Questions <freebsd-questions@freebsd.org>, Randy Schultz <schulra@earlham.edu> Subject: Re: program/binary ip filtering Message-ID: <563741EE-3A65-438C-8D75-AD8A4B7A12DD@earlham.edu> In-Reply-To: <22C0F9E3-6A59-4164-94DD-8F0677C3E37D@mac.com> References: <669BB85F-59F2-4DDE-ADAA-0111A0E85967@earlham.edu> <20070418144246.bab7d6d5.wmoran@potentialtech.com> <D78E83C6-6EC4-4656-90A7-8ABEC0E5406F@earlham.edu> <22C0F9E3-6A59-4164-94DD-8F0677C3E37D@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?563741EE-3A65-438C-8D75-AD8A4B7A12DD>