Let’s start this introduction with an external facing web application. They are normally deployed in so-called DMZ network zones because they cannot reside in the internal network nor in the plain Internet. The same applies also to a WAF or a Web Entry Server as they are normally implemented close to a web application. The following gives some background information in order to understand better the environment context of external facing applications.
The word DMZ is an abbreviation for “demilitarized zone”, which stands for a special area between front lines in a conflict. The term “no-man’s land” is also often used as it describes a deadly no-go area. However, that is only the worst case. In the best case it describes an area with defined rules and procedures how to securely pass across the front lines, just like the NNSC camp near Panmunjom, between the heavily fortified north and south inter-Korean border.
The NNSC camp contains some blue barracks from the UN which harbors a number of permanent Swiss and Swedish residents. They offer their neutral services to both belligerent camps since more than 50 years. These residents maintain strict processes and procedures which are respected by both sides – and which makes this tiny little zone probably the safest part on this highly dangerous border.
In IT a DMZ is a special network zone which is normally placed between other network zones. It can also have a large bandwidth of meanings – just like the previously mentioned analogy to the area between front lines. It is basically purpose, configuration and its use that defines if a DMZ is a dangerous no-go area or a trusted security zone.
Furthermore, there are multiple ways how to look at such DMZ network zones. The usual and obvious way is to look at it from the technical perspective. Naturally, as it is a technical subject belonging to network administration and to some security guys. It is also a subject full of pitfalls as many technical details need to be considered from multiple angles. Tiny details can make a huge difference between security failure and success.
What defines the character of a DMZ?
- Current configuration
- Actual use of it as a matter of fact (i.e. reality, regardless of purpose and configuration)
- Degree of stakeholder expectation match (i.e. or level of illusion)
This can translate directly into business failure or success, therefore, too important a subject to leave it to network administration alone. The business perspective – or better said the enterprise architecture perspective if you are on the IT side – needs to be considered in order to satisfy the expectations of all stakeholders.
Basic Concept of a DMZ
DMZ networks exist because of the need to communicate between networks of different trust levels. No communication needs, no need to have a DMZ.
No connectivity means no risks from connectivity threats (i.e. malware, unauthorized external access, DDoS, data leakage, data destruction, system misuse or sabotage). Other risks still exist of course, like the risks of a shadow IT network put in place unofficially or data on physical media entering or leaving the premises. Putting such risks aside, you are having a very secure environment if there is no communication at all.
Nevertheless, being so secure makes it also very hard to do any business. Opening up the firewall is inevitable and having connectivity inevitably means exposure to external threats. The risk level depends on the level of exposure, attack capabilities of the adversary, and the defense capabilities. And last but not least on the cost-benefit calculation of both sides (yes, the attacker also thinks in cost-benefit calculation terms).
Security depends on the implementation scenario and you even might get burned with correct firewall rules. Connection establishment and data flow are in some cases independent factors, which depends on protocol capabilities and implemented server behavior.
Questions for inbound
Policies to consider
This sounds like some innocent considerations, however, inbound connectivity starts a plethora of additional questions. Can such servers be placed together if they are supposed to be accessed from externally? What about accessing them from internally? How to treat service invocation calls coming from such servers, e.g. from the web application to the service or the DB layer? Where should these secondary servers be placed, anyway? What is the difference between an authenticated user on a customer application and an unauthenticated user on a public web application? What is the correct authentication level anyway? How to authenticate machines and how would that compare? How to implement secure systems administration?
Many additional policy considerations are needed in order to decide on further access to the internal network. Furthermore, additional watchdog services are needed (i.e. authorization, monitoring etc.) on the boundary and within the internal network, where it would matter. And so on.
The same thinking applies for outbound connectivity, although the concern is now far more about data security, especially regarding data leakage.
Questions for outbound
Policies to consider
Accepting connectivity is like opening the Pandora box – however – if ever there was a decision moment it is most probably already gone and part of prehistoric history for most firms and organizations. What matters now is to find the acceptable balance between risk exposure and security investments in order to sleep well at night.
DMZ Security Architecture as security vehicle
Obviously, such servers would be placed in a dedicated network zone, a DMZ. However, a comprehensive IT Security Architecture is recommended in order to deal with these communication risks.
Everything starts with the premise to prevent direct connectivity or communication between internal and external networks by using a DMZ architecture with restricted rules and setup. Ideally, there would be two firewalls as internal and external boundary. The DMZ would harbor the servers which should be accessible from both sides.
Ideally, no connection will be initiated from the DMZ, anyone can access it but only from one direction. Just think of it as a black hole. However, unlike a real black hole, it is also possible to get information out of it. Depending on firewall capabilities and setup connections can be kept open in order to grab desired information, all while respecting the initial policy not to allow services in a DMZ to start connection activities.
Furthermore, these servers also need to be protected. Leaving them alone is no option as anything connected directly to the Internet is highly exposed and at risk. Constant monitoring and also a secure way of server maintenance will be required.
The proxy service in the DMZ makes the difference
Some data still needs to pass through the firewall, depending on scenario. So, we need more control. However, which data packet is okay, which is not? Some application layer knowledge is required in order to be able to inspect the content payload in the data packet.
That is where the purpose of the DMZ becomes important. There is no such thing as all-purpose data inspection service that would be considered as good enough for all scenarios. Next generation firewalls are often sold with the argument that they provide deep packet inspection. A good thing – theoretically. However, it is an easy feature to turn on but a feature hard to maintain over time.
The behavior of such a firewall will be guided by myriads of background rules, maybe updated automatically from the vendor. This makes it error prone and difficult to maintain if the enterprise IT is complex. A serious business cannot leave it to IT hazards if their services must be available. Separation of concerns is a good and manageable alternative to such a chaos.
That is why the deep packet inspection feature is rarely used intensively on next generation firewalls. However, deep packet inspection matters more in dedicated scenarios, which is often implemented with specialized proxy solutions close enough to the application – in terms of IT layer but also in terms of similar IT personnel.
A Web Application Firewall (WAF) is such a dedicated proxy solution for web applications. All incoming web traffic for the application is routed and filtered through this security device. In the best case, the application owner can actively make use of the WAF features and build a rock solid web application.
A DMZ Security Architecture needs to be designed depending on the individual needs of a firm or organization. However, there are typical scenarios which might be used as templates in order to help implementing such a security architecture at the boundary. Read more: Dedicated DMZs – Security Architecture Blueprints.
Technical implementation details
There are many ways how to implement a DMZ. Following details should be considered when building a DMZ:
- Choose between a dual homed or single homed DMZ design
- Design the number of network segments in a DMZ, e.g. external facing network, internal facing network, additional networks for dedicated purpose
- Design how to do systems management of DMZ infrastructure and application servers, e.g. via dedicated management interfaces
- How many switches to use (sharing hardware like switches for external and internal segments is a security risk)
- Decide which DMZ elements to virtualize and what to have physical
- Which network or infrastructure services to implemented separately (reusing internal DNS, AD etc. is a security risk)
- Design policies of how to use the DMZ and clarify ownership responsibilities
- Design change management procedures and oversight responsibilities for the DMZ
Note: This list is not exhausting.
Note: A dual homed DMZ design has 2 firewalls (external and internal, all DMZ pictures here have been created with this scenario in mind). Single homed DMZ designs have only 1 firewall (Quick and cheap approach, higher risk of exposure).
2016/02/05 © ACROSEC Inc.