Веду небольшой корпоративный сайт. Впервые нормально посмотрел логи и был в шоке.
Тысячи запросов в день на адреса типа /wp-admin, /.env, /phpmyadmin, /.git/config. А у нас даже WordPress не стоит.
Это атака конкретно на нас или у всех так? Что делать?
Сначала успокойтесь: это не атака на вас, а фоновый шум, который получает любой адрес, открытый в интернете. Автоматические сканеры постоянно прощупывают все диапазоны IP и тыкают в известные уязвимости. Им пофиг, что у вас за сайт, и разбираться они не будут.
Теперь перейду к скептической части, потому что «норма» не значит «не важно». Разделяйте вот так:
Автоматический шум: запросы на случайные адреса с ответом 404, с разных IP, повторяющиеся паттерны. Это просто шум.
На что обратить внимание: попытки доступа к вашим реальным адресам. Перебор паролей на странице входа, попытки зайти в админку, манипуляции с параметрами. Это значит, что кто-то реально присматривался к вашему сайту.
Что делать, по приоритету: не оставляйте админку открытой для всех, поставьте лимит на попытки входа, держите софт в актуальном состоянии, делайте бэкапы и обязательно проверяйте их восстановлением.
Последний пункт чаще всего пропускают. Бэкап, который не проверяли на восстановление, — это не бэкап.
Добавлю техническую часть со стороны SOC.
Пытаться полностью заблокировать такой шум (например, банить каждый IP) — обычно пустая трата времени. IP постоянно меняются, списки раздуваются, а в один день вы случайно забаните своего же пользователя.
Вместо этого фильтруйте шум, чтобы видеть реальные инциденты. Практичный метод: пишите запросы с 404 в отдельный лог, а в основном потоке оставляйте только 200 и 500. И ведите отдельный счетчик неудачных попыток входа.
Как правило для алертов советую такое: много неудачных входов за короткое время с одного источника. Это паттерн, который реально выделяется на фоне шума и требует реакции.
И не забывайте: самые частые реальные взломы начинаются не с грубого подбора снаружи, а со входа по слитому паролю. Поэтому смотреть логи важно, но включить двухфакторную аутентификацию — тоже обязательно.
Вопрос: вы говорите, что впервые нормально посмотрели логи. А как далеко назад можно смотреть?
Причина проблемы в том, что на большинстве серверов срок хранения логов по умолчанию короткий. Все, кто хочет посмотреть историю после инцидента, упираются в одну и ту же стену: логов нет.
Как человек, которому нужны доказательства, советую конкретно: проверьте срок хранения логов и увеличьте его минимум до 90 дней. Место занимает мало, а в момент инцидента ценность огромная. Также храните логи не только на самом сервере, но и в другом месте; если сервер взломают, логи удалят первыми.
Дам цифры от лица хостинга, это не догадки, а паттерн, который мы регулярно видим в своей панели.
Даже новый домен, который нигде не рекламировался и на который нет ссылок, начинает получать такие автоматические попытки в первую же неделю. Причина проста: записи прозрачности сертификатов публичны, и новые домены видно оттуда.
То есть ситуации «мой сайт маленький, никто о нем не знает» в плане безопасности не существует. Быть маленьким не делает вас невидимым, это лишь снижает вероятность целевой атаки.
Я студент, хочу кое-что спросить, не обессудьте, если вопрос глупый.
Чё эти браузеры ищут файл /.env? Ну и что там такого ценного?
Совсем не глупый вопрос, очень даже по делу.
Файл .env — это текстовый файл с настройками приложения (environment, т.е. переменные окружения). Там обычно лежат адрес и пароль от базы данных, ключи сторонних сервисов, ключ шифрования сессий.
Короче, для взломщика этот файл — это найти ключ, а не ломать дверь. Поэтому сканеры сначала тыкают в него: цена вопроса один запрос, а выхлоп — всё.
В норме этот файл должен лежать вне папки, которую обслуживает веб-сервер. При кривой настройке он остается внутри public и его можно прочитать через браузер. Та же логика работает и для /.git/config: если репозиторий проекта случайно выложили в прод, можно скачать весь исходник.
Проверить элементарно: напишите в адресной строке /.env. Если 404 — всё ок, если видите содержимое — сразу закрывайте и меняйте все ключи в этом файле. Просто закрыть мало, считайте, что они уже утекли.
Команда Doki хочет добавить пару слов, потому что тема подняла важный и частый вопрос.
Мы тоже видим ту же картину: любой актив, торчащий в интернет, сканируется, даже если его нигде не афишируют. Поэтому клиентам мы в первую очередь советуем составить инвентарь активов — какие домены, поддомены, серверы реально наши, а какие забыли и они до сих пор живы.
На практике самая частая дыра — забытые тестовые среды. Прод нормально защищен, а тестовый сервер, поднятый два года назад, все еще смотрит в ту же базу данных.
Посты здесь носят общий информационный характер; рекомендуем заказать оценку с четко определенным объемом работ для вашей системы.
Если смотреть на процесс в целом, картина меняется. Если включена двухфакторная аутентификация, украденный пароль бесполезен.
Если включена двухфакторная аутентификация, украденный пароль бесполезен. Если напишете результат здесь, это поможет и другим.
Согласен, хочу даже особо подчеркнуть. Если путь уведомления длинный, уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент.
Интересно, есть ли те, кто делает иначе.
Есть один момент который меня интересует. Спешка в решениях оборачивается исправлениями через полгода.
Удачи.
Краткое резюме для новичков: Чем сложнее отменить решение, тем медленнее его принимайте.
Любой пункт, не зафиксированный письменно, в будущем обе стороны будут помнить по-разному. Удачи.
Спасибо, что написали об этом, это действительно так. Если разрешение и объем тестирования не зафиксированы письменно, тест не начинать.
Это мое мнение, не утверждаю, что оно единственно верное.
Я долго занимался этим вопросом. Большая часть потерь времени копится на задачах, ожидающих согласования.
Ошибка, сделанная на стороне лог, обычно исправима, но дорого. Надеюсь, это будет полезно.
А как вы решили этот вопрос? Пытаться сделать это в одиночку — самый дорогой путь.
Ошибка сделанная на стороне лог обычно исправима но дорого. Это мое мнение, не утверждаю что оно единственно верное.