BPFDoor - скрытный Linux-бэкдор, который связывают с китайскими APT-группами и атаками на телеком-инфраструктуру.
Он подключается к raw-сокету и анализирует входящие пакеты до того, как их обработают правила iptables или nftables. Поэтому корректно настроенный firewall сам по себе не гарантирует защиту.
Бэкдор не открывает постоянный порт и большую часть времени никак себя не выдаёт. Для активации атакующий отправляет специально сформированный пакет, после чего BPFDoor может установить обратное соединение и предоставить удалённый доступ к системе.
Обычный скан портов здесь мало поможет. При проверке стоит обращать внимание на подозрительные raw-сокеты, активные BPF-фильтры, замаскированные процессы и необычные исходящие соединения.
В статье разобраны устройство BPFDoor и способы его обнаружения:
Автономный ИИ-агент взломал Hugging Face, а закрытые модели не смогли помочь расследованию
Hugging Face раскрыла инцидент, который хорошо показывает будущую асимметрию кибербезопасности.
Атака началась с вредоносного датасета, эксплуатировавшего два пути выполнения кода в системе обработки данных. Затем автономный агент получил доступ к нодам, собрал облачные и кластерные учётные данные и перемещался между внутренними кластерами.
За одни выходные система выполнила тысячи действий через краткоживущие sandbox-среды. В журналах осталось более 17 000 событий.
Самая показательная часть началась во время расследования. Команда Hugging Face попыталась анализировать реальные эксплойты, команды и C2-артефакты с помощью передовых моделей через коммерческие API, но safety-фильтры блокировали запросы.
Модели не смогли отличить работу специалиста по реагированию на инциденты от действий атакующего.
В итоге анализ перенесли на самостоятельно размещённую open-weight модель GLM 5.2. Это позволило изучать вредоносный код без блокировок и не отправлять журналы, данные атакующего и упомянутые credentials внешнему провайдеру.
Возникает опасная асимметрия:
- атакующие запускают агентов без ограничений;
- защитники могут столкнуться с блокировками именно в критический момент;
- чувствительная телеметрия не всегда должна покидать инфраструктуру компании.
У команды безопасности должна быть заранее подготовленная модель, которую можно запустить локально и использовать во время реального инцидента.
Автономные кибератаки уже перестали быть сценарием из презентаций. Теперь вопрос в том, готовы ли защитные инструменты работать с той же скоростью.
В Linux флаг O_DIRECT позволяет читать и писать файл почти напрямую, минуя page cache ядра.
Зачем это нужно базам данных?
У PostgreSQL, MySQL, RocksDB и других систем часто уже есть свой buffer pool.
Если ещё и ядро будет кэшировать те же страницы, получится двойное кэширование и лишняя трата памяти.
Но у O_DIRECT есть неприятное условие: всё должно быть выровнено по блоку.
• buffer
• file offset
• размер чтения / записи
Например, под 4 KB блоки нельзя просто так прочитать 123 байта в любой `malloc`-буфер.
Промахнулся с alignment — read() вернёт EINVAL.
Именно поэтому низкоуровневый I/O в базах выглядит таким странным: там важны не только данные, но и то, как они лежат в памяти.
Бесплатный урок: доверь прод ИИ. Испугались? Не бойтесь, мы друг
⭐Слёрм запускает БЕСПЛАТНУЮ вечернюю школу «ИИ для инженеров: польза и риски».
Это серия онлайн-занятий о том, как использовать ИИ в инженерной работе осознанно, безопасно и с понятной пользой.
🧩 Будем разбирать реальные инженерные сценарии:
— как ИИ помогает DevOps-, SRE- и infrastructure-командам
— как использовать LLM для алёртов, инцидентов, логов, тикетов и документации
— где ИИ реально экономит время, а где создаёт новые риски
— как проверять результат модели и не ловить галлюцинации в проде
— что делать с безопасностью, данными, compliance и юридическими ограничениями
— как встроить ИИ в рабочий процесс, а не просто иногда спрашивать у него команды.
🧩 В программе — шесть онлайн-занятий с практиками из ИТ:
— ИИ для разбора метрик и шумных алёртов
— автофикс проблем прода с ИИ
— ИИ-агенты в бизнес-задачах
— юридические риски использования ИИ
— LLM в SOC и борьба с alert fatigue
— инженерное мышление в эпоху LLM
Школа подойдёт DevOps-, SRE-, infrastructure-, platform- и security-инженерам, а также всем, кто уже пробовал ИИ в работе и хочет понять, как использовать его системнее и безопаснее.
⚡️ Почему RSA в OpenSSL не делает «обычное деление»
В реализации RSA внутри OpenSSL почти не используется прямое модульное деление. Вместо этого там работает Montgomery reduction - алгоритм, который ещё в 1985 году предложил Питер Монтгомери.
Идея простая: в RSA постоянно нужны операции вида «умножили большие числа и взяли остаток по модулю». Обычное деление на больших числах дорогое, поэтому его стараются избегать.
Montgomery reduction переводит вычисления в специальную форму, где параметр R выбирают как степень двойки. После этого часть дорогих делений превращается в сдвиги битов и более дешёвую арифметику.
Для пользователя это незаметная деталь. Но без таких трюков современный RSA был бы намного медленнее.
Есть хороший шанс, что HTTPS-соединение, которым вы пользуетесь прямо сейчас, где-то внутри уже опиралось на эту технику.
C2 без сервера, домена и открытых портов - теперь прямо внутри GitHub
Появился OctoC2 - GitHub-native C2 framework, где весь трафик идёт через api.github.com по HTTPS. Без VPS, кастомных доменов и listening server. Для сети это может выглядеть как обычная активность разработчика или CI/CD.
По README, OctoC2 использует несколько каналов внутри возможностей GitHub, поддерживает fallback между ними и шифрование payload’ов. Проект прямо помечен как инструмент только для authorized red-team и security research.
GitHub-трафик нельзя считать безопасным просто потому, что это GitHub.
Что стоит мониторить:
* странные паттерны запросов к GitHub API
* неожиданные GitHub tokens на машинах
* необычную активность private repos
* подозрительную CI/CD-активность
* долгоживущие процессы, которые постоян
Линус Торвальдс не поддержал запрет AI-кода в Linux.
ИИ - это инструмент. Такой же, как компилятор, статический анализатор или IDE. Неважно, писал разработчик код вручную или использовал ассистента. Важно, что получилось в итоге.
Плохой патч отклонят, даже если его написал человек.
Хороший патч могут принять, даже если помогала модель.
Но ответственность переложить на AI не получится.
Разработчик должен сам проверить сгенерированный код, убедиться в соблюдении лицензий и поставить собственный Signed-off-by. AI-агент не имеет права делать это за человека. Использование модели также рекомендуется отмечать через Assisted-by.
Правило осталось прежним: присылай качественный код и будь готов за него отвечать.