Use the following steps to troubleshoot a network-facing application or traffic that the Host Intrusion Prevention firewall is blocking:
- Save any existing HipShield and FireSvc logs and delete the originals. This action resets the logs.
- Enable full IPS and firewall logging. See KB72869 for information about Host Intrusion Prevention logging.
- Open the Host Intrusion Prevention Client user interface (UI), and clear the Activity Log.
- In the Firewall Options policy, or locally on the client after unlocking the Client UI, enable the Adaptive Mode option.
- Test the issue:
Does it work?
Is an adaptive rule created? If so, add the appropriate rule to the customer firewall policy.
- Retest the issue with the updated policy applied.
- Check the Client UI activity log for any blocks.
- Search the FireSvc.log for BLOCKED PID.
- If there are no blocks and no rule is created in adaptive mode, make sure that the client is running the latest Host IPS patch. See KB70725 for patch and hotfix version information.
Use the Any-Any rule
- On the ePO server console, duplicate the Firewall Rule policy that is running.
- Modify this new policy, assign it to the test client, and create a new Firewall rule.
- Select the following:
Host IPS 8.0:
<Description tab>
Name = Allow Any-Any
Action = Allow
Direction = Either
Status = Enabled
<Network Options tab>
Network Protocol = Any Protocol
<Transport Options tab>
Transport Protocols = All Protocols
<Applications tab>
Leave blank
<Schedule tab>
Schedule Status = Leave unchecked (Disabled)
- Save the Allow Any-Any rule and move it to the top of the newly duplicated firewall policy.
- On the ePO server console, duplicate the Firewall Options policy that is running.
- Modify this newly duplicated policy, assign it to the test client, and modify the following features in the Firewall Options policy.
Host IPS 8.0:
"Allow traffic for unsupported protocols" = Enabled
Startup protection = Disabled
"Enable IP spoof protection" = Disabled
"Incoming TrustedSource block threshold" = Do not block
"Outgoing TrustedSource block threshold" = Do not block
- For Host IPS 8.0, either set the DNS Blocking policy to McAfee Default, or make sure that the assigned policy has no DNS Blocking entries.
- Retest the issue.
Does it work?
If it works, expand all firewall rule groups in the named policy and analyze each of the firewall rules from the top down. Pay special attention to those rules that have BLOCK as the action. Based on this review, move the Any-Any rule down to many positions in the rule set.
NOTES:
- By analyzing the rules several times and retesting the issue, you can determine which rule might be blocking the application.
- For Host IPS 8.0, other features might be blocking the traffic, such as TrustedSource or IP Spoofing functionality. The issue might reoccur if you re-enable these features. The reason is because the firewall rules created for these features are processed before your Firewall Rule policy.
Host IPS 8.0: Verify the application details match the executable details appropriately. For example, the File description value must be the exact application description, and not a COMMENT value for the application. See KB71735.
If a rule is not located, add the proper rule to the firewall policy set and retest.
Test by allowing Non-IP protocols
The firewall Network Device Interface Specification (NDIS) filter might not be seeing the traffic at all. To ensure that you have tested by allowing unsupported protocols, see
KB66899.
Test by disabling the TrustedSource functionality (Host IPS 8.0 only)
Network traffic is processed by the
TrustedSource - Get Rating firewall rule
before the other firewall rules contained in the
Firewall Rules policy, which might contain an
Allow Any-Any firewall rule.
Test by disabling the IP Spoofing functionality (Host IPS 8.0 only)
Network traffic is processed by the
IP Spoofing firewall rule
before the other firewall rules contained in the
Firewall Rules policy. The Firewall Rules policy might contain an
Allow Any-Any firewall rule.
Test by disabling or uninstalling the Host Intrusion Prevention NDIS drivers
NOTE: The information in the following Knowledge Base article is only for testing. It is not intended to be used as a solution to an issue:
KB75917 - Enable FWPassThru mode.
Advanced troubleshooting
NOTE: The following advanced troubleshooting might be required for more analysis. Contact Technical Support for assistance if any of the following are required.
Test the issue with the Microsoft NDIS Pass Thru driver installed
A defect in the NDIS might cause some issues. NDIS is the programming application interface for third-party network device drivers. To determine if NDIS is at fault, uninstall Host Intrusion Prevention and install the Microsoft Pass Thru NDIS driver. To request the NDIS PassThru driver, contact Technical Support.
Host IPS 8.0: Collecting data using Microsoft ETL logging
See
KB72868 for information about collecting ETL logs for Host Intrusion Prevention 8.0 for Windows.
Collect data using network capture software (for example, Wireshark)
Some advanced firewall issues might also require a network packet trace during the reproduction. Normally, two traces are recorded: one with the issue and the other without the issue. You can compare the traces to determine any differences with network packet traffic:
- Install network capture software, for example, Wireshark, on the test client.
- Clear and reinitialize all logs and the ClientUI activity log.
- Start capturing a network trace.
- Reproduce the issue.
- Stop the network trace capture.
- Click the EXPORT or SAVE option, and save the Host IPS ClientUI activity log.
- Collect the following:
- Network trace file
- McAfeeFireLog.txt - Host IPS Client UI Activity Log
- HipShield.log
- FireSvc.log
- Contact Technical Support and provide the logs and full MER tool results.
- If you are a registered user, type your User ID and Password, and then click Log In.
- If you are not a registered user, click Register and complete the fields to have your password and instructions emailed to you.
- Identify the client IP address and the IP address of the network server that the application is trying to communicate with.
- Disable the firewall and create a second network trace with everything working correctly to compare the working trace to the non-working trace.
- If possible, isolate the network traffic that might have been blocked in the first trace by comparing the working and non-working network trace. Add the appropriate rules to the policy.