Endpoint Protection

I'm running SEP 12.1.6.1a as an unmanaged client on Windows 10 with all default firewall rules.

SEP is blocking another computer on my local network for a 'port scan attack'. The Network Threat Protection log shows the generic 'Block All' rule being triggered.

The default 'Allow Ipv4 LLMNR from private IP addresses' rule is enabled and has priority over the 'Block Ipv4 LLMNR' rule. I notice however, that the allow rule only allows traffic on local UDP port 5355- that is, it allows incoming LLMNR requests. But the traffic that is triggering SEP is an incoming response- so the remote port is 5355, the local port is a dynamically assigned port, and neither LLMNR rule is triggered (both look for incoming requests on local port 5355).

So my question is- should SEP be smart enough to detect the outgoing LLMNR request and allow the incoming traffic against the same local port as the outgoing? I assume something is going wrong with my particular configuration, or else everyone would be getting hit with this phenomenon.

Thanks for any help you can provide.

It's only going to allow what the rules state. Would need to see a screenshot of the of the log or better yet attach the log here for review.

As said in the article at the below link:

"Some applications in the network may generate traffic patterns which trigger port scan detections. These generally include software designed for discovery, monitoring or security testing."

http://www.symantec.com/docs/TECH226408

Please follow the solution mentioned in this article to resolve your issue.

Thanks for responding- I've attached an example of the traffic. SEP immediately blocks for 10 minutes, then the cycle promptly repeats when the IP block expires.

I agree that it's not covered in the default firewall rules. But the port usage looks like it follows LLMNR specs (https://tools.ietf.org/html/rfc4795#section-2.3). I'm just surprised more people don't encounter this problem- I searched this forum and found only 3 mentions of LLMNR- none of them like this case.

Does SEP use logic beyond the firewall rules to identify port attacks? Could it be that the response is taking too long and thus looks like unsolicited traffic instead of a response to a query?

Attachment(s)

SEP LLMNR Example_0.txt   215 B 1 version

edit- double post

Any ideas guys?

Having same issue here.  Very recent fresh install of SEP 12RU6 with managed clients running Win7, 8.1 and 10.  Workgroup environment (SOHO).  This network was on SEP SBE 12 RU5 prior to the upgrade to 12RU6 a month ago, and had zero issues.  Full uninstall of 12.5SBE was performed prior to installing 12.6.  All policies were created fresh out of the box.  Everythign worked perfectly for three weeks.

A week or so ago clients started detecting port scan attacks from a Brother network printer, and from eachother including from the SEPM server (Win10), and cycling through blocking traffic for 600 seconds.  Have been chasing the issue now for several days without resolution.  I initially thought it might have to do with the LLMNR rules in firewall, but I think that's an unrelated coincidence.  I did try disabling network discovery on one of the endpoints, and that did not help. 

Have read every recent thread on this forum.  I believe I was able to "free up" the printer by excluding its IP from the network threat policy.  It no longer seems to trigger the alert and subsequent blocking on the managed clients.  Not sure I like this as a final solution, but it's not an endpoint and I'm pretty sure it's not infected.  All malware scans (SEP, MBAM, etc) come back completely clean.  Not interested in uninstalling or disabling NTP, or other more drastic measures.  

Read one post  indicating it might be Dropbox, but not all of the clients have Dropbox installed.  Two of the endpoints are actually pretty clean as far as non-M$ software.  The most frequent offender was the printer.  NETSTAT didnt reveal anything that looked suspicious to me, and by the time it finished listing the offending ports were not listed. 

Hopefully I've provided enough details.  Thoughts or ideas ?  

I am also having this problem currently with SEP 12.1.6 MU3. Logged blocks in the FW indicate SNMP and LLMNR traffic being blocked from the printer, which I presume is the cause. I too see it as hitting the default "drop all" rule at the end of the FW rules chain.  I've gone into the HP printer to shut off SNMP successfully, but having some problem finding the place to turn off LLMNR (not this forum's problem, I know).

My concern is that I _don't want_ to turn off LLMNR; I want SEP not to see my printer's "normal" activity as a threat, and I don't want to simply exclude the printer traffic from review, as another poster hesitantly did above. Any new news on this front?

RMichael

Was there ever a solution for this one?  I am also experiencing the same Port Scan attack alerts for LLMNR responses.  Seems to be only on one of our networks where most of the computers are in a Workgroup and not members of our Active Directory.  I don't necessarily want to turn off Network Discovery for these clients, but I also do not want to exclude them from all Port Scan detections either.

There was a supposed fix in 12.1.5 (I'm on 12.1.6)...

Fix ID: 3208344 Firewall incorrectly reports Link-local Multicast Name Resolution (LLMNR) response as a port scan Symptom: The Symantec Endpoint Protection client firewall incorrectly detects multiple Link-local Multicast Name Resolution (LLMNR) response packets as a port scan attack. Solution: Added UDP remote port 5355 to the firewall rule Allow LLMNR from private IP addresses to prevent the firewall from detecting this as an attack.

I've spent several days now going back and forth with Enterprise support on this to no avail. Since the above "fix" obviously wasn't working for me, I've think I've figured it out (at least for our scenario)...

Updated SEPM 12.1.4a to 12.1.6mp4, then began updating Win 7 Pro 64 bit clients from 12.1.4013.4013 to 12.1.6867.6400

Noticed SOME of the updated clients 12.1.6867.6400 began popping Port Attacks and doing Block All on local lan ip addresses including SEPM server. The most troubling part of all of this to me is that only 2 of the initial 5 upgraded stations exhibited this behavior, yet all were identically configured Optiplex 9020's and all were being fed the same policies (Clients completely locked down and Client User Interface Control Settings: Server mode).

Previous clients 12.1.1013.4013 in same group (same policies) that hadn't been upraded yet weren't exhibiting this behavior.

---

Problem Client 1 - Did an uninstall / clean wipe, did a client install from "12.1.6mp4 full download" of SEPx64 folder. Installed as unmanaged client, default settings (disable Defender), installed successfully, launched LiveUpdate by itself, completed updates, asked to restart. Restarted. Popups of port attacks from LAN began immediately. I rolled that client back to 12.1.4013.4013 and the problems ceased.

I don't have an explanation for why this client didn't work after fresh unmanaged install, perhaps the default unmanaged client rules are broken as well. I've read on another thread someone having a similar problem with an unmanaged client and the "fix" from Symantec was to go into the firewall rules on the client and make some trivial change like renaming a rule, and then saving. I did not try this before rolling this station back so I can't verify this.

---

Problem Client 2 - I created a duplicate group in SEPM, moved that client to that group, duped the firewall policy from existing group. I discovered that when I changed in SEPM -> Client User Interface Control Settings: Server to EITHER Client or Mixed mode the problem went away! As soon as I set back to Server mode and update policy, the blocking immediately began again. This points to something wrong with the SEPM's default firewall rule for "LLMNR from".

I set the mode back to Server and began experimenting with the SEPM firewall rules for that client. I changed the rule from "None" to "Write" so I could see when it was being applied, it wasn't. Here's what finally made it work for me, I deleted all of the private IP Ranges and added a new IP Subnet for our network, on client I right clicked "Update Policy", then it worked. So it appears that either something is broken with the IP Range field in that rule OR making this change triggered a sync of the SEPM rules to the client.

I had made dozens of changes and policy updates of the SEPM firewall rules prior to switching the field from IP Range to IP Subnet, so if just changing something trivial was the answer, the problem would have resolved much earlier. So this leads me to lean towards my "broken IP Range field" theory.

Hope this helps someone.

I experienced the same issue with SEP 12.1.5 (12.1 RU5) build 5337, 12.1.5337.5000. I was able to fix the issue by adding the remote UDP port 5355 to the firewall rule Allow LLMNR from private IP addresses. Under the firewall rules, double click the Service field for Allow LLMNR from private IP addresses:

Click the Add button to add remote UDP port 5355:

Hope this helps someone that is having this issue.
Regards,
Cameron