Frederick M Avolio wrote:
>
> 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.
OK, this could be where we have an issue, I was using the term "bastion
host" as a host, present on both internal and external networks
providing services to one, another, or both networks (IE An application
gateway)
By your definition I would term all the machines in my DMZ as bastion
hosts, and I have the firewall too.
> 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).
Agreed, in my mind it is the services more than the base OS that is
vulnerable to attack, and with the definition I have always had of a
bastion host, (IE That it is that it is on both networks), break the
bastion host and you have access to the internal network.
> > 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.
I did say that I use a DMZ, which means that to get into the network
"they" have to go two hops, both of which are made as hard as possible
by having hardened machines in the DMZ and a complete no-go rule from
the DMZ to the internal network.
> > 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...
In the second case every host in *the DMZ* is vulnerable. NOT the
internal network, as is the case in the first case.
> > 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.
The internal network is completely unreachable from the outside.
Words fail - see sketch:
| (Inet)
|
DMZ |
--------[ FIREWALL ]
|
|
| (Internal Network)
This is the design I am talking about.
NOTHING from the internet or the DMZ (Except returns) are allowed into
the internal network.
Only SPECIFIC services to SPECIFIC machines are allowed to the DMZ.
If I am not terribly mistaken this is your design
| (Inet)
|
|
[ PROXY ]
|
|
| (Local Network)
IE All internet available services are arrayed on the one "bastion host"
If it is then if you get access to the "PROXY" you have access to the
internal network.
I also put my eggs in one basket, the firewall, I just don't like
running services on the box attached to the Internet directly.
Here's Why:
Let's look at some scenarios...
Hacker gains access to internet connected machine due to bug in base OS:
(Both): Internal networks are compromised.
Hacker gains access to service provided to internet.
PROXY: Internal network heated bread product of your choice
FIREWALL: (EG) Web server in DMZ gets fried, DNS Server in the DMZ
gets compromised, all of which is logged by the firewall.
I'd like to keep all the script kiddies in the DMZ, thankee muchly, and
if necessary, rebuild the web server (As I said originally.)
> > 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. :-)
The reasoning for the above paragraph is that there data has to pass
from the internet to the internal network...
I think the packet filter has the option of being *more* granular.
You'll also find that the DMZ && Packet filter is a *very* commonly
recommended configuration.
I also am not looking for any form of playground barney *8^>
> 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/
Gav
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
