[prev in list] [next in list] [prev in thread] [next in thread] 

List:       firewalls-gc
Subject:    Re: Guantlet vs FW1
From:       Frederick M Avolio <fred () avolio ! com>
Date:       1999-11-29 19:55:40
[Download RAW message or body]

I hadn't replied to this because I didn't plan to. But someone sent me 
email sort of encouraging me to. See comments in line.

At 12:38 PM 11/24/99 +0000, Gavin Kerr wrote:
> > If you are saying that there are some attacks for which an application
> > gateway leaves you vulnerable that a packet filter doesn't... well
> > maybe I am tired (leaving myself a not-so-graceful out), but I don't
> > think so.  Maybe it is semantics. Would you be specific?
>


>An application proxy (Bastion host) is generally more susceptible to a
>direct attack. It is running services etc and, therefore, has bugs that
>can be exploited.

I see your point, but it is based on the false premise. First, we ought to 
clarify terms. A "bastion host" is a hardened host (often running a 
multipurpose operation system, such as UNIX or NT) usually used as a 
foundation for a firewall. This can be any kind of firewall -- application 
gateway (aka proxy-based), circuit, packet filter -- stateful/dynamic or 
static, or a hybrid. A "bastion host" can (should) also be the foundation 
for a web server, for example.

A bastion host, by definition, does not run a lot of services. Those that 
it does run are made as secure as possible. While the base OS is generally 
more complex than that of a router, and so possibly more vulnerable to 
attack, router operating systems have had reported vulnerabilities (see 
CERT advisories on Cisco IOS).

>A packet filter (as was said before) allows a person to connect directly
>to a machine inside your network.

Of course, which is what makes the statement that this is your standard, 
recommended configuration so extraordinary.


>So they are both "vulnerable" to different kinds of attack. In the case
>of the proxy host, to a direct attack, and in the case of a packet
>filter, to an attack on your actual systems.

So in the first case the firewall can be attacked and may make your entire 
network vulnerable. In the second case, every host on the inside can be 
attacked making your entire network vulnerable. Along with Mark Twain, I 
like putting all my eggs in the one basket...

>The packet filter setup makes it that much harder for them to get beyond
>the DMZ (And the machines that I set up in a way to make them less
>vulnerable to attack) and on to the machines that are on the internal
>network, and we're back to the "go attack someone else, it's easier". If
>I'd gone for a bastion host / proxy setup, then I'd be open to every
>script kiddie that had an exploit for a bug in a service on the
>firewall.

This would be true if the bastion host were not a bastion host. But then in 
your suggested setup every internal host is at the mercy of every script 
kiddie who has a script for any of your allowed services that you allow 
from the outside to every inside host.

>As I said, it's a matter of design. If I was running an e-commerce site
>I'd look at it in a far different way. Probably involving packet filters
>*and* port redirection from a bastion host, but it's unecessarily
>complicated for the network we have here, and the limited services being
>allowed to the net (WWW site only).

Granted for a particular network the less granular, more permissive 
filtering setup you describe is probably adequate. What got my attention 
was your statement that this is your commonly recommended configuration. 
Nevertheless I am not looking for a fist fight after school on the 
playground. :-)


Fred
Avolio Consulting
16228 Frederick Road, PO Box 609, Lisbon, MD 21765, US
+1 410-309-6910 (voice) +1 410-309-6911 (fax)
http://www.avolio.com/

[Attachment #3 (text/html)]

<html>
I hadn't replied to this because I didn't plan to. But someone sent me
email sort of encouraging me to. See comments in line.<br>
<br>
At 12:38 PM 11/24/99 +0000, Gavin Kerr wrote:<br>
<blockquote type=cite cite>&gt; If you are saying that there are some
attacks for which an application<br>
&gt; gateway leaves you vulnerable that a packet filter doesn't...
well<br>
&gt; maybe I am tired (leaving myself a not-so-graceful out), but I
don't<br>
&gt; think so.&nbsp; Maybe it is semantics. Would you be specific?<br>
<br>
</blockquote><br>
<br>
<blockquote type=cite cite>An application proxy (Bastion host) is
generally more susceptible to a<br>
direct attack. It is running services etc and, therefore, has bugs
that<br>
can be exploited.<br>
</blockquote><br>
I see your point, but it is based on the false premise. First, we ought
to clarify terms. A &quot;bastion host&quot; is a hardened host (often
running a multipurpose operation system, such as UNIX or NT) usually used
as a foundation for a firewall. This can be any kind of firewall --
application gateway (aka proxy-based), circuit, packet filter --
stateful/dynamic or static, or a hybrid. A &quot;bastion host&quot; can
(should) also be the foundation for a web server, for example.<br>
<br>
A bastion host, by definition, does not run a lot of services. Those that
it does run are made as secure as possible. While the base OS is
generally more complex than that of a router, and so possibly more
vulnerable to attack, router operating systems have had reported
vulnerabilities (see CERT advisories on Cisco IOS).<br>
<br>
<blockquote type=cite cite>A packet filter (as was said before) allows a
person to connect directly<br>
to a machine inside your network.</blockquote><br>
Of course, which is what makes the statement that this is your standard,
recommended configuration so extraordinary. <br>
<br>
<br>
<blockquote type=cite cite>So they are both &quot;vulnerable&quot; to
different kinds of attack. In the case<br>
of the proxy host, to a direct attack, and in the case of a packet<br>
filter, to an attack on your actual systems.<br>
</blockquote><br>
So in the first case the firewall can be attacked and may make your
entire network vulnerable. In the second case, every host on the inside
can be attacked making your entire network vulnerable. Along with Mark
Twain, I like putting all my eggs in the one basket...<br>
<br>
<blockquote type=cite cite>The packet filter setup makes it that much
harder for them to get beyond<br>
the DMZ (And the machines that I set up in a way to make them less<br>
vulnerable to attack) and on to the machines that are on the
internal<br>
network, and we're back to the &quot;go attack someone else, it's
easier&quot;. If<br>
I'd gone for a bastion host / proxy setup, then I'd be open to 
every<br>
script kiddie that had an exploit for a bug in a service on the<br>
firewall.<br>
</blockquote><br>
This would be true if the bastion host were not a bastion host. But then
in your suggested setup every internal host is at the mercy of every
script kiddie who has a script for any of your allowed services that you
allow from the outside to every inside host.<br>
<br>
<blockquote type=cite cite>As I said, it's a matter of design. If I was
running an e-commerce site<br>
I'd look at it in a far different way. Probably involving packet
filters<br>
*and* port redirection from a bastion host, but it's unecessarily<br>
complicated for the network we have here, and the limited services
being<br>
allowed to the net (WWW site only).<br>
</blockquote><br>
Granted for a particular network the less granular, more permissive
filtering setup you describe is probably adequate. What got my attention
was your statement that this is your commonly recommended configuration.
Nevertheless I am not looking for a fist fight after school on the
playground. :-)<br>
<br>
<br>
<div>Fred</div>
<div>Avolio Consulting</div>
<div>16228 Frederick Road, PO Box 609, Lisbon, MD 21765, US</div>
<div>+1 410-309-6910 (voice)<x-tab>&nbsp;</x-tab>+1 410-309-6911
(fax)</div>
<div><a href="http://www.avolio.com/" EUDORA=AUTOURL>http://www.avolio.com/</a></div>
</html>

-
[To unsubscribe, send mail to majordomo@lists.gnac.net with
"unsubscribe firewalls" in the body of the message.]


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic