news / tech talk

Most businesses that host their own servers operate their networks with a Demilitarized Zone (DMZ) located at the perimeter of their network. The DMZ usually operates on a separate firewall interface as a semi-trusted area for systems that interface with the outside world. Why do such zones exist and what kinds of systems or data should be in them? It seems common practice to have a firewall and DMZ on your network but many people, even IT professionals, do not really understand their purpose beyond a vague idea of semi-security. It is important to clearly understand the purpose of a DMZ in order to maintain real security.

Most firewalls are network-level security devices, usually an appliance or an appliance in combination with network equipment. They are intended to provide a granular means of access control at a key point in a business network. A DMZ is an area of your network that is separated from your internal network and the Internet but also connected to both. A DMZ is intended to host systems that must be accessible to the Internet but in different ways than your internal network. The degree of availability to the Internet at the network level is controlled by the firewall; the degree of availability to the Internet at the application level is controlled by software – really a combination of web server, operating system, custom application, and often database software.

The DMZ typically allows restricted access from the Internet and from the internal network. Internal users must typically access systems within the DMZ to update information or to use data gathered or processed there. The DMZ is intended to allow the public access to information through the Internet, but in limited ways. However, since there is exposure to the Internet and a world of ingenious people, there is an ever present risk that these systems can be compromised. The impact of compromise is twofold: first, information on the exposed system(s) could be lost (i.e., copied, destroyed, or corrupted) and second, the system itself may be used as a platform for further attacks to sensitive internal systems.

To mitigate the first risk, the DMZ should allow access only through limited protocols (e.g., HTTP for normal web access and HTTPS for encrypted web access) and then the systems themselves must be configured carefully to provide protection through permissions, authentication mechanisms, careful programming, and sometimes encryption. Think about what information your web site or application will be gathering and storing. That is what can be lost if systems are compromised through common web attacks like SQL injection, buffer overflows, incorrect permissions, etc.

To mitigate the second risk, DMZ systems should not be trusted by systems deeper on the internal network; in other words, DMZ systems should know nothing about internal systems though some internal systems may know about DMZ systems. In addition, DMZ access controls should not allow DMZ systems to initiate any connections further into the network. Instead, any contact to DMZ systems should be initiated by internal systems. If a DMZ system is compromised as an attack platform, the only systems visible to it should be other DMZ systems.

It is critical that IT managers and business owners understand the types of damage possible to systems exposed on the Internet as well as the mechanisms and methods of protection, like DMZs. Owners/managers can only make informed decisions about what risks they are willing to accept when they have a firm grasp of how effectively their tools and processes mitigate those risks.

Lee Le Clair is the CTO at Ephibian. His Tech Talk column appears the third week of each month in Inside Tucson Business