За 10+ лет работы с веб-проектами я видел, как неправильно настроенный firewall может как спасти сайт от атак, так и полностью его "уронить". И честно говоря, в 2026 году это уже не роскошь, а базовая необходимость — особенно после того, как количество DDoS-атак выросло в 3 раза по сравнению с 2022 годом.
Что такое Firewall и почему он нужен каждому сайту
Firewall — это программный или аппаратный барьер между вашим сервером и внешним миром. Грубо говоря, это охранник, который проверяет каждый запрос к сайту и решает: пропустить его или заблокировать. Но в отличие от обычного охранника, firewall работает 24/7 и может анализировать тысячи запросов в секунду.
На практике у меня был клиент с интернет-магазином на WordPress, который получал по 200-300 запросов в секунду от ботов. Сайт "лежал" по несколько раз в день. После настройки правильного firewall атаки прекратились, а нагрузка на сервер упала в 10 раз.
Современные firewall-решения работают на нескольких уровнях:
- Сетевой уровень — блокирует IP-адреса и целые подсети
- Транспортный уровень — контролирует TCP/UDP соединения
- Прикладной уровень — анализирует HTTP-запросы и их содержимое
- Уровень приложений — защищает конкретные CMS и веб-приложения
А вот что интересно: многие считают, что firewall нужен только крупным сайтам. Это заблуждение. Я видел, как небольшой корпоративный сайт на Битрикс атаковали через уязвимости в старых модулях. Ущерб составил больше 500 тысяч рублей — пришлось восстанавливать данные, чинить репутацию, платить штрафы за утечку персональных данных.
Типы Firewall-решений для веб-сайтов
За годы практики я работал с десятками различных firewall-решений. Каждый тип имеет свои плюсы и минусы, которые критически важно понимать перед выбором.
Аппаратные Firewall
Это отдельные устройства, которые стоят между интернетом и вашим сервером. Cisco ASA, Fortinet, SonicWall — классика жанра. У одного клиента стоит Cisco ASA 5516-X, который обрабатывает 4 Gbps трафика без просадок производительности.
Плюсы аппаратных решений:
- Максимальная производительность — выделенное железо работает быстрее программных решений
- Не нагружают основной сервер — обработка трафика происходит на отдельном устройстве
- Продвинутая аналитика — глубокий анализ трафика и детальные отчёты
Но есть и минусы: высокая стоимость (от 200 тысяч рублей), сложность настройки, необходимость в специалистах. Для обычного корпоративного сайта это избыточно.
Программные Firewall на сервере
Это мой основной инструмент для большинства проектов. iptables в Linux, Windows Defender Firewall в Windows Server, ufw в Ubuntu — всё это программные решения, которые работают непосредственно на сервере с сайтом.
# Базовая настройка iptables для веб-сервера
# Разрешаем HTTP и HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Разрешаем SSH только с определённых IP
iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 22 -j ACCEPT
# Защита от DDoS - лимит соединений
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP
# Блокируем все остальные входящие соединения
iptables -P INPUT DROPПрограммные firewall хороши тем, что они бесплатны, гибко настраиваются и не требуют дополнительного оборудования. Но они потребляют ресурсы сервера и могут стать узким местом при высокой нагрузке.
Облачные WAF-сервисы
Cloudflare, AWS WAF, Azure Application Gateway — это облачные решения, которые фильтруют трафик ещё до того, как он дойдёт до вашего сервера. Я использую Cloudflare для 80% своих проектов, и результаты впечатляют.
Например, сайт одного клиента получал 15 Gbps DDoS-атак. Cloudflare поглотил весь этот трафик, а до сервера дошло только 2% легитимных запросов. Сайт продолжал работать как ни в чём не бывало.
Настройка iptables на Linux-сервере
iptables — это стандартный инструмент для управления сетевым трафиком в Linux. За годы работы я выработал определённую методику настройки, которая покрывает 90% случаев.
Сначала всегда проверяю текущие правила:
# Просмотр текущих правил
iptables -L -n -v
# Просмотр правил с номерами строк
iptables -L INPUT --line-numbersПотом создаю базовую защиту. И вот тут важный момент: никогда не начинайте с команды `iptables -P INPUT DROP`, если подключены по SSH. Сначала разрешите SSH, потом уже запрещайте всё остальное.
#!/bin/bash
# Скрипт базовой настройки iptables для веб-сервера
# Очищаем все правила
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
# Разрешаем loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Разрешаем установленные соединения
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH - только с определённых сетей
iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -s 10.0.0.0/8 --dport 22 -j ACCEPT
# HTTP и HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# DNS (если сервер сам делает запросы)
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
# Защита от сканирования портов
iptables -A INPUT -m recent --name portscan --rcheck --seconds 86400 -j DROP
iptables -A FORWARD -m recent --name portscan --rcheck --seconds 86400 -j DROP
# Ограничение количества новых соединений
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 25 -j DROP
iptables -A INPUT -p tcp --dport 443 -m connlimit --connlimit-above 25 -j DROP
# Защита от SYN flood
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
# Блокируем всё остальное
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPTЭтот скрипт я использую как базу для всех проектов. Потом дорабатываю под конкретные нужды: добавляю правила для MySQL (порт 3306), почты (25, 587, 993), FTP и так далее.
Обязательно сохраняю правила, чтобы они восстанавливались после перезагрузки:
# В Ubuntu/Debian
iptables-save > /etc/iptables/rules.v4
# В CentOS/RHEL
service iptables save
# Автозагрузка в systemd
systemctl enable iptablesПродвинутые правила для веб-серверов
Для WordPress и Битрикс я добавляю специальные правила, которые блокируют типичные атаки:
# Блокируем попытки доступа к служебным файлам
iptables -A INPUT -p tcp --dport 80 -m string --string "wp-config.php" --algo bm -j DROP
iptables -A INPUT -p tcp --dport 80 -m string --string ".htaccess" --algo bm -j DROP
iptables -A INPUT -p tcp --dport 80 -m string --string "xmlrpc.php" --algo bm -j DROP
# Защита от SQL-инъекций на уровне сети
iptables -A INPUT -p tcp --dport 80 -m string --string "union select" --algo bm -j DROP
iptables -A INPUT -p tcp --dport 80 -m string --string "drop table" --algo bm -j DROP
# Ограничение частоты запросов с одного IP
iptables -A INPUT -p tcp --dport 80 -m hashlimit --hashlimit-above 50/min --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name http -j DROPНастройка Nginx Firewall-модуля
Nginx — это не только веб-сервер, но и мощный инструмент для фильтрации трафика. Я активно использую встроенные модули для защиты сайтов, и результаты часто превосходят ожидания.
Базовая защита в nginx начинается с правильной настройки лимитов:
# В /etc/nginx/nginx.conf, секция http
# Ограничение частоты запросов
limit_req_zone $binary_remote_addr zone=login:10m rate=1r/m;
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/m;
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
# Ограничение количества соединений
limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
# Размер буферов для защиты от переполнения
client_body_buffer_size 1K;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;
# Таймауты
client_body_timeout 10;
client_header_timeout 10;
keepalive_timeout 5 5;
send_timeout 10;А теперь конфигурация для конкретного сайта:
server {
listen 80;
server_name example.com;
# Применяем лимиты
limit_req zone=general burst=20 nodelay;
limit_conn conn_limit_per_ip 10;
# Блокируем доступ к служебным файлам
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}
# Защита админки WordPress
location /wp-admin/ {
limit_req zone=login burst=2 nodelay;
# Разрешаем доступ только с офисных IP
allow 192.168.1.0/24;
allow 10.0.0.0/8;
deny all;
try_files $uri $uri/ /index.php?$args;
}
# Блокируем xmlrpc.php
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
# API с отдельными лимитами
location /api/ {
limit_req zone=api burst=50 nodelay;
# Дополнительная проверка User-Agent
if ($http_user_agent ~* (bot|crawler|spider|scraper) ) {
return 403;
}
try_files $uri $uri/ /index.php?$args;
}
# Блокируем подозрительные запросы
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444;
}
if ($http_user_agent = "") {
return 444;
}
# Защита от SQL-инъекций в URL
if ($args ~ "union.*select.*\(") {
return 444;
}
if ($args ~ "union.*all.*select.*") {
return 444;
}
if ($query_string ~ "concat.*\(") {
return 444;
}
}У одного клиента была проблема: боты атаковали форму поиска, отправляя по 1000 запросов в минуту. После добавления лимитов нагрузка на MySQL упала в 20 раз, а время отклика сайта улучшилось с 2.5 секунд до 0.3 секунды.
ModSecurity для Nginx
ModSecurity — это WAF-модуль, который превращает nginx в полноценный application firewall. Устанавливаю его практически на всех проектах:
# Установка в Ubuntu 20.04/22.04
apt update
apt install nginx-module-modsecurity
# Загружаем модуль в nginx.conf
load_module modules/ngx_http_modsecurity_module.so;Конфигурация ModSecurity:
# В конфиге сайта
location / {
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
try_files $uri $uri/ /index.php?$args;
}И файл правил `/etc/nginx/modsec/main.conf`:
# Базовая конфигурация ModSecurity
SecRuleEngine On
SecAuditEngine RelevantOnly
SecAuditLog /var/log/nginx/modsec_audit.log
# Защита от XSS
SecRule ARGS "@detectXSS" \
"id:1001,\
phase:2,\
block,\
msg:'XSS Attack Detected',\
logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}'"
# Защита от SQL-инъекций
SecRule ARGS "@detectSQLi" \
"id:1002,\
phase:2,\
block,\
msg:'SQL Injection Attack Detected'"
# Блокируем загрузку исполняемых файлов
SecRule FILES_NAMES "@endsWith .exe" \
"id:1003,\
phase:2,\
block,\
msg:'Executable file upload blocked'"Облачные WAF-сервисы: Cloudflare и AWS
Облачные WAF — это мой фаворит для большинства проектов. Они работают как прокси между пользователями и вашим сервером, фильтруя весь трафик в облаке.
Настройка Cloudflare WAF
Cloudflare я использую в 80% проектов. Бесплатный план покрывает базовые потребности, а Pro за $20/месяц даёт серьёзные возможности.
Базовая настройка в Cloudflare:
- Security Level — ставлю "High" для большинства сайтов
- Challenge Passage — 30 минут (пользователь не будет видеть капчу полчаса после прохождения)
- Browser Integrity Check — включён (блокирует запросы без правильных заголовков браузера)
Кастомные правила WAF, которые я настраиваю для каждого проекта:
// Блокируем известные вредоносные IP
(ip.src in $bad_ips)
// Защита админки
(http.request.uri.path contains "/wp-admin" and ip.src ne 192.168.1.100)
// Блокируем боты без User-Agent
(http.user_agent eq "")
// Защита от SQL-инъекций
(http.request.uri.query contains "union select" or
http.request.uri.query contains "drop table" or
any(http.request.body.form.values[*] contains "' or 1=1"))
// Лимит частоты запросов
(rate(1m) > 100)Rate Limiting в Cloudflare настраиваю так:
- Общие страницы: 300 запросов за 5 минут с одного IP
- API endpoints: 1000 запросов за 10 минут
- Формы входа: 5 попыток за час
AWS WAF для серьёзных проектов
AWS WAF я использую для корпоративных проектов с высокими требованиями к безопасности. Он дороже Cloudflare, но даёт больше контроля.
Пример конфигурации через AWS CLI:
# Создаём Web ACL
aws wafv2 create-web-acl \
--name "WebsiteProtection" \
--scope CLOUDFRONT \
--default-action Allow={} \
--rules file://waf-rules.json \
--region us-east-1Файл правил `waf-rules.json`:
[
{
"Name": "AWSManagedRulesCommonRuleSet",
"Priority": 1,
"OverrideAction": {
"None": {}
},
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesCommonRuleSet"
}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "CommonRuleSetMetric"
}
},
{
"Name": "RateLimitRule",
"Priority": 2,
"Action": {
"Block": {}
},
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitMetric"
}
}
]AWS WAF хорош тем, что интегрируется с CloudFront, Application Load Balancer и API Gateway. Для одного клиента я настроил защиту API, которое обрабатывает платежи — WAF блокирует 99.7% вредоносных запросов, пропуская только легитимный трафик.
Специфичная защита для WordPress и Битрикс
У каждой CMS свои уязвимости и особенности. За годы работы с WordPress и Битрикс я выработал специальные подходы к их защите.
Firewall для WordPress
WordPress — самая атакуемая CMS в мире. 90% атак идут через стандартные векторы: xmlrpc.php, wp-login.php, устаревшие плагины.
Мой стандартный набор правил для WordPress в .htaccess:
# Защита .htaccess и wp-config.php
Order allow,deny
Deny from all
Satisfy all
Order allow,deny
Deny from all
# Блокируем xmlrpc.php
Order allow,deny
Deny from all
# Защита wp-admin от брутфорса
# Разрешаем доступ только с офисных IP
Order deny,allow
Deny from all
Allow from 192.168.1.0/24
Allow from 10.0.0.0/8
# Блокируем доступ к debug.log
Order allow,deny
Deny from all
# Защита от сканирования плагинов
RewriteEngine On
RewriteCond %{REQUEST_URI} /wp-content/plugins/
RewriteCond %{REQUEST_URI} !.*\.(css|js|png|jpg|gif|ico)$
RewriteRule ^.*$ - [R=403,L]
# Блокируем подозрительные User-Agent
RewriteCond %{HTTP_USER_AGENT} (libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC]
RewriteRule ^(.*)$ - [F,L]
# Защита от SQL-инъекций
RewriteCond %{QUERY_STRING} union.*select.*\( [NC,OR]
RewriteCond %{QUERY_STRING} union.*all.*select.* [NC,OR]
RewriteCond %{QUERY_STRING} concat.*\( [NC]
RewriteRule ^(.*)$ - [F,L]Для WordPress я обязательно устанавливаю Wordfence или Sucuri Security. Wordfence имеет встроенный firewall, который работает на уровне PHP до загрузки WordPress. Это позволяет блокировать атаки, не тратя ресурсы на инициализацию CMS.
У одного клиента Wordfence блокирует 15-20 тысяч атак в день. Без него сайт просто не выдержал бы такой нагрузки.
Защита Битрикс
Битрикс имеет встроенный модуль "Проактивная защита", но его нужно правильно настроить. Я всегда дополняю его серверными правилами.
Настройка в nginx для Битрикс:
server {
listen 80;
server_name bitrix-site.ru;
# Блокируем доступ к служебным директориям
location ~* ^/(bitrix/modules|bitrix/php_interface|bitrix/stack_cache) {
deny all;
}
# Защита системных файлов
location ~* /\.ht {
deny all;
}
location ~* \.(log|txt|tar|gz|bak|backup|old)$ {
deny all;
}
# Специальная защита для /bitrix/admin/
location /bitrix/admin/ {
# Ограничиваем по IP
allow 192.168.1.0/24;
deny all;
# Дополнительные лимиты
limit_req zone=login burst=3 nodelay;
# Проксируем в PHP
try_files $uri $uri/ @bitrix;
}
# Блокируем прямое обращение к PHP в upload
location /upload/ {
location ~* \.php$ {
return 403;
}
}
# Защита от выполнения скриптов в кеше
location /bitrix/cache/ {
location ~* \.php$ {
return 403;
}
}
}В самом Битрикс обязательно включаю:
- Проактивную защиту с уровнем "Высокий"
- Контроль активности для отслеживания подозрительных действий
- Двухфакторную аутентификацию для всех администраторов
- Блокировку IP после 3 неудачных попыток входа
Мониторинг и аналитика Firewall-логов
Настроить firewall — это половина дела. Вторая половина — это постоянный мониторинг и анализ логов. Без этого вы работаете вслепую.
Я использую несколько уровней мониторинга:
Системные логи iptables
Настраиваю логирование заблокированных пакетов:
# Добавляем правило логирования перед DROP
iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
# Смотрим логи в реальном времени
tail -f /var/log/syslog | grep "iptables denied"
# Анализируем самые частые атаки
grep "iptables denied" /var/log/syslog | awk '{print $13}' | sort | uniq -c | sort -nr | head -20Этот простой анализ показывает, какие IP чаще всего пытаются атаковать сервер. У одного клиента таким образом обнаружили ботнет из 500+ IP, которые сканировали порт 22.
Анализ логов nginx
Создаю специальный формат логов для анализа атак:
# В nginx.conf
log_format security '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'$request_time $upstream_response_time';
# В конфиге сайта
access_log /var/log/nginx/security.log security;Скрипт для анализа подозрительной активности:
#!/bin/bash
# analyze_attacks.sh
LOG_FILE="/var/log/nginx/security.log"
TODAY=$(date +"%d/%b/%Y")
echo "=== Анализ атак за $TODAY ==="
# Топ IP по количеству 403 ошибок
echo "Топ источников 403 ошибок:"
grep "$TODAY" $LOG_FILE | grep " 403 " | awk '{print $1}' | sort | uniq -c | sort -nr | head -10
# Попытки доступа к wp-admin
echo -e "\nПопытки доступа к wp-admin:"
grep "$TODAY" $LOG_FILE | grep "wp-admin" | grep " 403 " | wc -l
# Подозрительные User-Agent
echo -e "\nПодозрительные User-Agent:"
grep "$TODAY" $LOG_FILE | grep -E "(bot|crawl|scan)" | awk -F'"' '{print $6}' | sort | uniq -c | sort -nr
# SQL-инъекции в URL
echo -e "\nПопытки SQL-инъекций:"
grep "$TODAY" $LOG_FILE | grep -E "(union|select|drop|insert)" | wc -lНастройка алертов
Использую простой скрипт для отправки уведомлений при массовых атаках:
#!/bin/bash
# firewall_alerts.sh
THRESHOLD=100
LOG_FILE="/var/log/nginx/access.log"
LAST_HOUR=$(date -d '1 hour ago' +"%d/%b/%Y:%H")
# Подсчитываем 403 ошибки за последний час
BLOCKED_COUNT=$(grep "$LAST_HOUR" $LOG_FILE | grep " 403 " | wc -l)
if [ $BLOCKED_COUNT -gt $THRESHOLD ]; then
# Отправляем уведомление в Telegram
curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
-d chat_id="$CHAT_ID" \
-d text="🚨 Обнаружена атака на сайт! Заблокировано $BLOCKED_COUNT запросов за час"
# Или отправляем email
echo "Обнаружена атака. Заблокировано $BLOCKED_COUNT запросов" | \
mail -s "Security Alert" admin@example.com
fiЗапускаю этот скрипт через cron каждые 15 минут. Помогает быстро реагировать на крупные атаки.
Тестирование и оптимизация правил Firewall
Самая частая ошибка при настройке firewall — это отсутствие тестирования. Я видел случаи, когда неправильные правила блокировали поисковых ботов или CDN, что приводило к падению позиций в поисковиках и проблемам с производительностью.
Методика тестирования
Всегда тестирую firewall по следующему алгоритму:
- Функциональное тестирование — проверяю, что сайт работает корректно для обычных пользователей
- Тестирование ложных срабатываний — убеждаюсь, что легитимный трафик не блокируется
- Тестирование эффективности — проверяю, что атаки действительно блокируются
- Нагрузочное тестирование — смотрю, как правила влияют на производительность
Для тестирования использую несколько инструментов:
# Тест доступности основных страниц
curl -I http://example.com/
curl -I http://example.com/about/
curl -I http://example.com/contact/
# Проверка времени отклика с правилами и без
time curl -s http://example.com/ > /dev/null
# Тест различных User-Agent
curl -H "User-Agent: Mozilla/5.0" http://example.com/
curl -H "User-Agent: bot" http://example.com/
# Проверка блокировки подозрительных запросов
curl "http://example.com/?id=1' OR 1=1"
curl -X POST http://example.com/ -d "data="Оптимизация производительности
Firewall может существенно влиять на производительность сайта. У одного клиента 200+ правил ModSecurity увеличили время отклика с 80ms до 400ms.
Мои принципы оптимизации:
- Порядок правил имеет значение — самые частые проверки должны быть первыми
- Используйте whitelist вместо blacklist — проще поддерживать и быстрее работает
- Избегайте регулярных выражений в критичных по производительности местах
- Кешируйте результаты проверок — не проверяйте один IP несколько раз подряд
Пример оптимизированной конфигурации nginx:
# Быстрые проверки в начале
if ($request_method !~ ^(GET|HEAD|POST)$) {
return 444;
}
# Кешируем результаты geo-блокировки
geo $blocked_country {
default 0;
CN 1; # Китай
RU 0; # Россия разрешена
}
if ($blocked_country) {
return 403;
}
# Эффективная защита от ботов
map $http_user_agent $bot_blocked {
default 0;
~*bot 1;
~*crawler 1;
~*spider 1;
}
if ($bot_blocked) {
return 403;
}A/B тестирование правил
Для крупных проектов я провожу A/B тестирование firewall-правил. Например, тестирую разные уровни строгости блокировки и смотрю на влияние на конверсию.
У одного интернет-магазина слишком агрессивные правила блокировали 5% легитимных пользователей, что привело к потере 50 тысяч рублей в день. После ослабления правил конверсия восстановилась, а количество атак снизилось всего на 10%.
Частые ошибки при настройке Firewall
За 10+ лет я видел десятки типичных ошибок, которые могут полностью "уронить" сайт или сделать его уязвимым. Расскажу про самые критичные.
Блокировка самого себя
Классика жанра — настроил правила, потерял доступ к серверу. Было у меня несколько таких случаев в начале карьеры.
Как избежать:
- Всегда тестируйте с запасным подключением — держите открытой вторую SSH-сессию
- Используйте whitelist для своих IP — добавьте свой офисный IP в исключения
- Настройте автоочистку правил — через cron удаляйте временные блокировки
# Скрипт автоочистки - запускается каждый час
#!/bin/bash
# cleanup_firewall.sh
# Удаляем временные блокировки старше 24 часов
iptables -L INPUT -n --line-numbers | grep "temp_block" | \
while read line_num rest; do
iptables -D INPUT $line_num
done
# Проверяем доступность SSH с офисного IP
if ! nc -z 192.168.1.100 22; then
# Если SSH недоступен, добавляем экстренное правило
iptables -I INPUT 1 -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT
fiИгнорирование CDN и прокси
Часто забывают, что при использовании Cloudflare или других CDN настоящий IP пользователя приходит в заголовке X-Forwarded-For или CF-Connecting-IP.
Неправильная настройка nginx:
# НЕПРАВИЛЬНО - блокируем IP Cloudflare, а не пользователя
limit_req_zone $remote_addr zone=api:10m rate=100r/m;Правильная настройка:
# ПРАВИЛЬНО - используем реальный IP пользователя
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... другие диапазоны Cloudflare
real_ip_header CF-Connecting-IP;
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/m;Слишком агрессивная блокировка ботов
Блокировка всех ботов подряд — это путь к катастрофе. Поисковые боты, мониторинги, легитимные API-клиенты — всё это может попасть под раздачу.
У одного клиента заблокировали Googlebot, и за неделю органический трафик упал на 60%. Пришлось месяц восстанавливать позиции.
Правильный подход — whitelist для известных ботов:
# Разрешаем поисковых ботов
if ($http_user_agent ~* (googlebot|bingbot|yandexbot|slurp)) {
set $allowed_bot 1;
}
# Блокируем остальных ботов
if ($http_user_agent ~* (bot|crawler|spider)) {
set $blocked_bot 1;
}
if ($blocked_bot = 1) {
set $test "${allowed_bot}${blocked_bot}";
}
if ($test = "1") {
return 403;
}Отсутствие мониторинга false positive
Настроили firewall и забыли про него — типичная ошибка. Правила могут блокировать легитимных пользователей, и вы об этом не узнаете.
Обязательно настраиваю еженедельные отчёты:
#!/bin/bash
# weekly_firewall_report.sh
echo "=== Отчёт Firewall за неделю ===" > /tmp/firewall_report.txt
# Топ заблокированных IP
echo "Топ 20 заблокированных IP:" >> /tmp/firewall_report.txt
grep "$(date -d '7 days ago' +%Y-%m-%d)" /var/log/nginx/access.log | \
grep " 403 " | awk '{print $1}' | sort | uniq -c | sort -nr | head -20 >> /tmp/firewall_report.txt
# Проверяем блокировку известных сервисов
echo -e "\nБлокировка известных сервисов:" >> /tmp/firewall_report.txt
grep "Googlebot\|Bingbot\|YandexBot" /var/log/nginx/access.log | grep " 403 " | wc -l >> /tmp/firewall_report.txt
# Отправляем отчёт
mail -s "Weekly Firewall Report" admin@example.com < /tmp/firewall_report.txtЭти отчёты помогли выявить множество проблем: от блокировки корпоративных прокси до ложных срабатываний на API-запросы.
Firewall — это не "поставил и забыл". Это живой инструмент, который требует постоянного внимания и настройки. Но при правильном подходе он может защитить ваш сайт от 99% атак и существенно снизить нагрузку на сервер. А если вам нужна помощь с настройкой безопасности, техническая поддержка всегда готова помочь с любыми задачами.
Нужна помощь в настройке защиты сайта?
Обратитесь к нашим экспертам для профессиональной настройки firewall и комплексной защиты вашего веб-ресурса.