One beautiful spring evening, when I didn't want to go home, and the insatiable desire to live and learn was buzzing and burning like a hot iron, the idea arose to tinker with a tempting feature on the firewall called “IP DOS policy«.
After some preliminary affection and familiarization with the manual, I set it up in the mode Pass-and-Log, to see what the output was and to assess the questionable usefulness of this setting.
A couple of days later (to let the statistics accumulate, of course, not because I forgot), I looked at the logs and, dancing on the spot, I clapped my hands — there were records piled up to the brim. It seemed simple enough — just enable the policy to block all those flooding, scanning, establishing half-open sessions with a one-hour ban and go to sleep peacefully, assured that the border is secure. But having turned 34, I overcame youthful maximalism, and somewhere in the back of my mind, a tiny voice spoke up: "Let's lift our eyelids and see whose addresses our beloved firewall has recognized as notorious spammers? Just for fun."
We begin to analyze the collected data from the list of anomalies. I run the addresses through a simple script Powershell and my eyes catch familiar letters google.
Rubbing my eyes, I blink for five minutes to make sure I’m not imagining things — indeed, on the list of those whom the firewall considered to be a notorious spammer, the type of attack is udp flood, addresses belonging to the good corporation.
Scratching my head, I also configure the external interface to capture packets for further analysis. Rainbow thoughts fly through my mind: "How is it that something infected is within Google’s scope? And I discovered this? This is, this is — rewards, honors, and a red carpet, my own casino with blackjack and, well, you get it…"
I analyze the received file Wireshark-th.
Yes, indeed, packets are being blasted from an address within the scope Google of UDP packets from port 443 to a random port on my device.
But wait a minute… Here the protocol changes from UDP to GQUIC.
Semyon Semyonovich…
I immediately recall the report from HighLoad by Alexander Tobol «UDP against TCP or the future of the network stack ().
On one hand, there's a slight disappointment — no laurels, no honors for you, good sir. On the other hand, the problem is clear; it remains to understand where and how much to dig.
A few minutes talking with the Good Corporation — and everything falls into place. In an attempt to improve content delivery speed, the company Google announced the protocol back in 2012 QUIC, which allows eliminating most of TCP's drawbacks (yes, yes, yes, in these articles — and there is talk of a completely revolutionary approach, but, let's be honest, we just want pictures of kittens to load faster, not all these revolutions of consciousness and progress). Subsequent research showed that many organizations are now transitioning to this type of content delivery.
The problem in my case, and I think in others as well, turned out to be that too many packets were being sent, and the firewall perceived them as flooding.
There were only a few solutions:
1. Add to the exceptions list for DoS Policy on the firewall scope of addresses Google. Just thinking about the range of possible addresses made my eye twitch — the idea was shelved as absurd.
2. Increase the trigger threshold for udp flood policy — also not advisable, what if someone really malicious slips through.
3. Prohibit outbound requests from the internal network on UDP to 443 port outward.
After reading additional information on implementation and integration, the last option was accepted as the course of action. The thing is that the one beloved everywhere and mercilessly (I can't understand why, it's better to have the brazen red QUIC downward API support (simultaneously with this in Google Chrome -skinned face receive punishment for the consumed gigabytes of RAM), Firefoxinitially tries to establish a connection using its well-earned Google Chrome , but if the miracle doesn't happen, it resorts to tried and tested methods like QUIC, albeit with great shame. TLSWe create an entry for the service on the firewall
We set up a new rule and place it higher up in the chain. QUIC:
After enabling the rule in the anomaly list, everything is quiet and smooth, except for truly malicious violators.
Thank you all for your attention.
Resources used:
Report by Alexander Tobol
1.
2.
3.
4.
Source: habr.com
