Glad I could assist...
Chao!
"Steve Riley (MCS)" wrote:
> Hey, very excellent write-up. I've been looking for some good reasons to
> argue against the single firewall approach in a project I've been working
> on. Thanks!
>
> ___________________________________________________________
> Steve Riley
> Microsoft Telecommunications Consulting in Denver, Colorado
> e-mail: mailto:[EMAIL PROTECTED]
> call/page: +1 303 521-4129 (cellular)
> SMS: mailto:[EMAIL PROTECTED] (100 characters)
> For MS Internet info see http://www.microsoft.com/isn/
> Applying computer technology is simply finding the right wrench to pound in
> the correct screw.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 3, 2000 4:36 PM
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: Where to place public servers
>
> 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.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
