Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 240
  • Last Modified:

External Web Server accessing an internal File Server

Here's the deal, I am pretty sure this cannot be doen without creating a security breach on my company's Internal Network.

I have a Web Server on site that is setup in our DMZ, in the same firewall that the Web Server is plugged into, my Trust Network is plugged in.  Our file server and my web server are sitting right next to each other in my rack, but the web server does not communicate with the Internal Network (Security Reasons of course).

My question is this, Is there a way to limit the web server's communication with the File Server to request a certain set of PDF files on the Internal Network?

The reason for this is that my company wants a central directory on our file server to house these important documents, but to also be accessible by registered users of our web site.  This way the people that update the PDFs just have to update them in this directory, an I as the Web Developer will not have to manually upload these files every time there is a tiny change.

Please Help!!!

2 Solutions
Try this:
1. Setup a hardened web server on the internal network, with a virtual directory pointing to the file server.
2. Define NAT to the above server, with firewall rules allowing HTTP communications ONLY with your regular web server, preferably in a port other than 80.
3. Define a reverse proxy relationship between the internal server and an external virtual directory.
Such definitions can be easily done either in Apache or Squid, or even MS proxy server.

Another posibilty is using a replication utility to push the files from your file server to your web server. Somethihing like rdist will do if your file server is unix or linux flavoured. There are a few for Windows as well but I think you need to purchase them. Search Google for "file replication utility"

Do not make the mistake to open up your firewall any more than it has to. Argh, I cringe when I read this because ofcourse the business wants everything, but prudence and security deems otherwise.

If you must PULL, do it through an airlock - i.e. Internet connectivity is severed while the external system is pulling from an internal system.

The preferred is a push method from inside to out - and done on a batch basis.

If it is vitally important that 'slight' changes must be made live immediately, then commonly used web-publishing mechanisms must be employed. If it is acceptable that you wait 4,6-12,24 hours between pushes, then employ a batch to do so.

Technically there are many ways to do this, the real question is that of policy; sounds like you, in your position, or those around you, must establish policy, stick to it, and enforce all current and future requests to conform to that.

Totally agree PaulBobby. That's why I suggested the push replication.

I don't think there is a need to wait 6 hours for the update. You could schedule the check every 15 minutes as you don't need to update the whole file structure only the bits that changed if they changed. and if you needed it quicker you can always force the update manually so you only need the one method at all times.
I would do one of two things:
1) Setup an SSL proxy in the web DMZ that is hardened and communicates only via port 443 to the file server on your corporate LAN.  This still stands to be compromised, so;
2) Install an additional interface on your firewall and create a new DMZ and make a policy such that the Internet talks only to the first DMZ, the first DMZ can talk to the second DMZ (where the file server will be moved to) and the second DMZ can communicate openly with your corporate network.  This creates a Defense-in-Depth approach and provides one more choke point which can be monitored.


Gary Freeman

Featured Post

Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now