Drop or Reject Actions do not appear to apply for some rules on QRadar Network Security sensors

The NAP policy is an ordered set of rules that are used to inspect traffic. Some traffic inspection, such as IP-based inspection, can be performed on all packets and responses can be made on all packets accordingly. However, for application-based inspection, the sensor must first identify the application that is in use for the traffic before it can apply configured responses such as Drop or Reject Actions. Identifying the application that is in use requires that the sensor allow some packets to pass so that a successful connection can be established. After the connection is established, the XGS can begin analyzing Application Layer traffic and begin applying configured responses such as Drop or Reject to the traffic. This behavior is normal for application-based inspection and is by design. The result of this is that, during the connection establishment period in which the XGS allows the application finish its connection, connected devices such as firewalls might see those initial connection packets. Users might see reports of those packets from the connected devices and believe that the XGS is not responding to traffic correctly, although the sensor is working properly.

To avoid situations where users expect all traffic to be blocked based on IP but have some traffic passed due to application scanning, users should configure all Drop or Reject rules that are based on IP inspection at the top of the NAP policy. All application-based rules can then be configured below them in the policy. This allows the traffic to attempt to match based on IP first before performing an application-based inspection.

Note: This device cannot be configured for port-to-application mapping. It must make a decision by looking at actual traffic. For example, if your web server is running HTTP on port 8080, the sensor must let the 3-way handshake complete and look at the actual HTTP request before it identifies and confirms that this is HTTP application traffic only.

Examples: The following tests were run by attempting to connect to a web server in a lab network with network traffic passing through an XGS sensor.

Test 1

The first test was conducted using the following NAP rules:



Note that rule-2 in this case is using an application object and rule-1 is not.

After applying the rules to the sensor, a packet capture was run on the web server while a client attempted to access a web page hosted by the server through the network. The capture did not show any packets from the client's IP and the NAP events on the XGS confirm that the sensor dropped the traffic. This is because the decision to drop the traffic in this test is made without identifying the application that is in use. As such, the events that are returned from this traffic have a value of unknown in the Application column.

Test 2

In the second test, the rules are reversed, which results in the following configuration:



Note that rule-1 is now using the application object.

After applying the rule order change to the sensor, a packet capture was once again started on the web server and the client attempted to access the web page through the network. This time, the packet capture showed the initial TCP 3-way handshake being successful. This is because XGS had to allow a portion of connection in order to identify the application accurately. After the sensor identified the application and confirmed that it did not match the application specified in rule-1, the traffic moved to rule-2 and was blocked. The web page never loaded for the client during this test because the Drop functionality is working as expected. However, the XGS had to allow the 3-way handshake to complete before dropping in order to identify the application and verify that it was neither DHCP nor DNS, which could match the first rule.

The events that are returned from the traffic have a value of HTTP in the Application column for this test.