Архив метки: nginx

Получаем WildCard от Let’s Encrypt для домена.

let-encrypt-wildcard-ssl




Сегодня в статье научимся получать сертификат 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



Добавление RSS-ленты на главную страницу этого сайта не поддерживается, так как это может привести к зацикливанию, замедляющему работу вашего сайта. Попробуйте использовать другой блок, например блок Последние записи, для отображения записей сайта.


2020-04-11T09:27:55
Nginx

📜 Как защитить Netdata с помощью базовой аутентификации

Защитите Netdata, используя basic аутентификацию!

Настройте приложение Netdata для прослушивания только на локальном хосте вместо каждого интерфейса. Читать

Блокируем referrer spam с Nginx

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

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

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

Читать

Получения рейтинга A+ для домена

В сегодняшней статье рассмотрим конфигурацию 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




2019-08-08T08:00:33
Nginx

SSL_ERROR_RX_RECORD_TOO_LONG

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




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




Error_nginx_ssl_long




Что же делать. Вроде всё работает. В админку 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]



2019-07-10T13:58:33
Nginx

HTTP Strict Transport Security (HSTS) в NGINX

Netcraft недавно опубликовал исследование сайтов SSL/TLS, которые они отслеживают, и заметил, что только 5% из них правильно реализуют HTTP Strict Transport Security (HSTS). В этой статье описывается настройка NGINX и NGINX Plus для реализации политики HSTS.






Что такое HSTS?




HTTPS (HTTP, зашифрованный SSL или TLS) является неотъемлемой частью мер по обеспечению безопасности трафика на веб-сайт, что делает его очень трудным для злоумышленника, чтобы перехватить, изменить или поддельный трафик между Пользователем и веб-сайта.




Когда пользователь вводит веб-домен вручную (предоставляя имя домена без префикса http:// или https://) или следует простой ссылке http://, первый запрос на веб-сайт отправляется незашифрованным, используя простой HTTP. Большинство защищенных веб‑сайтов немедленно отправляют перенаправление для обновления пользователя до HTTPS‑соединения, но хорошо расположенный злоумышленник может смонтировать атаку “человек в середине” (MITM) для перехвата первоначального HTTP‑запроса и может контролировать сеанс пользователя с этого момента.




HSTS стремится справиться с потенциальной уязвимостью, указывая браузеру, что доступ к домену можно получить только с помощью HTTPS. Даже если пользователь вводит или следует простой HTTP-ссылке, браузер строго обновляет соединение с HTTPS.




Как работает HSTS?




Политика HSTS публикуется путем отправки следующего заголовка ответа HTTP с защищенных (HTTPS) веб-сайтов:




Strict-Transport-Security: max-age=31536000




Когда браузер видит этот заголовок с веб-сайта HTTPS, он “узнает”, что этот домен должен быть доступен только с помощью HTTPS (SSL или TLS). Он кэширует эту информацию на максимальный период (обычно 31536000 секунд – это примерно 1 год).




Необязательный параметр includeSubDomains сообщает браузеру, что политика HSTS также применяется ко всем поддоменам текущего домена.




Strict-Transport-Security: max-age=31536000; includeSubDomains




Например, ответ HTML для https://www.example.com может включать запрос к ресурсу от https://example.com, чтобы убедиться, что HSTS установлен для всех поддоменов example.com




Настройка HSTS в NGINX и NGINX Plus




Настройка заголовка ответа Strict Transport Security (STS) в NGINX и NGINX Plus относительно проста. Добавте параметр в конфигурационный файл nginx.conf:




add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;




Параметр always гарантирует, что заголовок задан для всех ответов, включая ответы на внутренние ошибки. Более старые версии NGINX (до версии 1.7.5 или NGINX Plus R5) не поддерживают параметр always и не устанавливают заголовок для внутренних ответов об ошибках.




Правила наследования для директив add_header




Блоки конфигурации NGINX наследуют директивы add_header от своих вложенных блоков, поэтому вам просто нужно поместить директиву add_header в серверный блок верхнего уровня. Существует одно важное исключение: если блок включает в себя директиву add_header, он не наследует заголовки от вложенных блоков, и вам нужно повторно объявить все директивы add_header:




server {     
    listen 443 ssl;     
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;     
# This 'location' block inherits the STS header     
    location / {         
        root /usr/share/nginx/html;     
    }     
# Because this 'location' block contains another 'add_header' directive,     
# we must redeclare the STS header     
    location /servlet {         
        add_header X-Served-By "My Servlet Handler";         
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;         
        proxy_pass http://localhost:8080;     
    } 
}




Тестируйте HTTP Strict Transport Security с осторожностью




После того, как клиент представлен с политикой HSTS, он кэширует информацию на указанный максимальный период. В течение этого периода браузер отказывается от доступа к веб-службе по незашифрованному HTTP. Если для политики HSTS указан параметр includeSubDomains, эти ограничения также применяются ко всем поддоменам текущего домена.




Очень сложно отказаться от политики HSTS, чтобы удалить HTTPS-версию веб-сайта или службы. Когда вы тестируете HSTS, используйте очень короткий максимальный тайм-аут и убедитесь, что вам комфортно с эффектами и обязательством поддерживать HTTPS-версию вашего сайта. Когда вы впервые начнете жить с вашей политикой HSTS, держите max-age маленьким и увеличивайте его только тогда, когда вы уверены в этом.




Должен ли каждый ответ HTTPS иметь заголовок STS?




Цель состоит в том, чтобы представить политику HSTS пользователям как можно скорее, когда они начинают сеанс HTTPS. Если они не получают политику HSTS во время сеанса, они останутся уязвимыми для будущих атак захвата HTTP.




Браузер должен наблюдать за заголовком STS только один раз, поэтому нет необходимости добавлять его в каждый блок местоположения и каждый ответ. Однако добавление его только на домашнюю страницу или страницу входа в систему, вероятно, недостаточно, и если вы добавите заголовок только к кэшируемым ответам, клиент может не увидеть его. Убедитесь, что вы покрываете как можно больше своего URL‑пространства, уделяя особое внимание динамическому (не кэшируемому) контенту.




Запуск HTTP и HTTPS версий веб-сайта бок-о-бок




Некоторые сайты запускают HTTP и HTTPS версии веб-сайта на одном сервере NGINX или NGINX Plus, чтобы сделать его содержимое доступным по любому протоколу:




server {     
    listen  80;     
    listen  443 ssl http2;     
# ... 
}




Это не подходит при использовании HSTS, поэтому в файле конфигурации WEB домена прописываем редирект на протакол HTTPS:




server {     
    listen 80 default_server;     
    listen [::]:80 default_server;     
    server_name _;     
    return 301 https://$host;    
# Либо 
  # return 301 https://$host$request_uri; 
} 
server {     
    listen 443 ssl http2;     
    server_name www.example.com;     
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; 
}




Укрепление HSTS




Клиент защищен от перехвата HTTP после того, как он увидел заголовок STS для соответствующего домена в течение объявленного периода максимального возраста.




Однако HSTS не является идеальным решением для захвата сеанса HTTP. Пользователи по-прежнему уязвимы для атаки, если они получают доступ к защищенному HSTS веб-сайту через HTTP, когда у них выполняются данные условия:




  • Никогда раньше не посещал сайт
  • Недавно переустановил свою операционную систему
  • Недавно переустановил свой браузер
  • Перешел на новый браузер
  • Перешли на новое устройство (например, мобильный телефон)
  • Удалил кэш браузера
  • Не посещал сайт в последнее время, и время max-age прошло




Чтобы решить эту проблему, Google поддерживает “список предварительной загрузки HSTS” веб-доменов и поддоменов, которые используют HSTS и представили свои имена https://hstspreload.appspot.com/. Этот список доменов распространяется и жестко закодирован в основных веб-браузерах. Клиенты, обращающиеся к веб-доменам в этом списке, автоматически используют HTTPS и отказываются обращаться к сайту по протоколу HTTP.




Имейте в виду, что после установки заголовка STS или отправки доменов в список предварительной загрузки HSTS удалить его невозможно. Это одностороннее решение сделать ваши домены доступными через HTTPS.




Если вы планируете добавить заголовок STS в конфигурацию NGINX, сейчас также самое время рассмотреть возможность использования других HTTP‑заголовков, ориентированных на безопасность, таких как X-Frame-Options и X-XSS-Protection.




NGINX Plus имеет дополнительные функции для защиты вашего сайта от угроз безопасности и других проблем, таких как распределенные атаки типа “отказ в обслуживании” (DDoS).



[endtxt]




RSS



Добавление RSS-ленты на главную страницу этого сайта не поддерживается, так как это может привести к зацикливанию, замедляющему работу вашего сайта. Попробуйте использовать другой блок, например блок Последние записи, для отображения записей сайта.


2019-05-13T08:00:24
Nginx