Network Intrusion Detection Systems

Network Intrusion Detection Systems (NIDSs) are designed to alert administrators when malicious or illegitimate traffic is detected. Malicious traffic can consist of worm or exploit-based code, while illegitimate traffic (often termed “misuse”) consists of traffic that deviates from established security policy such as surfing porn sites or peer-to-peer connections. Network-based IDSs can monitor an entire, large network with only a few well-situated nodes or devices and impose little overhead on a network. NIDSs are found in most networked computing environments today because, no matter how well security controls are implemented, it is impractical to maintain defenses against all known and potential threats to networked systems and applications. In VoIP environments, NIDSs provide an additional layer of defense.

NIDS Defined

NIDSs detect suspicious activity in three ways. First, the security community maintains an extremely large database of specific attack signatures. These signatures are programmed into the NIDS sensor, and are updated on a regular basis. Examples of attack signatures include Code Red, NIMDA, DoS attacks, buffer overflows, ASP, and CGI vulnerabilities. Second, the NIDS sensors contain preprocessors that continuously monitor the network for anomalous behavior. Though not as specific as attack signatures, these anomalies are still highly effective for the detection of port scans, distributed network probes, new forms of buffer overflows, and Denial-of-Service attacks. Third, all NIDS appliances can apply and detect security policy deviations. These policy deviations include the detection of unauthorized network services, applications running on unusual ports, and backdoor/Trojan activity.

Signature-based NIDSs are essentially network sniffers combined with a database of attack signatures. One of the most difficult (and necessary) tasks when initially configuring the NIDS is the job of de-tuning it. It is important that the number of false positives be reduced; otherwise, they will make meaningful analysis of the data impossible.

Active Security Monitoring

At this point, we have examined and hardened the working components of the existing security infrastructure, established procedures to confirm user and device identities, and logically separated voice and data traffic, thus allowing the network to now carry them. The next step in maintaining the security of this infrastructure is to monitor traffic and the state of key devices. This is accomplished by active monitoring.

Plenty of commercial and open-source tools exist to help with this, and in this chapter we will look at several categories of them. We won’t, however, discuss in any detail the large commercial network monitoring suites like NetIQ, SMARTS, BMC Patrol, HP OpenView Operations, HP Network Node Manager NNM, IBM Tivoli, Nortel Optivity NMS, Cisco Ciscoworks, Sun Solstice SunNet Enterprise Manager, Micromuse, Computer Associates CA Unicenter, and Microsoft Operations Manager 2000 (MOM). While we recommend that organizations employ one or more of these enterprise tool suites (particularly to monitor network jitter, packet loss, and latency), the configuration, use, or integration of any one of these tool suites with VoIP network monitoring components is complex, dependent upon both the suite chosen for monitoring, and the peculiarities of each particular network. For these reason we will have to leave this discussion to another time.

A related class of tools for both monitoring and performance testing of VoIP networks include tools like Empirix Hammer, Brix Network Verifier, and Shunra’s Virtual Enterprise. These tools use different techniques and metrics to monitor the functionality, performance, scalability, and robustness of VoIP networks to provide signaling and media quality data on every call. Administrators can monitor high-level network metrics via integration with their existing Network Management Systems or can drill into the details of any call down to individual protocol and network messages.

We will start off by discussing in more detail two intrusion detection (ID) technologies: NIDS (network-based) and HIDS (host-based). NIDS inspects all inbound and outbound network activity and identifies patterns of packet data that may indicate a network or system attack. NIDSs are normally arranged in a multiple-sensor-to-one-console configuration, where the sensors reside on dedicated appliances distributed at key network junctions, and report back to a central management console. HIDSs, on the other hand, normally reside on the server that they monitor. HIDS can also report back to a central management console. A third class of intrusion detection is exemplified by DShield or Symantec—distributed intrusion detection—where global system attacks are reported to, and consolidated by, a central manage-ment server. Intrusion detection is a requirement in contemporary networks since it is not possible to stay abreast of existing and potential threats to modern computing systems.

Next, we will take a look at logging, primarily focusing on syslog and SNMP. Syslog (system logger) provides a means to allow a machine to send event notification messages across IP networks to event message collectors (also known as syslog servers). The decision regarding how much and what types of data should be logged is a critical responsibility of the system administrator. However, in most modern systems the sheer amount of logging data generated by system loggers can easily overwhelm most system administrators. We have witnessed organizations that react to log events, not based upon the data contained in the logs, but rather according to the number of logs generated per some unit of time. In order to deal with this mass of data, many system administrators develop scripts or tools to examine the log files and extract the important information. These tools are important because, without them, log data is often ignored. SNMP (Simple Network Management Protocol) is the primary transport for most of the aforementioned large tool suites. There are, however, simple point solution SNMP tools available, and we’ll offer suggestions regarding general SNMP usage.

Finally, in this chapter, we will close with a section on penetration testing. Penetration testing is a means of monitoring the state of security controls on your VoIP network. The primary reason for testing systems or networks is to identify potential vulnerabilities and subsequently repair them. Penetration Testing (Pen Testing) is an intelligent combination of automated and manual examinations that are launched from either inside or outside the perimeter of a private network. This testing emulates the threat from hackers and other parties, and their attempts to enumerate and compromise visible services.

Although we are not aware of production ready VoIP-specific NIDS, several are rumored to be in development. As a note: Based upon data gathered from historical analysis of call flows, anomaly detection, particularly in a call center setting where traffic is more defined than in an entire converged network, may prove to be an effective NIDS strategy.

MAC Tools | Minor Authentication Methods

A basic security rule is that endpoints cannot be trusted until the identity of the endpoint is confirmed, or authenticated. In the case of VoIP, a method for authentication of IP phones is the hardware or MAC address. The MAC (Media Access Control) address is a six-byte address that usually is represented as hex numbers in the form AA-BB-CC-DD-EE-FF or AA:BB:CC:DD:EE:FF. The first three bytes represent the vendor ID and the remaining three bytes form a unique address for any network connected device. There are potentially 2⁴⁸ or 281,474,976,710,656 possible MAC addresses. The Web site http://coffer.com/mac_find/ is useful for doing MAC/Vendor lookups.

MAC Authentication

If an IP phone with an unknown MAC address attempts to download a configuration from a registration server, then that device should not receive a configuration assuming automatic registration has been disabled. This setup prevents someone from placing a rogue phone or sniffer into the network, unless of course the person spoofs the MAC address in hopes of intercepting calls.

ARP Spoofing

ARP spoofing is an essential part of call interception. If an attacker cannot successfully meddle with the switchs ARP table then eavesdropping is virtually eliminated. Of course, unrestrained console access to a switch also offers the chance for call interception; however, appropriate physical security controls and good passwords will minimize this threat. 

Port Security

Since 802.1x is still an emerging technology, not all devices support it. Devices that do not support 802.1x can be controlled by Media Access Control (MAC) address authentication. Devices with static IP addresses that do not support 802. 1x (such as printers and some IP phones) can be accommodated by utilizing various port security commands without the use of 802.1x (different switch vendors have different names for these commands). These devices should also be placed into their own VLAN.

Certification Path | Public Key Infrastructure

If a public key user does not already hold a copy of the CA that signed the certificate including the CA’s name, then it might need an additional certificate to obtain that public key. A sample scenario appears in Figure 1. Let’s assume that Bob requested authentication from Alice with his certificate signed by CA1. But Alice, whose certificate was signed by CA2, does not have the public key for CA1, which is required to validate Bob’s certificate. Then, Alice forms a certificate chain that contains both CA2’s and her certificate and requests that CA1 provide a public key for CA1.

 
Figure 1: A Sample Certification Path

In general, a chain of multiple certificates might be needed that would make up a certificate containing the public key owner (the end entity) signed by one CA, and zero or more additional certificates originating from CAs signed by other CAs. Such chains, called certification paths, are required because a public key user is initialized with only a limited number of assured CA public keys. Certification path processing verifies the binding between the subject name and subject public key. This requires obtaining a sequence of certificates that support that binding.

Many organizations elect to create self-signed certificates for their public key infrastructure rather than purchase one or more from a Certificate Authority. In most cases, this is fine. However there are two differences between self-signed certificates and CA-signed certificates. SSL-enabled Web browsers normally recognize a CA-generated certificate and automatically allow a secure connection to be made, without prompting the user. Self-signed certificates usually generate an annoying (and sometimes to nontechnical users, frightening) pop-up. CAs also guarantee the identity of the organization that is providing services to the browser or other certificate-enabled device.

Before signing a certificate, a CA verifies the identity of the requesting organization. Thus, if your PKI is accessed by the public at large, you should provide a certificate signed by a CA so that people who visit or call know that your infrastructure is owned by the organization who claims to own it.

Basic Certificate Fields | Public Key Infrastructure

Basic certificate fields for X.509 version 3 are shown in Table 1. The To Be Signed (TBS) certificate field contains the names of the subject and issuer, a public key associated with the subject, a validity period, and other associated information. It usually includes extensions which hold additional optional information. The subject field identifies the entity associated with the public key stored in the subject public key field. It also distinguishes if a certificate is for an end entity, a CA, or a CRL. The Subject Public Key Info (SPKI) field is used to carry the public key and to identify the algorithm by which the key is used (e.g., RSA, DSA, or Diffie-Hellman).

Table 1: Basic Certificate Fields for X.509 

Certificate Fields	Attribute	Type
TBS Certif icate	Version	V1, v2, v3
	Certificate Serial Number	Integer
	Algorithm Id	Algorithm Object Id.
	Issuer	Name
	Validity	Not before time
		Not after time
	Subject	Name
	Subject Public Key Info	Algorithm Id
		Bit string
	Issuer Unique Id	Bit string
	Subject Unique Id	Bit string
	Extensions
Signature Algorithm		Algorithm Id
Signature Value		Bit string

The signature algorithm field contains the identifier for the cryptographic algorithm used by the CA to sign the certificate.

The signature value field contains a signature digitally added to the encoded TBS certificate. By generating this signature, a CA certifies the validity of the information in the TBS certificate. To be more specific, the CA certifies the binding between the public key material and the subject of the certificate.

Certificate Revocation List

When a certificate is issued, it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA (e.g., an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the certificate.

CRL is similar to notices of stolen or lost credit cards reported to other credit companies. The CA periodically issues a signed data structure called a CRL. A CRL is a time-stamped list identifying revoked certificates. The list is signed by a CA or CRL issuer and made freely available in a public certificate and CRL repository. Each revoked certificate is identified in a CRL by its certificate serial number. When a system employing certificates uses a certificate for verifying a remote user’s digital signature, that system not only checks the certificate signature and validity, but also acquires a recent CRL and checks that the certificate serial number is not on that CRL.