Re: Information on Raptor

[BGrubin () SCIENT COM (Ben Grubin)]

This sounds very much like you may want to look at Argus Systems "Gibralter"
product.  The foundation of it is a B2-secure kernel for Solaris, on top of
which there is functionality for "security gateways" which perform very much
the service you describe below, but utilize kernel-level
compartmentalization to prevent the security single point of failure issue
you talk about.

Of course conglomerating services like this does eventually lead to a loss
of performance as you do more and more complex proxying, but that's when you
start splitting off separate hardware.

---
Benjamin P. Grubin                 / bgrubin () scient com - PGP key available
Infrastructure/Security Architect / mobile (617) 513-5978 fax (617) 585-3230
Scient -- Be Legendary           / http://www.scient.com/  ticker://SCNT

> -----Original Message-----
> From: Malikai [mailto:malikai () INTERACTIVEALIEN COM]
> Sent: Wednesday, February 23, 2000 1:27 PM
> To: VULN-DEV () SECURITYFOCUS COM
> Subject: Re: Information on Raptor
>
>
> On Tue, 22 Feb 2000, James Crooks wrote:
>
> > I found that when I took the Raptor courses a few years
> ago, the instructors
> > weren't from Raptor (3rd party contractors) and either
> didn't fully understand
> > the Raptor designs or didn't agree with them. I did find that I got
> > mis-information or incomplete information from the
> instructor in a number of
> > instances.
> This in fact was my case as well. After having been "trained"
> by a third
> party who apparently had "credentials" about the product, I
> did feel like
> I will still left in the cold.
>
> - If you can't do it, teach it.
> > As an application gateway, Raptor can do more for you like
> checking protocol
> > syntax (HTTP, SMTP, etc.) for valid traffic and denying
> access if an invalid
> > protocol format is found. To be fast, packet filtering
> systems can't inspect
> > upper layer protocols to any great extent, so they
> intrinsically provide less
> > protection.
> I can certainly agree with this approach, in fact I believe it is
> certainly more "secure" for the protected systems. My only
> problem with
> this approach is that we are now using verry complex,
> nonmodular systems
> which do "too much", in my point of view as security gateways.
>
> Don't get me wrong here though, I believe that "stateful filtering" is
> certainly a high speed, and relatively simple way of approaching this,
> however it leaves you out of the water when it comes to most
> application
> level attacks.
>
> With this in mind, I believe that proxies should be
> individual, modular
> systems which all serve their own function.
>
> In fact, and I will continue this through to the entire
> security gateway
> (systems).
>
> To go for the "all round secure fantacy" I would also handle the
> VPN/encryption gateway in a seperate host as well.
>
> I think this would provide several benefits:
>
> 1. Ability to integrate both filtering and proxying into one security
> network.
> 2. Speed and reliability of filtering
> 3. Application security of proxies (which is damn good with raptor, I
> might add)
> 4. Faster VPN functionality
> 5. Multiple points of policy implementation (has benefits and caveats)
> 5. No single point of failure in security mechanisms
>
> With the last issue, I found it verry hard to personally
> accept proxies
> which handle everything on their own. I imagine in a
> nightmare scenario
> that someone compromises the firewall through one of it's
> proxies. Then
> all of a sudden, your entire security gateway has been
> undermined. In a
> scenario when there is vpn traffic going through it as well,
> we have also
> put at risk the other sites connected.
>
> > In Raptor 6.5 VPN/Tunnelled traffic is handled by the GSP
> (Generalized Service
> > Passer) with full logging support.
>
> Now this is a relief. I am unfortunately not verry familiar with the
> Raptor product, as it shows. And due to this I was verry
> weary about using
> it in VPN environments.
>
> > Application proxies aren't for everyone:
> >
> >    * Application proxy performance has a significant
> overhead per connection
> >      (you've got to do twice the number of TCP connections
> just for starters, and
> >      then you get to the proxy verification, etc.) as well
> as the overall
> >      internal/external application response time profile -
> if you want or need
> >      super-fast then stay away from proxy (but you also
> lose some application
> >      level security protection).
> >    * I don't think you can argue that a proxy external to
> the firewall is any
> >      more or less efficient than an internal one (you've to
> the extra connection
> >      to make anyway and and external box means another
> platform and OS to
> >      support, not to mention another vendor...)
> >    * Offering services (including proxy) directly from the
> firewall is a
> >      philosophical issue and could easily take on the
> aspects of a religious war
> >      (just like UNIX/Linux vs NT!).
> >    * I'm not sure that you can categorically say that
> internal proxies decrease
> >      the security of the gateway (I can spin some
> "interesting" port 80 DOS and
> >      other attacks straight thru a stateful inspection box
> that my proxy box
> >      stops cold).
> >
> > /jc
> I agree 100% with all of these statements. I do however, belive that
> people (including myself) should understand the issues
> involved with proxy
> servers and the proxy vs. filter battles. I'm sure that
> people involved in
> both ends have verry important and useful points to make. Of
> course, this
> is assuming that people can communicate about the issues, and prevent
> valid argument from becoming flame wars. [=
>
> -Malikai