Devices, Media, and Topology Security

This chapter is from the book 

Understanding the Basic Security Concepts of Network and System Devices

Network devices—such as routers, firewalls, gateways, switches, hubs, and so forth—create the infrastructure of local area networks (on the corporate scale) and the Internet (on the global scale). Securing such devices is fundamental to protecting the environment and outgoing/incoming communications. You also have to be aware of security risks and controls available in the public switched telephone networks (PSTN) infrastructure because PSTNs are often used for computer communications. This section of the chapter introduces the security concepts applicable to physical devices, network topologies, and storage media.

Firewalls

A firewall is a hardware device or software application installed on the borderline of secured networks to examine and control incoming and outgoing network communications. As the first line of network defense, firewalls provide protection from outside attacks, but they have no control over attacks from within the corporate network. Some firewalls also block traffic and services that are actually legitimate.

A firewall is designed to protect one network from another network.

Because network security is concentrated on configuring the firewall, or at least is built around it, a compromised firewall can mean a disaster for a network. For smaller companies, though, a firewall represents the best investment of time and money. All things considered, a firewall is as indispensable as the Internet itself; however, you should not rely on it exclusively for top-to-bottom network protection.

Increasingly, companies are also deploying firewalls outside the edges of networks, as well as between network segments and even on individual machines, where justified.

Three basic types of firewalls are available, in addition to one—the stateful inspection firewall—that combines the features of the three basic types. Firewall architectures include the following:

• Packet-filtering firewall

• Circuit-level gateway

• Application-level gateway

• Stateful inspection firewall

Packet-Filtering Firewall

Packet-filtering architecture involves checking network traffic for source and destination addresses, source and destination port numbers, and protocol types. Packet filtering allows an administrator to exclude traffic based on its source and destination addresses, and, depending on the device, it can also exclude traffic aimed at specific protocols and ports or traffic that is sent to or from particular addresses. This architecture functions on the Network layer (layer 3) of the Open System Interconnection (OSI) model. Most quality routers (not just firewalls) have packet-filtering functionality built in. Devices made by Cisco Systems, the undisputed leader in the area of network devices in general, employ access lists provided as a feature of the Internetwork Operating System (IOS). For Transmission Control Protocol/Internet Protocol (TCP/IP) traffic control, the two types of access lists are standard and extended.

Only extended lists allow you to check for all the previously listed characteristics and include some other conditions, such as secondary connections. These access lists can be applied to different interfaces to screen network traffic in both directions or in either direction on each interface. You can apply an access list filter to the external interface so the router will discard prohibited packets before it has to spend CPU time on making a routing decision. All packets that are not explicitly permitted are effectively rejected. Similar solutions that come built into the operating system can be found in Windows NT and its TCP/IP implementation, Windows 2000 with the same protocol features plus IP Filtering in the local policies, many Unix-like operating systems, and specialized firewall platforms.

Packet-filtering solutions are considered generally less secure than circuit-level architectures because they still allow packets inside the network regardless of the communication pattern within the session. Thisopens the system to denial-of-services (DoS) attacks (buffer overflow exploits in "allowed" applications on target machines, connections exhaustion, and so on).

Circuit-Level Gateway

Circuit-level architecture involves monitoring TCP/IP session requests between trusted hosts on the LAN and non-trusted hosts on the Internet. This monitoring, performed on the Session layer (layer 5) of the OSI model, is done to determine whether a requested session is legitimate. When hosts establish a session in TCP/IP communications, they conduct a procedure called handshaking, in which peers agree on communication parameters in TCP SYN requests and TCP ACK responses. The firewall ensures that these session establishment packets occur only when prescribed. It also verifies the validity of the sequence numbers used in TCP to reassemble packets in the correct order, as shown in Figure 3.1.

Figure 3.1 A normal handshake.

Popular attacks, such as DoS, are often launched when an attacker begins the TCP three-step handshake sequence with a SYN packet (and thereby begins to establish a connection) that is never completed. Instead, the attacker emits another SYN packet and initiates another connection that is also never completed (when repeated thousands of times, it causes problems). This attack, called a SYN flood, forces a victim system to use up one of its finite number of connections for each connection the initiator opens. Because these requests arrive so quickly, the victim system has no time to free dangling, incomplete connections before all its resources are consumed. TCP/IP standards suggest acceptable timeout periods that assume a timeout will handle some type of congestion or outage adequately. However, a massive number of connection attempts can occur during the normal default timeout period, thereby exhausting system resources and making the system unavailable for legitimate users. These attacks are detected and prevented in circuit-level architectures where a security device discards suspicious requests. If you receive 2,000 SYN (connection) requests per minute from a single host, you should become suspicious. Security devices can also be configured to do some or all of the following:

• Block any future communications from a suspicious host—This can be problematic if an attacker is using a spoofed source address. Legitimate traffic from that address will be blocked as well.

• Throttle back the rate of responses to requests—You can honor a certain number of requests per minute and discard the rest.

• Expire unanswered initialization requests much more quickly than the default TCP/IP recommendations.

• Notify an administrator of a potential attack in progress.

In fact, some of these techniques are not unique to firewalls and borderline devices, but instead should be considered for company-wide deployment. This is referred to as hardening a TCP/IP stack.

The following are the most commonly used reconnaissance and attack methods:

• Ping sweep—An automated procedure of sending Internet Control Message Protocol (ICMP) echo requests (also known as PINGs) to a range of IP addresses and recording replies. This can enable an attacker to map your network.

• Port scan—An automated procedure of initiating sessions on every specified TCP port to see whether the host replies. If it does, a service is running on the target port of the machine. Different services run on default ports. For example, FTP usually runs on port 21, and HTTP usually runs on port 80. Port scanning programs check ports and use responses from these ports to guess which services are running on a machine. Publicly available programs such as nmap (available from http://www.insecure.org) and nessus (available at http://nessuso.org) use target system responses to valid and invalid data to guess the manufacturer or operating system versions of a system and to list vulnerable ports and services on scanned machines. This is known as fingerprinting. These programs can be used to find and close security holes on your network by simulating attacker reconnaissance and exploit behavior. Do not use them without prior consent and knowledge of your network administrator.

• Email reconnaissance—A probe in the form of a legitimate email sent to a nonexistent recipient in an attempt to obtain a nondelivery-report (NDR) reply. These reports sometimes reveal important email infrastructure elements, such as IP addresses and hostnames. Spammers use a form of email probing for different purposes, as noted in Chapter 2.

• SYN flooding or DoS—One of the first attacks to be tried against a target, it's perpetrated as described in the previous paragraph. The well-known Ping of Death and User Datagram Protocol (UDP) Bomb belong to the DoS category because they make a target machine unavailable as the result of a buffer overrun and a crash. These DoS attacks are not application specific and can be prevented by a firewall.

• Application-specific DoS attacks—Many applications do not take sufficient safeguards against malicious user input. Buffer overruns occur when attackers intentionally send more data than an application is designed to handle, causing the application to crash. A firewall cannot prevent this type of attack without preventing all communication with a particular application. This type of attack can be prevented by ensuring that applications run on your network have been tested against this type of attack.

• IP spoofing—An attack in which the source is disguised by using a different address as its source address. Potentially, the attacker not only escapes liability, but also appears to be a trusted source who has permission to access the system. Authentication methods, rath. firewalls, should be used in this case.

• Packet sniffing—As described in Chapter 2, packet sniffing is an effective reconnaissance method employed by attackers in a shared medium such as flat Ethernet. A firewall really can't do much against this technique, but applications aimed at detecting network nodes running in promiscuous mode can be used.

• Trojan horses, back doors, spyware—A common way to gain control over a remote system is by installing a small application on a target machine. A Trojan horse is an application that is hidden in some other type of content, such as a legitimate program. It can be used to create a new, secret account called a back door, or it can be used to run spyware, which collects user keystrokes for analysis. Trojan horses can also be used to infect and control affected systems, destroy and expose valuable company information, or use your systems as launching pads for further attacks from the inside. After an internal system is infected, a firewall is not very effective protection, although it can prevent certain types of traffic from flowing between the attacker and the infected host or between the infected host and other potential victims. Some Application-layer (layer 7) firewalls offer content filtering, which can help keep malicious Java applets and ActiveX controls out of your network. You must remember that a firewall is just a first line of defense—it should never be viewed as a cover-all insurance policy.

• DNS transfer—An attempt to issue an ls -d <domain name> command against a DNS server in a bid to list all DNS server records (tantamount to getting a map of a fortified city about to be invaded). All DNS servers must be configured to refuse such a listing if the request does not originate from a preconfigured DNS replication partner. DNS was designed to be a system open for querying, but a DNS lookup is not the same as asking for a list of all a server's DNS records. If a DNS software vendor does not allow disabling of the ls command, consider implementing a separate DNS server for publicly accessible services, such as those located in the demilitarized zone (DMZ), or switch software vendors.

Some reconnaissance probes can reveal more than enough information for an attacker to proceed with his plan. If a potential attacker doesn't know about your infrastructure and cannot probe it, chances are you are safe, at least until the next attacker tries.

You cannot guarantee that your ISP will monitor its network for such activity and prosecute port scanners and ping sweepers. Therefore, you want your firewall to catch these reconnaissance attempts, log the source information, and alert administrators on-the-fly. Ping sweeps are simple to protect against, but you should be aware that ICMP requests might be rejected or discarded and that this difference is important to attackers. Actively rejected ICMP echo requests mean that the target host is alive, which gives the attacker information. To protect against this probe, a firewall needs to discard the packet silently so the attacker's ICMP requests appear to be sent to an unused IP address. The same goes for port scanning: a decent firewall detects a port scan in progress and rejects further requests from the source IP address, sending a real-time alert to the administrator.

Many times, attacks are daisy-chained in a bid to get as much information or cause as much damage as possible. For example, an attack can begin with a ping sweep and when a host replies, a port scan is launched. The port scan can find the SMTP (email) port. Next, an email probe is sent to reveal information about the type of email software the server is running, resulting in a non-delivery receipt (NDR reply). Then, the attacker can test that specific email server for known vulnerabilities to see whether it is patched or can be exploited.

If the ISP uses descriptive names in its DNS, an attacker can learn about physical connection types and the estimated bandwidth of the target. In a worst case scenario, if crashing or breaking into that machine is not possible, social engineering can still work for the attacker.

A good firewall also prevents non-application-specific denial-of-service attacks and, in some cases, even provides content filtering if it is an Application-level gateway.

Application-Level Gateway

An Application-level gateway is known as a proxy, and it functions on the highest layer of the OSI model: the Application layer. A proxy server basically inserts itself between an internal client (inside the network perimeter) and an external server (outside the network perimeter) for the express purpose of monitoring and sanitizing external communications. (For example, a proxy can remove references to internal or private IP addresses from client communications before emitting them onto a public network segment, thereby hiding information about network internals and details from outsiders.) When a packet travels all the way up the TCP/IP stack on a proxy server, software developers can implement application-based security controls. Therefore, user access can be controlled on an individual basis, group policies can be applied, content types can be restricted, and so on. The higher up the OSI model that a proxy can operate, the more controls that can be implemented; however, there might be some costs in either performance or flexibility. Some applications will not run properly (because the protocols they use can't be proxied), or such applications might need to be specially configured to operate in the presence of a proxy server (such implementations are called proxyable or proxy aware when they can be made to work with a proxy server).

Stateful Inspection Firewall

The fourth type of firewall architecture, stateful inspection, combines the aspects of the three basic architectures explained in the previous sections. Stateful inspection firewalls not only examine packets at the Network layer, but also gather information about the packet's communications session from all layers to determine whether a packet is valid in the context in which it is received. For example, when a communications session is opened, the session is recorded in a state table. Subsequent session packets are checked against this state table to verify that they are valid in the context of the session. A packet that is already part of a valid session does not have to be compared to all the rules, which speeds up processing. Packets that do not make sense in the context of an open session can be discarded. Likewise, packets that attempt to exercise questionable or unwanted commands or activities can be blocked, and questionable patterns of activity (attempts at dangling synchronization, invalid segment sizes, and so forth) can be discarded. This prevents potential attacks from getting underway or denials of service from succeeding, but requires complex custom configurations to work.

Granted, firewalls residing higher up the OSI model can perform the same inspections that lower-level implementations can, but they are more complex to write (leaving the potential for overlooked back doors and lots of bugs), more complicated to maintain, and less complicated to attack as a result of the first two. However, providing that the software was written correctly and is deployed and maintained correctly, this provides the best security level.

Other Firewall Considerations

In addition to the four core firewall architectures, a few other elements that administrators have to consider are involved in the designing of a firewall solution:

• Network policy

• Service access policy

• Firewall design policy

• Authentication policy

Network Policy

Network policy deals with general network use issues, subdivided into high-level policy and low-level policy. High-level policy deals with "why"; low-level policy deals with how to place administrative controls on the network. On the high level, companies normally stipulate which applications can be used on the network, which applications can communicate with the outside world, which applications can talk to local clients from the outside, and which conditions must be met for exceptions to be allowed.

Low-level policy details specifically which commands will be used on the firewalls to actually lock them down. Many companies are missing this important element, which in turn leads to on-the-fly, poorly designed solutions that are not effective as security controls. If the company grows dependent on an on-the-fly solution and the engineer who implemented it leaves the company, successors will have to figure out why and how it works. After network policy is defined, the high-level portion should be communicated to the new and existing employees who need to be aware of what is allowed on the network and how it is allowed.

Service Access Policy

Service access policy, an extension to the network policy and overall organizational guidelines, should deal with issues of communications between the local network and remote services available on the Internet (and vice versa). Firewalls can be used to exclude the internal use of unauthorized external services and the unauthorized external use of internal services.

Firewall Design Policy

Firewall design policy refers to one of the two fundamental ways firewalls deal with the traffic rules defined by the administrators. They allow what is expressly permitted and deny the rest, or they deny what is expressly prohibited and allow the rest. For obvious reasons, "deny-all unless expressly permitted" is much more secure than the opposite. Every packet goes through the list from top to bottom, and if a match is not found, the packet is rejected. Thus, entries representing the most frequent kinds of traffic should be placed higher up the list to make a quick match and minimize overhead.

Authentication Policies

Authentication policies deal with issues of establishing secure, effective user authentication. Older methods of authentication, such as clear-text passwords, are no longer considered secure. The authentication methods used in today's networks must be secure enough to be useless in the hands of an interceptor. (Many technologies that can be used for this purpose are discussed in Chapter 2.)

In most cases, Application-level authentication is involved on a per-application or per-user basis without the involvement of firewalls. This is also true about lower-level network services, such as virtual private networking (VPN), where specialized devices establish a tunnel.

Generally, firewalls should not be called on to perform authentication services for general users or access. All that a firewall should be called on to handle is the traffic it should block (when rules or filters are violated) or allow to pass through for a connection to be established (when no untoward or unwanted patterns, addresses, or activities are detected). Firewall authentication policy comes into play only for firewall configuration. Whenever possible, use only secure methods for remote access to security devices. Telnet sessions, although quick and easy to establish, are inherently unsecure and can jeopardize network control. Instead, use secure shell (SSH) wherever possible. If a firewall does not support SSH, create a third-party SSH server for management purposes in the demilitarized zone (see the "Security Zones" section later in the chapter for more about DMZ and security zones). Then, configure the firewall to allow SSH in and to allow Telnet connections only from within the DMZ on the internal interface. This protects the public portion of the management session and (generally) 95% of the risk is eliminated. You can use a VPN link as an alternative to an SSH session; either way, communications will be encrypted and indecipherable to snoopers.

Even hardware firewalls are running highly specialized software that allows them to be configured and monitored remotely. All password and Telnet session protection rules apply in a standard fashion. That is, don't use Telnet to manage security devices remotely; this is tantamount to putting an expensive bleeding-edge digital security lock on your front door and advertising the passkey in the local daily. Use SSH where possible. If your firewall does not support SSH, create a third-party SSH server for management purposes in the demilitarized zone, and configure the firewall to allow SSH in and to allow Telnet connections only from within the DMZ on the internal interface. This protects the public portion of the management session and (generally) 95% of the risk is eliminated. You can use VPN as an alternative to SSH.

As always, use complex passwords of eight or more characters with mixed case and at least one digit and one punctuation mark. Programs are available that force users to choose secure passwords by refusing passwords that appear in the dictionary, are too short, or do not contain at least a few nonalphabetic characters.

Passwords should never be birthdays, family member or pet names, nicknames, or other easily guessed words. Passwords should also never be shared with anyone, especially not by email, via instant message, or over the phone. Passwords should not be stored on or around your workstation, and you should not use the password "remembering" features of popular browsers.

Passwords should be changed on a regular basis. Most companies use a rotation period between one and three months. More frequent password changes tempt employees to write passwords down, and less frequent password changes increase the chances of a password being discovered through either guessing or simple mistakes.

Periodic audits of accounts and automatic account expiration can ensure that users do not retain access to restricted areas after they no longer need it.

Be sure that the highest privilege levels are assigned to no less than two and no more than four senior engineers for fail-over purposes. (That is, if one engineer is on vacation, the other one is not likely to be absent, too.)

Configure alerting and lockout for failed login attempts. In addition, allow configuration changes only from certain hosts inside the internal network or from a particular local subnet to increase the chances that your security infrastructure will not be compromised catastrophically.

Routers

A router is a physical network device (usually running proprietary software) that is used to connect several network segments into one network or an existing large network into smaller subnets. Routers operate on the Network layer of the OSI model and unite multiple physical network segments into a single seamless, logical network by understanding how to forward traffic from a sender to ultimately reach an intended receiver. This means that routing behavior is influenced strongly by the protocols in use. To some extent, therefore, understanding routing also requires understanding how Network layer protocols behave.

Various LAN protocols that were developed many years ago are still around. They do, however, employ certain techniques that are famous for not scaling well as an enterprise grows. You must take network protocols into account when considering routing designs. Some protocols require you to design specialized solutions to compensate for nonscalable or less secure protocol features. Broadcasts and service advertisements are just two types of protocol features that can require special routing solutions (or workarounds). The next few paragraphs discuss the following protocols: NetBIOS Enhanced User Interface (NetBEUI), Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX), and TCP/IP protocols, for example.

NetBEUI supports only local, bridged (flat) networks; has no addressing capabilities; is not routable; and relies on broadcasts entirely. This protocol is fairly old, but it can still occur in some remote locations—most likely because of legacy application issues. NetBEUI is the easiest protocol to deploy because no configuration is required. Owing to broadcast traffic overhead and lack of logical or physical organization, NetBEUI is not recommended for networks with 30 or more nodes. It is therefore the worst protocol for scalability and should not be the focus for security efforts because it supports no security features.

IPX/SPX is a routable Novell protocol that is still widely used. Although Novell switched to TCP/IP recently, IPX/SPX has a significant deployed base and remains supported and widely used. IPX has one significant scalability shortcoming: The more servers and network resources added, the more broadcast traffic is generated in the form of periodic service advertising protocol (SAP) announcements. SAP packets inform the network about resource availability. When scaling, it might not be desirable to propagate such advertisements owing to traffic overhead or for security reasons (an advertisement is also an invitation, after all).

Routers can help mitigate issues by dividing a larger broadcast domain into smaller subdomains. By acting as a SAP relay agent, routers can aggregate and forward all broadcast advertisements from any NetWare system only as required. Remote segments need to receive directed summarized updates, sent to other routers on other subnets. You can also implement access lists to control access to specific protocols from specific subnets and to limit distribution of SAP information, thereby controlling who can locate (and access) network resources.

TCP/IP is the de-facto standard protocol for all new networks, whereas other protocols are maintained only for legacy applications or backward-compatibility. TCP/IP has been around for several decades and provides numerous built-in techniques for effective control of transmissions over LANs and WANs alike. It has an elaborate addressing scheme well suited for subnetting and routing, although some proprietary environments can still affect overall network design. Consider older Windows Networking built on TCP/IP with Windows Internet Naming Service (WINS), Dynamic Host Configuration Protocol (DHCP), Remote Access Service (RAS), and computer browser issues. Most importantly, TCP/IP scales extremely well.

Generally speaking, you should not mix protocols, unless business requirements dictate otherwise. Multiprotocol environments are more difficult to maintain, more difficult to troubleshoot, and less efficient because each protocol imposes overhead and maintenance traffic that subtracts from available bandwidth. Furthermore, recall from the firewall section of this chapter that the smaller an attack surface is, the lower the likelihood of it being hacked. Each protocol has its own vulnerabilities, and some protocols rely on broadcasting service advertisements, which are inherently unsecure. However, if using such protocols is a business requirement, routing provides solutions that can contain broadcast traffic within specific subnets and make the overall network more efficient and secure. In addition, routers can employ access lists to reject unwanted traffic.

As the basis of the network infrastructure, routers must be secured both physically and logically using the guidelines discussed in the "Other Firewall Considerations" section earlier in this chapter. Routers can be configured from a physically attached console or via a network connection such as an SSH session.

A router directs a packet to its network or Internet destination using routing protocols to exchange information and determine routing decisions. These concepts and protocols could fill a book, but for this discussion, just be aware that routing exists in an intranet between routing devices and on the ISP network between a border gateway router and a router.

Routers maintain routing tables that are consulted every time a packet needs to be redirected from one interface or segment to another. Routes can be added manually to the routing table—a very secure but less-manageable method, depending on the size of the network—or be updated automatically using routing protocols such as the following:

• Routing Information Protocol (RIP)/RIPv2

• Interior Gateway Routing Protocol (IGRP)

• Enhanced Interior Gateway Routing Protocol (EIGRP)

• Open Shortest Path First (OSPF), Border Gateway Protocol (BGP)

• Exterior Gateway Protocol (EGP)

• Intermediate System-Intermediate System (IS-IS)

Protocols such as RIP, IGRP, and OSPF are used internally to propagate route information as it changes, such as when a link goes down or the network needs to converge or become aware of the downed segment. BGP and EGP are used externally to exchange route updates between your gateway router and the ISP. Some routing protocols send updates at preconfigured intervals; some replicate the updates immediately as they are triggered.

Routing protocols employ different techniques to prevent routing loops (when a packet is rerouted indefinitely without finding the destination). Some of these techniques are

• Counting to infinity

• Route poisoning

• Split horizon

Later revisions of each of these routing protocols authenticate a replicating partner in a different way, and knowing how each works is extremely important in avoiding trouble situations, such as these:

• A hacker sending a route update to your network and poisoning (marking as downed) an important route to cause a DoS condition

• The creation of a routing loop that overloads the router and causes the network to become very slow and appear over- utilized

• The update of a route to send all outbound traffic to a different host, which would then forward it to the ISP, launching an active interception or man-in-the-middle attack

Of course, no matter how secure the routing protocol, the first rule is to change the default password on the router itself. Failing to create a unique password practically invites attackers to wreak havoc on your network.

Switches

Sometimes referred to as microsegmentation, switching increases the performance of traditional media by reducing collision domains and facilitating media access. Classic switches operate on the Data Link layer (layer 2) of the OSI model and can be considered a multiport bridge with high-port density.

Switches have superceded more traditional hubs (multiport repeaters), which are no longer capable of accommodating adequate media access. In addition to facilitating congestion and media-contention problems, a hub is considered highly unsecure because it enables a flat network (a network segment with many network nodes sharing the same communication channel and seeing communications of every other network node in the segment), which is vulnerable to packet sniffers. (A switch can provide protection against a casual user attempting to pry into the network but needs additional security, such as port access control and MAC filtering, against ARP poisoning, sniffers, and other more advanced threats.)

Over time, networks designed on traditional Ethernet technologies grew in size, and network node density was constantly increasing. At the same time, software was developing and introducing new network-intensive client/server applications that exercised lengthier and more bandwidth-intensive transmissions. Software advancements introduced multitasking in the Windows world, adding to the existing functions in the Unix environment, and added to the stresses on the aging Ethernet network technologies.

Here is a simple explanation of the slowdown:

1. Before a workstation can transmit, it listens to the wire and attempts to sense existing activity in the network segment.

2. If a transmission is sensed, the workstation must wait a random amount of time and sense again until the wire is clear of transmissions.

3. When the wire is transmission-free, the workstation can commence its own transmission. However, when more than one workstation attempts to transmit a signal on the wire at the same time, a collision occurs and the segment is jammed.

4. Transmitting workstations then wait a random amount of time and attempt to retransmit.

This regime is characteristic of shared media such as Ethernet and is called collision sense multiple access/collision detect (CSMA/CD) to describe the type of circuitry involved. Apple Computer implements a similar approach called collision sense multiple access/collision avoidance (CSMA/CA). This differs from CSMA/CD in that it uses explicit signals ready to send (RTS) and clear to send (CTS) before accessing the network media—this approach avoids collisions rather than detecting them (hence, the difference in their names).

As the number of workstations attempting transmissions on a network segment increases, the chance of a collision increases. With more transmissions and collisions, the network becomes over-saturated and slows down.

A collision domain is a collection of network nodes that belong to the same shared network segment. LAN switching effectively splits broad collision domains into smaller domains or even dedicated network segments and significantly reduces or completely eliminates collisions and transmission delays. It also effectively doubles transmission capabilities by using full-duplex technology, meaning it uses all four pairs of CAT5 cable: two pairs to transmit and the other two to receive signals.

With recent improvements in switching technology, cost per switch port has steadily decreased, turning switching into a sound technology investment. In addition to fixing media-contention issues, a switch can help prevent packet sniffing and increase overall network security. You should implement switching if media contention problems exist or if the chances of attracting a sniffer are high (for example, in your business's guest offices or conference rooms where the public can access corporate LAN services). Although switches can enhance network security, they are not security devices per se and should not be considered a replacement for purpose-built security devices.

Switch security, as with firewalls and routers, requires both physical and virtual security controls. A switch has proprietary software that enables remote configuration of the switching operating system. Restrict physical access to devices where you can—at the network access point if possible or deeper into the distribution and core layers of the network. Employ strong authentication and password policies to secure virtual and local console access to the device's operating system and configuration.

Wireless and Mobile Communications

Wireless communications security was discussed in detail in Chapter 2. You need to remember that Wireless Application Protocol (WAP) applications are vulnerable to attacks at the WAP gateway. At this point, data streams are decrypted from Secure Sockets Layer (SSL) and are encrypted into Wireless Transport Layer Security (WTLS) for transfer to WAP devices. There is a brief time when the data stream is unencrypted. So, if the gateway infrastructure is not adequately protected, the entire WAP system is at risk. This vulnerability is especially common in developing countries where infrastructure investments can take budgetary precedence over security investments.

Some companies that don't specialize in mobile communications might provide WAP applications and services. These companies usually pass their WAP traffic to a third-party WAP gateway. The WAP traffic leaves the provider's protected (we assume) network encrypted in SSL. When it is decrypted at the gateway before being reencrypted in WTLS, it can be compromised; the provider has no control over the security of the WAP server.

Providers could avoid this vulnerability by operating their own WAP servers, but this is not a practical solution for two reasons: WAP broadcasting requires very costly equipment investments, and the technology is difficult to maintain and upgrade. It would be prohibitively complex to coordinate switching WAP clients between WAP service providers.

WAP communication cannot be considered safe in its present implementation. Therefore, WAP devices are inherently unsecure as well. In addition to the WAP specification flaw, mobile devices are easily lost or stolen. A company must be aware of these risks and consider which, if any, WAP implementations are suitable for its purposes.

Corporate wireless 802.11x-based infrastructures, on the other hand, have matured, and most types of known attacks are extremely difficult to conduct in the presence of strong authentication and encryption technologies. Risks primarily are attributed to the nature of mobile devices: They are small, valuable, and preferred over other personal items among thieves. All security discussions about physical and virtual device security in the context of switches, routers, and firewalls also apply to wireless access point devices used at the access level of the wireless network infrastructure.

Modems

Modems are gradually becoming a relic of "last mile" communications. They are being supplanted by high-speed cable and DSL connections that are significantly faster and not much more expensive than dial-up access. Although modems still can be found in some corporations and small/home office environments, most companies now use a more centralized administration and security model. A corporate network environment provides a single point of access to the Internet for all workstations and is guarded by a firewall or other security controls.

Some companies might still rely on modems, and some migrated environments might still have unused (and possibly forgotten) modems installed and connected to telephone lines.

Another reason companies might have modems and modem pools attached and connected to their networks is RAS, which is covered in Chapter 2 and in the following section.

No matter how good its firewall, a network's security can be compromised through a single PC connected to both the network and a modem.

War-dialing attacks take advantage of network-accessible modems administrators have forgotten or did not know how to secure. A war dialer is an automated software application that dials a given range of phone numbers to determine whether any are actually serviced by modems—indicated by returning dual tone multifrequency (DTMF) tones—and accepting dial-in requests. Telecommunications providers employ anti-war dialing software that attempts to detect war-dialing activity and disable any subsequent attempts; unfortunately, this protection works only if the numbers are dialed in sequence.

After a dial-in request has been accepted by a victim modem, the attacker can initiate password-cracking routines and compromise the system in a matter of time. Real-time attack-alerting systems are unlikely to detect a war-dialing attempt because the attack takes place in a seldom- or never-used part of the system. Fortunately, because modem communications are being replaced by more secure technologies, war dialing has become an unlikely threat for a LAN.

Conventional dial-tone modems, with their low throughput, are relatively easy to flood with useless traffic. This is just one way to cause a denial of service through modems.

Dial-tone modems have two basic operation modes: transmission and command. When switched on, a modem enters command mode and awaits instructions from the terminal to begin transmissions. After communication has been established, the modem looks for certain patterns in the data flow that signal it to drop the connection and return to command mode.

The Hayes Corporation developed and patented one such sequence consisting of three escape sequences bounded by two pauses in the communication stream. The two pauses mark the escape symbols as an actual termination request, not a coincidental matching pattern in the data stream. To avoid paying royalties to Hayes, some equipment manufacturers have devised their own (sometimes incompatible or faulty) techniques. Attackers could create wide-scale disconnects by sending a normal data pattern containing certain character sequences (that these "alternative solutions" would interpret as termination requests) via email messages, mailing lists, and IRC chat sessions.

Cable and DSL modems are not vulnerable to dial-tone modem attacks, but an always-on connection to the Internet presents its own dangers. Encryption and firewall solutions must be used for protection against potential attacks over high-speed residential media.

Always-on access significantly increases the chances that an attacker will find and compromise a system. Often home users are not technically sophisticated enough to take the appropriate safeguards against attacks. Any system connected to the Internet should employ a properly configured firewall.

Cable modems also present an additional vulnerability because they provide Internet access using a shared coaxial cable. Potentially, all traffic to and from a machine connected to a cable modem is visible to other cable users in the area. Any cable modem traffic that accesses a network must be encrypted to prevent network compromises.

RAS

Remote Access Server (RAS) technologies are described in detail in Chapter 2. Modern technologies such as VPN use standard corporate network infrastructures such as firewalls and existing authentication systems. A dial-up modem pool, however, is an RAS device that is fairly distinct from the rest of the network. The following security controls can be used to protect the RAS point of entry to the corporate network:

• Using strong authentication

• Forcing callback to a preset number

• Using two-factor authentication

• Allowing dial-in only

• Restricting users who are allowed to dial in

• Restricting dial-in hours

• Using account lockout and strict password policies

• Restricting allowed protocols

• Restricting access to specific servers

• Configuring real-time alerting system

• Enforcing and review RAS logging

The items on this list can be complimented by other techniques.

Strong authentication helps protect against war dialers and unauthorized attempts to gain access to an otherwise secure environment. The Challenge-Handshake Authentication Protocol (CHAP), described in RFC 1994, or Microsoft's extended CHAP, described in RFC 2433, is a more secure approach than sending passwords in clear text where they can be intercepted on a PBX switch. (You learn more about telecom and PBX in the next section.) Challenge handshake authentication is much less vulnerable to replay attacks because the challenge is not the same every time.

The callback feature disconnects the incoming dial-in request and immediately initiates a call-back connection, to either a predefined number or a number specified by the user. Using a predefined callback number is more secure because it eliminates the war dialing threat and controls the telephone numbers that can establish connections. Callback virtually assures the identity of the person at the other end, but it does not eliminate PBX eavesdropping or software bugs in RAS software that can cause significant trouble.

Two-factor authentication can be used when a callback policy is impossible—for example, when a user travels frequently. Devices such as the Cisco AS Series use a password and a second identifying piece of data provided by a physical device that contains a small clock chip and a special algorithm to generate codes. Neither the password nor the device alone can be used to gain access.

Restricting dial-in hours can limit potential exposure to attackers seeking access and trying to brute-force a password by repeatedly dialing in and trying new combinations. Often, automated attacks try to establish connections outside standard business hours to avoid immediate intervention by network security administrators.

A strict lockout policy can also help prevent brute-force attacks. After a designated number of failed login attempts, the system should automatically disable a user account.

RAS logs should be reviewed frequently and systematically, looking for connection attempts from unfamiliar phone numbers, repeated connection attempts, connection attempts at odd hours, and any other activity that seems suspicious.

Restricting dial-in access to one or a few servers limits network exposure in the event of a successful break-in.

Restricting dial-in access to just one or a few network protocols can also limit the effects of a successful break-in.

A real-time alerting system that notifies an administrator of suspicious activity as it occurs can help prevent or curtail unauthorized access. Real-time alert systems must be monitored, however, so it is most effective to use them in combination with either 24-hour monitoring or limited dial-up hours.

Like all network devices, RAS modem pools should be located in a highly secure place (such as a server room) that guarantees physical security and is accessible only to authorized administrative personnel. The platform used for dial pools, such as a Cisco AS-series access server, also should be secured as described earlier in the "Firewalls," "Routers," and "Switches" sections.

When all the previous security controls are implemented, the RAS environment becomes fairly secure and poses a challenge to potential attackers. However, these controls will not protect (even cumulatively) from the following three items:

• PBX vulnerabilities

• RAS software bugs, buffer overflows, and DoS attacks

• Social engineering

Historically, RAS software bugs were abundant in Windows applications and on the Windows NT platform in particular, but this has improved a great deal since the release of Windows 2000. Regardless of the operating system brand and version, vendor security patches should be applied as soon as they are available.

Social engineering is a favorite method of gaining access to otherwise impregnable systems, and combined with a public PBX infrastructure, this poses a threat that is not feasible to contain.

Telecommunications/PBX

Attackers have targeted telecommunications infrastructure for years. Originally, attackers sought to gain free long-distance service. As the Internet became more popular and dial-up access became a de-facto communication technology for residential and corporate RAS connections, telephone switch access also meant that an attacker could eavesdrop on communication sessions and decode all the transmitted information. Clear-text authentication, Telnet, email, and File Transfer Protocols were all in danger of being intercepted—even in a seemingly secure scenario where a user dialed in to a corporate network and accessed corporate resources from within the corporate infrastructure.

Some PBX hacking efforts were concentrated on accessing local loops that are out of commission. Local loops are numbers that belong to a telephone company and are no longer in public service but are still active. These decommissioned numbers allowed hackers to rack up thousands of dollars in long-distance charges that the telephone company could not bill to anyone because the numbers were no longer registered.

Another attack on telephone company infrastructure that is of more interest to our discussion allows a hacker to gain access to one or more telephone company switches. Switches have secret dial-in numbers that allow the telephone company and switch manufacturers to dial in and administer the switch remotely. Instead of regular username/password combinations, some manufacturers, such as Nortel Networks, employ a pool of challenge phrases that are presented to the dialer on a random basis. The dialer is expected to respond with a matching answer to get into the system. After the dialer is in the switch, she can wiretap any line, hijack a dial tone, and establish complete control of the lines serviced by that switch. Getting the challenge/response codes from the telephone company or the manufacturer isn't easy, but some switches use default usernames and passwords without implementing any sophisticated security controls.

An attacker can use social engineering to trick a telephone company or manufacturer employee to give away the secret telephone number to a switch in a telephone conversation. One of the most famous convicted hackers in the U.S. claimed that he had control of telephone company switches that serviced all of Nevada. The level of detail he presented makes his claim plausible and also makes it seem probable that something similar could happen again.

IDS

Intrusion detection systems (IDSs) are designed to provide the network with more sophisticated protection than that offered by firewalls. IDS can come in different packages: as a standalone hardware device that eavesdrops on traffic, as a software application for a dedicated server, or as hardware add-in modules for existing firewalls. IDSs can be categorized based on three main parameters:

• Active or passive analysis—A passive IDS system monitors attacks in progress and just tells the administrator that her network is under attack. An active IDS system takes a preconfigured action against the intruder to protect the network against an attack in progress.

• Host or network analysis—Host-based IDS resides on network hosts and monitors system logs, communications, file systems, and processes for suspicious activities. Network IDS monitors network traffic and looks for suspicious traffic. A key tool used by IDS is signature matching. A signature is a string of data used to identify a potential attack; it includes a definition of the protocol and header information and packet data that is characteristic of an attack.

• Misuse or anomaly analysis—Misuse IDSs are designed to look for network traffic patterns, such as host port scanning, that match attack patterns stored in the attack pattern database. If network traffic matches one of the known patterns, an action or alert is triggered. Anomaly IDSs use norms that are established by the network administrator to define what is acceptable traffic and what is suspicious traffic. An example might be the number of ICMP echo requests that are allowable in a given time frame. Any traffic pattern outside the norm triggers an action or alert.

Both IDS and firewalls protect networks, but where and how they do so differs. Firewalls are designed to prevent attacks before they happen by keeping offending traffic offsite. If attackers are smart enough to get through a tightly locked firewall, the IDS comes into play. It detects attacks that penetrated the first line of defense. Therefore, the IDS acts as a safety net for firewalls. Also, IDS can prevent application-specific attacks that the majority of firewalls are indifferent to and are designed to catch attacks in progress within the network as well, not just on the boundary between private and public networks.

The biggest advantage of the more sophisticated IDS is the capability to conduct stateful packet matching. That is, not only are certain packets filtered on a per-packet basis, but the whole communication session is also examined with a knowledge of which types and quantities of packets are normally expected. IDSs can provide an excellent level of protection against attacks of all kinds, but they require tuning to become an effective tool in your network. With so many variations and approaches to monitoring, you need to select the approach from which your company would benefit the most. IDS is discussed more thoroughly in Chapter 4, "Intrusion Detection, Baselines, and Hardening."

Network Monitoring/Diagnostic

Certain accepted practices in the industry are not yet standards but are pioneered by the companies or organizations that make standards. One of these practices deals with network monitoring and diagnostics. The industry recommends a structured approach to network management that includes fault management, configuration management, accounting management, performance management, and security management. This approach is referred to as FCAPS. This section discusses the framework of FCAPS and provides an overview of network monitoring protocols and security-related issues.

FCAPS is not a proprietary framework. It was developed by the International Organization for Standardization (ISO) to address network management issues. FCAPS, as originally defined, specifically focuses on the technical aspects of running the network infrastructure. It does not include the management of expenses, people, or software and server hardware (except for the network interface cards).

However, today's networks and business requirements are more integrated, to the extent that a major network fault or security breach can bring a large corporation to a standstill. Therefore, most companies have integrated network and systems monitoring and management practices anyway. This is usually because of cost savings, advanced management software that is available, personnel issues, or business limitations. The following sections cover integrated network and systems monitoring and management practices.

Fault Management

Fault management embodies all the tasks and duties related to network monitoring and troubleshooting. It is paramount to establish that a problem exists in the network in the shortest amount of time, determine what the cause is, eliminate the cause, verify that the service has been restored, and document (or log) the problem in a fault documentation or system monitoring log.

Configuration Management

Configuration management encompasses network configuration, device configuration, and all network and otherwise relevant settings. Support personnel must know the network configuration to troubleshoot a problem in a timely fashion. Personnel turnover, network size, and configuration complexity necessitate configuration documentation. Network items such as IP addresses, DNS settings, DHCP settings, subnet masks and default gateways, router configurations, network maps, and other network configuration information should be kept up-to-date and accessible to support personnel. Having this documentation on hand can help determine whether a router configuration has been tampered with and is also invaluable when recovering from a catastrophic network event.

Accounting Management

Accounting management consists of knowing exactly what a network system is built with and includes recording the exact model numbers and specifications of all network components and equipment and gathering and keeping all hardware and software inventory data up-to-date and available. Combined with other data provided by FCAPS, this is a valuable source of information for determining where the system needs tuning or upgrading to increase productivity or eliminate network bottlenecks or security risks. This segment of FCAPS is also concerned with billing users, if appropriate, and measuring and logging network resource usage.

Performance Management

Performance management involves baselining the network and analyzing trends to detect network problems and plan upgrades to, a replacement of, and development of the network infrastructure. The idea behind performance management is to identify problems before they occur by analyzing all network statistics and relevant indicators. It involves periodically benchmarking or measuring network statistics and comparing them with acceptable standards as identified in the network design documents. Criteria can include such values as data transfer rates, network and segment utilization, CPU usage, collision rates, broadcast rates, CRC error rates, queuing issues, and so on. Knowing network baselines can make certain types of attacks or consequences obvious. Performance management is closely tied with fault, configuration, accounting, and security management.

Security Management

Security management is one of the most important areas of FCAPS and one that directly concerns this discussion (although you might have noticed that all areas of FCAPS enhance network security in one way or another). Security encompasses data encryption and integrity, authentication, securing data transmissions and network nodes, and managing overall security requirements by weighting them against usability of the network and ease-of-use from a user's perspective. Security management involves a thorough understanding and analysis of available technologies—both hardware and software. Designing and implementing a secure network isn't enough. Security must be proactively managed to avoid new exploits, repair newly discovered design flaws, upgrade and enhance existing operating systems and embedded software, and take advantage of new security and data protection technologies.

Simple Network Management Protocol

The Simple Network Management Protocol (SNMP, RFC 1157) was developed in the 1980s as a temporary solution to the network management problems that arose from growing network infrastructures. Although it had a simple and effective design, it was meant to be a stop-gap measure until better solutions were developed. However, over time, it has become apparent that these other solutions have enormous financial and infrastructure demands and that only large companies can afford them. Therefore, SNMP has become a widely deployed de-facto standard for network management.

The benefits of SNMP-based solutions include but are not limited to the following:

• Industry standard

• Hardware independent

• Relatively simple to code

• Extensible and customizable

The purpose of SNMP is to enable the flow or exchange of management information between network nodes and enable management of the network environment. The SNMP protocol is an Application-level protocol and is implemented by an SNMP agent. SNMP management infrastructure consists of three main components:

• SNMP managed node—Any network-enabled device running an SNMP agent—for example, a hub, router, switch, Unix station, or Windows station.

• SNMP agent—A software agent that stores and retrieves device-specific information from its Management Information Base (MIB) and that is aware of local aspects of hardware or software. SNMP agents interact asynchronously with the SNMP network management station to supply information about exceeded thresholds and warnings and to apply changes (set thresholds) received from the management station.

• SNMP network management station—The focal point of the SNMP infrastructure that makes all management information available to NOC operators. It displays a list of warnings and errors reported by the agents, allows a certain amount of configuration control, and provides exhaustive statistical information on network operation. Management stations query agents, configure thresholds, and acknowledge warnings. This is used as yet another defense front in the overall corporate security domain.

  Figure 3.2 shows the SNMP architecture.

Figure 3.2 SNMP architecture.

In Microsoft environments, an SNMP managed node is a Windows workstation; an SNMP agent is a software component called SNMP Service; and the SNMP network management station is third-party enterprise software. A few predominant network management station products exist, with HP OpenView being the most well-known product. Similar solutions are available from Sun, IBM, and DEC, and an open source network management product called OpenNMS is also available.

The SNMP protocol exists in three versions: SNMPv1, SNMPv2, and SNMPv3. SNMPv3 was approved as an Internet standard by the Internet Engineering Standards Group in March 2002. Its primary difference from prior versions is that it provides security mechanisms to authenticate the origin of data, verify the integrity of data, ensure the privacy of data, and make messages time sensitive to prevent replay attacks.

It is important to recognize that SNMP agents are implemented by a variety of vendors and that each implementation can be affected differently by inherent protocol vulnerabilities. Some SNMP implementations might contain decoding problems that make a device vulnerable to denials of service, buffer overflows, or hostile takeover attacks. Countermeasures include disabling SNMP, filtering outside access to SNMP services and ports, and allowing only SNMP traffic on management networks. See the CERT Advisory CA-2002-03 for vulnerability and workaround information about specific SNMP implementations.

SNMP Management Information Base

SNMP defines standards for device information organization and communication between agents and management stations. The following are two standards that are included in SNMP:

• Structure of Management Information (SMI)—Covered in RFC 1902, this is an OSI standard that governs how a data structure should be organized. The purpose of maintaining a database of management information is to make the information easily accessible and organize it in a logical manner. Management information within devices is organized into a hierarchical structure of objects that have properties and values. SNMP follows the logical structure, objects, properties, and values as defined by SMI. SNMP is employed to read these values and adjust them as appropriate.

• Abstract Syntax Notation One (ASN.1)—The syntax standard for all SNMP messages between agents and network management stations. Because ASN.1 is a standard, it provides reliable interoperability between different vendors.

Management Information Base (MIB), now in its second revision (MIB II, RFC 1213), is the data storage facility that houses SMI-compatible data structures in the SNMP agent. MIB exposes vendor-specific and device-specific information to the SNMP agent running on the device, thereby making it available to the management infrastructure. Examples of data available through MIB are an IP address, routing table, open TCP sessions, subnet mask, free disk space, current CPU utilization, and so on. For each object stored in the MIB, several properties are defined, such as the name of the object, unique identifier, description, data type, and access permissions. When requesting the object data, properties are returned with corresponding values.

Certain object properties, such as CPU utilization or number of FTP sessions, are read-only; others can be configured from the central location.

• Messages, Communities, and Trap Destinations

Management stations and agents exchange information over UDP using the default port 161 for general messages and default port 162 for traps. Normally, the network management station sends a request for data and an SNMP agent retrieves that data from the MIB and delivers it back to the network management station. However, the SNMP agent is also allowed to initiate communication with the station when a trap event occurs. A trap event is a trigger for an alarm to be generated and delivered to the management station. An alarm can be generated by unauthorized system usage, by exceeding configured thresholds, or by some types of hardware failure. The four major types of messages are explained in the following list:

• GET—Used and initiated by the management station to request information from the managed node. This request is accepted and processed by the agent.

• GET-NEXT—Used in the same way as GET to request the next object after the first object in a group was requested. This sort of enumeration is convenient for requesting arrays of data. For example, when retrieving a list of open TCP connections, a few different connections can exist, but they all belong to the same type of object in the MIB.

• GET-BULK—Used to indicate that maximum datagram transfer size should be used when pulling large amounts of management data, initiating the transfer from the management station. Again, the agent is the processing and transmitting component in this case.

• SET—This type of message is used when a MIB object property value must be changed, providing that it has read/write access permissions. This communication is sent from the management station and accepted and processed by the agent committing the changes to its MIB.

• TRAP—Also known as NOTIFY message. Trap events trigger trap messages to be sent from the agent to the management station. These trap events are defined by the management station and usually represent critical device conditions. The agent submits these traps, and the management station processes them, generating an alarm. Alarms can be acknowledged after they have been looked at by the network management personnel. SNMP traps are submitted on an asynchronous basis.

• INFORM—Allows the exchange of trap information between several management stations without having to query agents again.

• Trap Destinations

Every agent has to be configured with at least one trap destination to be capable of sending traps. A trap destination is essentially an IP address, an IPX address, or the hostname of a target management station running SNMP management software that can accept and process traps and generate alarms. Trap destination is a very important security configuration that, if modified, can reveal a lot of information about the host and network infrastructure to unauthorized individuals.

Communities

All agents and management stations must belong to an SNMP community. Communities can be thought of as shared strings, and their purpose is to provide a basic form of authenticating SNMP messages. They can almost be thought of as workgroups or domains in the SNMP world, although they share absolutely no relationship. SNMP and management stations that belong to the same community can accept messages from each other and communicate as defined in the community properties. Depending on your SNMP agent implementation, you could set whether this should be a read-only communication and from which hosts the SNMP agent should accept messages.

You need to define hard-to-guess community strings to prevent security holes from appearing in the network. The trouble with community strings in SNMPv1 and SNMPv2 is that they are passed in plain text, which makes them vulnerable to packet sniffing. After a community string becomes known or is guessed, an attacker can gain a lot of information about the host being queried, pivotal configuration settings, and potential system vulnerabilities. In SNMPv3, additional privacy measures make the detection of the community string more difficult.

Specifics of SNMPv2

SNMPv2 is based on the first version of the protocol and is designed to extend the functionality of its predecessor somewhat. Similar to SNMPv1, SNMPv2 is based on SMI. However, it introduces new data types and enhances some existing ones. It also implements SMI modules, the capability to group different information into modules, and capability and compliance statements.

SNMPv2 implements two new protocol operations, or message types: GET-BULK and INFORM, which aren't supported in the previous version. Also, packet data units (PDUs) formats are not compatible between the two protocols. Because of message format and type enhancements, the two versions are effectively rendered incompatible.

To manage all SNMP devices regardless of their version, an SNMPv2-based management environment has to either use SNMP proxies to translate messages between versions or use management products that are capable of identifying and adapting to the version of SNMP running on each managed device. SNMP proxies act as intermediaries between management hosts and managed devices that do not share the same communication standard. Their purpose is to receive messages from the management host, analyze the request, and issue the appropriate version command or commands to the target device. Proxies collect the response or responses and forward these to the network management station. In some instances, one SNMPv2 request is translated to several SNMPv1 requests due to message type enhancements in v2.

Recent versions of Cisco IOS software support all three versions of SNMP standards and eliminate the need for proxies when managing Cisco hardware.

RMON

The Remote Monitoring (RMON) specification can be considered an extension to the SNMP standard and is based on RFC 1271. It was defined in the early 1990s and is based on the similar standards as SNMP. It also relies on the MIB structure of information and SMI. As seen in RFC 1271, availability of RMON statistics and information can prove pivotal in designing and assessing network security. Its purpose is to deliver network information grouped into the following major monitoring elements:

• Statistics group—Contains statistical information collected by an RMON probe from each of the configured interfaces on the device. It provides detailed counter information, characterizing network traffic on each monitored interface. Reported numbers include

  • Packets dropped, sent

  • Bytes sent

  • Broadcast packets and multicast packets

  • CRC errors, runts, giants, collisions

  • Fragments, jabbers

  • Counters for packets in the byte size ranges of 64–128, 128–256, 256–512, 512–1024, and 1024–1518

• History group—As the name suggests, this group includes information that is sampled over a period of time at regular intervals and is stored for later analysis. It includes items sampled, sampling intervals, and number of samples.

• Alarm group—If alarm thresholds are configured on an RMON-monitored device, statistics data is sampled periodically to be compared to threshold values. If threshold levels are exceeded, an alarm is generated and posted to the alarm table.

• Host group—Contains basic statistical information on the hosts discovered in the network. This information includes host addresses, number of packets sent and received, number of multicast and broadcast transmissions, and other pertinent information.

• HostTopN group—Designed to prepare top lists of hosts based on certain configurable criteria. It can be used to compile top error lists, for example, and identify major sources of errors and faulty or improperly configured equipment in the network. It also can reveal break-in attempts and brute-force incursions. Information included here is statistics, hosts being rated, and duration and sampling rate of the compilation.

• Matrix group—Stores statistics on conversations between participating hosts. Each time a new conversation is initialized, it is verified with the group and is added if missing. Information in the matrix group includes source and destination addresses, packet counts, bytes transferred, and number of errors. This information can prove indispensable when analyzing and planning network usage, as well as when designing IDSs.

• Filter group—Contains streams of packets that are logged if they match a specified formula. This allows for detailed application-based or protocol-based communication statistics analysis on a given device. It can also be used for event generation. Criteria that can be specified include various packet parameters.

• Packet capture group—As the name implies, it allows the logging and analysis of actual packets. Parameters that can be specified include capture buffer size, status, and number of captured packets.

• Event group—Controls event generation and notification on a monitored device. It works together with the alarm group, controlling the amount and periodicity of alerts. It provides information about the event type, event description, and time of the latest occurrence.

Implementing all these groups isn't mandatory, and most vendors opt to implement the groups that provide the most basic and fundamental information first. However, some of the groups are dependent on others and cannot be implemented without implementing other groups as well. For example, the alarm group depends on the implementation of the event group.

RMON can provide crucial information for the following security purposes:

• Network security and real-time host metrics and configuration.

• Network monitoring and operations information critical to supporting networks and ensuring proactive monitoring, including alarms.

• Matrix information that describes data flows, characters, and quality and supplies network and security designers with one of the most critical parts of information needed to ensure effective designs.

• Packet capture, traffic analysis, and decoding capabilities necessary for troubleshooting and design.

• Historical information for trend analysis, baselining, and performance monitoring, needed to effectively design and support networks. It is used by both groups: network operations and network architecture/engineering personnel.

• Network accounting and billing applications can use data provided by RMON for business and financial purposes.

Cisco Systems includes RMON functionality in its IOS software. However sophisticated, this information is only as useful as it is accessible. Centralized RMON configuration management, analysis, and tuning is necessary, and several software packages are available to be deployed as add-ons to HP Openview, IBM, Sun, and DEC solutions. Some can even be operated independently without the need for implementing expensive management infrastructure.

You should be aware that the traffic between monitoring agents and management stations can slow down your network if you have a large number of hosts. Polling can take from as little as 800 bytes to up to more than 2 kilobytes per host. Multiply this by the number of hosts on your network, and the traffic load can become prohibitive.

Workstations

Workstation security is often overlooked, but this is one of the most attractive areas to intruders because it is the path of least resistance to deploying an attack. It is not unusual for users to be naive and to occasionally click links when they read "click this link" or to open emails with potentially suspect or downright ominous subject lines, especially if the company is not in an IT-related industry. Average non-IT users are not as aware of Internet risks as their IT counterparts are. (Note the usage of the word average here. It means that in every environment, you are likely to encounter exceptionally aware and, unfortunately, exceptionally unaware individuals. A single case of exceptional unawareness is enough to bring a network down.) Unfortunately, Internet risks are not the only risks that can exist in an organization. Basic user protection controls from Internet risks are covered in Chapter 2, but the following is a list of other risks you must protect against:

• Workstation and laptop theft

• Natural disasters, fire (arson)

• Physical access by unauthorized personnel (visitors)

• Physical failures of workstation components

See Chapter 7, "Physical Security, Disaster Recovery, and Business Continuity," for more information on these subjects.

You can't prevent things such as natural disasters and physical failures of components; however, you can prevent catastrophic information loss when a disaster occurs by implementing a corporate-wide backup policy. A comprehensive policy should mandate the storage of all company files on a dedicated network server that is located in a secure environment and that runs nightly backups. Backup tapes should be properly labeled with date and volume information, rotated, and stored offsite for further protection. One item many administrators overlook is the testing of backup media. It is not enough to run a nightly backup; the backup must be tested to ensure that it can actually be used to restore data. In addition, you might want to test the tape on various devices to ensure it works on other devices and not just yours.

In the area of theft, two solutions are available. The most obvious is a security lock. Every laptop comes with a hook for a security lock that can be used to deter all theft attempts. Similar locks exist for desktop workstations, as well. (These devices are particularly useful in schools, universities, walk-in printing shops, Internet cafes, and other public places that can be difficult to control.) To protect the information that must reside on a laptop or workstation, encrypt individual files or encrypt the file system. The Windows Encrypting File System (EFS) makes it impossible to read file information without appropriate login credentials.

If your company has regular visitors who might pose a risk, consider buying disk drive locks to ensure that critical information cannot be extracted using a disk drive. Some manufacturers now produce workstations without floppy drives. Securing floppy access also prevents employees from bringing in infected files. In addition to physical prevention, train employees to always log off or lock their unattended workstations. Combined, these methods will also prevent a visitor from booting a system from a floppy drive.

Servers

Everything discussed in the workstation section applies just as well to the servers. Naturally, servers are more sensitive to attacks. Therefore, all servers (and as much network equipment as possible) must be isolated in a server room or an ISP co-location facility and must be locked to prevent any type of unauthorized physical access. Visitors to these premises must be justified and supervised. No matter how rigorously your software is configured to guard your network from hackers, if a nighttime cleaning person can accidentally switch off the box while dusting it or knock a $15,000 piece of equipment over, your protective measures have failed. One major corporation spent thousands of dollars investigating how someone was sabotaging server backup tapes, only to find that the magnetic interference from a motorized floor buffer was erasing the tapes in their storage rack. Make sure that access to the room is limited to authorized personnel only; use server racks that have locking capabilities; and when selecting server hardware, assess its physical security controls in addition to its other features. We talk more about locking down servers in Chapter 4.