Bug in HIPS?- Cannot create exclusions for or disable UDP/TCP Port Scan
i think i may have discovered a couple of pretty major, and interesting bugs in McAfee HIPS. I have some DNS servers at a site i am working at that cause the UDP Port Scan Signature to get triggered, so we looked to create exclusions for these signatures
Exlusions i create in EPO policy for the UDP or TCP Port scan signatures do not work, nor even when i disable those signatures COMPLETELY or DISABLE ALL SIGATURES via policy, these Network IPS TCP Scan (3700) and UDP Scan (3701) signatures are still triggered, causing the blocking of the source of the ''attacks'' for a period of time, ie in the is instance, client cannot resolve names. (i can turn off blocking as work around)
When Network IPS is disabled, as a component of the systems, and i do an ''Intense TCP Port Scan '' or an ''Intense UDP Port Scan'' using Nmap, it causes these systems to halt/hang/crash causing a DOS on the systems, even after the scan is stopped.
This does NOT happen if HIPS is uninstalled or NDIS driver is disabled. Scan takes place again the system, and the system does not become unstable.
I wonder if there is a link between the inability to disable the signatures completely, and the fact that systems with HIPS installed hang when subjected to this kind of attack
Tested with HIPS 7.0.4 and 7.0.5
Would be great if someone else could test this out.
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.