Tomcat/Apache server configuration in a secure environment

Discussion in 'Java' started by Andrea M. Segovia, Feb 23, 2004.

  1. 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
     
    Andrea M. Segovia, Feb 23, 2004
    #1
    1. Advertising

  2. Andrea M. Segovia

    Sudsy Guest

    Andrea M. Segovia wrote:
    <snip>
    > 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.
     
    Sudsy, Feb 23, 2004
    #2
    1. Advertising

  3. Andrea M. Segovia

    Matt Parker Guest

    Sudsy wrote:

    > Andrea M. Segovia wrote:
    > <snip>
    >> 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.


    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

    --
    Not so interesting...
    http://www.mpcontracting.co.uk
     
    Matt Parker, Feb 23, 2004
    #3
  4. Andrea M. Segovia

    Matt Parker Guest

    Sudsy wrote:

    > Andrea M. Segovia wrote:
    > <snip>
    >> 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.


    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

    --
    Not so interesting...
    http://www.mpcontracting.co.uk
     
    Matt Parker, Feb 23, 2004
    #4
  5. Matt Parker <> wrote in message news:<403a9101$0$17807$>...
    > Sudsy wrote:
    >
    > > Andrea M. Segovia wrote:
    > > <snip>
    > >> 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.

    >
    > 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
     
    Andrea M. Segovia, Feb 26, 2004
    #5
  6. Andrea M. Segovia

    Sudsy Guest

    Andrea M. Segovia wrote:
    <snip>
    > 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:
    <http://www.ipconsulting.net/firewall.asp>

    > 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... ;-)
     
    Sudsy, Feb 26, 2004
    #6
  7. Sudsy <> wrote in message news:<>...
    <portions omitted>

    > 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
     
    Andrea M. Segovia, Mar 1, 2004
    #7
  8. Andrea M. Segovia

    Sudsy Guest

    Andrea M. Segovia wrote:
    <snip>
    > 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.
     
    Sudsy, Mar 1, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christos Gravvanis
    Replies:
    0
    Views:
    2,052
    Christos Gravvanis
    Jul 7, 2004
  2. milesd
    Replies:
    1
    Views:
    3,510
    nuklea
    Dec 16, 2004
  3. sjoshi
    Replies:
    0
    Views:
    6,629
    sjoshi
    Sep 27, 2005
  4. Replies:
    2
    Views:
    1,123
  5. Replies:
    0
    Views:
    328
Loading...

Share This Page