Re: Gauntlet 6.0

[firewalls () msg net <firewalls () msg net>]

FYI, I have a few minor Gauntlet bugs open, including one that could be a
rather serious security problem in certain rare circumstances.  So far NAI
has been reasonably responsive, so I'm not (yet) annoyed enough to publish.


> While awaiting arrival of hardware to install Gauntlet 6.0 on, I've been
> perusing the docu. The following come to mind:

The docs are good, but you really need hands-on experience, even just
an antique Ultra-1 which just barely boots with the sofware loaded.

I've built a Solaris-8 'jumpstart' server that does 100% of the OS install
work and 60% of the firewall installation, so I can build and destroy
Gauntlet 6.0 firewalls without typing much more than 'boot net - install'.

As part of this process I've stripped down the list of installed clusters
and patches to the bare minimum necessary to run, administer, and debug the
firewall- I believe I actually install less of Solaris than the E-ppliance.
I'd be happy to publish the install scripting details here or elsewhere.

 
> - Plugs-TCP redirect addressing - This appears to require static routing to
>   the specific redirected address to be propagated upstream (until some
>   NSP/ISP filters it out). Is this how it works? Has any one encountered a
>   real-world scenario where this feature is useful?

I am not sure what you mean by 'redirect addressing'?

We use the 'handoff host' or 'destination address' feature, this doesn't
require any special routes or other strangeness. For example, if I have a
user inside who absolutely has to have access to a vendor supplied service
on port 8282, instead of putting in permit destination rules, I put in a plug
proxy such that permitted internal users who attempt to connect to _any_
Internet address on port 8282 are connected specifically to the one vendor
host IP on port 8282, or another port of my choosing.  There are other uses
for this feature as well.

A practical use- force port 25 connections destined for the Internet to instead
go through your corporate mail gateway.

 
> - This Gauntlet-to-be-installed interposes a WebLogic app server and its
>   clients, which are Java servlets on Internet-facing web servers. Is there
>   a compelling security reason to use the plug proxy instead of packet
>   filtering for the WebLogic t3/t3s protocols? (Doubtless my client's
>   techies will cite performance reasons against the proxy...)

IME, the proxy doesn't hurt performance all that much- there is some
added latency, mostly in connection setup. What you gain with a proxy over
packet filter rules is the full 'application proxy' security layer- the
IP stack on the inside machine never communicates with the IP stack on
the outside. No chance of slipping packets through weak sequence number
checking, etc.

Gauntlet's "adaptive proxy" features supposedly give the benefits of both
world's -- the speed of packet filtering with the security of an application
proxy.


OTOH, there is one drawback to TCP plug proxies over filter rules--
if the remote listener is refusing connections or is not answering (down),
the plug will still accept the connection, then immediately drop the session
and log an error when the destination refuses the connection or the connect
times out. This can confuse badly written applications (cough-Java-cough)
that assume that a successful 'connect' means that everything is hunky-dory
and just start spewing data without waiting for a response from the remote
host...

Kevin Kadow
MSG.Net, Inc.
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards