Руководства по безопасности
4 частые ошибки в безопасности: настройки по умолчанию, забытые сервисы, отсутствие мониторинга и излишнее доверие к проверке ввода
В реальных инцидентах экзотические атаки встречаются редко. Если разложить причины по стоящим за ними допущениям, получится четыре убеждения. Каждое когда-то было верным, поэтому их никто не перепроверяет.
Если выстроить в ряд реальные инциденты, экзотические техники атак почти не встретятся. Встретится небольшой набор повторяющихся схем, и их проще увидеть, если сортировать не по технологиям, а по допущениям, которые за ними стоят.
① Допущение, что настройки по умолчанию безопасны (ничего не настроили)
Значения по умолчанию, выбранные для удобства разработки
подробные ошибки · доступные админ-панели · широкие права
↓ выпущено без изменений
Внутренние детали видны любому
структура, пути, версии и внутренние значения становятся читаемыми
- Отладочный вывод включён в продакшене
- Показывают ли страницы ошибок переменные окружения, пути к файлам или трассировки стека? Откройте несуществующий URL и посмотрите своими глазами, что вернётся. Особенности фреймворков — в руководствах по фреймворкам
- Доступные административные интерфейсы
- Инструменты управления базами данных и админ-консоли, доступные из интернета. Не полагайтесь только на аутентификацию: добавьте ограничение по IP или блокировку на уровне сети
- Заголовки не заданы или скопированы из устаревшего списка
- См. какие заголовки ещё важны, а какие нет. Устаревший заголовок может навредить, если его добавить
- Слабое хранение паролей
- Хранение паролей, как описано в статье о хешировании и соли. «Зашифровано» — это не описание схемы хранения
- Обновления прекратились
- Язык, фреймворк или CMS используются после окончания поддержки. См. автоматический мониторинг зависимостей и что на самом деле означает окончание поддержки
② Допущение, что неиспользуемое безвредно (ничего не закрыли)
Большая часть поверхности атаки создаётся тем, чем вы перестали пользоваться, а не тем, что вы построили. Как только что-то перестают использовать, оно незаметно выпадает из мониторинга и проверок.
- Секреты в публичной папке
.env, резервные копии, дампы, файлы конфигурации. что нельзя держать в публичной папке / размещение на виртуальном хостинге- Хранилище всё ещё публично
- Включение блокировки не удаляет существующую публичную политику. публичные бакеты
- Висячие записи DNS
- Если удалить ресурс, но не запись DNS, кто угодно может занять имя и захватить поддомен. захват поддомена
- Открытые пути регистрации и администрирования
- Не включена ли до сих пор открытая регистрация? Проверяйте по HTTP, а не читая конфигурацию (аутентификация и авторизация). Не оставляйте угадываемый URL единственным, что «прячет» страницу
- Аккаунты, которые вы считали закрытыми
- Отказ от услуги и удаление аккаунта — разные вещи, и данные хранятся, пока вы их не удалите. если взломали вашего хостинг-провайдера
- Старые ключи, токены и права
- Аккаунты ушедших коллег, токены без срока действия, слишком широкие области доступа. SSH-ключи и минимум привилегий / менеджеры паролей
Не ограничивайте инвентаризацию тем, что работает
Если проверять только «то, что сейчас используется», эту схему не найти вообще. Включите в проверку всё, что вы когда-либо создавали: поддомены, аккаунты, ключи, бакеты, тестовые среды, подписки на сторонние сервисы. То, чем вы перестали пользоваться, остаётся ресурсом, пока его не удалят. Как составить список: чек-лист инвентаризации ресурсов.
③ Допущение, что вы бы заметили (нет мониторинга)
Ущерб определяется не столько самим взломом, сколько тем, как долго он продолжается, прежде чем его заметят. А в большинстве сред механизма, чтобы заметить, нет.
Обычное состояние
・Журналы доступа есть, но их никто не читает
・Нет журнала попыток аутентификации (поэтому потом нельзя восстановить, что было просмотрено)
・Ограничения частоты настроены, но никто не видит, когда они срабатывают
・Публичность складывается из нескольких слоёв, и ни один из них по отдельности не даёт ответа
В итоге о том, произошло ли что-то, можно сказать только «мы не знаем».
Минимум, который стоит иметь
・Уведомление о регистрации нового пользователя (одного сигнала достаточно, чтобы заметить странное)
・Запись успешных и неудачных входов со сроком хранения
・Автоматический мониторинг уязвимостей зависимостей (люди за этим не уследят → osv-scanner)
・Запись срабатываний лимитов и оповещение о всплеске (ограничение частоты запросов и защита от злоупотреблений)
Всё сразу не нужно. Один работающий способ замечать проблемы — вот что не даёт инциденту затянуться.
Без журналов честный ответ — «мы не знаем», а не «ничего не произошло»
Самый опасный шаг при реагировании на инцидент — считать отсутствие записей доказательством того, что ничего не случилось. Без записей обоснованно можно сказать только «мы не знаем». В этом случае исходите из того, что взлом был, и замените всё, что могло быть раскрыто. Минимум для организаций — в статье базовый уровень безопасности для организаций.
④ Допущение, что проверенный ввод безопасен
Настоящий вопрос о вводе — не «правильно ли это значение», а «сколько я позволил этому вводу решать». Чем больше решений вы передаёте, тем хуже проверка за ними успевает.
- Только значение
- Обычный ввод. Проверки длины, формата и диапазона работают — безопасная сторона
- Ещё и структура
- Схемы, которые принимают целый вложенный объект и сливают его. загрязнение прототипа
- Ещё и тип
- Форматы, восстанавливающие объекты. Атака срабатывает раньше, чем ваши проверки значений. небезопасная десериализация
- Куда попадёт
- Загружаемые файлы, которые оказываются там, где их можно выполнить. уязвимости загрузки файлов
- Кто отправил запрос
- Доверие заголовку запроса при определении личности клиента. подмена X-Forwarded-For и доверенные прокси
Если посчитать переданные решения, станут видны опасные места. Причина обычно одна: пытаются решить проверкой то, что нужно решать структурой. Изменить принимаемый формат надёжнее, чем добавить ещё одну проверку.
Делаем по порядку
Посмотрите, как продакшен выглядит на самом деле (①)
Несуществующий URL, запрос с ошибкой, административные пути — запросите их по HTTP и посмотрите, что вернётся. Смысл в том, чтобы читать вывод, а не конфигурацию. Заголовки можно проверить разом сканером заголовков.
Запишите всё, что вы когда-либо создавали (②)
Поддомены, аккаунты, ключи, бакеты, сторонние сервисы. Главное — не фильтровать по признаку «ещё работает». Составьте список по чек-листу инвентаризации ресурсов и доводите неиспользуемое до удаления (а не просто отключения).
Настройте ровно один способ замечать проблемы (③)
Попытка сразу построить полный мониторинг обычно заканчивается тем, что его нет вовсе. Начните с одного: уведомления о новых регистрациях, всплеск неудачных входов или письма об уязвимостях зависимостей. Один, и обязательно проверьте, что он срабатывает (мониторинг, который настроили, но не проверили, — это мониторинг, которого у вас нет).
Посчитайте, что решают ваши входные данные (④)
Выпишите, решают ли внешние данные только значения или ещё структуру, тип и место назначения. Любое место, где они решают больше, чем значения, — приоритет для изменений.
Превратите обновления в механизм (чтобы ① не вернулось)
Первая схема обязательно возвращается, если её оставить. Поставить обновления зависимостей и фреймворков под автоматический мониторинг — единственный реалистичный ответ (как начать работать с osv-scanner / практическое руководство по устранению CVE). Процедура, которая существует только в документе, первой пропускается в загруженный день.
Позиция сайта: все четыре когда-то были верными
Общее у всех четырёх то, что каждое было правильным в какой-то момент. Значения по умолчанию были разумны во время разработки, неиспользуемое действительно не использовалось, пока вы были маленькими, вы бы действительно заметили, а проверка ввода решила очень много проблем. Именно поэтому их не перепроверяют.
Наша позиция — периодически спрашивать, когда прежде верное допущение перестало быть верным. Такая проверка дешевле и эффективнее, чем добавление новых технологий. И обратите внимание на разницу: чек-лист говорит, что делать, но не говорит, почему что-то упустили. А если причина не изменилась, то же самое снова упустят в том же месте.
Что почитать дальше
- В виде шагов: чек-лист базовой безопасности (частные лица и небольшие команды) / базовый уровень безопасности для организаций
- Инвентаризация: чек-лист инвентаризации ресурсов
- На реальных случаях: разборы инцидентов (одни и те же схемы появляются снова и снова)
- Тенденция: в 2026 году злоумышленники чаще приходили с учётными данными, чем с эксплойтами
FAQ
QС чего начать заниматься безопасностью?
Проверить, каким из четырёх схем соответствует ваша среда, быстрее, чем изучать отдельные техники атак. Остались ли настройки продакшена по умолчанию? Открыто ли что-то, что вы создали и не закрыли? Заметили бы вы, если бы что-то пошло не так? Насколько много вы позволяете решать внешнему вводу? В статье для каждого пункта есть конкретные проверки и ссылки на подробные материалы.
QЭто касается небольшого личного сайта?
Схемы те же, меняется порядок. Для частного лица или небольшой команды первыми окупаются две: проверка настроек по умолчанию (не включён ли отладочный вывод в продакшене?) и инвентаризация незакрытого (секреты в публичной папке, неиспользуемые поддомены, заброшенные аккаунты). Наблюдаемости нужна инфраструктура, поэтому она может подождать, но даже один сигнал, например уведомление о регистрации нового пользователя, сильно сокращает время, пока проблема остаётся незамеченной.
QЧем это отличается от чек-листа?
Чек-лист говорит, что делать, а здесь речь о том, почему что-то упускают. Список пунктов не поможет, если причина упущения не изменилась: то же самое снова упустят в том же месте. Все четыре убеждения когда-то были верными, поэтому и живут без проверки. Когда нужны конкретные шаги, переходите по ссылкам на чек-листы из каждого раздела.
QУ меня есть время только на одно. Что выбрать?
Исправьте что-то одно в третьем пункте — возможность заметить. Первые два превращаются в инциденты, если их игнорировать, но без третьего вы не узнаете, что инцидент произошёл. Ущерб определяется не столько самим взломом, сколько тем, как долго он остаётся незамеченным. Вести журнал, добавить одно уведомление, раз в месяц проводить инвентаризацию — любое из этого даёт наибольшую отдачу против затяжного инцидента.