
Каждый день я ложусь спать в районе 3 ночи, а в 7 утра уже на ногах и начинаю пахать. Сон по четыре-пять часов — это теперь моя новая реальность, чтобы просто успевать внедрять ИБ в облаке. У нас последнее коммерческое облако в России, если что )
И всё из-за того, что сейчас творится в мире с информационной безопасностью. Как очень точно сказал наш SRE-инженер: на изучение Ceph нужно либо положить жизнь, либо положить хер. С CVE — та же история. Третьего не дано.
Если у вас не выстроен процесс автоматической ревизии версий и накатывания патчей, вы в этом просто утонете.
Мне ежедневно от ЦМУ ССОП падают официальные предписания — PDF-сканы с красивыми размашистыми подписями: «В целях предотвращения рисков компрометации веб-ресурса и лежащей в его основе серверной инфраструктуры, необходимо обеспечить обновление программного обеспечения до исправленной версии, а также проверить журналы веб-сервера на предмет подозрительных обращений». За пару прошлых недель прилетело по удалённому исполнению кода в GitLab, Node.js, PHP. Дыра с RCE в WordPress, кажется, вообще никогда не будет закрыта навсегда. Дальше — критические баги в прошивках Zyxel, дыра в OpenSSH, уязвимости в Cisco Secure Firewall и системе Adaptive Scanner в Cisco Secure Defense.
Пример с Бегетом
То, что случилось с Бегетом недавно, — это очень похоже на сложную APT-атаку. По масштабу поражения и сложности это очень близко к истории, когда Rutube подобнулили. При этом Бегет назвал произошедшее форс-мажором. Но является ли это форс-мажором на самом деле или это прямая зона профессиональной ответственности хостера — споры предстоят долгие.
Потери распределились крайне неравномерно. Обычный виртуальный хостинг с простенькими сайтами они из бэкапов накатили практически в моменте. А вот всё облако — признали, что потеряно наглухо. VPS-ки, Kubernetes и S3-хранилища ушли в страну вечной охоты без шансов на восстановление. В сети даже пролетал мем: «Анекдот дня — хостер без бэкапов».
Многие наивно думают: ну есть же репликация в S3! Да, репликация защищает от того, что железка с дисками физически отвалится (это стандартная архитектурная база), но она вообще никак не защищает от стирания данных. Под капотом у S3-хранилищ (например, на базе того же Ceph) есть WORM-механизмы (Write Once Read Many), позволяющие задать Object Lock — несменяемый срок хранения объектов. Но как хостер ты никогда не станешь включать такие вещи по умолчанию для клиента, который платит три копейки за объект, живущий всего пару часов. Никто не будет за свой счёт бэкапить чужую терабайтную бинарную помойку.
Дело упирается в экономику и позиционирование. У нас по кастдеву клиенты часто говорят прямо: «Мы берём Селектел для железа, Яндекс для продвинутых облачных фичей, а Бегет — когда на какую-нибудь херню закодить и быстро потестить». Это такой околодискаунтер. В его экономику нормальное резервное копирование облака просто не ложится совсем. Да, у них на сайте гордо заявлено про «безопасность на всех уровнях, круглосуточные автоматические бэкапы и сертификаты PCI DSS и ISO». Нюанс в том, что эти сертификаты принадлежат дата-центру DataLine, где Бегет физически арендует стойки, а вовсе не внутренним процессам самого хостинга.
А теперь к диким аномалиям. Буквально через час после отключения всех серверов от автономной системы (AS) Бегета пошёл просто нереальный шквал BGP-анонсов — порядка одного миллиона за час! Для понимания: их пик за предыдущие 90 дней был всего 20 тысяч анонсов. Очень хочется почитать официальный постмортем, была ли это попытка самих инженеров изолировать сеть, обнуление конфигураций маршрутизаторов, побочный эффект удаления кластеров K8s, попытка BGP-хайджекинга или заметание следов.
Первый официальный пост в телеге, где они назвали катастрофу «крупным инцидентом», появился только через два с половиной часа. Хотя в официальной хронологии на сайте указано, что вредонос запустили в 2:30, а в 2:40 обнаружили взлом. Коммуникация волшебная, особенно учитывая масштаб: на хостинге живёт около 20% Рунета, включая Честный ЗНАК, BelkaCar и РЖД Тур. Среди клиентов на сайте значатся ещё World Class, Комус, Газпромбанк, DNS и Почта России.
Примечательно, что злоумышленники не стали воровать персональные данные для сливов, не перенаправляли трафик на сторонние платёжные шлюзы и криптокошельки и даже не делали дефейс сайтов. Было чистое желание устроить показательную разрушительную акцию. Думаю, как когда-то прилетало по Яндексу.
И чего?
Ну, для начала — не стоит сбрасывать со счетов социальную инженерию. Могли банально втереться в доверие к сисадмину или стащить его ноутбук. Люди — самое уязвимое звено. Вспомните относительно недавнюю драму с XZ Utils: чувак методично нагнал ботов в репозиторий, задолбал уставшего мейнтейнера, втёрся к нему в доверие и годами пропихивал бэкдор, пока он не пролез через зависимости в кучу систем. Катастрофы удалось избежать случайно, из-за бдительности и докопчивости человека, который вообще не должен был разбираться с кодом и тестовыми данными.
Если вы вспомните старый Хабр начала нулевых или всё тот же Ксакеп — примерно треть материалов была посвящена именно тому, как правильно разводить людей. Или посмотрите сериал «Mr. Robot» — там реалии социальной инженерии показаны во всей красе. Не зря его Дэвид Кеннеди консультировал.
Второй вектор — эксплуатация уязвимостей классического веб-хостинга. У любого крупного хостера помимо облака крутится тьма-тьмущая сайтов, где пыха живёт в полный рост. Разом накатить патчи на миллион клиентских инсталляций физически невозможно. Достаточно заинжектить компонент через дыру на виртуалхостинге, а оттуда начать раскручивать атаку вглубь — на гипервизоры и управляющие серверы.
Причём межсетевые экраны тут не панацея. NGFW отсекает чуваков, которые без разбора стучат по портам, но если NGFW не настроен на глубокую инспекцию HTTP-трафика, он уязвимость в полезной нагрузке пакета не заметит. Такое могут отфильтровать только продвинутые WAF или сервисы вроде Qrator, комбинирующие anti-DDoS с WAF. Но на масштабах огромного шаред-хостинга закрыть абсолютно всё на периметре нереально.
А если пыха не на клиентских сайтах, а в админке самого хостинга?
Что делать с потоком дыр?
Вспоминая недавние CVE и свеженайденные дыры — а сколько таких закладок живёт годами до того, как о них узнает мир? Вспомните Heartbleed в OpenSSL — два года дыра висела в проде до обнаружения! А сколько её эксплуатировали втихую до появления CVE — неизвестно. Вспомните аппаратные закладки в Huawei, бэкдоры в прошивках Juniper. Или виртуозный шедевр от АНБ, когда константу специально заложили в алгоритм генератора случайных чисел на эллиптических кривых. Представляете, какая глубокая компетенция нужна, чтобы это найти?
Так вот, сегодня оказывается, что в целом-то можно не наращивать компетенцию. Правила игры меняют большие модели. Anthropic недавно рассказали, как их ИИ-агент нашёл уязвимость нулевого дня и отработал цепочку меньше чем за 48 минут, а за следующие 5 минут поднялся до рута. Естественно, готовый эксплойт они публично не показывают — для ядер актуальных LTS-версий Ubuntu (на которых крутится от 60% до 80% всего мирового веба) патчи безопасности ещё даже не докатились до репозиториев. А скептики в каментах к статье об этом до сих пор утверждают, что раз доказательства эксплуатации уязвимости на всеобщее обозрение не представили, значит, их нет.
В чём ещё отличие их эксплойта от старых — думаю, там не хардкод на C++, а что-то, что напрямую взаимодействует с их LLM прямо в процессе атаки.
И таких уязвимостей падает всё больше. Сегодня безопасники старой школы смотрят на сыплющиеся CVE-шки точно так же, как седые сеньоры недавно смотрели на тысячу пулл-реквестов от джуна, которому вчера купили подписку на Claude Opus.
Да, в эти игры можно играть вдвоём. Мы у себя в процессах ИБ тоже активно используем ИИ. Но когда на нас первый раз упал массив находок и мы натравили агента на Fable для автоматизации рескана, начался цирк. Fable просто встал в позу: «Я — Opus 4.8, это кибербезопасность, я не буду это делать. 403 Forbidden». Безопасник, твою мать! Ему дают легальную кодовую базу, список уязвимостей, тестовый контур и просят: «Вот уязвимость, исправь код». А он включает паранойю. Приходилось «уговаривать» его через сложные цепочки промптов. И даже соглашаясь, он начинал душнить: «Я не буду писать описание уязвимости в отчёте, напишу только её номер». Доходило до смешного: я писал регламентные документы по управлению процессами SOC, а модель просто отказывалась генерировать текст из-за словосочетания «Red Team».
У Anthropic для этого есть закрытая программа Cyber Verification Program, где снимаются гарды:
— Первый уровень — подтверждаете базовую identity, после чего разблокируют работу с безопасностью и снимают почти все гардрейлы. Если без верификации рубится почти каждый запрос, то на первом уровне из 50 кибербезовских промптов спокойно проходят 46. Нужен только ID от разрешённой страны, то есть карточки цифровых кочевников Таджикистана или Кыргызстана подходят.
— Второй уровень — требует подтверждения компетенций через профессиональные сертификаты. Там для Red Team вообще снимаются любые блокировки. Но там надо быть сертифицированным сотрудником ИБ, то есть проверят ещё и компанию.
— Третий уровень — закрытый доступ для специалистов по защите критической информационной инфраструктуры. Там мало иметь кыргызскую прописку, надо иметь как минимум делловский или оракловский паспорт.
Если ID предъявить звёздно-полосатый, то открывается доступ к Mythos, но всё, что по фичам Red Team и выше, — только на корпоративных аккаунтах. Подписки за 200 баксов не катят.
Внутри своей платформы мы синхронизировали работу Red Team и Blue Team одним внутренним инструментом. Красные непрерывно сканят инфраструктуру, всё падает в пайплайн, синие закрывают дыры, и следом автоматически накатывается рескан с фиксацией шагов воспроизведения.
И да, ещё раз хочу сказать большое спасибо всем тем, кто какую только дичь не творил, пока облако было в бете. Некоторые ваши письма в духе «Это же у вас ханипот, уж очень очевидно, да, да?» я до сих пор вспоминаю. Потому что иногда это был не ханипот. Нам это очень помогло тогда. Многое, что мы считали невозможным, оказывалось только условно невозможным.
Из свежего — при очередном аудите наткнулись на потенциальный кросс-тенантный доступ. Архитектурно мы считали его невозможным: для эксплуатации атакующему нужно было одновременно поймать коллизию двух UUID — знать точный ID проекта и ID ресурса (по факту трёх, но дефолтный ID проекта у нас сейчас равен User ID, поэтому мы считали вероятность коллизии двух пар идентификаторов как математически достаточную для изоляции). Но когда мы смоделировали сценарий с методами социальной инженерии, стало понятно: вытащить эти идентификаторы у пользователя вполне реально. Мы тут же повысили уровень угрозы с Medium до Critical и быстро пропатчили логику. Бага появилась ещё при планировании архитектуры под многопользовательский режим, но с его включением появился и полнофункциональный IAM, и такой сценарий отпал сам собой.
Другой пример: подняли временную внутреннюю dev-площадку на внешних доменах, чтобы протестировать предфинал. Ради скорости оставили пару открытых хвостов. Потом сами себя агрессивно пропентестили, схватились за голову и — ну его нафиг — снесли контур целиком, не дожидаясь инцидентов.
Ещё мы пару дней в месяц колбасим гиперреалистичные ханипоты. Почему гиперреалистичные — потому что в силу знаний команды умеем посмотреть на них и с другой стороны. По ним мы сразу видим разведку и берём атакующего на карандаш. Телеметрия сразу летит в SIEM, а шаг два — в IRP, ибо массовые сканы дальше чтения баннеров обычно не ходят.
А вот в энтерпрайзе и госсекторе до сих пор царит кромешный ад, по моей оценке. Вот свежайшая история из одного банка — мы же тут погрузились в банковскую сферу — объект КИИ (без присвоенной категории значимости). В 2024 году руководство по требованиям для прохождения аудитов покупает дорогущую сертифицированную систему от ФСТЭК. Безопасник бодро рапортует, что всё работает идеально. Сисадмин при этом воет и ночует дома за консолью, рассказывая руководству, как он сутками отбивает атаки вот этими самыми руками. Когда запахло жареным, безопасник резко ушёл в отпуск. Назначили внутренний аудит, открыли SIEM-систему… Чувак с первого дня внедрения просто добавлял правила подавления алертов, чтобы они не мозолили глаза руководству! В системе висело примерно 800 неразобранных критических инцидентов. Из отпуска он уже не вышел.
А слабо ещё делать это на лету?
В облаке обновлять ИБ на лету — это невероятно сложная инженерная задача. У нас на обслуживании есть крупный клиент с годовой выручкой под 8 миллиардов рублей. Это около 23–24 миллионов рублей в сутки, почти миллион рублей за каждый час простоя.
Накатывать обновления безопасности на живую инфру при таком трафике без прерывания сервиса возможно только тогда, когда автоматизация инфраструктуры построена по Operator Capability Level не ниже второго уровня (с поддержкой роллинг-апдейтов), а в идеале — третьего уровня (с полным автоматическим управлением жизненным циклом приложений). А подавляющее большинство хостингов, которые называют себя облаками, застряли на первом уровне — умеют тупо создать виртуалку, удалить её или переименовать.
Мы, к счастью, умеем так апдейтить. Но это тоже не самая простая история.
И главный вывод, который подсказывают последние инциденты: всем пора взрослеть и строить мультиклауд. Репликация внутри одной серверной стойки или между соседними ЦОДами в Москве не защитит вас от стирания данных или масштабного физического настоящего форс-мажора. На рынке уже есть те, кто проектирует Disaster Recovery с учётом сценария возможного ядерного удара по Москве — ну, иначе я не могу объяснить, как у российских «остатков» одной западной компании появилось требование к тому, что данные обязаны в реальном времени реплицироваться на резервную площадку минимум за 500 километров от столицы, и сценарии, что любое количество узлов в столице может выпасть из сети. В прошлом году люди крутили пальцем у виска в комментариях к нашей статье про ЦОДы, когда мы это упоминали, но сегодня крупный бизнес закладывает такие риски в базовые SLA. Правда, наверное, называет по-другому.
В общем-то, хер мы на ИБ не положили, теперь придётся положить всё свободное время. Не знаю, чем эта история закончится, но, думаю, быстро и легко это точно не случится. Поэтому добро пожаловать в ИБ-покалипсис, который мы так давно ждали!
Dima_Levch
История с 800 подавленными алертами пожалуй страшнее всех этих CVE. Можно купить дорогую SIEM, пройти аудиты, а потом один человек просто отключит половину уведомлений чтобы руководство не беспокоить. И как такое вообще контролировать?
Dhwtj
Разделением полномочий. Очевидно же
km1337 Автор
Люди — это всегда самое уязвимое звено. Ничего с этим не сделаешь, никакие миллиарды этапов собеса и тест на полиграфе не докажут, что у сотрудника не перемкнёт что-нибудь в голове в самый неподходящий момент. Тут только смириться и периодически проводить аудиты. Ну и по возможности не завязывать на одного сотрудника критические задачи.
Aleksandr_Lar
Исключительно репрессивными механизмами, доходящими до правового террора, чем сейчас понемногу все государства и начинают заниматься. Подход не новый, аналогичный уровень угнетения существует в сфере какой-нибудь пожарной сигнализации или промышленной безопасности: проверяется не "успешность предотвращения инцидента", а именно корректность и соответствие нормативам всех принятых мер. Если здание ни разу не горело (критерий "не горело" прежде всего означает: "ГосПожНадзор считает, что не горело," - ЕВПОЧЯ), это не значит, что там всё правильно, поэтому противопожарные меры периодически проверяются достаточно лютыми экспертами.
Аналогично с ИБ - у нас в России ибэшник уже может заехать в тюрьму за нарушения, что само по себе несколько утяжеляет дефицит кадров.
Abstraction
Это работает для не-адверсариальных угроз (пожар нормативы не читает и начаться так чтобы нормативные меры его не остановили специально не планирует).
Для ИБ известных инструкций, следование которым бы обеспечивало безопасность информации, с которой надо работать много кому и много как, банально не существует (напоминаю что один из критериев безопасности - доступность, если вы не даёте манипулировать с данными легитимным клиентам, то вы её провалили).
Aleksandr_Lar
Тут я с вами немного не согласен, инструкции существуют, хотя и носят часто обобщённый характер в силу нежелания регулятора сильно ограничивать работу строгими сценариями.
Большинство компаний не имеют внутренней мотивации вкладываться в ИБ пока их не хлопнули, поэтому эффект может быть достигнут только навязыванием инструкций. В предложенном примере как раз наблюдается такая просадка мотивации, которая купируется "репрессивным механизмом с аудитом".