Обратный прокси-сервер — это служба, которая принимает запрос клиента, отправляет запрос одному или нескольким прокси-серверам, получает ответ и доставляет ответ сервера клиенту.
Благодаря своей производительности и масштабируемости NGINX часто используется в качестве обратного прокси-сервера для HTTP-серверов и серверов, отличных от HTTP. Типичная конфигурация обратного прокси-сервера — поставить Nginx перед приложениями Node.js , Python или Java . Читать
Сегодня в статье поговорим как Настроить HTTP заголовки WEB-сервера Nginx и обезопасить ваш сервер от различных атак.
Для начала давайте откроем конфигурационный файл WEB сервера Nginx
sudo nano /etc/nginx/nginx.conf
Найдите раздел HTTP, в этом разделе определяются конфигурации для HttpCoreModule Nginx. Добавьте следующую директиву:
server_tokens off;
Это запретит Nginx отправлять номера версий в заголовке HTTP.
Перезагрузите конфигурацию Nginx Чтобы применить это изменение:
sudo service nginx reload
Заголовок X-XSS-Protection может предотвратить некоторые XSS-атаки («межсайтовый скриптинг»), он совместим с IE 8+, Chrome, Opera, Safari и Android.
Добавьте следующее в nginx.conf в разделе HTTP:
add_header X-XSS-Protection "1; mode=block";
Заголовок X-Frame-Options позволяет снизить уязвимость вашего сайта для кликджекинг-атак. Этот заголовок служит инструкцией для браузера не загружать вашу страницу в frame/iframe. Не все браузеры поддерживают этот вариант, так что проверьте заголовок на совместимость перед тем, как его добавлять.
Добавьте следующее в nginx в директиве Server обычно она находится в конфигурационном файле сайта:
add_header X-Frame-Options “DENY”;
Можно предотвратить атаки с использованием подмены MIME типов, добавив этот заголовок ответа HTTP. Заголовок содержит инструкции по определению типа файла и не допускает сниффинг контента. При конфигурации потребуется добавить только один параметр: “nosniff”.
Добавьте следующую строку в файл nginx в директиве Server:
add_header X-Content-Type-Options nosniff;
Чтобы предотвратить XSS-атаки, кликджекинг, внедрение кода, можно добавить заголовок ответа Content Security Policy (CSP). CSP содержит инструкции о загрузке контента из разрешенных источников.
Добавьте следующее в секцию Server в файле nginx.conf:
add_header Content-Security-Policy "default-src 'self';";
Если после внесения данной директивы сайт стал отображаться не правильно, то вам необходимо :
По соображениям безопасности сервера рекомендуется отключить или скрыть информацию от злоумышленников, которые могут быть нацелены на ваш сервер, желая узнать, используете ли вы PHP или нет.
sudo nano /etc/php/7.4/fpm/php.ini
Найдите ключевое слово expose_php и установите его значение в Off:
expose_php = off
Если вы используете PHP как FPM, то вам нужно будет перезагрузить PHP-FPM:
sudo service php-fpm reload
После перезагрузки заголовок ответа X-Powered-By: PHP/7.4 должен отсутствовать
Если не помогло, то прописываем в nginx.conf следующее
proxy_hide_header X-Powered-By;
# или
#more_clear_headers 'X-Powered-By';
[endtxt]
Перед применением этого исправления вы должны проверить свой доступ и журналы ошибок Nginx. Если вы не получили никакой ошибки в журнале ошибок и получите статус HTTP 200/OK в журнале доступа. Но, тем не менее, вы получите пустые страницы на всех страницах PHP, тогда это исправление решит вашу проблему.
Ниже приведен блок местоположения, который мы использовали для блогов WordPress.
location ~ .php$ {
try_files $uri /index.php =404;
fastcgi_pass unix:/run/php/php7.3-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}
Здесь мы включаем fastcgi_params из ngx_http_fastcgi_module из Nginx. Но забыли добавить следующую строку в нужный файл.
Нам просто нужно открыть файл /etc/nginx/fastcgi_params и добавить строку ниже в конце файла.
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
ИЛИ вы можете напрямую пропустить эту строку с помощью приведенной ниже команды.
echo "fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;" >> /etc/nginx/fastcgi_params
Теперь перезапустите службу PHP-FPM и службу Nginx, используя приведенные ниже команды.
systemctl restart php7.3-fpm systemctl restart nginx
Как указано в Nginx Docs, параметр должен быть передан на сервер FastCGI. После применения этого исправления ваши PHP-страницы должны работать. Если нет, то у вас, вероятно, была другая проблема. Вы можете написать в комментарии, как вы решили эту проблему.
Сегодня в статье научимся получать сертификат WildCard от Let’s Encrypt для доменов третьего уровня.
Получать сертификат я буду для своего сайта работающего на Nginx + PHP-FPM.
Для начала нам необходимо установить утилиту CertBot. Для этого в терминале набираем следующее.
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install python-certbot-nginx
Данными командами мы добавили репозиторий для certbot, обновили все репозитории и установили certbot для Nginx.
Если у вас еще не установлен WEB-сервер Nginx, то читаем статью как это сделать.
Давайте наконец-то получим наш сертификат для поддоменов. но для начала в тестовом режиме. В терминале набираем:
sudo certbot --dry-run --manual --agree-tos --preferred-challenges dns certonly --server https://acme-v02.api.letsencrypt.org/directory -d *.obu4alka.ru -d obu4alka.ru
На что certbot выдаст вот такую запись:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel):
Ну тут все просто, необходимо ввести наш email для получения уведомлений о безопасности и оповещения о продлении. Двигаемся далее
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o:
Тут нам сообщают чтобы мы поделились нашим адресом с разработчиками и всякими некоммерческими организациями. Я конечно отвечаю нет “N“
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for obu4alka.ru
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.
Are you OK with your IP being logged?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o:
В данном сообщении нас предупреждают о том, что наш IP адрес на котором расположен наш сайт будет записан у разработчиков. Нажимаем “Y“
Please deploy a DNS TXT record under the name
_acme-challenge.obu4alka.ru with the following value:
3yTQ7zcagxbrWLdLI4Jp8wA_VarDKkAt7RqCOwjugaE
Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Certbot выдал нам запись, которую необходимо внести в txt запись DNS сервера. Как это сделать …. ну у каждого по разному. Вот пару фотографий как это происходило у меня.
Захожу в панель хостера — выбираю мой домен — управление доменом — Управление зоной ДНС
Добавляю информацию о TXT записи (это что выдал мне certbot).
За одно добавляю информацию о поддомене третьего уровня:
После внесения всех изменений в ваш домен необходимо будет немного подождать. Чтобы записи обновились у регистратора.
Если все прошло удачно, то вводим следующие команды для получения wildcard сертификата:
sudo certbot --manual --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns certonly --server https://acme-v02.api.letsencrypt.org/directory -d *.obu4alka.ru -d obu4alka.ru
Проходим все этапы заново и получаем наш сертификат.
Также давайте проверим что запись действительно обновилась. Для этого в терминале набираем следующую команду:
dig -t txt _acme-challenge.obu4alka.ru
или можно проверить например google DNS-ом:
dig @8.8.8.8 -t txt _acme-challenge.obu4alka.ru
Если запись обновилась, то двигаемся дальше. Так, как бот запрашивал нажатия “ENTER” после всех манипуляций, то жмем.
Waiting for verification...
Cleaning up challenges
Obtaining a new certificate
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/obu4alka.ru-0001/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/obu4alka.ru-0001/privkey.pem
Your cert will expire on 2020-07-10. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
Ну вот WildCard сертификат был получен.
Теперь необходимо внести изменения в конфигурационный файл nginx. Для этого открываем его (у вас название и пути могут отличаться):
sudo nano /etc/nginx/site-available/obu4alka-ssl.conf
Меняем директории для записей с ssl сертификатами, а также опцию server_name.
server_name obu4alka.ru *.obu4alka.ru;
...
ssl_certificate /etc/letsencrypt/live/obu4alka.ru-0001/fullchain.pem;
ssl_trusted_certificate /etc/letsencrypt/live/obu4alka.ru-0001/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/obu4alka.ru-0001/privkey.pem;
Проверяем все ли в порядке с настройкой nginx:
nginx -t
Если все в порядке, то перезагружаем nginx:
sudo /etc/init.d/nginx restart
Теперь Nginx настроен на обработку поддоменов третьего уровня с WildCard сертификатом.
При обновлении wildcard сертификата certbot категарически не хотел обновлять данные сертификаты. Терминал выдал мне следующее:
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/obu4alka.ru-0001/fullchain.pem (failure)
/etc/letsencrypt/live/obu4alka.ru-0002/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2 renew failure(s), 0 parse failure(s)
Решение было найдено после 4 часов изучение интернета. Опишу все процедуры к которым я прибегал. Может кому помогут.
/etc/letsencrypt/renewal находим наш домен и меняем строчку authenticator.
sudo nano /etc/letsencrypt/renewal/obu4alka.ru-0001.conf
#authenticator = manual # было
authenticator = nginx # стало
/etc/nginx/site-available находим наш конфигурационный файл от домена и смотрим чтобы был прописан IP-адрес перед портами 80 и 443 /etc/letsencrypt/live и удаляем все каталоги нашего домена. Также поступаем с директорией /etc/letsencrypt/archive и /etc/letsencrypt/renewal. А далее переходим к созданию сертификата заново.
Тут всё просто, точнее даже очень просто.
Создаем исполняемый bash скрипт и открываем на редактирование:
sudo touch /etc/cron.weekly/cert-nginx && sudo chmod +x /etc/cron.weekly/cert-nginx && sudo nano /etc/cron.weekly/cert-nginx
Следующего содержания:
#!/bin/bash
/usr/bin/certbot renew --post-hook "service nginx reload"
В результате каждую неделю скрипт будет запускаться и проверять необходимость обновления сертификатов. В случае такой необходимости сертификаты автоматически будут обновлены и будет запущен хук обновляющий конфигурацию сервера nginx (в моём случае)
[endtxt]
RSS
Защитите Netdata, используя basic аутентификацию!
Настройте приложение Netdata для прослушивания только на локальном хосте вместо каждого интерфейса. Читать
Защищаем домен и отбиваем атаку рефспама с помощью Nginx.
Самым простым способом защиты будет перечисление проблемных реферов, и отдача 444 ошибки соединениям с ними:
if ($http_referer ~* "(domain1.com|domain2.com|domain3.com)") {
return 444;