IDS Types and Components

Intrusion detection was born in the 1980s when James Anderson put forth the concept in a paper titled “Computer Security Threat Monitoring and Surveillance.” IDSs can be divided into two broad categories: network-based IDS (NIDS) and host-based IDS (HIDS). Both types of systems can be configured to monitor for attacks, track a hacker’s movements, or alert an administrator to ongoing attacks. Most IDSs consist of more than one application or hardware device. IDSs are composed of the following parts:

• Network sensors: Detect and send data to the system

• Central monitoring system: Processes and analyzes data sent from sensors

• Report analysis: Offers information about how to counteract a specific event

• Database and storage components: Perform trend analysis and store the IP address and information about the attacker

• Response box: Inputs information from the previously listed components and forms an appropriate response

The key to what type of activity the IDS will detect depends on where the network sensors are placed. This requires some consideration because, after all, a sensor in the demilitarized zone (DMZ) will work well at detecting misuse there but will prove useless for detecting attackers who are inside the network. Even when you have determined where to place sensors, they still require specific tuning. Without specific tuning, the sensor will generate alerts for all traffic that matches a given criteria, regardless of whether the traffic is indeed something that should generate an alert.

Network-based IDSs and IPSs use several detection methodologies, such as the following:

• Pattern-matching and stateful pattern-matching recognition

• Protocol analysis

• Heuristic-based analysis

• Anomaly-based analysis

• Global threat correlation capabilities

An IDS must be trained to look for suspicious activity. Figure 9-1 details the relationship between IDSs and the types of responses they can produce.

Pattern Matching

Pattern matching is a methodology in which the intrusion detection device searches for a fixed sequence of bytes within the packets traversing the network. Generally, the pattern is aligned with a packet that is related to a specific service or, in particular, associated with a source and destination port. This approach reduces the amount of inspection made on every packet. However, it is limited to services and protocols that are associated with well-defined ports. Protocols that do not use any Layer 4 port information are not categorized. Examples of these protocols are Encapsulated Security Payload (ESP), Authentication Header (AH), and Generic Routing Encapsulation (GRE).

This tactic uses the concept of signatures. A signature is a set of conditions that match some type of intrusion occurrence. For example, if a specific TCP packet has a destination port of 1234 and its payload contains the string ff11ff22, a signature can be configured to detect that string and generate an alert.

Alternatively, the signature could include an explicit starting point and endpoint for inspection within the specific packet.

Here are some of the benefits of the plain pattern-matching technique:

• Direct correlation of an exploit

• Trigger alerts on the pattern specified

• Can be applied across different services and protocols

One of the main disadvantages is that pattern matching can lead to a considerably high rate of false positives, which are alerts that do not represent a genuine malicious activity. In contrast, any alterations to the attack can lead to overlooked events of real attacks, which are normally referred to as false negatives.

To address some of these limitations, a more refined method was created. This methodology is called stateful pattern-matching recognition. This process dictates that systems performing this type of signature analysis must consider the chronological order of packets in a TCP stream. In particular, they should judge and maintain a stateful inspection of such packets and flows.

Here are some of the advantages of stateful pattern-matching recognition:

• The capability to directly correlate a specific exploit within a given pattern

• Support for all non-encrypted IP protocols

Systems that perform stateful pattern matching keep track of the arrival order of non-encrypted packets and handle matching patterns across packet boundaries. However, stateful pattern-matching recognition shares some of the same restrictions as the simple pattern-matching methodology, which was discussed previously, including an uncertain rate of false positives and the possibility of some false negatives. Additionally, stateful pattern matching consumes more resources in the IPS device because it requires more memory and CPU processing.

Pattern matching (signature), protocol decoding, and anomaly detection are some of the basic characteristics and analysis methods used by an IDS.

Each type takes slightly different approaches to detecting intrusions. A graph showing the relationship of these types and the vendors that use each method is shown in Figure 9-2.

Anomaly detection systems require the administrator to make use of profiles of authorized activities or place the IDS into a learning mode so that it can learn what constitutes normal activity. A considerable amount of time needs to be dedicated to make sure that the IDS produces few false negatives. If an attacker can slowly change his activity over time, the IDS might actually be fooled into thinking that the new behavior is acceptable. Anomaly detection is good at spotting behavior that greatly differs from normal activity. For example, if a group of users who log in only during the day suddenly start trying to log in at 3 a.m., the IDS can trigger an alert that something is wrong.

Somewhere in the middle of the spectrum of intrusion detection is protocol decoding. Protocol-decoding IDSs can reassemble packets and look at higher-layer activity. In this type of detection, models are built on the TCP/IP protocols using their specifications. If the IDS knows the normal activity of the protocol, it can pick out abnormal activity. Protocol-decoding intrusion detection requires the IDS to maintain state information. For example, let’s look at the Domain Name System (DNS) service. DNS is a two-step process. Therefore, a protocol matching IDS can detect that when a number of DNS responses occur without a DNS request, a cache poisoning attack might be happening. To effectively detect these intrusions, an IDS must reimplement a variety of application layer protocols to detect suspicious or invalid behavior.

On the opposite end of the scale, there is pattern matching. Snort is a good example of a pattern-matching IDS. Pattern-matching IDSs rely on a database of known attacks. These known attacks are loaded into the system as signatures. As soon as the signatures are loaded into the IDS, the IDS can begin to guard the network. The signatures are usually given a number or name so that the administrator can easily identify an attack when it sets off an alert. Alerts can be triggered for fragmented IP packets, streams of SYN packets (denial of service [DoS]), or malformed Internet Control Message Protocol (ICMP) packets. The alert might be configured to change the firewall configuration, set off an alarm, or even contact the administrator. The biggest disadvantage to the pattern-matching system is that the IDS can trigger only on signatures that have been loaded. A new or obfuscated attack might go undetected. Obfuscated attacks are those that are disguised.

Protocol Analysis

Protocol analysis (or protocol decode-base signatures) is often referred to as an extension to stateful pattern recognition. A network-based intrusion detection system (NIDS) accomplishes protocol analysis by decoding all protocol or client-server conversations. The NIDS identifies the elements of the protocol and analyzes them while looking for an infringement. Some intrusion detection systems look at explicit protocol fields within the inspected packets. Others require more sophisticated techniques, such as examination of the length of a field within the protocol or the number of arguments. For example, in SMTP, the device may examine specific commands and fields such as HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT. This technique diminishes the possibility of encountering false positives if the protocol being analyzed is properly defined and enforced. On the other hand, the system can generate numerous false positives if the protocol definition is ambiguous or tolerates flexibility in its implementation.

Heuristic-Based Analysis

A different approach to network intrusion detection is to perform heuristic-based analysis. Heuristic scanning uses algorithmic logic from statistical analysis of the traffic passing through the network. Its tasks are CPU and resource intensive, so it is an important consideration while planning your deployment. Heuristic-based algorithms may require fine tuning to adapt to network traffic and minimize the possibility of false positives. For example, a system signature can generate an alarm if a range of ports is scanned on a particular host or network. The signature can also be orchestrated to restrict itself from specific types of packets (for example, TCP SYN packets). Heuristic-based signatures call for more tuning and modification to better respond to their distinctive network environment.

Anomaly-Based Analysis

A different practice keeps track of network traffic that diverges from “normal” behavioral patterns. This practice is called anomaly-based analysis. The limitation is that what is considered to be normal must be defined. Systems and applications whose behavior can be easily considered as normal could be classified as heuristic-based systems.

However, sometimes it is challenging to classify a specific behavior as normal or abnormal based on different factors, which include the following:

• Negotiated protocols and ports

• Specific application changes

• Changes in the architecture of the network

A variation of this type of analysis is profile-based detection. This allows systems to orchestrate their alarms on alterations in the way that other systems or end users interrelate on the network.

Another kind of anomaly-based detection is protocol-based detection. This scheme is related to, but not to be confused with, the protocol-decode method. The protocol-based detection technique depends on well-defined protocols, in contrast to the protocol-decode method, which classifies as an anomaly any unpredicted value or configuration within a field in the respective protocol. For example, a buffer overflow can be detected when specific strings are identified within the payload of the inspected IP packets.

Traditional IDS and IPS provide excellent application layer attack-detection capabilities. However, they do have a weakness. For example, they cannot detect DDoS attacks where the attacker uses valid packets. IDS and IPS devices are optimized for signature-based application layer attack detection. Another weakness is that these systems utilize specific signatures to identify malicious patterns. Yet, if a new threat appears on the network before a signature is created to identify the traffic, it could lead to false negatives. An attack for which there is no signature is called a zero-day attack.

Although some IPS devices do offer anomaly-based capabilities, which are required to detect such attacks, they need extensive manual tuning and have a major risk of generating false positives.

You can use more elaborate anomaly-based detection systems to mitigate DDoS attacks and zero-day outbreaks. Typically, an anomaly detection system monitors network traffic and alerts or reacts to any sudden increase in traffic and any other anomalies.

You can also use NetFlow or IPFIX as an anomaly detection tool. NetFlow and IPFIX are protocols that provides detailed reporting and monitoring of IP traffic flows through a network device, such as a router, switch, or a firewall.

Global Threat Correlation Capabilities

Next-generation IPS devices include global correlation capabilities that utilize real-world data from threat intelligence providers. These threat intelligence providers often leverage big-data analytics for cyber security and provide subscription services that can be integrated in different security products and solutions. Global correlation allows an IPS sensor to filter network traffic using the “reputation” of a packet’s source IP address. The reputation of an IP address is computed by the threat intelligence provider using the past actions of that IP address. IP reputation has been an effective means of predicting the trustworthiness of current and future behaviors from an IP address.

Snort

Snort is an open source IDS originally developed by Martin Roesch, and it is now maintained by the Snort team. It’s considered a lightweight, network-based IDS that can be set up on a Linux or Windows host.

The Snort official documentation can be obtained from https://www.snort.org/documents.

Snort operates as a network sniffer and logs activity that matches predefined signatures or rules. Signatures can be designed for a wide range of traffic, including Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP).

Snort rules can be downloaded from https://www.snort.org/downloads#rules, and they are made up of two basic parts:

• Rule header: This is where the rule’s actions are identified.

• Rule options: This is where the rule’s alert messages are identified.

Here is a sample rule:

Click here to view code image

Alert tcp any any -> any 80 (content: "hacker"; msg: "Hacker Site
   Accessed";)

The text up to the first parenthesis is the rule header. The first part is known as the rule action. Alert is the action used in the preceding sample rule; rule actions can include the following:

• Alert

• Log

• Pass

• Activate

• Dynamic

The next item is the protocol. In the example, TCP was used. After the protocol is the source address and mask. Although the example uses any any, it could have been a specific network, such as 10.10.0.0/16. This is followed by the target IP address and mask, which again can be specific or listed as any. The final entry of the rule header designates the port. This example specifies 80.

The section enclosed inside the parentheses specifies the rule options: content: “hacker”; msg: “Hacker Site Accessed”;. Rule options are not required but are usually the reason for creating the rule. The first portion specifies the action, which is to examine port 80 traffic for the word hacker. If a match occurs, a message should be generated that reads, “Hacker Site Accessed,” and the IDS would create a record that a hacker site might have been accessed. The rule option is where Snort has a lot of flexibility. Table 9-2 lists some common keywords Snort can use.

Although the CEH exam will not expect you to be a Snort expert, it is a good idea to have a basic understanding of how it works and to understand basic rules. A few of these rules are shown in Table 9-3.

Although these are good examples of basic Snort rules, they can be much more complex. For example, Snort can use the negation command. IP addresses can be negated with !. The following example of negation will match the IP address 4.2.2.2 and IP addresses from 2.2.2.0 to 2.2.2.255, with the exception of IPs 2.2.2.1 and 2.2.2.3:

Click here to view code image

4.2.2.2,2.2.2.0/24,![2.2.2.1,2.2.2.3]

Rules can also be used to reference CVEs. The following is an example of one developed to alert upon detection of the Microsoft Blaster worm:

Click here to view code image

alert tcp $EXTERNAL_NET any -> $HOME_NET 135
(msg:"NETBIOS DCERPCISystemActivator bind attempt";
low:to_server,established; content:"|05|";distance:0; within:1;
content:"|0b|"; distance:1; within:1;byte_test:1,&,1,0,relative;
content:"|A0 01 00 00 00 00 00 00 C0 00 00 00 00 00 00 46|";
distance:29; within:16;
reference:cve,CAN-2003-0352;classtype:attempted-admin; sid:2192;
rev:1;)

Building Snort rules is only half the work. After a Snort alert occurs, it is important to be able to analyze the signature output. To be able to determine what attackers are doing and how they are doing it, you should be able to perform signature analysis. The goal of the signature analysis is to identify malicious activity and track down the offender. This activity can be categorized as the following:

• Scans and enumeration

• Denial of service (DoS) attacks

• Exploits

If you have never used an IDS, you might be surprised at the number of alerts it produces in just a few hours after you connect to the Internet.

One of the best ways to get familiar with IDS systems like Snort is by using the Security Onion Linux Distribution that can be downloaded from https://securityonion.net. Security Onion is an open source Linux distribution that includes tools like Snort, Suricata, Bro, Wazuh, Sguil, Squert, CyberChef, NetworkMiner, Elasticsearch, Logstash, and Kibana. These tools allow you to deploy an intrusion detection and log management and visualization framework in just minutes.

Figure 9-3 shows the main “Events” dashboard of the tool called Squert (part of the Security Onion Linux distribution). In Figure 9-3 you can see several alerts generated by the Snort IDS related to different Trojan activities (including the Zeus trojan).

The Security Onion also comes Elasticsearch, Logstash, and Kibana (the ELK stack), which is a very powerful log management and visualization framework used by many organizations. Figure 9-4 shows the Kibana web interface displaying several network IDS (NIDS) logs generated by Snort. You can see alerts related to Trojan activity, as well as a potential corporate privacy violation.

Now, let’s look at some of the ways that hackers attempt to bypass IDS and prevent it from detecting their activities.

IDS Evasion

Attackers can use a range of techniques to attempt to prevent detection. These are discussed next.

Flooding

One of the most basic is to attempt to overload the IDS by flooding it with traffic. The attacker might even insert a number of low-priority IDS triggers to attempt to keep it busy while a few more-damaging attacks slip by. Generating such a huge amount of traffic forces the administrator to sort through all the data and somehow try to make sense of it. The real target and intent of the attacker might be totally lost within the blizzard of messages, beeps, and alerts generated. If the attacker knows the topology of the network, he might use a TTL attack against the IDS by breaking up the traffic into different fragments with varying TTLs. The idea is to force the IDS to pass some fragments when dropping others with a low TTL. Now let’s look at some other IDS evasion techniques.

Insertion and Evasion

An insertion attack occurs when an IDS accepts a packet that an end system rejects. For example, the attacker could send a series of one-character packets to the targeted system with varying TTLs so that some packets successfully reach the IDS but not the targeted system. The result would be that the targeted system and the IDS get two different character streams. With an evasion attack, the concept has been flipped so that the targeted system accepts a packet that the IDS rejects.

As an example of how evasion attacks are carried out, consider the following. An attacker sends in the first fragment of a fragmented packet to an IDS that has a fragmentation timeout of 15 seconds, while the target system has a timeout of 30 seconds. The attacker simply has to wait more than 15 seconds, but less than 30 seconds, to send the second fragment. When entering the network, the IDS discards the second fragment because the timeout parameter has already triggered the disposal of the first fragment. Upon delivery of the second fragment to the target, it accepts the second fragment because the first fragment is still held in scratch memory. The result is that the attack is successfully delivered to the targeted system and the IDS has no record of the attack. An insertion attack sends packets to an IDS and target device that will be accepted by the IDS and rejected by the target. The idea behind insertion and evasion attacks is to send different data streams to the IDS and the targeted system.

Session Splicing

Another technique to use against IDSs is to attempt session splicing. Session splicing works by delivering the payload over multiple packets, which defeats simple pattern matching without session reconstruction. This payload can be delivered in many manners and even be spread out over a long period. It is really a form of fragmentation. By breaking up the payload over many packets, many IDSs will fail to detect its true purpose. IP fragments usually arrive in the order sent, but they don’t have to. By sending the packets out of order and playing with fragment IDs, reassembly can become much more complicated. If the IDS cannot keep all fragments in memory for reassembling, an attacker could slip by. Tools such as Whisker and Nessus can implement session-splicing techniques.

Shellcode Attacks

Shellcode attacks are also possible against an IDS. Shellcode is simply a list of specific instructions that can be executed after the shellcode is injected into a running application. It’s called shellcode because it’s specifically designed to open and run a command shell. Polymorphic and ASCII are the two variations that an attacker can use. Polymorphic shellcode allows the attacker to vary the attack so that signature matching is not effective. For example, “x90x90x90x90”, “/bin/sh” is easily detectable by an IDS. However, if an attacker can use an encoder and cipher with the attack payload with a random key, it makes the changes hard for an IDS to detect. ASCII shellcode is similar to polymorphic shellcode except that ASCII shellcode uses only characters found in the ASCII standard. Shown here is an example:

Click here to view code image

char shellcode[] =
"LLLLYhb0!X5Yhbo!"
"HZTYRRRPTURWa-5lmm-2QQQ-8AAAfhRRfZ0p>0x?fh88fZ0p?fh"
"fZ0pS0pH0p?fh55fZ0p@fhbbfZ0pA0pBfhyyfZ0pAfhwwfZ0pE0pB"
"fhDDfZ0pCfhddfZ0pU0pDfhzzfZ0pW0pDfhuufZ0pEfhhhfZ0pJ0p"
"FfhoofZ0pF0pMfhccfZ0pV0pGfhiifZ0pGfh//fZ0pL0pM0pHfhss"
"fZ0pIfhmmfZ0pIfhaafZ0pJfhHHfZ0pKfhnnfZ0pLfheefZ0pR0pN"
"0pOfhttfZ0pO0pN0xPfhVVfZ0pP0xQfh((fZ0pQfhPPfZ0pQfhfff"
"Z0pRfhFFfZ0pS0xSfhIIfZ0pTfhssfZ0pT0xTfhOOfZ0pV0xVfh22"
"cM2KgmnJGgbinYshdvD9d"

Notice in the last line that bin sh has been highlighted. The idea is to hide the shellcode so that it is harder for the IDS to flag on the content. The result is that, when executed, this code would execute a bin/sh shell.

Other IDS Evasion Techniques

Some other techniques that can be used to evade IDSs include the following:

• False positives: Trigger a large number of false positives in an attempt to desensitize the victim.

• Obfuscation: The IDS can be evaded by obscuring the attack. Techniques may include Unicode, encryption, and ASCII shellcode. For example, an attacker might encode data via Unicode to avoid pattern matching and signature matching at the IDS.

• DoS: The attacker sends so much data that the IDS or central logging server is overloaded.

• Pre-connection SYN: This attack calls bind to get the kernel to assign a local port to the socket before calling connect.

• Post-connection SYN: This technique attempts to desynchronize the IDS from the sequence numbers that the kernel is honoring.

• Invalid RST: This technique sends RSTs with an invalid checksum in an attempt to force the IDS to stop capturing data.

Keep in mind that these are possible techniques and are not always guaranteed to work. For example, Snort employs a keyword to optimize rule matching on session data. The flow keyword allows us to specify if a session is established.

The established keyword works much like one would expect it to. Upon the completion of the three-way handshake, Snort creates an entry in a session-tracking table. Whenever Snort attempts to match a rule using the established keyword, it checks for an entry in this session table. If one exists, this portion of the rule matches. When Snort sees a graceful connection termination through the use of FIN packets or an abrupt termination through the use of RST, the entry is removed from this table.

If we could spoof an RST into the connection with a bad sequence number, might we be able to evade Snort? Let’s say that Snort is running using a single rule:

Click here to view code image

alert tcp any any -> any 6666 (sid:10;msg:"Session Data";
flow:established;classtype:not-suspicious;)

This rule will trigger on any packet from any host on sourcing from any port, going to any host on port 6666, provided the session is established. To test the rule, we type a character into a Telnet client connected on port 6666. Snort outputs the following:

Click here to view code image

06/09-12:01:02.684761 [**] [1:50:0] content data [**]
[Classification: Not Suspicious Traffic] [Priority: 3] {TCP}
0.10.1.42:4210 -> 10.10.1.9:6666

Now we execute the hping2 command to generate an RST packet with a bad sequence number. The syntax is as follows:

Click here to view code image

hping2 -c 1 -R -M 0 -L 0 -s 6666 -p 4210 10.10.1.42

And finally, we send another character via Telnet. Snort yields the following output:

Click here to view code image

06/09-12:04:28.672541[**] [1:50:0] content data [**]
[Classification: Not Suspicious Traffic] [Priority: 3] {TCP}
10.10.1.42:4210 -> 10.10.1.9:6666

Snort correctly handles the RST packet with an incorrect sequence number and does not allow the attack to progress. Hopefully, this drives home the point that one of the best ways for the attacker to bypass the IDS is from the inside out. If the attacker can establish an encrypted session from the victim going outbound to the attacker, this would result in one of the most effective evasion techniques. Some of the tools that can be used for this technique include Netcat, Loki, ICMPSend, and AckCmd.

IDS Evasion Tools

Several tools are available that can be used to evade IDSs. Most of these tools exploit one or more of the techniques discussed in the previous section. The better-known tools include the following:

• HTTP tunneling: Uses proxies, HTTP, or HTTPS to tunnel traffic from the inside out.

• ADMutate: Borrows ideas from virus writers to create a polymorphic buffer-overflow engine. An attacker feeds ADMutate a buffer-overflow exploit to generate hundreds or thousands of functionally equivalent exploits, but each has a slightly different signature.

• Mendax: Builds an arbitrary exploit from an input text file and develops a number of evasion techniques from the input. The restructured exploit is then sent to the target.

• NIDSbench: Includes fragrouter, tcpreplay, and idstest. Fragrouter fragments traffic, which might prevent the IDS from detecting its true content.

• Nessus: Can also be used to test IDSs and can perform session-splicing attacks.

IDSs are not perfect and cannot be expected to catch all attacks. Even when sensors are in the right location to detect attacks, a variety of tools and techniques are available to avoid detection. For IDSs to be effective, the individuals responsible for them must continually monitor and investigate network activity to stay on top of changes in hacking tools and techniques.

The CEH exam looks specifically at IDSs, but it’s also important to remember that outside the test environment, organizations can use many types of networks controls. These include intrusion prevention system (IPS), network access control (NAC), and even security information and event management (SIEM). It’s of upmost importance that an organization is tracking events and correlating these so attacks can be detected. One example tool is Kiki Syslog server. This type of syslog server can capture and correlate logs from a variety of sources such as syslog messages and SNMP traps. These can be forwarded to a single management console. Port 514 is the default port for Syslog. Look for these technologies to continue to blur into single solutions—so much so that NIST now uses the term intrusion detection prevention (IDP) to describe IDS and IPS blended solutions.

Firewall Types

Firewalls act as a chokepoint to limit and inspect traffic as it enters and exits the network. Although a number of variations or types of firewalls exist, there are several basic designs:

• Packet filters

• Application-level gateway

• Circuit-level gateway

• Stateful multilayer inspection

Let’s first take a quick look at Network Address Translation (NAT) and then discuss packet filters and other firewall technologies.

Network Address Translation

NAT was originally developed to address the growing need for more IPv4 addresses, and it is discussed in RFC 1631. NAT can be used to translate between private and public addresses. Private IP addresses are those that are considered unroutable, meaning that public Internet routers will not route traffic to or from them. RFC 1918 defines the three ranges of private addresses as

• 192.168.0.0–192.168.255.255

• 172.16.0.0–172.31.255.255

• 10.0.0.0–10.255.255.255

NAT enables a firewall or router to act as an agent between the Internet and the local network. The firewall or router enables a range of private addresses to be used inside the local network, whereas only a single unique IP address is required to represent this entire group of computers to the external world. NAT provides a somewhat limited amount of security because it can hide internal addresses from external systems—an example of security by obscurity. NAT can also be problematic because packets are rewritten; any application-level protocol such as IPsec that requires the use of true IP addresses might be harder to implement in a NATed environment.

Some unroutable addresses are known as bogus addresses or bogons. Bogons describe IP packets on the public Internet that claim to be from an area of the IP address space that is reserved but not yet allocated or delegated by the Internet Assigned Numbers Authority (IANA) or a delegated Regional Internet Registry (RIR).

Packet Filters

Packet filters were the first type of firewall to be used by many organizations around the world. The capability to implement packet filtering is built in to routers and is a natural fit with routers because they are the access point of the network. Packet filtering is configured through access control lists (ACLs). ACLs enable rule sets to be built that will allow or block traffic based on header information. As traffic passes through the router, each packet is compared to the rule set, and a decision is made whether the packet will be permitted or denied. For instance, a packet filter might permit web traffic on port 80 and block Telnet traffic on port 23. These two basic rules define the packet filter. A sample ACL with both permit and deny statements is shown here:

Click here to view code image

no access-list 111
access-list 111 permit tcp 192.168.13.0 0.0.0.255 any eq www
access-list 111 permit tcp 192.168.13.0 0.0.0.255 any eq ftp
access-list 111 deny udp any any eq netbios-ns
access-list 111 deny udp any any eq netbios-dgm
access-list 111 deny udp any any eq netbios-ss
access-list 111 deny tcp any any eq telnet
access-list 111 deny icmp any any
interface ethernet1
ip access-group 111 in

As this example shows, ACLs work with header information to make a permit or deny decision. ACLs can make permit or deny decisions on any of the following categories:

• Source IP address: Is it from a valid or allowed address?

• Destination IP address: Is this address allowed to receive packets from this device?

• Source port: Includes TCP, UDP, and ICMP.

• Destination port: Includes TCP, UDP, and ICMP.

• TCP flag: Includes SYN, FIN, ACK, and PSH.

• Protocol: Includes protocols such as FTP, Telnet, SMTP, HTTP, DNS, and POP3.

• Direction: Can allow or deny inbound or outbound traffic.

• Interface: Can be used to restrict only certain traffic on certain interfaces.

Although packet filters provide a good first level of protection, they are not perfect. They can filter on IP addresses but cannot prevent spoofing. They can also block specific ports and protocols but cannot inspect the payload of the packet. Most importantly, packet filters do not maintain connection state information. This inability to track the connection state is a critical vulnerability because it means that packet filters cannot tell whether a connection started inside or outside the organization.

Consider the following example: The organization allows outgoing initiated port 21 FTP traffic but blocks inbound initiated FTP traffic. If a hacker attempted a full connect scan on port 21 to an internal client, the scan would be blocked by the router. But what if the hacker crafted an ACK scan on port 21 to the same internal client? The answer is that it would go directly to the client because the router cannot keep state. It cannot distinguish one inbound FTP packet from another. Even when the scan was blocked, a router might still give up valuable information. That’s because when a packet filter receives a request for a port that isn’t authorized, the packet filter might reject the request or simply drop it. A rejected packet will generate an ICMP type 3 code 13, communication administratively prohibited. These messages are usually sent from a packet-filtering router and can indicate that an ACL is blocking traffic. It clearly identifies the router. The basic concepts of bypassing and identifying packet filters are shown in Figure 9-5.

After the hacker has mapped what ports and protocols are permitted or denied, a plan of attack can be devised. Hackers can use techniques such as port redirection to bypass the packet filter. Port redirection would allow a hacker to redirect a source port attack through an allowed port on the packet filter. The items discussed here should be enough for you to start to see that a packet filter by itself is insufficient network protection. Stateful inspection will be needed.

Application and Circuit-Level Gateways

Both of these firewall designs sit between a client and a web server and communicate with the server on behalf of the client. They stand in place of the other party and can be used to cache frequently accessed pages. Application and circuit gateways increase security and prevent direct access into or out of the network. Circuit-level gateways work at the session layer of the OSI model and can monitor TCP packets. Application layer firewalls can examine packets at the application layer. Application layer firewalls can also filter application-specific commands and can be configured as a web proxy.

Stateful Inspection

Stateful inspection firewalls are closely related to packet filters, except that they can track the status of a connection. For example, if an ACK packet arrives at the firewall that claims to be from an established connection, the stateful firewall would deny it if it did not have a record of the three-way handshake ever taking place. The packet filter would compare the packet to a rule set and blindly forward the packet. Stateful inspection accomplishes this valuable task by maintaining a state table that maintains the record of activity connections.

In reality, most organizations use a combination of firewall technologies, such as packet filters, proxy servers, and stateful inspection. Used together with a good network design, firewalls can be quite effective. The most commonly used design is that of a demilitarized zone (DMZ). A DMZ is a protected network that sits between the untrusted Internet and the trusted internal network. Servers deployed in the DMZ need to be hardened and made more secure than the average internal computer. These systems are called bastion hosts. A bastion host is built by stripping all unneeded services from the server and configuring it for a specific role, such as web or email.

Building secure hosts and using firewalls is not enough. The architecture of the network can also play a big role in the organization’s overall security. Some common designs used to secure networks are shown in Table 9-4.

Identifying Firewalls

Now that we have spent some time reviewing firewalls, let’s turn our attention to some of the ways that firewalls can be identified. This is an important topic for the ethical hacker because after an attacker has identified the firewall and its rule set, he can attempt to determine and exploit its weaknesses. The three primary methods of identification are as follows:

• Port scanning

• Firewalking

• Banner grabbing

Port scanning is one of the most popular tools used to identify firewalls and to attempt to determine the rule set. Many firewalls have specific ports open; knowledge of this can help you to identify them. Several examples of this are older products such as Microsoft Proxy Server, which has open ports on 1080 and 1745, NetGuard GuardianPro firewall, which listens on ports TCP 1500 and UDP 1501, and Check Point’s FireWall-1, which listens on 256, 257, and 258.

Traceroute can also be a useful tool. When used with Linux, traceroute has the -I option, which uses ICMP packets instead of UDP packets. Although it isn’t 100 percent reliable, it can help you see which hop is the last to respond and might enable you to deduce whether it is a firewall or packet filter. A snippet of output from trace-route is shown in the following example:

Click here to view code image

1    10 ms   <10 ms   <10 ms  192.168.123.254
2    10 ms    10 ms    20 ms  192.168.10.1
...
15    80 ms    50 ms    50 ms  10.1.1.50 client-gw.net
16      *           *          *      Request timed out.
17      *           *          *      Request timed out.

Hping is another useful tool for finding firewalls and identifying internal clients. It is especially useful because it allows you to do the same kind of testing; it can use not only ICMP and UDP but also TCP.

Hping can be used to traceroute hosts behind a firewall that blocks attempts using the standard traceroute utilities. Hping can also

• Perform idle scans

• Test firewall rules

• Test IDSs

Because Hping uses TCP, it can be used to verify if a host is up even if ICMP packets are being blocked. In many ways, Hping is similar to Netcat because it gives the hacker low-level control of the packet. The difference is that Netcat gives control of the data portion of the packet; Hping focuses on the header. This Linux-based tool can help probe and enumerate firewall settings. The following example shows Hping being used to attempt to evade the detection threshold of the firewall:

Click here to view code image

[root]#hping -I eth0 -S -a 192.168.123.175 -p 80 50.87.146.182 -i
   u1000

Click here to view code image

hping [ -hvnqVDzZ012WrfxykQbFSRPAUXYjJBuTG ] [ -c count ]
[ -i wait ] [ --fast ] [ -I interface ][ -9 signature ] [ -a host ]
[ -t ttl ] [ -N ip id ] [ -H ip protocol ] [ -g fragoff ] [ -m mtu ]
[ -o tos ] [ -C icmp type ] [ -K icmp code ] [ -s source port ]
[ -p[+][+] dest port ] [ -u end ] [ -O tcp offset ] [ -M tcp sequence number ]
[ -L tcp ack ] [ -d data size ] [ -E filename ] [ -e signature ]
[ --icmp-ipver version ] [ --icmp-iphlen length ] [ --icmp-iplen length ] [ --icmp-ipid id ] [ --icmp-ipproto protocol ]
[ --icmp-cksum checksum ] [ --icmp-ts ] [ --icmp-addr ]
[ --tcpexitcode ] [ --tcp-timestamp ] [ --tr-stop ] [ --tr-keep-ttl ]
[ --tr-no-rtt ]

Firewalking is the next firewall enumeration tool. Firewalk is a firewall discovery tool that works by crafting packets with a Time To Live (TTL) value set to expire one hop past the firewall. If the firewall allows the packet, it should forward the packet to the next hop, where the packet will expire and elicit an ICMP “TTL expired in transit” message. If the firewall does not allow the traffic, the packet should be dropped, and there should be no response or an ICMP “administratively prohibited” message should be returned. To use Firewalk, you need the IP address of the last known gateway before the firewall and the IP address of a host located behind the firewall. Results vary depending on the firewall; if the administrator blocks ICMP packets from leaving the network, the tool becomes ineffective.

Figure 9-6 shows an example of how firewalking works. In this example, the target is Router 3. It has been identified as the edge device. As such, the idea is to determine which ports router 3 allows and which ports it blocks. The Firewalk steps are as follows:

Step 1. Hopcount ramping: Firewalk sends out a series of packets toward the destination with TTL=1, 2, 3, and so on. When router 3 is reached, that determines the TTL for the next phase. In Figure 9-6, router 3 is at a TTL of 3, so all future packets will use TTL=4.

Step 2. Firewalking: TCP or UDP packets are sent from the source past router 3, and all packets have a TTL of 4. If a packet reaches the destination, an ICMP TTL type 11 message is generated. If router 3 blocks the ICMP packets, no response is returned.

Keep in mind that your actual results will vary depending on the firewall, how it is configured, and whether the administrator blocks ICMP messages from leaving the network.

Banner grabbing is one of the most well-known and well-used types of enumeration. The information generated through banner grabbing can enhance the hacker’s effort to further compromise the targeted network. The three main services that send out banners include FTP, Telnet, and web services. No specialized tools are needed for this attack. Just telnet to the IP address of the address and specify the port. Here is an example with an older Eagle Raptor firewall:

Click here to view code image

telnet 192.168.13.254 21
(unknown) [192.168.13.254] 21 (21) open
220 Secure Gateway FTP server ready

If the firewall you are enumerating happens to be a Cisco router, there’s always the chance that a Telnet or Secure Shell (SSH) port has been left open for out-of-band management. Most Cisco routers have five terminal lines, so telnetting to one of those might provide additional identifying details:

Click here to view code image

[root@mg /root]# telnet 192.168.13.1
Trying 192.168.13.1...
Connected to 192.168.13.1
Escape character is '^]'.
Your connected to router1
User Access Verification
Username:

Telnet isn’t secure. Besides username password guessing, it’s also vulnerable to sniffing. If you have no choice but to use Telnet for out-of-band management, you will at a minimum want to add an access list to restrict who can access the virtual terminal (vty) lines. Web servers and email servers are also available to banner grabbing. Simply telnet to the web server address followed by the port and press Enter a couple of times. You will most likely be rewarded with the web server’s banner.

Bypassing Firewalls

Unfortunately, there is no secret technique to bypass every firewall that you’ll encounter during your ethical hacking career. Firewalls can be defeated because of misconfiguration or liberal ACLs. Attackers can also attempt to hide or obscure information at many layers of the TCP/IP model. A variety of tunneling techniques can be used to make malicious traffic look like normal network packets.

The Internet layer offers several opportunities for hackers to tunnel traffic. Two commonly tunneled protocols are IPv6 and ICMP. IPv6, like all protocols, can be abused or manipulated to bypass firewalls because it is possible that firewalls and IDSs may not be configured to recognize IPv6 traffic, even though most every operating system has support for IPv6 turned on. According to US-CERT, Windows misuse relies on several factors:

• Incomplete or inconsistent support for IPv6

• The IPv6 auto-configuration capability

• Malicious application of traffic “tunneling,” a method of Internet data transmission in which the public Internet is used to relay private network data

The second Internet layer protocol that might be used to bypass firewalls is ICMP. ICMP is specified by RFC 792 and is designed to provide support for logical errors and diagnostics. The most common ICMP message is the ping command, which uses ICMP type 8/0 messages to test connectivity. Some of the fields of the ICMP ping packet header include Type, Code, Identifier, and Optional Data. Proof-of-concept tools for tunneling over ICMP include ICMPSend and Loki. To prevent data exfiltration via ICMP, the ethical hacker should verify that inbound ICMP traffic is blocked.

The transport layer offers more opportunities for attackers to bypass firewalls. These attacks focus on TCP and UDP. TCP offers several fields that can be manipulated by an attacker, including the TCP Options field in the TCP header and the TCP Flag field. For example, although SYN packets occur only at the beginning of the session, ACKs may occur thousands of times. That is why packet-filtering devices build their rules on SYN segments. It is an assumption on the firewall administrator’s part that ACKs occur only as part of an established session. As such, TCP ACK packets can be used to bypass packet filters and stateless firewalls. Tools such as AckCmd serve this exact purpose. AckCmd provides a command shell on Windows systems. It communicates using only TCP ACK segments. This way, the client component is capable of directly contacting the server component through routers with ACLs in place to block traffic. The AckCmd tool can be downloaded from http://www.ntsecurity.nu/toolbox/ackcmd.

UDP is stateless and, as such, may not be logged in firewall connections; some UDP-based applications, such as DNS, are typically allowed through the firewall and may not be watched closely by firewalls and IDSs. Some ports, such as UDP 53, are most likely open where DNS can function. This means it’s also open for attackers to use as a potential means to bypass firewalls. There are several UDP tunnel tools, such as Iodine and UDPTunnel.

Application layer tunneling offers attackers yet another means to bypass firewalls. For example, an attacker might tunnel a web session, port 80, through SSH port 22. This could easily be possible because SSH is often allowed through firewalls and edge devices. Because SSH is encrypted, it can be difficult to monitor the difference between a legitimate SSH session and a covert tunnel used by an attacker to send data out of your network.

HTTP can also be used to tunnel traffic. It is widely available, and connections that initiate from the inside of your network may not be examined closely. Netcat is one tool that can be used to set up a tunnel to exfiltrate data over HTTP. Finally, there is HTTP over SSL (HTTPS). In some ways, this may be even easier for an attacker to use. Take a moment to consider that HTTPS traffic is encrypted and thus is not easily monitored. Although the source and destination IP addresses of the session are visible, consider the example of an attacker using a trusted internal IP address that is communicating with a trusted external IP address. Cryptcat (https://sourceforge.net/projects/cryptcat/) can be used for this activity. Attackers can also set up a Secure Sockets Layer (SSL) tunnel with stunnel or launch a browser with HTTPS and let the browser handle the SSL negotiation and encryption.

These are not the only options available to attackers. After all, firewalls cannot prevent any of the following attacks:

• Attack from secondary connections: Hackers that can bypass the firewall and gain access through an unsecured wireless access point or through an employee’s remote connection render the firewall useless.

• Use proxy servers: Proxy servers can be used to bypass firewall restrictions.

• Tunnel traffic: Use techniques such as anonymizers, third-party sites, and encryption.

• Social engineering: Firewalls cannot protect against social engineering attacks.

• Physical security: If the hacker can just walk in and take what he wants, the firewall will be of little use even if it is properly configured.

• Poor policy or misconfiguration: It sounds like an oxymoron: “You cannot deny what you permit.” If the firewall is not configured properly or wasn’t built around the concept of denying all, there’s the real chance that the hacker can use what’s available to tunnel his way in.

• Insider misuse or internal hacking: Firewalls are usually located at the edge of the network and therefore cannot prevent attacks that originate inside the network perimeter.

It is possible for attackers to go from the inside out and to hide their activities in many ways. From the inside out means to get something planted on an internal system and have it connect out to the attacker. One way is to obscure the target addresses in URLs so that they can bypass filters or other application defenses that have been put in place to block specific IP addresses. It is important to log activity to a syslog server or other logging service so abnormal activities can be tracked. It’s also important to ensure that all systems have their time synchronized so that a timeline of attacker activities can be reconstructed should an attack be detected.

Although web browsers recognize URLs that contain hexadecimal or binary character representations, some web-filtering applications don’t. Here is an example of an encoded binary IP address: http://8812120797/. Does it look confusing? This decimal address can be converted into a human-readable IP address. Convert the address into hexadecimal, divide it into four sets of two digits, and finally convert each set back into decimal to recover the IP address manually.

To convert an IP address to its binary equivalent, perform the following steps.

Step 1. Convert each number in the IP address to its binary equivalent. Let’s say that the address is 192.168.13.10:

192 = 11000000

168 = 10101000

13 = 00001101

10 = 00001010

Step 2. Combine the four 8-digit numbers into one 32-digit binary number. The previous example produces

11000000101010000000110100001010.

Step 3. Convert the 32-bit number back to a decimal number. The example yields 3232238858.

Step 4. Entering http://3232238858 into the address field takes you to 192.168.12.10.

Trivial FTP (TFTP) can be another useful tool for hacking firewalls. While scanning UDP ports, you want to pay close attention to systems with port 69 open. Cisco routers allow the use of TFTP in conjunction with network servers to read and write configuration files. The configuration files are updated whenever a router configuration is changed. If you can identify TFTP, there is a good chance that you can access the configuration file and download it. Here are the basic steps:

Step 1. Determine the router’s IP; nslookup or ping -a can be useful:

Click here to view code image

C: >ping -a 192.168.13.1
Pinging Router1 [192.168.13.1] with 32 bytes of data:
Reply from 192.168.13.1: bytes=32 time<10ms TTL=255
Reply from 192.168.13.1: bytes=32 time<10ms TTL=255
Reply from 192.168.13.1: bytes=32 time<10ms TTL=255
Reply from 192.168.13.1: bytes=32 time<10ms TTL=255
Ping statistics for 192.168.13.1:
          Packets: Sent = 4, Received = 4, Lost = 0 (0%
            loss),
Approximate round trip times in milli-seconds:
          Minimum = 0ms, Maximum =  0ms, Average =  0ms

Step 2. After the router’s name is known, you can then use TFTP to download it from the TFTP server:

Click here to view code image

C: >tftp -i 192.168.13.1 GET router1.cfg
Transfer successful: 250 bytes in 1 second, 250 bytes/s

Step 3. If you’re lucky, you will be rewarded with the router’s configuration file.

Legacy Cisco routers store passwords in configuration files saved in one of three forms:

• Clear text

• Vigenere

• MD5

Clear text requires little explanation. Vigenere provides only weak encryption. A host of tools are available to break it, including Cain. Many Vigenere-cracking tools are also available online. One is available at http://www.ifm.net.nz/cookbooks/passwordcracker.html. Just take the password that follows the password 7 string in the configuration file and plug it into the tool. Figure 9-7 shows an example.

Since Cisco IOS Release 15.2(2)E, you can enable global AES encryption for all router passwords using the passwd encryption command in global configuration mode. Doing so mitigates the password attack previously described.

Firewalls are also vulnerable if the hacker can load a Trojan or tool on an internal client. Most firewall rules are much more restrictive going into the network. If the hacker has an accomplice inside or can trick a user into loading a Trojan, he can use this foothold to tunnel traffic out on an allowed port. Figure 9-8 shows an example of this, where the hacker has tricked an internal user into running Netcat on the victim’s system. Netcat uses the existing outbound port of 80 to connect to the hacker’s system.

Types of Honeypots

Honeypots can be both low and high interaction. Low-interaction honeypots work by emulating services and programs that would be found on an individual’s system. If the attacker does something that the emulation does not expect, the honeypot will generate an error. For example, consider the following command:

nc -v -l -p 80

If you were to scan the system that I had this Netcat command running on, the port would show as open. But what if you attempted to grab a banner with Telnet, HTTPPrint, or any other banner-grabbing tool? There would be no response because Netcat would not return a banner. This is a good example of a low- interaction honeypot.

High-interaction systems perfectly emulate a system or network of computers. The idea is to have a controlled area in which the attackers can interact with what appear to be real applications and programs. High-interaction honeypots rely on the border devices to control traffic so that attackers can get in, but outbound activity is tightly controlled.

A variety of honeypot types are available; some are commercial products, and others are open source. The following is a partial list of some of these honeypots:

• KFSensor

• NetBait

• PatriotBox

• Specter

• BackOfficer Friendly

• LaBrea Tarpit

• Honeyd

• Tiny Honeypot

Honeypots such as LaBrea Tarpit are examples of black holes. These sticky honeypots are built explicitly to slow down or prevent malicious activity. LaBrea Tarpit can run on a Windows computer.

Detecting Honeypots

There are some items to consider before setting up and running a honeypot. One is that the attacker will break free of the honeypot and use it to attack other systems. There is also a certain amount of time and effort that has to be put into setting up, configuring, and monitoring the honeypot. When added to the already busy day of the security administrator, honeypots add another item in a long list of duties she must attend to. One of the biggest concerns is that the attacker might figure out that the honeypot is not a real target of interest and quickly turn his interest elsewhere. Any defensive mechanism must be measured by the cost to install, configure, and maintain versus the number of benefits the system will provide.

Attackers can attempt to determine that a honeypot is not a real system by probing the services. For example, an attacker might probe port 443 and see that it is open. However, if an SSL handshake is attempted, how will the honeypot respond? Remember that some protocols go through a handshake procedure. A low-interaction honeypot might only report the port as open but not have the capability to complete the proper handshake process. For example, during the SSL connection, the client and server exchange credentials and negotiate the security parameters. If the client accepts the server’s credentials, a master secret is established and used to encrypt all subsequent communications. Tools that can probe honeypots include the following:

• THC-Amap

• Send-Safe Honeypot Hunter

• Hping

• Nessus

All of these can be used to probe targets to help determine whether they are real. Nessus, one of the tools listed previously in the section “IDS Evasion Tools,” can craft the proper SSL response so that it can probe services such as HTTP over SSL (HTTPS), SMTP over SSL (SMPTS), and IMAP over SSL (IMAPS).