How can you configure a network or host-based sensor to ignore or whitelist traffic from certain internal hosts without creating firewall rules?
Users can utilize the
pam.report.filter* advanced parameter to configure a sensor to ignore traffic or events from certain IP addresses. All traffic or events that meet the specified criteria will be ignored. Users can add this parameter to the tuning parameters policy in the following contexts:
Filtering IPS events by IP Address (source or destination)
Example Scenario: We have a scanner located at 192.168.0.1 that routinely generates many security events during audit scans. Because we know that these events are benign, we do not want our IPS using the extra system resources to process the events. We also do not want to use our SiteProtector database to store all of this unnecessary security event data. We can filter this traffic at the inspection engine level by using the following tuning parameter:
ip addr 192.168.0.1
There are many different ways the Value field can be completed depending on your needs. Here are some examples of different ways to filter using the
|To filter events by||Value String example|
|Single IP (Source or Destination)||
|Single Source IP Address||
|Single Destination IP Address||
|All events from/to a Subnet (Using CIDR notation)||
|All traffic from.to a range of Addresses||
Filtering IPS events by specific Event ID and IP Address (source or destination)
Example Scenario: We use the RDP_Login audit event to monitor remote access on our admin VLAN. The common management system is 10.0.0.23. We do not want to see the RDP_Login events from this system. In order to filter IPS inspection for this signature using the 10.0.0.23 IP address, we first need to find the issueid for RDP_Login. There are two ways that this can be done. You can right click the event in the Analysis view of the SiteProtector Console and select Open Event Details... or you can look at the PAM help file and find the event there. Both of these sources are considered to be authoritative and will provide the issueid for the event that you are looking for. The issueid for RDP_Login is 3113009. Based on this example, we will use the following tuning parameter to ignore the traffic:
ip addr 10.0.0.23
As with the filterall parameter, the filter parameter can use all of the Value variants listed in the previous table.
Using multiple filterall or filter Parameters
It is sometime necessary to add multiple instances of the aforementioned parameters depending on administrative need. For example you could create one parameter to filter events generated by a vulnerability scanner and another to ignore events for a particular host.
You can add multiple instances of the parameter to filter more than one address entry by adding an index to the parameter name.
Example using multiple filterall parameters:
ip addr 192.168.0.9
ip addr 10.0.0.0/16
Example using multiple filter parameters:
ip addr 192.168.9.0/24
ip addr 10.10.8.130
|Security||IBM Security Network Intrusion Prevention System||Protocol Analysis Module (PAM)||Platform Independent||Version Independent|
|Security||Proventia Virtualized Network Security Platform||Not Applicable||Platform Independent||Version Independent|