On Thu, 1 Jul 2004, Peter Curran wrote:
> On Wednesday 30 June 2004 22:16, Bart Simpson wrote:
> > 1. application level gateway (Socks5) with authentication, granular
> > controls as in time,date etc... Today's firewalls need more then just
> > packet
> > filtering. Most use a combo of application/packet-filter
> 
> Interesting observation.  Socks is an example of a circuit or transport 
> gateway.  Jolly useful for authentication, but no better than a packet filter 
> when it comes down to looking at the actual content of an application session 
> (to do intelligent URL filtering, filter active content, check viruses, etc).

That's not true at all.  TCP is a stream-oriented protocol, and examining
(or worse, modifying) the stream at the packet level is very complicated
and very bug-prone.  Many packet-oriented hacks for TCP-based protocols
just plain don't work right when packet boundaries fall in "inconvenient"
places.  Note that this issue isn't limited to "content-based filtering";
even things as mundane as making FTP work properly through NAT suffer from
the need to examine and perhaps manipulate data in the control connection.

If you really have to deal with a stream, then deal with a stream,
i.e. *above* TCP, but try to avoid that at all as much as possible, due to
performance issues.


There's another *huge* benefit to SOCKS that's often overlooked.  SOCKS
isn't just a simple proxy.  Client functions like bind() and listen(),
which don't ordinarily generate network traffic (and thus are invisible to
firewall/NAT code) negotiate with the SOCKS server such that it looks to
the application as if it were actually running on the same machine as the
SOCKS server.  I.e., if it asks for the local IP address of a connection
(perhaps to send to a peer), it gets the *server's* IP address (meaning
its WAN IP for a WAN connection).  Similarly, it gets the server's port
number.  And if it does a listen(), the *server* does a listen(), and the
incoming connection is properly fielded without explicitly setting up NAT
redirection.

The upshot of this is, that for anything that works through SOCKS at all,
it's usually not necessary to have *any* hackery specific to the
application protocol to deal with NAT issues (except for protocols like
PPTP that *really* go out of their way to be obnoxious :-)).  However,
there are two important limitations:

1) Initially, SOCKS only worked for TCP, with a horrible disgusting kludge
for ping and traceroute.  As of SOCKS5, UDP is now supported as well, but
AFAIK other protocols (e.g. GRE) aren't.  (Even supporting GRE wouldn't
fix the PPTP control-connection problem)

2) Unlike NAT, SOCKS isn't transparent to the client.  The client either
needs to run "socksified" applications, or run a transparent SOCKS proxy
that intercepts socket calls and performs the proper "SOCKS magic".  Most
web browsers and a number of other applications fall into the first
category, and the second approach is available for many platforms these
days, sometimes even built-in.

> If you go down the Socks route, then there is a performance penalty to pay.  

Yes, that's the main downside, and why it shouldn't be used
indiscriminately.  But having it available to handle NAT-unfriendly
protocols that have neither special NAT hacks nor application proxies
would improve overall capability.

It's too bad that SOCKS didn't use a separate control connection rather
than prepending the negotiations to each "real" connection.  With the
former approach, it might have just interfaced to NAT to do the actual
data forwarding at the packet level.

> If you go for the functionality of application proxies, and start doing some 
> content checking/filtering then there is a severe performance penalty.  If 
> the platform is big and meaty then this probably doesn't matter.  My platform 
> is a Soekris Net4501 and I think it will barf if you feed it a proxy-based 
> environment.  A Net4801 may be bettter.

An application proxy per se is no worse than SOCKS, but yeah, once you
start doing content-based filtering it gets expensive.  In that case, you
need the NetNanny9901 (with multiple quad-processor Power4s) to check all
the GIFs and JPEGs to be sure they don't contain offensive content. :-)

> This sounds similar to the 'interesting exchange of views' in a recent 
> soekris-tech thread.  Could you explain why running a gui via https is less 
> secure than tunneling an X session over SSH, or using a protocol like 
> checkpoint's (which I think is just using secure sockets as well).??

The GUI per se isn't less secure, but relying on HTTP authentication is
horrible.  The problem is that HTTP was originally designed to be
stateless, but a "stateless authenticated session" is an oxymoron.  Since
users would scream bloody murder if they had to reenter the username and
password on every page, every frame, and every image, browsers normally
cache and/or save the authentication info.  But they're notoriously bad
about giving the user enough control over this, or even making it clear
what they're doing.  The net result is that there's usually no explicit
"logout" from an HTTP-authenticated session, and in Windows, if you forget
to turn off the "save password" checkbox even once, that browser is now
semipermanently "logged in" to the GUI.  If that isn't enough, throw in
some "interesting" Javascript from a malicious site and see what happens.

Forwading an X11 session is another interesting approach, though I don't
know if the footprint of even just the "client" side of X is small enough
to be plausible on something like a Soekris.  And there seem to be enough
security concerns about X11 forwarding to have it disabled by default in
recent versions of OpenSSH.  This largely seems to be the result of X11's
backwards concept of "client" vs. "server".

> Lots of 'network security engineers' are popping up all over with similar 
> comments.  Well, I am a network security engineer with 10+ years experience 
> not just of deploying firewalls, but also building them.  I quite like the 
> m0n0 GUI and have no issues over security.  What I would add, however, is 
> client-side authentication so that I can use a cert rather than name/pass for 
> access.

One way to do this is to have SSH available and limit HTTP access to
localhost.

> > 8. Switch the core to OpenBSD. Its a firewall right? OpenBSD just has
> > better code audits and they are the ones that own the frontier when it
> > comes to security and reliability. Just makes since when you building a
> > firewall to use the best options. I would at least dump IPF for PF as PF
> > is just amazing with its flexibility, scalability, ability and onslaught
> > of perfection. We reduced our cost by 35% by just using PF. Our traffic
> > ambiguous errors are over. We have never failed a audit using open, and
> > as a admin
> > / engineer you sleep better @ night knowing that your gates are
> > protected by the best
> > of the best. Personally i think freebsd does a better job in situations
> > like http servers
> > and i use them as such.  It's rather simple semantics, use the best in
> > the field you are working on and open is the leader in security.  IMHO!
> >
> Agreed

I would agree, and note that the main argument against this (aside from
the effort involved in switching) seems to be performance.  But there are
a couple of things worth noting in that regard:

1) In general, each BSD variant has its particular "thrust".  FreeBSD's is
mainly servers (running on x86 hardware; anything else besides Alpha be
damned).  NetBSD's is portability.  OpenBSD's is security, and hence
indirectly firewall/router uses.  Because of the latter, improving routing
performance is an area of significant priority in OpenBSD development.  
No Unix-based router can escape the fundamental problem of being designed
as a host that can also do routing, rather than vice-versa, but a focus on
routing performance certainly helps.

2) Security is a much more pervasive issue than performance, since the
latter is usually focused in specific areas of the code.  Thus, improving
the performance of code with good security is usually a lot easier than
the converse.  Not that FreeBSD's security is *bad*, but it doesn't get
the same level of attention that OpenBSD's does.

					Fred Wright