Механизмы защиты и усиления безопасности веб‑серверов Nginx и Apache
Веб‑сервер — одна из наиболее критических точек в инфраструктуре любой организации. Именно он отвечает за прием и обработку HTTP‑запросов, взаимодействие с приложениями и передачу данных пользователям. Любая ошибка в его конфигурации может привести к компрометации системы, утечке информации или отказу в обслуживании.
Наиболее широко в Linux-средах используются Nginx и Apache HTTP Server. Первый существует больше 20 лет, он стал стандартом для высоконагруженных и облачных систем благодаря своей легкости, производительности и возможностям обратного проксирования. У второго еще более многолетняя история, гибкая модульная архитектура и обширные возможности. Появившийся еще в 1995 году, Apache до сих пор используется в миллионах инсталляций.
Чтобы снизить риски, организации используют комплексный подход к защите. Прежде всего, речь о харденинге веб‑сервера — настройке конфигурации таким образом, чтобы минимизировать поверхность атаки и исключить наиболее распространенные векторы атак. Кроме того, применяют современные решения класса web application firewall (например, BI.ZONE WAF), которые позволяют защитить веб‑приложения от целого спектра атак, включая SQL‑инъекции, XSS и эксплоиты бизнес-логики. Но даже этого недостаточно, если злоумышленнику удастся проникнуть глубже в инфраструктуру. В этом случае на помощь приходят решения класса EDR. Так, BI.ZONE EDR обеспечивает контроль активности конечных точек, выявление подозрительных процессов и предотвращение развития атак внутри корпоративной сети.
В этой статье рассмотрим основные риски, связанные с использованием Apache и Nginx, и опишем практики их харденинга — от минимизации поверхности атаки и настройки TLS до организации журналирования и интеграции с системами безопасности. А также покажем, как BI.ZONE EDR помогает в поиске мисконфигураций, которые могут позволить злоумышленнику получить доступ к веб‑серверу.
Nginx — это высокопроизводительный веб‑сервер и обратный прокси-сервер, который также может выполнять функции балансировщика нагрузки, кеширующего прокси и почтового прокси. Благодаря событийно-ориентированной архитектуре Nginx обрабатывает соединения с высокой скоростью и потребляет мало ресурсов. Это сделало его одним из наиболее популярных решений для обслуживания веб‑приложений.
Основные задачи Nginx:
- Обслуживание статического контента (HTML, CSS, изображения, файлы).
- Обратное проксирование и балансировка нагрузки.
- Завершение TLS‑сессий (TLS termination).
- Кеширование ответов приложений.
- Использование в качестве Ingress Controller в Kubernetes.
Наиболее простой способ развернуть Nginx на Linux — использовать пакетный менеджер дистрибутива.
Debian/Ubuntu:
sudo apt update sudo apt install nginx -y sudo systemctl enable nginx sudo systemctl start nginx
RHEL/CentOS:
sudo dnf install epel-release -y sudo dnf install nginx -y sudo systemctl enable nginx sudo systemctl start nginx
После запуска сервис будет доступен по умолчанию на порте 80.
Файл конфигурации Nginx по умолчанию находится в /etc/nginx/nginx.conf, а виртуальные хосты — в /etc/nginx/sites-available/.
Пример простейшего виртуального хоста:
server {
listen 80; # Слушаем порт 80 (HTTP)
server_name example.com; # Имя виртуального хоста (доменное имя)
root /var/www/html; # Корневая директория сайта
index index.html; # Файл по умолчанию (открывается при запросе / )
location / {
try_files $uri $uri/ =404; # Проверяем: существует ли файл → директория → иначе возвращаем 404
}
}
После внесения изменений нужно проверить конфигурацию и перезапустить сервер:
sudo nginx -t
sudo systemctl reload nginx
После того как Nginx развернут, можно перейти к его настройке и поиску мисконфигураций.
Ограничение доступа к определенным ресурсам — один из самых простых и эффективных способов повысить безопасность веб‑сервера. К таким ресурсам относятся административные панели, служебные каталоги, внутренние API, файлы конфигурации, которые не должны быть доступны публично.
В Nginx контроль доступа реализуется через директивы allow и deny, которые задаются внутри блока location.
Ограничение доступа к административному разделу:
location /admin {
allow 192.168.0.1; # Разрешён доступ только для этого IP
deny all; # Всем остальным доступ запрещён
}
В этом примере доступ к /admin получит только хост с IP‑адресом 192.168.0.1. Любой другой запрос вернет ошибку 403 Forbidden. Такой подход часто используется для изоляции административных интерфейсов (например, phpMyAdmin или собственной панели управления). Таким образом, использование IP‑блокировок и ограничений по путям помогает уменьшить поверхность атаки и предотвращает случайное раскрытие критически важных данных.
Еще один эффективный прием защиты веб‑сервера — ограничение частоты запросов от одного клиента. Эта мера помогает одновременно в двух случаях:
- предотвращает атаки методом подбора паролей (брутфорс), когда злоумышленник пытается перебрать учетные данные через форму авторизации;
- снижает риск перегрузки сервера в рамках DoS-/DDoS‑атак, когда один или несколько источников посылают слишком много запросов за короткий промежуток времени.
В Nginx для этого используется механизм limit_req_zone и limit_req. Он создает общий «пул» (shared memory zone) для хранения состояния по клиентам и позволяет ограничить количество запросов в секунду.
http {
limit_req_zone $binary_remote_addr zone=sql:10m rate=1r/s;
location / {
limit_req zone=sql burst=5;
}
}
Таким образом, если злоумышленник попытается отправить сотни запросов подряд (например, к /login), Nginx будет возвращать код 503 Service Unavailable, эффективно ограничивая его возможности. Важно помнить, что rate limiting не заменяет полноценную защиту от распределенных атак, но это хорошая «первая линия обороны», которая снижает нагрузку на бэкенд и защищает чувствительные точки веб‑приложения от агрессивного перебора. Однако использовать этот параметр нужно осторожно, потому что можно ограничить и легитимные запросы к серверу.
С помощью BI.ZONE EDR можно найти Nginx, на котором не заданы лимиты:
HTTP‑заголовки безопасности помогают защитить пользователей от XSSadd_header в блоках server или location.
Например, параметр X-Frame-Options используется для защиты от clickjacking.
Настройка защиты от clickjacking разрешает открывать страницы в iframe только в рамках собственного домена:
add_header X-Frame-Options "SAMEORIGIN";
Параметр X-Content-Type-Options предотвращает загрузку вредоносного контента, запрещая браузеру «угадывать» MIME‑тип:
add_header X-Content-Type-Options "nosniff";
Для защиты от XSS в старых браузерах применяется X-XSS-Protection:
add_header X-XSS-Protection "1; mode=block";
Такой заголовок блокирует страницу при обнаружении подозрительного скрипта.
Корректная настройка этих параметров снижает риски атак и является частью харденинга Nginx. Проверить, какие заголовки реально используются в конфигурации, можно с помощью BI.ZONE EDR:
На веб‑сервере могут храниться не только публичные ресурсы (HTML, CSS, изображения), но и внутренние служебные файлы или каталоги, которые никогда не должны быть доступны из интернета. Речь идет, например, о конфигурациях, файлах версионирования или временных данных приложений. Если такие файлы окажутся открытыми, злоумышленник сможет получить критически важную информацию: структуру проекта, настройки базы данных, токены или пароли.
В Nginx для защиты таких объектов используется блокировка доступа по регулярным выражениям:
location ~ /\.(ht|git|svn|env) {
deny all;
}
Или блокировка любых обращений ко всем скрытым файлам и каталогам, которые могут содержать чувствительные данные (ключи доступа, пароли, резервные копии):
location ~ /\. {
deny all;
}
Защита конфиденциальных файлов и директорий — обязательная часть харденинга: она предотвращает утечки исходного кода и секретов, которые в противном случае могли бы стать удобной точкой входа для злоумышленника.
Каталоги загрузки — одно из самых уязвимых мест веб‑приложений. Пользователи могут загружать файлы, которые на первый взгляд кажутся безопасными (например, изображения), но злоумышленник может попытаться загрузить PHP‑скрипт, Perl-скрипт или другой исполняемый файл, чтобы получить доступ к серверу. Если Nginx будет обрабатывать такие файлы как исполняемые, это приведет к полной компрометации сервера.
Настраивайте блоки location, используя запрет на обработку скриптов в каталогах, где файлы не должны исполняться:
location /uploads {
# Отключаем выполнение PHP-скриптов
location ~ \.php$ {
return 403;
}
# Можно также отключить другие типы исполняемых файлов
location ~ \.(pl|py|sh|exe)$ {
return 403;
}
}
Ни один процесс харденинга не будет эффективным без мониторинга. Даже самые надежные настройки не гарантируют, что сервер не станет целью атак. Подробные журналы позволяют отслеживать происходящее и вовремя реагировать на подозрительные активности.
В Nginx есть два основных типа журналов:
access_log— фиксирует все запросы к серверу (клиентский IP, URL, метод, код ответа, размер ответа,User-Agentи т. д.).error_log— записывает ошибки сервера, включая проблемы с конфигурацией, отказы SSL, попытки доступа к запрещенным ресурсам и другие сбои.
Пример настройки журналов в nginx.conf:
http {
# Журнал запросов
access_log /var/log/nginx/access_bizone.log bizone;
# Журнал ошибок
error_log /var/log/nginx/error.log warn;
# Формат записи для access_log
log_format bizone 'LEEF:1.0|NGINX|NGINX|$nginx_version|$status| dev_time=$time_iso8601 site=$server_name server=$host src_ip=$remote_addr src_realip=$realip_remote_addr dst_ip=$server_addr dst_port=$server_port proto=$server_protocol user=$remote_user request_time=$request_time request_method=$request_method request_uri=$request_uri uri_query=$query_string uri_path=$uri body_bytes_sent=$body_bytes_sent http_referer=$http_referer http_user_agent=$http_user_agent http_x_header=$http_x_header http_x_forwarded_for=$http_x_forwarded_for upstream_addr=$upstream_addr upstream_status=$upstream_status upstream_response_time=$upstream_response_time';
}
Зачем это нужно для безопасности:
- Логи позволяют выявить подозрительные действия: большое количество ошибок 404 или 403 от одного IP‑адреса, попытки подбора паролей, сканирование директорий.
- Помогают обнаружить атаки DoS/DDoS — резкий всплеск количества запросов с одного или нескольких IP‑адресов.
- Дают возможность отслеживать эксплуатацию уязвимостей (например, массовые запросы к PHP‑файлам в Nginx без PHP).
Таким образом, правильно настроенные журналы — это не только инструмент диагностики, но и ключевой элемент безопасности: они помогают вовремя выявить атаки и минимизировать их последствия.
Правильная настройка прав доступа к файлам и каталогам Nginx — ключевой элемент харденинга. Даже если сервер полностью обновлен и защищен, неправильно настроенные права позволят злоумышленнику получить доступ к конфигурации и веб‑контенту:
chown -R nginx:nginx /etc/nginx
chown -R nginx:nginx /var/www/html
Также стоит ограничивать права доступа к каталогу и конфигурации Nginx:
chmod -R 750 /etc/nginx
chmod 640 /etc/nginx/nginx.conf
BI.ZONE EDR определяет, какие права доступа у конфигурации и контента, а также какой пользователь является владельцем файлов:
Даже при строгой настройке безопасности и харденинге Nginx невозможно полностью исключить риск потери данных — из‑за сбоев оборудования, человеческой ошибки или вредоносной активности. Резервное копирование позволяет быстро восстановить работоспособность сервера и минимизировать последствия инцидентов.
Рекомендуем настроить резервное копирование для следующих типов файлов:
1. Конфигурационные файлы Nginx:
- основной конфиг:
/etc/nginx/nginx.conf; - файлы виртуальных хостов:
/etc/nginx/sites-available/и/etc/nginx/sites-enabled/; - дополнительные включаемые файлы, модули, SSL-/TLS‑сертификаты, правила ModSecurity или WAF.
2. Веб‑контент и статические файлы:
- каталог с веб‑приложением (
/var/www/html/или кастомный путь); - файлы медиа, загрузки пользователей, бэкапы баз данных (если они хранятся локально).
3. Дополнительные компоненты: скрипты автоматизации, cron‑задачи, SSL‑ключи, системные настройки безопасности, если они влияют на работу веб‑сервера.
Часто при работе с Nginx проблемы связаны не с уязвимостями самого сервера, а с ошибками конфигурации. К распространенным примерам относятся доступ к служебным файлам вроде .git или .env, включенный листинг директорий, использование устаревших версий TLS, а также отсутствие заголовков безопасности. Подобные мисконфигурации делают систему уязвимой для утечек данных и повышают вероятность успешной атаки.
Чтобы минимизировать риски, важно отключать ненужные модули, запускать сервер с минимальными правами, ограничивать допустимые HTTP‑методы, корректно настраивать TLS и добавлять заголовки, предотвращающие выполнение нежелательных сценариев на стороне клиента. Дополнительно стоит использовать лимиты на соединения и частоту запросов для защиты от перегрузки, а также обеспечивать централизованное логирование и мониторинг.
Оптимальный подход к харденингу Nginx подразумевает не только применение отдельных настроек, но и регулярную проверку конфигурации.
Apache HTTP Server (httpd) — один из старейших и самых популярных веб‑серверов. Долгое время он был де‑факто стандартом в веб‑инфраструктуре и до сих пор используется во множестве проектов. Его ключевая особенность — модульная архитектура: функциональность можно расширять за счет подключения модулей (например, для TLS, переписывания URL, аутентификации, проксирования).
Основные возможности Apache:
- Обслуживание статического контента (HTML, изображения, файлы).
- Динамические приложения через модули (
mod_php,mod_wsgiи др.). - Поддержка виртуальных хостов.
- Гибкая система управления доступом (через конфиг или
.htaccess). - Расширяемость за счет модулей.
Debian/Ubuntu:
sudo apt update
sudo apt install apache2 -y
sudo systemctl enable apache2
sudo systemctl start apache2
RHEL/CentOS:
sudo dnf install httpd -y
sudo systemctl enable httpd
sudo systemctl start httpd
После запуска Apache будет слушать порт 80.
Конфигурация Apache хранится:
- в
/etc/apache2/apache2.conf— основной конфиг (Debian/Ubuntu); - в
/etc/httpd/conf/httpd.conf— основной конфиг (RHEL/CentOS); - на виртуальных хостах:
/etc/apache2/sites-available/(Debian/Ubuntu); - на виртуальных хостах: создаются отдельные CONF‑файлы в
/etc/httpd/conf.d/(RHEL/CentOS).
Простейший виртуальный хост:
<VirtualHost *:80>
ServerName example.com # Имя сайта
DocumentRoot /var/www/html # Корень сайта
<Directory /var/www/html>
Options -Indexes # Запрещаем листинг каталогов
AllowOverride None # Запрещаем .htaccess
Require all granted # Разрешаем доступ всем
</Directory>
DirectoryIndex index.html # Файл по умолчанию
</VirtualHost>
После внесения изменений проверьте конфигурацию и перезапустите сервер:
sudo apachectl configtest # Проверка конфигурации
sudo systemctl reload apache2 # (или httpd) Перезагрузка без остановки
После того как Apache развернут, можно перейти к его настройке и поиску мисконфигураций.
По умолчанию Apache выводит содержимое директорий, если в них отсутствуют индексные файлы вроде index.html или index.php: браузер получает сгенерированный список всех файлов и подпапок в каталоге. Это представляет серьезную угрозу безопасности — злоумышленник получает удобную карту структуры приложения, может обнаружить и скачать резервные копии, временные файлы или административные скрипты. А также значительно упрощается поиск уязвимостей и их дальнейшая эксплуатация. Чтобы предотвратить подобные риски, отключите листинг каталогов.
В основном конфигурационном файле (httpd.conf или apache2.conf) либо в файле виртуального хоста (/etc/apache2/sites-available/*.conf в Debian/Ubuntu, /etc/httpd/conf.d/*.conf в RHEL/CentOS) добавьте или измените параметр:
<Directory /var/www/html>
Options -Indexes
</Directory>
Отключение листинга каталогов — простая, но важная мера безопасности, которая предотвратит раскрытие информации о структуре сайта и файлах. Вместе с другими настройками (например, сокрытием версии сервера) это значительно уменьшает поверхность атаки. С помощью BI.ZONE EDR можно получить данные об отключенном или включенном листинге каталогов в Apache:
Apache предоставляет специальные служебные каталоги, такие как /server-status и /server-info, которые используются для мониторинга и отладки работы сервера. Через них администратор может получить информацию о количестве активных соединений, обработанных запросах, загруженных модулях и конфигурации сервера. Но, если эти страницы остаются доступными из внешней сети, злоумышленник получает сведения о внутреннем устройстве системы, которые могут быть использованы для подготовки атак. Именно поэтому защита подобных ресурсов — одна из первоочередных задач при настройке веб‑сервера.
Доступ к этим каталогам лучше жестко ограничить. Сделать это можно с помощью директивы <Location>, задав разрешение только для доверенных хостов или IP‑адресов. В итоге служебная информация будет доступна исключительно администраторам внутри корпоративной сети. При необходимости можно дополнительно применить базовую аутентификацию: даже если злоумышленнику удастся попасть в доверенный сегмент, ему все равно потребуется имя пользователя и пароль.
<Location "/server-status">
Require ip 192.168.0.0/24
AuthType Basic
AuthName "Server status"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
</Location>
<Location "/server-info">
Require ip 192.168.0.0/24
AuthType Basic
AuthName "Server info"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
</Location>
Таким образом, страницы /server-status и /server-info необходимо рассматривать как конфиденциальные зоны веб‑сервера. Их защита должна быть реализована так же строго, как и у административных интерфейсов, чтобы исключить риск раскрытия критически важной информации.
Одна из возможных угроз для веб‑сервера — атаки, основанные на отправке слишком больших запросов. Злоумышленники могут использовать огромные заголовки или тела HTTP‑запросов, чтобы перегрузить сервер, вызвать переполнение буфера или потреблять ресурсы системы до тех пор, пока она не станет недоступной для легитимных пользователей. Чтобы минимизировать такие риски, в Apache предусмотрена директива LimitRequestBody, которая позволяет задавать максимально допустимый размер тела клиентского запроса.
По умолчанию сервер может принимать достаточно большие запросы, что оправдано в случаях загрузки файлов пользователями. Однако, если на сайте нет функциональности загрузки или максимальный размер передаваемых данных известен заранее, лучше жестко ограничить этот параметр. Например, можно разрешить не более 100 КБ для тела запроса — этого будет достаточно для большинства форм и текстовых данных, но исключит возможность загрузки чрезмерно больших файлов.
Эта директива может указываться как на уровне всего сервера (в файле httpd.conf или apache2.conf), так и в пределах отдельного <Directory>, <Location> или <VirtualHost>. Это удобно в ситуациях, когда для разных ресурсов сайта нужны разные лимиты. Например, для административного интерфейса можно задать минимальное ограничение, а для каталога загрузки файлов — более высокое:
<VirtualHost *:80>
ServerName example.com
# Ограничение для всего сайта — 100 КБ
LimitRequestBody 102400
<Directory "/var/www/uploads">
# Для каталога загрузки увеличиваем лимит до 10 МБ
LimitRequestBody 10485760
</Directory>
</VirtualHost>
Директива LimitRequestBody — простая, но эффективная мера защиты от атак переполнения и злоупотребления ресурсами. Она позволяет более гибко управлять безопасностью, уменьшая поверхность атаки и лишая возможности перегружать сервер слишком большими запросами.
С помощью BI.ZONE EDR можно детектировать настроенные лимиты запросов к веб‑серверу Apache:
По умолчанию Apache при возникновении ошибок, таких как 404 Not Found или 500 Internal Server Error, отображает стандартные системные страницы. Эти страницы могут содержать технические подробности о сервере или структуре веб‑приложения. Злоумышленники иногда используют такую информацию для поиска уязвимостей или подготовки целевых атак. Например, сообщение о 500‑й ошибке может раскрыть версию Apache или внутренние пути в файловой системе.
Чтобы избежать раскрытия лишних сведений и одновременно сделать сайт более удобным для пользователей, настройте собственные страницы ошибок. Это можно сделать с помощью директивы ErrorDocument, которая позволяет задать путь к пользовательскому HTML‑документу или перенаправление на другой ресурс.
# Пользовательская страница для ошибки 404 (страница не найдена)
ErrorDocument 404 /custom404.html
# Пользовательская страница для ошибки 500 (внутренняя ошибка сервера)
ErrorDocument 500 /custom500.html
В этом случае при возникновении ошибки сервер не покажет пользователю стандартный ответ Apache, а отобразит подготовленную страницу. Это не только снижает вероятность раскрытия технической информации, но и улучшает пользовательский опыт: можно оформить такие страницы в фирменном стиле и подсказать пользователю дальнейшие действия (например, вернуться на главную страницу).
BI.ZONE EDR дает возможность отслеживать настройки директивы ErrorDocument:
Мониторинг — одна из важнейших функций Apache, которая не только помогает в отладке и администрировании, но и играет существенную роль в обеспечении безопасности. Анализ журналов позволяет выявлять попытки атак, необычную активность пользователей, а также оперативно реагировать на инциденты.
Apache поддерживает два основных типа журналов:
- журнал ошибок (ErrorLog) — фиксирует внутренние ошибки веб‑сервера, проблемы с доступом к файлам, сбои в модулях и критические события;
- журнал доступа (AccessLog) — регистрирует все HTTP‑запросы клиентов с деталями: IP‑адрес, используемый метод, URL, код ответа, размер ответа и др.
Все настройки логирования выполняются в основных конфигурационных файлах (httpd.conf, apache2.conf) или внутри виртуальных хостов (/etc/apache2/sites-available/*.conf на Debian/Ubuntu, /etc/httpd/conf.d/*.conf на RHEL/CentOS).
Для настройки логирования в файл httpd.conf, расположенный в каталоге /etc/apache2, нужно добавить вне секции <VirtualHost> строки для настройки формата и метода отправки событий:
LogFormat "%h \"%{X-Forwarded-For}i\" %A %p %u %f %t %m %V %U \"%q\" %H %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" tosiem
ErrorLogFormat "[%t] [%l] [pid %P] [client\ %a] %M% , \"%{Referer}i\""
Для интеграции с SIEM‑системами надо указать уровень важности регистрируемых событий info и категорию объектов стандарта syslog:
LogLevel info
ErrorLog syslog:local4
Для каждой секции <VirtualHost> файла httpd.conf последовательно откройте все файлы, находящиеся в каталоге /etc/apache2/sites-enabled, и добавьте для каждой секции <VirtualHost> в каждый файл строку для включения журналирования:
CustomLog "|/usr/bin/logger -p local4.info -t apache" tosiem # Для Ubuntu/Debian
CustomLog "|/usr/bin/logger -p local4.info -t httpd" tosiem # Для CentOS/RHEL
Корректно настроенное логирование позволяет не только контролировать работу веб‑сервера, но и своевременно обнаруживать атаки, значительно повышая уровень безопасности Apache. А с помощью BI.ZONE EDR можно узнать, настроен ли аудит у сервера Apache:
Резервное копирование — одна из важнейших мер безопасности веб‑сервера. Даже если соблюсти все правила харденинга, атакующий может повредить файлы конфигурации или веб‑контент. Либо может произойти сбой оборудования. В таких случаях только своевременно созданные резервные копии позволят быстро восстановить работу сервера без потери данных и длительного простоя.
Важно создавать резервные копии не только контента сайта, но и файлов конфигурации Apache, включая основные файлы (httpd.conf, apache2.conf), конфигурации виртуальных хостов (sites-available/*.conf) и дополнительные модули (mods-enabled, conf-available). Это позволяет при необходимости полностью восстановить корректную работу сервера после инцидента.
Ключевые направления харденинга Apache — ограничение утечек информации, защита конфиденциальных каталогов, корректная настройка SSL/TLS, управление HTTP‑методами, внедрение Content Security Policy и контроль количества подключений.
Кроме того, критически важно настроить логирование и регулярно анализировать журналы, а также автоматизировать резервное копирование конфигурации и веб‑контента. Совокупность этих мер позволяет снизить риск успешных атак, таких как XSS, SQL‑инъекции, перебор паролей, и обеспечить надежную защиту как серверной инфраструктуры, так и данных пользователей.
Правильная настройка Apache требует комплексного подхода: каждая директива, каждый модуль и каждая проверка играют роль в создании безопасной среды для работы веб‑приложений.
Независимо от типа веб‑сервера существует ряд ошибок конфигурации, которые существенно ослабляют безопасность системы. Эти мисконфигурации не зависят от конкретного программного обеспечения и отражают общие ошибки в подходе к администрированию и обеспечению безопасности веб‑серверов.
Один из первых шагов в повышении безопасности веб‑сервера — ограничение информации, которую он сообщает во внешние ответы. По умолчанию и Nginx, и Apache добавляют в заголовок Server сведения о своем имени и версии. Более того, Apache по умолчанию может дополнительно раскрывать тип операционной системы и модули, подключенные к серверу.
Пример для Nginx:
Server: nginx/1.22.1
Пример для Apache:
Server: Apache/2.4.57 (Ubuntu)
Такая информация полезна злоумышленникам: зная точную версию ПО, они могут подбирать эксплоиты под конкретные уязвимости. Сокрытие версии снижает риск эксплуатации автоматизированными сканерами и делает систему менее «заметной» для атакующих.
Для ограничения информации в Nginx в конфигурационном файле nginx.conf используйте:
server_tokens off;
После этого сервер будет указывать только название (nginx) либо вовсе не будет отправлять заголовок (при дополнительной фильтрации, например, через proxy_hide_header).
В Apache в конфигурационных файлах (httpd.conf или apache2.conf) применяются директивы:
ServerTokens Prod
ServerSignature Off
Они отключают раскрытие версии, ОС и подписи на автоматически сгенерированных страницах. Таким образом, минимизировать раскрытие информации о сервере — это не абсолютная защита, но хорошая практика базового харденинга, которая уменьшает поверхность атаки.
BI.ZONE EDR позволяет обнаруживать случаи, когда сервер раскрывает избыточную информацию о своей версии и операционной системе, что помогает вовремя скорректировать настройки:
Content Security Policy (CSP) — это мощный инструмент защиты веб‑приложений, позволяющий ограничивать источники контента, загружаемого браузером, и предотвращать выполнение вредоносных скриптов. CSP особенно эффективна против XSS‑атак (межсайтового внедрения скриптов), кражи данных и различных инъекций.
Механизм работает через HTTP‑заголовок Content-Security-Policy, в котором сервер указывает браузеру, откуда можно загружать ресурсы: скрипты, стили, изображения, шрифты, медиаконтент и т. д. Если ресурс не разрешен политикой, браузер блокирует его выполнение. Например, можно задать правило, при котором контент загружается только с текущего домена (’self’).
Пример для Nginx:
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self';";
В Apache для реализации CSP используется модуль mod_headers, который позволяет добавлять заголовки HTTP. Такую директиву можно размещать как в основном конфигурационном файле Apache (httpd.conf или apache2.conf), так и внутри виртуального хоста или <Directory>. Например, для конкретного каталога:
<Directory "/var/www/html/admin">
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'"
</Directory>
Важно учитывать, что слишком строгая политика может заблокировать легитимный контент (например, внешние библиотеки или стили), поэтому перед внедрением CSP в продовую среду ее нужно тщательно протестировать.
Таким образом, реализация CSP позволяет жестко контролировать источники контента и существенно повышает уровень безопасности веб‑приложения, снижая вероятность XSS‑атак. Проверить наличие и корректность заголовка CSP в ответах сервера можно с помощью BI.ZONE EDR, что позволяет оперативно выявлять слабые места в конфигурации:
Использование HTTPS стало обязательным стандартом для всех современных веб‑сервисов. Шифрование соединения защищает передаваемые данные от перехвата, обеспечивает их целостность и подтверждает подлинность сервера. Однако одного лишь наличия SSL-/TLS‑сертификата недостаточно — для реальной безопасности важно корректно настроить протоколы и шифры, исключив устаревшие и уязвимые варианты.
По умолчанию как Nginx, так и Apache могут поддерживать устаревшие версии протоколов (SSLv2, SSLv3, TLS 1.0, TLS 1.1) и слабые алгоритмы шифрования. Их использование открывает путь для атак «человек посередине» (MitM), позволяя злоумышленнику перехватывать и подменять данные. Чтобы минимизировать такие риски, разрешайте только современные версии TLS — 1.2 и 1.3.
В Nginx безопасная конфигурация может выглядеть так:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
В Apache аналогичные параметры задаются в настройках виртуального хоста или в файле ssl.conf:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite HIGH:!aNULL:!MD5
Чтобы пользователи всегда подключались к защищенной версии сайта, нужно настроить автоматическое перенаправление с HTTP на HTTPS. В Nginx это делается через директиву return или rewrite, а в Apache — с помощью Redirect в конфигурации виртуального хоста:
<VirtualHost *:80>
ServerName example.com
Redirect "/" "https://example.com/"
</VirtualHost>
Правильная настройка HTTPS — это не только защита от атак и утечек данных, но и фактор доверия: современные браузеры помечают сайты без TLS как небезопасные, а поисковые системы учитывают наличие HTTPS при ранжировании.
Проверить корректность конфигурации SSL/TLS можно с помощью решения BI.ZONE EDR, которое позволяет выявлять устаревшие протоколы, слабые шифры или отсутствие редиректа с HTTP на HTTPS:
Каждый HTTP‑метод, поддерживаемый веб‑сервером, расширяет поверхность атаки. Методы вроде TRACE, PUT или DELETE редко используются в веб‑приложениях, но могут позволить злоумышленникам выполнять нежелательные действия, например проводить XST‑атаки (сross-site tracing) или изменять файлы на сервере. В большинстве случаев для корректной работы сайта достаточно методов GET, POST и иногда HEAD. Все остальные следует запретить, чтобы снизить риск эксплуатации уязвимостей.
В Nginx это достигается простым условием в конфигурации:
if ($request_method !~ ^(GET|HEAD|POST)$) {
return 405;
}
Так сервер принимает только разрешенные методы и возвращает ошибку 405 Method Not Allowed при попытке использовать остальные.
В Apache, если нужно разрешить только методы, необходимые для работы сайта, например GET и POST, и запретить остальные, можно использовать <LimitExcept>:
<Directory "/var/www/html">
<LimitExcept GET POST>
Require all denied
</LimitExcept>
</Directory>
Такое ограничение не влияет на легитимную работу сайта, но значительно сокращает поверхность атаки и защищает сервер от несанкционированных запросов.
Харденинг веб‑сервера — это фундаментальный шаг, с которого начинается защита любой инфраструктуры. Надежная конфигурация, минимизация поверхности атаки и контроль доступа создают прочную основу безопасности. Однако и этого порой недостаточно: злоумышленники могут атаковать уровень веб‑приложений, обходя описанные меры защиты.
Поэтому в современных инфраструктурах используют файрвол веб‑приложений (WAF). Он помогает защитить сервер от наиболее распространенных атак на веб‑приложения, таких как SQL‑инъекции, XSS и попытки обхода аутентификации. WAF позволяет фильтровать вредоносные запросы еще до того, как они достигнут веб‑сервера. В Apache и Nginx часто применяют модуль ModSecurity, который можно дополнить набором правил OWASP Core Rule Set для базовой защиты. Более гибкие и продвинутые сценарии можно реализовать с помощью коммерческих решений, например BI.ZONE WAF, который обеспечивает расширенную аналитику атак. Такой подход снижает риск компрометации приложения и повышает уровень защищенности.
Харденинг веб‑серверов — ключевой элемент обеспечения безопасности современных веб‑приложений. Защита Nginx и Apache требует комплексного подхода: важно минимизировать раскрытие информации о сервере и операционной системе, а также контролировать доступ к конфиденциальным каталогам и файлам. Используйте современные версии протоколов шифрования и надежные шифры, чтобы снизить риск перехвата пользовательских данных и MitM‑атак.
Не менее важно регулировать работу сервера на уровне HTTP‑запросов, ограничивая методы, скорость запросов и количество одновременных соединений. Так вы предотвратите брутфорс-атаки и снизите влияние DoS‑атак. Реализация политики безопасности контента (CSP) и настройка заголовков безопасности дополнительно защищают от XSS и инъекционных атак.
Правильно организуйте логирование. Это позволит быстро выявлять и устранять потенциальные угрозы. Регулярно делайте резервные копии конфигурации и веб‑контента, чтобы восстанавливать работоспособность сервера в случае инцидентов. Внедрение BI.ZONE WAF, мониторинг активности пользователей и проверка настроек с помощью BI.ZONE EDR создают еще один уровень защиты, повышая общую устойчивость инфраструктуры.
Современные угрозы становятся все сложнее и изощреннее, а методы злоумышленников постоянно развиваются. Меры защиты, эффективные вчера, уже сегодня могут оказаться недостаточными. Поэтому харденинг веб‑серверов — это не разовая задача, а постоянный процесс. Только комплексная и последовательная реализация всех мер позволяет создать надежную и устойчивую среду для работы веб‑приложений, защищая как данные пользователей, так и саму инфраструктуру организации.
В этой статье мы рассмотрели веб‑серверы на базе ОС Linux. В дальнейшем расскажем о харденинге веб‑серверов на базе ОС Windows — следите за анонсами в соцсетях.