Сегодня в статье поговорим как Настроить HTTP заголовки WEB-сервера Nginx и обезопасить ваш сервер от различных атак.

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

Заголовок X-XSS-Protection может предотвратить некоторые XSS-атаки («межсайтовый скриптинг»), он совместим с IE 8+, Chrome, Opera, Safari и Android.

Добавьте следующее в nginx.conf в разделе HTTP:

add_header X-XSS-Protection "1; mode=block";

X-Frame-Options

Заголовок X-Frame-Options позволяет снизить уязвимость вашего сайта для кликджекинг-атак. Этот заголовок служит инструкцией для браузера не загружать вашу страницу в frame/iframe. Не все браузеры поддерживают этот вариант, так что проверьте заголовок на совместимость перед тем, как его добавлять.

Добавьте следующее в nginx в директиве Server обычно она находится в конфигурационном файле сайта:

add_header X-Frame-Options “DENY”;

X-Content-Type-Options

Можно предотвратить атаки с использованием подмены MIME типов, добавив этот заголовок ответа HTTP. Заголовок содержит инструкции по определению типа файла и не допускает сниффинг контента. При конфигурации потребуется добавить только один параметр: “nosniff”.

Добавьте следующую строку в файл nginx в директиве Server:

add_header X-Content-Type-Options nosniff;

Content Security Policy

Чтобы предотвратить 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]

RSS

Перед применением этого исправления вы должны проверить свой доступ и журналы ошибок Nginx. Если вы не получили никакой ошибки в журнале ошибок и получите статус HTTP 200/OK в журнале доступа. Но, тем не менее, вы получите пустые страницы на всех страницах PHP, тогда это исправление решит вашу проблему.

Шаг 1: Конфигурация блока местоположения для всех файлов 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. Но забыли добавить следующую строку в нужный файл.

Шаг 2: Добавьте fastcgi_param в файл конфигурации

Нам просто нужно открыть файл /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, то читаем статью как это сделать.

Получаем WildCard от Let’s Encrypt

Давайте наконец-то получим наш сертификат для поддоменов. но для начала в тестовом режиме. В терминале набираем:

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 от Let`s Encrypt

При обновлении 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
• Третье: После долгих мучений (первые два варианта не помогли) я решил удалить конфиги и директории на сертификаты от certbot. И так переходим в директорию /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

Защищаем домен и отбиваем атаку рефспама с помощью Nginx.

Самым простым способом защиты будет перечисление проблемных реферов, и отдача 444 ошибки соединениям с ними:

if ($http_referer ~* "(domain1.com|domain2.com|domain3.com)") {
return 444;

Читать →

В сегодняшней статье рассмотрим конфигурацию Nginx для получения рейтинга A+ на сайте ssllabs.

Начальная конфигурация:

• Сервер Ubuntu Server 18.04
• VestaCP – контроль панель
• Web сервер Nginx v1.17.2
• DNS сервер bind9
• PHP v7.4
• MySQL v5.7

Все сайты конфигурируются через контроль панель VestaCP, поэтому все примеры будут показаны для данной панели, но также вся приведенная конфигурация применима и к обычной конфигурации сервера.

И так начнем:

Настройка сжатия в Nginx

Открываем файл конфигурации nginx

sudo nano /etc/nginx/nginx.conf

И вносим в секцию http следующие строки:

##Compression
gzip                on;
gzip_static         on;
gzip_vary           on;
gzip_comp_level     6;
gzip_min_length     1024;
gzip_buffers        16 8k;
gzip_types          text/plain text/css text/javascript text/js text/xml application/json application/javascript application/x-javascript application/xml application/xml+rss application/x-font-t$
gzip_proxied        any;
gzip_disable        "MSIE [1-6].";

Настройка stapling в Nginx

Для начала создадим файл dhparams.pem:

sudo openssl dhparam -out /home/admin/conf/web/dhparams.pem 4096

путь можете указать свой, но не забудьте тогда поменять его и в конфигурации nginx

Также ускорим проверку сертификата клиентом и увеличим скорость загрузку сайта. Для этого у вас должен быть сертификат SSL. У меня сертификат от letsencrypt, для него и привожу пример. Сертификат получен при помощи certbot установленного в системе.

Давайте добавим в конфигурацию nginx, следующую секцию:

##Stapling Session
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/obu4alka.ru/chain.pem;
resolver 8.8.8.8;
ssl_session_tickets off;
ssl_dhparam /home/admin/conf/web/dhparams.pem;

название сайта и пути пишем свои.

Включаем HSTS в Nginx

В секцию http:

## HSTS Session
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report";

Настройка TLSv3 в Nginx

Также вносим в секцию http:

##SSL Session
ssl_session_cache   shared:SSL:10m;
ssl_protocols       TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

Если необходимо, то можете добавить TLSv1.1 и TLSv1.0 в ssl_protocols

Сгенерировать шрифты можно по адресу SSL Configuration Generator

Включаем SSL и HTTP2 в Nginx

Открываем на редактирование файлы виртуальных хостов. По умолчанию они находятся в директории /etc/nginx/sites-enabled/ваш-сайт.conf

В моем случае пути следующие:

sudo nano /home/admin/conf/web/mysite.nginx.ssl.conf

И вношу изменение:

##было
server {
     listen      80.81.82.83:443 ;
     server_name obu4alka.ru www.obu4alka.ru;

##стало
server {
     listen      80.81.82.83:443 http2 ssl;
     server_name obu4alka.ru www.obu4alka.ru;

Работа с HTTPS устроена таким образом, что если у сервера был запрошен по защищенному протоколу сайт, не имеющий сертификата, либо вообще произошло обращение по IP-адресу, то в ответ будет показан тот защищенный сайт, который находится первым в конфигурации. Во многих случаях такое поведение будет неожиданным для пользователя и его следует избегать. В нашем случае, при запросе узла отличного от указанного в конфиге, сервер оборвет соединение без отправки данных (ошибка 444 в Nginx).

server {
     listen      80.81.82.83:443 http2 ssl;
     server_name obu4alka.ru www.obu4alka.ru;
     if ($host != $server_name) {
        return 444;
     }

Тестирование на получения рейтинга A+

переходим на сайт ssllabs.com – для тестирования и получения рейтинга.

Также можете перейти на сайт hstspreload.org– для внесения сайта в списки HSTS сайтов.

[endtxt]

RSS

• Тест скорости дисков в Linux
• Как запустить команду в фоне в Linux
• Ошибка несоответствие размеров GPT PMBR
• nginx: [warn] protocol options redefined
• Как включить поддержку linux в windows 11

Всем доброе время суток. Сегодня рассмотрим пример по устранению ошибки nginx “SSL_ERROR_RX_RECORD_TOO_LONG”, которая появилась после обновления ключей ssl в админ панели VestaCP.

Все началось одним прекрасным утром, я попытался зайти на сайт, но не тут то было, мне вместо знакомой страницы показалась вот такая запись.

Что же делать. Вроде всё работает. В админку VestaCP заходит, сам nginx тоже отрабатывает без ошибок

sudo /etc/init.d/nginx restart
[sudo] password for user:
[[ ok  Restarting nginx (via systemctl): nginx.service.

но вот сайт работать отказывается.

Ну, интернет мне в помощь. А он мне говорит, что данная ошибка связана с SSL протоколом. SSL получила запись, длина которой превышает максимально допустимую величину. Тут я задумался, недавно настраивал nginx на получения статуса A+ на сайте ssllab. Ладно, лезу в настройке nginx. Открываю файл nginx.conf и выключаю stapling и add_header Strict-Transport-Security. Перезагружаю web сервер, а не тут то было. Ошибка все равно осталась. Посидев около часа на форумах набрёл на рекомендацию в добавлении записи ssl и http2 в конфигурационный файл сайта. Так, лезу и добавляю запись:

listen 11.11.11.11:443 ssl http2

После рестарта web сервера сайт заработал в обычном режиме.

Ура!!! Ошибка исправлена.

[endtxt]