Hi Geoff,
Thanks for the great response !
I have one big problem to handle however, our Web servers (MS IIS) in the
DMZ segment will need to access internal application and database servers
(MS SQL server).
The tricky bit here is that they won't work through a masqueraded
connection, so they both have to be on the same network. (DCOM embeds ip
information in the packet itself, so header translation will not work)
My thought was to turn off ip forwarding on the web server and put in a
second NIC that would appear on the private network.
Obviously this will cause a problem if the web servers are compromised, as I
need these servers to talk to application servers using DCOM and also to SQL
Server. I can tighten the traffic to only use the DCOM and SQL Server ports
which is fine. That way there is no IP address translation involved.
The other idea that was pointed out to me was to use a reverse proxy outside
the internal network, that then referred requests to machines on the
internal network. This way there is only the reverse proxy accessable to
the world. Would this be a safer option to get around the IP Masquerading
between web server and back end ?
Cheers,
Greg.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Breach, Geoff
Sent: Wednesday, 10 November 1999 21:28
To: Firewalls (E-mail)
Subject: RE: Three NIC Firewall
> What disadvantage do I have by using one machine with 3
> NIC's. One to DMZ (Web servers, External Email Servers),
> one to Router to internet, and the last masquerading my
> internal network.
Not much disadvantage to my mind. I quite like the 3-NIC
solution. It gives you the ability to 'physically' separate
each of the three significant networks (the trusted, the
semi trusted, and the untrusted) from each other, and make
communications from any one to any other one pass through
the firewall. Therefore you get control over any network
talking to the other. This is a Good Thing (tm) IMHO.
If external email and/or web servers on the DMZ are
compromised, the Bad Guy (tm) still has to make her
way back through your firewall to get to your private
LAN.
The web/mail servers on the DMZ are protected from
compromise by both The Bad Guys on the net, and the
Ubiquitous Disgruntled Employee.
The net is protected from your Ubiquitous Disgruntled
Employee (and your "Wouldn't it be great to mass-market
to our mailing list with email SPAM" Marketing Department
(don't laugh, I had one of those once - right pissed they
were when I deleted all their SPAM too!).
Your LAN is protected from the 'net.
You get 'complete' control over every inter-network bit
of traffic that flies past.
It's a win/win/win design really.
The performance argument might pop up, but (1) in your
case, you're talking of ~100 nodes behind the firewall,
and (2) most performance arguments can be rendered
insignificant with cash (!).
> My other thought was to have this configuration (without the
> masqeuraded NIC) , and have another tightly configured
> machine on the internal network do the masquerading.
Naaah, I don't like that so much. Public numbers on
private networks make me jumpy. It's against the RFC
(RFC1597, RFC1918, et-al), and, well, it just makes me
jumpy security-wise.
Let your firewall box do your NAT/masquerading - it's
not going to be too busy with the load you're throwing
at it...
> The number of users on the LAN is low (~100), and I am also
> looking at a VPN to another office.
Potential performance hit here. VPN = number crunching =
processor time. Make careful decisions about how big/fast
a processor and RAM you throw at the problem, but still,
it's nothing particularly complex.
> I cannot justify any of the 'production firewalls' that are
> often discussed on this list, and will build my own.
Real men (and women) build their own firewalls! Good on yer
mate! (I'm Australian, ok!)
At risk of launching another religous war, take a good look
at OpenBSD (and maybe FreeBSD) if you're going to make a
home brew firewall. They both (but particularly OpenBSD) have
good reputations in the security business.
HTH,
Geoff
--
CREDIT | FIRST Geoff Breach, [EMAIL PROTECTED], +61293944040
SUISSE | BOSTON Global Network Services - Asia Pacific Engineering
Opinions expressed herein are mine, not my employer's
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. CREDIT SUISSE GROUP, CREDIT SUISSE FIRST BOSTON, and each of
their subsidiaries each reserve the right to monitor all e-mail
communications through its networks. Any views expressed in this message
are those of the individual sender, except where the message states
otherwise and the sender is authorised to state them to be the views of any
such entity.
-
[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.]
