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

Во время выборов в Координационный совет сообщалось о масштабных ддос-атаках на изначально выбранную платформу. В результате голосование было перенесено на другую платформу.
Мы задались вопросом, почему так случилось. И главное: почему провести голосование там не удалось, тогда как многие независимые инициативы спокойно на аналогичной платформе работают.
Организаторы выборов в КС заявляли о гигантских количествах запросов: 1,3 миллиарда.
Сначала голосование было организовано на платформе storage.googleapis.com. Это дешевое, надежное, с бесконечным запасом объема хранилище от Гугла, которым пользуются компании для сохранения архивов, данных, образов, файлов. Из этого хранилища только берут информацию при обращении, другого функционала у него нет. Поэтому Гугл тарифицирует объем отданного трафика с адреса и также количество запросов к нему.
В инструкциях по пользованию Гугл напрямую предупреждает, что возможности по защите такого адреса минимальные и, по сути, сводятся к разрешению брать информацию из бакета только с разрешенных IP, отсекая всех остальных. Гугл советует клиентам делать адреса бакетов такими, чтобы их невозможно было отгадать. Между тем адрес платформы для голосования КС был расшарен в публичном доступе.
Гугл также предупреждает, что при повышении количества запросов к бакету будет постепенно увеличиваться мощность, чтобы удовлетворить все запросы. Но эти запросы будут тарифицироваться. Возможности поставить ограничение по бюджету в этом случае нет.
Таким образом, при массовых запросах на него, например, при ддос-атаке, у владельца адреса соответственно будет расти счет от Гугла — особенно при условии, что из этого бакета отдается какое-то ощутимое количество информации.
Белорусские независимые СМИ также пользуются бакетом Гугла как рамкой для своих сайтов. Преимущество в том, что такую ссылку в Беларуси невозможно заблокировать — иначе повалится куча важных для экономики сервисов. Кроме того, это относительно безопасно: провайдер не видит ничего дальше за 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 году, было рискованным по разным причинам и использовать такое решение больше не стоит.
Можно ли было страницу голосования сделать легче? «Может, и реально. Но это означает, что надо все делать свое. А люди, скорее всего, использовали готовые библиотеки», — сказал нам белорусский программист, работающий в Португалии.
Комментарии
Вы ведаеце колькі там відарысаў было? Яны па-вашаму ня важаць ні аднага кілабайта? Проста ў бюлетэні маюцца нормы і іх трэ спаўняць нават на электронных выбарах.
І што значыць пісаць свае? Там жа стандртны фреймворк быў па тыпу React, там і радкоў было напісана можа зусім ня дужа, проста сёння такі стандарт напісання коду і сайтаў ў тым ліку.
Ведаю, што гавару, у самога дзесяць гадоў у гэтай індустрыі.
На мой погляд з усіх фактаў спадар намагаецца выбраць самыя брыдкія да падыходу імплемянтацыі спадара Лібера, тым болей за яго кошт, але дзеля бяспекі беларусаў