Improving Computer Security through Network Design

Danny Smith
Technical Director
AUSCERT
auscert@auscert.org.au

Abstract

Security conscious organisations have learned the benefits of protecting their information processing infrastructure from unauthorised actions by intruders. This is usually achieved through a variety of security mechanisms including the use of filtering routers and firewall systems.

Unfortunately, many organisations leave key systems open to attack due to poor network design. This paper discusses typical scenarios which may lead to possible compromises, and examines ways to overcome these problems.

Introduction

The concept of a security domain that is introduced in this paper is not new. Many computer security practitioners have been (either explicitly or implicitly) using the ideas presented here for many years in protecting their networks.

What is required by all organisations is a more formal approach to the definition and protection of the various security domains. Failure to do this leaves an organisation open to attack and abuse. The purpose of this paper is to introduce the reader to a more formal concept of a security domain, how to recognise one, the dangers of sharing two domains of differing security requirements, and how to design a network to use and protect security domains.

A brief introduction to the three security requirements is used to provide a better understanding of the risk assessment process. This process helps to identify the differing security requirements for different parts of the information processing infrastructure, and hence to define the security domains.

Security Requirements

Security is often addressed as three main requirements: Confidentiality, Integrity, and Availability. It is the breakdown of these requirements that leads to problems requiring resolution. Loss of confidentiality may embarrass the organisation, or destroy its credibility. Loss of integrity may cause the organisation to lose control over its business. Loss of Availability may limit the organisation's ability to perform its business adequately, if at all.

Security protection mechanisms are often designed to increase one or more of these three requirements, usually through security services including authentication, access control, and non-repudiation.

Security Policies and Risk Assessment

Protecting computer systems against attack is more than implementing a few simple security solutions. As organisations become increasingly dependent on their information infrastructures for timely information, the effect of losing access to that information becomes more pronounced. Loss of access to the information may be just as devastating to an organisation as loss of control of it.

Threats to the information infrastructure may take a variety of forms, including accidental and deliberate threats. In many organisations, protection has been provided to minimise the effect of accidental threats such as fire, flood, power failure, or disk corruption. Some organisations are starting to implement measures to minimise the effect of a deliberate attack. This is usually achieved through a variety of security mechanisms including the use of filtering routers and firewall systems.

Often, organisations have implemented these solutions without careful consideration of a master approach to total security. It does not matter if corporate information is unavailable due to a lightning strike or a denial of service attack by an external intruder; the overall result is still the same.

To provide a more holistic approach to computer security, organisations must engage in a risk assessment exercise. A detailed description of this process is beyond the scope of this paper, but the basic mechanisms are important to understand. Organisations, in general, should perform the following tasks before deciding what and how many security measures are required to protect information systems:

Identify the assets of the organisation that require protection. This may include physical items such as computer hardware, blank stationery, backup tapes; non-physical items such as data, software, network access; and other usually unrecognised important issues such as the organisation's reputation.
Place a value on those assets. This will help determine the amount of security required later.
Determine what threats these assets may face. What are the attacks or problems that could adversely affect this asset (deliberate and accidental)?
Determine the types of vulnerabilities that could generate or cause this threat. For example, the loss of air conditioning to the computers could be brought about due to either a compressor failure or loss of power. Different problems - same result (no air conditioning).
Quantify the chance of a particular vulnerability actually occurring. For example, in Brisbane, the threat of a serious earthquake may be minimal, but the threat of a flash flood or lightning strike from a summer thunderstorm could be significantly higher.
By identifying the threats and their likelihood of occurring, and combining that with the value of the asset, we can quantify the loss we are likely to experience should that threat actually occur.
This is in essence the risk to that asset. Consider this as a two dimensional matrix (see Figure 1): cost of the asset on one axis, and risk of a threat on the other. In the area where there is a high risk to a high cost asset, solutions should be put into place to reduce the risk of loss to that asset. In the areas where there is either a low level of risk to a high cost asset or high level of risk to a low cost asset, the requirement to reduce the risk is not so clear. In the area where there is a low risk to a low cost asset, there may be no need to do anything more and the existing risk considered acceptable.

Figure 1.
Security measures are implemented to reduce the risk to an asset to an acceptable level. The more resource spent on security measures, the lower the risk that can be achieved. The risk can usually never be totally removed, and a small amount of residual risk is maintained. It is generally not good business sense to spend more money on securing an asset against some threat, than the cost of replacing the asset if some loss occurs.

Security Domains

In this paper, the term Security Domain is used to describe a network of computer systems that share a specified security level through a common element. The security domain may not always be clearly defined, and many security domains may overlap. In general, overlapping two different security domains is not good practice, and may lead to a weakness in the security systems.

The boundaries of a security domain can sometimes be difficult to identify. This is particularly true in client-server applications, where the client and server are quite a distance apart and the intervening network can be considered to be secure (perhaps through the use of cryptography).

A more formal model of this concept has been previously described as "rings of trust". In this model, outer rings contain a lower level of security, and systems requiring higher levels of security are located inside the inner rings. To move from an outer ring into an inner ring, extra security mechanisms are encountered. This model is shown in Figure 2.

Figure 2.

Some easier examples of security domains are any part of the network that relies on a form of trust relationship for correct operation. For example, an NFS client expects that its NFS server will supply the correct file details when requested. Should that server return false data (for example, indicate a program is privileged when it should not be), then the potential to compromise the client exists. Since the client and the server must trust each other, these two machines can be considered to be in one security domain.

Similar trust relationship protocols exist, such as the X window system (due to poor authentication, the X server must trust the X clients), the Berkeley trusted system commands (such as rlogin, rsh, and so on), NIS clients and NIS servers.

Another example of security domains can be defined by the classification of traffic that is found on the network connecting computers together. If a system that requires a higher level of protection is connected to a network which is accessible to the general public, then an increased potential for compromise of that system exists. If a network was created that was restricted to only essential traffic, and this was separated from the public network, then this could decrease that potential for compromise. Placing all machines that require general access on one network, and all restricted machines on a separate network allows the restricted network to be more effectively protected.

Security Domains by Example

Consider the following example which contains a number of security domains that require different levels of protection.

A small organisation has a few computer systems. These systems are used to transact the company's business including storing customer account details, accessing the latest stock prices, providing computing support for a small development team, and housing a public web site for clients to access. This organisation may be protecting some of these systems by locating them behind a commercially installed firewall system.

A sample picture is found in Figure 3.

Figure 3.

If the web system is located behind a firewall, then traffic from the public network must be allowed through that firewall to that system. This may provide one avenue of attack for an intruder.

If the web system is sharing disk space with another system (say a development machine) via NFS, then these two machines could be considered to be at the same security level.

If the development team are using NIS to distribute password files, then each of the systems in the NIS domain could be considered to be at the same security level.

If they are using the X window system within the organisation or trusted system commands such as rlogin or rsh, then these systems could be grouped into security domains due to the potential for an intruder to move from one system to the next via these services.

If special protection is implemented to prevent a small number of systems from accessing the global network, then these systems have had a special security requirement established for them.

The analysis could go on, but it should be becoming clearer that different systems have different security requirements. Some systems by nature of their role, the services they run, the protocols they use, or the restrictions placed upon them have a certain level of security requirements. Other systems have a different level.

In this example, a problem with the web daemon could allow an intruder to gain unauthorised access to that system running through the outer firewall. From there, the NFS, NIS, X, or other relationships may be exploited to gain further access to development systems, and from there potentially access to the production systems.

This example demonstrates that different security domains have been combined on the same network, and this may allow a breakdown in the total security.

What the organisation needs to do is to examine their systems and operation to determine how they could group systems, services, protocol requirements, and restrictions together in the same place (or on the same machine) so that appropriate levels of security can be applied.

For example, in the scenario above, placing the web daemon behind the firewall may not significantly increase the security of that daemon as the general public will still need to be able to reach those services. Provided that no other services were offered by that system, then it might be just as easily protected outside the firewall. Moving this system to outside of the firewall may therefore not significantly reduce its security. This will allow tighter controls on what traffic must be allowed through the firewall to be implemented, thus significantly increasing the security of internal machines.

Using NFS and a web daemon on the same system may also be a problem. The web daemon is in general a service that requires full public access to be totally effective, whereas NFS is a trust related protocol that is almost never used over the wider network. Combining these two protocols together (particularly where the general public are using one protocol, and we want to restrict their use of the other) may allow an intruder to gain access through one protocol, and leverage further access through the second. If these two services were split into separate security domains (enforced by filter rules), then the intruder would not be able to exploit a vulnerability in one service which could possibly be used to gain additional access through a second service.

If some machines on a network are to be restricted from using the global network in some way (based upon address filtering), whilst other machines on that same network are allowed full access, then all it takes is for the user to change the address of a restricted machine and full access can be gained. This can be limited through managed hubs and careful filters, however, this is usually difficult to manage and extremely inflexible. It is usually a better solution to place all restricted machines on one network and restrict the entire network appropriately, and place all unrestricted machines on another network with different access restrictions. This can become difficult if there are many different levels of restriction to implement however, this is usually not the case.

Identifying Security Domains

In general, the various security domains and their interaction becomes clearer after an organisation performs the risk assessment exercise. During that exercise, the assets and their required protection levels are identified.

By combining systems and networks together that have a similar requirement for security into a single place or onto one network, it is possible to establish an appropriate level of security. This forms a security domain.

If two assets (such as the web pages and the client database) require different protections, but are located in a single security domain (such as on the same system or the same network), then a potential for problems may exist.

Many organisations combine multiple services onto single machines in an effort to reduce costs. It is imperative that the temptation to combine services with differing security requirements onto one server is resisted. Ultimately, it will be cheaper to purchase two servers to split the services over, than it will be to recover from a major computer security incident. By careful planning, it is possible to separate services onto different systems, and combine a range of services with similar security requirements onto the same system (or within the same security domain).

Combining Security Domains

Once the security domains are identified and the level of protection determined, the interaction between those domains must be clearly defined and strictly enforced. This enforcement can be implemented using screening routers, firewalls, or other forms of boundary protection. For example, it may be an acceptable requirement that electronic mail pass between security domains (maybe from a single machine to another single machine) but that all other traffic is restricted.

All attempts to circumvent boundary protections should be reported and investigated.

By combining two or more security domains onto a single network, within a single machine, or failing to adequately separate the security domains, the effect is to lower the security requirements for each of those domains to the lowest value in each of the three security requirements; confidentiality, integrity, and availability.

Many organisations combine different security domains in inappropriate ways, leaving the organisation open to attack. Using the "rings of trust" model, the organisation's network may look something like the diagram shown in Figure 4.

Figure 4.

Identifying the different rings should not be too difficult if some careful thought is given to the design of the network and the services it offers.

Take care not to trade off one security requirement to satisfy another.

For example, one security domain could be a customer database that is considered absolutely confidential. Access to that database could be restricted to a few key personnel only, perhaps from set locations only, and increased authentication schemes employed to ensure only authorised access is granted.

Another security domain within the same organisation could be the anonymous FTP server. This does not require the same level of protection (in terms of confidentiality, although strict integrity or availability requirements may still exist), and in general, requires a much more open access policy for it to function successfully. Since DNS often has the same security requirements, then placing the publicly accessible DNS on this server may, at first, appear to a good idea.

If however, the correct operation of the customer database system requires reliable access to the company's DNS server, then an attack on the DNS server may cause problems in the operation of the database systems, compromising the availability of information and seriously impacting the business. In this example, availability has been sacrificed to improve confidentiality and integrity.

Examples

The following are real examples where organisations have combined security domains, and paid the price.

A university department had a single subnet which they shared between staff systems and a student lab. The IP addresses for the student machines were blocked at the router to prevent unauthenticated access to the wider network. The addresses of the staff systems were not blocked. Students soon learned that if they changed the address of their student system in the lab to another IP address, they could get full network access. Word of this spread, and the practice increased. New addresses were discovered and used, causing staff systems to go offline as their address was hijacked, and finally when the router address was hijacked, the entire network failed to operate reliably.

An organisation implemented a firewall system to prevent unauthorised network traffic into their site. They then allowed in Web traffic, FTP traffic, ftp-data traffic, telnet, smtp, network time, news, gopher, and a range of other services to a variety of internal systems. Effectively, the firewall was nearly useless.

A university had a public access library catalog system connected to a main backbone network where significant levels of traffic traversed. The system was compromised and a password sniffer successfully captured hundreds of passwords very quickly.

An organisation failed to filter NFS traffic at their router. This allowed an intruder to gain access to the systems through a NFS vulnerability, and the intruder then used this access to gain deeper penetrations into the organisation.

A research institution protected their supercomputer from public access. Unfortunately, they did not also protect the front-end computer systems adequately. An intruder compromised the front-end systems, and from there gained access to the super-computer.

A government department had many levels of trust relationships between many computers within their organisation. They were not connected to the Internet, so it was assumed they could not be attacked. The intruder accessed one system via a modem, and from there managed to compromise a significant portion of the network within hours.

An Example Solution

The diagram in Figure 5 shows an organisation that has performed their risk assessment, and designed a network according to their needs (this does not mean that this network will be suitable for all organisations!).

In this example, the organisation has a world wide web and ftp server available to the general public, a highly protected production network for transacting business, a development network for designing and testing new software, and an infrastructure network (such as DNS) that both the production and development networks can share. This means that the production network is not relying on information that is sourced via the development network, nor is it required that the development network access the production network for infrastructure support. In addition, the public network supplies infrastructure support to the general public that is updated from the internal network regularly.

Figure 5.

Conclusion

By recognising computer systems, applications, or network services that have a set requirement for security, it is possible to apply appropriate protections. Combining two different levels of security requirements lowers all security domains to the lowest common security level, effectively reducing the security for many domains.

By separating the different security domains into different parts of the network, they can be protected to an appropriate level which greatly increases their security, and can assist the prevention of "domain jumping" by intruders to gain deeper and more serious penetrations into the organisation, or to seriously impact the organisation's access to their information processing infrastructure.