UDP Flood from Google or how not to deprive all Youtube

One beautiful spring evening, when I didn’t want to go home, and the indefatigable desire to live and learn fell and burned like a hot iron, the idea came up to poke a tempting stray feature on a firewall called " IP DOS policy ".

After preliminary caresses and familiarization with the manual, I set it up in Pass-and-Log mode to look at the exhaust in general and the dubious usefulness of this setting.

After a couple of days (so that the statistics were collected, of course, and not because I forgot), I looked at the logs and, dancing on the spot, clapped my hands - I did not indulge in any records. It would seem that it’s easier - turn on the policy in the blocking mode of all floods, scans, which establish half-open sessions with a ban for an hour and sleep calmly with the knowledge that the border is locked. But youthful maximalism overcame the 34th year of life, and somewhere in the back of the head a thin voice sounded: “Let's raise our eyelids and see whose addresses our beloved firewall recognized as malicious flood-makers? Well, in the order of delirium. "



We begin to analyze the data obtained from the list of anomalies. I drive the addresses through a simple Powershell script and my eyes stumble upon the familiar google letters.







I rub my eyes, blink for about five minutes, in order to make sure that I didn’t think of it - it’s really on the list of those whom the firewall considered a malicious flood-maker, the type of attack is udp flood , addresses belonging to the corporation of good.













I scratch my head, simultaneously setting up packet capture on the external interface for further analysis. Rainbow thoughts flash through my head: “How is it that something is infected in the Google scope? And did I find this? Well, well, well - awards, honors and a red carpet, and your own casino with blackjack and, well, you understand ... "



I parse the resulting Wireshark file.

Yes, indeed, UDP packets from port 443 to the random port on my device are shown from the address from the Google scope.

But wait a minute ... Here the protocol changes from UDP to GQUIC .

Semen Semenych ...







Immediately I recall a report from High Toad by Alexander Tobol " UDP against TCP or the future of the network stack" ( link ).

On the one hand, there is a slight disappointment - neither to you, gentleman, laurels, nor honors. On the other hand, the problem is clear, it remains to understand where and how much to dig.

A couple of minutes of communication with the Corporation of Goodness - and everything falls into place. In an attempt to improve the speed of content delivery, Google back in 2012 announced the QUIC protocol, which allows to remove most of the shortcomings of TCP (yes, yes, in these articles - Rrraz and Dva talk about a completely revolutionary approach, but, to be honest, I want to fotochki with cats loaded quickly, and not these revolutions of your consciousness and progress). As further research has shown, many organizations are now transitioning to a similar content delivery option.

The problem is mine and, I think, not only in my case it turned out that in the end there are a lot of packets and the firewall perceives them as a flood.

There were few solutions:

1. Add to the exclusion list for DoS Policy on the firewall scopes of Google addresses. Just thinking about the range of possible addresses, the eye began to twitch nervously - the idea was postponed as delusional.

2. Raising the response threshold for udp flood policy is also not comme il faut, but suddenly someone who is really malicious will slip through.

3. Prohibit calls from the internal network via UDP to port 443 out.

After reading additionally about the implementation and integration of QUIC in Google Chrome , the last option was adopted as an indication of action. The fact is that, beloved by everyone everywhere and mercilessly (I don’t understand why, it’s better to get the impudent red-haired Firefox -muzzle for the consumed gigabytes of RAM), Google Chrome initially tries to establish a connection using its suffered QUIC , but if a miracle does not happen , then he returns to proven methods such as TLS , although he is ashamed of this wildest.



We create an entry for the QUIC service on the firewall:







We configure a new rule and place it somewhere higher in the chain.







After the inclusion of the rule in the list of anomalies, quiet and smooth, with the exception of really malicious violators.







Thank you all for your attention.



Resources Used:

1. Report of Alexander Tobol

2. Description of the QUIC protocol from Infopulse

3. Wikipedia

4. KB from Fortinet



All Articles