Аудит безопасности сайта: что проверяем и зачем — IT-Aegis

Аудит безопасности сайта: что проверяем и зачем

Аудит безопасности сайта: что проверяем и зачем

Профилактический аудит дешевле аварийной чистки после взлома: в первом случае вы платите за проверку, во втором — за срочность, простой и восстановление репутации домена. Особенно это заметно перед высоким сезоном, когда день неработающего магазина стоит больше, чем весь аудит.

Ниже — что именно проверяется и почему каждый пункт попал в список.

Зачем проверять сайт, который работает

Заражение почти всегда начинается тихо: на сайте появляется один лишний файл, который неделями ничего не делает. Задача аудита — найти его до того, как он сработает, и закрыть путь, которым он попал внутрь. Работающий сайт не равен здоровому сайту: половину находок владельцы не видят вообще, потому что вредоносный код не показывается администратору.

Файловая система

Сравниваем ядро CMS с эталонной версией по контрольным суммам и разбираем всё, что не совпало. Ищем неизвестные PHP-файлы в каталогах загрузок, где исполняемого кода быть не должно, конструкции вида eval и base64, подозрительные задания планировщика. Отдельно смотрим даты изменения: файл темы, изменённый в три часа ночи, обычно меняли не вы.

База данных

В базе прячется то, что не найти в файлах: спам-ссылки внутри опубликованных материалов, вставки в виджеты, редиректы в настройках, лишние учётные записи с правами администратора. Проверяем и права самой учётки базы — ей почти никогда не нужен полный доступ, а выдают его по умолчанию.

Конфигурация и доступы

  • Версии CMS, модулей и PHP — что устарело и что снято с поддержки.
  • Права на файлы и закрытость конфигов с паролями от внешних запросов.
  • SSL и заголовки безопасности, принудительное перенаправление на HTTPS.
  • Двухфакторная аутентификация в панели и ограничение попыток входа.
  • Список доступов: старые сотрудники и прошлые подрядчики среди пользователей — обычная находка.

Резервные копии

Проверяем не наличие копий, а возможность из них восстановиться. Копия, которая лежит на том же сервере и никогда не разворачивалась, при аварии не поможет. Что должно быть у копий по частоте, глубине и месту хранения, разобрано в статье про правило 3-2-1.

Что находим чаще всего

Где смотримТипичная находка
Каталог загрузокPHP-файл среди картинок — почти всегда бэкдор
Список пользователейАдминистратор, которого никто не заводил, или доступ уволенного сотрудника
Модули и плагиныВерсии с известными уязвимостями, снятые с поддержки
Настройки в базеРедирект для посетителей из поиска, невидимый для админа
Резервные копииЕсть, но лежат рядом с сайтом и ни разу не проверялись

Как проходит аудит

  1. Снимаем копию файлов и базы, чтобы работать с ней, а не с боевым сайтом.
  2. Сверяем ядро и модули с эталонными версиями, разбираем расхождения.
  3. Проверяем базу, права, конфигурацию и список доступов.
  4. Устраняем найденное и закрываем путь входа, а не только следствие.
  5. Отдаём отчёт и список того, что стоит изменить в регулярных работах.

Что вы получаете на выходе

Отчёт на понятном языке: что нашли, чем это грозило, что уже устранено и что требует решения — например, обновление CMS с проверкой совместимости модулей. Плюс рекомендации по регулярной части: мониторинг, политика обновлений, двухфакторная аутентификация, порядок работы с доступами.

Как часто повторять проверку

Разовый аудит фиксирует состояние на сегодня. Через квартал картина уже другая: вышли обновления, добавились модули, сменились люди с доступами. Разумный ритм — полная проверка раз в полгода и обязательно перед высоким сезоном, плюс внеочередная после любого крупного изменения: переезда на новый хостинг, смены подрядчика, установки тяжёлого модуля вроде маркетплейс-выгрузки.

Между аудитами работает регулярная часть: обновления по расписанию, мониторинг доступности и изменений файлов, проверка копий. Она стоит дешевле и ловит проблему в первые часы. Что входит в такое обслуживание, разобрано в статье про стоимость поддержки сайта.

Что аудит не решает

Проверка показывает состояние и закрывает найденное, но она не заменяет двух вещей. Первая — дисциплина обновлений: если модули не обновлять, через полгода список уязвимостей соберётся заново. Вторая — порядок с доступами: пока пароль от админки лежит в общем чате, любая техническая защита обходится по-человечески, без взлома. Отдельная история — дешёвый хостинг, где соседние сайты на том же сервере становятся источником заражения, и аудит вашего сайта тут не поможет.

Выводы

  • Аудит нужен не после взлома, а до него: сработавшее заражение стоит дороже проверки.
  • Проверять файлы без базы бессмысленно — половина находок живёт именно в базе.
  • Копии считаются рабочими только после проверки восстановления.
  • Старые доступы подрядчиков и уволенных сотрудников — самая недооценённая дыра.
  • Разовый аудит закрывает текущее состояние; чтобы оно не поехало, нужны регулярные обновления.

Проверим ваш сайт и покажем реальную картину: аудит безопасности и чистка с отчётом. Если нужна не разовая проверка, а постоянный контроль, это поддержка с обновлениями и мониторингом.

Услуги по теме

Обсудить проект — аудит, разработка, поддержка.

Оставить заявку Услуги