From a security point of view, the type of cable chosen for various parts of the network can depend on the sensitivity of the information traveling over that cable. The three most common cable types used in networking infrastructures are twisted pair, coax, and optical fiber. Optical fiber is most often used in high-bandwidth and long-haul environments. Unlike either twisted pair or coax, optical fiber does not radiate any energy and, therefore, provides a very high degree of security against eavesdropping. Optical fiber is also much more difficult to tap into than either twisted pair or coax cable.

Wiretaps can sometimes be detected by using tools to measure physical attenuation of cable. Typically, a time domain reflectometer (TDR) tool is used to check coax cable, and an optical time domain reflectometer (OTDR) tool is used for optical fiber cable. These devices are used mainly to measure signal attenuation and the length of an installed cable base; sometimes, however, they can also detect illegal wiretaps.

Let's take a look at how you can detect taps in fiber-optic cable using an OTDR. One of the things an eavesdropper needs when tapping into an optical cable is an optical splitter. The insertion of an optical splitter into an optical cable allows the tap to be made, but it also affects the signal level in the media. This level can be measured. If a benchmark optical signal level is observed at several points along the topology of an optical media network, any conventional optical tap inserted into the network should be observable. Figure 7-1 shows an initial OTDR fiber-optic cable trace between two buildings.

Figure 7-1. A Baseline OTDR Measurement

Figure 7-2 shows the fiber-optic trace taken after an optical splitter was inserted into the length of the fiber cable.

Figure 7-2. The OTDR Measurement After the Fiber-Optic Splitter is Inserted

Although these types of traces can be an indication that an illegal tap might be in place, they are most useful in detecting cable degradation problems.

When choosing the transmission media to install for various segments of the network infrastructure, it is important to ensure that eavesdropping on the physical wire is proportionally more difficult as the data on that wire becomes more sensitive. In addition, if it is important that the transmission media be secure, the entire data path must be secure. (See Figure 7-3.)

Figure 7-3. An Example of Consistent Transmission Media Use

Figure 7-3 shows a large medical facility with two buildings connected by an FDDI ring. Because the server holding the patient records is located in the administrative building, and the doctor retrieving the information is located in the hospital building, both the backbone segment and the LAN segments of the network use optical fiber. It is very difficult for someone to gain access to patient information by tapping into optical fiber.

The physical path of the media, also known as the network topography, is a concern for the availability of the network and its attached devices. It touches on the reliability and security of the infrastructure. It is important to have a structured cabling system that minimizes the risk of downtime.

Imagine a large campus environment with multiple buildings. If the topography of the backbone network infrastructure is not a true starred network with common conduits at the base of the star, a construction worker with a backhoe could bring down large portions of the network. (See Figure 7-4.) If alternative physical paths are made available (that is, if you create a true starred network), however, only small portions of the network might become inaccessible if the physical cable fails. (See Figure 7-5.)

Figure 7-4. A Sample Physical Topography

Figure 7-5. A True Starred Physical Topography

The cable infrastructure should also be well secured to prevent access to any part of it. If cables installed between buildings are buried underground, they must be buried a minimum of 40 inches, although local regulations might dictate other guidelines. Sometimes, cables can be encased in concrete to provide maximum protection. The International Telecommunication Union has a number of recommendations (the Series L Recommendations) that cover the construction, installation, and protection of cable plants. You can access these guidelines at http://online.vsi.ru/library/ITU-T/.

The location of critical network resources is extremely important. All network infrastructure equipment should be physically located in restricted-access areas to eliminate the possibility of unauthorized access by physical proximity. Facility issues can be a horrific nightmare, but when it comes to creating space for wiring closets that house critical infrastructure equipment, such as switches, firewalls, modems, and routers, it is imperative that you fight for whatever autonomous space there is. Don't overlook any aspect of the physical facility. Having a secure lock on a wiring closet does not provide much protection if you can go through the ceiling panels to get into the room.

The infrastructure equipment includes more than just the networks and the routers, firewalls, switches, and network access servers that interconnect the networks. Infrastructure equipment also includes the servers that provide the various network services:

Most of these servers can be segmented into a common area to provide easier access control measures. However, you must also be sure that adequate redundancy needs are met to ensure the availability of these critical services, especially when a single LAN may get segmented from the rest of the network.

Here is another area of concern that is sometimes overlooked. When printing confidential configuration files or faxing configurations, there is the possibility that the printouts from printers or fax machines might fall into the wrong hands. You might want to make it a requirement to put all sensitive printers and fax machines on a LAN segment that is physically located in a room with controlled access. Also, you must have a way to dispose of the printouts and documents securely. Shredding is not out of the question.

Who has access to the wiring closets and restricted locations? The physical access requirements of controlled areas are determined largely by the results of the risk analysis or a physical security survey. It is good practice to restrict physical access to wiring closets and locations of critical network infrastructure equipment. Access to these areas should not be permitted unless the person is specifically authorized or requires access to perform his or her job.

Wireless access servers require special consideration because the nature of the technology requires that they be deployed in open spaces. A possible solution could be to put wireless access servers under video surveillance to deter physical tampering.

Part of the physical security policy should be to have contract maintenance personnel or others who are not authorized with unrestricted access, but who are required to be in the controlled area, to be escorted by an authorized person or to sign in before accessing the controlled area.

To ensure an enforceable physical security policy, it is essential to ensure that people's work areas mesh well with access restrictions. If these conditions are not met, well-meaning employees will find ways to circumvent your physical security. (For example, they will jam doors open rather than lock and unlock them 15 times per hour.)

If your facility is providing temporary network access for visitors to connect back to their home networks (for example, to read e-mail), plan the service carefully. Define precisely where you will provide it so that you can ensure the necessary physical access security. A typical example is at large industry meetings; if these meetings are hosted at a corporate facility, the host corporation usually has a separate network solely for guest privileges. This network should reside in a single area and access should be given only to conference attendees.

Adequate environmental safeguards must be installed and implemented to protect critical networked resources. The sensitivity or criticality of the system determines whether security is “adequate.” The more critical a system, the more safeguards must be put in place to ensure that the resource is available at all costs. At a minimum, consider the following environmental safeguards:

The last item might seem a little extreme, but anyone who has worked with fiber-optic equipment knows that is has been prone to network degradation and downtime caused by dust particles and will recognize the usefulness of this seemingly inane point.

Routing involves two basic activities:

The latter activity is typically referred to as Layer 3 switching. Switching is relatively straightforward: It involves looking up the destination address in a table that specifies where to send the packet. The table is created as a result of determining the optimal path to a given destination. If the table entry for a given destination is not there, the optimal path must be computed. The computation of the optimal path depends on the routing protocol used and can be a very complex process.

A security policy can incorporate detailed routing policies, where routes for separate networks and subnets are announced and accepted on an as-needed basis. Most routers, regardless of the routing protocol used, have features that suppress the announcement of specified routes and can ignore certain received routes and not incorporate them into their tables. Usually, there are many ways to accomplish the same goal. It is best to first design the logical boundaries, decide how open or closed an environment you want, and then implement the policy accordingly.

Filtering routes is one way of exerting some control over who can source traffic and to what destination. Filtering does not protect you from spoofing attacks, but it can make spoofing attacks harder to carry out.

Figure 7-10 shows a common scenario of creating logical routing boundaries.

Figure 7-10. An Example of Logical Routing Boundaries

In this scenario, the corporate network is divided into three distinct components:

The campus network has a Class B address of 144.254.0.0, which is subnetted into 256 distinct networks using an 8-bit subnet mask of 255.255.255.0. The Internet access is provided by an unnumbered interface. An unnumbered interface refers to a point-to-point connection that is configured without using an IP address. The remote access for a branch office is provided by a subnetted Class C address of 192.150.42.0 with a 5-bit subnet mask of 255.255.255.248. This branch office is mainly used for taking orders via the web and carrying out the corporation's financial transactions. The web servers used to collect the order information are all located on the 192.150.42.32 network. The corporation's routing policy allows free access to all corporate campus servers but allows only the branch office web server network, 192.150.42.32, to access the Internet through the campus network. The policy can be implemented as follows:

Static routing protocols offer the ultimate control of routes. However, the management of static routes in environments that exceed 10 or more entries can become an administrative nightmare. A dynamic routing protocol is much more flexible and can offer similar control for larger environments.

In some remote access scenarios, it may also be useful to further subdivide wireless network access, VPN network access, and dial-in access into separate subnets. If you have different authentication and access control policies for these remote access networks, these policies are easier to control and enforce using separate subnets.

A VLAN is a group of hosts or network devices—such as routers (running transparent bridging) and bridges—that form a single bridging domain. Layer 2 bridging protocols, such as IEEE 802.10 and Inter-Switch Link (ISL), allow a VLAN to exist across a variety of equipment, such as LAN switches.

VLANs are formed to group related users regardless of the physical locations of their hosts to the network. The users can be spread across a campus network or even across geographically dispersed locations. A variety of strategies can be used to group users. For example, the users can be grouped according to their department or functional team. In general, the goal is to group users into VLANs so that most of the user traffic stays within the VLAN. If you do not include a router in a VLAN, no users outside that VLAN can communicate with the users in the VLAN and vice versa.

Typically, although not necessarily, a VLAN corresponds to a particular subnet. Because a VLAN enables you to group end stations even if they are not located physically on the same LAN segment, you must ensure that the VLAN boundaries are properly understood and configured.

Within an existing VLAN, private VLANs provide some added security to specific network applications. Private VLANs work by limiting which ports within a VLAN can communicate with other ports in the same VLAN. Isolated ports within a VLAN can communicate only with promiscuous ports. Community ports can communicate only with other members of the same community and promiscuous ports. Promiscuous ports can communicate with any port. This is an effective way to mitigate the effects of a single compromised host.

When providing access control, it never works to have a different password for every router, switch, firewall, and other network device. Probably the easiest approach is to use one password for console access and another for logical Telnet or Secure Shell (SSH) access to the devices. These passwords should be changed on a monthly basis (or whatever timetable is comfortable). The passwords should definitely change when a person leaves the group.

Better access control can be achieved by avoiding common group passwords and instead, having passwords per individual user needing access to a given device. Using a AAA protocol such as RADIUS or TACACS+, per-user authentication, authorization, and accounting can be achieved in a scalable manner. This is extremely important as networks become larger, because individual password management of network devices only scales in small installations. As the number of routers, switches, and so on grows, it may be time to consider using a specific set of hosts as jumphosts to access the network devices. An administrator would be required to strongly authenticate to the jumphost and then from the jumphost leverage an authentication service to access network devices. The authentication service can be accomplished using RADIUS, TACACS+, or Kerberos where there typically exists machine-level trust to the network elements.

Some organizations still base their authentication mechanisms on standard, reusable passwords. Any reusable password is subject to eavesdropping attacks from sniffer programs. It is recommended that, if possible, these environments change to a more robust authentication scheme, such as any of the one-time passwords described in Chapter 2, “Security Technologies.” If this is not possible, however, here are some recommendations for using traditional passwords:

Many systems offer the capability to configure a greeting or banner message when accessing the system. Never include location information or the type of system in greeting or login banner messages. The system announcement messages must not welcome the user or identify the company, neither must it identify the equipment vendor or the type of operating system in use. Savvy intruders can easily reference databases of vendor or system hacks and bugs that they then can exploit. Make intruders work to get into the system before they learn what type of system it is; this gives you an additional chance to detect them breaking in. In addition, governments are creating legislature requiring specific language to aid in prosecution of any network infiltrators. It is always best to discuss the use and language of a banner message with your corporate legal department to ensure that the message is appropriate for your environment.

Example 7-1 shows a sample of a good banner message.

**WARNING**WARNING**WARNING**WARNING**WARNING**

YOU HAVE ACCESSED A RESTRICTED DEVICE. USE OF THIS DEVICE WITHOUT AUTHORIZATION
OR FOR PURPOSES FOR WHICH AUTHORIZATION HAS NOT BEEN EXTENDED IS PROHIBITED.
LOG OFF IMMEDIATELY. VIOLATORS WILL BE PROSECUTED TO THE FULL EXTENT OF THE LAW.

**WARNING**WARNING**WARNING**WARNING**WARNING**

Any security implementation is only as secure as its weakest link. If the security mechanisms you put in place are too complex for the users, they will find a way to circumvent the security practices, thereby creating more vulnerabilities.

Traffic can be filtered in either the inbound or outbound direction. Generally, inbound traffic comes from an outside untrusted source to the inside trusted network. Outbound traffic comes from inside the trusted network to an outside untrusted network. (See Figure 7-12.)

Figure 7-12. Traffic Direction

Whether traffic was initiated from the inside (trusted) network or the outside (untrusted) can be a factor in managing traffic flow. For example, you might want to allow certain UDP packets to originate from inside the trusted network (DNS), but might not allow DNS requests to come in from the outside untrusted network. Alternatively, you might want to restrict TCP traffic to outside untrusted networks if the TCP session was initiated from the inside trusted network.

The source or destination address can be used to filter certain traffic. This approach is useful for implementing precursory controls to help avoid spoofing attacks. Specifically, inbound filters should be configured that block source addresses that should be internal and to block destinations that are not internal.

TCP and UDP source and destination port numbers are used to recognize and filter different types of services. Which services you support is a key question and is discussed in more detail in the “Network Services” section later in this chapter.

At all ingress points to trusted networks, you should authenticate users before they can access particular services, such as Telnet, FTP, or HTTP. Available authentication mechanisms vary, but they all aid in controlling use and auditing who is accessing which services. As an aside, authentication can also help service providers with billing and accounting information.

It can be useful to look at applications and determine certain controls. You might want to look into filtering certain URLs or filtering specific content types (such as Java applets).

If you do not authenticate routing updates, unauthorized or deliberately malicious routing updates can compromise the security of your network traffic. A security compromise can occur if an unfriendly party diverts or analyzes your network traffic. For example, an unauthorized router could send a fictitious routing update to convince your router to send traffic to an incorrect destination. This diverted traffic could be analyzed to learn confidential information about your organization, or merely to disrupt your organization's ability to effectively communicate using the network.

Checksums protect against the injection of spurious packets, even if the intruder has direct access to the physical network. Combined with a sequence number or other unique identifier, a checksum can also protect against replay attacks, wherein an old (but once valid) routing update is retransmitted by either an intruder or a misbehaving router. The most security is provided by complete encryption of sequenced, or uniquely identified, routing updates. This approach prevents an intruder from determining the topology of the network. The disadvantage to encryption is the overhead involved in processing the updates.

In many cases, attacks against random hosts behind the firewall can be completely prevented, depending on how you've configured the firewall. The most conservative configuration allows no traffic at all to reach internal hosts unless those hosts initiate an outgoing connection of some kind. If you're set up this way, a number of attacks can be deterred.

Web servers, mail servers, FTP servers, and so on behind the firewall are at the most risk because any host on the network can send at least some kinds of packets to them at any time. You are generally better off putting those exposed services on a demilitarized zone (DMZ) network, rather than on your internal network. You must also make sure that application server itself is protected. Firewalls do some things to protect exposed services, but that's still where the biggest risks lie.

If internal client hosts have formed outgoing connections, they are exposing themselves to some return traffic. In general, attacks against internal clients can be conducted only by the server to which the client has connected—which includes someone impersonating that server using IP spoofing. To impersonate the server, the attacker obviously has to know which server the client has connected to.

For any given attack, protection is generally complete for hosts that aren't actively talking to the net, partial for hosts that are actively talking to the net, and minimal for exposed services. However, security depends on how the system is configured.

No product, even if properly configured, can protect you completely against outside hosts assuming the addresses of your inside hosts. There is no way a firewall, or any other device, can determine whether the source address given in an unauthenticated IP packet is valid—other than to look at the interface on which that packet arrived. Therefore, no firewall can protect against the general case of one outside host spoofing another. If something has to rely on the address of an outside host, you must have control over the entire network path to that host, not just a single access point.

Any internetworking product can make spoofing attacks more difficult by making it harder for the attacker to guess which nodes it's profitable to spoof at any given moment. This protection is not complete; an attacker who can sniff the network at strategic points, or who can make good guesses based on knowledge of the traffic patterns, can get around the internetworking product.

The actual data you collect for your logs will differ for different sites and for different types of access changes within a site. In general, the information you want to collect includes the following:

Of course, you can gather much more information, depending on what the system makes available and how much space is available to store that information.

Depending on the importance of the data and the need to have it local in instances in which services are being denied, data could be kept local to the resource until needed or be transmitted to storage after each event. Consider how secure the path is between the device generating the log and the actual logging device (the file server, tape or CD-ROM drive, printer, and so on). If that path is compromised, logging can be stopped or spoofed or both.

In an ideal world, the logging device would be directly attached to the device generating the log by a single, simple, point-to-point cable. Because that is usually impractical, the data path should pass through the minimum number of networks and routers. Even if logs can be blocked, spoofing can be prevented with cryptographic checksums. (It probably isn't necessary to encrypt the logs because they should not contain sensitive information in the first place.)

The storage device should also be carefully selected. Consider write-once, read many (WORM) drives for storing audit data. With these drives, even if attackers can get to the data (with the exception of the physical media), they cannot change or destroy the data.

Because collecting audit data can result in a rapid accumulation of bytes, you must consider the availability of storage for this information in advance. By compressing data or keeping data for a short period of time, you can reduce the required storage space. It is useful to determine a time frame with which everyone is comfortable and for which you will keep detailed audit logs for incident response purposes.

Audit data should be some of the most carefully secured data at the site and in the backups. If an intruder were to gain access to audit logs, the systems themselves—in addition to the data—would be at risk. Audit data can also become the key to the investigation, apprehension, and prosecution of the perpetrator of an incident. For this reason, it is advisable to seek the advice of legal counsel when deciding how you will treat audit data. Get legal counsel before an incident occurs. If your data-handling plan is not adequately defined before an incident occurs, it might mean that there is no recourse in the aftermath of an event, and it might create a liability resulting from the improper treatment of the data.

Because of the nature of the content of audit data, a number of legal questions arise that you might want to bring to the attention of your legal counsel. These legal considerations often differ from country to country. If you collect and save audit data, be prepared for consequences resulting from both its existence and its content. One area of concern is the privacy of individuals. In certain instances, audit data might contain personal information. Searching through the data, even for a routine check of the system's security, might represent an invasion of privacy. If you collect sensitive data, you should probably encrypt the stored data.

A second area of concern involves your having knowledge of intrusive behavior originating from your site. If an organization keeps audit data, is it responsible for examining it to search for incidents? If a host in one organization is used as a launching point for an attack against another organization, can the second organization use the audit data of the first organization to prove negligence on the part of that organization?