What is best protection for RDBMS backend of web-server in DMZ

What is best protection for RDBMS backend of web-server in DMZ

[Sanjay Arora]

Hi all

What are the issues involved in securing a RDBMS that is serving a web-server in DMZ. RDBMS is postgreSQL, OS is Linux, Webserver is Apache.

Application is CRM, Customer Registration/Editing is the main part that interacts with the web, Rest of the CRM application works in the Green subnet protected by an iptables firewall, specicically IPcop v. 1.3 presently. 

Should I bifurcate the DB and put the registration part in DMZ or should I put a copy of the registration part in DMZ and sync it periodically with the main DB. Or should I keep full DB on the Green Network & create a pinhole to access the RDBMS from the Green subnet, maybe in some kind of ssh tunnel. Any other ideas unknown to me that may be workable?

Can some one point me to resources that discuss these issues. Also, I would like the experienced people to please comment on pros & cons of various methodologies and pointers to security literature/checklists for Web-server/RDBMS security issues, especially on a shoestring budget with netfilter, linux & other open source tools. Please touch on various subjects like monitoring, recovery etc., so as to give me broad idea of scope of my research and pointers to resources.

With best regards and thanks in advance.
Sanjay.

Re: What is best protection for RDBMS backend of web-server in DMZ

[Antony Stone]

On Sunday 22 August 2004 4:43 pm, Sanjay Arora wrote:

> Hi all
>
> What are the issues involved in securing a RDBMS that is serving a
> web-server in DMZ. RDBMS is postgreSQL, OS is Linux, Webserver is Apache.

Your main challenge is to avoid SQL-injection attacks from user-supplied 
input.

This cannot be prevented with firewalls - it requires careful coding and 
validation of input in the scripts which join Apache to PostgreSQL.

I would say that a firewall between the Apache and the PostgreSQL machines, or 
a firewall in front of a combined machine, is essential, and should provide 
HTTP access only, but is actually only a small part of the security solution 
in a case such as this.

> Should I bifurcate the DB and put the registration part in DMZ or should I
> put a copy of the registration part in DMZ and sync it periodically with the
> main DB. Or should I keep full DB on the Green Network & create a pinhole to
> access the RDBMS from the Green subnet, maybe in some kind of ssh tunnel. 

I would put the DB in the DMZ and provide selective access to it from inside + 
outside - that's what a DMZ is for.   Never put a public-access machine on 
the internal network, and don't split an application with some sort of data 
sync going on unless you *really* have to.

Regards,

Antony.

-- 
Some mistakes are too much fun to make only once.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: What is best protection for RDBMS backend of web-server in DMZ

[John A. Sullivan III]

On Sun, 2004-08-22 at 11:43, Sanjay Arora wrote:
> Hi all
> 
> What are the issues involved in securing a RDBMS that is serving a
> web-server in DMZ. RDBMS is postgreSQL, OS is Linux, Webserver is
> Apache.
> 
> Application is CRM, Customer Registration/Editing is the main part
> that interacts with the web, Rest of the CRM application works in the
> Green subnet protected by an iptables firewall, specicically IPcop v.
> 1.3 presently. 
> 
> Should I bifurcate the DB and put the registration part in DMZ or
> should I put a copy of the registration part in DMZ and sync it
> periodically with the main DB. Or should I keep full DB on the Green
> Network & create a pinhole to access the RDBMS from the Green subnet,
> maybe in some kind of ssh tunnel. Any other ideas unknown to me that
> may be workable?
> 
> Can some one point me to resources that discuss these issues. Also, I
> would like the experienced people to please comment on pros & cons of
> various methodologies and pointers to security literature/checklists
> for Web-server/RDBMS security issues, especially on a shoestring
> budget with netfilter, linux & other open source tools. Please touch
> on various subjects like monitoring, recovery etc., so as to give me
> broad idea of scope of my research and pointers to resources.
> 
> With best regards and thanks in advance.
> Sanjay.
I take it from your need to synchronize that the portion of the DB
needed for public access is needed by the rest of the internal
application.  Thus, complete separate is not possible.  If you put the
bifurcated DB on the DMZ, you must allow the DB to penetrate the
firewall to get to the Internal network and if you place the DB on the
internal network, you must provide a firewall hole for the Web front end
to talk to the DB.  I also take it from your point a shoestring budget
that very secure environments such as placing the Web front end, public
DB and internal DB all on separate networks is not an option.

Given that, I would suggest that you place the Web Server in a firewall
protected DMZ which only allows the Internet access needed to run the
web application (obviously admins from the internal network will have
greater access) and place the DB for the web front end on the private
network (preferably in its own firewalled network but that is an extra
expense).

I would not put the public DB in the DMZ despite Antony's usually
outstanding advice to do so.  My thinking is that the DMZ is still
vulnerable and web servers in a DMZ particularly so.  If a user is able
to compromise the web server on the DMZ, they may have free reign on the
DMZ and can get to any service on the DB.  From there, they can do
whatever they want to the DB.  One could argue that if they compromise
the DB on the internal network, that they would likewise have free reign
of the internal network, an even worse scenario, but, one way or the
other, you must expose your internal network - either to the Web server
or the the synchronizing DB.  In other words, if I have the web server
and the public DB in the DMZ, there is a chance a compromised web server
will give full access to the DB and the DB can be used to gain access to
the internal DB.  If I have the web server in the DMZ and the public DB
on the private network, if they crack the web server they do not have
free reign of the public DB but they may still be able to get to the
internal network through the DB.  Either way they may be able to get to
the internal network but the former option seems a little safer. 
Someone please correct me if I am wrong.

There is a very effective poor man's technique you can use to add an
extra layer of protection to the public DB.  Either on the DB server or
on the firewall, alter the TTL to go no further than the DMZ.  This way,
if someone does crack the web front end and uses the web front end to
crack the public DB and tries to dump the public DB data to some
Internet site, the packets will die when they leave the DMZ.  For
example, if the DB is on the internal network and the web server is one
hop away on the DMZ, set the TTL to 2.  It will decrement to 1 on the
DMZ and if it tries to go across the Internet, the ISP's router will get
the packet with a TTL of 1 and discard it as expired.  Of course, this
means that one cannot cruise the Internet from the DB server.  That
might not be a bad problem to have :-)

We like to do this on the firewall in the ISCS project
(http://iscs.sourceforge.net) There, when one configures a server or a
resource on that server, one has the option to set the public TTL.  This
can be seen in the Resources screen shots on the ISCS web site.  One
merely sets the value and ISCS automatically creates the mangle table
rules to change the TTL for any packets headed out over the Internet.

Hope this helps - John  
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com

Re: What is best protection for RDBMS backend of web-server in DMZ

[Sanjay Arora]

On Mon, 2004-08-23 at 08:06, John A. Sullivan III wrote:

> I take it from your need to synchronize that the portion of the DB
> needed for public access is needed by the rest of the internal
> application.  Thus, complete separate is not possible.  If you put the
> bifurcated DB on the DMZ, you must allow the DB to penetrate the
> firewall to get to the Internal network and if you place the DB on the
> internal network, you must provide a firewall hole for the Web front end
> to talk to the DB.

That is correct.

>   I also take it from your point a shoestring budget
> that very secure environments such as placing the Web front end, public
> DB and internal DB all on separate networks is not an option.
No..I meant that I dont have resources to buy expensive closed source
licences. The public portion of the DB is small. Also, is restricted to
new registrations & edits, therefore will not require much resources
unless my site is very successful in what I mean to do. So I can put a
Pentium III type machine, on a separate segment with a cross cable or a
hub and an additional card in web-server maybe or maybe put an
additional machine as firewall between the two.

Tell me, does it make a difference if the DB server & the firewall
protecting it from the DMZ are on the same machine or a different one
with minimalist setup?

> Given that, I would suggest that you place the Web Server in a firewall
> protected DMZ which only allows the Internet access needed to run the
> web application (obviously admins from the internal network will have
> greater access) and place the DB for the web front end on the private
> network (preferably in its own firewalled network but that is an extra
> expense).
No as said above, I can afford to spare a small machine...I like that
;-)

> I would not put the public DB in the DMZ despite Antony's usually
> outstanding advice to do so.  My thinking is that the DMZ is still
> vulnerable and web servers in a DMZ particularly so.  If a user is able
> to compromise the web server on the DMZ, they may have free reign on the
> DMZ and can get to any service on the DB.  From there, they can do
> whatever they want to the DB.  One could argue that if they compromise
> the DB on the internal network, that they would likewise have free reign
> of the internal network, an even worse scenario, but, one way or the
> other, you must expose your internal network - either to the Web server
> or the the synchronizing DB.  In other words, if I have the web server
> and the public DB in the DMZ, there is a chance a compromised web server
> will give full access to the DB and the DB can be used to gain access to
> the internal DB.  If I have the web server in the DMZ and the public DB
> on the private network, if they crack the web server they do not have
> free reign of the public DB but they may still be able to get to the
> internal network through the DB.  Either way they may be able to get to
> the internal network but the former option seems a little safer. 
> Someone please correct me if I am wrong.
Hmmm...that essentially means that I redesign my application (still in
System Analysis stage) not to synchronise the databases using triggers
or something similar initiated by the DMZ and work out a design that
causes the DB to push out updates in xml files, which are then
transferred to the main db in the green network using sftp, scp, ssh or
email whose sessions are initiated by the green network, I should be
fairly secured.

This batch processing approach would also allow me to check the data for
SQL Injection risks, if they do crash the dmz db...maybe there is some
way to check if the dmz db is not crashed by sql injection attacks
before the batch is processed by the green db server. Antony, Thanks for
the tip. But I guess I have to learn a lot about SQL injection before I
do that ;-(

> There is a very effective poor man's technique you can use to add an
> extra layer of protection to the public DB.  Either on the DB server or
> on the firewall, alter the TTL to go no further than the DMZ.  This way,
> if someone does crack the web front end and uses the web front end to
> crack the public DB and tries to dump the public DB data to some
> Internet site, the packets will die when they leave the DMZ.  For
> example, if the DB is on the internal network and the web server is one
> hop away on the DMZ, set the TTL to 2.  It will decrement to 1 on the
> DMZ and if it tries to go across the Internet, the ISP's router will get
> the packet with a TTL of 1 and discard it as expired.  Of course, this
> means that one cannot cruise the Internet from the DB server.  That
> might not be a bad problem to have :-)
> 

Thats a very nice idea. I will definitely do that alongwith putting the
DB server in additional firewall layer.

> We like to do this on the firewall in the ISCS project
> (http://iscs.sourceforge.net) There, when one configures a server or a
> resource on that server, one has the option to set the public TTL.  This
> can be seen in the Resources screen shots on the ISCS web site.  One
> merely sets the value and ISCS automatically creates the mangle table
> rules to change the TTL for any packets headed out over the Internet.
> 

John, I checked out your isca project...seemed a nice effort, but I did not see any download links for alpha/pre-alpha downloads. What stage is it in?

I remember coming across such a software with similar policy oriented, lower layer neutral approach. But I think it was already released...though dont remember the name..Anyone?

Can anyone suggest some tools for managing multi-stage firewalling and snort like sensors for monitoring...something like firewalling each server for services it does not provide and the ip ranges it is supposed to provide it for...and monitoring the whole thing ;-)

I am glad that I use open source...otherwise thinking the cost of licences with such an approach would be bankruptive ;-))

With best regards.
Sanjay.

Re: What is best protection for RDBMS backend of web-server in DMZ

[John A. Sullivan III]

On Mon, 2004-08-23 at 07:46, Sanjay Arora wrote:
> On Mon, 2004-08-23 at 08:06, John A. Sullivan III wrote:
> 
> > <snip>
> 
> >   I also take it from your point a shoestring budget
> > that very secure environments such as placing the Web front end, public
> > DB and internal DB all on separate networks is not an option.
> No..I meant that I dont have resources to buy expensive closed source
> licences. The public portion of the DB is small. Also, is restricted to
> new registrations & edits, therefore will not require much resources
> unless my site is very successful in what I mean to do. So I can put a
> Pentium III type machine, on a separate segment with a cross cable or a
> hub and an additional card in web-server maybe or maybe put an
> additional machine as firewall between the two.
> 
> Tell me, does it make a difference if the DB server & the firewall
> protecting it from the DMZ are on the same machine or a different one
> with minimalist setup?
If I understand your question correctly, it depends on how much you want
to spend on both equipment and administrative overhead.  It is clearly
safer if you have separate security devices so that if one security
gateway is compromised, there are still other, uncompromised devices
protecting the rest of the network.  However, this kind of network
compartmentalization creates a lot of administrative overhead.  Every
time a new network is added (growth, merger, acquisition, re-addressing)
or a new service is added (a new server or a new service on an existing
service), there is a change to the security configuration.  This is a
bear with manually configured, order dependent rules but does create the
kind of multi-layered security security analysts recommend and network
engineers say is too expensive :-)  (and yes, there are other important
components to multi-layered security).

The ideal scenario is that the Internet users hit the Web server on the
protected DMZ, the Web server then sends the traffic through the public
firewall to an internal firewall which separates the internal users from
the internal servers from the private backends to the public servers. 
This way, if someone compromises the public web server and manages to
leap to the public DB, they cannot easily get to the internal network. 
It also means that if someone on the inside has been compromised through
a phishing, spam, trojan, flavor of the day malware, that they intruder
now poised on the inside of the network also does not have free access
to all services on either DB - just the access the end user would have
(bad enough but better than giving them telnet or MSRPC to the database
underlying server).

This is the major impetus behind ISCS.  When we can drive the cost of
managing that change down to a reasonable level, one can become more
creative with internal security.  I'll share our recommendations here as
general advice in case you find it helpful.  The recommendation pertain
to Internet, VPN, leased-line WAN and, in some cases, LAN access.

We discuss five different network security models:

0) Level 0 is zero security.  All users on the internal network are
allowed access to all services on all devices on the WAN - certainly not
what you want but the way most WANs and LANs are built.

1) Separate the WANs and Internet into zones with user authentication
based upon IP address.  The LAN is still unprotected but the WAN has
become compartmentalized with a spoofable and easily circumvented form
of user authentication.

2) Separate the servers from the users with an internal firewall with
user authentication via IP address.  The LAN has now been
compartmentalized so that the servers are protected from unauthorized
service access from both LAN and WAN users but the user authentication
is still weak.

3) Separate the WANs and Internet into zones with some form of extended,
out-of-band user authentication (e.g., www.nufw.org) such as X.509 cert,
SecureID token, AD, e-Directory, LDAP or RADIUS credentials.  If IPSec
is used, we have the added advantage of protecting the traffic in
transmission.  ISCS can support extended user authentication for IPSec
users based upon their X.509 cert DN's.

4) Combine 2 and 3, i.e., isolate the servers into separate server farms
and only allow access to the needed services to users based upon some
form of extended user authentication.

In your case, it may be feasible to place the public DB on its own
network using either model 2 or 4.  I'm not sure how much extra security
you gain in this case by making the user DB communicate with the
internal DB via extended user authentication.  On the other hand, such
user authentication would help protect your DB from internally postured
attacks.
> 
> > Given that, I would suggest that you place the Web Server in a firewall
> > protected DMZ which only allows the Internet access needed to run the
> > web application (obviously admins from the internal network will have
> > greater access) and place the DB for the web front end on the private
> > network (preferably in its own firewalled network but that is an extra
> > expense).
> No as said above, I can afford to spare a small machine...I like that
> ;-)
> 
> <snip>

> > We like to do this on the firewall in the ISCS project
> > (http://iscs.sourceforge.net) There, when one configures a server or a
> > resource on that server, one has the option to set the public TTL.  This
> > can be seen in the Resources screen shots on the ISCS web site.  One
> > merely sets the value and ISCS automatically creates the mangle table
> > rules to change the TTL for any packets headed out over the Internet.
> > 
> 
> John, I checked out your isca project...seemed a nice effort, but I
> did not see any download links for alpha/pre-alpha downloads. What
> stage is it in?
Funny you should ask! There should be a pre-alpha release on the site
tomorrow. We had not planned to make one because, as an Integrated
Secure Communications System, it really doesn't become useful until all
the integrated parts have been completed.  But we have had a lot of
requests to play with what is done and it is at the point it is at least
reasonably functional.
> 
> I remember coming across such a software with similar policy oriented,
> lower layer neutral approach. But I think it was already
> released...though dont remember the name..Anyone?
I'd love to know about it.  We really did not want to launch a new
project but could find nothing in either the proprietary (even among the
six-figure priced products) or open source world that does what ISCS
does.  We would prefer to not reinvent the wheel if something else
exists.
> 
> Can anyone suggest some tools for managing multi-stage firewalling and
> snort like sensors for monitoring...something like firewalling each
> server for services it does not provide and the ip ranges it is
> supposed to provide it for...and monitoring the whole thing ;-)
That's exactly our goal.
> 
> I am glad that I use open source...otherwise thinking the cost of
> licences with such an approach would be bankruptive ;-))
> 
> With best regards.
> Sanjay.
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net