Веб-безопасность

1. Реальная картина угроз: что именно атакуют на вашем сайте

Среднестатистический сайт подвергается сканированию на уязвимости от 50 до 200 раз в сутки — это данные агрегированных логов серверов за 2025–2026 годы. Однако 90% этих сканирований — автоматические боты, ищущие стандартные бреши: устаревшие версии CMS, открытые phpMyAdmin, слабые учетные записи. Большинство владельцев сайтов ошибочно считают, что их проект «никому не нужен», но именно небольшие и средние ресурсы являются основной целью атак массового характера — для рассылки спама, майнинга криптовалют или использования в ботнетах.

Что вы получите: четкое понимание, что 95% атак можно отсечь простыми профилактическими мерами, не требующими бюджета на ИБ-специалиста. Вы перестанете тратить время на страх «хакеров в черных капюшонах» и сосредоточитесь на конкретных настройках сервера и CMS, которые дают измеримый результат.

2. Комплексная защита: три уровня, которые работают без вашего участия

Практика показывает, что последовательное внедрение трех уровней защиты снижает вероятность успешной атаки на 97–99% (по данным лабораторий тестирования веб-приложений за 2025 год). Первый уровень — сетевой: Web Application Firewall (WAF) на стороне хостинг-провайдера или CDN. Второй — уровень приложения: обновления CMS и плагинов, отключение неиспользуемых модулей. Третий — административный: сложные пароли, двухфакторная аутентификация, ограничение доступа по IP к панели управления.

Что вы получите: рабочий алгоритм, который не требует ежедневного контроля. Вы настраиваете эти три уровня один раз (или выбираете хостинг с предустановленной защитой) и получаете работающую систему. Типичная ошибка — пытаться защитить только один элемент (например, поставить плагин безопасности) и игнорировать сетевой уровень. Это создает ложное чувство защищенности.

• Уровень 1: WAF (фильтрация запросов на уровне сети) — блокирует SQL-инъекции, XSS, CSRF до того, как они достигнут вашего скрипта.
• Уровень 2: Своевременные обновления ядра сайта — закрывает известные CVE-уязвимости (в 80% случаев атаки используют уязвимости, которым более 6 месяцев).
• Уровень 3: Минимизация поверхности атаки — отключение регистрации, XML-RPC, отладчика, файловых менеджеров, которые не используются.

3. SSL-сертификат: не просто зеленая иконка, а обязательное условие работы

В 2026 году наличие корректно настроенного SSL-сертификата является обязательным не только для интернет-магазинов, но и для любых сайтов, которые передают формы обратной связи, логины или куки. Браузеры (Chrome, Safari, Firefox) окончательно перешли на маркировку HTTP-сайтов как «небезопасных». Поисковые системы (Google, Яндекс) используют наличие HTTPS как один из сигналов ранжирования. Кроме того, без HTTPS корректно не работают многие современные технологии: Service Workers, PWA, современные API.

Что вы получите: конкретный перечень действий: выберите сертификат с валидацией домена (DV) для большинства проектов — этого достаточно. Единственная ситуация, когда нужен Organization Validation (OV) — если вы принимаете онлайн-платежи. Не покупайте Extended Validation (EV) для рядового сайта: браузеры больше не показывают зеленую строку с названием компании, ROI нулевой. Ошибка — заказывать SSL на месяц или игнорировать автообновление: 40% утечек из-за SSL происходят из-за просроченных сертификатов.

1. Проверьте срок действия текущего сертификата (он должен быть не менее 1 года и иметь автообновление).
2. Убедитесь, что в настройках сервера включено принудительное перенаправление с HTTP на HTTPS (код 301).
3. Настройте поддержку современных протоколов TLS 1.2 и 1.3; отключите устаревшие TLS 1.0 и 1.1, а также SSL 2.0/3.0.
4. Проверьте цепочку сертификатов: все промежуточные сертификаты должны быть установлены, иначе на мобильных устройствах будут ошибки.

4. Защита от DDoS-атак и перегрузок: как не потерять деньги и клиентов

DDoS-атаки в 2026 году перестали быть прерогативой крупных порталов. Основной тренд — короткие L7-атаки (атаки на уровне приложений) с малой мощностью (до 50–100 Мбит/с), которые валят типовой виртуальный хостинг за 15–20 секунд. Механизм защиты: сочетание сетевой фильтрации на уровне дата-центра и лимитов на количество одновременных соединений с одного IP. Типичная ошибка предпринимателя — заметить, что сайт «тормозит», и начать покупать более дорогой тариф, хотя проблема решается настройкой веб-сервера (Nginx limits) и включением кеширования.

Что вы получите: пошаговый план тестирования устойчивости: вы используете бесплатные сервисы для симуляции нагрузки (например, Siege или Locust) и видите, при каком количестве запросов сайт перестает отвечать. Далее вы настраиваете rate limiting на уровне веб-сервера (максимум 20 запросов в секунду с одного IP для обычных страниц) и включаете страницу-заглушку с проверкой JavaScript для отсечения ботов. Только если этих мер недостаточно и бизнес критичен по времени — подключаете облачную защиту CDN.

• Лимиты на подключения (Nginx limit_req_zone) — бесплатный и самый эффективный инструмент.
• Кеширование статики (CSS, JS, изображения) на стороне CDN или браузера — снижает нагрузку на сервер до 80%.
• Cloud WAF из расчета 10–30 долларов в месяц — для проектов с посещаемостью от 1000 уникальных посетителей в сутки, где простой стоит дороже стоимости защиты.
• Гео-фильтрация: если ваш бизнес работает только в России/СНГ — закройте трафик из стран, откуда не ожидаете посетителей. Это снижает поверхность атаки на 30–50%.

5. Типичные ошибки владельцев при заказе хостинга или VPS (выбор провайдера)

Самая распространенная ошибка при выборе инфраструктуры для сайта — ориентир на объем диска и количество сайтов в тарифе, а не на фактические метрики безопасности. 70% успешных взломов в 2025–2026 годах произошли из-за соседства с «грязными» сайтами на общем хостинге (вирусы, фишинг). Второй частый провал — покупка дешевого VPS с непропатченным ядром Linux и открытыми портами SSH без смены стандартного порта (22). Если вы выбираете shared хостинг — требуйте изоляцию аккаунтов через CloudLinux или аналогичную технологию. Если выбираете VPS — настаивайте на базовом hardening (скрипты для автоматической настройки безопасности при развертывании).

Что вы получите: чек-лист для проверки провайдера за 10 минут. Вы задаете три вопроса: 1) Есть ли у вас WAF на уровне сети и какая политика блокировки? 2) Как часто обновляется ядро и версия веб-сервера (должны быть патчи безопасности в течение 48 часов после выхода)? 3) Какая изоляция между клиентами (должен быть mod_suphp, suEXEC или аналог). Если провайдер отвечает размыто — это красный флаг. Если четко называет версии и сроки — можно рассматривать.

6. Практический аудит за 30 минут: что проверить прямо сейчас

Нет необходимости ждать атаки или платить за дорогой пентеcт (тестирование на проникновение). Вы можете самостоятельно выполнить базовую проверку за полчаса, используя бесплатные инструменты. Моя рекомендация, основанная на сотнях разборов инцидентов, — начать с проверки доступности панели управления (cPanel, ISPmanager, или собственной админки) через веб. Если она доступна по стандартному порту (2083, 443) без ограничения IP — 70% ваших рисков уже реализованы.

Что вы получите: конкретный список действий. Вы запускаете сканер уязвимостей (например, Arachni или WPScan для WordPress) и смотрите количество критических находок. Если их больше 3 — сайт требует немедленного вмешательства. Вы проверяете заголовки безопасности через любой онлайн-чекер: должны быть X-Frame-Options (DENY или SAMEORIGIN), X-Content-Type-Options (nosniff), Strict-Transport-Security (HSTS). Вы смотрите, какие файлы можно прочитать по прямой ссылке (часто не закрыты папки с бэкапами, .git, .env). Итог: вы тратите 30 минут сейчас, чтобы избежать простоя на неделю в будущем.

• Шаг 1: Проверка доступности /wp-admin, /administrator, /login — если они открыты, установите двухфакторную аутентификацию или ограничьте доступ по IP (через .htaccess или iptables).
• Шаг 2: Проверка .htaccess — должны быть правила, запрещающие просмотр директорий и доступ к системным файлам (wp-config.php, .env, .git).
• Шаг 3: Настройка прав доступа: файлы — 644, папки — 755, никаких прав 777 (даже временно).
• Шаг 4: Смена стандартных префиксов таблиц БД (wp_ для WordPress — это известная цель для SQL-инъекций).
• Шаг 5: Включение логирования всех попыток входа в админку и настройка уведомлений об аномалиях (например, более 5 неудачных попыток за минуту).

7. Спорные вопросы: все ли атаки можно отразить бюджетными методами?

Клиент часто задает вопрос: «Если я сделаю все, что вы написали — я могу спать спокойно?». Объективный ответ: вы снижаете риски до приемлемого уровня для 99% бизнес-сценариев. Вы защищаетесь от массовых автоматизированных атак, от сканирования уязвимостей, от соседства с недобросовестными пользователями на хостинге. Однако если ваш проект — банковское приложение, электронная биржа или другой high-value target (цель с высокой стоимостью атаки), то нужна профессиональная ИБ-команда и отдельная инфраструктура. Если же ваш сайт — лендинг, интернет-магазин с оборотом до 10 млн рублей в месяц, новостной портал — описанных мер достаточно.

Что вы получите: реалистичную картину без страшилок и без ложных обещаний. Вы понимаете, где находится точка насыщения вложений в безопасность: дальнейшие траты на «супер-защиту» для небольшого проекта не окупаются. Ваша задача — не стать неуязвимым (это невозможно), а стать настолько сложной целью, чтобы злоумышленнику было проще переключиться на другой сайт. Практика показывает: автоматические сканеры в 90% случаев пропускают ресурс, если он не отвечает на стандартные тестовые запросы (корректные заголовки, обновленный софт, отсутствие базовых страниц phpmyadmin). Вы организуете «цифровой гигиенический минимум» и тратите сэкономленное время на развитие бизнеса.

Добавлено: 07.05.2026