[mdlug] File transfer problem

[Michael ORourke]

>  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).

Well...  I would like to trust the machines (and users) in our intranet and 
for the most part I do.

> * 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.

Correct.  No outside connections allowed.

> * 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.

Correct.  User accounts are "jailed" to a single directory.

> 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.

The biggest risk I see in having direct FTP access to the web repository, 
from our intranet, is that a disgruntled employee or compromised system 
could cause a lot of damage very easily.

There were several discussions last Friday at the office about which 
approach to take.  Our final decision was that it would be easier to give 
the content management team direct FTP access to the web repository (like 
they had before).  Personally, I was leaning towards the more conservative 
approach (not giving direct FTP access).  But who knows, we may revisit this 
again in the near future.  Anyways, thanks for your reply.   -Mike

>
> Apologies for not answering the question you asked, but I hope this helps.
>
> --
>   Mark Montague
>   mark at catseye.org
>


--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.872 / Virus Database: 271.1.1/3363 - Release Date: 01/06/11 
02:34:00