Одним прекрасним весняним вечором, коли йти додому не хотілося, а невгамовне бажання жити і пізнавати свербило і палило аки розпеченим залізом, виникла ідея поколупати привабливу приблуду фічу на файрволі під назвою «IP DOS policy".
Після попередніх ласок та ознайомлення з мануалом налаштував у режимі Pass-and-Log, щоб подивитися взагалі на вихлоп та сумнівну корисність даної настройки.
Через пару днів (щоб статистика набралася, звичайно, а не тому, що забув) глянув у логи і, пританцьовуючи на місці, заляпав у долоні — записів набралося по саму не балуйся. Здавалося б, чого простіше — вмикай політику в режим блокування всіх флудуючих, скануючих, які встановлюють напіввідкриті сесії з баном на годину та спи собі спокійно з усвідомленням того факту, що кордон на замку. Але 34-й рік життя подолав юнацький максималізм і десь на потиличній ділянці мозку пролунав тоненький голосок: «А давай піднімемо повіки і подивимося, а чиї ж адреси наш улюблений файрвол розпізнав як злісних флудильників? Ну так, у порядку марення.»
Починаємо аналізувати отримані дані зі списку аномалій. Проганяю адреси через простенький скрипт Powershell і очі натикаються на знайомі літери google.
Тру очі, моргаю хвилин п'ять, щоб переконатися, що мені не здалося - дійсно в списку тих, кого файрвол вважав злісним флудильником, тип атаки - udp флудадреси, що належать корпорації добра.
Луску в потилиці, попутно налаштовуючи на зовнішньому інтерфейсі захоплення пакетів для подальшого аналізу. У голові проносяться райдужні думки: «Як так, щось інфіковане у скоупі Google? І це виявив я? Та це ж, це ж нагороди, почесті та червона килимова доріжка, і своє казино з блэкджеком і, ну ви зрозуміли…»
Розбираю отриманий файл Wireshark-ом.
Так, дійсно з адреси з скоупу Google Фігачат пакети UDP з 443 порту на рандомний порт на моєму девайсі.
Але, заждіть… Ось протокол змінюється з UDP на GQUIC.
Семен Семенич…
Відразу ж згадується доповідь з Високе навантаження Олександра Тоболя «UDP проти TCP чи майбутнє мережевого стека»().
З одного боку, настає легке розчарування - ні тобі, пан, лаврів, ні почестей. З іншого боку, проблема зрозуміла, залишилося зрозуміти куди та скільки копати.
Пару хвилин спілкування з Корпорацією Добра – і все встає на свої місця. У спробі покращити швидкість доставки контенту компанія Google ще 2012 року анонсувала протокол QUIC, що дозволяє прибрати більшу частину недоліків TCP (так-так, у цих статтях - и говориться про цілком революційний підхід, але, будемо відверті, хочеться, щоб фоточки з котиками завантажувалися швидше, а не ось ці всі ваші революції свідомості і прогресу). Як показало подальше дослідження, на такий варіант доставки контенту багато організацій зараз переходять.
Проблема в моєму і, я думаю, не тільки в моєму випадку виявилася в тому, що пакетів у результаті йде дуже багато і файрвол сприймає їх як флуд.
Варіантів рішення виявилося небагато:
1. Додати до списку винятку для DoS Policy на файрволі скоуп адрес Google. При одній тільки думці про діапазон можливих адрес очко почало нервово смикатися — відкладено ідею як марення.
2. Підвищити поріг спрацьовування для udp flood policy — теж не комільфо, а раптом хтось справді шкідливий прошмигне.
3. Заборонити звернення з внутрішньої мережі UDP на 443 порт назовні.
Почитавши додатково про реалізацію та інтеграцію QUIC в Google Chrome було прийнято як вказівку до дії останній варіант. Справа в тому, що, коханий всіма повсюдно і нещадно (не зрозумію за що, краще вже нахабна руда Firefox-овська морда отримуватиме за відіпані гігабайти оперативки), Google Chrome спочатку намагається встановити з'єднання з використанням свого вистражданого QUICАле якщо дива не відбувається, то він повертається до перевірених методів типу TLSхоч і соромиться цього дичайше.
Створюємо на файрволі запис для сервісу QUIC:
Налаштовуємо нове правило і розміщуємо його десь вище в ланцюжку.
Після включення правила у списку аномалій тиша та гладь, за винятком справді злісних порушників.
Дякую всім за увагу.
Використані ресурси:
1.
2.
3.
4.
Джерело: habr.com