Re: newbie: Proxy as Bastion Host?

["Patrick M. Hausen" <hausen () punkt de>]

Hi Andre!

> I have been reading the security advisories of FreeBSD, Linux,  read the
> book "SATAN" from O'Reillly,
>  and browsed through a lot of web-information about Firewall concepts etc.
>
> I did all this because I am in need to present a Firewall concept to our
> managers... *sweat*.
> Now the Question.
> I read that as bastion host is usually used as a proxy, socks,
> auhtentification server that resides before the firewall. The idea behind
> this bastion host is to only allow certain connection types _from_ the
> bastion host to the firewall, and block off all other request of these
> connection types. [right/wrong?]
>
> Now, what I didnt find in the books is a good explanation WHY it would be
> better to have the "proxy" outside as a bastion host, instead of behind the
> firewall. The firewall could basically work as a proxy too...
> Now as I trust the books when they say its better to have proxy be a bastion
> host, I still have to explain the WHY to our managers....
> Can someone explain the Why to me? 

Your basic misunderstandig seems to be the concept that the bastion host
makes one part of an entire firewall system. You can't put your bastion
before or behind your firewall, the bastion _is_ the firewall.

Now for which other components you might need or might not need, depending
on your security requirements ...

The classic setup as in Cheswick&Bellovin "Firewalls and Internet Security",
excellent introductory text BTW, is the "belts and suspenders" configuration
consisting of

        * an external packetfilter
        * a dual homed bastion host
        * an internal packet filter

The concept of the bastion as an application level gateway that doesn't
foward packets but relays desireable protocols at the application level,
possibly with additional authentication and content scanning, should be
obvious.

Now for the packet filters: the external one protects the bastion itself
which is often implemented on top of a general purpose OS like, say,
some brand of Unix ;-), and may be open to attacks that are not easily
addressable at the application layer.
The internal packet filter protects your network _in_case_ the bastion
is compromised. Without it, the hypothetical attacker would have
full access to your internal network with the ability to sniff packets,
to impersonate other hosts by means of DoS attacks against them and
IP changing its own IP address afterwards and so on ...
The internal packet screen makes this a little more difficult.

Cheswick&Bellovin recommend that it _is_ possible to run the external
packet screen on the bastion itself - like a FreeBSD system driving
a PPP line. The strongly recommend against running the internal
packet screen on the bastion. The reason is obvious: if the bastion
is compromised, than an internal screen running on the very same host
is for naught.

Then, there's the somewhat controversal concept of a DMZ. Historically
the DMZ is the network between your bastion and the external packet
screen. You might want to put externally accessable servers like
your corporate's WWW-server there.
Some vendors of commercial firewalls have turned this simple concept into
a special "feature" of their firewall system by naming a third network
connection and the ability to apply certain relaying and traffic filtering
measures to that network a DMZ. Again, depending on your needs, this
might be useful.

You definitely _don't_ want to run your WWW-server in your internal network
and transparently relay TCP connections through your bastion. If the
WWW-server can be compromised, and I bet it can, then your internal
network is open to attack as if the firewall wasn't there.

If you try to design a firewall for your company, be aware, that a
firewall is a _policy_enforcement_system_. You have to have a
written policy first, then design the firewall to match.

And, of course, every system _can_ eventually be broken. You need
to consider the investment/security tradeoff very carefully.
Many of my smaller customers for example are completely satisfied
with a simple packet filtering/proxy system implemented on a single
host. If it's easier to wear a blue collar, look busy, enter the
office to the front door and steal a PC, and if the customer is
a not for profit organization that considers all his work "open"
anyway, a couple of thousand Deutschmarks spent on a big firewall
system is almost useless.
If your management insists on buying an "absolutely secure system",
ask them if every employee has passed a security audit, if their
backup tapes are locked up properly etc.
Of course, e.g. banks already have all these security installations
and you can be pretty sure, tehy have the best firewall systems
available, too - if they have transparent internet access at all.


Hope, this helps,
Patrick