Есть такая русская поговорка: ничто не обходится так дешево и не ценится так дорого, как вежливость.

OpenAI и здесь вершит революцию, показывая, что вежливость - не такой и дешевый аспект противоестественного интеллекта. Или они так бюджеты осваивают?

Поздравляю всех подписчиков с Пасхой. Христос Воскресе!

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

Я, хоть и не вендор NGFW, и не заказчик в чистом виде, но имею довольно большой опыт работы с разными (NG)FW, а особенно с их обвязкой в корпоративной среде. Поэтому, чтобы исключить обсуждение базовых потребностей, решил их перечислить в презентации, на фоне которой шел разговор. Оказалось, не зря: посетители фотографировали слайды, и даже просили организаторов прислать ее.

Поделюсь содержимым. Вдруг кому пригодится.

1. Что именно нужно заказчикам от NGFW?

- кластеризация active-passive с синхронизацией состояния сессий
- рефлексивные ACL
- базовая инспекция протоколов/приложений, чтобы правило для условного FTP помещалось в одну строку
- умение работать на высоких скоростях стабильно, без задержек и с большим количеством строк ACL
- удобный интерфейс управления
- migration tool, чтобы конфиг заморского девайса конвертировать в отечественный
- сертификация

2. На что вендор делает акцент в своем NGFW?

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

3. Обвязка.

NGFW в чистом виде хорош в небольшой стабильной инфраструктуре, в более динамичной среде нужна обвязка, чтобы в итоге не получился permit any any:
- migration tool
- отображение актуальной карты сети
- централизованное управление конфигурациями
- централизованное управление изменениями
- стандарты безопасной конфигурации сети
- интеграция с SOC/AntiDDoS/VM

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

Переиграла и уничтожила. Возможно, у женщины на работе ИБшники запрещали пользоваться мессенджером для ПДн, вот она и запомнила.

А вы говорите, мало пользы от ИБшных запретов.

Если вы задумывались, как в реальной жизни мог бы выглядеть DDoS с использованием spoofing и reflection - вот и пример подъехал, спасибо коллеге за наводку.
#DDoS

Кому цветную шпаргалку по текстовому редактору, сравнимому с операционной системой?

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

Получается, 15% подписчиков читают нелюбимый канал, либо выбрали этот пункт за отсутствием пункта "терпимо, не отписался ведь, а что другие выбрали?"

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

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

Нашел интересный one-pager по Linux. Делюсь.

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

Все уже слышали о DDoS-атаке на Lovit, наиболее бурный период обсуждения уже позади, но все еще актуален вопрос: что делать небольшим Интернет-провайдерам, чтобы минимизировать ущерб от DDoS?

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

Для готовности отражения DDoS-атак:
1. Проектировать сеть таким образом, чтобы обеспечить техническую возможность защиты от DDoS любого подключенного клиента.
2. Реализовать возможность фильтрации атак на границе сети с помощью правил BGP flowspec либо централизованно управляемых списков доступа.
3. Выполнить инвентаризацию и функциональное профилирование сегментов сети для применения соответствующих правил защиты от разных векторов атак.
4. Внедрить центры анализа и очистки трафика от DDoS и выполнить соответствующие настройки.
5. Организовать взаимодействие по отражению DDoS-атак с аплинками и РКН.
6. Обеспечить кадровый состав соответствующей службы.
7. Выстроить процессы отражения DDoS 24x7.

Для обеспечения возможности быстрого восстановления после отражения либо окончания DDoS, как правило, особых мер не нужно. DDoS-атака имеет быстрый ощутимый эффект, но по ее окончании либо отражении он прекращается.
Осложнения могут возникнуть в случае подверженности активного сетевого оборудования уязвимостям с эффектом DoS condition, поэтому стоит обновить версии ПО либо применить конфигурационные меры минимизации риска эксплуатации уязвимостей.

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

Поэтому стоит озаботиться:
1. Безопасной конфигурацией сегмента управления сетью и управляющих интерфейсов оборудования. Для этого не нужно много денег.
2. Резервным копированием конфигураций и образов ПО.
3. Надежным хранением резервных копий изолированно от продуктивной инфраструктуры.
4. Управлением уязвимостями сетевого оборудования и прикладных сервисов.
5. Мониторингом событий информационной безопасности и реагированием на них 24х7.

Всем удачи. Чем больше выполнено рекомендаций, тем вероятнее удача.

#DDoS

Если вдруг маленький провайдер с криво настроенными роутерами доступа поймал DNS Amplification DDoS именно такого характера, как я описывал здесь, то правило iptables, которым я лет 12 назад подлечил провайдерский DNS (и, в итоге, весь сервис для абонентов), выглядело так:

iptables -N DNS_ANY
iptables -v -A DNS_ANY -m recent --name dns_any --update --seconds 10 --hitcount 3 -j DROP
iptables -v -A DNS_ANY -m recent --name dns_any --set -j ACCEPT
iptables -v -A INPUT -p udp --dport 53 -m string --from 40 --to 123 --algo bm --hex-string '|0000FF00|' -j DNS_ANY

Оно лимитировало поток запросов типа ANY.
Если заменить 0000FF00 на другие значения, можно лимитировать еще и такие запросы, которые, кроме легитимного использования, часто берут для amplification:
00002E00 - RRSIG
00003000 - DNSKEY
00001000 - TXT

#DDoS #DNS #Amplification

Теперь в виде статьи на хабре: https://habr.com/ru/companies/ru_mts/articles/893608/

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

Время идёт, нигерийские невесты меняются.

#fun #мошенники

Прочитал на досуге, что 18 марта 2004 года обнаружили уязвимость в средствах защиты ISS (тогда еще не IBM). И известно это стало, потому что появился зловред Witty, ориентированный на средства защиты ISS. Он катком прошелся по СЗИ, которые жизнь к этому не готовила, запуская вредоносный код "потому что могу".

Что интересно, уязвимость RCE была в модуле PAM (protocol analysis module, а не то, что вы подумали), и, в частности, обработка трафика ICQ вызвала такую болячку. Кто застал это время - помнит, что трафик ICQ ходил открытым текстом, и системы IDS (сейчас их называют NAD/NTA) можно было настроить как сетевой DLP на определенные паттерны. Настройка подобных правил в ISS была очень нетривиальной, в отличие от того же Cisco IDS. От себя скажу, что в процессе настройки паттернов пришлось перечитать некоторую часть личной переписки, что оставило неприятный осадок. DLP тогда еще не был популярен, как отдельный класс решений, мы выживали, как могли.

Но относительно ISS мне запомнилось 2 факта, намекающих, что не особо их жизнь научила.
1. Годах в 2008-2009 довольно популярным был программный сенсор ISS, который устанавливался на Windows XP. Он нормально работал только с Service pack 1, несмотря на то, что SP2 был выпущен в 2004, а SP3 - в 2008. Нам приходилось защищать управляющий интерфейс сервера с XP с помощью port ACL на свиче.
2. Как-то я разбирался с выпадением в синий экран сенсора. Целый день просидел в ЦОД, но потом оказалось, что DoS condition вызывался настройкой bandwidth 10000 на dst SPAN port свича. Сетевики забыли снести предыдущие настройки, выделив SPAN-порт, подтвердив, что разгильдяйство им не чуждо. Но и реакция ISS-сенсора слишком уж неправильная на такие настройки, на мой взгляд.

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

Что и вам советую.

Теперь давайте посмотрим, как можно использовать middlebox'ы для DDoS-атак типа amplification.

Middlebox работает так:
- видит пакеты от клиента к серверу: SYN, ACK, затем PSH/ACK (передаются данные), RST/ACK (запрос на завершение сессии)
- состояние TCP-сессии не отслеживается
- в случае блокировки отдает либо контент страницы с информацией о запрете, либо URL, на котором живет такая страница

Теперь представим:
1. Злоумышленник подменяет SRC IP жертвы и отправляет TCP PSH/ACK с запросом заведомо запрещенного URL через middlebox.
2. Жертве прилетает нежданный пакет с контентом страницы либо URL, на порт, который не открывался для отправки запроса.
3а. Если этот пакет просто игнорируется - дальнейшего усиления нет. Eof.
3b. Если жертва отправляет RST в сторону middlebox'а - эпопея продолжается.
4a. Если middlebox игнорирует RST - бардак затихает.
4b. Если middlebox отвечает клиенту - пинг-понг может продолжаться практически бесконечно.

В итоге имеем, что атака типа amplification, которую не ждали от TCP, становится реальностью, и коэффициент усиления может достигать бесконечности.

Но нужно понимать, что корень зла - не сам по себе middlebox, а либо его неправильная сетевая имплементация, либо реализация софта / баг / конфигурация.

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

Отвечаю на заданный ранее вопрос.

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

Каждый сетевой интерфейс имеет, как минимум, 1 принимающий (Receiver, или Rx) и 1 передающий (Transmitter, или Tx) порты. В медной витой паре их больше, а в оптических интерфейсах, как правило по одному Rx и Tx.

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

Ответ: в таком режиме устанавливаются DPI-устройства операторской сети, выполняющие разнообразные функции, в том числе и блокировку доступа к запрещенным ресурсам.

Кстати, для однозначной интерпретации государевой блокировки даже есть отдельный HTTP-код ответа:
451 Unavailable For Legal Reasons
описан в RFC7725.

Чем нам грозит возможное возвращение иностранных игроков на российский рынок кибербеза и не только?

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

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

Спасибо нашей PR-службе, умеют в лаконичные формулировки.

Попробую более развёрнуто описать, что я имел в виду:
1. Возвращение заказчиков к использованию иностранного оборудования и ПО в связи с отсутствием необходимого функционала у отечественных аналогов. При определённых ограничениях:
- только там, где это разрешается, явно не запрещено либо не предписано ультимативно использование отечественного
- иностранным производителям придется отказаться от лицензирования продуктов через обращение к своему облаку: российский заказчик уже понимает, чем это чревато, а государство может дополнительно обязать возвращенцев к локальному лицензированию
- возможен демпинг в первые годы со стороны зарубежных игроков: им запас прочности позволит играть локально в минус для выбивания менее богатых российских игроков из заказчиков
- государство прямо или косвенно будет поддерживать отечественного производителя: субсидии, нормативные акты, заградительные налоги/пошлины для возвращающихся иностранных компаний и т.п.
2. Хантинг специалистов.
- некоторый отток специалистов из отечественных компаний будет, но уходить будут гораздо более осторожно
- возможен даже частичный возврат с карьерным ростом уехавших ранее российских специалистов
- возможен точечный отток за границу отечественных специалистов, благодаря открывающимся через глобальных игроков рынка возможностям
- спрос может спровоцировать гонку зарплат, но не так сильно, как может показаться на первый взгляд
3. Точно сработают еще какие-то факторы, которые я не учел в этом сообщении, но не знаю, какие.

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

А вы что думаете на этот счёт?

Ох уж эти пентестеры в попытках вызвать у банков недопустимое событие по неуплате кредита...

А вот вам и пример ситуации с заказчиком.

Лучший коммент коллеги:
- Заплатил и забыл?
- Нет, заплатил, вернулся и доплатил!

🗣 Андрей Дугин, RED Security: Сервисная модель далеко не всегда работает по системе «заплатил и забыл»

Андрей Дугин, руководитель центра сервисов кибербезопасности RED Security и автор блога «Кибербез Андрея Дугина», рассказал порталу Cyber Media о мифах вокруг MSSP-провайдеров в ИБ, преимуществах и недостатках облачных решений, а также поделился «вредными советами», как подключить сервисы кибербезопасности и получить нулевой результат.

Недавно увидел среди тезисов выступления в программе одной конференции:

Почему сетевой харденинг эффективней чем хостовый

Гениально: сама по себе постановка вопроса холиварная как на тему "что лучше?", так и на тему "а почему их вообще противопоставляют?". Успех у аудитории обеспечен.

Ведь если реализовать Zero Trust Network Access без харденинга подключаемого в сеть оборудования - можно оставить без доступа в сеть не только злоумышленников, но и бухгалтера, который не сможет начислить зарплату повелителю ZTNA.

Кто внедрял 802.1x, тот в этом цирке не смеется.

А вы за какой холивар?

Харденинг - это как ЗОЖ цифрового мира:

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

Ничего не забыл?

Читали уже, наверное, какую полезную функцию реализовали в Госуслугах - запрет на получение кредита.

И, что интересно, в этой игре есть уровни: можно полный запрет, можно частичный.

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

Теперь интересно, как дальше пойдут белые и черные процессы, которые вертятся вокруг кредитов:
1. Получат ли доступ к этой информации банки, чтобы попусту не предлагать кредит? Вряд ли. Потому что если и получат, то перестроят разговор в ту сторону, чтобы склонить сомневающегося клиента отменить запрет, или сделать его частичным. Ничего личного, только бизнес.
2. Как видоизменятся скрипты мошенников? Будут сообщать, что произошла отмена запрета как контраргумент, или появится новая тема звонка/фишинга "вам отменили возможность поставить запрет на кредит, переведите деньги на безопасный счет"...

Будем посмотреть, но расслабляться не стоит.

В поисках вариантов визуализации кибербезопасности иногда наталкиваюсь на интересные картинки.

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

Берите на вооружение, свою аудиторию такой стиль найдет обязательно. Кому из ваших коллег такое зайдёт - вам самим виднее.

Забавное, но верное наблюдение одной из причин, почему сетевики не особо идут в network automation. Тру сетевик рождается и живёт в CLI, надменно глядя на тех, кто работает через GUI и не доверяя роботам, кроме rancid.

Когда алгоритмы обработки трафика не успевают обработать пакет на wire speed.

Смех смехом, а именно поэтому лучше исключить человеческий фактор при контролях ИБ на потоке.

Ставь на сканы паспорта watermark 'DROP DATABASE' - злоумышленники тоже люди, и их ресурсы тоже уязвимы.

Вышла моя статья по защите онлайн-сервисов. Не нарушая традиции отечественных производителей, устройство с управляемыми рефлексивными ACL я называю не иначе, как NGFW.

Еще один интересный one-pager, но уже по эволюции кибератак.
Был бы протокол, а атака найдётся.

Интересный one-pager для тех, кто задумывался о том, что же цифровизуется в бетоне. А оказывается, у современной строительной компании в этом плане есть и потребность, и решение.

ЗЫ. Слайд из открытых источников, материалы конференций, так что никакого инсайда.

Интересный слайд нашел в одной из презентаций.

А у вас в компании как?

👍 - точно так же
😁 - бывает
🧄 - ни разу такого не было