Endpoint Protection

Anyone else notice DoS messages "Denial of Service "UDP Flood Attack" attack detected. Description: An excessive number of User Datagram Protocol (UDP) packets are being generated on this computer causing 100% CPU utilization"

This started after I started upgrading clients from RU5 to RU6. The details show the traffic to be inbound from our internal DNS servers. Is it possible that RU6 introduced a change to cause a false positive or maybe RU 5 DoS protection wasn't working correctly. As crazy as it may sound this message doesnt appear until I upgrade to RU6.

We haven't seen or heard of that from both our internal and external beta customers.

Can you easily reproduce?

Attach the Logs. So that we can understand

Regards...
Ramji Iyyer

Yes, I saw this as well immediately after upgrading to RU6 on one of my test boxes. Traffic from two different machines in remote locations were blocked. One machine was not even on at the time, the other was on. The machine that was on had been infected with Conficker (not anymore though)

As I take a look at the logs, I can see a reference to W32.Downadup.B, C in there so I'm guessing it has something to do with those being infected at some point in the past. I can only speculate as to why a machine that was already turned off would be blocked. I would attach logs but I don't see an export button in the particular log view (Client Management Logs - Security Log)

Which logs do you want me to attach? i've got a case open with Symantec as well.

Can you post your case number? This is an issue that we definitely want to follow up on. Is it possible that you could post some steps to get this to easily reproduce the issue so we can replicate it in our tests boxes? So far I have been unable to do so.

Thanks
Grant

Case number 411-949-901. I was out of my office yesterday so I missed the call from support. I'm following up with them today. I will need to get a system experiencing this issue to try and reproduce it. What's interesting is that I've upgraded XP, and Win 7 (x86, x64) clients to RU6 and so far only the XP clients are triggering this IPS detection. All are using the same shared IPS policy.

Symantec support confirmed that the DoS protection was not working properly in RU5. RU6 resolved this issue and explains why we began seeing this issue. Resolution is to add our DNS servers to the host exclusion list and/or find out why these systems are receiving too many UDP packets from our DNS servers.

I appreciate you coming back and letting us know. Very helpful for future users : )

Grant-

Please post any additional information regarding this issue.  Can threshholds be listed in this forum to know what we have to change on our DNS servers?  This will help to determine if we should focus on a DNS fix or just create an exception for our DNS servers.

Anyone who reads this and comes up with a solution besides adding exceptions, please reply!

Adding our DNS server IP's to the host exclusion for IPS stopped the issue internally but we started seeing the same issue for users at home. We use a different IPS policy for the home location and there's no way we can keep up with everyones home DNS/Gateway IP address. The home users are having their router detected as the DoS.

We are looking at turning this feature off until we know why these DoS are occuring at home and on the corporate network.

One of our testers noticed this happened when he had a Windows 7 system and was using XP mode although not all of our testers are using Windows 7.

Same issue here:

I had a policy applied to all 260 domain controllers that essentially disabled IPS (all boxes were unchecked) however after the servers rebooted Sunday morning following their WSUS updates, all 260 server's DNS server service failed to start which caused considerable headaches this morning....

With the Firewall, withdrawing the policy disables the firewall completely, does the same apply for IPS? Only I was under the impression that you need to apply an IPS policy with nothing ticked in order to disable that componant? Nothing like a bit of regularity in a product huh!!

It definitly sounds like we have a bug or issue with DoS and RU6. I was originally told by support that DoS detection didn't work correctly in RU5 but was fixed in RU6... I'm not so sure now...

I'm seeing this issue on a Windows 7 64-bit machine (unmanaged) with RU6 as well, never saw it on RU5.  I can't imagine that all our DNS servers are sending excessive UDP packets and that this new behavior is a "fixed" version of IPS in RU6.  I'm only getting the DoS warning from DNS servers, nothing else.

I'm also seeing a lot of blocked IPv6 traffic in the firewall log, probably due to broadcast traffic in Windows 7.  Even when I disable the two default IPv6 rules it still reports blocked traffic.  If I disable IPv6 on the adapters it looks OK, but again I never had to do this in RU5.

What's the story here?

I am very careful with the IPS policy setting that blocks an "attackers" IP address for X amount of seconds.
Seems like a perfect way to block all of your critical servers if there is a false positive.

That setting to me has too much associated risk for server based systems.
In an outside network location I have it enabled but interally it is turned off by default.

Z

I have the same issue with the ru6. I've attached the security log.

Still no feedback from Symantec? Excluding one or another IP-address isn't a real solution in my opinion.

Does anyone have any idea of the threshold of UDP packets that causes this to be triggered¿¿¿¿¿  I've contacted Symantec Support and they couldn't answer this!  All they wanted to do was connect to my computer to see the pop-ups!

I need some idea of how to adjust this one DoS Attack instead of unchecking the box to turn off all DoS attacks.  Any assistance would be GREATLY appreciated.

This has also been confirmed in RU6a.  If anyone needs it, I have a case number of 412-090-904.

Any additional information on this is stil appreciated!

Is it possible to remove the "solved" designation on this thread?  It's clearly not solved since it looks like we have a bug.

RU6a only looks to address a migration issue and the reported problem with the Java console.

I've done a wireshark trace and noticed that when a site does lots of DNS requests in a short time (here 18 DNS request in 1,5s) the DOS feature of SEP comes in.
So I suppose Symantec should increase the number of requests/sec before potential DOS is detected or we should have the possibility to control this value ourselves through the console.

So it sounds like for now, DoS protection should be disabled ?? or a host exclusion list put in place ?

Host exclusion will only work internally as soon a laptop goes out to the rest of the world, the host exclusion is useless,
We can't disable DOS protection because of this new feature 
This feature needs to be looked at and fixed by Symantec prior to us rolling ru6a

I'm checking with Security Response to see if they have any info.

Thanks for your patience.

I'm getting this even plugged into a Linksys router at home, certianly my laptop shouldn't be doing enough DNS requests to trigger this, seems like the threshold for the new IPS is set way too low.

This seems to be happening a lot when computers go off their corporate network and seems like a bigg issue with Comcast DNS servers. How many are experiencing it on their corporate network?

Granted, it's an issue but seems to happen more so off network than on.

Like I mentioned before we started seeing this on our corporate network and then our home users started complaining about similar issues. After looking at the logs I was finding users home gateways/routers being blocked because they act as their DNS server.

This is a big issue in my opinion and needs to be patched asap.

Agreed, while we can set policy as a work-around for in office use, once they're outside the corporate network it's just not realistic to handle it this way.  I've had to disable IPS entirely, not what I wanted to do but the only option until a patch is released.  I just don't understand how this wasn't found during testing, did no one take a laptop with RU6 on it home?

You may want to leave your IPS on, but disable the Denial of Service Detection.  This is a check box in the IPS settings.

I have gotten information from a Symantec source that the threshold is set to 15.  This is definitely a low setting.

Also, I notice that Internet Explorer seems to have less DNS traffic than Firefox or Chrome (at least in our environment).

I agree. You can disable this feature while leaving IPS enabled for the other protections. In my opinion the DoS detection feature based on thresholds offers very little value

I hope this link works.  I've entered a suggestion in the Symantec Ideas site.  Please vote on this so that it will get a higher visibility and be addressed.

https://www-secure.symantec.com/connect/idea/increase-denial-service-udp-flood-attack-threshold-0

DoS was working as designed in RU5. I got that straight from support and development. I've had two cases open for over a month, they were just closed due to "working as designed".
Cass was helping me - cases 320-239-573 and 411-752-839
What was happening - servers were reporting DoS attacks from our own computers, more specifically, this was happening constantly with DCs.
I had the "block traffic for xxxx" TURNED OFF. Found out that SEP STILL blocks ALL pings of all sorts from all sources for several seconds REGARDLESS of if that's enabled or not. It was enabled and folks couldn't even get logged in and policies would not apply, etc. - because XP machines PING the DCs several times, and if they can't ping, you have trouble. 10 minutes was a huge amount of time, so I decided to uncheck that and have it not block at all.
That's when I learned that it will block regardless of that setting, for roughly 15 seconds or so. When it sees a DoS it blocks ALL pings, period. I could prove it by setting up two computers with a ping -t dcaddress and monitor. Every so often, the pings would drop for like 5 or 6 tries. When I checked in wireshark, there was a large number of FRAGMENTED packets and pings coming through in like 1 second. Most from a single computer, but when that combined with similar pings from other computers within that 1 seconds, SEP reacted blocking traffic for several "pings" and I saw the pings drop from both of my test computers.
So the solution - move the DCs into a sub-group and disable DoS detection. I still run full IPS, but uncheck DoS detections.
We've been ok since that time.
Symantec if you need to post info from the above cases, feel free to do so, just remove names if you would.
Otherwise if my case info is helpful to anyone, feel free to share it.

LOL - as a government agency, even my salary is public record  ;-)

15 detections in 1 second, any source - it blocks for several seconds - EVEN WITH that 10 minute block feature NOT checked. Check how XP uses pings to check domain speeds, gets policies, etc. and you'll see what I went through.

BTW - Cass is a super tech to work with!!!!!!!! He was always helpful, patient, and did everything he could to get me information.

I just read another post that someone working with Symantec support stated Symantec will release a new IPS signature to fix this in a few days. The user said Symantec acknowledged that the IPS signature is applied differently in RU6 compared to RU5.

Anyways, I thought this was interesting since I was first told that DoS was not working in RU5 and was fixed in RU6. This came from Symantec support. I also experienced strange ping issues after upgrading to RU6 and had to move my ping firewall rules to the top.

Interesting in that it was working fine in RU5, at least "as designed" as confirmed by weeks of testing here.
So far I've seen no ill effects on IPS for having move to RU6 for some testing.
All quiet so far.

We have found that the DNS prefetching of most browsers can cause this trigger\threshold to be met more often than not.  By disabling DNS prefetching in web browsers, this alert is almost non-existent.

Feel free to try this as a solution to help your environment if you like, otherwise, we'll continue to wait for Symantec.

Uh, guess I've never seen nor heard of that in a browser.......... I sure have never seen such settings in what I use anyway.
Our issue with RU5 had zero to do with browsing. The computer was just sitting there and it blocked pings and traffic.

Hi ShadowsPapa,

That sounds like a separate issue.  I'd recommend checking the SEP traffic logs on the actual client machine (not from the SEPM) to see what may be blocking the pings and traffic.  If you see one of the strangely-named "GUI%GUICONFIG#" rules, then it's something set locally on that machine (probably through a simple checkbox in SEP).

Hope this helps!

No, it was confirmed from external sources. SEP's DOS was blocking things - the DCs receive hundreds of pings from the clients constantly. Some of the traffic was fragmented (we're not sure what's going on there!) and it was confirmed - and Cass had us turn DoS detection off on the DCs and life is better now.
We spent weeks diagnosing, with many dozens of tests and wireshark captures from clients, DCs, even ASAs.
RU5 blocks traffic any time it senses a threat, even if the active response is disabled. Cass confirmed with development - this is a known thing.

It was indeed RU5, and DoS detection doing it, and it was triggered by clients contacting the server.

We've had NO issues with web browsing at all from any SEP version, including RU6a, which I use and have seen no issues with at all to this point. Running on a few servers, including the domain controllers and my own computers, and about a dozen clients - no issues with RU6. However, I don't think I'll turn DoS back on on those DCs as it will block traffic when clients start to turn on and log in and contact the DCs

I missed the part about the issue being from the DC end.  I was thinking pings, etc. were being blocked on the client side.

We are working on fixing this issue.  If anyone is having this issue in SEP 11 RU6 we recommend disabling the Denial of Service (DoS) feature.  You can disable the DoS feature from on the Intrusion Prevention policy on SEPM.  Disabling this feature will stop these events from occurring.

Have customers that we are holding off on due to this issue.  6b soon?

i do no so mach, bat. i use in the new .net framework ver. 4
mybe this is Cause for that to hapen

sori for my bad english!

My user is getting this error too. Please advise when is the solution will release?

And does anybody know if its possible to do the workaround fix, through a registry setting?

Hi MPRS,

I don't know of a registry entry currently, but one of the following options should be fairly ok to use until then.  Hope this helps!

• Disable Denial of Service Detection (only this option, not the entire Network Threat Protection)
• Disable DNS Prefetching through your web browser (since this seems to be the biggest cause of the DoS alerts for now, but I'm sure it's probably not the only cause).

I'd like to know where DNS prefetching is - it's not in any of our browser options........... I can't find it anywhere.

I just had my first user complain about the DoS errors when connecting to his home Linksys router. I created a temp group and disabled the DoS protection. I am wondering what is the status of the fix? Also, this is a problem with the client not the SEPM correct? My thinking is...

Keep the RU6 SEPM, and roll the user client back to RU5, if the user is having issues. This would keep the DoS protection running.

Thanks,
Mike

Which browser are you currently using?  Chrome provides a check box (very nice of them).  Firefox makes you add in an additional boolean setting.

Chrome is banned here due to many other Google hijinks. Nothing "google" is allowed for several reasons, not the least of which is privacy and security reasons.

Firefox is used only by IT.

"The masses" use IE for compatability with the inhouse and other apps and such..........
There is no such setting in IE that I can see.

Can versions be rolled back?

@thatdude,

I meant uninstalled. So, uninstall RU6 client, push out RU5 client.

Mike

Ok thanks. It would be nice if we could do a version roll back from the console for things like this. It would make deployment of new version go quicker if it could be rolled back easily when a problem is found

I opened a case with Symantec when we started seeing this on campus.
I was told it couldn't be a false positive unless our DNS server had extremely low latency because after te initial DNS response there would have to be 10 more DNS responses within 100ms to trigger it. They said this would be impossible unless our DNS servers had less than 5ms latency. This contradicts what others have been told on the trigger level I believe.

Found that a web page like www.nytimes.com or www.thestar.ca both reference content on more than 10 hosts on the one page alone so unless I am misunderstanding, simply visiting that page will do more than 10 DNS lookups and since our DNS servers are on campus and have less than 1ms latency.

They asked me to send them network traces to confirm it was a false positive. I declined.

I happened to send an FYI note to my Symantec rep and copied his technical guy and got an email back on short order that indicated "known problem in RU6 and fixed in RU6 MP1"

Does anyone else feel like they are just wasting their time with Symantec and especially with Symantec support?

I was probably one of the first ones to open a case regarding this issue. Symantec asked me for traces but I could never obtain any. That being said I dont feel im wasting my time with Symantec support but I would like to get a straight answer and an acknowledgment that this is a ISSUE and a fix will be released.

Still not solved apparently. For me it's strange it takes such a long time to get a solution or at least a valid response from symantec.
Disabling DOS is a workaround but not really a solution I think.

Just stood up a new SEPM with RU6A.  Problem is still rearing its ugly head.  Can't be that tough of a fix.  Can you say LiveUpdate?

I also confirm that using RU6a on a windows 7 64bit (Server 2008R2) machine unmanaged will produce this error consistantly.  I see it every so often when using FF but 100% of the time using chrome.

stops internet traffic until you close the browser and reopen.

I also confirm that using RU6a on a windows 7 64bit (Server 2008R2) machine unmanaged will produce this error consistantly.  I see it every so often when using FF but 100% of the time using chrome.

stops internet traffic until you close the browser and reopen.

Is there any update on the status of this problem?

I think were all waiting for SEPv11 RU6 MP1 to be released.

soon, very soon...

Define soon  :)

meanwhile the service can be stop manually (right click on the system tray icon assuming the policy is allowed) while at home to prevent unnecessary browsing disturbance :-|

According to this thread (https://www-secure.symantec.com/connect/forums/endpoint-1106-false-denial-service-attacks-dns-servers).  It looks like RU6 MP1 hits this week!

Any reason why the updated bits are not available for regular downloading? My company has not decided if they want to upgrade or not, but I would like to download the update and patch my own system.

 

TrevorK

Well I suppose this problem has been fixed already in the MR6 MP1.

Has anyone still got problem with the latest version ?

It's fixed in RU6 MP1

we see something similar with an IT user is trying to remotely add a printer to another user's pc.  

steps to reproduce:

windows explorer - \\machinename - view remote printers - add a printer

-add local printer - standard TCP/IP port - enter printer dns name

at this point, it will usually fail to resolve the printer and get pop-up that traffic to the printer is now being blocked b/c of DOS.  

Windows 7 32x, occurs on both 11.06a and 11.06mp1.  IPS working as designed?

What is the version number of R6 MP1?  I have unmanaged at home with version 11.0.6000.550 installed.  This is a Windows 7 64bit machine and every time I open Firefox I get a DoS attack blocked by Symantec.

 

Reports of a machine that can be online for a short while then taken offline because of Denial of Service attack from the default gateway.  Our dd-wrt SOHO firewall does not have any port forwarding of any kind enabled.  UPnP is disabled.  DMZ is disabled.  So was their a recent regression?

 

Win7 64bit TabletPC