Кибербез Андрея Дугина

Насыщенная получается неделя. Только вчера вернулся из Самары, как завтра уже выступать на конференции в Петербурге.

Буду рассказывать о миграционных маршрутах сетевиков и ИБшников между собой, благо и сам такой путь прошел, и есть целые команды коллег с аналогичным маршрутом.

Ну и немного об использовании противоестественного интеллекта поговорим. Какая же конференция в 2026 году без этого?
https://spb.nastachku.ru/programma

Интересный вариант заполнения тыльной стороны бейджика с конференции, чтобы его хотелось сохранить.

В самый раз для тех, кто считает, что в килограмме 1024 грамма.

Сейчас все начали сильно переживать за данные, отправляемые во внешние ИИ-модели.

Как будто забыли о том, как писали стратегии в гугл доках и отправляли их через телеграм.

Реальная осознанность, или благодарочка регулятору?

В тему позиционирования того, на каких уровнях происходит защита от DDoS, прочитал сегодня статью одного игрока на рынке, который позиционирует свою защиту на уровнях L2-L7.

Как вы понимаете, возник вопрос "а как он защищает от DDoS на L2?"

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

Какие DDoS-атаки могут быть на уровне L2:

1⃣ L2 loop, порождающий broadcast storm, когда пакеты начинают крутиться между двумя коммутаторами, так и не достигнув адресата. Если при этом они отправляются через все порты, кроме входящего - очень быстро размножаются и забивают коммутаторы. Подключенный к такой сети центр очистки от DDoS ничего не сможет сделать. Разве что не пропустить это трафик дальше. Решить проблему может только разрыв петли. В частности, во избежание таких ситуаций и придуман протокол Spanning Tree. Он выстраивает топологию сети на уровне L2 таким образом, чтобы переданный соседу пакет не мог вернуться через другой порт даже от другого свича.

2⃣ MAC flooding - когда генерируется большое количество пакетов с разными MAC-адресами для переполнения таблицы коммутации. Свич начинает отправлять пакеты во все порты, кроме того, через который пакет вошел. Центр очистки тоже не сможет ничего сделать.

Остальные атаки на уровне L2 можно назвать DDoS'ом с большой натяжкой, поэтому перечислять их не буду.

Если вдруг кто знает пример отражения DDoS центром очистки именно на уровне L2 - поделитесь. Вдруг я чего-то не понимаю.

Интересное объяснение необходимости микросегментации обнаружил: сравнили с наличием/отсутствием герметичных отсеков на подводной лодке.

Справедливости ради, подобное сравнение можно применить и к обычной сегментации сети.

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

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

Локальные LLM разного профиля

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

А научите ли вы каждую модель знаниями о своих возможностях и о соседних LLM, чтобы их можно было узнать, обратившись к любой из них?

Или на листик выписываем в этом случае статичная страничка с описанием - наше всё?

Думаю, уже многие видели Топ-25 директоров по кибербезопасности.

Мы с коллегами посчитали, и обнаружили, что, как минимум, каждый 4й CISO из Топ-25 пользуется сервисами RED Security 😎 и нам это очень нравится.

SecRED успеха CISO 😎

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

Но мы не расслабляемся: каждый 4й - это хорошо, но мы можем лучше. И будем лучше 😎

Я решил сходить на митап Облако без угроз 22 сентября (18:00-22:00) в Кибердоме.

Благо он в нерабочее время, и мне по пути домой с работы.

В программе заявлены доклады:

Как устроена защита инфраструктуры в публичном облаке сегодня

Соответствие всего всему: как и для чего мы обеспечиваем поИБшный комплаенс

И панельная дискуссия Облако без угроз

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

Возможно, с кем-нибудь из вас там и увидимся.
Если что - регистрация по ссылке.

Линия раздела создает контраст, и при чем здесь ИБ

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

Я видел не одного CISO, который заявлял, что до него в этой организации ИБ никто не занимался. А в некоторых компаниях даже наблюдал несколько CISO подряд с подобным утверждением. Собственно, это их утверждение и создаёт линию раздела с контрастным обрамлением с обеих сторон. Насколько такие утверждения соответствуют действительности - в каждом случае вопрос индивидуальный.

Глядя на подобные ситуации, я отметил для себя главное:

1⃣ Ты можешь прийти хоть после самого лучшего CISO, и всё равно что-то улучшить.

2⃣ Тот, кто будет CISO после тебя, тоже всегда может что-то улучшить.

3⃣ Даже после ухода из компании А в компанию Б и вернувшись через некоторое время в компанию А, ты можешь что-то улучшить.

То есть, контрастное обрамление линии в краткосрочной перспективе будет создаваться. Более того, контраст можно искусственно увеличить на уровне восприятия, как делали CISO из примера выше. А вот поменять цвет состояния ИБ на долгосрок - тут уже нужна последовательная работа в правильном направлении с учетом множества факторов.

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

#CISO

⚡️ Обратная сторона постквантовой криптографии в DNSSEC

Очень незаметно в ИБ-сообществе прошла новость о том, что Cloudflare реализовала возможность валидации DNS-записей по DNSSEC с использованием ML-DSA-44 (стандартизированный NIST FIPS 204 постквантовый алгоритм цифровой подписи).

DNSSEC позволяет проверить подлинность DNS-ответа по всей цепочке доверия DNS:

Root - TLD - Domain - IP

Есть мнение, что существующие алгоритмы можно будет взламывать квантовым компьютером, который вот-вот появится и разделит жизнь криптографии на "до" и "после". Поэтому Cloudflare, вроде, молодцы. Но есть нюанс...

Нас с коллегой заинтересовала не криптографическая сторона, а размер подписи в 2420 байт.

Cloudflare предлагает проверить ответ на тестовом домене, запустив определенную команду.
Пробуем:

dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec

<интересует секция с размером ответа, поэтому пропускаем остальное>

;; Query time: 56 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (TCP)
;; WHEN: Mon Sep 14 18:55:10 MSK 2026
;; MSG SIZE  rcvd: 2563

То есть, в ответ на запрос (66 байт) получаем ответ 2563 байт - почти в 43 раза больше.

Теперь видоизменим команду так, как ее будут использовать для DDoS:

dig @1.1.1.1 valid.mldsa44.dnstest.dev rrsig

<интересует секция с размером ответа, поэтому пропускаем остальное>

;; Query time: 32 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (TCP)
;; WHEN: Mon Sep 14 18:55:23 MSK 2026
;; MSG SIZE  rcvd: 22347

Видим, что ответ (22347) больше запроса (66) в 338,6 раз. Просто подарок для атакующих.

Напоминаю: суть DDoS-атаки DNS Amplification в том, чтобы забомбить жертву большими ответами DNS-серверов на запросы с подделанного адреса жертвы, переполнив канал мусорным трафиком.

Из примечательного: если запустить запрос на получение всех записей тестового домена (ANY), то ответ будет намного меньше:

dig @1.1.1.1 valid.mldsa44.dnstest.dev any

<интересует секция с размером ответа, поэтому пропускаем остальное>

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (TCP)
;; WHEN: Mon Sep 14 19:18:07 MSK 2026
;; MSG SIZE  rcvd: 60

Во избежание использования для DDoS-атак в норме DNS-сервер заставляет клиента переходить с UDP на TCP, если размер DNS-ответа превышает 512 байт при классическом DNS, либо 1232-4096 (как настроить) для EDNS.

В случае с 1.1.1.1 мы видим это в строке

;; SERVER: 1.1.1.1#53(1.1.1.1) (TCP)

Но если бы все DNS были так настроены, то и DDoS-атак DNS Amp было бы намного меньше.

Остается надеяться, что DNSSEC с постквантовым алгоритмом подписи ML-DSA-44 будет доступен только по TCP, иначе нас ждет новый виток популярности DNS Amplification и рекордные по мощности DDoS-атаки.

Ведь вряд ли мы с коллегой вдвоем умнее всего Cloudflare вместе взятого. Ведь вряд ли...

#DDoS #DNS

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

В сетевых технологиях даже есть развилка "Networking for AI" и "AI for networking".

Сетевая безопасность - не исключение. Но из всех пока прочитанных мной материалов использование AI/ML в защите от DDoS пока самым лаконичным и реалистичным выглядит именно этот слайд.

Согласны?

👍 - да
😱 - да ну, ерунда какая-то
😎 - я и есть AI/ML для DDoS

Интересное наблюдение. С развитием технологий противоестественного интеллекта скоро станет проще взломать B2C-сервис, чем отменить на него подписку.

Обиженный сетевик-диверсант

Послушал на досуге дискуссию сетевиков о потребности в системе управления сетью (Network Management System, NMS).

Один из аргументов "за" NMS был: как быстро вы определите и устраните корень зла, если обиженный сетевик выполнит конфигурацию, которая отрицательно повлияет на сервисы, и потрет логи?

Я сразу увидел две нестыковки:

1. На моем опыте обиженный сетевик может такое сделать, только уже уволившись, если ему не закрыли доступы при увольнении. И то если будет сложно доказать его причастность. Например, общая учётная запись, где годами не меняется пароль, полное отсутствие белых списков для management plane security и 2FA для удаленного доступа. Если специалист еще работает и планирует работать дальше - не будет он такой ерундой заниматься. Но это мой опыт. Не исключаю, что у коллег было обратное.

2. Похоже, сетевики не учли наличие ИБ в пищевой цепочке.
Если:
- правильно выстроить процесс управления учетными записями
- внедрить стандарты и шаблоны безопасной конфигурации сетевого оборудования
- выстроить контролируемый безопасный процесс управления сетевым оборудованием
- отправить логи необходимой глубины для обработки в SOC, описав принципы формирования инцидента и плейбуки реагирования

То потертые сетевым диверсантом логи все равно уже будут лежать на серверах ИБ, и если попадут под описание критериев инцидента SOC, то правда вскроется со скоростью, сопоставимой с регистрацией инцидента доступности. Ну, или немного медленнее, но сетевикам вся информация уже придет в тикете от SOC.

ИБ и сетевики не должны любить друг друга, но использовать ресурсы и экспертизу для общего блага компании обязаны.

Что положить первокласснику собой в школу? 🤔

1 сентября принято вспоминать школу, поэтому мы решили провести небольшой эксперимент и отправили экспертов RED Security мысленно обратно за парту и задали им всего один вопрос:

Что бы вы посоветовали себе-первокласснику?

Читаем, мотаем на ус и поздравляем всех с Днём знаний! 🎓

Вкратце, что произойдет, если аналитику SOC за KPI поставить количество обработанных инцидентов. Разломать один инцидент на 12 частей, конечно, не получится, но брать из очереди только те, которые выглядят максимально просто - вообще не проблема.