Няўдалае тэхнічнае рашэнне дорага абышлося арганізатарам галасавання ў Каардынацыйную раду

Падчас выбараў у Каардынацыйную раду паведамлялася пра маштабныя ддос-атакі на першапачаткова абраную платформу. У выніку галасаванне было перанесена на іншую платформу.

Мы задаліся пытаннем, чаму так здарылася. І галоўнае: чаму правесці галасаванне там не ўдалося, тады як многія незалежныя ініцыятывы спакойна на аналагічнай платформе працуюць.

Арганізатары выбараў у КР заяўлялі пра гіганцкія колькасці запытаў: 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 годзе, было рызыкоўным з розных прычын і выкарыстоўваць такое рашэнне больш не варта. 

Ці можна было старонку галасавання зрабіць лягчэйшай? «Можа, і рэальна. Але гэта азначае, што трэба ўсё рабіць сваё. А людзі, хутчэй за ўсё, выкарыстоўвалі гатовыя бібліятэкі», — сказаў нам беларускі праграміст, які працуе ў Партугаліі.

• 6
• 6
• 2
• 14
• 5
• 5
• 0
• 1