The next lab requirements go beyond what a basic firewall rule can do. A firewall can allow or block a traffic flow, but it cannot check if the traffic, webpage, or file is malicious or not. To handle these cases, we need more advanced security inspection. In UX 2.0, these functions are configured as reusable security profiles. Then these profiles are combined into an Advanced Inspection Profile, which is attached to a firewall rule with an action Inspect, as shown below.

We configure these profiles under Configuration > Policy Groups > Objects and Profiles > Security profiles, as shown in the screenshot below. 

Notice that this is an important shift in thinking. The firewall rule decides which traffic is allowed to pass. The security profiles decide what must be checked inside that traffic. In other words, allowing a flow is not the same as declaring it safe and risk-free.

Step 3.a. Intrusion Prevention (IPS) Profile

Let’s begin with a question again - why do we need IPS alongside a firewall action? A firewall rule blocks or allows traffic. An IPS checks whether the allowed traffic is dangerous.

The most common scenario when we need IPS is HTTP/HTTPS traffic. Why? Because HTTP is always allowed. Everything goes over HTTP these days - user input, REST API calls, file uploads, file downloads, logins, cookies, application data, etc. Because of that, HTTP(s) traffic is the largest attack surface. It carries the most risk. At the same time, for the firewall policy, all web traffic looks the same – TCP on ports 80/443. The firewall cannot know whether HTTP carries legitimate app data or SQL injection, command injection, SSRF, or another web application exploit. 

That is where IPS adds value. It inspects the allowed traffic and checks whether it contains known attacks or malicious patterns.