Cisco Firepower IPS is to detect and prevent intrusions in the network. This is the topic of this section to be discussed.
Cisco Firepower IPS Rules Fundamental
Cisco Firepower IPS detection main methods
there are two main methods that IPS detects intrusions in the network.
In the signature based detection, all knows attacks and intrusions are already encoded in the signatures like what we have in anti-virus. We have to regularly update signatures to detect latest known attacks.
in signature based detection, we are not able to detect zero-day attacks, which are new and there is no signature still written for them.
In anomaly based detection, all traffic violating normal traffic are assumed to be attack. In this method, Firepower is always learning and updating normal traffic pattern of the Enterprise. Any traffic violating normal profiled pattern is assumed to be anomaly.
With anomaly based detection, we can detect zero-based attack but is has mostly false positive.
False positive is normal traffic incorrectly labeled as intrusion traffic.
Cisco Firepower IPS and Snort
Cisco Firepower IPS rules are based on open source Snort IDS software. before Firepower version 6.7, Snort version 2 was used, but after Firepower version 6.7, Snort version 3 is also supported.
Snort Version 2 and Snort Version 3 are not compatible. there is a snort convertor feature in new firepower versions to change snort rules from version 2 to version 3.
https://www.cisco.com/c/en/us/td/docs/security/firepower/compatibility/firepower-compatibility.html
throughout this course we are configuring IPS rules based on Snort version 3.
Cisco Firepower IPS Rules
In “Devices -> Device Management”, you can check if the Firepower is using the new Snort version 3. You can also change it to old Snort version 2 if you want.
In “Objects -> Intrusion Rules”, you can check all Firepower IPS rules in both old Snort version 2 and new Snort version 3 format.
Let’s check IPS rules based on Snort version 3, since our firepower is using Snort Version 3.
As you can see, we have 44.960 firepower rules which are grouped in 9 parent group and 67 final groups. As an example in group “Server -> Apache”, we have 161 rules
In the right section you have the capability to search rules based on many options including name and CVE number.
For each rule you can see the Snort version 3 syntax, which is mostly similar but with a few differences compare to Snort version 2.
In the right top corner of Firepower rules we can convert old Snort version rules to Snort version 3 rules and import them into Firepower or download them to your computer.
Cisco Firepower IPS Variable Set
if we check the Snort syntax of a rule in the “Server -> Apache” group, we can see that there are some variables called in the Snort rule, like $EXTERNAL_NET, $HOME_NET or $HHTP_PORTS.
These variables are defined in a default variable set and we can configure them based on our topology and environment. You can also create a new variable set to be used in your IPS policy.
In “Objects -> Object Management -> Variable Set”, you can change the variable set or configure a new one.
Here you can see that the value of HOME_NET variable is any. You can for example include you real internal network as a value for HOME_NET variable.
Cisco Firepower IPS Policy configuration
In “Policies -> Intrusion”, we are able to create new policies.
The option “All IPS Rules” is a shortcut for “Objects -> Intrusion Rules” which we have discussed earlier.
With “Create Policy”, we can create new policy.
when we create a new policy, we have to choose the option detection mode or prevention mode. in detection mode all rules with drop action will be alerted only and the connection will not be blocked. Normally we use prevention mode except for some specific cases.
We also have to choose a based policy. In the based policy, you must decide whether security is more important to you or connectivity is preferred in your network.
If security is more a priority, we will choose the option “security over connectivity”. In this option, you’re likely to have some false positives that recognize normal connections as intrusions.
If connectivity is preferred, , we will choose the option “connectivity over security”. In this option, we’ll likely have more false negatives that can’t detect intrusions, and they’ll be recognized as normal traffic.
We also have an option in the middle, “Balance security and connectivity”, which try to minimize both false positive and false negative.
The option “Maximum Detection” has more emphasis on the security even more than “security over connectivity”.
After creating policy, you have the option to configure the rules based on Snort Version 2 or Snort Version 3. I choose Snort Version 3 to configure the rules.
After configuring IPS policy, now we have the capability to change the action of any of IPS rules for this policy.
If we go to Server -> Apache” group. We can see that in “Balanced Security and Connectivity” mode, there are 135 “Disabled” rules. 26 rules with action “Block” and no rule with alert action.
One advantage of Snort version 3 is that we can change the mode of security for each group independently. With creation of IPS policy, we have selected default “Balanced Security and Connectivity” for all group rules.
With clicking “Security Level Description”, we can change the level of security. By default the level of security is 2 from 4. I change the level of security from 2 to 3. Now we can see that the action of 61 rules are “Blocked” and 100 rules “Disabled” which is more aggressive compare to 26 and 135 rules.
For each rule we have the option to change the action to “Block”, “Alert” or “Disable”.
For a test I want to change the action of “ICMP Echo Reply” rule which is “Disable” by default. I change it to “Block” to block any icmp traffic from EXTERNAL_NET to HOME_NET.
After changing IPS rules, we have to apply it to an access control rule. I will apply IPS Policy1 to “permit_all” rule in access control with default variable set.
As you have noticed we have the option to select a different variable set for our IPS policy.
Now we expect that our ICMP traffic from inside to outside will not receive any reply. We can monitor the result in “Analysis -> Intrusion -> Events”.
