Installation of ENS on File Servers causing NIPS events

[calvinmaher]

I have installed ENS 10.6 on a File Server Cluster and Exploit Prevention is enabled. Ever since it was installed there are random hip.nips threat events Threat Name: ExP:NIPS Violation Description: ExP:NIPS Violation Blocked a Network exploit attempt Analyser Rule name: TCP Port Scan Does anybody know if there are any more detailed logs to find the route cause? Or is it a false positive?

[Former Member · Accepted solution]

You would really need to look more into the event details to see what was being triggered. To be honest, ENS Debug Logging would help provide more details as well and after the issue had occurred again you would need to review the ENS Debug Logs in %Programdata%\McAfee\Endpoint Security\Logs.

What further details do you see from the event reported in ePO?

[calvinmaher]

Thanks for the info - I've turned on debug logging for EP on one of the hosts, wait and see.

There was no other information other than it triggering the  TCP port scan analyser rule

[ktankink · Accepted solution]

If you have NIPS events to review in ePO, you can use that now.  Find the ExP:NIPS Violation (or Event Category: Host intrusion (hip.nips)) related to Signature 3700 in the ePO Threat Events menu, and review the Threat Source IP address (or Threat Source IPv4 address) value.  This is the remote IP address triggering the signature.

Review the system that is configured with that IP address.  Determine what on the system may be performing a TCP Port scan on the system.  It could be a legitimate port scanner (ePO Rogue Sensor with OS Fingerprinting, NMAP or third-party scanner, or third party vulnerability assessment solutions), or it could be a possible malicious (or unapproved) port scanner (e.g. something in your environment that is not setup as a legitimate port scanning device).

If legitimate, create a NIPS exclusion for that remote IP address, in the ENS Threat Prevention Exclusions configuration (exclusion type = Network IPS).

[calvinmaher]

Thanks. The source is a virtual switching IP being used in a hyper-v cluster. Our Nessus scanner sits on the same cluster so just investigating that to confirm

[Sohel]

Hello,

I'm having a similar issue and I was wondering if you were able to resolve the issue.

Our Nessus scanner is getting blocked even after creating an exclusion for the ip-address in Exploit prevention.

I pulled below from threat event in ePO:

...................................................................................................................................................

Analyzer Detection Method:Exploit Prevention
Threat Name: ExP:NIPS Violation
Analyzer Rule Name:SMB Brute Force Attack
Description:ExP:NIPS Violation Blocked a Network exploit attempt.
Attack Vector Type:Network

.........................................................................................................

(below is my policy)

[calvinmaher]

Hi, this might be a stupid question but have you got the , (comma) character after the IP address, for syntax separation.
We don't get the SMB brute force attack rule, we get a TCP Port Scan analyzer which is triggered from Clustered hosts. If you're getting SMB attack is your Nessus scanner using Port 139? It could be a host trying to port scan to spread the Wannacry detection, for example.

[Sohel]

Commas are in place per policy instruction.

We are not using port 139, so I'm not sure why it's saying SMB Bruce attack. 

so by adding the ips to exclusion list fixed your issue?