I have talked about security in several places throughout this book already, but there are a few points that warrant special consideration. In general, security is far too broad of a topic for even a single book. I usually take the view that the network cannot be the police. By this, I mean that there are too many ways to get around security restrictions. Placing too much reliance on the network is like locking the doors but leaving the windows open.
In particular, many organizations have policies about such things as outgoing email. In some cases, they have active email filtering to try to block users from sending out corporate secrets. This is a good idea in many cases, as email makes an extremely convenient medium for espionage. However, many organizations appear to forget that it's just as easy to put a floppy disk with those same secrets in your pocket and walk out the door.
The same is true for incoming data. Many organizations try to prevent viruses from coming in by scanning email as it arrives. Scanning is definitely a good idea, but it has to be accompanied by a general virus-scanning process that catches them when they come in through the window instead of the door.
To complicate matters further, no matter how good the network scanning is, it misses a lot. The outgoing file of corporate secrets could be in code. Even firewalls can be circumvented rather easily if one has access to the inside of the network.
See, for example, the April Fool's joke RFC 3093, which describes a way to make a tunnel through HTTP. Since most firewalls readily pass all HTTP packets, it is possible to hide an interactive session inside of an HTTP session. To the firewall, though, it just looks like legitimate web traffic.
Network security should never be considered actual security; it is just one element of a corporate security policy. It is, in effect, just one small tool that should be used to protect the organization.
Every organization should have a standard corporate security policy. This is a short document that describes what activities are allowed and what are not. To be effective, it needs to be backed up by well-defined penalties when somebody deliberately violates the policy. Usually, these penalties involve anything from a reprimand to dismissal, and perhaps even criminal action in some cases. To be effective, everybody in the organization needs to be aware of the policy.
This security policy document is sometimes combined with an appropriate use policy. Appropriate use policies generally define certain activities, such as distribution of pornography or engaging in abusive or criminal behavior using corporate resources, as unacceptable.
The problem with these sorts of documents is that they are frequently too vague to be enforceable. Not everybody would agree on what constitutes pornography or abusive behavior. Thus, it is possible to have a situation in which somebody believes that she is respecting the policy, while her supervisor believes that she is not.
For this reason, I personally prefer to keep security policy separate from appropriate use policy. It should be easier to create a well-defined security policy that does not need to be rewritten to solve problems of vagueness like this. If the appropriate use policy is a separate document, it can be rewritten without throwing the security policy into doubt at the same time.
A security policy needs to address two main issues: espionage and sabotage. Espionage is theft of information. Sabotage is deliberate disabling or damage of systems or information.
Sabotage using a sledgehammer is usually more effective than using the network. Espionage using a torch to cut your way into a safe of secret documents is also very effective. But neither of these methods has anything to do with the network, so they aren't covered by the network security policy. If you aren't extremely careful about restricting your definitions, building and enforcing this sort of policy can become an impossible task.
There are arguably more ways to do effective sabotage than espionage because the goal is simpler. These methods usually take the form of denial-of-service attacks. However, sabotage can also involve the network equivalent of simple graffiti, as in web site vandalism.
The security policy should be quite general. Once it is complete, you should think of ways to implement it. Think about what sorts of attacks are actually expected and where they are likely to originate. For example, do you believe that employees can be basically trusted, so that enforcement efforts can focus on external threats? Sometimes an organization has different internal groups who would benefit from one another's secrets.
The classic example is an investment bank. These organizations typically include a group of stock traders and a group of corporate financiers. The finance people arrange for large loans and help companies issue stocks and bonds to raise capital. If the stock traders were aware of these activities, they could benefit greatly; unfortunately, being aware of them constitutes illegal insider trading, and it carries severe penalties when the authorities find out about it. Thus, investment banks have to be careful about internal espionage.
In many organizations, the payroll department has computers that issue paychecks to employees. There has to be an appropriate level of security to prevent employees from giving themselves unauthorized bonuses.
Usually, the most serious threat is external. If the organization can't trust its employees, then it has far more serious problems.
The issue of auditing is extremely important but frequently forgotten. There is no point in just locking the doors and assuming that they will remain locked. You have to check them periodically.
In networking, every network Access point has to be monitored carefully. There are several standard things to look for. For example, are the remote-access accounts used properly? Do the accounts belonging to users who are on holiday appear to have heavy use? Futhermore, when a user is in the office, their remote access ID shouldn't be in use.
To look for firewall-evading tunnels like the one discussed earlier in this chapter, you can examine firewall logs. In most cases, these connections should be fairly short-lived, and most of the information should flow inward. If long-lived connections have a lot of outbound information, then this activity should be considered suspicious.
What is considered suspicious varies from one organization to the next, so somebody has to spend a lot of time with the log files to try and identify what sorts of things to look for. Once this is done, it is usually best if the logs are examined by an automated process. Firewall logs tend to be enormous files that are far too big for a human to read through and make sense of.
Most importantly, every suspicious event should be investigated. Suspicious events that keep happening are even more suspicious.
Many organizations use a Layer 2 security mechanism on their hubs and switches. Most high-end access devices have the ability to detect and compare the MAC addresses connected on each port to an expected address. If the device doesn't have the right address, then the port is disabled and a security trap is sent to the network management station. This situation radically increases the amount of work involved in maintaining these access devices. It also has a number of benefits as well.
First, using a system like this means that all network records have to be kept at least somewhat up-to-date. If a PC moves from one place to another or if somebody rearranges a patch panel, things stop working.
The security rationale behind this precaution, though, is to prevent unauthorized access to the network. Most networks are vulnerable to somebody walking in and leaving a small computer plugged in behind a filing cabinet. This device can then make a connection through the firewall to a server somewhere out on the Internet. By running a tunnel through this connection, it's easy for somebody to then have relatively free access to the entire network.
Alternatively, this device could run an autonomous program to gather information or to disrupt the internal network.
This sort of attack can be prevented in two important ways. First, any LAN ports that are not in use should be disabled. Disabling the ports prevents a device from being plugged into a random port on the wall that is no longer in use. Second, port-level MAC-address security needs to be enabled on the access device, whether it is a hub or a switch. Enabling the device is necessary to prevent somebody from taking a legitimate workstation connection and splitting it with a hub. Then the workstation that is supposed to be on the port and the unauthorized device can share the Access point.
On many hubs, there is another reason for using this kind of security. While a switch port only receives traffic destined for that MAC address and multicasts, a hub port receives traffic that is intended for every other port as well. This reception allows a "packet-sniffer" type device to sit passively on the port and listen to everything that goes past on the network. Any PC can be easily converted to execute this type of attack by simply installing publicly available software. Then whomever runs the attack can analyze the data that was gathered and use it to reconstruct secret information.
Note that this process is possible on any hub-access device. Even the device that has a legitimate claim to be on a specific port can have this software loaded onto it. Some hubs have gone even further and have implemented jamming.
Ethernet rules require that each time a packet is sent through a hub, it has to be sent out every port. However, it is possible to jam the information in the packet by replacing it with a string of nonsense. Usually, this string is just a bit pattern such as 1010101.... The real packet is transmitted only to the port that should receive it, and every other port receives the jammed version.
This situation is less common now than it once was because access switches are now cost competitive with hubs—particularly hubs with this level of sophistication. On a switch, this is not necessary, as the only port that receives the packet is the one to which it was addressed. There are still methods for attacking a switch with a "packet-sniffer" type device, but they are much more invasive and difficult to execute.
In several places throughout this book, I mentioned the idea of using routers to filter traffic for security reasons. Using routers to filter traffic basically means using the router as a simple firewall. It is configured to look for particular types of packets and to restrict where they are sent.
One common example involves putting a semitrusted server or router connection on the internal network. Doing so is sometimes necessary to deliver a service from an external service provider. No external service provider should ever be trusted fully, since they are intrinsically not subject to your organization's security policy.
This issue becomes a bit fuzzy when it comes to WAN links. The WAN provider has much control over the link medium and can, in theory, see the data that you send through them. Thus, some organizations choose to encrypt data over such links. I discuss the methods for doing this in Section 10.3.3.
This issue also becomes fuzzy when the external service provider's function includes back-office processes such as manipulating important corporate data such as financial information. In these cases, the organization may just decide to treat the external organization as if it were trusted.
For organizations that do not feel comfortable about this situation, however, several techniques improve the security. If the external service provider is considered potentially hostile, then a firewall may be required. However, in most cases, a simpler solution with a filtering router is probably sufficient.
Remember that the threat may not be from the service provider's organization, but from your own organization's competitors who may be using the same service. Suppose, for example, that Company A and Company B both use Service Provider C. If C's network doesn't prevent A from accessing B's network, then corporate espionage through this path is possible.
Many organizations choose to put these Access points behind routers. The routers are configured to allow only certain applications through. Usually, this configuration is specified by means of TCP port numbers, but it can also be easily restricted to certain IP addresses. Restricting on IP addresses can be useful when the service provider's server always uses the same address. The same can be effective internally when the access is always to the same internal device.
Filtering on IP addresses alone is rarely completely reliable; it doesn't do anything about spoof attacks in which the source address of the packet is altered. It also doesn't help in cases when the service provider's server has been compromised by the attacker.
The most reliable mechanism is to filter on everything that you can. If the application is always on the same TCP port number, then make sure that only this port can pass the filter. If this port is combined with IP-address filtering, then the security is that much better.
Note, though, that it is still possible in this case to launch an attack from inside the service provider's network using a spoofed source address and the known application TCP port number. This sort of attack can be extremely difficult to defend against. If it is considered likely, then a robust firewall is necessary.
IPsec is a set of security mechanisms for use with IP. RFC 2401 defines the current version. A detailed discussion of this sophisticated cryptographic system is beyond the scope of this book. But discussing its network design implications is useful.
IPsec is a public-key network security system that is used for both authentication and encryption of IP data. It is optional with IPv4. However, many of its functions have been integrated into the main IPv6 specification.
Public-key security means that both communicating devices share an encryption key or password. Each device has a public and a private key. The public key is generated from the private key using a nonreversible process and is then shared.
Device B knows device A's public key, and vice versa, but neither knows the other's private key. Device B can send secret information to device A by encrypting it using an algorithm that can be reversed using A's private key. The data can only be encrypted using information that only the sender has. Then it can only be decrypted using information that only the recipient has.
IPsec actually doesn't restrict the specific algorithm used. There are several good encryption algorithms such as DES, Triple DES, and RSA. They all have strengths, but legal restrictions exist on the use of Triple DES outside of the United States.
IPsec specifies how these algorithmic techniques can encrypt and authenticate IP packets. It is possible to use either or both encryption and authentication.
Encryption or authentication can be deployed using IPsec in two ways. It can be done for all of the traffic between two nodes, as a tunnel. Alternatively, individual traffic flows or conversations can be encrypted or authenticated separately. This process is called IPsec transport.
The tunnel mode is generally preferred because it can be used to hide information about the ultimate traffic destinations. For example, suppose a user has a PC connected to the internal network from the Internet via an IPsec tunnel (which is one way to implement a VPN system). In this case, somebody else might intercept and view the packets as they cross through the Internet. However, they will be encrypted, so they can tell very little from this process.
Suppose this session is encrypted per-flow rather than across the whole tunnel. Then it is possible for the person intercepting packets to do what is called traffic analysis. Traffic analysis means that they might tell from the IP addresses and TCP ports that large numbers of files are passing between two specific individuals. In many cases this much information could be sufficient to guess the contents of the packets. By analogy, if you see several pizza delivery cars all arriving at the same house, you can be pretty certain that there's a party going on. You don't need to know what's on the pizzas. Thus, whenever possible, it is usually better to use a fully encrypted tunnel.
There are cases when using this tunnel is not particularly feasible, however. For example, if the user communicates simultaneously with many different hosts that are not all behind the same gateway, it may be easier to use the per-flow system.
Understanding when authentication and encryption are needed is also important. Encryption is used to provide privacy. Authentication is used to verify the source. Clearly these functions are distinct but complementary. Authentication is particularly important if there is some question about the authenticity of the source. For example, if there is a danger that somebody will attempt to spoof or hijack a conversation, then authentication is critical. Encryption, on the other hand, is just used to make sure that nobody else can read the information. It doesn't necessarily mean that it comes from the expected source.
The best security is achieved by using both authentication and encryption together. However, as with the per-tunnel versus per-flow implementations, this usage varies with the particular network application.