Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • +3 person also asked this people also asked this
  • Locked Locked
  • Replies 39 replies
  • Answers 5 answers
  • Subscribers 14 subscribers
  • Views 1025022 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Google & "UDP flood" action

AlexanderTsui
Hello

So to get straight to the point, I'm running Sophos UTM (FW Ver.: 9.203-3, Virtual) Home License and, as the thread title shows, browser-based Google products are affected by the IPS and some of its traffic are being tagged by the IPS as "UDP flood" firewall rule 60013, which is to Drop UDP_FLOOD attempts. 

As a result, some Google products will be capped at 2mbps download speeds. Strangely enough, it only happens to one wired client and not any virtualised clients nor wireless clients (so this means neither the LG Smart TV running YouTube nor the Android smartphone running Google Maps experience this issue.) When this plays out:

  • YouTube will load videos at 2mbps, causing buffer to 1080p videos and less often to 720p videos; and
  • Google Maps will load its chunks of map and image data slowly


Now, I can definitely turn off UDP flood protection, but that leaves a gigantic gap on my network. It's probably not the best practice when the UTM is responsible as the gateway between the Internet and my network at home. You now understand why this is probably something I would consider to avoid. I had disabled it for a minute and it definitely increased the loading speeds to what my ISP provides, which is 30x more than what it was throttling me to. As of right now, it's enabled.

Has anyone else experienced this issue? Has anyone found a fix for this? This started happening probably around the time where the OpenSSL Heartbleed vulnerability was discovered, if not a month or two before it.

UPDATE: Alright, so here's what's getting hit by IPS so that we all have that general idea...

IP of Google is the source IP. 
WAN IP is the destination.
Action is UDP Flood
Source Port: 443
Destination Port: Some random port on the 50000~60000s. 

Last time I checked, 443 isn't exactly UDP for the nature of what's being transported and a corporation like Google would keep atop for any such UDP floods to prevent it from happening.

Second Update:
Please don't tell me this is too difficult. It has to be some simple explanation. 
2014:07:14-16:40:20 core ulogd[4786]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" initf="eth1" srcmac="[Source MAC]" dstmac="[Destination MAC]" srcip="206.111.13.173" dstip="[My WAN IP]" proto="17" length="1228" tos="0x00" prec="0x00" ttl="57" srcport="443" dstport="55971"


Thanks


This thread was automatically locked due to age.
  • 0 in reply to DouglasFoster

    It's 2000 hours here.  I'd say google drive is doing pretty well with tcp.

    Left waveform is upload, right is download.

    What's interesting, on a modern android cell phone (snapdragon 820, 4gb ram, ac wifi capable of 300 mbps sustained speeds), I can only upload/download at 2-3 MB/s (16-25 mbps).  Google photos does better at about 80 mbps.

  • 0 in reply to DouglasFoster

    This whole discussion raises a larger security issue.

    Google has demonstrated that UDP can be useful for talented developers to roll a custom protocol that bypasses normal security checks.    It brings back a recollection of reading that some malware has also been seen using UDP to implement a hidden protocol that bypasses normal firewall security.

    Google's research, referenced in the QUIC article, indicates that most organizations do not block outbound UDP, and most firewalls allow UDP responses.   Organizations are not blocking outbound UDP because it is so hard to build the expertise about"normal" outbound traffic to know what must be allowed before implementing an outbound block.

    It is probably time for the industry to start blocking UDP by default.   If you are forwarding all external DNS traffic to Quad9, Google, Norton DNS, or your ISP, then you don't even need to allow UDP 53 globally, just to and from those servers.

    But I will have to collect some logs to know what other UDP traffic lurks on my network.   Fortunately, UTM has the tools to do so.

  • 0 in reply to Jay Jay

    The QUIC Response doesn't need to be in 'Allowed Target Services' or in your Firewall Block rule.  It does need to be in an Exception for Anti-UDP Flooding for "Internet IPv4 -> QUIC Response -> Any" traffic.

    Cheers - Bob

  • 0 in reply to BAlfson

    Bob,

    Can you post a pic of what it's supposed to look like?  Still getting IPS UDP flood notices in the log with just the response service.

  • 0 in reply to Jay Jay

    I was just trying to be specific.  What I use is really much simpler:

    If this doesn't resolve the issue, please post a representative line form the Intrusion Prevention log.

    Cheers - Bob

  • 0 in reply to BAlfson

    ^^Right.  You have both the response and initiate service.  That does work.  Your earlier post suggested you were just using the QUIC response service only.

    -----

    brings up a valid point.  Is this a pinhole that should be allowed just to permit access to several google services. After playing with this for a day, I'm falling back on the KISS concept. I don't see significant improvement in speed with udp vs tcp. By blocking 443/udp (in the firewall) altogether eliminates the udp flood lines in IPS. This seems to be the best solution unless I'm overlooking something.

  • 0 in reply to Jay Jay

    I think I said above that I like to block QUIC with a firewall rule to make Chrome>Google go through the Transparent Proxy, but to add QUIC to 'Allowed Target Services' to let the Standard Proxy use it - that's the reason for the Intrusion Prevention Exception.  I haven't measured the effect.

    Cheers - Bob

  • 0

    Can anybody explain like I'm 5 years old why this is happening?  I haven't been able to figure out why my Google services at home have been so painfully slow for the past 6 months and just started disabling every feature on my router until finding out it was the UDP flood protection causing this issue.  I have read through the thread, but I honestly do not understand what is causing this.  I don't mind having UDP flood protection disabled, as I am running UTM on a home network behind a dynamic IP that rarely, if ever, gets attacked.  I am still very curious as to what the root cause of this issue is, though.  It is affecting services like Google Photos and was capping my downloads at about 250 Kb/s.  I can understand why YouTube would cause this issue, since video is sent in a UDP stream, but I do not understand why this is happening to TCP streams, as well.  As part of my troubleshooting, I tried using an anonymous VPN service I have that can saturate my 300mb/s line and restricted the VPN session to TCP traffic only.  Google services would still be extremely slow.  This just does not make sense to me at all.  Any insight would be appreciated.

  • 0

    Hi Alexander

     

    I personally recommend to disable flooding protection anyway (that's a protection feature of antic times before DDoS attacks and the capability to easily flood your whole uplinks and is today of low value and usually creates more troubles than benefit.

     

    However - if you get flooded from Google with UDP traffic from source Port 443 to a high port of your firewall, I'd assume that's QUIC traffic. This also means it bypasses your UTM/XG's web proxy security completely. There's a "Block QUIC" option in the web proxy to block QUIC and force Google services to fallback to standard HTTPS over TCP.

     

    While QUIC is performancewise a good thing, it's today also a insecure thing because of the completely unfiltered traffic.

     

    Blocking QUIC most likely also solves your UDP flood problem.

     

    /Sascha