[mdlug] File transfer problem

[Mark Montague]

  On January 6, 2011 21:40 , "Michael ORourke" <mrorourke at earthlink.net> 
wrote:
> I have a web repository that is in a DMZ which serves out content via NFS to
> Apache web servers.  This server has no direct access outside the DMZ from
> our Intranet.  We need to be able to provide the web content team access to
> the web repository to upload files.  In our old environment, they could FTP
> directly to the web repository from our Intranet.  However, in the new
> environment, things are more locked down.

Why not allow the web content team to FTP files to the web repository in 
the DMZ?  If you allowed this, what would be the security risk?  Or to 
put it another way -- what threat is being protected against that 
justifies making the web content team's job harder, bringing another box 
into the mix (a box on your management network that is accessible from 
the intranet and which can access the web repository server in the DMZ), 
and setting up a lot of glue with ftp/cron/rsync/scp and shell scripting?

My assumptions:

* You trust the machines on your intranet (e.g., you believe they are 
not compromised and would not attack your web repository server).

* The FTP daemon on the web repository in the DMZ is only reachable from 
machines on your intranet.  Specifically, it is not reachable from the 
Internet.  This can be accomplished via firewall rules and/or 
configuring the FTP daemon itself.

* The FTP daemon on the web repository in the DMZ is configured to only 
allow the web content team to modify files in the appropriate web 
document root or other location; it is configured to deny both read and 
write access to any other areas of the web repository filesystems.


My justification:  The purpose of a DMZ is generally to house services 
that are exposed to the hostile Internet.  By separating these servers 
from your intranet, you are able to protect your intranet by making the 
intranet inaccessible from the Internet.  Also, if an attacker manages 
to compromise a machine in the DMZ, they have gained access to -- at 
most -- only a limited set of externally-facing services and have not 
gained any access to more sensitive resources on the intranet.  Thus, 
there is no harm in giving machines on the intranet access to services 
running on machines in the DMZ (however, the converse is not true: 
machines in the DMZ should have no access under any circumstances to 
machines on your intranet).


So setting up FTP on the web repository server in the DMZ to accept 
connections from (and only from) your intranet should not decrease 
security.  And it will save time and money, allow the web content team 
to continue working as they have been without loss in productivity (due 
to not having direct access and/or delays in publishing web content) and 
without needing to be re-trained, result in a simpler web publishing 
workflow, and result in fewer service dependencies.  If you present it 
in this way to your network security staff and/or management, hopefully 
they will go for it.


Apologies for not answering the question you asked, but I hope this helps.

--
   Mark Montague
   mark at catseye.org