We have previously talked about Intrusion Prevention Policy, or IPS, and saw how to configure and tweak the same. What we did not talk about and is closely tied to the IPS policy is Network Analysis Policy or NAP. So, what is NAP? The NAP is sort-of-kind-of-pre-IPS-policy. What I mean by this awkward construction? Well, the Snort (and all other IPS systems, for that matter) uses pattern matching technique to find and prevent exploits in network packets. Whether it is a simple string comparison or more complex regex match, it is still a pattern matching. In order to do this, Snort engine needs network packets to be prepared, if you will, in a such way that this comparison can be done. This process is done with the help of NAP and can undergo a three stages which help each other and Snort at the end:
Each part plays a critical role in making sure that packet is sane and can be used by Snort rules and all of them are glued together with the NAP. How the NAP works? Basically, a network analysis policy processes packet in phases: first the system decodes packets through the first three TCP/IP layers, then continues with normalizing, preprocessing, and detecting protocol anomalies. From the Cisco’s documentation:
- The packet decoder converts packet headers and payloads into a format that can be easily used by the preprocessors and later, intrusion rules. Each layer of the TCP/IP stack is decoded in turn, beginning with the data link layer and continuing through the network and transport layers. The packet decoder also detects various anomalous behaviors in packet headers.
- In inline deployments, the inline normalization preprocessor reformats (normalizes) traffic to minimize the chances of attackers evading detection. It prepares packets for examination by other preprocessors and intrusion rules, and helps ensure that the packets the system processes are the same as the packets received by the hosts on your network.
- Various network and transport layers preprocessors detect attacks that exploit IP fragmentation, perform checksum validation, and perform TCP and UDP session preprocessing.
- Various application-layer protocol decoders normalize specific types of packet data into formats that the intrusion rules engine can analyze. Normalizing application-layer protocol encodings allows the system to effectively apply the same content-related intrusion rules to packets whose data is represented differently, and to obtain meaningful results.
- The Modbus and DNP3 SCADA preprocessors detect traffic anomalies and provide data to intrusion rules. Supervisory Control and Data Acquisition (SCADA) protocols monitor, control, and acquire data from industrial, infrastructure, and facility processes such as manufacturing, production, water treatment, electric power distribution, airport and shipping systems, and so on.
- Several preprocessors allow you to detect specific threats, such as Back Orifice, portscans, SYN floods and other rate-based attacks.
- The sensitive data preprocessor detects sensitive data such as credit card numbers and Social Security numbers in ASCII text, in intrusion policies.
Now that we know a little bit about NAP, how do we configure one? Stay tuned, there is a big surprise down the road…
This is the screen shot of the advanced settings of our Access Control Policy, or ACP. We can see what IPS policy we are using, what variable set is tied to that policy and finally what is our Network Analysis Policy. When we configured the ACP and IPS, we never actually did anything with regard to the NAP. Why is so? Well, there is default NAP that is tied to the ACP and most people think that the default settings are good for most deployments and that we should stick to these default settings. We could not be more wrong! Default NAP is almost never ok for anybody if used as-is. Why? Read on…
When we create an Access Control Policy, by default it is tied to the “Balanced Security and Connectivity” NAP, which can be viewed in advanced settings of ACP:
Creating our custom NAP is a little bit tricky. Maybe the better description is “it is hard to find NAP policies”. They can be reached by going to “Policies->Access Control->Network Access Policy” (it is hard to find, located at the top right corner):
The creation of NAP is similar to the creation of IPS policy. We begin creation of policy by choosing the NAP policy template:
On new systems we can chose among four templates:
- Connectivity Over Security
- Balanced Security and Connectivity
- Security Over Connectivity
- Maximum Detection
My advice: it is best to use “Balanced Security and Connectivity”. It is recommended template and is perfectly fine with almost every organization. Don’t go above that and never, I mean never-ever use “Maximum Detection”. At least in a production environment.
In system that is being used for some time, we can create our new NAP based upon other NAPs, which are, in turn, based upon one of those four base NAPs.
When we create our NAP, we can point our Access Control Policy to use this NAP, by going to ACP’s advanced settings. Isn’t this what we all do? Yes. And is there anything wrong with this approach? Yes. So, what is wrong?
After we select our base policy, we have the opportunity to edit this NAP. Settings are different here that with IPS policy, but the principle of inheritance that we talked about earlier stays the same: settings in our layer called “My Changes” takes precedence over the same settings in basic layer “Balanced Security and Connectivity” (given that we opt to use the recommended base policy):
We won’t get into details about these settings now. It is important to understand that settings given here help Firepower detect attacks efficiently and prevent IPS evasion techniques, such as encoding, IP Fragmentation, overlapping fragments, protocol ambiguities, resource exhaustion, TTL manipulation and so on.
Let’s go back to the beginning of this blog and refresh our knowledge about that pattern matching that IPS engine does and how the network packet is prepared for this process (decoding, normalizing, preprocesing). Now, let’s imagine that the malicious user is crafting his attack by using one or more evasion techniques to beat our IPS and compromise his targets, our internal resources. The purpose of NAP is to defeat attacker’s efforts so that it prepares or changes packets in such a way that IPS policy can act upon this traffic. It is known fact that different operating systems do packet reassembly different way. To be effective, IPS must prepare network packets in much the same way as the resource it protects would do. So, if we are protecting Linux systems, we prepare the traffic in one way and for Windows systems, we do that another way. By ‘we’ I mean IPS.
So, one of the most important things with NAP is to tell it how to normalize or prepare network traffic for analysis. Not many things should be changed here, but one of them is certainly “IP Defragmentation”:
So, this part of NAP is saying “I’m protecting Windows targets”. Like Windows targets can be protected 😀
This setting is ok if we really have only Windows hosts, but that is almost never the case. This does not mean that Linux or other hosts are not going to be protected, but they won’t be protected efficiently or some attacks may be missed. We need to tweak this setting a bit, in order for Snort to see our topology more clearly. For example, if we had Linux servers in the network segment 10.1.10.0/24, we would adjust the settings accordingly:
So the NAP would know how to protect our Linux servers (we added them manually), as well as Windows servers (they fall under the default targets). Of course, no network segment contains only Windows or Linux hosts, so we could tweak our policy further:
Here is our Cisco switch SVI interface in the middle of Linux network segment and NAP now knows how to differentiate it.
Another place inside Network Analysis Policy where we should do similar tweaking is “TCP Stream Configuration”. Here we can apply the same principles as with “IP Defragmentation”. Again, the system by default has a wrong assumption, so we tell it to be smarter:
We can see that we can be even more precise when choosing an operating system type. If our operating system is not listed, we should go for closest match. For example, we have “Windows 2003” listed, but no “Windows 2012” or “Windows 2016”. Or we could have Linux kernel 3.x, but only 2.x option to select. Chances are that “Windows 2016”, for example, handles network packets similar to “Windows 2003”, or Linux 3.x similar to Linux 2.x.
Among other NAP settings, perhaps “Inline Normalization” should be mentioned here and turned on. Settings->Transport/Network Layer Preprocessor:
Let’s not forget to save our NAP, refer access control policy to it and deploy our settings to devices.
Now, our NAP policy will work for us as it should. Of course, there is one small caveat here. Our NAP policy is “one size fits all”, which means that we only have one NAP with different settings for various network segments. What if we would want to have multiple NAP policies and tie them to individual segments? We could that. Under access control policy’s advanced settings we chose “Network Analysis and Intrusion Policies” pencil icon and click “No Custom Rules”. Here we can select our networks and assign separate NAP to each one, and left default NAP handle the rest of the hosts:
Final thoughts: there are tons of settings inside the NAP. Changind these settings are considered advanced IPS tweaking and should not be taken lightly. We must know exactly what we are doing and with NAP it requires lots of research. Otherwise things may be broken.
I hope this was useful for you guys and hope to see you soon.
Thanks for sticking around!