This content has been marked as final. Show 1 reply
For issue 1 i was pointed to this article: - https://kc.mcafee.com/corporate/index?page=content&id=KB66283
The workaround they recommend though is not acceptable as even if NIPS is disabled, if the firewall is enabled, it still leaves us open to issue 2
Issue 2 has been recreated and esculated to Tier 3 for software engineers to look into.
Additional infomation if you are interested i notied about issue 2:-
ADDITIONAL INFORMATION : -ISSUE 2: Systems enter a Denial of Service like state when UDP Port Scan or TCP Port Scan run again system with McAfee Host Intrusion Prevention installed, but IPS disabled
Additional information around the overall configuration of HIPS on the devices is that we also have the Firewall Enabled. The firewall is enabled at ALL times, but uses connection aware groups.
When users are connected to a network with certain IP ranges, and a certain IP suffix, all traffic for those clients are enabled (Allow All IP Protocols IN/OUT). This meaning that all Ports are enabled inbound and outbound on these systems, so traffic matching this Connection Aware Group has those rules applied to them
When systems are not on a network matching connection group, there are only basic firewall rules enabled to allow basic connectivity, with almost all inbound ports blocked (i can clarify these if required) and some outbound allowed
When systems are subjected to an Intense TCP or UDP Port scan when they are on the LAN, the firewall component will be allowing all traffic, and clients will in affect have all ports inbound and outbound enabled, This is the scenario where the problems occur.
Interestingly, when the Firewall component is COMPLETELY disabled on these systems, they can be subjected to this attack, without system instability ensuing, and the IPS component does its job of blocking the host, as expected.
When systems are on another unknown network, IE, not one that is known to any connection aware groups, then clients only have certain ports or traffic allowed, and as mentioned before, only a few inbound ports allowed and some outbound. In this scenario problems DO NOT occur. When systems are subjected to an Intense TCP or UDP Port scan when they are on this kind of network, the systems do NOT become unstable. I believe this is because the firewall is DROPPING all traffic inbound, and is not having to process this against CAG groups/rules, and then passing the traffic onto the IPS.
For us, from a workaround perspective, this is GOOD, as it does not leave our systems open to TCP/UDP port scan attacks making the systems unstable when off the network.
To summarise, this seems to be an issue of the Firewall components ability (or lack of) to pass the TCP/UDP Port scan packets which match an allowed CAG policy through its software and onto the IPS. It seems it cannot handle the amount of data that is generated when an Intense TCP/UDP Port scan is initiated when they match ALLOWED rules. This seems to be the case as when the Firewall component is disabled completely, or if this traffic is DROPPED if it doesn't match a rule (when it is off the network), the symptoms are not experienced, narrowing the issue down to the Firewall component and 'allowed' traffic.
In my own mind, i cannot see why the firewall component should not be able to cope with this data. If we had a vulnerability management solution that did port scans on clients, causing them to become unstable is not acceptable so is as such still an outstanding major issue for at least this kind of scenario, and its clear systems are NOT unstable when the Firewall is disabled, or the traffic gets dropped.
Be aware this pertains to ISSUE 2 ONLY and does NOT affect the issue described in ISSUE 1, which is related, but very different.