Tomcat/Apache server configuration in a secure environment

[Andrea M. Segovia]

Hello,

I am looking at the security aspects of a web-based application using
Apache, Tomcat to an Oracle backend.

The current architecture has the Apache and Tomcat server integrated
on one physical server. My instinct (as someone with a sys admin/net
admin background) is to separate Apache and Tomcat server functions on
different servers and place a firewall or filtering router in between,
as the Tomcat server is the one that will have access to the Oracle
databases, and is therefore more valuable.

Is this approach recommended? What additional problems does it present
to the application developers and server administrators?

What is the standard application architecture for these types of
Internet applications?

I have been unable to find much information on overall web-based
application architectures that include discussions of how to design
(before the fact) or fit (after the fact) these applications for/to
existing security architectures from either the programming or
security point of view....any pointer to resources discussing
"integration" issues for web-based systems as a whole would also be
appreciated....

Andrea

 

[Sudsy]

Andrea M. Segovia wrote:

The current architecture has the Apache and Tomcat server integrated
on one physical server. My instinct (as someone with a sys admin/net
admin background) is to separate Apache and Tomcat server functions on
different servers and place a firewall or filtering router in between,
as the Tomcat server is the one that will have access to the Oracle
databases, and is therefore more valuable.

If the Oracle server is already separate from the Apache/Tomcat
server then you don't gain much by splitting Apache and Tomcat.
You'll typically run the webserver in the DMZ and limit access
to the database server via the firewall between the DMZ and the
internal network. This is fairly standard stuff. Sorry that I
don't have links to sites with the pretty graphics which show
this conventional architecture although I'm sure that they're
out there.

 

[Matt Parker]

Andrea M. Segovia wrote:


If the Oracle server is already separate from the Apache/Tomcat
server then you don't gain much by splitting Apache and Tomcat.
You'll typically run the webserver in the DMZ and limit access
to the database server via the firewall between the DMZ and the
internal network. This is fairly standard stuff. Sorry that I
don't have links to sites with the pretty graphics which show
this conventional architecture although I'm sure that they're
out there.

I agree with you in many ways, but I have encountered paranoid sysadmins who
don't like Tomcat and Apache on the same machine - often to do with
performance, not just security. Given that, if the OP *really* wants to do
it that way, they should look at the mod_jk module for Apache...

Matt

 

[Matt Parker]

Andrea M. Segovia wrote:


If the Oracle server is already separate from the Apache/Tomcat
server then you don't gain much by splitting Apache and Tomcat.
You'll typically run the webserver in the DMZ and limit access
to the database server via the firewall between the DMZ and the
internal network. This is fairly standard stuff. Sorry that I
don't have links to sites with the pretty graphics which show
this conventional architecture although I'm sure that they're
out there.

I agree with you in many ways, but I have encountered paranoid sysadmins who
don't like Tomcat and Apache on the same machine - often to do with
performance, not just security. Given that, if the OP really wants to do
it that way, they should look at the mod_jk module for Apache...

Matt

 

[Andrea M. Segovia]

I agree with you in many ways, but I have encountered paranoid sysadmins who
don't like Tomcat and Apache on the same machine - often to do with
performance, not just security. Given that, if the OP really wants to do
it that way, they should look at the mod_jk module for Apache...

Matt

I'll try not to be too paranoid

So the most common architecture for this type of application to have
Apache/Tomcat on one server in the DMZ and then link to the back-end
database (Oracle in this case) in the internal network.

The network security group is loathe to allow connections initiated
from the DMZ to the internal network - but are willing to allow
connections from the internal network to the DMZ. Can this be
accomodated? Should it?

What is the accepted way of connecting the Apache/Tomcat server to an
internal database in a secure environment? What measures can be taken
by the application developers to ensure security? What measures can be
taken by the network admins?
What about the system admins/DBAs of the Apache/Tomcat server and the
internal database server?

Thanks for the responses so far....I am hoping to stimulate discussion
on this topic as I would like to hear different approaches and
opinions on this topic.

Andrea

 

[Sudsy]

Andrea M. Segovia wrote:

I'll try not to be too paranoid

So the most common architecture for this type of application to have
Apache/Tomcat on one server in the DMZ and then link to the back-end
database (Oracle in this case) in the internal network.
Correct.

The network security group is loathe to allow connections initiated
from the DMZ to the internal network - but are willing to allow
connections from the internal network to the DMZ. Can this be
accomodated? Should it?

What kind of architecture are they envisioning? Something which
connects to your server in the DMZ and then relays requests, like
a proxy? That's way out there...

What is the accepted way of connecting the Apache/Tomcat server to an
internal database in a secure environment? What measures can be taken
by the application developers to ensure security? What measures can be
taken by the network admins?

A common configuration uses either 10.x.x.x or 192.168.x.x for the IP
addresses in the DMZ along with some form of NAT. The router connecting
to the Internet will not permit traffic to flow from 'net to DMZ if it
has a source address in the range of the DMZ. The router from the DMZ
to the internal network will ONLY permit source addresses in the range
of the DMZ.
The idea is that "external" addresses cannot directly access the
"internal" network. It's difficult to explain without benefit of
diagrams and usenet is text-only. I recommend that you visit the
Cisco site (www.cisco.com) and a Yahoo! search using the keywords
"+dmz +firewall +nat +diagram" turned up (among others) the
following:

What about the system admins/DBAs of the Apache/Tomcat server and the
internal database server?

The firewall between the DMZ and the 'net is typically configured
to deny access to everything EXCEPT certain services. You might
open port 80 (HTTP) and 53 (DNS) but any attempt to access the
administration interfaces (from the outside) will fail. You can
readily configure the internal firewall to permit more liberal
access to services in the DMZ.
IOW, when designed and implemented properly, your sysadmins should
not be able to find an access vector from the "outside".

Thanks for the responses so far....I am hoping to stimulate discussion
on this topic as I would like to hear different approaches and
opinions on this topic.

I don't know if you'll find many different approaches as the one
I've mentioned is standard. And it works, which is perhaps why
it's the norm... ;-)

 

[Andrea M. Segovia]

A common configuration uses either 10.x.x.x or 192.168.x.x for the IP
addresses in the DMZ along with some form of NAT. The router connecting
to the Internet will not permit traffic to flow from 'net to DMZ if it
has a source address in the range of the DMZ. The router from the DMZ
to the internal network will ONLY permit source addresses in the range
of the DMZ.
The idea is that "external" addresses cannot directly access the
"internal" network. It's difficult to explain without benefit of
diagrams and usenet is text-only. I recommend that you visit the
Cisco site (www.cisco.com) and a Yahoo! search using the keywords
"+dmz +firewall +nat +diagram" turned up (among others) the
following:
<http://www.ipconsulting.net/firewall.asp>

The firewall between the DMZ and the 'net is typically configured
to deny access to everything EXCEPT certain services. You might
open port 80 (HTTP) and 53 (DNS) but any attempt to access the
administration interfaces (from the outside) will fail. You can
readily configure the internal firewall to permit more liberal
access to services in the DMZ.
IOW, when designed and implemented properly, your sysadmins should
not be able to find an access vector from the "outside".

Thanks for the detailed answer. How does the NAT provide additional
protection than just configuring the DMZ-to-internal router interface
to deny connections from any IP address other than valid ones in the
DMZ (ie. if you were not using the 10.x.x.x or 192.168.x.x private
addresses)? Does using NAT mainly prevent IP address spoofing or does
it have other functions?

I am also concerned that this method may not prevent someone from
breaking into the web server (Apache/Tomcat) and using it to skip to
the internal database server. Is this a valid concern in the
Apache/Tomcat environment? What measures can be used to prevent or
mitigate this risk?

I am playing devil's advocate here....I need to be able to argue that
access from the DMZ to the internal network is necessary but can also
be safe.

Regards,
Andrea

 

[Sudsy]

Andrea M. Segovia wrote:

Thanks for the detailed answer. How does the NAT provide additional
protection than just configuring the DMZ-to-internal router interface
to deny connections from any IP address other than valid ones in the
DMZ (ie. if you were not using the 10.x.x.x or 192.168.x.x private
addresses)? Does using NAT mainly prevent IP address spoofing or does
it have other functions?

Your external IP address has to be valid. The servers in the DMZ are
using the reserved range. You use NAT to map one to the other. If you
receive a request on your external IP, port 80, you can use NAT to
map it to 192.168.0.5:8080, for example. If you receive an SMTP request
(port 25) then you could map it to 192.168.0.2:25. The idea is that the
external clients have no knowledge of your internal network architecture.

I am also concerned that this method may not prevent someone from
breaking into the web server (Apache/Tomcat) and using it to skip to
the internal database server. Is this a valid concern in the
Apache/Tomcat environment? What measures can be used to prevent or
mitigate this risk?

You only map the services you want. Drop telnet, ftp, ssh, etc. on the
floor. If you're using ipchains or iptables (Linux) for your firewall/
router then check this out:
<http://www.fwbuilder.org>
Unless someone uses a buffer overrun hack on one of the ports you open
up then you're not giving access to "the usual suspects". Hence you
make it far more difficult to breach security on the DMZ servers.

I am playing devil's advocate here....I need to be able to argue that
access from the DMZ to the internal network is necessary but can also
be safe.

Fair enough. Sit down with the concerned parties and a white board and
demonstrate how this typical configuration works. See if they can come
up with any attack vectors. They won't succeed and everyone will walk
away satisfied.
Or pay me to fly out and make a presentation... ;-)

In any case, this is completely off-topic for this ng. Contact me
off-list if you have further questions/concerns.