готовность к эпохе ИИ
13 статей с этим тегом
Ядро Linux CVE-2026-98432: use-after-free в TCP, вызываемый по сети (CVSS 9.8). Установите исправленное ядро, перезагрузитесь и проверьте MPTCP
CVE-2026-98432 — use-after-free в коде IPv4 TCP ядра Linux, опубликованный 15 октября 2026 года. CNA проекта ядра оценивает его в CVSS v3.1 9.8 (сеть, без привилегий, без действий пользователя). Исследователи одной ИИ-компании, как сообщается, в лабораторных условиях и по собственному отчёту продемонстрировали удалённое выполнение кода с правами root на сервере со слушающим сокетом Multipath TCP (MPTCP). BleepingComputer пишет, что удалённое выполнение кода на обычных TCP-серверах публично не показано, а эксплуатация в реальных атаках не подтверждена; этот сайт 1 ноября не нашёл CVE в каталоге KEV от CISA. Исправления из основной ветки есть в 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 и 7.2.10 и более поздних. На 1 ноября у Debian есть исправленные ядра, у SUSE — часть, а Ubuntu и Red Hat указывают исправления как находящиеся в работе. Одного отключения MPTCP недостаточно. Вывод этого сайта: обновляйте доступные из интернета серверы Linux по мере выхода исправлений, перезагружайтесь и пользуйтесь временной мерой поставщика только до тех пор.
Безопасность для эпохи ИИ: что закрыть прямо сейчас (приоритетный чек-лист)
ИИ в основном усиливает атаки на СУЩЕСТВУЮЩИЕ слабые места (незакрытые CVE, повторно используемые пароли, открытые секреты), а не изобретает новые — найденные автоматически, быстро, в масштабе. Поэтому лучшая подготовка — закрыть основы в правильном порядке: закрытие CVE + мониторинг зависимостей, отказ от повторного использования паролей + MFA, удаление открытых секретов, минимум привилегий, сокращение публичной поверхности, логи/IOC, резервные копии.
Меры безопасности в эпоху ИИ: что работает, а что нет, и почему малые сайты тоже становятся целями
Четыре заблуждения эпохи ИИ: (1) слишком мал, чтобы стать целью → автоматизированным атакам не нужен человек, выбирающий цель; (2) нужен особый новый механизм → основы по-прежнему работают лучше всего; (3) продукт делает вас безопасными → проектирование профилактики раньше обнаружения; (4) код от ИИ быстрый, значит безопасный → он может выйти с уязвимостями, поэтому проверяйте перед публикацией. Работают скучные основы в правильном порядке.
Подделка писем от вашего домена: как отличить её от взлома и как SPF, DKIM и DMARC её останавливают
Подозрительное письмо, которое будто пришло с вашего домена, обычно не взлом, а поддельный From, потому что SMTP позволяет кому угодно вписать строку From. Чтение заголовков (Authentication-Results, Received, Reply-To) отличает взлом от подделки. Главная причина, почему оно доходит до входящих, — отсутствие политики DMARC. Исправьте это через SPF → DKIM → DMARC (p=none → reject).
Основы резервного копирования: правило 3-2-1 и план восстановления, переживающий программу-вымогатель
«У меня есть резервная копия» недостаточно — пользу приносит только та копия, восстановление из которой вы проверили. Основа: правило 3-2-1 (три копии, два типа носителей, одна вне площадки). Против программы-вымогателя также нужна хотя бы одна «офлайновая или неизменяемая» копия — постоянно подключённая копия шифруется вместе с оригиналом. Облачная синхронизация — не резервная копия (она тиражирует и удаления, и шифрование). Версионирование и периодический тест восстановления завершают практику.
Как правильно выбирать MFA: что значит «устойчивый к фишингу» и почему SMS слаб
MFA сочетает разные категории факторов. Вводимые вручную коды можно выманить фишингом; SMS также зависит от контроля номера. Для важных аккаунтов выбирайте устойчивые к фишингу методы, например passkey или ключи FIDO2, и проверяйте условия проверки пользователя и восстановления.
Как по-настоящему закрывать CVE в зависимостях: сканировать, исправлять, изолировать и продолжать следить
Работа с уязвимостями не закончена, когда вы «исправили». Готово = 1) скан, 2) фикс, 3) изоляция/передача, 4) мониторинг. Пока не налажен мониторинг (ежедневное обнаружение изменений), это незавершённо — зависимости снова станут уязвимыми завтра. Идеальное исправление, которое перезаписывает следующий деплой, стоит ноль. Малые команды остаются в безопасности за счёт двух дисциплин: автоматического обнаружения изменений и «локально→push→деплой».
Установка и использование osv-scanner: автоматический поиск CVE в ваших зависимостях
osv-scanner сканирует lock-файлы и контейнеры, выявляя CVE в ваших зависимостях, бесплатно. Здесь разобраны установка, запуск и интеграция в CI, плюс когда применять его vs npm/pnpm audit vs Dependabot. Взгляд этого сайта: какой инструмент подходит, зависит от вашей конфигурации. Используйте osv-scanner для проектов с несколькими экосистемами или без GitHub, и встроенный pnpm audit для одного npm-дерева.
Безопасны ли менеджеры паролей? Как они работают, облако vs локально и как выбрать
Менеджер паролей помогает использовать отдельный надёжный пароль для каждого сервиса. Шифрование с нулевым разглашением призвано защищать содержимое даже при утечке зашифрованных данных у провайдера, но безопасность также зависит от силы мастер-пароля, настроек шифрования и защиты устройства. Используйте MFA против несанкционированного входа, а облачный или локальный вариант выбирайте по применению.
Оставили файл с секретом в публичной директории? Проверьте свой webroot
Всё, что в вашем webroot, любой может скачать по URL. Забытый JSON с токеном/учётными данными, .env или резервная копия означают мгновенную утечку — и если он пришёл из общего шаблона, тот же файл лежит на каждом сайте. Исправление: кладите в публичную директорию только то, чем можно публично делиться, держите секреты вне webroot с правами 600, а найдя один — проверьте каждый сайт и хост.
Базовая безопасность для инди-разработчиков и малых операторов: стандартные меры в порядке приоритета
База — это не «всё одинаково важно». Порядок приоритета этого сайта: 1) админ-аккаунты, домен и почта (MFA), 2) секреты и код, 3) само приложение, 4) патчи, обнаружение, восстановление. При конечном времени заполняйте сверху вниз. Большинство серьёзных взломов происходит не из-за новых атак, а из-за пробела в этих базовых мерах.
Наименьшие привилегии SSH-ключа: не храните root-ключи продакшена в эфемерных средах, которые можно скомпрометировать
Регистрация root-ключа в продакшене из эфемерной, компрометируемой среды (под GPU, раннер CI, одноразовая ВМ) означает, что в тот миг, когда среда скомпрометирована, атакующий получает root в продакшене. Исправление: никаких root-ключей в эфемерных средах; убирать ключи, когда не используются; если снова нужно — пользователь не root плюс ключ с ограничением команды, ограничивающий ключ одной операцией. Относитесь к переиспользуемому ключу как к самому критичному активу и никогда не стройте конфигурацию, где один утёкший ключ открывает все серверы.
Из кода, написанного ИИ, утёк API-ключ, и им воспользовались для мошеннических списаний: причиной была незакрытая уязвимость CVSS 10.0
Скачок счёта был симптомом. Причиной была незакрытая опубликованная RCE с CVSS 10.0. Обезличенный случай, сведённый к урокам по защите.