Anthony Lucia
asked on
Tunneling in DMZ or begind firewall
Is there a good reason to provide tunneling within the DMZ vs. begind the firewall.
In one scenario, you would wrap and unwrap packets within the DMZ (probably from a proxy), and in another scenario you would do it at the application level behind the firewall
Which would be more secure?
njd
In one scenario, you would wrap and unwrap packets within the DMZ (probably from a proxy), and in another scenario you would do it at the application level behind the firewall
Which would be more secure?
njd
It brings back to principle of detecting at the earliest for any malicious content in the traffic. I was thinking of probably 3 main use case
Case 1 - If we are talking about traditional FW, IP and Port are at most what they can check based on rule so tunneling of the content will make no differences. The traffic such as SSL will pass in and even bypass the IPS or web appl FW unless termination or interception is configured. We should at best do it earliest as another layer before reaching the server end.
Case 2 - If we are talking about NG FW or UTM, content inspection is one area they can inspect further including at application level. Tunneling such as VPN and SSL in common should be terminated or intercepted at this end to inspect before granting the traffic inwards further.
Case 3 - If tunneling is allowed through till the server, it leaves with HIPS in the server to (hopefully) detect the threats incoming, if any. This should be the last line of defence assuming the threat is real, and I do not advocate always relying on that defence and layering is better deterrence scheme instead. Having said that, there is still possibility that (1) and (2) can be somehow bypass/evaded, but we leave it to circumstances such as patch/signature delays, insider, misconfiguration and zero day threats instead of intended tunneling.
Note that the above is assuming inbound traffic we should not ignore outbound too, esp if there is reverse tunneling type or reverse shell type (where the connection is initiated from internal to make it legit and pass the ruleset). Inspection should likewise cater for that. Key is that for all tunneling if there are anomalous tunnel protocol establishment attempts, it should sound the alert aloud (and secure by default, deny that)
Case 1 - If we are talking about traditional FW, IP and Port are at most what they can check based on rule so tunneling of the content will make no differences. The traffic such as SSL will pass in and even bypass the IPS or web appl FW unless termination or interception is configured. We should at best do it earliest as another layer before reaching the server end.
Case 2 - If we are talking about NG FW or UTM, content inspection is one area they can inspect further including at application level. Tunneling such as VPN and SSL in common should be terminated or intercepted at this end to inspect before granting the traffic inwards further.
Case 3 - If tunneling is allowed through till the server, it leaves with HIPS in the server to (hopefully) detect the threats incoming, if any. This should be the last line of defence assuming the threat is real, and I do not advocate always relying on that defence and layering is better deterrence scheme instead. Having said that, there is still possibility that (1) and (2) can be somehow bypass/evaded, but we leave it to circumstances such as patch/signature delays, insider, misconfiguration and zero day threats instead of intended tunneling.
Note that the above is assuming inbound traffic we should not ignore outbound too, esp if there is reverse tunneling type or reverse shell type (where the connection is initiated from internal to make it legit and pass the ruleset). Inspection should likewise cater for that. Key is that for all tunneling if there are anomalous tunnel protocol establishment attempts, it should sound the alert aloud (and secure by default, deny that)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
While it's implied in your question, tunnelling does not necessarily mean you're encrypting. Tunnelling on it's own may simply be used as a means to carry one protocol across another.
GRE (Generic Router Encapsulation) tunnelling is a good example of this, it doesn't encrypt the original payload, it simply wraps it up so you can get it from A to B without the path between needing to know about the thing you're attempting to transmit.
A number of technologies are available to both encapsulate and encrypt data in transport. A couple of popular examples include:
There are, of course, many other protocols which can be used to tunnel (both with and without encryption). Suitability depends on your goals and the reason for your question in the first place.
Chris