In one section of the book (Page 301) the author contrasts nmap to "Firewalk". He says, "nmap cannot differentiate between what is open on an end machine and what is being firewalled. Firewalk, on the other hand, can determine if a given port is allowed through a packet-filtering device.With this information, Firewalk allows an attacker to determine your firewall rule set." I get the impression he thinks Firewalk is superior to nmap (although he doesn't come right out and SAY that).
He then shortly thereafter says, "Firewalk even works against traditional and stateful packet filters, which both just decrement the TTL by one. However, Firewalk does not work against proxy based firewalls, because proxies do not forward packets. Instead, a proxy application absorbs packets on one side of the gateway and creates a new connection on the other side, destroying all TTL information in the process. Packet filters actually forward the same packets, after applying filtering rules, keeping the TTL relatively intact (albeit decremented by one). So, although Firewalk is a highly effective technique against packet filter firewalls, it does not work at all against proxy firewalls. For services that the firewall is proxying, Firewalk reports that the associated ports are closed." Statements like this are what started me thinking I'd ask some of you (who probably know a whole lot more about this than I do :-)) your opinion about an OpenBSD with Squid. It sounds like a powerful combination to me! :-) Ed On Sun, Mar 23, 2008 at 1:42 PM, System Administrator <[EMAIL PROTECTED]> wrote: > 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
