🥷 Джонни вещает: репозиторий 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

🌐 Технический ликбез: CAA, RFC 8657 и как это должно нас спасать

Казалось бы, если твой трафик могут перехватить на уровне провайдера, то ты беззащитен. Но это не так. Для защиты от подобных сценариев существует механизм Certification Authority Authorization (CAA), описанный в RFC 8659.

Это простая DNS запись, которая говорит: "Для моего домена сертификаты может выпускать только вот этот УЦ".

# Разрешаем только Let's Encrypt
example.com. IN CAA 0 issue "letsencrypt.org"

Но, как показал случай с jabber.ru, этого недостаточно. Атакующие ведь и использовали разрешённый УЦ, который им и выдал сертификат.

Постфактум, благодаря анализу инцидента инженером по имени Хьюго Ландау (Hugo Landau), он пришёл к выводу, что предложенный им стандарт ещё в далеком 2019 году под номером RFC 8657 мог бы предотвратить подобный инцидент. Этот стандарт расширяет CAA двумя критически важными параметрами:

1. accounturi: Это «второй фактор» для выдачи сертификата. Этот параметр привязывает выдачу сертификатов к конкретному аккаунту в УЦ. URI вашего аккаунта в Let's Encrypt — это уникальный идентификатор.

# Разрешаем Let's Encrypt, но ТОЛЬКО с аккаунта с ID 12345678

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"

Даже если злоумышленник перехватит ваш трафик, он не сможет получить сертификат, потому что его запрос придёт с другого аккаунта Let's Encrypt, а LE поддерживает этот стандарт ещё с января 2021 года. УЦ сверит accounturi из запроса с тем, что указан в вашей CAA-записи, увидит несоответствие и откажет в выпуске.

2. validationmethods: Этот параметр позволяет ограничить методы, которыми УЦ может проверять владение доменом.

# Разрешаем Let's Encrypt, но только через DNS-валидацию

example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

Поскольку атака на jabber.ru была возможна из-за перехвата сетевого трафика, ограничение валидации методом dns-01 (который требует внесения изменений в DNS-зону, а не контроля над трафиком) сделало бы атаку значительно сложнее, а использование DNSSEC доменом могло бы сделать её вовсе невозможной.

3. Комбо

# Максимальная защита

example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01;
accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"

Хьюго Ландау, автор RFC 8657, заявлял в своём анализе инцидента, что основываясь на том, что мы знаем об этой атаке, она была бы предотвращена развёртыванием этого расширения.

#Cloudflare #DNS #MITM #CAA #RFC | 😊 @iscode

🥷 Слон в посудной лавке: при чём тут Cloudflare?

А теперь самое главное. Cloudflare, будучи лидером в области интернет-инфраструктуры и безопасности, для своего безальтернативного для бесплатных аккаунтов сервиса Universal SSL делает очень странную вещь - когда он включен, Cloudflare автоматически добавляет в вашу DNS-зону CAA-записи для своих партнёрских УЦ (Let's Encrypt, Google Trust Services и др.).

Вот как выглядит эта запись:

# Записи для обычных сертификатов (issue)
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "pki.goog; cansignhttpexchanges=yes"
example.com. IN CAA 0 issue "digicert.com; cansignhttpexchanges=yes"
example.com. IN CAA 0 issue "comodoca.com"
example.com. IN CAA 0 issue "ssl.com"

# Записи для wildcard-сертификатов (issuewild)
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 issuewild "pki.goog; cansignhttpexchanges=yes"
example.com. IN CAA 0 issuewild "digicert.com; cansignhttpexchanges=yes"
example.com. IN CAA 0 issuewild "comodoca.com"
example.com. IN CAA 0 issuewild "ssl.com"

Видите проблему? Они до сих пор не используют accounturi и не дают переписать записи!

Это оставляет ту же самую дыру в безопасности, от которой пострадал jabber.ru . Cloudflare, по сути, говорит: "Любой аккаунт в Let's Encrypt может получить сертификат для этого домена, если пройдёт валидацию".

Ваша собственная, более строгая CAA-запись с accounturi для вашего сервера, не спрятанного за прокси, становится практически бесполезной. Потому что по правилам обработки CAA, если есть хотя бы одна разрешающая запись без accounturi, УЦ имеет право выпустить сертификат для любого аккаунта. А если вы решите вручную прописать в CF записи с accounturi , то CF заботливо их не применит и оставит свои. А чтобы отказаться от Universal SSL, придётся заплатить чеканную монету.

— Таким образом, Cloudflare не просто не использует современные стандарты безопасности для своих клиентов, но и активно мешает им делать это самостоятельно, сводя на нет всю идею RFC 8657.

Выводы и что делать?
Ситуация на данный момент патовая. С одной стороны, у нас есть рабочий и поддерживаемый ведущими УЦ (Let's Encrypt внедрил это ещё в 2021 году) стандарт, который решает реальную и доказанную проблему. С другой - крупнейший инфраструктурный провайдер, который не только игнорирует этот стандарт, игнорирует сообщения об этом стандарте, но и своей реализацией создаёт риски для миллионов пользователей.

Для пользователей:

1. Проведите аудит. Проверьте свои CAA-записи. Если вы используете Universal SSL от Cloudflare, знайте, что вы уязвимы для атак типа jabber.ru.
2. Требуйте перемен. Если вам небезразлична безопасность вашего проекта, поддержите мою тему на форуме Cloudflare. Чем больше будет резонанс, тем выше вероятность, что нас услышат. Это не первый такой запрос, но предыдущие были попросту проигнорированы.
3. Рассмотрите альтернативы. Для критически важных проектов, возможно, стоит отказаться от Universal SSL в пользу ручного управления сертификатами и полного контроля над CAA-записями либо в Cloudflare, либо в другом сервисе.

Что должен сделать Cloudflare:
1. Начать использовать accounturi и validationmethods для всех сертификатов, которые они выпускают в рамках Universal SSL. Это немедленно и по умолчанию повысит безопасность для всех их клиентов. Они же точно знают ID своих профилей, который запрашивают выпуск сертификатов?
2. Обеспечить полное управление CAA-записями для пользователей, чтобы они могли добавлять свои собственные записи с accounturi и validationmethods, и чтобы эти записи корректно сосуществовали с записями Cloudflare.
3. Обновить документацию и честно рассказать пользователям о текущих рисках и о том, как они обрабатывают CAA.

Да, белый пушистый лис не объявит себя до некоторого времени, но, как показывает практика, он гарантированно придёт. И лучше закрыть эту дыру сейчас, чем потом разгребать последствия, как это пришлось делать администраторам jabber.ru.

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

#meme | 😊 @iscode

🥷 Глубокий разбор российских СЗИ: антивирусы, НСД, виртуализация

Коллеги, выбор отечественных средств защиты информации (СЗИ) — критически важен для ИБ-инфраструктуры. Где искать актуальные исследования и глубокий анализ? И почему же это важно? — об этом речь пойдёт ниже:

Во-первых, если криво выбрать СЗИ, оно запросто может тормозить всю сеть – представим, что антивирус начнет грузить канал до упора или агент контроля доступа положит сервер. И безопасность сегментов тоже станет под ударом: слабое звено в одном месте – угроза для всех.
Во-вторых, защита виртуализации – это прямая связка с сетевым разделением! VLAN'ы, микросегментация – они должны идеально работать с тем, как СЗИ изолирует виртуалки и контролирует трафик между ними. Без этого толку – ноль.

🕹 Ну и не забудем про централизованное управление: все эти консоли для СЗИ жрут сеть как не в себя. Если инфраструктура кривая – лаги, потеря событий безопасности, администрирование превратится в кошмар. Короче, без нормальной сети – никак. Вот почему стоит всегда быть в курсе фишек и подводных камней российских СЗИ.

🔍 Основной упор — канал CORTEL: @Cortel_cloud

Именно там регулярно публикуют:
— Детальные сравнительные обзоры российских СЗИ по всем указанным направлениям.
— 8 кругов ада на пути отказа от зарубежных виртуальных платформ
— 4 кейса успешной замены иностранных гипервизоров
— Как энергетики перевели ИТ-инфраструктуру на российский софт

Ещё больше полезного про ИБ и не только в канале CORTEL

➡️ Подписаться

Реклама ООО "Кортэл"
ИНН: 7816246925

Онлайн-конференция ИБ без фильтров

🔥Мероприятие, где говорим о реальных проблемах и ищем практические решения, возвращается!

🗓 14 августа 11:00-15:00 мск ждем на бесплатной онлайн-конференции «ИБ без фильтров»

Что будет полезного?

Честный диалог, нестандартные кейсы и полезный опыт — все без фильтров.

Кому стоит сходить?

Мероприятие для представителей бизнеса от экспертов в области информационной безопасности.

Какие темы затронем?

— Как оценить навыки ИБ-специалиста.
— Как снизить риски с помощью систем класса «менеджеры паролей».
— Как вовлечь разработчиков, сотрудников и бизнес в защиту компании.
— Чем важны разные источники данных при расследовании инцидентов ИБ.

Кто в спикерах:
— Анастасия Федорова. Руководитель образовательных программ, Positive Education
— Кира Шиянова. Менеджер продукта платформы Jet CyberCamp, «Инфосистемы Джет»
— Никита Вьюгин. Менеджер проектов «МКО Системы»
— Валерий Комягин. Генеральный директор BearPass
— и другие эксперты из крупных компаний рынка ИБ

▶️Регистрация по ссылке.
Ждем вас на самый честный диалог по теме ИБ

🥷 Джонни вещает: проброс авторизации

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

🆘 Для понимания ситуации, пример ниже будет ссылаться на вот эту схему (click)

Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.

— Компромиссным вариантом было бы иметь «другой» SSH-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

⚙️ SSH предлагает возможность форварда SSH-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.

Вызов выглядит так: ssh -A user@8.8.8.8 ssh user2@10.1.1.2

Удалённый SSH-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали SSH-клиенту доступ к своему агенту авторизации (но не ключу!).

#SSH #Authorization | 😊 @iscode