7

I am a software developer with little network security knowledge and almost no knowledge of the current network architecture for the environment I work in. If I had any, I still would not want to divulge any information as such could be a security risk. Currently, company policy prevents any server communication outside of our network. As needs are changing, I am looking for a way to relay to management that a safe, reliable, secure alternative approach exists to allow an external web server to communicate with an internal server and vice versa.

I guess the route of having a company server in the DMZ was to avoid the problems of not having remote access and not being governed by the company network team. The desired approach is to possibly use a third-party service such as through a cloud service and thus gain control over our own deployments.

An alternative approach that was suggested by a peer to having a server in the DMZ was to only permit communication with HTTP protocol, block all ports but 80 (not sure if on server and/or firewall), and only allow GET and POST verbs.

Please enlighten me with the possibilities, concerns, side effects, suggestions, and alternative approaches of achieving the ability to allow an external server to communicate internally and vice versa that do not involve a DMZ. Please do not use a link to a 500 page PDF as your answer unless it is provided as a reference with some good detail.

Thanks in advance!

Improve this question
4
  • 1
    What is the data that is being sent between the internal and external server? Of what value is the data to a potential attacker? What are your needs for confidentiality, integrity, and availability? Are you restricted to specific costs or classes of hardware and software?
    – this.josh
    Jul 12, 2011 at 20:15
  • The data is not sensitive, but that is not to say that we want any of it exposed. The only possible value of interest might be a user name. Availability should be high as the intent of the external web server would be to provide as the intermediary for communication with mobile units. The flow of information mostly should be from the mobile device to external server to internal server. Cost is a huge factor, and the intent would be to try to work within current means, in which, the only addition to the equation would be the new web server.
    – Alban
    Jul 13, 2011 at 16:54
  • This looks tricky. High availability with low cost is difficult. How do you current get data from the mobile devices into your internal server, or is the a new capability?
    – this.josh
    Jul 13, 2011 at 17:35
  • Devices in field will be pushing data to server. The external piece in this equation is to act as an intermediary without directly exposing internal pieces. Definitely don't want the external system to go down, but it would be the pawn. The truth of the matter is, I am looking for a way to get a secure channel between the external server and the internal network. The internal network is what I don't want compromised. How could this be done without a DMZ?
    – Alban
    Jul 13, 2011 at 18:02

3 Answers 3

Reset to default
6

The traditional answer is a three-tier architecture: web, app, and data. Your web layer is isolated out front, and can only talk to the app server with limited methods (e.g., only a small number of RPC-ish calls available). The app server then talks to the data(base) layer, and of course you can do whatever with ACLs or stored procedures to make that more secure. For security purposes, a three-tier architecture is a good solution when done right.

You're peer's suggestion about only allowing port 80 is sort of an assumed minimum. And whitelisting the verbs is fine, but realize that the majority of attacks you'll face operate above that layer and will route quite happily over GET/POST. Which leads into the modern answer: Intrusion Prevention Systems that'll watch all the traffic going by, detect malicious patterns, and act to interdict them.

The traditional answer and the modern answer all lead up to the real answer: you can't set [an external web server] up that's as safe, reliable, and secure as not having one in the first place. Whatever you do will increase your risk by some margin. How you do it will change how big that margin of risk is. Whether you go with a three-tier architecture, IDS/IPS, log monitoring and alerting, etc... You and your management decide how to mitigate the risk, and get it to an acceptable level.

And unfortunately, learning how to safely mitigate the risk means digging through 500 page PDFs to learn the tricks. A hat for a cat, or a cat for a hat, but nothing for nothing.

Improve this answer
5
  • what I meant regarding the 500 page PDF was in lieu of a response like, "here's link, now go read it."
    – Alban
    Jul 12, 2011 at 19:57
  • 1
    According to your response, I am to take it that protocol filtering is not sufficient, and, thus, the need of an IPS. My lack of knowledge is preventing my ability to ask the right questions. Is the DMZ the best and only approach? Can you give me some other terms or topics that could help me in my research?
    – Alban
    Jul 13, 2011 at 17:20
  • 1
    Most of what you say is good, however it also contradicts the IPS requirement - many applicative attacks would take place at a higher level than IPS understands. Unless you can "teach" it your applicative logic, business context, etc...
    – AviD ♦
    Jul 13, 2011 at 18:20
  • Simple protocol filtering is not sufficient. When I say "simple protocol filtering", I mean "we allow HTTP GET and HTTP POST but no other HTTP verbs." The reason that this is insufficient is because clever people have spent years doing things like trying HTTP "GET ../../../../../etc/shadow" and finding out that the web server wasn't smart enough to realize that was breaking the intended rules.
    – gowenfawr
    Jul 13, 2011 at 18:22
  • 1
    (continued) An IDS/IPS improves on simple protocol filtering by looking at data and not just protocol format, and can catch things simple protocol filters miss. However, as @AviD points out, there's always more to worry about. An IDS/IPS lacks the information specific to your application that might help it understand an attack or malicious use; it lacks the signatures to tell what's good and what's bad. Which is why we layer on other measures, such as putting the server in a DMZ and limiting access to/from it, etc. etc. As for terms, you'd want to look for guides on 'hardening' the server.
    – gowenfawr
    Jul 13, 2011 at 19:04
3

Architectures you could use:

  • For data that is not subject to change, you can use a push method putting the content on the website using an authenticated and secure method (vpn, https or ssh/sftp) in a batch mode, overnight or on-demand. e.g. Uploading the updated code to the web-site, uploading the pricing database, uploading the business data to be accessed.
  • For data that can be put in the DMZ you can put all three tiers (Web Server, App Server and DB Server) in the DMZ and leave it there, if you need the data internally you can probably convince them to copy the db internally or reference it from your internal network.
  • For internal data that is needed real-time from your web-site then you can construct a minimal interface that might get past your Security/Network department. Something like a minimal db function that is tightly secured, uses least privilige and monitored possibly using a intermediary bastion database or similar (think oracle databases connected by database links).

Other issues:

  • If the communication is passed over the internet then you should encrypt and authenticate (vpn, https or sftp/ssh).
  • You might want to ask the Security experts how best to integrate internal and external data, if you can't beat em, get them invested in coming up with a solution.
  • Try to determine the concerns your security people have, they are usually valid and I have tried to explain what they might be from my similar experience, but you will need to start thinking about the way they look at the world (a bit of an explore on this security stack exchange site will give you hints).
Improve this answer
1

Asumptions: The interface between your internal network and the external network currently provides the desired level of assurance. The external server is low assurance and may be compromised.

Goals: Maintain the current level of assurance at the connection between the internal and external networks. Add a new interface to the connection without setting up a DMZ.

Unfortunatly the answer depends on your present architecture, but I will try to guess at what you might have. I am assuming that you have a router connected to a single bastion server (combo firewall, IDS, NAT, proxy, etc) and that the other side of the bastion server is your internal network. You want to preserve the existing security of your current setup, so I think modifying the architecture as little as possible is prudent.

Note: this is a rough sketch, you should do thorough analysis and planning before implementing a solution.

Buy a new machine capable of supporting two physically separate ethernet interfaces. What I mean is that if the motherboard has onboard ethernet then you need a PCI or PCI Express ethernet card. If the motherboard has no onboard ethernet then you need two PCI or PCI Express Ethernet cards.

If your bastion host can support a new physically separate Ethernet card, then get a new card for your bastion server.

If you have a new Ethernet card for your bastion server then connect one of the ethernet ports on the new machine to the new card on the bastion server. Otherwise just connect the new machine to any available port on the bastion server.

Pick an internal machine as your internal contact point for the new machine. If possible install new new physically separate ethernet card on the internal contact point. Install VPN software on the new machine and the internal contact point. Configure the bastion server to only accept incoming (do you need outgoing also?) packets of the correct type from the MAC address of the new machine. If the bastion server has a new Ethernet card, configure the bastion server to only accept packets from the new machine on the new physical interface. Configure the firewall on the internal machin to only accept incoming VPN packets from the new machine (if possible, on the new Ethernet interface). Configure the new machine to accept the appropriate packets from the internet. Connect the other physically separate ethernet interface to the router that is connected to the internet. Check the audit logs regularly, keep good backups, etc.

This is not too expensive. One PC (does not have to be server level), three ethernet cards, some cabling, some software, and a lot of configuration. The nice part is that you now have a machine you have physical access to, which is connected to the internet and requires minimal changes to the network architecture to accomidate it. The bad part is this will take a lot of configuration and probably some energetic convincing of the owners of the bastion host and the internal contact machine.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .