DEV Community: Navalny Team

Как мы делали приложение «Фотон-2024»

Navalny Team — Tue, 09 Apr 2024 12:58:49 +0000

В рамках кампании против Путина на президентских выборах в России в 2024 году IT-отдел команды Навального разработал приложение под Android и iOS, которое помогало случайным образом выбирать любого другого кандидата. Для этого приложение использовало аппаратный генератор случайных чисел, основанный на квантовом эффекте. Эту идею предложил Алексей Навальный.

Задача разработки приложения включала в себя требования непосредственного подключения к аппаратному генератору в офисе ФБК, устойчивости приложения к нагрузкам и блокировкам и обеспечения приватности пользователя. В этой статье мы раскрываем некоторые технические подробности реализации.

Выбор устройства и покупка квантового генератора

Алексей темой случайности озаботился еще во время изучения языка Python. Когда он столкнулся с функцией random, то заинтересовался, как работает случайность в скриптах, которые он писал во время обучения. Откуда конкретно берется случайное число?

В 2019 году он узнал о том, что компьютерная случайность не есть истинная случайность, что это псевдослучайность. Когда выполняется random.random() в скрипте, случайное число не рождается во Вселенной из ничего, а основано на простой математике — на так называемых вихрях Мерсенна.

Изучение природы случайности Алексей продолжил и в заключении. Чтение биографии Эйнштейна и подробное знакомство с квантовой физикой дало ему идею, откуда можно брать истинную случайность — из фотонов, частиц света.

В начале XX века Эйнштейн и Бор начали знаменитый спор о том, являются ли случайные процессы в квантовом мире лишь кажущимися, случайными, или же они истинно случайные. Этот спор с Бором многие знают по фразе Эйнштейна «Бог не играет в кости!». Так Эйнштейн выразил позицию, что истинной случайности нет, а есть просто скрытые параметры, которые и создают кажущуюся случайность в квантовых процессах. Через полвека после спора наука смогла проверить экспериментально через неравенства Белла, кто же прав, — и прав оказался Бор. Его интерпретация квантовой механики, называемая копенгагенской, до сих пор главенствует в науке.

Когда в конце сентября 2023 возник спор о стратегии голосования на президентских выборах, Алексей вспомнил идею о случайности, создаваемой фотонами, и предложил переложить моральную ответственность выбора «любого другого кандидата», за которого можно было бы проголосовать в рамках кампании против Путина, на генератор истинно случайных чисел. Так родилась идея приложения «Фотон», где реальный фотон будет определять случайного кандидата.

Что важно: Алексея не устраивал простой псевдорандом, ему нужен был реальный фотон, летящий и делающий выбор для каждого конкретного человека.

От идеи получать истинную случайность по API в AWS, где случайность брали бы у австралийских физиков, сделавших лазерную установку, и получали бы энтропию из квантовых флуктуаций вакуума, он отказался.

Для надежности мы решили использовать две установки, основную и резервную. Обе от ID Quantique, обе на квантовых эффектах, но на разных. Одна использует дробовой шум при облучении слабым источником света CMOS-матрицы, что вызывает флуктуации количества детектируемых квантов света каждой из ячеек матрицы. Эта установка, Quantis QRNG PCIe, дает порядка 40 Мбит/с энтропии. Вторая, Quantis QRNG USB, подключаемая по USB и содержащая полупрозрачное зеркало, на которое направляется поток одиночных фотонов, выдает около 4 Мбит/с энтропии.

Квантовый генератор случайных чисел с полупрозрачным зеркалом работает следующим образом. Источник раз за разом испускает одиночный квант света. Тот налетает на полупрозрачное зеркало, через которое проходит 50% света, а 50% отражается. И, поскольку фотон неделим (слава Планку и Эйнштейну), он либо пролетает через зеркало, либо отражается. Детекторы определяют, куда попал фотон, и так генерируется случайный выбор, 0 или 1. Для компенсации неравнозначности нуля и единицы в случае, если зеркало имеет не идеально точную 50-процентную пропускную способность, используется постобработка по алгоритму Джона фон Неймана. С ее помощью определенные выше биты группируются по два, что в четыре раза уменьшает получаемую энтропию, но делает ее unbiased.

Схема работы квантового генератора случайных чисел

Физическое подключение и первоначальная настройка

Вместе с устройством, помимо руководств по эксплуатации, поставляются исходники драйверов, системные требования (по большей части с упором в программную часть) и библиотека на C.

Так как драйвер генератора требовал конкретные версии ядра Linux и системных пакетов, мы развернули виртуальную машину с CentOS 7 как самой стабильной из перечисленных в документации поддерживаемых операционных систем.

Сам генератор был установлен в офисный сервер. Доступ к нему пробросили в виртуальную машину через гипервизор — систему управления виртуальными машинами. Предварительно установили на хост-систему драйвер для корректного отображения устройства и выполнения инструкций проброса.

После определения генератора в системе скомпилировали драйвер. Заморозили обновления для ядра и используемых драйвером системных пакетов, чтобы случайно не сбить работу системы обновлениями. Только после этого можно было передать разработчикам доступ к виртуальной машине.

Ввиду того, что документация, технические характеристики, исходный код драйвера — защищенная NDA собственность компании-производителя, в сети отсутствует подробная информация о генераторе, а также темы с решением проблем на форумах. Любые вопросы, касающиеся генератора и его ПО, можно задать только официальным представителям техподдержки.

В комплекте, помимо самого устройства, находился сертификат, подтверждающий подлинность генератора и результаты проверки работоспособности конкретного устройства.

Архитектура приложения и алгоритм работы

В связи с тем, что пользователю приложения необходимо было подключаться к квантовому генератору, размещенному в офисе ФБК, без сетевого соединения на стороне приложения было никак не обойтись. А значит, Роскомнадзор имел бы все шансы идентифицировать пользователя и попытаться заблокировать адреса, по которым он обращался к генератору при помощи СОРМ и ТСПУ. Мы решили построить архитектуру приложения, исходя из устойчивости к потенциальным блокировкам, нагрузкам от большого количества запросов и сохранения приватности пользователя.

Приложение должно было быть реализовано на двух платформах (Android и iOS), а также работать на планшетах — выбор пал на Flutter. В будущем плюсами данного выбора станут скорость и гибкость в разработке, но из-за отсутствия достаточного количества библиотек некоторые решения пришлось писать вручную. В нашем случае это была кастомная библиотека DNS over HTTPS (DoH) для работы по протоколу RFC 8484. Вместо стандартного сетевого соединения клиент генерировал случайную строку из 20 символов a-z0-9 и через DoH запрашивал один поддомен дискавери-домена (скажем, w4a1s27c81syputinvor.photon.navalny-team.org) через случайный публичный резолвер, например 1.1.1.1 от Cloudflare или 8.8.8.8 от Google. В качестве фолбэка было добавлено еще несколько альтернативных, чтобы Роскомнадзор не решался блокировать любой из них под угрозой сломать множество приложений российского сегмента интернета.

Приложение проверяло, чтобы ответ сервера состоял ровно из двух записей TXT: с префиксами «N» для имени кандидата и «D» — для его описания в utf-8. Необходимо было, чтобы записи были минимально возможного размера, чтобы ответ влез в ограничения ответа DNS — 512 байт. Разгоняться с контентом было нельзя, и поэтому приложение не выдавало длинных биографий кандидатов или их фотографий, тем более что особого значения это не имело. Если вы читаете эту статью вскоре после ее публикации, возможно, сервер еще работает и вы можете сгенерировать себе еще кандидатов командой host -t txt w4a1s27c81syputinvor.photon.navalny-team.org.

Схема архитектуры приложения «Фотон-2024»

Клиентская библиотека генератора случайных чисел написана на C и представляет собой довольно простой интерфейс: перечисление подключенных устройств, получение версий, открытие-закрытие сессии и, собственно, запрос на получение случайных чисел.

Сервер HW RNG, к которому был подключен генератор, при запуске устанавливал TCP-соединение с DNS-сервером (по отдельному внутреннему порту) и без остановки лил туда случайные числа. Поскольку сервер считывал данные из сокета только по мере поступления запросов от пользователей, рано или поздно backpressure от сервера заставлял клиент заблокироваться. Энтропию из буфера брали в порядке LIFO, чтобы для пользователей брались «свежие» фотоны.

DNS-сервер реализовывал основную логику бэкенда. При запуске он считывал JSON-файл с кандидатами с бакета GCS и обновлял его в фоне каждые 10 секунд на случай изменений. Сервер считывал данные от HW RNG и писал их в буфер фиксированного размера на случай поступления спайков клиентских запросов. Размер буфера можно сделать таким, сколько памяти не жалко — хоть гигабайт.

Сервер получал запрос с утвержденным адресом нашего дискавери, брал нужное количество байт энтропии и делал выбор кандидата в соответствии с текущим конфигом, полученным с GCS. Ответ упаковывался в TXT-записи DNS.

Чтобы сделать работу системы максимально надежной, было реализовано несколько аварийных режимов:

Если по каким-то причинам энтропии в буфере было бы недостаточно (например, сломался сервер HW RNG или пропал интернет в офисе ФБК), DNS-сервер сгенерировал бы случайное число из /dev/urandom. Пользователь бы об этом не узнал, но администраторы получили бы оповещение. К слову сказать, этого так ни разу в продакшене и не случилось — все случайные числа были сгенерированы настоящими фотонами.
Если бы у пользователя оборвалось соединение, отключился интернет или приложение было бы заблокировано Роскомнадзором, на такой случай в него была заложена функция локального рандома для выбора кандидата из списка, которое приложение в фоновом режиме получало с GCS.
На случай, если бы свежеустановленное приложение так ни разу и не смогло обновить список кандидатов и DNS-сервер не отвечал, в нем еще был захардкожен список с кандидатами на дату сборки приложения.

Если приложению не удавалось подключиться к квантовому генератору в офисе ФБК и оно было вынуждено делать локальную генерацию, то оно честно в этом признавалось:

Для хранения данных в приложении использовались защищенные хранилища — Keychain (iOS) и KeyStore (Android).

Для отправки запроса в «фотонную пушку» по нажатию кнопки в приложении и получения ответа нужны были считанные миллисекунды: пользователь дольше любовался красивой анимацией, реализованной отделом дизайна.

Бот «Умного голосования» для мессенджеров аналогично обращался к DNS серверу, получал «квантового кандидата», и ответ в нем был мгновенным.

Заключение

Для контроля работы и сбора статистики были организованы дашборды в Grafana. Записывались запросы к квантовому генератору и состояние буфера энтропии. Был подключен Firebase c инструментарием Google Analytics на стороне приложения.

«Фотонная пушка» сработала более 650 тысяч раз.

График распределения запросов к квантовому генератору из приложения и телеграм-бота

Приложением воспользовались более 70 тысяч человек. Оно попало в топы рейтингов сторов в своей категории. Роскомнадзор даже ограничил доступ к сайту Google Play Market в день выпуска.

Задача сделать приложение, которое подключалось бы к квантовому генератору и выдавало бы один результат, звучит просто. Но в условиях ограничений интернета в России она вынуждает разработчиков продумывать в своей архитектуре дополнительные меры безопасности и дополнительный функционал для борьбы с репрессивными органами, которые не только ограничивают свободу, но и ломают российский интернет. Нашим долгом было воплотить идею Алексея Навального и продолжить борьбу с Путиным.

Все это стало возможным только благодаря вашей помощи. Поддержать нашу работу можно по ссылке: https://donate.fbk.info/it. Чтобы сделать пожертвования еще безопаснее, мы даже добавили на сайт функцию генерации одноразового биткоин-адреса и обязательное смешивание всех полученных средств через миксер.

Security of Navalny's underground resistance on the Dark Web

Navalny Team — Wed, 25 Oct 2023 10:53:25 +0000

In 2017, Navalny's team started an underground resistance in Russia. Initially serving as pre-election hubs, they later evolved into regional political centers. This network of these centers posed a significant threat to Putin, leading to a relentless escalation of repression tactics, including raids, account freezes, employee arrests, physical assaults, and menacing threats. In 2021, the authorities falsely concocted an extremism case, ultimately forcing the shutdown of those centers, all purportedly in the name of safeguarding those involved.

In December 2022, our team relaunched Navalny's resistance movement, but this time in a form of an underground organization. Our primary objective was to create a secure platform for online communication and collaboration among coordinators and activists.

In developing our security system, we avoided relying on security through obscurity. By sharing the information in this article, we are not increasing the risks but, instead, providing experts with an opportunity to evaluate our security measures and assess their relevance and depth.

About the system

The website of Navalny's underground resistance provides each user with a personal account. Activists sign up based on their professional and geographical affiliations. The platform offers participants assignments tailored to their specialties and interests, providing them a possibility for direct communication with coordinators. Users earn points for completing assignments, with that achieving specified levels, and then can purchase avatars as rewards.

In August 2023, the platform underwent a significant update, introducing a messenger feature that facilitates anonymous communication among participants while they are working on assignments.

Threat and attacker modeling

Our system development commenced with threat modeling, where we outlined the objectives that potential attackers might pursue. We were acutely aware of the risks faced by those in Russia who support our cause, and we prioritized their safety above everything else. We identified the primary threat as the potential exposure of the activists' identities. Additionally, we acknowledged secondary threats, which encompass denial of user access to the service, jeopardizing confidential projects and plans, compromising the integrity of our service's software, and moving laterally to other services after a potential compromise.

During the second phase, we profiled potential intruders, identifying who might act as our adversaries — primarily, corrupt law enforcement agencies or special services, and Internet censorship enforcement entities. We then assessed their capabilities for attaining their objectives. We considered four primary attack vectors: targeting our systems through hacking, conducting searches on activists, compromising our employees through bribery, infiltration, or threats, and the most straightforward approach: encountering a "Comrade Major" in an online chat room.

Threat and attacker modeling serve as the bedrock of information security. Our priorities often meant we had to make product decisions that could negatively impact user experience and retention. For instance, we couldn't create a user-friendly mobile app with a clever workaround for evading censorship, equipped with notifications to improve user retention, like the ones in the “Smart Voting” app. That limitation arose from the concern that such an app would become easy to discover if someone were to search the phone of an activist.

Once we pinpointed the threats that demanded our attention, we initiated planning of a layered security system comprising multiple security perimeters. With each additional barrier we erected — such as authentication or a firewall — we asked ourselves, "Alright, but what if these defenses are bypassed? What potential actions could an attacker take afterwards?" Our goal was to ensure that any breach would fall short of facilitating a successful attack.

Tor

One pivotal decision we made was hosting the website on the dark web. Standard web browsers not only expose a wealth of user information, including device metadata, IP addresses, but also leave behind extensive traces on the user's device, like browsing history and caches. We made the deliberate choice to exclusively employ the Tor browser to access our system, as it minimizes these risks and takes numerous other measures to safeguard users.

This approach complicates the process of implicating a user in the organization's activities in the event of device seizure. While it might be evident that the Tor application is installed on a device, it would remain unclear what purpose it served. It's worth noting an interesting tidbit: Edward Snowden used Tor to communicate with journalists when disclosing classified information about the NSA. As a side note, Tor is being developed by a nonprofit organization, so if you can, consider supporting our fellow colleagues financially — donate.torproject.org.

Tor browser can also serve as a means to evade Roskomnadzor's (the Russia’s Media Supervision Agency, or simply saying the main censorship body of the country) surveillance. With the widespread deployment of the DPI (Deep Packet Inspection) equipment by most ISPs in Russia, concealing access to HTTPS websites has become considerably more challenging. Mainstream browsers still lack the ECH (Encrypted Client Hello) protocol support, and while Roskomnadzor may not discern the data exchanged between the user and the site, it can track plenty of metadata, e.g. which user has accessed which domains. Consequently, we opted to host the site on the .onion domain, rendering it inaccessible through regular browsers. This ensures that users cannot inadvertently stumble upon the website and register that fact in DPI logs.

Personal data

To sign up within the system, an activist is not required to disclose any personally identifying information. We only identify activists through their chosen pseudonyms, without any attempts to uncover their true identities. Every activist is assigned a reputation, quantified in points. These points accrue as supporters successfully complete tasks, raising their trustworthiness. As a result, more confidential and significant assignments can be delegated to them. So if a "Comrade Major" seeks access to classified projects, they must first undertake simpler tasks, such as distributing flyers or creating protest graffiti. Let’s give them a chance to finally do something useful!

To sign up for the system, a participant is required to create a pseudonym (username), a suitably complex password, and provide a brief description of their professional skills in an open format.

Actual names, email addresses, and phone numbers are not collected (except for an email address for the first contact, which is then erased from the database). All registrations undergo an extra level of review, following which users gain access to the system's complete functionality. The moderation process serves as a safeguard against excessive registration attempts. Given that Tor users remain anonymous, Tor shields malicious users who could inundate the system with automated bot submissions and disruptive messages from us. To ensure minimal disruption to the site's operation, our moderators scrutinize and filter out irrelevant or spam registrations. They also categorize supporters based on their professional interests (such as software engineers, designers, attorneys, etc.) before granting them access to the site.

Insider risks

Insiders refer to our staff members, including coordinators, moderators, software engineers, system administrators, and so on. They possess additional access to the system, which could potentially be exploited by attackers. While we have confidence in our employees, we still implement precautions in case they are compromised. This is because an employee might not only willingly become an attacker (due to ideological reasons or bribery) but could also fall victim to hacking (remember that phishing remains a threat) or be coerced into cooperation, possibly through pressure on their family members in Russia.

To safeguard against insider threats, we take a few measures. Firstly, we adhere to the principle of least privilege, ensuring that employees only have access essential for their immediate responsibilities. For instance, software engineers can access the code repository but not the servers, while testers can access the testing environment but not the production environment. Secondly, we employ multiple security layers to shield against insider threats. For example, even if system administrators were to dump the database or exfiltrate files from the downloaded file storage, they would be unable to decrypt them.

Encryption

We apply encryption to protect all sensitive database fields and uploaded files. Our solution involves using symmetric encryption with authentication (AEAD), which serves as a protection against tampering with the encrypted content. Importantly, the encryption keys are not retained within the application itself but are securely stored in Google's Cloud KMS (Key Management System). Additionally, we employ envelope encryption, that entails encrypting each file with its unique ephemeral key, that is in turn wrapped by KMS.

Cloud KMS keys are not exportable and are stored within a separate Google Cloud project. Access to this project is restricted to a select group of highly trusted administrators. Permission for encryption and decryption using these keys is exclusively granted to service accounts linked to workload identities of services that need to interact with the database.

This encryption approach minimizes the security perimeter of the data processed by the service. For instance, even if an administrator accesses the database, they won't be able to see the plaintext. The same holds true for backups. Furthermore, even systems responsible for creating backups do not need to decrypt the data. Everything is securely backed up directly in the encrypted state, and in order to compromise the data, one would also need to acquire access to the KMS keys, significantly raising the difficulty level of any potential data compromise.

Attacks on the application

If the application itself is compromised due to a technical vulnerability, an attacker can potentially access everything within the application's purview. It is the system's most valuable asset, and a successful attack could yield significant damage. To mitigate this risk, we implement two key strategies. Firstly, we refrain from storing any personal data of our users, ensuring that even in the event of data exfiltration, it would be exceptionally challenging to identify supporters. Secondly, we make concerted efforts to minimize the attacker's ability to establish a foothold within the system.

As our servers run on Google Kubernetes Engine (GKE), they consist of virtual machines that undergo regular updates and are frequently replaced by fresh ones. We employ Google's Container-optimized OS (COS) as the base image, known for its security posture. When it comes to service authentication, we avoid using exported JSON keys of service accounts, which can be susceptible to theft and long-term misuse. Instead, we rely on GKE Workload Identity, which furnishes applications with temporary tokens that have a brief lifespan, typically lasting only a few minutes.

Deployment

The entire infrastructure is segregated into two distinct environments: trusted and untrusted. The untrusted environment, devoid of sensitive data, is primarily dedicated to development and testing purposes. Conversely, the trusted environment encompasses all components with access to protected data.

The application code and containers are built by specialized secure virtual machines known as "runners." The runners operate in an isolated environment separate from other projects and engineers. Access to the project where the runners operate is restricted to a limited number of trusted engineers, and even then, direct access is only permitted in the event of runner failures. Service accounts associated with these machines hold administrative access to the production environment. This enables adoption of the gitops approach, resulting in meticulously documenting a comprehensive history of all production changes in both git logs and Google Cloud audit logs. Such dual audit setup allows for retrospective tracing of potential attacks.

We use the untrusted environment for building code from unprotected GitLab branches that are not considered secure. These branches are open for any developer to commit changes for review or deployment to test servers. Even if a developer were to introduce something malicious that compromises the build server, it would not grant them access to the production environment. Following a review by another team member and the subsequent merging of the branch into the primary production branch, the code undergoes build and deployment within the trusted environment, dedicated to production.

To improve cost-efficiency and achieve better server utilization, we use Kubernetes. For our build system, we've developed an in-house solution, allowing virtual machines with GitLab runners to run only when they are needed. The runner management system itself runs in the trusted environment, bolstering our overall security measures.

DoS attacks

When the system was launched, the team anticipated that, unlike in the open Internet, attackers would find it costly to carry out DoS attacks within the Tor network. However, attackers wasted no time, and our monitoring systems quickly detected a significant surge in server load. In the beginning, we were prepared to filter traffic only at the HTTP level, and initially it was sufficient. However, attackers switched tactics to more sophisticated ones, exploiting numerous ways to overwhelm our Tor client.

To provide some context, it's essential to understand how onion sites work. Unlike in regular Internet, where clients directly connect to servers, in Tor, both clients and servers establish connections with specialized introduction nodes. Those nodes act as intermediaries to introduce clients and servers to each other. For data transfer, after being introduced, both parties connect to rendezvous nodes through secure tunnels. The rendezvous servers then consolidate both tunnels into a single circuit, facilitating transmission of regular HTTP traffic between the clients and the servers.

In our case, the attackers flooded us with a massive influx of connection requests, effectively forcing our server to initiate numerous connections with rendezvous servers, which involved computationally intensive asymmetric cryptography. Notably, they never even attempted to transmit any data through these established tunnels, and the attack never reached the HTTP servers.

Standard defense mechanisms against DoS attacks, such as identifying the sources and temporarily blocking them, are unfeasible within the Tor network because we lack any means to identify the clients. Consequently, we developed a specialized solution. The key challenge was that a typical onion server could not scale efficiently. When an onion server is launched, it connects to the Tor network and publishes a service descriptor that points exclusively to itself. If one were to initiate a second instance of the same server, it would overwrite the descriptor of the first instance, rendering them unable to function at the same time.

To tackle this issue, we employed onionbalance, a third-party tool that enabled us to deploy multiple onion servers at once, each operating on its unique, randomly generated onion address. Subsequently, onionbalance retrieved their descriptors from the network, consolidated them into a unified descriptor, and then published that combined descriptor as the primary onion site's descriptor. This approach effectively distributed the traffic load across the servers, enabling them to handle traffic surges.

Here's an overview of our solution's architecture:

Tor-balancer serves as a wrapper around onionbalance, interacting with our cluster to obtain a list of healthy and active Tor server instances. It then creates a configuration for onionbalance and runs the balancer. If the collection of active instances change, for instance, if some instances go offline or new ones come online, the configuration is automatically regenerated, and onionbalance is restarted.

Meanwhile, Tor-frontend wraps a standard onion server. It generates a random onion address, starts an onion server at that address, waits until it successfully registers itslef and becomes accessible on the Tor network, and subsequently starts responding to HTTP requests with its designated onion address. This HTTP interface is what allows tor-balancer to discover which individual onion addresses should be merged to construct the final descriptor. This way, we evenly distribute the load across multiple onion addresses using "discovery" descriptors, preventing any single address from being overloaded by an attacker and causing denial of service.

The client initiates a connection with the server once, which is typically a slow and resource-intensive operation. Afterward, within that same connection or circuit, it can establish numerous logical connections, which are faster and more resource-efficient. To counteract potential attacks, we enforce a rule: if a client establishes an excessive number of connections within its circuit, we either terminate the circuit entirely or impose rate limits using ingress-nginx. This strategy allows our system to effectively counteract such attacks.

The second layer of defense involves relinquishing server privacy. Since we are not a dark market and take pride in openly declaring ownership of our service, there's no point for the server to establish a triple-wrapped connection to a rendezvous node. Instead, we utilize a Tor option that enables our server to form a direct connection. This significant adjustment has led to a substantial reduction in the amount of asymmetric cryptography performed on the server, significantly reducing its workload. Client privacy remains unaffected, and the server's operations become more efficient. As a result, we have successfully thwarted any further DoS attacks on the server.

Coordinators

Within this system, any participant has the capability to send a message to a coordinator and receive a response. For instance, they can report the completion of an assignment or ask a question.

To facilitate the coordinators' responsibilities, we employ a dedicated administrative panel built on the Django framework. Its functionality proves more than sufficient for efficiently managing sign-up requests, assigning tasks, assessing their completion, and engaging in private chats with activists. Moderators are not privy to users' real usernames; instead, they are assigned impersonal sequential numbers to enable another level of pseudonymization. All administrators are mandated to employ two-factor authentication, and their access is restricted by job role, with access exclusively allowed through a VPN. We also maintain audit logs to enable tracking of which staff member utilized which access.

Team coordinators were tasked with distributing and grading assigned tasks, supervising execution and maintaining communication with the activists through private chats. This indirect process necessitated human resources and raised the issue of delayed feedback. To address it, we decided to launch public group chats based on the platform, allowing supporters to interact directly with each other within a task.

Chats

In terms of both functionality and design, the chat interface closely resembles the interface of a messenger app like Telegram. Users can seamlessly switch between chats, read, compose, and delete messages, respond to messages from others, and clear message histories.

Our chats run on top of websockets over the Tor network. Every chat message is encrypted at rest with Cloud KMS. To prevent an excessive number of requests to KMS, the system incorporates a local cache in the application's memory for plaintext messages.

Users have the option to manually delete chat messages, and messages are also automatically deleted after a certain period of time.

To safeguard chat rooms against message spam, the system enforces a limit on the number of messages a user can send within a given time frame. Once this limit is reached, further messages will not be accepted. Additionally, we conducted comprehensive load testing of the chats with various scenarios to ensure that the server can withstand the anticipated load.

We've implemented measures to safeguard chat users from potential metadata-based identification. The concern here is that attackers with access to SORM (the police system for traffic supervision) can detect when users access Tor. While they may not discern the specific activities users engage in, concealing their presence becomes quite challenging. Attackers could enter a popular chat room within the system, send bulky messages of a certain size, and exploit SORM data to identify users across Russia who received messages of the same size at the same time. Although this identification process may yield noisy results and somewhat fuzzy identification, repeated attempts could eventually allow them to reliably ascertain which Russian users were present in the chat room during that time. To substantially complicate such an attack, we introduced randomness in both the message sizes delivered to users and the time intervals between these messages. This deliberate variation obscures the signal, reducing it to a level beneath the noise, thereby making identification through metadata exceedingly difficult.

Anonymity

The deepest level of our defense is anonymity. Even if all the abovementioned security measures were to fail—servers get compromised, coordinators are compromised, and administrators face threats—the only thing an attacker would obtain is solely a record of anonymous-to-anonymous communication that doesn't disclose any personally identifying information.

However, even without any security breaches, publicly accessible chat rooms are susceptible to spammers, provocateurs, and other malicious individuals. To mitigate those risks, we implement some protective measures.

To begin with, each chat room is allocated a moderator who can see slightly more than a regular user. The moderator has access to both the merged feed, where all messages subject to moderation are routed to, and a violations feed, which contains reports from other users regarding rule violations. Within these administrative chats, the moderator holds the ability to delete messages and impose temporary or permanent bans on users. Importantly, the moderator need not be an administrator with access to the admin panel over VPN; they could be an ordinary user signed in within their personal account, albeit endowed with extra privileges.

Furthermore, to thwart any attempts by an individual like "Comrade Major" to amass enough data to indirectly identify a user, we've instituted an additional mandatory layer of pseudonymization. Within a chat room, each user is allocated a randomly generated alias distinct from the one they use for their primary sign-in—this is the alias visible to other participants. The usernames of the activists that they use when logging into their accounts remain secret and are not displayed anywhere. We've prearranged a selection of adjective-noun combinations to ensure that all participants sport amusing and unique aliases. Consequently, users encounter each other as "Spotted Hippogryph" or "Cute Cat." Users also have the option to change their alias to another randomly generated one if desired.

The Fedor bot, being constant present in the chat room, serves as a reminder to participants about safety protocols. For instance, it advises them not to disclose any personal information about their real lives and encourages them to regularly rotate their nicknames to sever ties with their past online identities. Functioning much like a regular chat participant, the bot selects a random message from its knowledge base and shares it within the chat.

File uploads

The messenger doesn't just facilitate exchange of short messages; it also allows image uploading. We've taken measures to ensure that the metadata associated with the images uploaded to a shared chat room is automatically stripped off, preventing anyone from ascertaining details such as the creator, creation date, and location.

To accomplish this, we opted for exiftool as our solution for metadata removal. It supports the broadest range of formats and is easy to use. However, it's worth noting that exiftool relies on numerous codecs written in C, a language that makes it easy to introduce vulnerabilities enabling remote code execution.

To mitigate the risk of a compromised exiftool affecting the entire application, we've isolated it as a separate microservice within a sandboxed environment. This setup ensures that if a malicious file is encountered, hackers won’t be able to breach the primary service or establish a foothold on the server, thereby preventing interception of other users' files. This microservice runs within Google's serverless Cloud Functions execution environment, which limits the lifespan of an instance and restricts its access to the database and other microservices at the network level.

During the initial day of the chat rooms’ launch, our security measures were put to the test when malicious testers attempted to shell our system with a genuine zip bomb disguised as an image containing millions of empty pixels. A zip bomb, in this context, refers to an archive filled with billions of zeroes that have been compressed to an extraordinarily compact size by a compression algorithm. If a recipient attempts to decompress it, they would rapidly deplete their available memory or storage, or even both.

_decompression_bomb_check raise DecompressionBombError( PIL.Image.DecompressionBombError: Image size (50625000000 pixels) exceeds limit of *N* pixels, could be decompression bomb DOS attack.

Fortunately, the bomb was defused as our library's security measures kicked in. However, even if it had exploded, it would not have caused any harm to the primary service thanks to the isolation.

Conclusion

We've developed a unique tool that empowers supporters and activists in Russia to challenge the regime more efficiently while maintaining secure communication and minimizing the risk of being exposed. This endeavor was made possible through generous donations from our supporters, and we express our heartfelt gratitude to them! You can also become a part of the underground resistance and lend your support right away:

Patreon of the underground resistance: https://www.patreon.com/shtab_navalny

You can donate company shares to us via the DonateStock website. It's quick and convenient, and the site sometimes doubles the sum of donation:
https://donatestock.com/rikolto-ltd

ACF crypto wallets:

Bitcoin
3QzYvaRFY6bakFBW4YBRrzmwzTnfZcaA6E

Ethereum
0x314aC71aEB2feC4D60Cc50Eb46e64980a27F2680

Monero
42e1hkdsTHUUWSM24jVgLTH4MDJPMbNS1XDt7rK36dTBSKweohz9FSWKAAoqHLN9nSVgocnSnkR2AaLMWtsrmAoQGPdWSE1

Zcash (Z-address)
zs1l8ztrqpk0qyn2hyte3x9m568taz64jyc90ppfskylqgawxw7r3gq453yn6hk9swq2l0dq9yal0a

USDT (ВЕР-20)
0x9A4B20a7909Af03dd8B4f28A419840F9715E1F73

Benevity is a corporate donation software used by over 900 companies: Apple, Google, Twitter, Facebook and others. If you work for a large company, your corporate website probably has an Employee Giving section. Type Anti-Corruption Foundation in the search box there and enter the donation amount. The advantage of Benevity is that sometimes corporations will multiply the amount of donations made through it by several times.

Безопасность Штабов Навального в Dark Web

Navalny Team — Wed, 25 Oct 2023 08:50:00 +0000

В 2017 году команда Навального открыла штабы по всей России. Сначала они были предвыборными, а затем стали региональными политическими центрами. Опасная для Путина, сеть штабов подвергалась непрерывным и усиливающимся репрессиям: обыски, аресты счетов и сотрудников, физическое насилие, угрозы. В 2021 году власти выдумали дело об экстремизме, и штабы пришлось закрыть — для защиты всех участников.

В декабре 2022 года наша команда возобновила работу штабов Навального — теперь в виде подпольной организации. Нужно было разработать средства для коммуникации и коллаборации координаторов и активистов в онлайне. Осознавая риски для сторонников и активистов, находящихся в России, мы подошли к вопросу обеспечения их безопасности максимально серьёзно. Мы строим нашу систему безопасности, не полагаясь на принцип security via obscurity, поэтому, рассказывая о ней, мы не подвергаем ее значительным дополнительным рискам, а напротив — даем возможность специалистам понять уровень ее безопасности и дать свою оценку качества нашей работы.

Описание системы

Сайт Штабов Навального представляет из себя личный кабинет. Активисты могут зарегистрироваться в нем по профессиональному и территориальному признаку. На базе платформы публикуются задачи, которые назначаются в соответствии со специальностью и интересами участников, имеется возможность связи с координатором. Пользователь может заработать баллы за выполненные задачи, достигнуть определенных уровней и, например, приобрести за это аватары. В августе 2023 года на базе платформы вышло большое обновление: запущен мессенджер, обеспечивающий анонимную коммуникацию участников в рамках задачи.

Моделирование угроз и нарушителей

Разработку системы мы начали с моделирования угроз — определения целей, которые могут ставить перед собой злоумышленники. Как главную угрозу мы определили идентификацию участников штабов. Вторичные угрозы — блокировка доступа пользователей к сервису, компрометация секретных проектов и планов, компрометация программного обеспечения нашего сервиса и получение через него доступа к другим сервисам.

Вторым этапом мы произвели моделирование нарушителя — прикинули, кто может быть нашим злоумышленником (очевидно, это сотрудники коррумпированных правоохранительных органов и спецслужб, органов обеспечения цензуры в интернете), и какие у них есть возможности по достижению их целей. Мы рассматривали четыре основных вектора атак: на серверы (хакерство), на активистов (обыски), на сотрудников (внедрение, подкуп, угрозы) и самое простое: «товарищ майор» в чате.

Моделирование угроз и нарушителей — это фундамент обеспечения информационной безопасности. Поставив безопасность активистов во главу угла, мы были вынуждены часто принимать продуктовые решения в ущерб юзабилити, удержанию пользователей и т.д. Например, мы не могли позволить себе сделать удобное приложение для телефона с крутым обходом блокировок, как в Умном голосовании, с уведомлениями, возвращающими неактивных пользователей, — ведь при досмотре телефона это приложение будет легко найти.

Когда мы определили, с какими угрозами надо бороться, мы начали планировать эшелонированную систему безопасности с несколькими периметрами защиты. Каждый раз, когда мы возводили очередную стену: «тут у нас аутентификация», «тут у нас файрвол», — мы думали: «Хорошо, а что будет, если эта защита будет взломана? Что сможет сделать злоумышленник?» — и придумывали, как сделать, чтобы этого было недостаточно для успешной атаки.

Tor

Одним из ключевых решений стало размещение сайта в dark web. Обычные браузеры не только раскрывают много информации о пользователе, например метаданные с типом и именем устройства, IP-адрес пользователя, но и оставляют много следов на устройстве — историю посещений, кэши. Нами было принято решение для подключения к штабам использовать исключительно браузер Tor, который ничего из этого не делает и предпринимает еще много других мер для защиты пользователей. Доказать причастность пользователя к деятельности организации, в случае изъятия устройства, таким образом проблематично — видно, что приложение Tor установлено, но для чего оно использовалось — непонятно. И тут на ум приходит интересный факт: именно Tor использовал Эдвард Сноуден для коммуникации с журналистами при сливе секретных данных АНБ. Кстати говоря, Tor разрабатывает некоммерческая организация, и если у вас есть возможность, поддержите коллег финансово — donate.torproject.org.

С помощью данного браузера можно спрятаться и от Роскомнадзора. С момента введения повсеместного DPI на большинстве провайдеров в России сохранить в тайне доступ к сайтам на HTTPS стало гораздо сложнее. В популярных браузерах до сих пор отсутствует возможность использования протокола ECH, и, хотя Роскомнадзор не знает, какая именно информация передавалась между пользователем и сайтом, он видит, какой пользователь на какие домены обращался. Поэтому нами было принято решение разместить сайт на onion-сервере, обратиться к которому из обычного браузера нельзя. Таким образом пользователи даже случайно не смогут зайти на сайт и «засветиться» в логах DPI.

Персональные данные

Для того чтобы зарегистрироваться в системе, активисту не нужно предоставлять свои личные данные. Мы видим активистов только под их псевдонимами, не зная и не пытаясь узнать их реальные личности. У каждого активиста есть репутация, которая измеряется в баллах. Баллы выдаются по мере выполнения заданий и делают активиста более доверенным — ему можно поручать более секретные и серьёзные задания. Таким образом, если «товарищ майор» захочет узнать больше о секретных проектах, ему придется выполнять больше простых заданий — расклеивать листовки и рисовать протестные граффити. Пусть наконец сделает что-нибудь полезное!

Для регистрации в системе штабов участнику необходимо придумать свой псевдоним (логин), достаточный по сложности пароль и коротко описать свои профессиональные навыки в свободной форме.

Реальных имён, электронных почт и телефонов не требуется. Все регистрации проходят дополнительную модерацию, после которой пользователю открывается доступ к полному функционалу системы. Модерация также защищает от флуда регистрациями. Поскольку в Tor клиенты анонимны, это ровно так же защищает от нас и самих злоумышленников, которые могут ботами заполнить миллионы анкет, а потом заспамить систему накрученными сообщениями. Чтобы это не повлияло на работу сайта, модераторы проверяют анкеты, отсеивая мусорные, размечают активистов по их профессиональным интересам (программисты, дизайнеры, юристы и т.д.) и только после этого пропускают их на сайт.

Поэтому, пожалуйста, отнеситесь с пониманием к тому, что нам нужно время на проверку ваших анкет. Мы ставим цель — 1-3 суток, но в случае атак оно может и затянуться.

Риски от инсайдеров

Инсайдеры — это сотрудники штабов: координаторы, модераторы, программисты, системные администраторы и т.д. У них по роду деятельности есть дополнительный доступ к системе, которым могут воспользоваться злоумышленники. Мы доверяем нашим сотрудникам, но всё равно предпринимаем меры на случай их компрометации — ведь сотрудник может не только стать злоумышленником по своей воле (по идейным соображениям или быть подкупленным), но и быть взломанным (фишинг никто не отменял) или принужденным к сотрудничеству, например, через давление на родственников.

Для того чтобы защититься от угроз со стороны инсайдеров, мы предпринимаем специальные меры. Во-первых, мы всегда руководствуемся принципом минимальных привилегий — у наших сотрудников нет лишнего доступа, который не нужен им для выполнения прямых обязанностей. Например, у программистов есть доступ к репозиторию с кодом, но нет доступа к серверам. У тестеров есть доступ к тестовому окружению, но нет доступа к продакшну. Во-вторых, мы используем несколько периметров и для защиты от угроз инсайдеров. Скажем, даже если системные администраторы сделают дамп базы данных или скопируют все файлы из хранилища загруженных файлов, они не смогут их расшифровать.

Шифрование

Все чувствительные поля базы данных и все загружаемые на сервер файлы зашифрованы. Мы используем симметричное шифрование с аутентификацией (AEAD), защищающее также от подмены зашифрованного содержимого. Ключи шифрования хранятся не в приложении, а в облачной системе управления ключами Cloud KMS от Google. Файлы шифруются при помощи envelope encryption — каждый файл шифруется своим эфемерным ключом, который уже шифруется KMS.

У ключей Cloud KMS запрещён экспорт. Они хранятся в отдельном проекте Google Cloud, доступ к которому есть только у самых доверенных администраторов. Доступ к шифрованию и расшифрованию этими ключами выдан только сервис-аккаунтам, связанным с workload identity сервисов, которые должны работать с базой данных.

Такой подход к шифрованию минимизирует периметр защиты данных. Например, даже если администраторы будут делать запросы к базе данных, они не смогут увидеть содержимое. То же самое касается и бэкапов. Более того, даже системы, делающие бэкапы, не должны расшифровывать данные. Всё бэкапится в зашифрованном виде, и для того, чтобы украсть данные, надо ещё и получить доступ к ключам KMS, что сильно усложняет задачу компрометации данных.

Атаки на приложение

Если будет скомпрометировано само приложение через какую-нибудь техническую уязвимость, злоумышленник может получить доступ ко всему, к чему имеет доступ приложение. Это самый ценный актив системы, и успешная атака способна нанести очень большой ущерб. Чтобы его минимизировать, мы во-первых, не храним никаких персональных данных пользователей, чтобы даже в случае перехвата всех данных было максимально сложно идентифицировать активистов, а во-вторых мы стараемся минимизировать возможности злоумышленника закрепиться в системе.

Поскольку серверы работают на GKE, они являются виртуальными машинами, которые периодически обновляются и заменяются новыми. В качестве базового образа используется COS (Container-optimized OS) от Google, представляющий из себя защищенную Linux-систему. Для аутентификации сервисов мы не используем экспортируемые JSON-ключи сервис-аккаунтов, которые можно украсть и использовать длительное время. Вместо этого применяется GKE Workload Identity, которая дает приложениям только временные токены со сроком жизни несколько минут.

Деплой

Вся инфраструктура разделена на две части — доверенную и недоверенную. В недоверенной работает тестовое окружение, в котором нет никаких секретных данных. Оно используется для разработки и тестирования. В доверенной напротив — работает всё, у чего есть доступ к защищаемым данным.

Сборкой кода приложения и контейнеров, занимаются специальные защищенные виртуальные машины (раннеры), работающие в изолированной от других проектов и инженеров среде. Доступ к проекту, в котором работают эти раннеры, есть у ограниченного количества доверенных инженеров, и то только на случай их поломки. У сервис-аккаунтов этих машин есть административный доступ к продакшну, что позволяет использовать подход gitops, в котором история всех изменений продакшна ведется в двух местах — в логах git и в аудит-логах Google Cloud, что позволит если не предотвратить атаки полностью, то хотя бы проследить их ретроактивно.

Мы используем недоверенную среду для сборки кода из незащищенных веток GitLab. Это ветки, куда любой разработчик может делать свои коммиты для ревью или выкатки на тестовые серверы. Даже если разработчик закоммитит что-то вредоносное, что скомпрометирует сервер сборки, это не даст ему никакого доступа к продакшну. После ревью другим сотрудником и мержа ветки в основную продакшн-ветку, код собирается уже в доверенной среде и деплоится в прод.

Для экономного расходования средств и достижения плотной загрузки серверов мы используем Kubernetes, а для системы сборки — собственное решение включения виртуальных машин раннеров только в тот момент, когда они нужны. Система управления раннерами также работает в защищенной среде.

DoS-атаки

При запуске системы штабов команда рассчитывала, что, в отличие от открытого интернета, в Tor злоумышленникам будет накладно устраивать DoS-атаки. Но атакующие не заставили себя долго ждать, и наш мониторинг вскоре зафиксировал резкое увеличение нагрузки на серверы. Мы были готовы к фильтрации трафика на уровне HTTP, и поначалу этого было достаточно, но злоумышленники стали поступать хитрее — они создавали множество маршрутов и нагружали наш клиент Tor.

Здесь надо немного объяснить, как работают onion-сайты. В отличие от обычного интернета, где клиенты подключаются к серверам напрямую, в Tor и клиенты, и серверы, подключаются к специальным узлам дискавери, которые "знакомят" их друг с другом, а после этого для передачи данных и те, и другие подключаются к узлам рандеву, устанавливают туннели с обеих сторон, и сервер рандеву замыкает их в единую цепь, по которой потом уже будет ходить обычный HTTP.

В нашем случае злоумышленники отправляли огромное количество запросов на установку соединений, вынуждая наш сервер заниматься установкой соединений с серверами рандеву и сопутствующей дорогостоящей асимметричной криптографией. Далее они даже и не пытались ничего отправлять по этим туннелям, и атака даже не доходила до HTTP.

Обычные средства защиты от DoS-атак типа определения источников и их временной блокировки в Tor невозможны, поскольку мы никак не можем идентифицировать клиентов. С этой целью было разработано специальное решение. Дело в том, что обычный onion-сервер не умеет масштабироваться. Когда запускается Tor, он подключается к сети и публикует дескриптор сервиса, указывающий на него единственного. Если запустить второй инстанс того же сервера, он затрет дескрипторы первого, и они вместе работать не смогут.

В качестве решения проблемы мы используем onion balance - сторонний инструмент, который позволяет запустить несколько onion-серверов (каждый из которых работает на своём случайном onion-адресе), а затем загрузить из сети их дескрипторы, объединить в единый дескриптор и опубликовать уже в качестве дескриптора основного onion-сайта. Это позволяет распределять нагрузку на серверы и выдерживать пропорционально больший трафик.

Так выглядит архитектура нашего решения:

Tor-balancer - это обёртка над onionbalance, которая обращается в наш кластер, получает список здоровых и активных инстансов тор-сервера, генерирует конфиг для onionbalance и запускает его. Если набор активных инстансов меняется (например, какой-то отключился, или новый включился), то конфиг регенерируется, и onionbalance перезапускается.

Tor-frontend управляет обычным onion-сервером. Он генерирует случайный onion-адрес, запускает onion-сервер на этом адресе, ждёт, пока он успешно зарегистрируется и станет доступным в сети тор, а потом начинает отвечать на HTTP-запросы собственным onion-адресом. Именно обращаясь к этому HTTP, tor-balancer может узнать, какие индивидуальные onion-адреса надо использовать для компиляции общего большого дескриптора.

Клиент устанавливает маршрут (circuit) с сервером один раз. Обычно это медленная и «дорогая» операция с точки зрения ресурсозатратности, а дальше может устанавливать любое количество логических соединений в рамках одного circuit — это уже быстро и дешево. Для борьбы с атаками настроено правило: если какой-то клиент внутри своего circuit установил большое количество соединений, такой circuit либо разрывается совсем или замедляется rate limit’ом на ingress-nginx. Это позволяет эффективно бороться с атаками.

Таким образом мы распределяем нагрузку между onion-адресами с помощью «дискавери» дескрипторов и не даем злоумышленнику нагрузить один конкретный адрес и завалить систему.

Вторым уровнем защиты от атак был отказ от конфиденциальности сервера. Поскольку у нас не дарк маркет и нам не надо прятать сервер (мы и так с гордостью говорим, чей он), серверу нет никакой нужды устанавливать тройное соединение с точкой рандеву. Вместо этого мы используем опцию Tor, которая позволяет нашему серверу устанавливать прямое соединение. Это позволило нам резко сократить объем асимметричной криптографии, который надо делать на сервере, и в несколько раз сократить нагрузку на сервер. Конфиденциальность клиентов при этом никак не страдает, а серверу — легче.

Больше успешных DoS-атак на сервер не было.

Координаторы

В системе штабов любой участник может написать сообщение координатору и получить ответ. Например, он может сообщить о выполненном задании или задать вопрос.

Для работы координаторов мы используем специальную административную панель на базе фреймворка Django. Его функционала более чем достаточно для удобного разбора заявок на регистрацию, постановки задач и оценки их выполнения и общения с активистами в личном чате. Модераторы не видят реальных логинов пользователей, но, чтобы они могли как-то идентифицировать их, модераторы видят пользователей под еще одним уровнем псевдонимов — для них пользователи обозначены обезличенными порядковыми номерами. Для всех администраторов включено принудительное правило двухфакторной аутентификации, действует разграничение доступа по направлениям работы, и доступ включен только из-под служебного VPN. Ведется журнал действий, чтобы всегда можно было установить, какой сотрудник каким доступом пользовался.

Координаторы команды ставят задачи, следят за их исполнением, оценивают, поддерживают связь в личном чате с пользователем. Это требует человеческих ресурсов и создает проблему отсутствия быстрой обратной связи. Поэтому на базе платформы было решено запустить публичные групповые чаты для взаимодействия активистов друг с другом напрямую в рамках задачи.

Чаты

По функционалу и дизайну, интерфейс чатов приближен к ленте мессенджера типа Telegram. В нем можно переключаться между чатами, читать, писать и удалять сообщения, отвечать на чужие сообщения и чистить историю.

Чаты работают поверх вебсокетов внутри Tor. Каждое сообщение чата зашифровано при помощи Cloud KMS, и чтобы избежать избыточного количества запросов к KMS, в системе реализован локальный кеш расшифрованных сообщений в памяти приложения.

Сообщения в чате можно удалять вручную, а по прошествии времени они удаляются автоматически.

Для защиты чатов от спама сообщениями, в системе настроено ограничение на количество отправляемых сообщений в единицу времени, после которого сообщения перестанут приниматься. Мы также проводили нагрузочное тестирование чатов различными сценариями, чтобы убедиться, что сервер выдерживает расчетную нагрузку.

Мы предприняли меры по защите пользователей чата от их идентификации по метаданным. Дело в том, что злоумышленники, имеющие доступ к СОРМ, видят, когда пользователи пользуются тором. Они не знают, что именно пользователи там делают, но сам факт скрыть довольно сложно. Они могут подключиться к популярному чату в системе штабов, отправить какое-то большое сообщение заведомо известной длины и по данным СОРМ посмотреть, какие из пользователей по всей России в тот же самый момент получили сообщение той же самой длины. Сигнал зашумлен, идентификация будет нечеткой, но после нескольких таких сообщений они смогут достоверно выяснить, кто из россиян сидел в это время в чате. Чтобы сильно затруднить возможность такой атаки, мы рандомизируем размер сообщений, отправляемых пользователям, и задержки времени между ними, чтобы размыть сигнал и сделать его ниже уровня шума.

Анонимность

Самый глубокий уровень нашей обороны — это анонимность. Даже если все предыдущие уровни падут — серверы будут взломаны, координаторы куплены, а админы запытаны, — все, что получит злоумышленник, — это историю общения анонимов с анонимами, прямо не раскрывающую никаких идентифицирующих данных.

Но даже без всякого взлома, общедоступные чаты также подразумевают наличие в них спамеров, провокаторов и прочих злоумышленников. Поэтому мы предпринимаем соответствующие меры защиты.

Во-первых, за каждым чатом закрепляется модератор. Он видит чуть больше, чем обычный пользователь. Общую ленту, в которую падает поток всех сообщений, которые он модерирует, и ленту нарушений — жалобы от других пользователей. В этих административных чатах модератор имеет функционал удаления сообщений и блокировки пользователей - на определенное время или насовсем. При этом модератором не обязательно должен быть администратор с доступом в отдельную панель. Это обычный пользователь, зарегистрированный в личном кабинете, только с повышенными привилегиями.

А во-вторых, чтобы «товарищ майор» не мог, долгое время наблюдая за чатом, собрать достаточно информации на пользователя, чтобы идентифицировать его по косвенным данным, мы ввели еще один принудительный уровень псевдонимизации. Каждому пользователю в чате назначается случайное имя, отличное от того, которое он использует для основного входа в систему — именно его и видят другие участники. Имена пользователей, с помощью которых участники штабов входят в личный кабинет, нигде не фигурируют. Мы заранее подготовили комбинации из прилагательных и существительных, чтобы покрыть всех участников забавными и уникальными именами. «Пятнистый Гиппогриф» или «Милый Кот» — такими видят пользователи друг друга. Доступна функция смены имени на другое, но тоже случайное.

Бот Федор, постоянно присутствующий в чате, напоминает участникам о правилах безопасности - например не рассказывать ничего про свою реальную жизнь или регулярно менять свой ник, чтобы разорвать связь с собой прошлым. Он выглядит, как обычный участник чата, берет случайное сообщение из своей базы знаний и отправляет в чат.

Загрузка файлов

Мессенджер — это не только обмен короткими сообщениями, но и загрузка изображений. Мы позаботились о том, чтобы их метаданные автоматически очищались при загрузке в общий чат, и чтобы никто не мог узнать, кем, когда и где они были созданы.

В качестве решения для очистки метаданных был выбран exiftool. Он поддерживает наибольшее количество форматов и прост в использовании. Однако важно обратить внимание на то, что exiftool использует множество кодеков, написанных на С — языке, на котором очень легко написать уязвимый код, дающий возможность удаленного исполнения кода злоумышленником.

Чтобы скомпрометированный exiftool не привел к компрометации всего приложения, мы запускаем его отдельным микросервисом в изолированной песочнице, чтобы при загрузке вредоносного файла, хакер не мог бы получить доступ к основному сервису либо закрепиться на сервере и перехватывать файлы других пользователей. Мы запускаем этот микросервис в бессерверной среде исполнения Cloud Functions от Google, благодаря которой он живет короткое время и на уровне сети не имеет доступа к базе данных и другим микросервисам.

В первый день работы чатов террористы тестеры подбросили нам настоящую zip-бомбу в виде картинки из миллионов пустых пикселей. Zip-бомба — это архив на миллиарды нулей которые сжали компрессором до очень компактного размера. Если получатель пытается его распаковать, у него просто напросто кончится или память, или диск, или и то, и другое.

_decompression_bomb_check raise DecompressionBombError( PIL.Image.DecompressionBombError: Image size (50625000000 pixels) exceeds limit of *N* pixels, could be decompression bomb DOS attack.

К счастью, бомба так и не разорвалась - сработала защита в библиотеке. Но даже если бы она сработала, основному сервису это бы никак не повредило.

Заключение

Мы создали уникальный инструмент, дающий возможность сторонникам и активистам в России более эффективно бороться с режимом, поддерживая связь между собой и не боясь быть раскрытыми. А оплачено все это за счет пожертвований наших активистов, за что им огромное спасибо!

Поддержать работу IT-отдела Команды Навального: https://donate.fbk.info/it

Вы тоже можете присоединиться и поддержать Штабы:

Патреон Штабов: https://www.patreon.com/shtab_navalny

Вы можете пожертвовать нам акции компаний через сайт DonateStock. Это быстро и удобно, к тому же площадка иногда удваивает сумму. https://donatestock.com/rikolto-ltd

Криптокошельки ФБК (ACF):

Bitcoin
3QzYvaRFY6bakFBW4YBRrzmwzTnfZcaA6E

Ethereum
0x314aC71aEB2feC4D60Cc50Eb46e64980a27F2680

Monero
42e1hkdsTHUUWSM24jVgLTH4MDJPMbNS1XDt7rK36dTBSKweohz9FSWKAAoqHLN9nSVgocnSnkR2AaLMWtsrmAoQGPdWSE1

Zcash (Z-адрес)
zs1l8ztrqpk0qyn2hyte3x9m568taz64jyc90ppfskylqgawxw7r3gq453yn6hk9swq2l0dq9yal0a

USDT (ВЕР-20)
0x9A4B20a7909Af03dd8B4f28A419840F9715E1F73

Вы можете оформить корпоративное пожертвование, чтобы помочь Штабам Навального работать. Это можно сделать через платформу Benevity.

Benevity — программа для корпоративных пожертвований, которую используют более 900 компаний: Apple, Google, Twitter, Facebook и другие. Если вы работаете в крупной компании, скорее всего, на вашем корпоративном сайте есть раздел Employee Giving. Там в поисковой строке вбейте Anti-Corruption Foundation и введите сумму. Плюс системы Benevity в том, что иногда корпорации в несколько раз увеличивают размер сделанных через нее пожертвований.

История защиты Умного голосования от DDoS-атак

Navalny Team — Thu, 14 Sep 2023 12:49:41 +0000

С самого начала своего существования Умное голосование каждый год подвергалось DDoS-атакам — в период со дня публикации рекомендаций до дня выборов. Первую атаку мы зафиксировали в 2019 году, аккурат за неделю до голосования. Разумеется, мы ее ждали. К тому времени на сайте уже была развернута защита от атак, и она с честью приняла на себя удар и так же с честью упала. Пожалуй, самая масштабная атака произошла в этом году, 2022-м, и с ней мы успешно справились. Миллиарды запросов к сайту и тысячи заблокированных адресов за сутки — такова была цена доступности Умного голосования на московских муниципальных выборах. В посте мы рассказываем об истории Умного голосования и опыте нашей команды по борьбе с DDoS: о методах атак, архитектуре и технологиях по защите.

Чтобы понять некоторые из принятых технических решений, необходимо ненадолго заглянуть в прошлое. История Умного голосования восходит к 2018 году, когда Алексей Навальный впервые выдвинул идею консолидированного протестного голосования. К тому времени в России уже несколько лет работала система интернет-цензуры, осуществляемая Роскомнадзором. РКН рассылал списки заблокированных сайтов провайдерам, и те были обязаны блокировать к ним доступ.

Разумеется, команда Навального понимала, что попытки заблокировать сайт будут предприняты примерно сразу после его открытия, а значит, нужны были такие решения по хостингу, какие РКН на том этапе технически не мог заблокировать. В то время на провайдерах еще не было массово установлено оборудование DPI, и блокировки осуществлялись в лучшем случае по IP-адресу. Соответственно, сайт нужно было размещать на IP-адресах, общих с другими важными сайтами, чтобы РКН не смог его заблокировать, не сломав пол-интернета. В ретроспективе это решение оказалось совершенно правильным, и сайт так никогда и не был заблокирован по IP.

Итак, в начале 2019 года был запущен сайт на домене vote2019.appspot.com. Домен appspot.com принадлежит Google, и в нем автоматически создаются поддомены для всех проектов, использующих App Engine. Все сайты в appspot.com доступны по одним и тем же IP-адресам. Мы не рискнули тогда запускаться на отдельном домене для сайта, чтобы имя сайта прямо кричало, что оно работает на общей площадке и блокировать его нельзя.

В то время уже существовали коммерческие системы защиты от DDoS, например, в России был популярен Qrator. Но именно тот факт, что фронтенд приложения должен был работать на Google App Engine, не позволял нам использовать готовые решения. Если бы мы спрятали сайт за одним из них, то сервис защиты от DDoS выделил бы сайту отдельный IP-адрес, и он был бы немедленно заблокирован Роскомнадзором.

Достоинством App Engine является отличная масштабируемость — пока на сайт нагрузки нет, будет запущено всего 1-2 инстанса приложения. А если приедет большая нагрузка, то в течение нескольких секунд App Engine сможет поднять тысячи инстансов нашего приложения и переварить нагрузку. Учитывая все это, мы приняли решение строить собственную систему защиты от DDoS на базе App Engine.

Архитектура

Чтобы не разориться на App Engine, мы решили не запускать на нем тяжеловесное Умное голосование целиком. Вместо этого мы стали гонять там легковесный кеширующий прокси-сервер на Go, который проверяет трафик на признаки атаки и либо отбивает запросы, либо отдает ответы из кеша, либо проксирует их в основное приложение. Go в первую очередь был выбран из-за того, что он компилируемый — в результате приложение и запускается быстро, и ресурсов тратит мало, что очень важно для быстрого масштабирования при росте нагрузки и для экономии денег соответственно.

Поскольку во время атаки каждый инстанс прокси-сервера видит только малую долю всего трафика, принимать локальные решения о том, кого блокировать, а кого нет, качественно не получится — без полноты информации хороших решений, как известно, не принять. Поэтому был придуман отдельный бэкенд-сервис — «координатор», который собирает статистику со всех проксей, находит паттерны в трафике и посылает обратно нашу «политику партии» — кого мы баним, а кого нет.

Координатор также предоставляет базовые административные функции — показ статистики, мониторинг, ручное управление политикой банов и т. д. Координатор записывает свое состояние и всю телеметрию в базу данных для того, чтобы ему не были страшны перезапуски.

Жирным выделен data plane — путь запросов пользователей (ну и, разумеется, DDoS). Нежирным — все остальное, то есть control и management plane.

Анализ трафика

Все прокси Front Shield ведут локальный реестр обслуженных запросов и раз в 2 секунды отправляют его координатору в HTTP-запросе. В ответ координатор возвращает текущий бан-лист — список правил, по которым должны баниться запросы.

На стороне координатора все запросы анализируются, и если по каким-то IP-адресам обнаруживается подозрительная активность, то они попадают в бан на сутки. Анализ трафика делается асинхронно с приемом данных от инстансов прокси, поэтому решения могут чуть-чуть отставать от реального времени. На практике, если какой-то IP-адрес начинает резко слать много запросов, в бан он попадает в среднем через 5 секунд (2 секунды на доставку отчетов о трафике координатору, 1 секунда на анализ, 2 секунды на доставку бан-листов обратно на фронтенд).

Крещение огнем

Итак, остается около недели до голосования 2019 года. Приходит алерт от мониторинга, что сайт Умного голосования недоступен. Мы смотрим в консоль Front Shield и видим небольшой и очень короткий всплеск трафика. Было даже странно, что система не справилась даже с такой скромной нагрузкой. Начинаем разбираться, и все быстро встает на свои места — консоль самого App Engine показывает 20 тысяч запросов в секунду. Просто инстансы Front Shield приняли все эти запросы и массово упали от нехватки памяти. App Engine увидел нагрузку и быстро добавил инстансов, но атакующие, видимо, убедились, что в силах положить сайт, и быстро остановили атаку, рассчитывая устроить то же самое в день голосования.

Так началась борьба меча и щита. На каждую проблему, обнаруженную нападающими, мы придумывали решения. В данном случае была реализована техника load shedding, которая анализирует загрузку процесса и, если она приближается к своему пределу, начинает возвращать ошибки на раннем этапе обработки запроса, не дожидаясь падения. Это позволяет избежать каскадных аварий, когда падения одних инстансов увеличивают нагрузку на оставшиеся и дальше все разваливается, как домино.

В день голосования 2019 года все прошло довольно спокойно — было несколько атак без всяких последствий. Леонид Волков тогда постил графики Front Shield у себя в соцсетях.

Выборы 2020

После повсеместного внедрения ТСПУ на провайдерах особого смысла держать сайт Умного голосования живым не было. Именно поэтому наша команда выпустила дополнительные инструменты, такие как приложение под Android и iOS и телеграм-бот, в которых можно было узнать рекомендуемых кандидатов. Подробнее о технологиях для обхода блокировок, примененных в нашем приложении, можно почитать в нашем другом нашем посте. Поскольку в мобильном приложении пользователям не надо запоминать доменное имя и оно не является брендом, мы могли позволить себе менять домены раз в минуту, и DDoS-атаки просто не успевали сфокусироваться на сервере, как он уже менялся.

Веб-сайт же, разумеется, мы могли бы перенести на другой домен (не в appspot.com), но, во-первых, особого смысла с точки зрения блокировок в этом не было — любой сайт был бы во внесудебном порядке успешно заблокирован РКН, как только стал бы хоть немного заметен, во-вторых, скорее всего, если бы мы даже и закрылись за CloudFlare или Google Cloud Armor, как показывает практика, во время больших атак процентов 10 трафика все равно пролезает в бэкенд, и нам бы все равно приходилось тратить ресурсы на его обработку и загрузку CPU. Система, которая «знает» трафик, «знает» паттерны поведения пользователей, может быть гораздо более точной в обнаружении ботов и может защитить бэкенд гораздо эффективнее.

Так и вышло: DDoS-атак на бэкенд приложения практически не было, а атаки на сайт мы успешно отбили — ничего особенно выдающегося в тот год не было.

Выборы 2021

В этот год были очень крупные и важные выборы — избирались депутаты Госдумы и мы понимали, что атаки на Умное голосование достигнут беспрецедентных масштабов. Поэтому мы сделали еще одно крупное обновление — добавили еще один слой блокировок перед прокси Front Shield. У App Engine есть встроенный файрвол, который можно настраивать через API. Он позволяет вообще не платить за отбивание запросов с забаненных адресов — они даже не доходят до приложения. У этого решения есть один минус — жесткое ограничение на число правил файрвола: их всего 1000. Нам надо было придумать, как использовать их максимально эффективно. Мы заметили, что не все боты одинаково производительны — некоторые могут слать во много раз больше трафика, чем большинство других. Поэтому мы научили координатор собирать статистику: с каких IP-адресов идет больше всего трафика, который мы определяем как DDoS, те и заносить в файрвол. Но как только адрес попадал в файрвол, мы тут же «теряли» его из мониторинга — узнать, продолжает ли он отправлять запросы, а если да, то в каком количестве, становилось невозможно. Поэтому был реализован алгоритм, который со временем «забывает» старые грехи IP-адресов и замещает их в таблице новыми, самыми «злыми» на данный момент. Если разбаненный адрес продолжит слать трафик, то он быстро вернется в бан.

В неделю перед голосованием, когда мы опубликовали рекомендации, злоумышленники не просто начали заливать Front Shield огромным трафиком, но и стали действовать креативно. Они искали изъяны в системе и били так, чтобы пробить все слои кеширования при помощи рандомизации и достать до бэкенда. У нас во время голосования (а оно в этот раз было трехдневным) дежурили команды разработчиков и бэкенда, и Front Shield. Какие-то атаки мы отражали, дорабатывая код Front Shield прямо на лету, — скажем, делали нормализацию запросов или регулировали параметры анализа статистики. Например, одним из паттернов атаки было использование какого-то гигантского ботнета, где каждый из IP-адресов слал относительно мало трафика, но суммарно выходило очень много, и нам пришлось увеличить интервал сбора статистики в памяти координатора, чтобы обнаруживать этих ботов на основании более длительного времени. Какие-то ошибки приходилось исправлять прямо на бэкенде. Например, мы обнаружили, что поиск адреса «а а а а а а а а а а а а а а а а а а а а а а» был очень дорогим, и при помощи небольшого исправления алгоритма быстро справились с проблемой.

Надо отметить, что в основном атаки шли на бэкенд приложения, потому что сайт был к тому времени уже заблокирован, и его важность была сильно ниже, чем у приложения.

Выборы 2022

Все началось с осени 2021 года. Кремль начал под ноль зачищать информационное пространство, и под нож попали социальные сети. Пожалуй, Instagram стал той их роковой ошибкой, в результате которой клиенты VPN прописались в телефонах у огромного количества даже технически не подкованных россиян, и внезапно оказалось, что важность сайта Умного голосования снова возросла.

Вечером 10 сентября 2022 года, аккурат перед ключевым днем голосования, на сайт была запущена огромная DDoS-атака, которая продлилась более суток. Она продолжилась и после выборов, поэтому мы были вынуждены после окончания голосования совсем отключить Front Shield, чтобы не расходовать ресурсы зря. Миллиарды запросов к сайту и тысячи заблокированных адресов за сутки — такова была цена доступности Умного голосования на московских муниципальных выборах.

К сожалению, из-за принципа работы файрвола App Engine мы так никогда и не узнаем, сколько трафика пришло на сайт, но во время кратковременных сбоев, о которых мы напишем ниже, на какое-то время мы переставали обновлять файрвол, и в пиках прокси обрабатывала до 250 тысяч запросов в секунду, а отдаваемый сервисом трафик достигал 100 гигабит в секунду. Скорее всего, реальный масштаб атаки был в несколько раз больше.

Один из обычных методов борьбы с DDoS — территориальные ограничения. Например, если нас не интересует трафик из Южной Америки, то можно его сразу блокировать, а не пытаться даже обслуживать. В случае же Умного голосования так делать было нельзя, потому что в условиях блокировок всем пользователям из России приходилось пользоваться VPN, и страна, которую мы видели на фронтенде, была какой угодно, но только не Россией.

Одной ошибкой, которую мы совершили, была отдача неверных заголовков кеширования. Дело в том, что перед тем, как запросы достигают приложения на App Engine, они обрабатываются Google Frontend, который имеет свой собственный слой кеширования. Если приложение своими заголовками Cache-Control позволяет кешировать ответы, то Google Frontend это запомнит и будет в будущем отдавать их из кэша. Приложение даже не догадывалось, что у нас есть такие гигантские источники запросов и не могло занести их в файрвол.

Это продолжалось в течение нескольких часов. Поменяв заголовок Cache-Control с «public, max-age=120» на «private, max-age=120», мы решили проблему, и боты быстро улетели в бан.

Был еще ночной «тест» со стороны нападающих накануне основной атаки в день голосования. Количество забаненных запросов держалось на уровне 20-30k rps, но иногда пробы достигали и 250 тысяч. Напомним, что мы считаем трафик уже после файрвола, то есть сколько там было до него — мы не знаем, но, скорее всего, в несколько раз больше.

Анализируя логи, мы поняли, что они отыскали один из эндпоинтов, на который у нас не была включена нормализация, и рандомизированными запросами смогли на несколько минут уложить бэкенд. Мы поспешно добавили в правила нормализацию для этого эндпоинта.

В день голосования атака усилилась. Front Shield без остановки блокировал не менее 40 тысяч запросов в секунду (опять же, это то, что прошло через файрвол), а ко второй половине дня голосования трафик дорос до 100 тысяч запросов в секунду.

Нам пришлось несколько раз добавлять памяти координатору из-за огромного количества данных, которые он должен был держать и обрабатывать. В мирное время eму нужно около 50 мегабайт, во время прошлых DDoS-атак он мог вырасти до гигабайта, а в этот раз, особенно под конец дня, ему понадобилось больше 20 гигов.

В какой-то момент мы заметили, что координатор сломался. Оказалось, что он уже 45 минут не отвечает ни на какие запросы и находится в жестком дауне. Мы быстро обнаружили причину — из-за большого числа операций записи binlog базы данных переполнил диск, и все записи остановились. Как только мы решили эту проблему, координатор «проснулся» и принял первые за 45 минут отчеты от проксей — 200 тысяч запросов в секунду. Скорее всего, на протяжении этих 45 минут трафик на прокси плавно нарастал, поскольку никто не обновлял файрвол, и дорос до 200 тысяч.

Причудливый узор во время пика трафика — это артефакт мониторинга, возникший из-за билинейной интерполяции точек и большого пропуска. Хотя уж больно он похож на кривую сложности Dwarf Fortress!

Когда голосование близилось к концу, App Engine показывал, что за последние сутки было обслужено более 2,4 миллиарда запросов, и это отражало только то, что прошло через файрвол и смогло добраться до прокси. Оценочно можно предположить, что трафика было в несколько раз больше. Скорее всего, около 10 миллиардов запросов за сутки.

Таким образом, нас защитило несколько слоев: файрвол отбивал запросы от самых крупных ботов, прокси Front Shield отбивала «длинный хвост» с более мелких, далее прокси из локального кэша отдавала часть ответов на популярные запросы, и все остальное уже шло в бэкенд. На бэкенде запросы встречала «батарея» nginx с дисковым кешем, ну и дальше уже само приложение. Такая многослойная котлета позволила нам сохранять устойчивость сервиса на протяжении всего времени работы сайта.

За один только день голосования в бан-лист Front Shield было внесено более 30 тысяч IP-адресов. Злоумышленникам не удалось достичь своей цели от слова совсем. Все системы функционировали штатно — мы держали нагрузку, и сайт отлично работал, быстро и надежно. Также работали телеграм-бот и приложение, которые были полностью изолированы от сайта.

А у нас в трекере висят тикеты — вынести все захардкоженные настройки в файлы конфигурации, написать документацию и выложить исходники Front Shield в общий доступ. Надеемся, у нас до них дойдут руки :)

Вся эта работа была бы невозможна без вашей поддержки. Огромное спасибо!

Поддержать работу IT-отдела можно здесь: https://donate.fbk.info/it

Этот пост был опубликован на портале Habr 14 сентября 2022 года, а на следующий день скрыт администрацией сайта. В поддержке сослались на особый порядок блокировки «в отношении материалов от организаций, признанных экстремистскими» и на «инициирование политических дискуссий». Мы выступаем против ограничения свободы распространения информации. Habr мы рассматривали как площадку для обмена опытом и для отчета о работе нашей технической команды.

РКН против приложения «Навальный»: борьба за доступность

Navalny Team — Thu, 14 Sep 2023 10:53:24 +0000

2021 год в России запомнится беспрецедентной волной судебных и внесудебных блокировок ресурсов средствами DPI. 26 июля Роскомнадзор заблокировал множество наших ресурсов: блог Навального navalny.com, сайт сети региональных штабов shtab.navalny.com, сайт Фонда борьбы с коррупцией fbk.info и другие. Под блокировки попали даже сайты проектов «РосЯма» и «РосЖКХ». Все перечисленные ресурсы были заблокированы на основании требования Генеральной прокуратуры РФ как содержащие призывы к массовым беспорядкам, осуществлению экстремистской деятельности, участию в массовых (публичных) мероприятиях, проводимых с нарушением установленного порядка, и информационные материалы организаций, деятельность которых признана нежелательной. Сайт проекта «Умное голосование» заблокировали за неделю до выборов — 6 сентября. С конца августа РКН развернул настоящую войну с приложением «Навальный» и чуть не сломал весь российский интернет.

В этом посте мы расскажем о противостоянии, которое развернулось между нашей командой и РКН летом — осенью 2021 года: о технологиях по обходу блокировок, о собственной системе мониторинга, о том, как нам удалось «обучить» РКН регулярным выражениям. Расскажем, как РКН был вынужден пойти на крайние меры, попытавшись заблокировать публичные DNS в России, и каких результатов нам удалось достичь.

Введение

Наша команда рассматривала сценарий блокировок заранее. Еще в 2020 году было решено использовать мобильное приложение как основной инструмент доставки до пользователей постов в блоге и рекомендаций «Умного голосования».

С момента введения повсеместного DPI в России за доступность сайтов стало бороться все сложнее. Дело в том, что протокол TLS не предусматривает шифрование изначального «рукопожатия» между клиентом и сервером. Когда во всем мире обнаружился дефицит IPv4-адресов, виртуальный хостинг (когда несколько разных доменов работают на одном IPv4-адресе) пришлось широко использовать и в TLS. Клиент во время рукопожатия передает доменное имя сайта (SNI — Server Name Indication), а сервер в ответ отправляет сертификат для этого домена. Этим и пользуются разработчики DPI, позволяя различать трафик, идущий на один и тот же адрес, по SNI и блокируя только тот, что им нужно. Во время разработки стандарта ESNI (Encrypted SNI, позволяющего шифровать заголовок SNI) обнаружились неустранимые проблемы, и на замену ESNI пришел протокол ECH (Encrypted Client Hello), в котором шифруется все рукопожатие со стороны клиента.

Стандарт ECH еще не стал всеобщим. В IETF он находится в фазе активной разработки в статусе draft. Последнее обновление документа с описанием стандарта было как раз в августе 2021 года. Следовательно, поддержки этого протокола на конечных клиентах (браузерах) не предусматривалось. Мы понимали, что успешно скрыть домен в HTTPS-трафике от РКН нам не удастся. Поддержка доступности web-сайта стала весьма проблематичной задачей.

Когда требование Генпрокуратуры о блокировке было исполнено, сетевое сообщество начало организовывать прокси до заблокированных ресурсов команды Навального, однако на практике это оказалось неэффективным. Любой адрес, замеченный РКН, рано или поздно попадал под внесудебную блокировку и моментально становился недоступным. Было понятно, что любые публично распространенные прокси, вне зависимости от доменного имени, будут успешно заблокированы.

После вступления блокировок в силу мы первым делом провели простой эксперимент: переключили домены наших ресурсов на IP-адреса AppEngine. Были возможны три варианта: либо блокировка полностью отключилась бы (если айпишники AppEngine находились в белом списке у РКН), либо весь AppEngine в российском сегменте интернета оказался бы заблокированным, либо осталась бы только блокировка по DPI. Результаты теста подтвердили наши ожидания — доступность не возросла. Надо отметить, что РКН хорошо подготовился и начиная еще с 2016 года явно обеспечил покрытие DPI на большинстве провайдеров России, в том числе DPI «по сигнатурам» (он же ТСПУ).

Система мониторинга

Здесь стоит рассказать о средствах мониторинга, с помощью которых мы проверяли доступность наши ресурсов.

Блокировки через «технические средства противодействия угрозам» (ТСПУ) нельзя отследить традиционными методами, с помощью реестра РКН или так называемых «Дельт». Нет никакого подлинного списка ресурсов, которые блокировались на уровне ТСПУ. Блокировки приобрели не подотчетный и непрозрачный характер. Поэтому, чтобы отслеживать работоспособность ресурсов, пришлось разработать систему отслеживания на уровне провайдеров РФ.

Для реализации такой системы мы приобрели комплекты Raspberry Pi 3B. Наши читатели наверняка знают, что мы фанаты «Малинок», и в этот раз выбор снова пал на них. Эти микрокомпьютеры обладают полноценной Linux-системой на борту, а также оборудованы сетевой картой с портом RJ45, дешевы и просты в обслуживании.

Модель RPi

Мы подготовили комплекты Pi для волонтеров, которые согласились установить у себя эти импровизированные «зонды». В каждом из них была скомпилирована ОС на базе Ubuntu 20.04 — так, чтобы волонтеру было достаточно просто подключить Raspberry Pi в сеть. Малинки совершали попытки обращения к нужным ресурсам и отслеживали статус, отсылая его нам.

Для безопасности мы скрыли весь служебный трафик Pi в VPN-сеть. Оставили только GET-запросы и скачивание пакетов при обновлении.

Мы постарались охватить своей сетью провайдеров по всей стране. В первую очередь, конечно, нас интересовали провайдеры с ТСПУ, но в связи с тем, что нет никаких официальных публичных списков провайдеров с этим «черным ящиком» на борту, мы пытались придерживаться самых крупных — большой тройки, Ростелекома, Дом.ру и подобных. Сеть составляли где-то 50% провайдеров с ТСПУ и 50% без.

Пример download показателей обращения к ресурсу системы мониторинга

Для отправки запросов, хранения полученных данных и алертов мы воспользовались Zabbix. Чтобы отслеживать блокировки сайтов, использовалась встроенная функция «веб-агента» и кастомные скрипты, исполняемые на зондах.

Дашборд со сканерами системы мониторинга доступности

Для обработки и вывода данных использовалась Grafana.

Дашборд с гистограммой системы мониторинга доступности | Grafana

В дополнение был написан API-микросервис, которому мы дали имя «Navalny Hello». Его основной задачей было выдавать по любому домену информацию о блокировке. Сервис работал на основе Pi-сканеров и выдавал скоринг для каждого запрашиваемого адреса.

Пример ответа сервиса «Navalny Hello» по запросу доступности ya.ru

Требования к приложению

В приложении «Навальный» важнее всего было обеспечить доступность блога и проекта «Умное голосование». Мы публикуем свои рекомендации по голосованию за три дня до выборов, чтобы власти не могли снять кандидатов, за которых мы советуем отдать голос. При этом основная функция приложения — поиск кандидата по адресу (пользователь вбивает свой адрес и получает конкретную рекомендацию). Таким образом, залить список кандидатов прямо в приложение через стандартное обновление было проблематично, — тем более что обновление в Google Play и Apple Store могут рассматривать от нескольких суток до нескольких недель, и такого запаса времени у нас просто не было.

Учитывая необходимость постоянной синхронизации приложения с адресами нашего бэкенда, мы выделили в основных требованиях несколько пунктов:

защита от блокировки IP-адресов;
защита от блокировки доменных имен;
обход DPI-средств провайдеров.

Был подготовлен специальный протокол, который поддерживал технологии DoH-резолвинга и SNI-фейкинга. С помощью закодированного дискавери, представляющего собой JSON-структуру с электронной подписью для защиты от replay-атак, мы смогли «научить» приложение обнаруживать через публичные DNS актуальные адреса бэкенда для обновления контента. Когда РКН банил наш адрес, мы создавали новый, обновляли дискавери, контролировали значение TTL записи, чтобы избежать ненужного кэширования, и таким образом перед очередным запросом пользователя сообщали для него новый маршрут обращения. К моменту блокировки сайтов приложение работало в Google Play и Apple Store с данной версией протокола.

Ротация «на опережение»

В «мирное время» секретные механизмы предусмотрительно не были включены. Специалисты РКН не совершали никаких дополнительных действий после блокировок сайтов и только 20 августа перешли в наступление и предприняли первые попытки заблокировать адреса приложения. Чтобы не раскрывать все наши возможности до дня выборов, мы решили поиграть в «догонялки» с РКН — обновляя дискавери и доставляя пользователю необходимые адреса.

По первым наблюдениям, РКН осуществлял мониторинг чуть ли не вручную. Мы запустили скрипт, который генерил доменные адреса третьего уровня, например 1np13q836n.rkngov.com, готовил для них необходимый бекенд и отдавал в дискавери. Согласно нашему мониторингу, каждый новый адрес третьего уровня попадал в реестр и разливался в качестве правила по провайдерам в течение 13 минут. Когда в РКН удостоверились, что мы осуществляем ротацию доменов исключительно третьего уровня, они наконец решились блокировать всю вторую зону целиком.

Мы вернулись к варианту хостинга на AppEngine. Каждый проект в AppEngine автоматически получает служебное доменное имя, соответствующее идентификатору проекта. Скажем, проект navalnyapp был доступен на домене navalnyapp.appspot.com. Однако в документации на AppEngine мы обнаружили, что сайты получают и другие служебные домены, например <версия>-dot-<проект>.appspot.com. Если в качестве версии указать любую строку, для которой даже нет версии приложения, то осуществляется fallback на основную версию. В итоге адрес для ротации в дискавери был заменен на *-dot-navalnyapp.appspot.com. Основная задумка заключалась в том, что в данном случае нам не обязательно было «заранее готовить» новый адрес. Достаточно было дописать перед «dot» любое слово, и такие адреса моментально мапились на наш проект. РКН стал получать на своих сканерах «адреса-приветы» от нашей команды — putinprivet-dot-navalnyapp.appspot.com, putinvor-dot-navalnyapp.appspot.com, 123putinuhodi-dot-navalnyapp.appspot.com, 321putin… и т.д.

Вы можете проверить это сами: придумайте любой аналогичный адрес, вбейте его в браузер — и обнаружите на корневом адресе блог Навального. Впрочем, сейчас все эти адреса заблокированы.

Подобным образом мы могли осуществлять ротацию в любом объеме и в любое время. На сканерах своего мониторинга мы мгновенно увидели 100% доступность, и РКН встал перед выбором: либо обучить свой блокирующий софт регуляркам, либо заблокировать всю зону appspot.com целиком.

Дашборд с показателями доступности приложения при ротации служебных доменов -dot-navalnyapp.appspot.com

Интересно заметить, что на любой «нестандартный» ход РКН реагировал с предсказуемой задержкой. Если мы что-то меняли в будни, условно говоря, с 9 до 17, то реакция следовала в течение часа. А если дожидались вечера (лучше, конечно, вечера пятницы), то 100% доступность сохранялась до 9 утра следующего рабочего дня. Видимо, у РКН была дежурная смена юных падаванов, которые делали какие-то совсем простые вещи, и настоящие специалисты, доступные только в рабочее время.

Пока РКН «учился в регулярки», мы смогли выиграть время и апгрейднуть скрипт ротации наших адресов. В связи с тем, что любые из них блокировались сразу по второй зоне целиком, мы написали обновление. Скрипт заблаговременно и массово регистрировал домены второго уровня у одного из хостеров. Затем регистрировал их в CloudFlare, добавлял в качестве кастомного домена к нашему проекту в AppEngine (это было сделано для того, чтобы исключить блокировки на тех провайдерах, которые не умели в DPI), ждал выпуска сертификата гуглом и каждые n минут подсовывал эти домены приложению, предварительно проверяя через наш вышеупомянутый сервис «Navalny Hello», не заблокированы ли они. Таким образом мы могли переиспользовать адрес, если РКН со временем внезапно решил бы его «разблокировать». Благодаря непрерывному мониторингу, ускоряя или замедляя скрипт, мы могли определить, за какое время РКН замечал новые адреса второго уровня. В очередной раз на сканеры нашего противника посыпались «адреса-приветы» самых дешевых доменных зон, например: www.roskomnadzoruhodi.website, www.svobodypoltzakluchennym.xyz, www.rknidiotdohni.fun, www.privetput1nu.online, www.rknprivet.club и т.д.

Вы можете проверить — эти адреса и сейчас заблокированы у провайдеров с ТСПУ.

CDN вступают в борьбу

Мы в очередной раз выиграли время. Но предварительная покупка доменов, пускай даже в самых дешевых доменных зонах, в долгосрочной перспективе и в больших объемах требует затрат, а от идентификации адреса до распространения блокировки на провайдерах, согласно нашим сканерам, стало проходить не больше минуты. Так что мы решили обратиться за адресами к известным CDN-провайдерам, таким как Bunny, Fastly, Amazon.

Идея заключалась в том, что РКН не решится целиком блокировать доменную зону второго уровня, предоставляемую публично известными CDN-провайдерами, и мы сможем относительно дешево проксировать трафик на бэкенд с их помощью через дискавери приложения. Пошаманив с настройками кэширования, мы запустили скрипт ротации доменов с CDN от Bunny.

К моменту, когда мы израсходовали более 6000 подобных адресов, РКН также провел несколько тестов и все-таки решился на полную блокировку b-cdn.net на ТСПУ. Практически сразу мы получили письмо от основателя Bunny о том, что они вынуждены приостановить действие нашей учетной записи, поскольку это негативно сказывается на доступности их сети. Вероятнее всего, блокировкой РКН был задеты крупные пользователи Bunny в России.

Письмо от основателя Bunny c объяснением причин блокировки аккаунта

В качестве резервного варианта мы переключили ротацию на Fastly CDN. Это работало нормально, и на этот раз РКН уже не решался блокировать весь второй уровень более известного CDN. Но из-за ограничений по количеству создаваемых зон на аккаунт (мы не всегда могли освобождать старые зоны, и из-за багов в приложении в некоторых случаях приходилось их «копить», чтобы устройства, получившие старую запись дискавери, могли их использовать неограниченно долго) в конечном счете мы перешли на адреса Amazon. Довольно легко получилось арендовать на старте квоту со значением около 10 тысяч адресов в доменной зоне cloudfront.net.

На этот раз мы наконец создали очевидную проблему для РКН. Адреса пачками и довольно быстро готовились по ранее опробованному скрипту. Наши сканеры зафиксировали рост доступности.

Доступность адресов CloudFront при использовании в ротации приложения «Навальный»

DNS под угрозой. Domain Fronting, DOH-резолвинг и NewNode

РКН оставалось разве что блокировать Amazon целиком. И в этом случае у нашего приложения в запасе еще оставался секретный механизм SNI-фейкинга. Именно в этот момент в РКН впервые задумались о запрете на использование публичных систем доменных имен и начали готовить российских провайдеров к отключению Google и CloudFlare DNS, рассылая соответствующие письма с требованиями.

В РКН даже провели тесты кратковременной блокировки DNS, что и зафиксировал наш мониторинг и пользователи российского сегмента интернета:

https://twitter.com/ShieldNav/status/1435692644676603906?

Мы были готовы и к такому развитию событий. Все это время параллельно работали над дополнительными обновлениями по обходу блокировок для нашего приложения. Мы полагали, что на один день забанить Tor ради большой цели для РКН, в принципе, не будет проблемой. Конечно, у этого был бы медийный эффект, но, вероятнее всего, кроме гиков, этого бы почти никто не заметил. Так что идею использовать Tor мы отложили. Была подготовлена имплементация технологии Domain Fronting в качестве дополнительного инструментария, которым мы могли аналогичным образом управлять на стороне клиента через дискавери. А также DOH-резолвинга на случай полной блокировки DNS в России и решения проблемы обновления самого дискавери.

Идея была проста. Вышеупомянутый navalnyapp.appspot.com, (а вообще говоря, любой *.appspot.com) можно фронтить в любой ${garbage}.appspot.com. Мы также нашли возможность фронтинга еще через пару популярных ресурсов, которые РКН вряд ли решился бы полностью отключить в России (мы намеренно не хотели бы раскрывать их в этом посте). Добавили этот функционал в приложение. А в качестве DoH-резолвинга расширили параметры нашего дискавери до получения записей с нескольких storage-провайдеров, таких как Google Cloud Storage и Amazon S3, на случай блокировки Google и Cloudflare DNS.

Помимо всего прочего, в приложении закладывались и альтернативные, весьма экспериментальные способы обхода блокировок, включая использование механизмов P2P-обмена данными. В конце августа нам удалось сделать экспериментальную сборку приложения с внедренным SDK под названием NewNode. NewNode, а также экспериментальный мессенджер FireSide — продолжение исследовательских работ, которую ведет команда, известная другим инновационным мессенджером FireChat. Они же разработчики известного протокола BitTorrent. По задумке, эта штука должна обеспечивать связность даже при полном отключении интернета — просто передавая данные от клиента к клиенту через встроенные в мобильные телефоны модули беспроводной связи Bluetooth и Wi-Fi. SDK NewNode специально создан, чтоб научить мобильные приложения использовать для передачи данных встроенные механизмы BitTorrent, LEDBAT и передачу данных от устройства к устройству (Device-to-Device Communications — D2D). Эта тема, пожалуй, заслуживает отдельной статьи, но если коротко объяснять принцип работы, то для разработчика SDK выглядит как прокси, который использует собственный транспорт для передачи данных: сильно переделанный DHT в качестве транспорта, D2D для организации каналов в случае недоступности интернет-ресурса и LEDBAT, который оркеструет все доступные способы коммуникации, выбирая самый эффективный в данный момент времени.

В постановлении РКН о блокировке публичных DNS для провайдеров предполагалась также блокировка DNS-over-UDP. Именно этот сервис использует библиотека NewNode, что только укрепляет нас в мысли о направленности данных действий исключительно против нашего приложения. Примерно в то же время была замечена и блокировка приложения NewPipe в части YouTube-клиента по TLS-отпечаткам. РКН, по всей видимости, проводил предварительные тесты (или перепутал NewNode или NewPipe? :))

Последняя сборка приложения «Навальный» содержит NewNode и потенциально будет работать (в крупных городах с большой плотностью населения) даже при полном отключении интернета.

Заключение

Паралельно с ежеминутными блокировками, РКН продолжал отправлять запросы в Apple и Google с требованиями удалить приложение «Навальный». Письмами дело не ограничилось — представителей Apple и Google вызвали в Совет Федерации на заседание комиссии по защите суверенитета: неисполнение требований РКН было воспринято как иностранное вмешательство в выборы. В московский офис Google незадолго до выборов приходили силовики. Дошло и до прямого шантажа — по данным издания Bloomberg, российским сотрудникам Google угрожали тюрьмой, если компания не исполнит требования властей.

Письмо от РКН с запросом удаления приложения «Навальный» в App Store service

Само собой, все эти процессы усложняли ревью любых наших обновлений. Рассмотрение зависало на несколько дней. Последние обновления, c domain-fronting и DoH-резолвингом, мы отправили 10 сентября. Очевидно, РКН рассматривал два сценария: либо приложение удастся удалить, либо придется ломать половину российского интернета, отключив публичные DNS. К счастью для РКН, им удалось добиться первого сценария. В конце концов, после почти недельного ожидания, наши обновления были подтверждены магазинами приложений, но одновременно с этим их моментально удалили из магазинов. Это случилось утром 17 сентября, в первый день выборов. А в ночь на 18 сентября Павел Дуров, сославшись на действия Apple и Google, заблокировал телеграм-бота «Умного голосования».

Наша команда распространяла списки с рекомендациями кандидатов через репозиторий в Github, Google Docs, YouTube и APK-сборку Android c последними алгоритмами обхода блокировок. Аккурат перед днем голосования мы успели закинуть в магазины приложений и последнее обновление с обычным PDF-файлом, где содержался список рекомендованных кандидатов. Так что те немногие пользователи, которые все-таки успели обновить или загрузить сборку, могли потрясти телефон и посмотреть в PDF список кандидатов даже без активного подключения к интернету.

В РКН понимают, что, как только будет принят стандарт ECH и его реализация доедет до серверов крупных сервисов и в популярные браузеры, бороться с непокорными сайтами станет намного сложнее. DPI придется полагаться исключительно на фингерпринтинг со всеми вытекающими ложноположительными и ложноотрицательными проблемами. Иными словами, им придется или поломать весь интернет, или сдаться. Поэтому на следующий день после выборов Министерство цифрового развития, связи и массовых коммуникаций РФ разместило для общественного обсуждения проект федерального закона, устанавливающего запрет на использование на территории РФ протоколов шифрования, которые позволяют скрыть имя (идентификатор) интернет-страницы или сайта. Нет никаких сомнений, что это происходит для «легализации» борьбы с новыми методами обхода блокировок, подобными тем, над которыми работала наша команда в этом году.

Такие законы с каждым днем делают российский сегмент интернета все хуже — менее безопасным и менее приватным. Наша задача — отстоять его.

Вся эта работа была бы невозможна без вашей поддержки. Огромное спасибо!

Поддержать работу IT-отдела можно здесь: https://donate.fbk.info/it

Этот пост был опубликован на портале Habr и в 2022 году скрыт администрацией сайта. В поддержке сослались на особый порядок блокировки «в отношении материалов от организаций, признанных экстремистскими» и на «инициирование политических дискуссий». Мы выступаем против ограничения свободы распространения информации. Habr мы рассматривали как площадку для обмена опытом и для отчета о работе нашей технической команды.