Няўдалае тэхнічнае рашэнне дорага абышлося арганізатарам галасавання ў Каардынацыйную раду
Старонка для галасавання была «тлустая», а галасаванне было арганізаванае на платформе storage.googleapis.com. У выніку ддос наносіў нашмат больш страт арганізатарам галасавання, чым атакуючаму боку.

Падчас выбараў у Каардынацыйную раду паведамлялася пра маштабныя ддос-атакі на першапачаткова абраную платформу. У выніку галасаванне было перанесенае на іншую платформу.
Мы задаліся пытаннем, чаму так здарылася. І галоўнае: чаму правесці галасаванне там не ўдалося, тады як многія незалежныя ініцыятывы спакойна на аналагічнай платформе працуюць.
Арганізатары выбараў у КР заяўлялі пра гіганцкія колькасці запытаў: 1,3 мільярда.
Спачатку галасаванне было арганізаванае на платформе storage.googleapis.com. Гэта таннае, надзейнае, з бясконцым запасам аб'ёму сховішча ад Гугла, якім карыстаюцца кампаніі для захавання архіваў, даных, вобразаў, файлаў. З гэтага сховішча толькі бяруць інфармацыю пры звароце, іншага функцыяналу ў яго няма. Таму Гугл тарыфікуе аб'ём аддадзенага трафіку з адраса і таксама колькасць запытаў да яго.
У інструкцыях па карыстанні Гугл наўпрост папярэджвае, што магчымасці па абароне такога адраса мінімальныя і, па сутнасці, зводзяцца да дазволу браць інфармацыю з бакета толькі з дазволеных ІР, адсякаючы ўсіх астатніх. Гугл раіць кліентам рабіць адрасы бакетаў такімі, каб іх немагчыма было адгадаць. Між тым адрас платформы для галасавання КР быў расшараны ў публічным доступе.
Гугл таксама папярэджвае, што пры павышэнні колькасці запытаў да бакета будзе паступова павялічвацца магутнасць, каб задаволіць усе запыты. Але гэтыя запыты будуць тарыфікавацца. Магчымасці паставіць абмежаванне па бюджэце ў гэтым выпадку няма.
Такім чынам, пры масавых запытах на яго, напрыклад, пры ддос-атацы, ва ўласніка адраса адпаведна будзе расці рахунак ад Гугла — асабліва пры ўмове, што з гэтага бакета аддаецца нейкая адчувальная колькасць інфармацыі.
Беларускія незалежныя СМІ таксама карыстаюцца бакетам Гугла як рамкай для сваіх сайтаў. Перавага ў тым, што такую спасылку ў Беларусі немагчыма заблакаваць — інакш паваліцца куча важных для эканомікі сэрвісаў. Акрамя таго, гэта адносна бяспечна: правайдар не бачыць нічога далей за storage.googleapis.com/.
Калі ддосяць бакеты СМІ — а іх ддосяць рэгулярна — доступ да іх або не спыняецца, або спыняецца на лічаныя хвіліны. Больш за тое, СМІ наладзілі свае платформы так, што такая ддос-атака каштуе яе арганізатарам нашмат даражэй, чым уласнікам бакета. Таму што праз нікчэмную колькасць аддадзенай у адказ інфармацыі цана атакі робіцца непрапарцыйна вялікай адносна нанесенай шкоды.
«Кантэнт бакета праз нашу сістему вельмі дробны, бо мы аддаём пару кілабайтаў, а не ўвесь злепак старонкі. Таму кошты з нашага боку ў моцныя атакі не так дужа растуць, як з боку атакантаў», — патлумачыў «Нашай Ніве» ІТ-інжынер, які наладжваў такую сістэму для аднаго са СМІ.
У выпадку ж з галасаваннем у Каардынацыйную раду ёсць падставы меркаваць, што кожная аддача з бакета па адрасе https://storage.googleapis.com/ccelect26/index.html/… складала не долі кілабайтаў, а каля 3,4 мегабайт. Прынамсі, такая аддача фіксавалася пры звароце на сайт https://rada2026.svaepeera.com, на які пераехала галасаванне пасля атак на бакет.
Мы замяралі гэтую аддачу ў тэрмінале:
index-DnQoUsja.js: 881 bytes
lib-BZRoH1pn.js: 2581282 bytes
index-CPW0kV3N.js: 802688 bytes
Прасцей кажучы, старонка для галасавання была «тлустая» — магчыма, перагружаная цяжкімі скрыптамі і не аптымізаваная.
Гэта дазваляе таксама зрабіць выснову, што ўласнік бакета, на якім было спачатку разгорнутае галасаванне, панёс страты. Магчыма — вялікія, парадку дзясяткаў тысяч даляраў.
«Наша Ніва» спытала ў Паўла Лібера, які дапамагаў Каардынацыйнай радзе ў арганізацыі галасавання.
«Паколькі выдаткі ў сувязі з атакамі не кампенсуюцца мне ні з якіх грошай, акрамя маіх уласных, я не планую іх раскрываць», — адказаў Лібер.
Ён таксама патлумачыў, што сайт для галасавання наўмысна распаўсюджваўся праз публічны Гугл-бакет, таму што, мяркуе ён, «такая спасылка больш бяспечная пры выпадковым заходзе з Беларусі, паколькі для тэлекам-правайдараў першаснай з’яўляецца бачнасць дамена Google».
«Калі мы выявілі, што атакі маюць высокую інтэнсіўнасць і здольныя перапоўніць сутачныя ліміты гэтага бакета (тады людзі замест сайта бачаць памылку), мы перайшлі на звычайны сайт + Cloudflare і прымалі асноўныя ўдары ўжо туды.
Таксама Лібер звяртае ўвагу, што «выбары перанеслі не таму, што была DDoS-атака, а таму, што былі ўнесеныя змены ў тэхнічнае заданне, і прадстаўнік камісіі тэставаў гэтыя змены, у выніку чаго тэрмін старту перанеслі на 12 мая а 12:00 — пра гэта гаварылася ў публічным анлайн-стрыме камісіі».
Спецыяліст па кібербяспецы з 20‑гадовым досведам, з якім кансультавалася «Наша Ніва», мяркуе інакш. На яго думку, тэхнічнае рашэнне, выкарыстанае для галасавання ў Каардынацыйную раду ў 2026 годзе, было рызыкоўным з розных прычын і выкарыстоўваць такое рашэнне больш не варта.
Ці можна было старонку галасавання зрабіць лягчэйшай? «Можа, і рэальна. Але гэта азначае, што трэба ўсё рабіць сваё. А людзі, хутчэй за ўсё, выкарыстоўвалі гатовыя бібліятэкі», — сказаў нам беларускі праграміст, які працуе ў Партугаліі.
Каментары