> Thanks for the great response !
You're welcome...
> 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).
Yuck :-)
> 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)
Uh-huh...
> 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.
No. Please don't. All to many people do this, and all too
many people believe it's ok. It's ugly, scary, and a Bad
Thing (tm). Why bother to build a firewall if you're going
to add a perfectly good back door?
[...]
Because you have control over both of the endpoints, it's
not going to be too much trouble to make the two talk to
each other with real IP addresses.
Mixing RFC1918 addresses with public addresses through
firewalls, etc is only really difficult where you don't
control one of the endpoints...
You mentioned before you were planning to use VPN for other
stuff, and this is a nice place to use it to get around
this particular problem...
As an example, the Axent Raptor firewall offers a function
that they call 'local tunnel'. That particular firewall
passes all traffic through application level proxies, with
the exception of traffic that passes through VPN tunnels.
(For the record, you can force VPN traffic up the stack
through app level proxies too).
They use the 'local tunnel' concept to offer a filtered
route through the firewall for a specific and small number
of machines.
You could work your problem this way: On your firewall,
build a VPN tunnel between your DMZ NIC and your Internal
NIC, set filtering to allow only the two machines to
talk through it, and set routes on the machines to make
sure they know how to find each other.
If you have the ability, filter traffic on IP address and
at MAC layer. The Raptor can do this. I don't know what
options there are in freeware.
Establish a database connection between the two boxen,
and sniff the traffic, then tighten down the filters to
the absolute minimum required to keep the connection going.
Remember that things often use one set of connections to
establish a connection, others for the ongoing communication.
Take care to account for both when designing your filters.
Obviously, this 'VPN' doesn't need any encryption. To
save processor time, you should actively disable encryption
for this 'link'.
This suggestion operates in a setup where the bastion/
firewall host has IP_FORWARDING disabled, and the only
routing that happens between interfaces is via the VPN.
Obviously, if you're using a bastion with forwarding on,
you wouldn't need the VPN software to solve this problem.
That is one way I'd look at solving the problem. There
are others. Some of the brand-name firewalls (Axent, Gauntlet)
have application level proxies that can pass Oracle SQL*Net
connections - maybe a change of database is an option.
I still don't like passing the db connection through the
firewall at all. Databases are sensitive things, and
companies have a habit of storing lots and lots of money
in databases (valuable data). A badly configured db
server is often all to keen to hand over that data to
anyone who asks for it.
A really badly configured db server will happily accept
changes from anyone who offers them.
Mistakes happen. Databases and their servers are large
and complex. Expect errors, and counter them with multiple
levels of security.
My preferred solution would be to have two db servers.
One on your DMZ for real-time access from the web server.
This one should contain the bare minimum amount of data
required to provide the online service.
A second, real database server holding all your private
info sits on the private protected network. Updates
between the two databases (where possible) happen via
a 'disconnected' and not real-time method. Maybe ftp a
set of updates through every hour/day/whatever, or
sneakernet, or something like that.
If you require live updates and/or requests between
(1) the web server and the internal db, or (2) the
internal and external db servers, pay close attention
to rights, limits and security.
Make sure the DMZ box[es] have very limited access
to read and write the internal database. Consider
quarantining writes from the external machines, with
some form of checking before they're absorbed into the
main data.
Pay careful attention to code design in your web
clients too...
One eye-opening attack occured on a database belonging
to an online auction house in Australia recently. An
attacker figured out that, by structuring his URLs
carefully, he was able to help himself to a complete
set of customer details (address, email, name, etc)
from the auction site's database.
An ugly compromise. The firewall behaved perfectly - it
checked the requests at application level, and found them
to be legal HTTP from legal sources (public internet).
The client code and database security was bad. It allowed
export of all the sensitive information.
Don't rely only on your firewall with databases. Think
outside the square.
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.]
