2

I've got the following situation: A web server located in a DMZ receives file uploads from web browsers. The uploaded files are stored on the web server's file system. In the next step, these files must be forwarded to another server (let's call this the internal server) in the internal network. For the last step, the internal server needs a traditional file access. I would like to discuss some solutions:

  1. Web Server accesses a shared file system on the internal network Pros: Simple, files are stored and accessed from both machines with SMB/CIFS Cons: Pretty dangerous to allow a SMB/CIFS access (I remember all the bad Windows bugs in the past) in the internal network.

  2. Install some kind of a custom service on the internal server, web server get's a client to send the data. Could be FTP or some custom implementation. Cons: The installed service may not be safer than the shared folder.

  3. Shared folder in the DMZ, only accessible from the internal server. Pros: from 1. Cons: ?

Do you see points I forgot or another completely different solution?

Note: A "control channel" from the web server to the internal server exists, thus, the web server can send a "load new data from this directory" command to the internal server.

Thanks.

  • One thing worth considering is that traffic from the web could be very dangerous. I would highly suggest at the very least virus scanning the incoming files from the web browsers. I would also recommend only allowing the relevant file types (for example, executables are extremely dangerous and should be blocked unless they are absolutely necessary). – Jonathan Nov 4 '14 at 14:16
2

You should give consideration to converting the document from its native format. Convert JPG to PNG, say, and Word to PDF. It's a catch-all attempt to try and remove any document-specific malware. The advantage is that it might protect against unknown and future threats. The disadvantage is that it might mess with formatting or lose content. The level of effort you go to here is determined by the risks.

Advancing the idea, you could keep a native copy around so that in the case of it being damaged in the conversion process, you can recover the original, and make the risk-based decision to use that. For the truly paranoid, encrypt the native file with the public key of a key pair, where the private key is only available on a specific hardened standalone non-persistent machine. Use that machine alone for viewing the native documents.

Still more: the document conversion process needs to be on a "trusted" machine. Ideally don't do it on the Internet-facing web server, nor on the internal server; so it should be done in the DMZ.

Your data should be pulled from the Internet into the DMZ by the DMZ, and then pulled from the DMZ into the internal network, by the internal network. It's just a good principle, and otherwise might require more firewall rules than you otherwise need.

I'd look at rsync-over-ssh as a battle-tested one-way sync method with mutual authentication. Run it regularly, and you don't have to worry about signalling the DMZ to come and collect files (might not be enough if you must process these files quickly, though)

Of course, this may well be too much effort to manage your risk.

  • Thanks for your detailed answer. You mentioned some interesting ideas (pubkey encryption of the source files may be useful for us), however, document conversion isn't usable for us since we're working mainly with a proprietary file format and there is no conversion tool for that. Most important for me was what you mentioned about the firewall architecture. Thanks. – Peter Clause Nov 10 '14 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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