Nginx

= точное совпадение ^~ - не пробовать другие регекспы после совпадения, более строгие локейшены, чем простые * - регистро зависимый регексп ~* - регистро независимый регексп

Очень краткая заметка с примером как можно ограничить скорость обработки запросов от IP адресов, но исключив при этом роботов с определённым “юзер агентом”. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # ref: https://gist.github.com/supairish/2951524 # IP адреса в белом списке - для них не будет применяться лимитирование geo $geo_whitelist { default 0; 1.2.3.4 1; 2.3.4.5/24 1; } # Юзер агенты в белом списке - для них не будет применяться лимитирование map $http_user_agent $whitelist { default $geo_whitelist; ~*(google) 1; } # Если в белом списке 0, то помещаем "binary IP address" в $limit для применения к ним ограничений map $whitelist $limit { 0 $binary_remote_addr; 1 ""; } limit_req_zone $limit zone=perip:30m rate=1r/s;​

NGINX великолепен! Вот только его документация по ограничению скорости обработки запросов показалась мне, как бы это сказать, несколько ограниченной. Поэтому я решил написать это руководство по ограничению скорости обработки запросов (rate-liming) и шейпингу трафика (traffic shaping) в NGINX. Мы собираемся: описать директивы NGINX, разобраться с accept/reject-логикой NGINX, визуализировать обработку всплесков трафика на различных настройках. Директивы NGINX по ограничению скорости обработки запросов В этой статье мы будем говорить о ngx_http_limit_req_module, в котором реализованы директивы limit_req_zone, limit_req, limit_req_status и limit_req_level. Они позволяют управлять значением кода состояния HTTP-запроса для отклоненных (rejected) запросов, а также логированием этих отказов. Чаще всего путаются именно в логике отклонения запроса. Сначала нужно разобраться с директивой limit_req, которой требуется параметр zone. У него также есть необязательные параметры burst и nodelay. Здесь используются следующие концепции: zone определяет «ведро» (bucket) — разделяемое пространство, в котором считаются входящие запросы. Все запросы, попавшие в одно «ведро», будут посчитаны и обработаны в его разрезе. Этим достигается возможность установки ограничений на основе URL, IP-адресов и т. д. burst — необязательный параметр. Будучи установленным, он определяет количество запросов, которое может быть обработано сверх установленного базового ограничения скорости. Важно понимать, что burst — это абсолютная величина количества запросов, а не скорость. nodelay — также необязательный параметр, который используется совместно с burst. Ниже мы разберемся, зачем он нужен. Каким образом NGINX принимает решение о принятии или отклонении запроса? При настройке зоны задается ее скорость. Например, при 300r/m будет принято 300 запросов в минуту, а при 5r/s — 5 запросов в секунду. ...

В этой статье опишу небольшую инструкцию для установки сертификата с помощью acme.sh на базе алгоритма ECDSA P-384, этот алгоритм имеет высокий уровень быстродействия и защищенности. Например 256 битный ECDSA соответствует 3072 битному RSA по степени защиты, но при этом скорость работы в несколько раз выше. Установка acme.sh 1 curl https://get.acme.sh | sh Получение сертификата Метод 1 : использование одной и той же директории для всех acme challenge запросов Первоначально нам необходимо создать файл acme.conf в директории /etc/nginx/common/ со следующим содержанием: 1 location /.well-known/acme-challenge/ { alias /var/www/html/.well-known/acme-challenge/; } После этого установим пользователя www-data (или вашего) владельцем директории /var/www/html : 1 chown -R www-data:www-data /var/www/html Последним шагом нам нужно включить acme.conf в вашу конфигурацию виртуального хоста nginx, добавлением следующей строки : 1 include common/acme.conf; Перечитываем конфигурацию nginx командой service nginx reload и уже сейчас вы можете получить свой первый сертификат с помощью acme.sh: ECDSA Certificates (384 Bits) 1 acme.sh --issue -d yourdomain.tld -d www.yourdomain.tld -d blog.yourdomain.tld --keylength ec-384 -w /var/www/html Метод 2 : используем Cloudflare DNS API Настраиваем ваши API ключи 1 2 export CF_Key="sdfsdfsdfljlbjkljlkjsdfoiwje" export CF_Email="[email protected]" ECDSA Certificates (384 Bits) 1 acme.sh --issue -d yourdomain.tld -d www.yourdomain.tld -d blog.yourdomain.tld --keylength ec-384 --dns dns_cf Устанавливаем SSL сертификат в Nginx НЕ ИСПОЛЬЗУЙТЕ сертификаты в директории ~/.acme.sh/, они только для служебного использования, структура директории может измениться в будущем. Создайте директорию для хранения ваших сертификатов в продакшене. ...

Много где написано о том, как получить 100% и A+ по тесту от Qualys. При всём при том практически везде директивы ssl_ciphers и подобные даются как эдакие магические строки, которые нужно просто вставить, и надеяться, что автор не подводит вас под монастырь. Эта статья призвана исправить это недоразумение. По прочтению этой статьи директива ssl_ciphers потеряет для вас всякую магию, а ECDHE и AES будут как друзья да братья. Подготовка Работать будем с Debian 8.7. Если у вас другой дистрибутив, то версии должны быть такие же или более новые. 1 2 3 4 5 6 7 8 # lsb_release -d Description: Debian GNU/Linux 8.7 (jessie) # openssl version OpenSSL 1.0.1t 3 May 2016 # nginx -V nginx version: nginx/1.6.2 Настроим nginx для получения сертификатов от Let’s Encrypt по инструкции, но только до получения сертификата для нашего домена. 1 certbot certonly -d example.com -d www.example.com Конфиг используем минимальный. Ничего лишнего. Всё по умолчанию. 1 2 3 4 5 6 7 8 server { server_name www.example.com example.com; listen 443 ssl default_server; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; } Теперь прогоним тест для этого сервера. ...

Сложность в том, что некоторым скриптам необходимо знать через какую схему они работают, http, или https. Таким образом они формируют ссылки, а иногда принудительно перенаправляют клиентов куда нужно. Из-за не верной настройки серверного ПО переадресация не может завершиться и браузер покажет нам ошибку ‘too many redirects’. В статье рассмотрим две схемы: nginx (front1, server2) -> nginx (front2, server1) -> php-fpm (back, server1) nginx (front1, server2) -> nginx (front2, server1) -> apache (back, server1) Первой рассмотрим схему с php-fpm: nginx (front1, server2) -> nginx (front2, server1) -> php-fpm (back, server1) На сервере nginx (front1, server2) у нас обязательно должны быть строки 1 2 3 4 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded_For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; среди которых нам важна последняя. На сервере nginx (front2, server1) в секцию http добавляем 1 2 3 4 5 6 7 8 http { ... map $http_x_forwarded_proto $fastcgi_https { default off; https on; } ... } Если его добавить в любое другое место - получите следующую ошибку при перезапуске nginx: 1 nginx: [emerg] "map" directive is not allowed here Если прописать просто $https вместо $fastcgi_https - получите следующую ошибку: 1 nginx: [emerg] the duplicate "https" variable in /etc/nginx/nginx.conf Дело в том, что начиная с какой-то бородатой версии NginX имеет встроенную переменную $https, поэтому ее повторно использовать не получится. ...

Давно искал что-то подобное. Конфигурация nginx позволяет перенаправлять посетителей сайта на мобильную версию по UserAgent‘у. И казалось бы… это совсем не сложно, но у нас есть ещё и плюшки. Плюшки в том что мы можем добавить в адресную строку параметр для переключения на полную версию, или обратно на мобильную. Всё это записывается в cookies и сохраняется на заданное нами время. т.е. людей не будет напрягать то, что их при каждом входе принудительно перенаправляет на мобильную версию, а они то хотят полную. Таким образом принудительное переключение с полной версии на мобильную происходит добавлением example.com?mobile=yes, а переключение с мобильной на полную добавлением example.com?mobile=no 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 #with regex from http://detectmobilebrowsers.com/ #map suggestion via kolbyjack #not tested map $http_user_agent $mobile_agent{ default 0; ~* "android.+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino" 1; ~* "^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-)" 1; } #set $mobile_rewrite variable set $mobile_rewrite do_not_perform; if($mobile_agent = 1){ set $mobile_rewrite perform; } #check if query arg = yes (example.com?mobile=yes), set variable if ($arg_mobile = 'yes') { add_header Set-Cookie mobile=yes; set $mobile_rewrite perform; } #check if cookie mobile=yes, set variable if ($cookie_mobile = 'yes') { set $mobile_rewrite perform; } #check if cookie mobile=no, break if ($cookie_mobile = 'no') { set $mobile_rewrite do_not_perform; } #check if query arg = no (example.com?mobile=no), break if ($arg_mobile = 'no') { add_header Set-Cookie mobile=no; } #if $mobile_rewrite = perform, do the redirect if ($mobile_rewrite = perform) { return 301 $scheme://mobile.domain.com$request_uri; } Ниже должна быть ссылка на оригинальный скрипт, но она потерялась в процессе очередного переезда :(

Пару лет назад думал что настроил на вэб сервере поддержку ipv6, все онлайн тесты проходили на ура. Но сейчас, настроив у себя ipv6, понял что при обращении к сайтам получаю в ответ “403 Forbidden”. Не приятно конечно, но надо что-то делать. Тогда, при настройке, была информация что нужно добавлять в конфиг сервера запись вида 1 listen [::]:80 ipv6only=on; при чём если её добавлять в несколько виртуальных серверов, то nginx выкидывал ошибку. Пришёл к выводу что достаточно одной директивы в конфиге по умолчанию. Ошибался. В общем смысл таков: В конфиге по умолчанию должно быть прописано 1 2 listen 80 default_server; listen [::]:80 default_server ipv6only=on; а в конфигах каждого виртуального хоста прописываем 1 2 listen 80; listen [::]:80; Таким образом все сайты работают с ipv4 и ipv6. Если поддержка ipv6 для сайта не нужна, то строку 1 listen [::]:80; прописывать не нужно! А ошибку “403 Forbidden” получал из-за того, что у меня хост по умолчанию её отдаёт для всех желающих ломиться по IP, или подбирать поддомены.

Заметка об использовании переменных в домене на web сервере nginx, или динамические поддомены. Важно не забыть выше расположить статические поддомены, чтоб динамические их не перебивали. Ну и примеры ниже: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 server { server_name www.example.com; location / { proxy_pass 127.0.0.1:80; } } server { server_name ~^(?<dynamic>[a-z0-9\-]+)\.example.com$; location / { proxy_pass 127.0.0.1:80/sites/$dynamic$uri$is_args$args; } } Вот ещё вариант: Если у вас много поддоменов или вы хотите создавать их автоматически, тогда имеет смысл создать одну универсальную конфигурацию, которая будет обслуживать все поддомены, направляя запросы посетителей в соответствующие каталоги. В первую очередь, необходимо настроить DNS: добавить поддомен с именем * (звездочка, без кавычек) и направить его на IP вашего веб-сервера. Измените секцию server вашего сайта следующим образом: 1 2 3 4 5 6 7 8 9 10 11 12 server { listen 80; server_name example.com *.example.com; root /var/www/example.com/$subdomain; set $subdomain ""; if ($host ~* ^([a-z0-9-\.]+)\.example.com$) { set $subdomain $1; } if ($host ~* ^www.example.com$) { set $subdomain ""; } } Не забудьте поменять example.com на имя вашего домена. Эта конфигурация работает следующим образом: ...

Небольшая заметка о том, как средствами Nginx закрыть доступ к файлам/папке по паролю. В nginx это решение не менее элегантно, чем в apache, а может и еще лучше, кому как нравится. В конфигурационном файле, в папке (локейшене), которую хотим закрыть надо только указать файл, где хранятся пароли. Вот два примера для закрытия папки с файлами: 1 2 3 4 5 6 7 8 location ^~ /files/ { root /path/to/server; autoindex on; autoindex_exact_size off; auth_basic "Hello, please login"; auth_basic_user_file /usr/nginx/passwords; access_log /usr/nginx/logs/files.log download; } и админовской части c дополнительным ограничением по IP: 1 2 3 4 5 6 7 8 9 10 location ^~ /admin/ { fastcgi_pass unix:/home/project/server.sock; include conf/fastcgi.conf; allow 11.11.0.0/16; allow 22.22.22.22; deny all; auth_basic "Hello, Admin, please login"; auth_basic_user_file /usr/nginx/adminpassword; access_log /usr/nginx/logs/admin.log main; } Добавить пользователя можно с помощью стандартной утилиты от apache: 1 htpasswd -b passwords NewUser NewPassword В файле запись с зашифрованным паролем имеет вид: 1 NewUser:P47ghZ4kloG78: Your Can Comment Here Защиту от перебора паролей можно организовать одновременно двумя методами, основанными на использовании iptables: Блокирование IP на время, если количество запросов в секунду превышает какое-либо разумное количество Вести лог неудачных попыток подбора пароля и скриптом раз в минуту проверять лог и заносить IP адреса в iptables Для первого варианта достаточно создать правила: ...