Re: securing DB access from the DMZ

[Holger Kipp <holger.kipp () alogis com>]

On Wed, Feb 20, 2002 at 01:47:47PM -0800, wasabi_pea () hushmail com wrote:
> The webserver has two network interfaces.  One has a public IP that 
> carries web traffic to and from the Internet.  The other has a private 
> address and carries database requests to and from the core banking 
> database over a single TCP/IP port (as far as I know).  The second 
> NIC plugs into our core switch behind the firewall, to which our 
> database server is also directly connected.  The connection from the 
> webserver to the switch makes me nervous.

That would make me nervous as well. The idea of using two NICs is not
bad, though, as it _can_ improve security.

> The former administrator wasn't concerned with the second NIC, and claimed 
> that it was impossible for traffic to route from one NIC to the other. 

This is correct in theory if ip-forwarding is disabled. As the machine is
a MS-based system I wouldn't trust it as far as I could throw it ;-)
My 2 EUROcent recommendation:

- harden your IIS, maybe even use some FW-Software on the system.
  Switch off all ports/services not needed on the external NIC and
  (of course) the internal NIC.
- put a firewall between internal NIC and your internal core switch
  so you can restrict access from the outside (only permit DB-access)
  and from the inside (for admin-tasks). 
- monitoring blocked packets coming from the internal NIC might help
  detecting an intrusion.
- it might also be a good idea not to allow outgoing connections
  from your IIS (so from the internet one has to open TCP/IP
  connections like https, and the IIS can only answer to such a 
  request, but is not allowed to open further connections on its 
  own - a simple state-based FW can do that)

I'm more comfortable with Unix than Microsoft-Products, especially
if it is about security, so I'd recommend using something like
FreeBSD, running Apache within a Jail-Environment... But if you
follow all security advisories for hardening your IIS this should
also be sufficient.

> I'm not sure I feel comfortable trusting that assumption to protect the 
> database server from intrusion.  However, the former administrator like 
> the solution so much he carried it out on all the servers in the DMZ, 
> so that they could be administered without going into the server room.

As long as your IIS is not hacked (and IP forwarding is disabled),
everything should be just fine. If it is, however, the attacker currently
has not only access to the DB but to the whole internal network, which
is slightly worse.

> I'm considering alternative designs and solutions.  I think I'd like 
> to cut the secondary connection to the switch and bring the database 
> traffic back through the firewall to the inside network. 

imho that doesn't improve security and would only increase complexity
of fw-rules.

> I'm also considering a second firewall to create a more secure zone 
> for the database server and other important assets, like the Human 
> Resources server.  That way I can further secure access to them from 
> both external and internal users.

Suggestion (just to show the idea):

          {Internet}
               |
               |
        [Cisco router]
               |
               |           (A)
        [Cisco PIX 520]---DMZ---[IIS 4 Webserver]
               |           |      (Second NIC)
               |           |           |
               |         [Server 2]    |
               |                |      |
     [Cisco Catalyst 6509]      | (B)  |
               |                |      |
               |                |      |
             (LAN)------------[State-Based FW]---[DB Server]
                                      |   |
                                      |   +------[Server 2]
                                      |  (C)
                                      +----------[Server 3]

Depending on security considerations, one
can use one DMZ per Server instead of
just one DMZ (A). The same applies to the
connections that are needed to access 
internal servers (B) and the backend servers
itselv (C). You need to secure all the
servers, of course. The weakest part in
this case is your IIS 4 Webserver as this
machine needs access to the DB Server, so
if it gets hacked - game over.

Regards,
Holger

-- 
Holger Kipp, Dipl.-Math., Systemadministrator  | alogis AG
Fon: +49 (0)30 / 43 65 8 - 114                 | Berliner Strasse 26
Fax: +49 (0)30 / 43 65 8 - 214                 | D-13507 Berlin Tegel
email: holger.kipp () alogis com                  | http://www.alogis.com
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards