Which of the following categories of controls are firewalls intrusion detection systems and a Radius server classified as?

Firewalls and intrusion prevention systems

While there are many other security products available—some of which are highly relevant to industrial networks—none have been so broadly used to describe products with such highly differing sets of capabilities. The most basic “firewall” must be able to filter network traffic in at least one direction, based on at least one criterion, such as IP address or communication service port. A firewall may or may not also be able to track the “state” of a particular communication session, understanding what is a new “request” versus what is a “response” to a prior request.

A “deep packet inspection” (DPI) system is a device that can decode network traffic and look at the contents or payload of that traffic. Deep packet inspection is typically used by intrusion detection systems (IDS), intrusion prevention systems (IPS), advanced firewalls and many other specialized cyber security products to detect signs of attack. Intrusion Detection Systems can detect and alert, but do not block or reject bad traffic. Intrusion Prevention Systems can block traffic. Industrial networks support high availability making most general IPS appliances less common on critical networks; IPS is more often applied at upper-level networks where high availability (typically >99.99%) is not such a high priority. The result is that good advice can lead to inadequate results, simply through the use of overused terms when making recommendations.

Note

Most modern intrusion prevention systems can be used as intrusion detection systems by configuring the IPS to alert on threat detection, but not to drop traffic. Because of this the term “IPS” is now commonly used to refer to both IDS and IPS. One way to think about IDS and IPS is that an IPS device that is deployed in-line (a “bump in the wire”) is more capable of “preventing” an intrusion by dropping suspect packets, while an IPS deployed out-of-band (e.g. on a span port) can be thought of as an IDS, because it is monitoring mirrored network traffic, and can detect threats but is less able to prevent them. It may be the same make and model of network security device, but the way it is configured and deployed indicates whether it is a “passive” IDS or an “active” IPS.

Consider that the most basic definition of a firewall, given earlier, fails to provide the basic functionality recommended by NIST and other organizations, which advise filtering traffic on both the source and destination IP address and the associated service port, bidirectionally. At the same time, many modern firewalls are able to do much more—looking at whole application sessions rather than isolated network packets, by filtering application contents, and then enforcing filter rules that are sometimes highly complex. These unified threat management (UTM) appliances are becoming more common in protecting both industrial and business networks from today’s advanced threats. Deploying a “firewall” may be inadequate for some installations while highly capable at others, depending upon the specific capabilities of the “firewall” and the particular threat that it is designed to protect the underlying system against. The various network-based cyber security controls that are available and relevant to industrial networks are examined in detail in Chapter 10, “Implementing Security and Access Controls” and Chapter 11, “Exception, Anomaly and Threat Detection.”

Dangers of Protocol Tunneling

Protocol tunneling can explicitly bypass security restrictions. In that sense it poses a serious challenge to network security. Further, when coupled with encryption techniques like steganography it becomes nearly impossible to eliminate. The primary dangers posed by protocol tunneling are data exfiltration, hijacking, and enabling direct attacks.

Warning

“Deep packet inspection,” where security devices and software inspect the packets to determine what their payload really is, can detect many common forms of protocol tunneling. Of course, it is still possible to “leak” information out. Steganography is the practice of transmitting information in such a way that only the sender and recipient know that there was a transmission at all. Typically the hidden message is embedded in another, typical and unremarkable, message.

It is possible to use steganography to tunnel a protocol over otherwise typical transmissions. One can queue up the data to transmit, wait for outgoing messages, and transmit the tunneled traffic over this otherwise normal traffic. Deep packet inspection will determine this to be expected traffic.Z

You should be aware of protocol steganography, as it represents a serious threat for data exfiltration that is not adequately addressed by current technologies.

Data exfiltration is the most obvious malicious application of protocol tunneling. An insider can use protocol tunneling to transmit confidential information outside the company. A tunnel, once configured and established, can serve as a back door, or reverse-connect proxy, allowing subsequent intrusion.

Creating a tunnel entails other risks as well, even if the intent of the tunnel is not malicious. The tunnel can be hijacked, allowing an intruder to compromise security. In the incident described at the beginning of this chapter, the P2P protocol was exploited to gain unauthorized access to confidential information. Older versions of the SSH protocol are subject to hijacking by a kind of man-in-the-middle attack (the subject of Chapter 6, “Man-in-the-Middle”) called SSH injection. Nearly all protocols used on the Internet allow bidirectional data transfer; if people can use the tunnel to get out, others may use it to get in.

Finally, a tunnel may be created simply to enable other malicious technologies. Chapter 1, “Denial of Service,” explains how networks of compromised machines (“botnets”) can be managed using Internet relay chat (IRC), a simple communications protocol. Tunneling IRC over another protocol makes it more difficult to detect these botnets.

Every communications channel can be exploited to create a tunnel. Even one of the simplest Internet protocols, the ICMP echo/reply, also known as ping, can be exploited to create a tunnel.AA Many Windows machines set their clocks using a protocol known as Network Time Protocol (NTP). A single NTP packet contains four 64-bit timestamp fields, or 32 bytes total. Even though 32 bytes per packet is not a lot of bandwidth, if the message to be sent is small or suitably compressed an NTP tunnel may be sufficient.

Deep Packet Inspection

To address the limitations of Packet Filtering, Application Proxies, and Stateful Inspection, a technology known as Deep Packet Inspection (DPI) was developed (or marketed). DPI analyzes the entire packet, and may buffer, assemble, and inspect several related packets as part of a session. DPI operates at L3-L7 of the OSI stack.

DPI engines parse the entire IP packet, and make forwarding decisions by means of a rule-based logic that is based upon signature or regular expression matching. That is, they compare the data within a packet payload to a database of predefined attack signatures (a string of bytes). Additionally, statistical or historical algorithms may supplement static pattern matching.

The issue with DPI is that packet data contents are virtually unstructured compared with the highly structured packet headers (review the previous section on NAT for more details). Analysis of packet headers can be done economically since the locations of packet header fields are restricted by protocol standards. However, the payload contents are, for the most part, unconstrained. Searching through the payload for multiple string patterns within the datastream is a computationally expensive task. And as wire speeds increase, the requirement that these searches be performed at wire speed adds to the cost. Additionally, because the threat signature database is dynamic, it must be easily updateable—this rules out the use of normal ASICs. Promising approaches to these problems include a software-based approach (Snort implementing the Boyer-Moore algorithm) and a hardware-based approach (FPGAs running a Bloom filter algorithm).

Tools & Traps…

Deep Packet Inspection is a promising technology in that it may help to solve these problems. DPI engines are situated at network boundaries where bandwidth and security controls are logically implemented. New, programmable ASICs coupled with efficient algorithms can realistically parse the entire contents of each packet at gigabit speeds. Also, combining Firewall and IDS within a single device should simplify device configuration and management. But there are concerns as well.

One of the primary benefits of the traditional firewall/IDS deployment is that the failure of one component does not leave the network completely unprotected. Deploying devices with separate functionality also prevents being locked into a single solution and vendor.

Particular attention must be paid to firewall and deep packet inspection configurations to make sure they don’t introduce unacceptable latency. Implementation of some security measures can degrade QoS. These complications range from interruption or prevention of call setup by firewalls to encryption-produced latency and delay variation (jitter).

Limitations on matching resulting from security mechanisms

Note that the crux of the problem of deep packet inspection is the inability to make forwarding decisions based on fields that are not normally visible to the traditional packet switch. What we have presented thus far refers to fields that are in the packet payload, but the same problem can exist for certain packet header fields in the event that those fields are encrypted by some security mechanism. An example of this would be encrypting the entire payload of a layer two frame. Obviously, this obscures the layer three headers fields from inspection. This is not a problem for the traditional layer two switch which will make its forwarding decisions solely on the basis of the layer two header fields which are still in the clear. An Open SDN switch, on the other hand, would lose its ability to make fine-grained flow-based forwarding decisions using all of the twelve-tuple of packet header fields normally available as criteria. In this sense, such encryption renders normal header fields unavailable to the OpenFlow pipeline much like fields deep within the packet payload.

Restricting Network Connections

Complex firewall rules are unnecessary for web sites. Sites typically only require two ports for default HTTP and HTTPS connections, 80 and 443. The majority of attacks described in this book work over HTTP, effectively bypassing the restrictions enforced by a firewall. This doesn’t completely negate the utility of a firewall; it just puts into perspective where the firewall would be most and least effective.

A rule sure to reduce certain threats is to block outbound connections initiated by servers. Web servers by design always expect incoming connections. Outbound connections, even DNS queries, are strong indicators of suspicious activity. Hacking techniques use DNS to exfiltrate data or tunnel command channels. TCP connections might be anything from a remote file inclusion attack or outbound command shell.

Background

Applications such as network security, network monitoring, and load balancing require deep packet inspection capability which must be performed while maintaining high network data rates. Up until now, this capability has been supplied by dedicated hardware platforms called network appliances that come in a variety of form factors from single board products to modular ATCA chassis. These appliances traditionally use specialized processing chips shown in Figure 9.5.

Depending on the performance requirements, network appliance designers may choose standard CPUs, specialized CPUs called network processor units (NPUs), field programmable gate arrays (FPGAs), or custom designed application specific integrated circuits (ASICs). As can be seen in Figure 9.5, software development costs are higher for NPUs than CPUs due to their unique programming requirements. Both FPGAs and ASICs require extensive logic design and verification, while for the ultimate performance, ASICs also require several years of design and development and millions of dollars in non-recurring engineering (NRE) charges. Because of this, only the largest network equipment OEMs develop ASICs since they can spread the high NRE cost across large product volumes. Some network appliances use mixtures of these products, using the higher cost devices only where needed. For example, CPUs may be used for control plane functions, NPUs for layer 2-3 processing and FPGAs or ASICs for deep packet inspection. But in any case, network appliances are costly systems compared to systems using only standard CPU blades.

A couple of factors are now changing the way network appliance functions are implemented. For many process generations, CPU performance has been following Moore’s law and doubling in density every 18 months which has provided a significant improvement in performance. But NPUs and FPGAs have also kept pace with Moore’s law, constantly keeping them in the performance lead for these specific networking applications. Today CPUs have moved to multiple cores and have added some specialized hardware functions that are dramatically closing the gap. Because Ethernet bandwidth performance improvements and therefore the incoming packet rates are not moving at the same pace as processor performance improvements, standard CPUs are now starting to be used in packet processing applications traditionally reserved for NPUs or FPGAs.

Data center administrators require network security, monitoring, and load balancing functions throughout the data center and must constantly install and replace these specialized network appliances to meet their needs. If they could simply repurpose their existing server resources to supply these functions, they could quickly scale network functions based on demand using the software orchestration layer. This is the idea behind the new industry initiative called network function virtualization. Several companies, such as Intel, are behind these initiatives, using their latest multicore Intel® Xeon® processor line and Intel® Data Plane Development Kit (Intel DPDK) to provide network appliance features using standard server resources. We will next describe several key NFV applications that are important in the data center.

Network function virtualization

Network appliance is a generic term for a system that provides various networking services that require deep packet inspection and packet processing. Services may include firewall, intrusion detection, load balancing, network monitoring, VPN services, and WAN optimization. These are typically used in carrier networks or at the edge of data center networks and are built using either modular chassis or other rack-mounted form factors. Some of these services are moving into cloud data center networks and new ways of deploying these services are being developed.

Figure 4.12 shows a traditional modular network appliance with specialized processing blades containing expensive devices such as network processors and/or high-end FPGAs or ASICs.

As data comes into this system, it is distributed across these blades where deep packet inspection is used for applications such as firewalls, load balancing, and intrusion detection. Many of these systems are implemented in an ATCA platform which is an industry standard form factor for carrier networks. A handful of vendors supply specialized processing cards and switch modules that can be mixed and matched within the ATCA chassis. Specialized software must also be developed by these vendors for the unique CPUs, NPUs, or ASICs on these cards.

Data centers also utilize some of these applications for security and efficiency reasons. Firewalls and intrusion detection applications can be distributed throughout the data center to filter incoming data. Load balancing applications can be run within each rack to more efficiently utilize the server resources within the rack. Network monitoring applications can be used to test the health of the network and optimize traffic distribution. WAN optimization applications can be used at the edge of the network to efficiently transfer information between data centers.

A few industry trends are changing the way these applications are being implemented within the data center as data center administrators are attempting to homogenize their compute resources. Not only does this reduce acquisition costs by allowing the purchase of fewer products and higher volumes per product, it reduces maintenance costs and allows more efficient equipment utilization as data center needs change. Another trend is the use of server CPU resources for deep packet inspection applications that previously needed specialized devices such as NPUs due to high-bandwidth processing requirements. Today, multicore server class CPUs can also process these high-bandwidth flows.

Because of these trends, data center administrators are starting to implement these special network applications on standard virtualized servers within the data center as shown in Figure 4.12. This is known as network function virtualization (NFV). In this implementation, a vSwitch is used to move data between VMs within a server. A flow can come into the server, run through a firewall application running on one VM, an intrusion detection application running on another VM, and then be load balanced across other servers within the rack using a third VM, all within the same NFV server. A ToR switch can distribute the load across multiple NFV servers running in parallel in order to maximize bandwidth performance.

The use of standard servers for these applications provides a lot of flexibility for the data center administrator. For public cloud or IaaS services, various network functions can be offered to end customers on demand with little or no infrastructure change. As traffic loads within the data center change, NFV can be moved or expanded at different points within the data center, optimizing data center resource utilization. When combined with software defined networking, this provides a dynamic and agile way to deploy on-demand resources within cloud data center networks. We will provide further details on software defined networking in Chapter 9.

Payload inspection scenarios

Payload inspection is a very general term for accessing the payload of a packet. It is also referred to as deep packet inspection. Example scenarios where packet payloads are inspected on a network device are as follows.

Monitoring: Traffic monitoring is used to understand properties of the traffic aggregate (e.g., distribution of application layer protocol use in aggregate) or to track individual sources or connections (e.g., lawful interception of individual' digital communication). In the case of monitoring of aggregates, payload inspection may be used to determine what application layer protocol is used in a particular connection. In this case, the payload is scanned for particular strings that identify specific application layer protocols. In the case of lawful intercept, packet payloads are recorded and reassembled for forensic purposes.

Security: To protect end systems from malicious network traffic (e.g., hacking attacks, worms, viruses), network security devices inspect the payload of packets to identify suspicious patterns. These patterns can consist of specific strings (e.g., worm signature) or more general patterns (e.g., sequence of strings over multiple packets indicating a hacking attack).

Content blocking: Content blocking may be used by network providers to limit the exchange of data that infringes copyright, violates local laws, or is considered obscene. Similar to payload scanning for security-related patterns, packet payloads are inspected to determine if the packet content matches criteria of the search.

Quality of service: Certain types of network traffic may consume large amounts of networking resources (e.g., peer-to-peer file sharing). Therefore, network service providers may attempt to identify traffic from these sources and throttle their bandwidth consumption in the network. Payload inspection can be used to determine if packets belong to such traffic types.

Applications related to security and quality of service are discussed more in Chapter 10. We now discuss how specific strings and patterns can be found in packet payloads.

Symantec: General Specifications

Symantec's firewall/VPN products that are available at the time of this writing can be broken into three major categories, as shown in Table 3.6.

Table 3.6. Symantec Firewall/VPN Product Categories

Table 3.7 shows key features of Symantec's small/remote office firewall/VPN appliances at the time of this writing:

Table 3.7. Symantec Small/Remote Office Firewall/VPN Model-by-Model Comparison

Symantec's current enterprise gateway security appliances, at the time of this writing, comprise the 5400 series (SGS 5430, SGS 5440 and SGS 5460).Table 3.8 compares features of the three enterprise gateway security appliances.

Table 3.8. Symantec Enterprise Gateway Appliance Model-by-Model Comparison

Symantec markets two software packages that are designed to run on Windows NT/2000 or Solaris; these are the Symantec Enterprise Firewall and Symantec Enterprise VPN. The current version is 7.0 at the time of this writing. The Symantec Enterprise Firewall is ICSA certified.

This software is also the basis for the enterprise security gateway appliances. Symantec Enterprise Firewall 7.0 includes:

Hybrid architecture firewall

Deep packet inspection

Application proxy

Automated system hardening

Wide range of user authentication methods (RADIUS, LDAP, digital certificates, S/Key, Defender, SecureID, Windows domain authentication)

Integrated Web content filtering

Integrated load balancing

EAL-4 certification

AES support

NAT: both inbound and outbound for VPN and non-VPN traffic

WebNOT URL filtering

Symantec Enterprise VPN includes:

Support for IPSec VPNs; interoperates with other IPSec-compliant VPN clients and servers

Operates independently of firewall and integrates into networks with non-Symantec firewalls

One-step configuration and one-step connect

Remote centralized management for large scale deployments.

The cost of the Symantec firewall/VPN appliances for small or remote offices, at the time of this writing, is as follows:

The cost of the Symantec enterprise gateway security appliances, at the time of this writing, is shown in the following list. These prices are for a base license (50-node firewall, one client-to-gateway VPN session).

A base license is for a 50-node firewall, unlimited gateway-to-gateway VPN, and one client-to-gateway VPN session. The base license also includes one year of Gold Maintenance support service and content updates of virus definitions, attack signatures, and URL filtering via LiveUpdate.

The appliance itself contains all supported security features, but several of the security functions have to be licensed separately, including the following:

Optional Event Manager plug-in for centralized logging, alerting and reporting

Optional Advanced Manager plug-in (included Event Manager) for centralized management of rule sets and security policies

Optional high availability and load balancing

Optional enhanced anti-virus engine

Optional hybrid anomaly intrusion prevention and detection engine (real-time monitoring, detection and prevention using protocol anomaly detection and attack signatures)

Additional concurrent VPN sessions

13.8.1 Network-Based Application Recognition

Network-Based Application Recognition (NBAR) is a feature first available in Cisco IOS Software Release 12.0(5)XE2. NBAR provides specific and granular classification and protocol discovery for traffic transiting an IP router in a network infrastructure. NBAR can specifically recognize a wide variety of applications, such as Web-based and client/server applications—even those that dynamically assign TCP and UDP port numbers, which are generally problematic for identifying and classifying. Figure 13.64 gives an overview of NBAR in a network.

NBAR has the ability to execute protocol analysis in real time, giving some performance-monitoring capabilities particularly useful for network planning and troubleshooting. NBAR is capable of comparing traffic to a wide variety of known protocols and providing information on throughput.

According to the parameters defined in the “Performance Measurement Framework” section, Table 13.6 gives an overview of NBAR as a measurement tool.

Table 13.6. NBAR Performance Measurement Overview

NBAR may be activated for classification through CLI using a class map definition with match protocol <protocol-name>, where protocol-name is an NBAR-defined protocol. Enabling protocol discovery through CLI using ip nbar protocol-discovery in the interface configuration mode will also activate NBAR.

NBAR may also be activated by enabling AutoQoS, a new feature that combines protocol discovery with class-based traffic measurement to automatically generate QoS policies.

NBAR Protocol Support

NBAR is capable of classifying applications as follows:

•

Statically assigned TCP and UDP port numbers

•

Non-TCP and non-UDP IP protocols

•

Dynamic TCP and UDP port numbers assigned during protocol connection establishment

•

Classification based on deep packet inspection; NBAR can look deeper into the packet to identify applications

•

HTTP traffic by URL, hostname, header fields, or MIME type using regular expressions such as *, ?, [ ], Citrix ICA traffic, RTP payload type classification

•

Currently supports more than 90 protocols/applications

Figure 13.65 gives an overview of NBAR packet classification options.

Figure 13.65. NBAR Classification Overview

Note that not all protocols are shown in the figure. A more exhaustive list is shown in Figure 13.66.

Figure 13.66. NBAR Protocol Support List

New applications can be dynamically added by the network operator using a Packet Description Language Module (PDLM). In general, a Cisco IOS code upgrade or reboot is not required to add new PDLMs. Note that PDLMs must be produced by Cisco engineers.

PDLM is the heart of the NBAR engine. The Protocol Description Language (PDL) is part of the Cisco IOS image defining the baseline protocols supported in the code version. The baseline protocols can be viewed using the CLI command show ip nbar version. PDLM allows additional protocol support to be downloaded from CCO as required. These can be viewed using the CLI command show ip nbar pdlm.

There is no proactive notification of new PDLM, so to load a PDLM to a router, connect to the following URL: www.cisco.com/cgi-bin/tablebuild.pl/pdlm

NBAR Protocol Discovery

NBAR allows protocol discovery per interface, providing real-time statistics on applications per protocol, bidirectional statistics for bit rate (bps), packet counts, and byte counts.

NBAR allows traffic statistics collection for all protocols known to NBAR through PDL or PDLM. NBAR will discover application protocols transiting an interface, either input or output. NBAR can be applied independently of an SP applied through Modular QoS Configuration (MQC).

Figure 13.67 shows configuration of the NBAR protocol discovery and the subsequent output that can be expected.

Figure 13.67. NBAR Protocol Configuration and Output

SNMP may also be used for accessing NBAR protocol discovery data. The NBAR Protocol Discover MIB will automatically use all PDLMs available to build a statistics table. All protocols will be listed in the SNMP statistics table, with all 0s used to indicate no packets matching a given protocol. SNMP also allows the user to configure and view multiple “top-N” statistics tables listing protocols by bandwidth usage. The operator may also configure notifications when defined thresholds are crossed.

Table 13.7 shows supported tables in the NBAR Protocol Discovery MIB, with brief descriptions.

Table 13.7. NBAR Protocol Discovery MIB Tables

Table	Description	SNMP Access
cnpdSupportedProtocols	List of all supported protocols	Read-only
cnpdAllStats	All NBAR statistics per interface	Read-only
cnpdTopNstats	Top-N table statistics	Read-only
cnpdThresholdhistory	History of falling/rising events	Read-only
cnpdStatus	Enable or disable NBAR per interface, including time stamp	Read-write
cnpdTopNconfig	Configure top-N table by interface	Read-write
cnpdThresholdconfig	Protocol threshold configuration	Read-write
cnpdNotificationsconfig	Enable traps	Read-write
cnpdMIBNotifications	Rising or falling events	Read-write

Thresholds may be set on individual protocols on a specific interface or on a selected statistic, regardless of protocol type. Thresholds may also be set for any combination of supported protocols and/or all protocols as required, giving a flexible solution.

Notifications (traps) may be triggered based on these defined thresholds. SNMP notification is generated and sent with a summary of threshold information included in the trap. Hysterisis mechanism stops multiple traps occurring for the same breached threshold within a sample period.