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