Aza,
I understand your perspective on your public hosts;
Inet-------FW1------Public Servers
\--- Private Servers
However, this has a disadvantage that that only one firewall needs to be
penetrated to enter local network. In addition, there must be an enforcement
point between networks at a different trust level. So this configuration
would put the public Servers and the internal private servers at the same
trust level. If they are really different, then so should be your policy to
protect them.
In addition, Placing a publicly accessible servers on the same trusted domain
firewall is about as sure a way of getting your internal network compromised
as any. By allowing inbound connections to pass through the firewall to
appointed segments, you are opening up your trusted segments to attack as soon
as a vulnerability is discovered in one of the untrusted segment servers.
Granted the other segments are protected by policy, but considering that the
intrusion or vulnerability of the untrusted segment servers has compromised
the firewall, it is just a matter of time before the other segments go as
well.
In fact, vulnerabilities of protected servers can be used against the firewall
itself. Hence, the actual firewall can be compromised. The firewall is then
useless in trying to minimize the scope of the compromise (what firewalls
where designed to do).
Consider:
THE TWO FIREWALL APPROACH
This is the reason that people like the two-firewall approach
Inet-------FW1------Public Servers-----FW2 --- Private Servers
This approach is the concept of security in depth. In real-world firewalls,
walls are measured in minutes of burn through delay. One would then calculate
the time it would take for a fire to burn through to the "apps" room from the
"inet" room as the time of the outer firewall plus the time of the inner
firewall. In the electronic world, things aren't so clear. In particular, if
the two enforcement points are using the same kind of technology and are
configured by the same people, they probably have the same kinds of
vulnerabilities, and so having them in series adds very little to the strength
of the suite.
Hence, the DMZ approach to make sense, the two firewall suites should be using
different technologies, e.g. the outer FW1 is a stateful packet filter from
one vendor, while the inner FW2 is from another vendor. Why? Once one
Firewall has been breached, the second if the same type of firewall, with the
same administrator, with the same policies� follow?
You probably also want to have an IDS setting off an alarm somewhere on that
Citrix net, so that you are made aware that there is traffic between the two
firewalls of a nature that is not permitted, so that you can take appropriate
action before the inner firewall goes down.
Inet -- FW1 -- Public Servers-- FW2 -- Private Servers
|
IDS
Cheers,
Aza Goudriaan wrote:
> In a 'security improvement module' about deploying firewalls
> (http://www.sei.cmu.edu/pub/documents/sims/pdf/sim008.pdf or in HTML:
> http://www.cert.org/security-improvement/modules/m08.html), several
> different architectures for placing a firewall are given. In this document
> they are speaking about a untrustworthy host, which is a host that isn't
> protected by the firewall. Therefore, hosts on the private network (behind
> the firewall) can place only limited trust in it.
> I think that kind of hosts are web servers, mail servers and ftp servers.
>
> The people who have written this document, advise this architecture when
> using a single firewall:
>
> priv. network --- firewall ----- untrustw. host ----- internet
>
> They motivate their choice with the statement that when the untrustw. host
> has been compromised, intruders don't have access to your network. I agree,
> but your public host isn't really secured. In my opinion it is better to
> place the public host behind the firewall and then create rules to access
> that system from internet (static NAT, e.g.), and / or use a reverse proxy.
>
> What is your opinion about it?
>
> TIA.
>
> Kind regards,
> Aza Goudriaan.
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
