Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our company currently has a customer facing cluster for our signups and customer account management which have direct access to the live database (one master plus several read only slaves).

We have had some discussions recently about improving the security of this setup (beyond existing firewalls). The idea (coming from management) is that the production servers should not have direct access read or write to the database but that instead something should run from either the database server or some other internal server that connects out to the production servers and requests information from some temporary queue existing there.

So

Currently:

Application writes new signups into db Application reads data about customers from db

(App -> DB)

Proposed:

Application writes new signups into temporary local cache (could be filesystem, temp db, memcached, etc) Cron/daemon from internal network connects OUT to application server and fetches queued db requests Cron/daemon writes new data into db or reads old data from db as requested

Cron/daemon pushes back result to application server

(App <- Daemon -> DB)

As a developer (not a sysadmin), this seems ludicrous to me but I readily admit to not being a security expert. As an alternative, I've proposed that if we can't have direct DB access, then we could have an intermediary layer that accepts structured requests and generates DB queries and returns the data. This would look something more like

(App -> Proxy -> DB)

Management's response is that this is suboptimal (but it is still at least open to debate).

I assume this type of argument has played out lots of times in lots of places but I haven't seen anything that specifically addresses the pros or cons of their proposed architecture. Is the proposed backwards proxy approach really that much more secure that its worth the time to build it? If not, what would use to back up your argument if you were asked to implement such an architecture.

share|improve this question

What specific vulnerability are they looking to mitigate? Seems like a lot of extra overhead and complexity (which inevitably leads to problems of one kind or another).

If the App servers still have access to the database servers, through a proxy or other intermediary, a rooted app server could still craft a request that hoses the DB. I just don't see any particular added security in the proposal; perhaps I'm missing something.

Security isn't some nebulous or fungible "thing" that you can add through obscurity or complexity. Security is specific measure(s) taken to mitigate specific threat(s).

share|improve this answer
    
I wasn't given any specific threats, just the 'ideal' that external servers could never push requests/data to internal servers. Instead, the internal servers would have to pull information. The reason: "because its more secure". – Rob Van Dam Nov 6 '10 at 2:18
    
@Rob, "just because" is the reason your mom gives when you're 5 years old. Unless they've got specifics, I'm still completely against adding unnecessary complexity. – Chris S Nov 6 '10 at 17:44
    
"What specific vulnerability are they looking to mitigate?" Isn't it obvious? A database provides a Turing-complete language and a wide array of complicated functionality. By creating a structured message queue which creates only prepared statements from a known set of used templates, they ensure that someone who's cracked the webserver can't run arbitrary queries or try buffer overruns or what-have-you against the database; only those specific commands which are whitelisted can be run. It's to decrease the attack surface. – Parthian Shot Apr 6 at 18:25
    
Similarly, the daemon's outgoing connection is made so that the daemon doesn't need to accept incoming connections and, as a result, is somewhat protected against resource exhaustion attacks like SYN floods, or attacks based on compromise of the webserver's private key (so long as the attacker isn't on the daemon host's LAN). More to the point, whatever protocol you develop for the requests and responses will need to operate over an encrypted, authenticated tunnel. You could find a TLS-wrapper library, or you could use an SSH tunnel. – Parthian Shot Apr 6 at 18:34
    
If you tunnel from the webserver to the daemon server, it's harder (not impossible, just marginally harder) to get things right because, fundamentally, SSH is for the client to run commands on the server. But you don't want the client to be able to do that. So if you do the reverse- bind a SOCKs proxy to a UNIX domain socket (with appropriate SELinux policy and file permissions / ACLs) on the webserver, you can rest slightly easier knowing that all SSH is doing is providing an encrypted tunnel between a UNIX socket on the daemon, and a UNIX socket on the webserver. – Parthian Shot Apr 6 at 18:39

Production servers shouldn't be External. Typical model is a three zone model, External, DMZ (De-Militarized Zone), and Internal. External should never be able to access Internal. However, the Productions servers should be in the DMZ. DMZ servers should have limited access into the Internal network. Access from the DMZ should be an a least privilege basis.

For this type of application, I would provide access to services on the internal network which do the necessary actions. These should be a limited set of actions which can update one client's data at a time.

Generic access from the DMZ risks your data if someone cracks the a production web server.

share|improve this answer
    
I believe this is (close to?) the model I was suggesting. So customers access the external servers which send requests thru the DMZ to anything internal, correct? As opposed to something on the DMZ that pulls requests from external, performs them and pushes back answers? – Rob Van Dam Nov 6 '10 at 2:52
    
Yes, if the external servers are off your network, then the DMZ services can be provided by a reverse proxy sever ensuring the appropriate requests are being sent by the appropriate servers. If the servers are on your network, they should be in the DMZ. DMZ servers should be able to accept requests rather than pulling them. See en.wikipedia.org/wiki/DMZ_(computing) for more details. – BillThor Nov 7 '10 at 4:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.