Enhancing Security with Snort in Cisco Secure Firewall Threat Defense

Enhancing Security with Snort in Cisco Secure Firewall Threat Defense

May 19, 2024 Off By Das

Snort is an open-source intrusion detection system (IDS) and intrusion prevention system (IPS) used for real-time traffic analysis. In other words, it is an engine that detects and prevents malicious activities within a network, ensuring its safety. 

Snort examines network traffic attributes (such as packet headers and payload content) to identify and stop malware-related traffic. It uses a rules-based detection engine, where rules are created based on signatures or patterns associated with known threats. In addition Snort allows logging for future analysis and can work with various operating systems.

An example for Snort rule – a rule  that triggers an alert when five or more TCP SYN packets are sent to different ports on a single destination IP address within a 60-second window, indicating a possible port scan attack.  

Another example – a rule that triggers an alert when the keyword “union” is found in the HTTP URI of a TCP packet going from the external network to the HTTP server, indicating a possible SQL injection attempt.

 

 

The History Of Snort – Main Points 

  • In 1998, Martin Roesch began developing Snort with the goal of creating a lightweight, open-source, real-time network intrusion detection system (IDS). 
  • Over the years, Snort has been developed and new versions have been released, each introducing new features and bug fixes. 
  • In 2001, Sourcefire acquired the rights to Snort, and Martin Roesch continued to lead its development within the company. 
  • In 2005, Sourcefire introduced Intrusion Prevention System (IPS) and Firepower Next-Generation Intrusion Prevention System (NGIPS). 
  • In 2013, Cisco Systems acquired Snort, integrating it as a core component of Cisco’s cybersecurity solutions, including Cisco Firepower Threat Defense and Cisco SecureX. 

Snort In Cisco Firepower 

As mentioned in this post, firewalls use predefined rules to determine whether to allow or drop certain communications. Cisco’s firewall is no different, but it has a significant advantage: the Snort engine, which constructs IPS rules based on network attributes with nearly no engineer intervention.  

In Cisco’s next-generation firewall there are two main engines – LINA, you may know from Cisco ASA, and Snort. LINA is the traditional core process responsible for packet processing, access control, and routing within the FTD device. Snort, on the other hand, responsible for deep inspection of traffic in real-time to detect and prevent security threats. Both of the engines works together but you can choose what traffic you want to pass to the Snort engine and what traffic will skip it (for example traffic sensitive to latency).

The following image illustrates the stages of traffic inspection, starting from LINA Phase One, progressing through the Snort phase, and concluding with LINA Phase Two:FTDPolicyFlow3 

LINA Phase One

Ingress traffic starts at the LINA. It is initially checked to determine if the packet belongs to an existing connection. If not, it undergoes VPN decryption to enable inspection, followed by Un-NAT/Egress, which reverses the address translation and performs route checking. If the packet does not belong to an existing connection, it proceeds directly to DAQ. This is a crucial for efficient network traffic processing.

The Data Acquisition Library (DAQ) serves as a bridge between LINA and Snort, facilitating communication between the two. Within Snort inspection, there are several policies. If the traffic is denied by any of these policies, processing halts, and a command is sent to LINA to drop the traffic at the next LINA phase. Similarly, for allowed traffic, DAQ sends a command to LINA to continue processing. Notice that neither DAQ nor Snort drops packets – LINA is responsible for packet control.

In the LINA Prefilter policy, traffic can be filtered based on layer 3/4 attributes such as IP, ports, or interface, as well as tunnel traffic. The Prefilter determines whether the traffic is sent to the Snort engine, skipped, or dropped. 

 

Snort Phase

Security Intelligence IP

Security Intelligence IP (SI IP) is a policy designed to block or alert about threat-associated IP addresses. SI IP configuration is managed through the Access Control Policy (ACP) and is not enabled by default. A network administrator can add malicious IP addresses to the SI IP list or feed to block them. If a packet matches the source or destination of an IP on this list or feed, it is dropped.

You may wonder how network administrators can identify malicious IP addresses. Cisco has a Talos database, which provides extensive intelligence and classification of known malicious IPs into threat categories, such as phishing or spam IP addresses.

SSL/TLS decryption

SSL/TLS decryption is the next phase – network administrator can turn on decryption in order to enable inspection of encrypted data. You can choose what traffic will be decrypted and what will not and can specify security parameters to drop the traffic according to like having certificate.

Security Intelligence for URLs and DNS

Security Intelligence for URLs and DNS is the next policy. Similar to SI IP, you can manually configure which URL or DNS names need to be blocked, allowed, or monitored. Additionally, you can use the Cisco FTD Talos database for automatic configuration of URL and DNS names. This step occurs after SSL/TLS decryption because the data needs to be in plain text to identify the URL or DNS.

Identity Policy

The Identity Policy provides user-based authentication. It relies on integration with identity sources such as Cisco ISE or Active Directory. Once you have integrated the identity source with the FMC, you can create rules based on user identity. For example, you can create a rule that allows access to certain URLs for specific users. Note that the Identity Policy is intended to pull and manage user identities and does not control the traffic—this is done in the ACP (except for Captive Portal and Remote Access VPN, which are controlled through the Identity Policy).

ACP

The Access Control Policy (ACP) is the next policy. In the ACP, you can create Layer 3 to Layer 7 rules, identity rules, application rules, and more. There are several actions you can configure in ACP rules, and these actions influence the subsequent phases of traffic processing.

  • Allow action: Directs the traffic to further inspection (e.g., QoS Classify, network discovery, etc.).
  • Trust action: Directs the traffic to QoS Classify and then skips back to LINA.
  • Block action: Stops further inspection, directs the traffic to LINA, and drops it.

QoS Classification

QoS Classification is a process used to categorize network traffic into different classes based on predefined criteria. This process ensures that important traffic receives priority. QoS is not configured from the ACP. In this stage, the packet is classified, and in the LINA phase, the QoS policy is enforced

Network Discovery

In the Network Discovery stage, Snort learns about the network and its attributes, such as operating systems and services running on hosts. In this stage, we only collect information and do not perform drop or allow actions.

File Policy

In the File Policy, you can monitor files on the network. You can block or alert based on specific file types or perform inspection to detect malware using the Snort database. You can also monitor file transfers in traffic that goes through the FTD and even examine traffic that does not go through the FTD using host agents.

IPS

The final phase of the Snort engine is IPS inspection. In this phase, Snort performs deep packet inspection to identify and block malicious activities. The IPS rules are also configured through the Access Control Policy (ACP).

 

LINA Phase Two

After Snort inspection, or after Prefilter rules, depend on the configuration, the traffic will return to the LINA engine. There LINA performs the desired action – either blocking the traffic or passing it to the next processing stage based on the Snort inspection or Prefilter rules results. The update of the desired action occurs in the flow update stage.

After this, the packets will be transformed by NAT if needed (in the NAT stage), enforced by QoS policies (in the QoS stage), and encrypted (in the VPN encrypt stage).

 

Conclusion

In conclusion, it seems like the Cisco FTD has impressive capabilities thanks to its integration of the Snort engine. This integration transforms the seemingly impossible goal of implementing an Intrusion Prevention System (IPS) in the organization’s network into an achievable one. The engine ability to learn the network and its attributes, perform stateful deep packet inspection, and detect malware plays a crucial role in enhancing network security.