On 23 Mar 2008 at 7:58, Ed Flecko wrote: > The book is called "Counter Hack Reloaded: A Step-by-Step Guide to > Computer Attacks and Effective Defenses (2nd Edition)" - > http://www.amazon.com/Counter-Hack-Reloaded-Step-Step/dp/0131481045/re > f=pd_bb > s_1?ie=UTF8&s=books&qid=1206284032&sr=8-1 > > The author makes several references to "proxy firewalls" and implies > they are more secure than "traditional" firewalls because they > ignore > typical reconnaissance, probing attempts like nmap, etc. because > they > function at the application layer.
Assuming you have correctly understood the author's intent, then he is completely wrong. There is no difference in the abilities of either proxy or packet-filtering firewalls to block probing (reconnaissance) attempts. In fact, it is much much easier to configure a stealthy (or "invisible") firewall with a powerful packet filtering engine like OpenBSD's pf. The main argument about proxy firewalls being more secure focuses on the ease of configuration, or more specifically on the fact that it is fairly easy for a novice to mis-configure a packet-filter wide open, whereas a well designed application gateway will preclude such a faux- pas. The second half of the same argument has to do with content analysis -- application gateways (proxies) by definition operate at the application layer and have an inherent ability to analyze the application specific data content and react accordingly, including extensive data re-writing and manipulation. A properly designed packet filter operates only on TCP/IP headers and is oblivious of the payload (data content). This is the reason OpenBSD's pf(4) requires the support of ftp-proxy(8) to allow FTP data transfers across the firewall. For a thorough discussion of this issue (payload manipulation on the firewall) please check the list archives -- there has been a number of excellent threads recently. If you've come from Linux world or have looked at some Linux-based commercial firewalls, you have probably seen the term "deep packet inspection". That is an ugly hack whereby the packet filter uses various special cases to examine the payload of the packets passing the firewall. While at first glance this approach seems to provide more control than generic packet header filtering, it still falls way short of the capabilities and reliability of a true proxy -- after all, it still operates on individual packets and will miss many things due to normal or malicious fragmentation. So, to bring it back to your original question, a typical SOHO OpenBSD firewall is a packet filtering firewall even with a Squid Cache running. After all, which part of the firewall actually implements the security policy and handles the traffic control? BTW, even if you were to add some application gateways to your OpenBSD firewall, you would only have a "hybrid" firewall, i.e. one that combines the features and functionality of both packet filtering and proxying. The classic, or "true" proxy firewall turns IP forwarding off and requires that any traffic crossing the firewall use a dedicated proxy. Such firewalls are never transparent -- the client computers always make their connections to the firewall itself regardless of what the ultimate destination may be. Moreover, because they require a specialized application (the proxy) for every type of communication that is to be supported across the firewall, they are typically very expensive -- too many development hours for a share of a relatively small market of deep-pocketed customers ;-) > > Ed > > On Sat, Mar 22, 2008 at 7:38 AM, Lars Noodin > <[EMAIL PROTECTED]> > wrote: > > Ed Flecko wrote: > > > I'm reading a book on network security and it mentions "proxy > > > firewalls" ... are there other "proxy firewalls" the > > > author is referring to? > > > > Which book? Title, author, ISBN would help. Or send a link to a > review. > > > > > > > As a matter of curiosity, has anyone ran an nmap scan against > an > > > OpenBSD box with Squid? What did the scan results indicate? > > > > The results depend entirely on how you have Squid set up and how PF > is > > configured. > > > > Regards, > > -Lars > > --------------------------------------------------------- System Administrator [EMAIL PROTECTED] Bitwise Internet Technologies, Inc. 22 Drydock Avenue tel: (617) 737-1837 Boston, MA 02210 fax: (617) 439-4941
