Представьте: 29 декабря, реклама работает, корзины забиты, менеджерам звонят с криком «успейте до НГ» - и в этот момент ваш сайт ложится. Или хуже: не ложится… а спокойно сливает данные клиентов куда-то «на сторону».
Это не сюжет хоррора для айтишников - это то, что каждый год реально происходит с тысячами бизнесов по всему миру. Атаки на веб-приложения - один из самых распространённых векторов для злоумышленников, особенно в периоды распродаж и праздников, когда трафик растёт, а все заняты продажами, а не безопасностью.
Начинаем с базового: HTTPS не «для галочки»
Вопрос №1: ваш сайт открывается по https:// и без ошибок «Небезопасно»?
1. Есть ли вообще валидный SSL-сертификат
- В браузере рядом с адресом - замочек, без красных предупреждений.
- Сертификат не истёк (дата окончания не «вчера» и не «завтра»).
2. Всё ли грузится по HTTPS, а не «через одно место»
- Частая ситуация: сам сайт по HTTPS, а картинки, скрипты или формы - по HTTP.
- Это называется mixed content - данные всё равно можно подсмотреть или подменить.
3. Включена ли принудительная переадресация
- Любой заход на http://вашдомен должен автоматически улетать на https://вашдомен.
- Это настраивается в конфиге сервера (Nginx, Apache) или в панели хостинга.
Если этот пункт не закрыт - дальше можно даже не читать. Без нормального HTTPS говорить о безопасности вообще бессмысленно.
Доступ к админке: кто вообще может зайти «в дом»?
Большинство взломов - это не голливудские хакеры с зелёным кодом, а банальное «подобрали пароль от админки». Особенно, если логин admin, пароль 123456 (да, до сих пор встречается) или тот же пароль, что от почты.
1. Смена логина и пароля администратора
- Логин не должен быть admin, root, название сайта и т.п.
- Пароль - не меньше 12–14 символов: буквы разного регистра, цифры, спецсимволы.
- Никаких дат рождения, имён детей и названий компаний.
2. Двухфакторная аутентификация (2FA)
- Для популярных CMS (WordPress, Bitrix и т.д.) есть плагины/модули 2FA.
- Суть простая: даже если пароль утечёт, войти без одноразового кода не получится.
3. Ограничения по IP и попыткам входа
- Ограничить доступ в админку по IP (если с неё заходят только несколько человек).
- Лимитировать число попыток входа (после, например, 5 попыток - блокировка).
4. Запрет /admin «для всех подряд»
- Если CMS популярная, URL админки тоже лучше поменять.
- Да, это не панацея, но «стреляют» сначала по типовым URL, так что лишняя защита не помешает.
Обновления: «работает - не трогай» = прекрасный путь к взлому
Большинство успешных атак на сайты-— это эксплуатация известных уязвимостей в старых версиях CMS, плагинов, тем и библиотек. Инфу о дырах в публичных системах выкладывают в открытый доступ, а скрипты для автоматического взлома пишают школьники.
1. Версия CMS
- Установлена ли последняя стабильная версия?
- Если вы на древнем ядре, которое уже не поддерживается, - это мина замедленного действия.
2. Плагины и модули
- У каждого плагина/модуля - своя история уязвимостей.
- Оставляем только то, чем реально пользуемся, остальное - выключаем и удаляем.
- Обновляем оставшиеся до последней стабильной версии.
3. Тема / шаблон
- Кастомную тему нельзя «обновить одной кнопкой», но: посмотрите, не тянет ли она старые версии библиотек (jQuery 1.x, древние слайдеры и т.п.).
- Любые сторонние скрипты стоит обновить до версий, которые ещё поддерживаются.
4. Сторонние виджеты
- Онлайн-чаты, виджеты обратной связи, формы подписки - всё это тоже код.
- Если отжили своё и давно не обновлялись, их лучше заменить на актуальные решения.
Резервные копии: без них любые разговоры - это сказки
Самый честный вопрос, который можно себе задать: «Если сайт сломается 31 декабря в 22:30, за сколько времени я смогу восстановиться и из чего?»
1. Есть ли автоматический бэкап
- Идеальный вариант: ежедневные или хотя бы недельные копии файлов и баз данных.
- Бэкапы НЕ должны храниться на том же сервере, где сам сайт (иначе при проблеме вы теряете и сайт, и копию).
2. Знаете ли вы, как восстановиться
- Частая проблема: «Бэкап вроде есть, но как им пользоваться - никто не знает».
- Один раз прогоните тестовое восстановление на отдельном окружении.
Лучше потратить время заранее, чем разбираться в панике.
3. Есть ли бэкап не только сайта, но и базы
- Многие вспоминают про файлы, но забывают про базу данных.
- Без базы у вас максимум статический музей, а не работающий магазин.
Формы, заявки, комментарии: любимая дверь для хакеров
Все поля, которые заполняет пользователь (форма заказа, обратная связь, поиск, комментарии) - это место, куда злоумышленник будет пытаться «засунуть» вредный код.
Два основных типа атак, которые остаются актуальными годами:
- SQL-инъекции - попытка «вклинить» свой запрос в базу данных через поле ввода.
- XSS-атаки (межсайтовый скриптинг) - внедрение своего JavaScript-кода, который выполняется у ваших посетителей.
1. Фильтрация и экранирование данных
- Любые пользовательские данные должны проходить проверку и очистку, прежде чем попасть в запрос к базе или в HTML.
2. Ограничения по длине
- Если поле «Имя» позволяет вбить туда 10 000 символов - это уже тревожный звоночек.
3. reCAPTCHA или её аналоги
Не только от ботов, но и от массовых попыток «ломать» формы.
4. Файлы в формах
Если пользователь может загрузить файл - убедитесь, что:
- Нет возможности залить .php или другой исполняемый код.
- Файлы не попадают в папку, откуда их можно выполнить как скрипт.
Логи и мониторинг: видите ли вы вообще, что с сайтом происходит?
Много бизнесов узнают о проблеме не от системы мониторинга, а из жалоб клиентов: «Почему сайт тормозит?» или «А что это за странное всплывающее окно?».
1. Включённые логи сервера и приложения
- Логи ошибок (error log) и доступов (access log) должны сохраняться и быть доступны.
- Хоть раз откройте их и посмотрите:
- Нет ли постоянного шквала запросов на странные адреса (/wp-admin.php, /phpmyadmin, /xmlrpc.php и т.п.).
- Нет ли десятков запросов в секунду с одного IP.
2. Уведомления о падении сайта
- Любой простой сервис мониторинга, который пингует сайт и шлёт уведомление, если тот не отвечает.
- Это не «киберщит», но вы хотя бы узнаете о проблеме раньше клиентов.
3. Мониторинг нагрузки
- Минимум: понимать, что такое «нормальная» загрузка CPU, RAM и диска.
- Перед праздниками нагрузка растёт - если сервер и так работает на пределе, он просто не выдержит пики.
Права и доступы: кому вы открыли дверь в систему
Часто «дырка» - не в коде, а в людях.
Проверьте:
- Кто имеет доступ к админке
- Сколько активных аккаунтов?
- Есть ли старые сотрудники, фрилансеры, агентства, которым доступ больше не нужен, но он не отключён?
- Не нужно, чтобы каждый пользователь был админом.
- Маркетологу часто достаточно прав на контент, а не на управление системой.
- Кто может зайти в панель хостинга?
- Кто управляет доменом (регистратор, панель DNS)?
- Есть ли резервный доступ (не на одном личном почтовом ящике, который могут заблокировать)?
Защита от грубой силы и DDoS: как сайт переживёт новогодний шквал
Новогодний пик продаж - это рост трафика не только от клиентов, но и от ботов. Автоматические переборы паролей, спам в формы, попытки DDoS - всё это тоже приходит «поздравить» ваш бизнес.
Что стоит сделать:
- Ограничение числа запросов (rate limiting) (на уровне сервера или веб-фильтра можно ограничить число запросов с одного IP за единицу времени).
- Это не убьёт нормальных пользователей, но осложнит жизнь ботам.
- WAF - Web Application Firewall - это фильтр, который отслеживает и блокирует типичные вредоносные запросы (вроде SQL-инъекций, XSS и т.п.).
- CDN для статики - CDN разгружает ваш сервер, раздавая картинки, стили и скрипты с распределённой сети.
- В пике вам не придётся держать монстра-сервер только потому, что все одновременно решили открыть главную страницу.
Социнженерия и люди: где всё ломается по-настоящему
Можно построить крепость, но толку мало, если кто-то из сотрудников:
- открывает подозрительные вложения,
- вводит пароль от админки «на похожем сайте»,
- по телефону диктует коды из SMS «администратору хостинга».
Базовый минимум:
1. Обучение команды
- Письма с «срочным продлением домена» проверяем через официальный кабинет, а не по ссылке в письме.
- Никому не диктуем логины и пароли по телефону и в мессенджерах.
2. Раздельные пароли
- Пароль от почты, домена, админки сайта и FTP/SSH - это должны быть разные пароли.
- В идеале - менеджер паролей и 2FA.
3. Резервный канал связи
- Чтобы в случае проблем с доменом или сайтом вы могли связаться с хостером/регистратором, даже если почта на этом же домене не работает.
Итог: безопасность - не космос, а часть нормального обслуживания сайта. Защита сайта - это не магия, а такая же рутина, как менять масло в машине.
Не нужно становиться кибер-гением, чтобы:
- не отдавать админку на ключе «123456»,
- не держать CMS десятилетней давности,
- не жить без бэкапов и мониторинга.
Чем раньше вы это сделаете - тем меньше шансов, что ваш сайт «повиснет» именно в тот момент, когда к нему выстроится очередь из живых денег. И пусть в этом новогоднем сезоне единственное, что «горит», - это горячие продажи, а не ваш сервер.