Linux – What would a simple DMZ look like for scenario of database server and (web server+middle tier)

dmzfirewalllinux

I have two Linux servers:

  1. The first contains an Oracle 11G database that includes an Oracle HTTP Server
  2. The second contains a Java middle tier plus Apache webserver and Apache Tomcat.

Someone mentioned to me I should consider a DMZ. The goal is to protect the database from external users. However, we can trust internal users. Internal users will still need to access all aspects of the database server.

Could someone help me understand what a simple DMZ (for small business) would look like in this situation? Is it implemented in hardware or software or both?

Not knowing anything about DMZ, I'm trying to understand the things I'd need to instruct my hosting provider to do to implement the DMZ (assuming there's a lot of info needing to decide rather than just telling them: "give me a DMZ"). What would I need to tell them, or what decisions would I need to make before approaching them?

Is there any reason someone may not want or need to implement a DMZ in the scenario above? Or, is it generally accepted to always be a good idea?

Best Answer

The point of a DMZ is to establish a security perimeter through which only known, desired traffic is permitted to flow. This can be done with a hardware firewall device (a Cisco ASA, etc) or with a software firewall (Linux iptables, OpenBSD pfsense, etc). The point is to have a mechanism to arbitrate traffic and make decisions about what flows are appropriate.

Physically, the interconnection of a DMZ to your Internet connection might look something like:

  {  the internet }----[ Firewall Device ]-----{  LAN  }
                                |
                                |
                             { DMZ }

Typically one physical network interface card on the firewall device is dedicated to connection to each of these segments (Internet, DMZ, and LAN). It can be done with VLANs to use fewer physical NICs but then you're starting to mix differing security concerns within the same physical medium (and that's generally to be avoided unless you're gaining some specific advantage by doing that).

Assuming that the users of the application would access the Apache webserver on TCP port 80 of the "second server" (which I'm going to call the "web server") to use the application I would see the web server computer sitting in a DMZ segment with access controlled by the firewall device creating the DMZ to:

  • Allow requests from arbitrary source IPs and ports on the Internet to the web server (TCP port 80)
  • Allow requests from arbitrary TCP ports on the web server to the Oracle database server on the Oracle TNS port (typically TCP port 1521)
  • Allow requests from arbitrary source IPs and ports on the LAN to the SSH port on the web server (for administration)

(Assuming you're using a stateful firewall device to arbitrate access to the DMZ you wouldn't specifically need to create rules for responses to the requests above.)

This is a very simplistic view, but it communicates the idea. You'll probably want the let the web server make DNS requests and you may want to allow it to access an HTTP or HTTPS server from which to download OS updates. I'd strongly recommend against allowing the web server arbitrary outbound access to the Internet (because many exploits rely on the computer being exploited being able to download a "second stage" payload). If you don't need anyone on the Internet to administer the web server don't allow inbound SSH from the Internet. (If you do need to administer it from off-site better to connect to a VPN in the LAN segment and access the web server from the LAN.)