Great Circle Associates Firewalls
(October 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: sex, lies, and firewall code
From: Graham Wheeler <gram @ cdsec . com>
Date: Tue, 21 Oct 1997 15:11:41 +0200 (SAT)
To: firewalls @ greatcircle . com
In-reply-to: <Pine . LNX . 3 . 91 . 971021080655 . 18181C-100000 @ gargoyle> from "Paul D. Robertson" at Oct 21, 97 08:54:05 am

> 
> On Tue, 21 Oct 1997, Graham Wheeler wrote:
> 
> > > > My biggest beef with 'state-based firewalls' is that a
> > > > state-based filter cannot rewrite packets, it passes packets through,
> > > > leaving the internal network exposed to various packet attacks.
> > 
> > This is not true. Our Citadel firewall, for example, which supports both
> > proxies and state-based packet filtering, when used in transparent
> > state-based filtering mode, modifies all packets to hide
> > internal addresses and ensure that client ports are still unique as a 
> > result, as well as modifying the packet contents for FTP (PORT changes)
> > NNTP (newsgroup blocking). It also parses packet content to log FTP
> > transfers, WWW URLs, newsgroup access, etc.
> 
> I think you're missing the point completely here.  What a packet filter 
> doesn't do is rewrite what are 'legitimate' packets at the transport 
> layer.  Modifying portions of a packet isn't the same as rewriting it.  

The object-oriented design I spoke about inspects the packets and modifies
them from the Ethernet frame all the way to the application content - so
it does more than just inspecting/modifying up to the transport level. 

Also, please explain what you mean by `modifying portions of a packet isn't
the same as rewriting it'. Rewriting implies modifying, and modifying implies
rewriting, unless you have some specific definition for these terms other
than their general meaning.

Your argument neglects the fact that a proxy typically abdicates responsibility
for transport and lower level security to the TCP/IP stack, which may itself
be vulnerable to attack. 

> For instance, a packet filter won't protect an NT 4.0 base computer from OOB 
> attacks, and still allow a Solaris one to function.  You _have_ to upgrade 
> every "protected" machine or deny legitimate OOB packets.  Proxies simply 
> don't have that problem, fix the gateway and the problem immediately 
> disappears.  

I think this argument is vacuous. It all depends on the implementation.
There is no reason why a sophisticated packet filter can't allow OOB data
to some hosts and not others. There is no reason why a sophisticated 
contextual packet filtering mechanism can't emulate all the functionality
of a proxy, while the converse is clearly not the case.

[I'm talking principle here; I'm not suggesting that any of the packet 
filtering firewalls on the market take things to this extreme, nor that
they should].

> Transport and Internetwork layer bugs are erradicated with one solid proxy's 
> stack.  If the proxy is running on an OS which isn't vulnerable (taking some 

The same can be said of OO approach we use.

> In the case of other covert channels, it is certainly possible for a packet 
> filter to zero the "empty" part of a frame, or replace the data portion of 
> an ICMP echo request datagram, but most of them don't.  Proxies give you 
> that protection cheaply, it's part of the model.  Filters need to have it 
> written in.  By the time it is all written in, if that ever happens, the 
> fantastic speed increases touted by those vendors are non-existant.

Perhaps you think that the kernel TCP/IP stack consumes no resources? Either
way, the CPU has to do the work...

> Fragment attacks are another place where well-tuned proxies tend to work 
> out well by default.

Proxies don't have to worry about fragments as they sit above the TCP/IP
stack. That doesn't mean the firewall O/S is invulnerable. Also, a packet
filtering approach is arguably better at detecting and reporting such 
attacks.

> > I agree that it is much easier to write a proxy to do these things, as you
> 
> Which makes the code easier to verify, which makes the code easier to 
> write correctly, which makes the assurance level higher.  We are talking 
> security here.  

It also means that a vendor who bases a firewall only on proxies can 
hire less skilled programmers, because its easier, and these programmers
may be less aware of the issues involved, etc. 

> Hell, 99% of the firewalls out there have administrators who have never 
> done a risk analysis on SMTP or HTTP.  That sure as hell doesn't make 
> those people right, bright, or someone to base a firewall choice on.

Sure - although I think your 99% figure is a bit high ;-).

> Attackers are getting _more_ sophisticated.  Firewall administrators are 
> getting _less_ sophisticated.  Packet based firewalls are more permissive 
> than proxies.

1 & 2 I agree with. 3 remains your opinion; as someone who has spent the last
three years writing both I don't necessarily agree; it depends very much
on the implementations. 

gram
-- 
Dr Graham Wheeler                          E-mail: gram @
 cdsec .
 com
Citadel Data Security                      Phone:  +27(21)23-6065/6/7
Internet/Intranet Network Specialists      Mobile: +27(83)-253-9864
Firewalls/Virtual Private Networks         Fax:    +27(21)24-3656
Data Security Products                     WWW:    http://www.cdsec.com/



Follow-Ups:
References:
Indexed By Date Previous: Re: sex, lies, and firewall code
From: Jyri Kaljundi <jk @ stallion . ee>
Next: [no subject]
From: jhuffman @ msgroup . com (Jim Huffman)
Indexed By Thread Previous: Re: sex, lies, and firewall code
From: "Paul D. Robertson" <proberts @ clark . net>
Next: Re: sex, lies, and firewall code
From: "Paul D. Robertson" <proberts @ clark . net>

Google
 
Search Internet Search www.greatcircle.com