Demilitarized Zone

Demilitarized Zone

The Internet is renowned as a dangerous place in security terms. Many large organizations have been attacked by individual crackers or groups of crackers. Their motivation varies from profit, through vandalism and on to the simple joy of a new challenge (‘I can pit my wits against you and win’). The larger the organization, or the more sensitive the data involved, the more of an attraction it is for the attacker to breach the security of the organization.

Internet technology systems, particularly those facing the public Internet, are regularly subject to attacks on their functionality, resources and information. How do we protect our systems from direct attacks?

Most Internet technology applications provide functionality that is vital to the business or daily life of their users. Alternatively, or additionally, they may contain some form of customer or company information that is quite sensitive. This functionality will be delivered using an APPLICATION SERVER ARCHITECTURE, with the data being held in a COMMON PERSISTENT STORE. The application may be delivered to the public, to business partners or to a variety of employees and contractors in the far-flung corners of a global organization. Each of these environments contains a potential security threat to the application's functionality and data. Statistics suggest that most attacks on computer systems originate within the organizations that use them rather than outside.

The risk of attack will vary based on the profile of the organization and the potential rewards for the attacker. However, even if you assess your organization as being of little interest to a serious Internet cracker, you will still need to take precautions. Most cars nowadays have some form of alarm or immobilizer system – usually fitted by the manufacturer. Such a system will not deter the serious criminal who will have a variety of countermeasures at their disposal. However, the system does serve to deter the casual criminal who will pass up your car for another that is not fitted with such an alarm (or will just lose interest and wander off). In this respect, Internet security is very much like the security associated with cars. Very few organizations require military-quality security for their corporate systems and data, however most organizations want to avoid being the victim of the ‘petty cracker’ or ‘script kiddy’.

The Internet technology application must obviously be protected from penetration by crackers, but there is also a broader view. The application will usually need to access information and services that are internal to the organization. This suggests that there is some form of contiguous connection between the internal systems and the crackers that threaten the application. Hence there is also a need to protect any connected internal networks from a perceived threat, certainly if the source of that threat is external to the organization.

There is a balance to be struck between making the application accessible to legitimate users and protecting corporate systems and data from inappropriate use. In an ideal world, the application would require no authentication from the user and would make it easy to access all the information and functionality held by the organization. On the other hand, such information may well be sensitive, such as credit card numbers or medical records. The functionality may allow users to transfer money or obtain goods and services. Such data and functionality needs protecting in the same way that bank cashiers are protected from physical attack. Indeed, a competitor of GlobalTech recently had credit card numbers stolen from their application server as they were stored in a location accessible from the public Internet.

The GlobalTech system is typical of applications that must balance the forces described. The system holds customer profiling information, retailer order information and commercially-sensitive sales information, any of which could be stolen or corrupted by an attacker. This information will be shared with GlobalTech's corporate systems making them liable to attack as well. In addition to this, retailers can order goods and services across the Internet. As this functionality is directly accessible from the outside world, it can be subject to direct attack. A breach of the security will potentially result in attackers being able to order goods and services at no cost. GlobalTech must take measures to protect this system data and functionality.

Box 8.5 100% security

‘Our system must be secure.’

‘Security is our top priority.’

‘We must protect our customers’ data as part of the trust relationship we have with them.'

These and many other phrases will undoubtedly be used during the inception phase of any e-commerce project. However, security is no more of an absolute than any nonfunctional characteristic. Military systems will tend to rate security far higher than ease of use or richness of interface, but even they are regularly breached. It is a brave architect or designer who will guarantee 100% security for a system – especially for a high-profile e-commerce system.

As you have seen already, you cannot opt to have 100% of all non-functional characteristics in your system. It is almost impossible to have 100% availability due to practical limits on the system architecture and the lack of a bottomless pit of money. And what does 100% performance mean?

In addition to the absolute limitations, there are tradeoffs to be made. Measures that improve one non-functional characteristic will in many cases affect the value of another non-functional characteristic. This is particularly true of security. Most security measures are based on trying to make it more difficult for attackers to access system data and functionality. The measures taken to secure a system will generally slow it down in one way or another. If the system is too highly protected, these security measures become serious ‘speed bumps’ on the road between your system and your customers. If you have too many speed bumps, you will soon have very few customers.

Provide a region of the system that is separate from both the external users and the internal data and functionality – commonly known as a DEMILITARIZED ZONE (DMZ). Restrict access to this region from the outside by means of limiting network traffic flow to certain physical servers. Use the same techniques to restrict access from servers in the DMZ to the internal systems.

Under this model, people outside the organization can only gain access to a set of web servers in the DMZ. Ideally these web servers are not responsible for any business functionality, since this makes it open to direct attack. Business functionality is delegated to application servers that can be shielded from the outside world. Hence it is best to use DEDICATED WEB AND APPLICATION SERVERS so that the application servers can be protected more than the web servers. The level of security on the exposed web servers can be increased and unnecessary services removed. Any attempts to access other servers from the outside will be denied by an external firewall, consisting of a combination of hardware and software firewall elements. As the number of servers exposed to the outside world is reduced, it means that there are fewer parts of the system that need a high level of security. In order to access those servers not directly exposed (and hence less securely configured), any attacker will have to breach several security elements that form part of the DMZ.

Network traffic within the DMZ and from the DMZ to the internal servers is limited by use of firewall software and hardware and router or switch filtering. A typical DMZ configuration, as used by GlobalTech, is shown in Figure 8.2.

Figure 8.2: DEMILITARIZED ZONE applied to the GlobalTech system.

The external router limits the network traffic from the outside world. It filters incoming traffic to ensure that packets carrying ‘unfriendly’ protocols are not carried into the organization. The external router can also ensure that traffic from the outside world is only allowed to access specific machines in the DMZ – traffic that attempts to access the corporate systems, or even the internal router, will be refused. This is sometimes referred to as a choke point. Traffic will be shepherded to the machines that make up the external face of the organization, such as the web servers. These machines will be built solely for the purpose of delivering web content and will be locked down to prevent other, unintended, access, as discussed in Box 8.6. The GlobalTech system only allows HTTP and FTP traffic into the organization, and even then such traffic is only allowed to the web servers. The external router drops any traffic that tries to reach the internal router, the firewall, or the external router itself. This rogue traffic is also logged at the firewall and notified to the system administrators in order to assist in the detection of potential intruders.

An internal router can then act as another choke point. Traffic through this router is limited to connections between the server in the DMZ and specific internal servers using a fixed set of protocols, which reduces the risk of attack on other internal systems. The use of an internal router helps to reduce the risk of attack should the external router be breached. Because of this threat, no traffic should be allowed directly from the external router to the internal router. The internal router used by GlobalTech allows inbound traffic only from the web servers, and even then it limits it to specific protocols (IIOP), specific hosts and specific port ranges. This means that any cracker who achieves a beachhead within the DMZ must either attack the internal router directly (and risk setting off alarms from the router) or they must be literate in IIOP to the degree that they could use it to gain access to one of the servers on the other side of the internal router.

Box 8.6 Hardening a system

As delivered, server-level operating systems provide a variety of useful services. However, services that are useful in a networked intranet environment can become a security threat when exposed to the outside world. A probing tool, such as SATAN/SANTA or SAINT, can quickly expose vulnerabilities in unsecured systems which can then be exploited by specific attacks. To reduce the chances of such a probe discovering weaknesses, systems that are exposed to potential attack should be hardened. This hardening takes the form of disabling or removing unwanted services, accounts and utilities. Examples of this would include the disabling of the telnet service on a Unix system, the disabling of the uucp account and the removal of any compilers that come as part of the standard build. In addition, hardened systems should have the latest security patches applied to them.

The process of hardening will generally consist of two stages. In the first stage, a base platform build will be defined. This will consist of just those packages and services that are required to run the components to be installed on the server together with the latest security patches. This will be bundled into some format that can be repeatedly installed (such as Sun Jumpstart) so that the server build is consistent and not prone to individual errors when being configured. The second part of hardening is that the hardened systems should be audited on a regular basis. Tools such as Nessus and Titan can be used to examine a Unix system, identify potential security vulnerabilities, and even automatically fix them. If a system has been hardened, then such tools can be run every day to re-close any security holes opened by crackers. Once the system is hardened, you may choose to install an intrusion detection system (IDS), such as Tripwire, to warn of potential attacks.

The characteristics of a hardened system will be different from those of a development system. Development systems tend to be very open, since this usually makes development easier. Those systems used in the QA or test environment should be hardened to the same degree as those in the live environment (as far as possible). This means that when the application or component is deployed onto the QA/test environment, any conflicts with security policy can be identified and addressed. It is no good waiting until your application is deployed in the live environment to discover that you cannot connect to your database because of firewall policy. It is usually part of the architect's job to ensure that suitable hardening takes place in QA/test to achieve this aim.

The whole operation of the routers and the traffic filtering may be controlled from a machine running specific firewall software. This makes it easier to apply consistent rules to the routers and to use statistical analysis to detect potential attacks. In some configurations, the firewall hardware itself acts as one or more of the choke points in the DMZ design. The firewall in the GlobalTech configuration acts as a clearing house for security alerts and as a management console for the DMZ. GlobalTech chose Firewall-1 software based on its track record and traditional association with Sun, on whose hardware it is deployed. The firewall software gets alerts from the two routers and provides a unified view of security in the DMZ. The firewall software also controls the configuration of the two routers to avoid inconsistencies creeping in between the three main parts of the ‘firewall system’.

Applying a DMZ to a system is a good way of providing protection for the system. However, you must remember that protecting the platforms on which the system is built is only part of the solution. Security is an ongoing task – some people would say that security is more of a policy issue than a technical one. All protection mechanisms – such as a DMZ – must be backed up with appropriate procedures and processes to ensure that the level of security remains high (see Box 8.7). If there is a high level of concern about possible attacks on the system, an intrusion detection system (IDS) may also be used. An IDS monitors the traffic on the network or on specific hosts looking for suspicious activity. If the IDS identifies a pattern of network or host traffic that indicates an attack is underway it will notify the system administrators. An IDS may be used on the network between the two routers, on the internal network or both.

Box 8.7 Protection or response

In the security patterns we discuss, the focus is very much on the protection of the system and its data through strategies based around SECURE CHANNELS, INFORMATION OBSCURITY, KNOWN PARTNERS and a DEMILITARIZED ZONE. However, this is only part of the security picture. In [Schneier 2000], Bruce Schneier describes such protective measures as ‘prophylactic’ – in other words they are just protective measures trying to create a boundary between the system or data and the outside world. Despite our best efforts, this will never be enough to offer a conclusive security story. Schneier continues:

There are three parts to an effective set of countermeasures:

• 
  

  
  Protection
  

  
  


• 
  

  
  Detection
  

  
  


• 
  

  
  Reaction
  

  
  

…

Protection, detection and reaction countermeasures work in tandem.

We discuss briefly various detection mechanisms such as intrusion detection systems (IDS). Such mechanisms can plug into an OPERATIONAL MONITORING AND ALERTING infrastructure so that system administrators are informed of any attempted breach (or at least any that is detected). This provides us with a certain degree of detection. However, we have not discussed reaction and potential countermeasures – and nor do we intend to do so. Neither of the authors would pretend to be a security expert, we simply use it within the boundaries of our knowledge as part of the system architecture where it is required. In architecture terms, the focus tends to be on protection with detection enabled by architectural decisions but with reaction falling outside of the scope of the purely architectural. If you need more information on the processes and procedures involved in risk assessment, security audit, countermeasures and seriously secure systems then refer to material such as [Anderson 2001] or find yourself a good security consultant.

Impact of the Pattern on Non-functional Characteristics

Availability	Availability may be negatively impacted as the firewall becomes a single point of failure (standard procedure is for a firewall to ‘fail closed’, i.e. in the event of failure it will deny all connections to the protected systems).
Performance	There is a potential negative impact on performance due to the overhead of network traffic filtering and the necessity for physical separation between the web servers and the application servers as defined in DEDICATED WEB AND APPLICATION SERVERS (although splitting the servers may actually improve performance). If this has not already been done to improve another non-functional characteristic, it must be done to implement a DMZ and so will add multiple extra network hops for each user transaction.
Scalability	The scalability of the underlying application is unaffected. However, the additional elements (such as filtering routers and firewall software) must be able to scale to the desired number of users and concurrent connections.
Security	Security is improved because fewer systems are exposed to attack and multiple firewall artefacts must be breached to compromise security.
Manageability	Manageability is negatively impacted since the very restrictions that limit access to internal data may make it difficult to access the application from an internal monitor.
Maintainability	Unaffected by this pattern.
Flexibility	Unaffected by this pattern.
Portability	Unaffected by this pattern.
Cost	Cost is increased as extra elements must be procured to build the DMZ. These include not only the filtering routers, firewall software and firewall host, but also the extra network equipment, such as switches and cabling, used in the DMZ itself.

Moving On

A DMZ helps to defend the ‘static’ parts of the application. However, a DMZ provides limited protection for data in transit (it helps to prevent eavesdropping inside the DMZ but it does not protect traffic once it has passed outside the DMZ). To ensure the security of data as it passes between the system and the users you should implement SECURE CHANNELS. You can also apply INFORMATION OBSCURITY to protect data in storage.

You can improve the security of a DMZ by applying INFORMATION OBSCURITY to the configuration information of its individual elements. This makes it more difficult for an attacker to get a good idea of the topology, roles and relationships of different elements that make up the DMZ.