An intrusion detection system (IDS) is a network security function that performs real-time traffic inspection and detects network anomalies based on signatures, statistics, protocol analysis, etc. Once an IDS detects an attack, it raises alerts and notifies security admins via logging and reports. However, it does not take any actions to prevent the attack (hence, it is only a "detection" system).

An intrusion prevention system (IPS) goes one step further. It takes pre-defined countermeasures to prevent the attack, such as blocking traffic or resetting connections (hence a "prevention" system).

Nowadays, organizations have highly connected environments with a vast attack surface due to cloud and remote workers. IDS/IPS is one of the essential elements of the modern enterprise security suite. It counters known threats and attacks in real-time, offloading the security teams’ workload. 

Understanding the IOS-XE Architecture

To understand the IDS/IPS implementation in Cisco SD-WAN, it is important to know the routers' IOS-XE architecture. 

• IOS-XE operating system uses Linux as a base kernel.
• Linux is responsible for all low-level functions, such as:
  • chassis/device management.
  • I/O and memory management.
  • inter-process communications.
  • On-Board Failure Logging (OBFL).
  • timers, and so on.
• IOS runs on top of the Linux kernel as a daemon (referred to as the "IOSd").
• IOSd runs the control plane and all network functions.
• The Linux kernel also provides a hosted application space for Linux Containers (LXC) and other external daemons.

 Figure 1 shows a simplified view of the IOS-XE operating system architecture.

The Snort IPS engine

Generally, IOS-XE routers have several multi-core processors (CPUs). Some cores are allocated for IOSd, while others are for the app hosting environment. Cisco SD-WAN devices implement the IDS/IPS functionality by leveraging the Snort open-source network Intrusion Prevention System (IPS). Snort is deployed in a Linux container (LxC) hosted within the IOS-XE app hosting space. A Virtualization Manager layer (VMAN) ensures enough CPU cores and other device resources are allocated to the Snort container. 

Figure 2 illustrates a simplified version of the Snort implementation architecture. Notice that there are two virtual interfaces (Management VPG and Traffic VPG). The management one is used to download signature updates from Cisco's repository and as a source interface for logs and reports. The traffic VPG interface is connected to the data plane and forwards traffic to the Snort container for IDS/IPS inspection and back. 

Based on the use case, organizations can use the Snort IPS engine either in IDS or IPS mode:

• In IDS mode, the engine monitors application traffic and detects anomalies based on signatures, protocol analysis, statistics, etc. If an attack is detected, it sends log messages and alarms.
• In IPS mode, the engine can take actions to prevent the detected attack.

The Unified Thread Defense (UTD) file

To enable Snort IPS in Cisco SD-WAN, the first thing to do is download the Unified Thread Defense (UTD) .tar file from cisco's software repository. We can check which UTD version is required for each edge router by using the "show utd engine standard version" command, as shown in the output below.

cEdge-3# show utd engine standard version 
IOS-XE Recommended UTD Version: 1.0.3_SV2.9.16.1_XE17.7
IOS-XE Supported UTD Regex: ^1\.0\.([0-9]+)_SV(.*)_XE17.7$

Once we know the required UTD file, we can locate it on the software.cisco.com website, shown in figure 3 below.

Once we have the file, we upload it into the vManage image repository at Maintenance > Software Repository > Virtual Images > Upload Virtual Image.  

Signature Store

IDS/IPS signatures are unique traffic patterns of a distinct exploit attempt. Cisco has a signature store that provides up-to-date signature packages to devices. Routers can download these packages periodically or on demand.

When a router updates its signature package, the Snort engine restarts. Depending on the Snort configuration, traffic may be interrupted or bypass IDS/IPS inspection while the updating takes place. Two configuration options control this behavior:

• Fail-open (default) - traffic bypass the Snort engine on failures or during updates.
• Fail-close - traffic is dropped on failures or during updates.

Signature Set

Within the vManage IPS policy, there are three signature levels available, as shown in figure 4 below. Each level contains a different list of security vulnerabilities based on the Common Vulnerability Scoring System (CVSS) score.

• Connectivity - This set includes information for vulnerabilities with a CVSS score of 10 from the previous two years. The set provides optimal performance as fewer rules are included.
• Balanced (default) - This set contains information for vulnerabilities with CVSS 9 and 10 from the previous two years. The set offers the best balance between performance and protection.
• Security -  This set includes information for vulnerabilities with CVSS 8, 9, and 10 from the previous three years. The set provides the best level of protection, but the router's performance may suffer if it doesn't have enough resources (CPU and RAM).

Additionally, some signatures may be performance-impacting, while others may create a lot of false positives. That's why the IPS policy allows us to configure a whitelist of signatures, as shown in figure 4 above.

Secure App Hosting Profile

When we attach a security policy that contains an IPS policy to a device template, vManage wants us to add a sub-template called "container profile." This sub-template is created on vManage at Feature Template > Add Template > Secure App Hosting and defines how many CPU cores will be allocated for the Snort container. 

The Resource profile allocates one CPU core to the Snort container by default. For better performance, we may set it to High, allocating two CPU cores to Snort. However, before doing it, we must ensure that the router has enough resources (CPU and RAM).

The NAT option can be set to "On" if the Snort IPS engine must send logs or other information to an external server not located within the SD-WAN domain.  

The "Download URL Database on Device" can be set to "Yes" if the router must do manual signature updates via the Internet. NAT must be set to "On" in that case.

Summary of enabling Enterprise FW and IPS

Now let's summarize the process of enabling Enterprise Firewall and IPS on a cEdge router. Basically, putting all we have learned in the last two lessons together.

FW and IPS in the Control-Plane

Figure 6 illustrates the process of enabling FW and IPS policies in the control plane at a high level:

1. The first step in enabling IPS is to check the required Unified Thread Defense (UTD) file and download it from software.cisco.com. Then upload the tar file to the vManage's virtual image repository.
2. The second step is to define a new security policy (assuming there is no existing policy already applied). Within the security policy, we configure a firewall policy and an IPS policy.
   1. For the firewall policy, we define a source and a destination zone and associate them in a zone pair. Then we configure the required traffic rules and apply them to the zone pair.
   2. For the IPS policy, we configure the inspection mode (either IDS or IPS), the signature level, and a whitelist and apply it to one or more target VPNs.
   3. Lastly, we configure a new feature template of the type "Secure App Hosting" profile. There we set how many CPUs will be available in the Snort container.
3. Then we attach the security policy to the respective device templates.
4. Once the device policy is attached, vManage downloads the LxC container from the software repository to the Edge router and brings up the Snort container. 

FW and IPS in the Data-Plane

In the data plane, the application traffic coming from the source zone is first inspected by the enterprise firewall policy. The inspection consists of verifying the TCP sequence numbers and flags, examining the L7 header, and verifying the specification for the respective application. 

Next, the Unified Thread Defense (UTD) is invoked. The app traffic is redirected to the Snort container over the traffic VPG interface. The Snort IDS/IPS inspects the traffic for known threats and attacks. Based on the configured inspection mode (IDS or IPS), the traffic is either detected or prevented. If the inspection mode is set to prevent (IPS), the Snort engine detects the traffic's signature and prevents the flow (if the signature is blacklisted), and sends logs to the configured syslog address. If the traffic flow is not matched against a malicious signature, it is forwarded back to the IOSd process.

Lastly, the traffic is routed along the overlay fabric towards the edge routers at the data center and goes out to the Internet and back.