↓ English version is below ↓
Уроки, вынесенные из отключения интернета в Казахстане в январе 2022 года для обхода цензуры
Интернет в Казахстане был недоступен большую часть дня, каждый день с 05.01.2022 по 10.01.2022. Но блокировка не была полной: люди в Казахстане и за его пределами находили способы хоть как-то устанавливать соединения. Хотя успех был лишь частичным, он показал, что отключение Интернета — не обязательно безнадежная ситуация. Существуют инструменты и методы, которые мы можем использовать в будущем.
Обсуждение случившегося:
- Network shutdown, all around Kazakhstan
- Shutdown in Kazakhstan since 2022-01-05, with brief periods of connectivity · Issue #99 · net4people/bbs · GitHub
- Kazakhstan internet shutdowns and protests: Timeline
Что удалось:
- Жители Казахстана быстро сообщили о моменте отключения (которое сначала было только в мобильных сетях). Исследователи со стороны (например, Cloudflare Radar, CAIDA IODA, Атлас RIPE) смогли собрать данные о сетевой связности и отслеживать её изменения.
- Жители Казахстана могли проводить тесты сети и сообщать о своих результатах в течение коротких периодов восстановления доступа.
- Было обнаружено, что некоторые TCP-порты (включая как минимум порты 3785 и 179) не были заблокированы: исследователи настроили прокси-серверы на этих портах, чтобы предоставлять людям в стране доступ в интернет.
- Было обнаружено, что DNS-трафик на UDP-порту 53 не был заблокирован, и некоторые смогли выйти в сеть с помощью DNS-туннеля.
Что можно улучшить в работе исследователей:
- Начальная реакция могла бы быть быстрее. Было бы хорошо начать настраивать прокси в первый или второй день, а не на 4 или 5.
- Отсутствуют преднастроенные и публичные туннели DNS. Людям приходилось делать свои собственные туннели, что значительно ограничивало круг лиц, для которых был доступен этот метод обхода.
Также следует понимать, что сила даже авторитарных государств не безгранична. Казахстан столкнулся с политическими и экономическими проблемами, которые затруднили удержание интернета в отключенном состоянии. Касым-Жомарт Токаев, президент Казахстана, сказал следующее в публичном выступлении 7 января 2022:
https://www.gov.kz/news/details/309489?lang=kk (архив)
Осындай «белсенділердің» кесірінен интернет бұғатталады. Нәтижесінде миллиондаған азамат пен отандық бизнес зардап шегеді.
https://www.gov.kz/news/details/309489?lang=ru (архив)
Из-за этих «активистов» «зауживается» Интернет, в результате чего страдают интересы миллионов граждан и отечественного бизнеса. То есть наносится огромный ущерб внутренней экономической, социальной и политической стабильности.
https://www.gov.kz/news/details/309489?lang=en (архив)
Because of these activists, the use of Internet gets limited, as a result of which the interests of millions of citizens and domestic businesses suffer. In other words, internal economic, social and political stability is greatly damaged.
Следует улучшить нашу координацию в ответ на такие внезапные события, как отключение интернет-связности, но при этом стремиться сделать так, чтобы надёжно отключать интернет стало сложнее в общем и целом.
Открытые порты и их сканирование
09 января 2022 г. было сообщено, что в стране работают обычные SOCKS-прокси на порту TCP 3875. На следующей день было получено подтверждение, что OpenVPN на порту UDP 3785 также работает. Сканирование портов показало также доступность порта 179.
Порты 3785 и 179 используются для маршрутизации. 3785 — bfd-echo (Bidirectional Forwarding Detection Echo). Порт 179 — bgp (Border Gateway Protocol). Доступность этих портов конечным пользователям можно объяснить некорректной настройкой блокировки или техническими ограничениями. Однако, следует помнить об этом в дальнейшем.
На факт доступности этих портов отреагировал Tor Project, открыв особую службу поддержки пользователей по почте, предоставляющую мосты Tor на рабочих портах. Lantern перенастроил часть своих серверов на порт 3785 и другие.
Сканирование портов — удобный метод для нахождения брешей в системе блокировок в целом. В случае отключения интернета он был особенно полезен, т.к. зачастую сканировать порты можно извне с такой же точностью, как и изнутри страны. Так, доступность порта 179 была обнаружена путём сканирования сети Казахстана снаружи: сначала был обнаружен хост, доступный по порту 3785, затем было произведено сканирование всех портов этого хоста. Это выглядит следующим образом в Nmap:
# nmap -PS3785 -sn -n gov.kz/24
Nmap scan report for 195.12.114.89
Host is up (0.21s latency).
Nmap done: 256 IP addresses (1 host up) scanned in 15.57 seconds
# nmap -Pn -n -p- --reason 195.12.114.89
Nmap scan report for 195.12.114.89
Host is up, received user-set (0.23s latency).
Not shown: 65529 filtered ports
Reason: 65529 no-responses
PORT STATE SERVICE REASON
179/tcp closed bgp reset ttl 233
646/tcp closed ldp reset ttl 236
3784/tcp closed bfd-control reset ttl 234
3785/tcp closed bfd-echo reset ttl 234
4784/tcp closed bfd-multi-ctl reset ttl 233
5060/tcp open sip syn-ack ttl 50
Nmap done: 1 IP address (1 host up) scanned in 344.21 seconds
gov.kz/24 означает сканирование IP-адресов gov.kz и всей подсети /24, т.е. 256 соседних адресов. -PS3785 включает функцию обнаружения хостов с помощью отправки TCP SYN на порт 3785. -sn отключает полное сканирование портов и выводит только доступные хосты. -n отключает получение обратной DNS-записи PTR. -Pn отключает другие способы обнаружения доступности хостов и выполнит только сканирование одного порта. -p- задаёт сканирование портов 0–65535. --reason добавляет колонку REASON в вывод программы.
В этом случае мы уже знали о доступности порта 3785, поэтому поиск других портов был достаточно простой задачей и мог быть выполнен в пределах маленькой сети. Если о доступности портов изначально неизвестно, следует сканировать больший диапазон портов.
DNS-туннели
09 января 2022 г. пользователь сообщил о работоспособности dnstt — туннеля DNS, в режиме подключения по UDP-порту 53. По-видимому, можно было использовать как провайдерский DNS-резолвер, так и публичный резолвер 8.8.8.8 от Google в качестве промежуточного узла для построения туннеля.
dnstt был создан отчасти как реакция на отключение работы интернета в Иране в ноябре 2019 г., когда OONI сообщали, что DNS-трафик не был заблокирован. Хоть dnstt в первую очередь предназначен для использования с зашифрованным DNS (DNS через TLS или DNS через HTTPS), он поддерживает режим UDP DNS, несмотря на неустойчивость этого режима к блокировке, как раз для подобных экстремальных ситуаций.
Но полезность туннелей DNS была ограничена, потому что на момент отключения не было уже существующей прокси-инфраструктуры, а для человека, не подкованного с технологиях обхода, не было простого способа запустить туннельный клиент — в частности, не было готовых клиентов для мобильных устройств. Настройка туннеля DNS требует настройки некоторых записей DNS, запуска туннельного сервера на постоянно подключенном к сети компьютере и распространения связки из доменного имени и открытого ключа среди потенциальных пользователей. Выполнение некоторых из этих шагов заранее позволит нам реагировать быстрее.
DNS-туннели, использующие порт UDP 53, легко обнаружить, т.к. они передают доменное имя туннелирующего сервера в открытом виде. Из-за отсутствия шифрования, человек, просматривающий трафик, может обнаружить имя сервера и заблокировать его. dnstt шифрует содержимое запросов, но он не может предотвратить факт обнаружения использования DNS-туннеля. Было предложено улучшить программу, чтобы она отвечала на любой запрашиваемый домен, что немного повысит устойчивость к блокировке, поскольку к одному и тому же серверу можно обращаться по разным именам, но даже при этом можно обнаружить туннель UDP на порту 53. Лично мне обычно не нравятся методы обхода цензуры, которые зависят от неосведомленности цензора, но я думаю, что такие вещи оправданы, поскольку мы продвигаем границы того, что может быть возможно во время отключения доступа к сети.
Перевод от @ValdikSS.
Lessons from the January 2022 Internet shutdown in Kazakhstan for censorship circumvention
Internet access in Kazakhstan was shut down for most of the day, every day between 2022-01-05 and 2022-01-10. But the blockade was not total: people inside and outside Kazakhstan found ways to maintain a small level of connectivity. Though success was only partial, it showed that an Internet shutdown is not necessarily a hopeless situation. There are tools and techniques that we can be prepared to try in the future.
Background:
- Network shutdown, all around Kazakhstan
- Shutdown in Kazakhstan since 2022-01-05, with brief periods of connectivity · Issue #99 · net4people/bbs · GitHub
- Kazakhstan internet shutdowns and protests: Timeline
What worked well:
- People inside Kazakhstan quickly reported the onset of the shutdown (which was only on mobile networks at first). Researchers on the outside (for example Cloudflare Radar, CAIDA IODA, RIPE Atlas) were able to collect network evidence and monitor for changes.
- People in Kazakhstan could perform network tests, and report their results during the brief periods of restored access.
- It was discovered that certain TCP ports (including at least ports 3785 and 179) were not blocked, and proxies were set up on those ports to help people in the country.
- It was discovered that DNS traffic on UDP port 53 was not blocked, and some people were able to get access using a DNS tunnel.
What we can do better:
- The initial response might have been faster. It would have been good to start setting up proxies on day 1 or 2, not day 4 or 5.
- There was no easy-to-use DNS tunnel infrastructure already in place. People had to make their own tunnels, which effectively limited the number of people who could use this form of circumvention.
It is good to remember that even authoritarians’ power is not unlimited. They face political and economic constraints that increase the cost of sustaining a shutdown. Kassym-Jomart Tokayev, the President of Kazakhstan, acknowledge the cost of the shutdown in his public address of 2022-01-07:
https://www.gov.kz/news/details/309489?lang=kk (archive)
Осындай «белсенділердің» кесірінен интернет бұғатталады. Нәтижесінде миллиондаған азамат пен отандық бизнес зардап шегеді.
https://www.gov.kz/news/details/309489?lang=ru (archive)
Из-за этих «активистов» «зауживается» Интернет, в результате чего страдают интересы миллионов граждан и отечественного бизнеса. То есть наносится огромный ущерб внутренней экономической, социальной и политической стабильности.
https://www.gov.kz/news/details/309489?lang=en (archive)
Because of these activists, the use of Internet gets limited, as a result of which the interests of millions of citizens and domestic businesses suffer. In other words, internal economic, social and political stability is greatly damaged.
Let’s improve our ability to respond to acute situations like shutdowns, while keeping in mind a broader goal of establishing conditions in which acts like shutting down the Internet are harder to commit.
Open ports and port scans
On 2022-01-09, it was reported that a plain SOCKS proxy on TCP port 3875 worked. A day later there was confirmation that OpenVPN on UDP port 3785 also worked. Port scans further revealed that port 179 worked as well.
Ports 3785 and 179 are related to routing. 3785 is bfd-echo (Bidirectional Forwarding Detection Echo). Port 179 is bgp (Border Gateway Protocol). The fact that these ports were open to ordinary users may have been only an oversight or a technical limitation. Nevertheless, it is a good thing to remember.
The Tor Project responded to the port-number discovery by setting up a special email help line for users to get a Tor bridge on a usable port. Lantern made some of their servers listen on port 3785 and others.
Port scanning can be a useful technique for finding holes in blockades, in general. In a shutdown situation, it can be especially useful, because it likely works equally well from the inside or the outside. In this case, the accessibility of port 179 was discovered by scanning a network in Kazakhstan, from the outside, to find a host that responded on port 3785; then scanning to see what other ports that host responded on. Using Nmap, it looks like this:
# nmap -PS3785 -sn -n gov.kz/24
Nmap scan report for 195.12.114.89
Host is up (0.21s latency).
Nmap done: 256 IP addresses (1 host up) scanned in 15.57 seconds
# nmap -Pn -n -p- --reason 195.12.114.89
Nmap scan report for 195.12.114.89
Host is up, received user-set (0.23s latency).
Not shown: 65529 filtered ports
Reason: 65529 no-responses
PORT STATE SERVICE REASON
179/tcp closed bgp reset ttl 233
646/tcp closed ldp reset ttl 236
3784/tcp closed bfd-control reset ttl 234
3785/tcp closed bfd-echo reset ttl 234
4784/tcp closed bfd-multi-ctl reset ttl 233
5060/tcp open sip syn-ack ttl 50
Nmap done: 1 IP address (1 host up) scanned in 344.21 seconds
gov.kz/24 means to scan the IP address of gov.kz and its /24 network; i.e., it and the 255 addresses around it. -PS3785 means to do host discovery using a TCP SYN probe to port 3785. -sn means to only report the hosts that are up, do not port scan yet. -n means not to do reverse DNS resolution. -Pn means to skip host discovery and only do a port scan. -p- means to scan all 65536 TCP ports. --reason adds the REASON column to the output.
In this case, we had the advantage of already knowing that port 3785 was accessible, so it was relatively easy to find other ports, by scanning a small network. If no ports are known in advance, you may have to start with a wider scan over a large range of ports.
DNS tunnels
On 2022-01-09, a user reported having success with dnstt, a DNS tunnel, in its UDP port 53 mode. Apparently, one could use either an ISP resolver, or Google’s 8.8.8.8, as the recursive resolver in the middle of the tunnel.
dnstt was created, in part, as a reaction to the November 2019 shutdown in Iran, when OONI reported that DNS traffic was not blocked. Although dnstt is primarily intended to be used with encrypted DNS (DNS over TLS or DNS over HTTPS), it retains a UDP DNS mode, even though that mode is not resistant to blocking, precisely because it may be useful in an extreme situation such as a shutdown.
But the usefulness of DNS tunnels was limited, because there was no alredy existing proxy infrastructure in place at the time of the shutdown, and no easy way for someone without technical ability to run a tunnel client—in particular there was no ready-made mobile app. Setting up a DNS tunnel requires setting some DNS records, running a tunnel server on an always-on network-connected computer, and distributing the server’s domain name and public key to potential users. Doing some of these steps in advance would let us respond more quickly.
DNS tunnels that use UDP port 53 are detectable because they must include the domain name of the tunnel server. Without some form of encrypted DNS, a middlebox observer can look for DNS queries that are addressed to known tunnel servers, and block them. (dnstt encrypts the contents of the tunnel, but without encrypted DNS it cannot hide the existence of the tunnel.) There is a proposal to let the dnstt tunnel server respond to any domain name, which would enhance blocking resistance a bit, because the same server could be addressed by many names, but even with this a UDP port 53 tunnel is detectable. Personally, I do not normally like circumvention strategies that depend on a censor being ignorant, but I think it is justifiable to try things like this, as we advance the frontiers of what may be possible during a shutdown.