Защита сайта: файрвол, ограничение входа, права на файлы и поиск вредоносного кода
1. Firewall: группа безопасности в облаке плюс WAF — сначала закройте ненужные порты
Многие думают, что файрвол — это программа на сервере, но для сайта на облачном хостинге первая линия защиты — группа безопасности облачного провайдера. Главная опасность — когда в группе безопасности по умолчанию открыты порты 3306, 6379, 9000: база данных и Redis оказываются в открытом интернете, и сканеры подбирают к ним доступ за считаные минуты. Правильно — разрешить в группе безопасности только 80 и 443, а порт 22 ограничить фиксированным IP вашего офиса.
Вторая линия защиты — WAF (Web Application Firewall). Бесплатной версии Cloudflare достаточно: она автоматически блокирует SQL-инъекции, XSS и типовые сканеры. Не делайте правила WAF слишком агрессивными, иначе заблокируете обычных посетителей. Сначала включите режим только логирования на 3 дня, убедитесь, что доля ложных срабатываний ниже 1%, и только потом переключайтесь на блокировку.
| Порт/сервис | Состояние по умолчанию | Состояние после усиления | Причина |
|---|---|---|---|
| 80/443 | Открыт 0.0.0.0/0 | Открыт 0.0.0.0/0 | Должен быть доступен из интернета |
| 22 SSH | Открыт 0.0.0.0/0 | Ограничить фиксированным IP компании, перейти на вход по ключу | Главная цель брутфорса паролей |
| 3306 MySQL | Часто открывают по ошибке | Разрешить только 127.0.0.1 | Никогда не открывать в интернет |
| 6379 Redis | Часто открывают по ошибке | Только локально, задать пароль | При доступе без авторизации злоумышленник запишет свой публичный ключ |
| 9000 PHP-FPM | Локальный socket | Оставить локальный socket, не открывать TCP | Доступ из интернета не нужен |
| 8888/宝塔面板 | Часто открыта наружу | Ограничить по IP и сменить порт по умолчанию | Панель — частая цель атак |
场景示例：一个用宝塔面板的WordPress站，刚上线时安全组全开，三天后服务器CPU跑到100%。登上去看是3306端口被境外IP爆破，MySQL日志里全是连接失败记录。改成安全组只开80/443和限公司IP的22，CPU立刻降回5%。这个事故10分钟就能避免，但多数人上线时根本不看安全组。
Как настроить правила WAF — та же логика, что и в защите форм обратной связи от спама: сначала логировать и наблюдать, потом блокировать, а не банить все подозрительные запросы сразу.
2. Ограничение входа: сужаем вход для брутфорса
wp-admin в WordPress — главный вход для взлома независимого сайта. Логин admin по умолчанию, простой пароль, открытая страница входа — сканер пробегает словарь за пару часов. Контринтуитивный факт: плагин ограничения входа работает лучше любого сканера безопасности, потому что большинство брутфорс-атак вообще не доходит до эксплуатации уязвимостей — они упираются в страницу входа и блокируются.
Три обязательных ограничения входа: блокировка после 5 неудач на 30 минут, смена стандартного пути входа (/wp-admin на случайную строку), обязательная 2FA. Пароль не короче 16 символов, генерируйте менеджером паролей, не используйте слово плюс цифры. С SSH то же самое: запретите вход по паролю, оставьте только ключи.
| Параметр | По умолчанию | Значение защиты | Инструмент/реализация |
|---|---|---|---|
| Блокировка после неудачных входов | Без ограничений | 5 неудач — блокировка на 30 минут | Wordfence или свой fail2ban |
| Путь входа | /wp-admin | Случайная строка, например /login-7f3k | Плагин WPS Hide Login |
| Двухфакторная аутентификация | Нет | Обязательный TOTP 2FA | Wordfence или Two Factor |
| Длина пароля | 6 символов | ≥16 случайных символов | Генерация менеджером паролей |
| Аутентификация SSH | Вход по паролю | Только ключи, пароль запрещён | в sshd_config указать PasswordAuthentication no |
| Пользователь базы данных | root удалённо | Отдельный пользователь, только с локального хоста | Создать отдельный аккаунт в MySQL |
Пример из практики: SaaS-сайт для зарубежных рынков, страница входа в админку на /secret-admin, включена 2FA, блокировка после 5 неудач на 30 минут. Логи показывают около 2000 попыток входа в неделю с зарубежных IP — все заблокированы, ни одна не прошла. Без ограничений при средней стойкости пароля вероятность успешного подбора за 3 месяца превысила бы 30%.
Общий подход к выбору плагинов и технологическому стеку — в статье Четыре собственных плагина технологического стека crater.
3. Права на файлы: чтобы загруженные вредоносные файлы не запускались
Права на файлы — слой, который многие игнорируют. После взлома WordPress атакующий обычно загружает PHP-вебшелл в каталог wp-content/uploads. Если в uploads разрешено выполнение PHP, вебшелл сразу получает контроль над сайтом; если выполнение PHP запрещено, загруженный файл не запустится, и атакующий останется ни с чем.
Стандартные права: каталоги 755, файлы 644, wp-config.php — 400 (только владелец может читать). Не ставьте всё на 777 ради удобства — это всё равно что повесить ключ на двери. Для каталога uploads добавьте в конфигурацию nginx правило, запрещающее выполнение .php, .phtml, .php5 и подобных файлов.
| Путь | Права | Владелец | Пояснение |
|---|---|---|---|
| Корень сайта | 755 | www-data:www-data | Не давать 777 |
| wp-config.php | 400 | root | Веб-процесс не может читать |
| wp-content/themes | 755 | www-data | Нужны права на запись для автообновления |
| wp-content/uploads | 755 | www-data | Запретить выполнение PHP |
| wp-content/plugins | 755 | www-data | Нужна запись для обновления плагинов |
| Каталог .git | Не выставлять в веб | — | Раскрытие приведёт к утечке исходного кода |
Ещё одна частая причина взлома — файлы резервных копий базы данных лежат прямо в веб-каталоге. Многие плагины бэкапа по умолчанию сохраняют .sql.gz в wp-content/backup/, и атакующий, найдя его сканером, просто скачивает файл и получает все данные сайта. Правильно — хранить бэкапы вне корня сайта либо после создания копии автоматически загружать её в объектное хранилище и удалять локальную версию. О стратегии бэкапа читайте Бэкап и восстановление сайта.
4. Вредоносные сканирования и патчи: раз в неделю, обновление в течение 7 дней
Искать вредоносный код нужно не после взлома, а заранее. Раз в неделю сверяйте хеши системных файлов: если хеши файлов ядра WordPress не совпадают с известной версией, значит, их изменили. Обновления плагинов и тем нужно устанавливать в течение 7 дней — от публикации уязвимости до её использования автоматическими сканерами в среднем проходит 14 дней, так что патч за 7 дней отсекает большинство атак.
Сканеры делятся на три типа: плагины вроде Wordfence проверяют известные сигнатуры webshell; ClamAV запускает антивирусное сканирование на уровне сервера; анализ серверных логов выявляет подозрительные шаблоны доступа. Используйте их вместе, не надейтесь, что один инструмент закроет всё. О подходе к анализу логов AI-краулеров читайте анализе логов AI-краулеров, те же методы анализа логов помогут находить и вредоносные сканеры.
| Что проверить | Частота | Инструмент | Работа с исключениями |
|---|---|---|---|
| сверка хешей системных файлов | Еженедельно | Wordfence core integrity | Нашли расхождения — восстановите из чистой версии |
| Обновление плагинов и тем | Каждый понедельник | Админка WP + логи | Обновить в течение 7 дней |
| Сканирование webshell | Еженедельно | ClamAV или Wordfence | Изолировать и удалить вредоносные файлы |
| Подозрительные входы | Ежедневно | Логи fail2ban | Автоматическая блокировка IP атакующих |
| Недавно изменённые файлы в веб-каталоге | Еженедельно | find -mtime -7 | Неожиданные изменения — сразу разбираться |
| Аномальные записи в базе данных | Еженедельно | base64-контент в wp_posts | Удалить скрытый код eval |
Контринтуитивное напоминание: после взлома не спешите чистить сайт онлайн. Главная проблема онлайн-очистки в том, что webshell и задачи cron, спрятанные в базе данных, вычистить до конца не получится, и через две недели всё вернётся. Правильный порядок: отключить сайт от внешних сервисов, восстановить из последнего чистого бэкапа, сменить все пароли и ключи, проверить cron и остатки в базе данных, затем снова запустить сайт. Полный порядок действий после взлома читайте Очистка и повторная индексация сайта после взлома.
Чек-лист ежедневного осмотра смотрите Шесть задач на месяц в период обслуживания сайта, зафиксируйте в нём и усиление безопасности. Как настроить пороги оповещений, читайте Мониторинг сайта и оповещения.
FAQ: частые вопросы
Сайт взломали — что делать в первую очередь?
Стоит ли покупать платный WAF, хватит ли бесплатной версии Cloudflare?
Как часто обновлять плагины WordPress и безопасно ли автообновление?
Какие права выставить для wp-config.php и каталога uploads?
Менять ли стандартный SSH-порт 22 и можно ли оставить вход по паролю?
Как понять, что сайт взломали, и есть ли предвестники?
В заключение
В защите сайта дороже всего не инструменты, а установка «пронесёт». Независимый сайт — не банк, но это вход для ваших заявок: если его взломают или он упадёт, вы потеряете реальные лиды. Четыре уровня защиты не обязательно внедрять сразу, но порядок важен: сначала закрыть порты, потом ограничить вход, затем настроить права на файлы и в конце подключить сканирование. Первые три шага делаются за один день и дают максимальную отдачу.
Три шага на практике. Первый: зайдите в группу безопасности облака и закройте порты 3306, 6379, 8888 — им не место в открытом интернете, а SSH ограничьте IP-адресом компании. Второй: смените путь к wp-admin, включите 2FA и блокировку после 5 неудачных попыток, а для SSH перейдите на вход по ключу. Третий: раз в неделю в фиксированное время проверяйте хеши основных файлов и обновляйте плагины. Выполнив эти три шага, вы уже отбиваете 80% типовых атак.
Запомните одну фразу: независимые сайты взламывают редко из-за изощрённых хакеров — чаще из-за слабых паролей, необновлённых плагинов и открытых резервных копий баз данных. Закройте эти три входа, и это поможет лучше любой системы безопасности.