Cisco Firewall with Cisco IPS

We are constantly under pressure to ensure mission-critical systems are thoroughly safe from bad actors that will try to penetrate your network and attack critical services with a range of attack vectors. So we need to create a reliable way to detect and prevent intruders. Adopting a threat-centric network security approach with the Cisco intrusion prevention system is viable. The Cisco IPS is an engine based on Cisco Snort that is an integral part of the Cisco Firewall, specifically, the Cisco Secure Firewall.

Firewalls have been around for decades and come in various sizes and flavors. The most typical idea of a firewall is a dedicated system or appliance that sits in the network and segments an “internal” network from the “external” Internet. With the traditional Layer 3 firewall, we have baseline capabilities that generally revolve around the inside being good and the outside it bad. However, we must move from just meeting our internal requirements to meeting the dynamic threat landscape in which the bad actors are evolving. We have Malware, social engineering, supply chain attacks, advanced persistent threats, denial of service, and various man-in-the-middle attacks. And nothing inside the network should be considered safe. So we must look beyond Layer 3 and incorporate multiple security technologies into firewalling.

So we have the standard firewall that can prevent some of these attacks, but we need to layer on additional capabilities to its baseline. Hence, we have a better chance of detection and prevention. Some of these technologies that we layer on are provided by Cisco Snort, which enables the Cisco intrusion prevention system ( Cisco IPS ) included in the Cisco Firewall solution that we will discuss in this post.

Before you proceed, you may find the following posts helpful for pre-information:

1. Cisco Secure Firewall
2. WAN Design Considerations
3. Routing Convergence
4. Distributed Firewalls
5. IDS IPS Azure

• A key point: Back to basics with Intrusion Detection.

An intrusion detection system (IDS) can assist in detecting intrusions and intrusion attempts within your network, allowing you to take suitable mitigation and remediation steps. However, remember that a pure IDS will not prevent these attacks but will let you know when they occur. So they can fix half of the puzzle. An IDS will parse and interpret network traffic and host activities. This data can vary from network packet analysis to the contents of log files from routers, firewalls, and servers, local system logs, access calls, and network flow data, to name a few.

Likewise, an IDS often stores a database of known attack signatures and can compare patterns of activity, traffic, or behavior it sees in the data it’s monitoring against those signatures to recognize when a close match between a signature and current or recent behavior occurs. It is possible to distinguish IDSes by the types of activities, traffic, transactions, or systems they monitor. For example, IDSes that monitor network links and backbones looking for attack signatures are called network-based IDSes. In contrast, those that operate on hosts and defend and monitor the operating and file systems for signs of intrusion are called host-based IDSes.

Cisco Firewall

The Cisco Firewall is a next-generation firewall that provides several compelling threat detection and prevention technologies to the security professional’s toolbox. The Cisco Firewall solution is more than just Firewall Threat Detection (FTD). We have several components that make up the security solution. Firstly, we have the Firewall Management Center (FMC), which is the device that gives you the GUI and configures the policy and operational activities for the FTD. We also include several services.

Around Malware, we have two key pieces. First, the Cisco Secure Endpoint cloud is a database of known bad and good files and maintains a file hash for all those entries. So as files pass through the firewall, they can decide on known files. These hashes can be calculated at the line rate, and the Cisco firewall can do quick lookups. This allows you to hold the last packet of the file and get a determination: good, bad, or unknown.

So if you like, we can make a policy by checking the hash. However, you can extract the file if you have not seen it before, and it can be submitted to Cisco Secure Malware analytics. This is a sandbox technology. The potentially bad file is placed in a VM-type world, and we can get a report with a score sent back. So this is a detection phase and not prevention, as it can take around 15 mins to get the score sent back to us.

These results can then be fed back into the Cisco Secure Endpoint cloud. Now everyone, including other organizations that have signed up to the Cisco Secure Endpoint cloud, can block this file that is seen in just one place. So no data is shared; it’s just the hash. Also, Talos Intel. This is the research organization’s secret source, with over 250 highly skilled researchers. It can provide intelligence such as Indicator of Compromise (IoC), bad domains, and signatures looking for exploits. And this feeds all security products.

Cisco IPS

So we need a bunch of network security technologies that can work together. First, we need a Cisco IPS that provides protocol-aware deep packet inspection and detection that Cisco Snort can provide, which we will discuss soon. So you also need a list of bad IPs, Domains, and file hashes that allow you to tune your policy based on these. For example, for networks that are the source of spam, you want a different response from networks known to host the bad actors C&C.

Also, for URL filtering. When you think about URL filtering, we think about content filtering in the sense that users should not access specific sites from work. However, the URL is valuable from a security and threat perspective. Often, transport is only over HTTP, DNS is constantly changing, and the bad actors rely only on a URL to connect to, for example, a C&C. So this is a threat intelligence area that can’t be overlooked.

We also need to look at file hashing and run engines on the firewall that can identify Malware without sending it to the cloud for checking. Finally, it would help if you also had real-time network awareness and indicators of compromise. The Cisco Firewall can watch all traffic, and you tell us that here are the networks that this firewall protects, and these are the top talkers. Potentially to notice any abnormal behavior.

Cisco Snort

This is where Cisco Snort comes to play. Snort can carry out more or less all of the above with its pluggable architecture. More specifically, Snort 3. Cisco now develops and maintains Snort, known as Cisco Snort. Snort an open-source network intrusion prevention system. In its most straightforward terms, Snort monitors network traffic, examining each packet closely to detect a harmful payload or suspicious anomalies.

Cisco Snort can perform real-time traffic analysis and packet logging as an open-source prevention system. So the same engine runs in the commercial product as in the open-source development. The open-source core engine has over 5 million downloads and 500,000 registered users. Snort is a leader in its field. Before the Cisco IPS team got their hands on it, Snort was released in 1998, and the program was meant to be a packet logger. You can still download the first version. It has come a long way since then. So Snort is so much more than a Cisco IPS.

In reality, Snort is a flexible high-performance packet processing engine. And the latest version of Snort 3 is pluggable, so you can add modules to make it adaptable to cover different security aspects. Snort 2 to Snort 3 takes two years to evolve. With the release of 7, Cisco Secure Firewall Threat Defence introduced Snort 3 on FMC-managed devices. Now we can have a Snort 3 filter with the Cisco Firewall, rule groups, and rule recommendations. These combined will help you use the Cisco firewall better to improve your security posture.

Snort 2

So we started with Snort 2, even though Snort 3 has been out for a few years. Sort 2 has 4 primaries or, let’s say, essential components:

1. It starts with the decoder. So this is where some minor decoding is performed once the packers are pulled off the wire. This is what you might see with TCPDump.
2. Then we have the pre-processor, which is the secret sauce of Snort 2. These are responsible for the normalization and assembly. Their primary role is to present data to the next component, the detection agent.
3. The detection engine is where the Snort rules are, and this is where we process the rules against the traffic to observe. 
4. Log module. Based on the rules on traffic, if something is found, we have a log module enabling you to create a unified alert.

• A key point: Snort Rule tree

When Snort looks like a rule set, it doesn’t start at the top and run a packet through; it breaks it up into what is known as rule trees based on, for example, source port or destination port. So when it comes to a rule to evaluate a packet, a packet only goes through a few rules. So, Cisco Snort, which provides the Cisco IPS for the Cisco Firewall, is efficient because it only needs to enable packets through the rules it might be appropriate for.

• A key point: Knowledge check for Packet Sniffing

Capturing network traffic is often a task during a penetration testing engagement or while participating in a bug bounty. One of the most popular packet capture tools (sniffer) is Wireshark. If you are familiar with Linux, you know about another lightweight but powerful packet-capturing tool called tcpdump. The packet-sniffing process involves a cooperative effort between software and hardware. This process can be broken down into three steps:

Collection: The packet sniffer collects raw binary data from the wire. Generally, this is accomplished by switching the selected network interface into promiscuous mode. In this mode, the network card can listen to all traffic on a network segment, not only the traffic addressed.

Conversion: The captured binary data is converted into a readable form. This is as far as most developed command line packet sniffers can go. The network data can be interpreted fundamentally at this point, leaving most of the analysis to the end user.

Analysis: Finally, the packet sniffer analyzes the captured and converted data. The sniffer verifies the protocol of the captured network data based on the information extracted and begins its analysis of that protocol’s distinguishing features.

Snort 3

Then we have a new edition of Cisco IPS. Snort 3.0 is an updated version of the Snort with a unique design and a superset of Snort 2. Snort 3 includes additional functionality that improves efficacy, performance, scalability, usability, and extensibility. In addition, snort 3 aimed to address some of the limitations of Snort 2. For example, snort 2 is packet-based, so it’s a packet sniffer per packet. So it would help if you built in statefulness and awareness of fragments and the fact that HTTP GET’s boundaries are not packet boundaries, which can spread over multiple packets.

• A key point: HTTP Protocol Analyzer

Snort 3 has a good HTTP protocol analyzer that can detect HTTP running over any port. Many IPS providers only look at 80, 8080, and 442. But HTTP over any other port than the other IPS, other than the Cisco IPS, assumes it is TCP. However, based on Cisco Snort, Cisco IPS can detect HTTP over any port. Now that it knows HTTP, Snort can’t set up different pointers in the other parts of the packet. So when you get to the IPS rules section looking for patterns, you don’t need to do the lookup and calculation again, which is essential when you are going at a line rate.

• A key point: Snort is pluggable

Also, within the Cisco firewall, Cisco Snort is pluggable and does much more than protocol analysis. It can perform additional security functions and make network discovery, a type of passive detection. Along with advanced malware protection and application identification, not by ports and protocols but by doing deep packet inspection. Now you can have a policy based on the application. There is also an identity engine that can also map users to IP, allowing identity-based firewalling. So Cisco Snort does much of the heavy lifting for the Cisco Firewall.

Snort 2 architecture: The issues

Snort 3 has a modern architecture for handling all of the Snort 2 packet-based evasions. It also supports HTTP/2, whereas Snort 2 only supports HTTP/1. The process architecture is the most meaningful difference between Snort 2 and Snort 3. So to go faster in Snort 2, you put more Snorts running on the box. So a connection arrives and is hashed based on a 5-tuple or a 6-tuple, depending on the product. I believe 5-tuple for the open-source and 6-tuple for the actual commercial product.

Connections on the same hash go to the same CPU. So to improve Snort 2 performance, if you had a single CPU on a box, you add another Snort CPU and get double the performance with no overhead. Snort 2 works with multiple Snort processes, each affiliated with an individual CPU core, and within each Snort process, there is a separate thread for management and data handling.

But we are loading Snorts over and over again. So we have linear scalability, which is good, but duplicated memory structure is bad. So every time we load Cisco Snort, we load the rules, and everything runs in their isolated world.

Snort 3 architecture: Resolving the issues

On the other hand, Snort 3 is multi-threaded, unlike Snort 2. This means we have one control thread and multiple packet threads. So the packet arrives at the control thread, and we have the same connection hashing with 5-tuple or 6-tuple. Snort 3 only runs on one process, with each thread affiliated with individual CPU cores, backed by one control thread that handles data for all packet-processing threads. The connections are still pinned to the core, but they are packet threads, and each one of these packet threads is running on its CPU, but they share the control thread, and this shares the rules. 

The new Snort 3 architecture eliminates the need for a control thread per process and facilitates configuration/data sharing among all threads. As a result, less overhead is required to orchestrate the collaboration among packet-processing threads. So we get better memory utilization, and reloads are much faster.

Snort 3 inspectors

Snort 3 has inspectors now. In Snort 2, we had pre-processors. So we have an HTTP inspector instead of a pre-processor. So packets are processed differently in Snort 3 than in Snort 2. So in Snort 2, the packet comes linearly in specific steps. This was done with a preprocessing stage. So, what has to happen is that the packet has to go through, and every field of the packet will be decoded, and if this is HTTP, they will look at the GET, the body, and the header, for example. All of this will be decoded in case a rule needs that data. In the case of RPC, there are so many fields in an RPC packet. So it could decode fields in the packet that a rule never needs. So you need to save time in decoding the data.

Parallel resource utilization

On the other hand, Snort 3 uses what is known as parallel resource utilization. So in the packet inspection process, we have plugins and a publish and subscribe model. So when it looks at a packet, there are things it can decode. When the packet gets to the rule, the rule might say that it needs the body and not any other fields. Then the body will only be decoded. This is referred to as just in time instead of just in case. So if any fields in the packet need not be decoded, you don’t waste time.

Rules Group Security Levels.

With Snort 2 regarding rule sets, you have only a few options. For example, you can pick no rules active-based policy, which is not recommended. There is also a connection-based rule set ( connectivity over security). We also have balanced security and connectivity. Then we have security over connectivity rules set. With Snort 3, you will get more than just these policy sets. So we have rule groups that we can individually set the security levels. So the new feature is Rule Groups, making it easier to adjust your policy. So with rule groups, we can assign security levels to each sub-group. So you can adjust based on your usage, such as a more aggressive rule set for Chrome or not for Internet Explorer. So the security level can be set on a per-group basis. But Snort 2 offers this only in the base policy. 

• Level 1 – Connectivity over Security 
• Level 2 – Balanced Security and Connectivity 
• Level 3 – Security over connectivity 
• Level 4 – Maximum Detection

Now there is no need to set individual rule states. So we have levels that equate to policy. With Snort 2, you would have to change the entire base policy, but with Snort 3, we can change the groups related to the rule set. What I like about this is the trade-off so you can have rules for example, Browser, that are not common on your network but still exist. 

• About
• Latest Posts

Matt Conran: The Visual Age

Public Speaker, Author and Consultant at Conran Insight

Matt Conran has more than 25 years of networking and security industry with entrepreneurial start-ups, government organizations, and others. He now focuses on public speaking, authoring content, consulting, and creating Elearning courses.

Latest posts by Matt Conran: The Visual Age (see all)

• Fortinet’s new FortiOS 7.4 enhances SASE - April 5, 2023
• Comcast SD-WAN Expansion to SMBs - April 4, 2023
• Cisco CloudLock - April 4, 2023