Архив автора: admin

Блокировка доступа к NGINX

Способы ограничения доступа к ресурсу в NGINX




Блокировка по User Agent`у




Я использую эту технику, прежде всего, для защиты от роботов, которые игнорируют настройки в моем файле robots.txt.




if ($http_user_agent ~ "Windows 95|Windows 98|xpymep|TurnitinBot|sindice|Purebot|libwww-perl")  {
  return 403;
  break;
}




Я выбрал для блокирования libwww-Perl, потому что в последние несколько лет, я не видел ни GET или POST по libwww-Perl, вероятно пробовали использовать какую-то уязвимость ПО.




Блокировка по IP-адресу




deny 85.17.26.68;     # spam
deny 85.17.230.23;    # spam
deny 173.234.11.105;  # junk referrers
deny 173.234.31.9;    # junk referrers
deny 173.234.38.25;   # spam
deny 173.234.153.30;  # junk referrers
deny 173.234.153.106; # spam
deny 173.234.175.68;  # spam
deny 190.152.223.27;  # junk referrers
deny 195.191.54.90;   # odd behaviour, Mozilla, doesnt fetch js/css. Ended up doing a POST, prob a spambot
deny 195.229.241.174; # spammy comments
deny 210.212.194.60;  # junk referrers + spam




Блокировка по запросу




Кроме того, можно заблокировать доступ на основе информации которая отправляется в заголовках HTTP.




if ($http_referer ~* (viagra|sex|porn|) ) {
  return 403;
}




Я использую ключ ~* для того чтобы предотвратить запрос GET по указанным словам во всей строке.




Блокировка по подсети




deny 69.28.58.0/24;   # spam
deny 79.142.64.0/20;  # spam
deny 80.67.0.0/20;    # spam




Блокировка по геолокации




Мы можем заблокировать целые страны, основанные на данных GeoIP предоставляемых MaxMind. Необходимо, чтобы NGINX имел модуль GeoIP. Во-первых, вы должны обозначить NGINX где база данных GeoIP находится в файловой системе. Вы можете сделать это внутри HTTP {}; Конфигурация блока:




geoip_country /etc/nginx/GeoIP.dat;




Теперь сообщаем NGINX страны которые необходимо заблокировать:




if ($geoip_country_code ~ (BR|CN|KR|RU) ) {
  return 403;
}




Блокировка по паролю




В конфигурационном файле, в папке, которую хотим закрыть надо только указать файл, где хранятся пароли. Вот два примера для закрытия папки с файлами:




location ^~ /codes/ {
   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/codes.log   download;
      }




либо админки с ограничением по IP-адресу:




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:




htpasswd -b passwords NewUser NewPassword




В файле запись с зашифрованным паролем имеет вид NewUser:P47ghZ4kloG78: #Your Can Comment Here




Защиту от перебора паролей можно организовать одновременно двумя методами, основанными на использовании iptables:




  • Блокирование IP на время, если количество запросов в секунду превышает какое-либо разумное количество
  • Вести лог неудачных попыток подбора пароля и скриптом раз в минуту проверять лог и заносить IP адреса в iptables




Для первого варианта достаточно создать правила:




iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW
   -m recent --name bhttp --set
iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW
            -m recent --name bhttp --update --seconds 120
            --hitcount 360 -j DROP
iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -j ACCEPT




Можно вместо DROP использовать TARPIT, чтобы усложнить жизнь ломателям.




Для второго варианта надо добавить в конфиг:




location /401.html {
   root   /usr/nginx;
            access_log   /usr/nginx/logs/denied.log  error401;
        }




Формат error401, у меня например такой:




log_format error401  '$remote_addr - $remote_user [$time_local] '
   '$status "$request"';



2022-04-14T17:32:32
Software

Блокировка доступа к NGINX

Способы ограничения доступа к ресурсу в NGINX




Блокировка по User Agent`у




Я использую эту технику, прежде всего, для защиты от роботов, которые игнорируют настройки в моем файле robots.txt.




if ($http_user_agent ~ "Windows 95|Windows 98|xpymep|TurnitinBot|sindice|Purebot|libwww-perl")  {
  return 403;
  break;
}




Я выбрал для блокирования libwww-Perl, потому что в последние несколько лет, я не видел ни GET или POST по libwww-Perl, вероятно пробовали использовать какую-то уязвимость ПО.




Блокировка по IP-адресу




deny 85.17.26.68;     # spam
deny 85.17.230.23;    # spam
deny 173.234.11.105;  # junk referrers
deny 173.234.31.9;    # junk referrers
deny 173.234.38.25;   # spam
deny 173.234.153.30;  # junk referrers
deny 173.234.153.106; # spam
deny 173.234.175.68;  # spam
deny 190.152.223.27;  # junk referrers
deny 195.191.54.90;   # odd behaviour, Mozilla, doesnt fetch js/css. Ended up doing a POST, prob a spambot
deny 195.229.241.174; # spammy comments
deny 210.212.194.60;  # junk referrers + spam




Блокировка по запросу




Кроме того, можно заблокировать доступ на основе информации которая отправляется в заголовках HTTP.




if ($http_referer ~* (viagra|sex|porn|) ) {
  return 403;
}




Я использую ключ ~* для того чтобы предотвратить запрос GET по указанным словам во всей строке.




Блокировка по подсети




deny 69.28.58.0/24;   # spam
deny 79.142.64.0/20;  # spam
deny 80.67.0.0/20;    # spam




Блокировка по геолокации




Мы можем заблокировать целые страны, основанные на данных GeoIP предоставляемых MaxMind. Необходимо, чтобы NGINX имел модуль GeoIP. Во-первых, вы должны обозначить NGINX где база данных GeoIP находится в файловой системе. Вы можете сделать это внутри HTTP {}; Конфигурация блока:




geoip_country /etc/nginx/GeoIP.dat;




Теперь сообщаем NGINX страны которые необходимо заблокировать:




if ($geoip_country_code ~ (BR|CN|KR|RU) ) {
  return 403;
}




Блокировка по паролю




В конфигурационном файле, в папке, которую хотим закрыть надо только указать файл, где хранятся пароли. Вот два примера для закрытия папки с файлами:




location ^~ /codes/ {
   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/codes.log   download;
      }




либо админки с ограничением по IP-адресу:




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:




htpasswd -b passwords NewUser NewPassword




В файле запись с зашифрованным паролем имеет вид NewUser:P47ghZ4kloG78: #Your Can Comment Here




Защиту от перебора паролей можно организовать одновременно двумя методами, основанными на использовании iptables:




  • Блокирование IP на время, если количество запросов в секунду превышает какое-либо разумное количество
  • Вести лог неудачных попыток подбора пароля и скриптом раз в минуту проверять лог и заносить IP адреса в iptables




Для первого варианта достаточно создать правила:




iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW
   -m recent --name bhttp --set
iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW
            -m recent --name bhttp --update --seconds 120
            --hitcount 360 -j DROP
iptables -A INPUT -p tcp --syn --dport 80 -i eth0 -j ACCEPT




Можно вместо DROP использовать TARPIT, чтобы усложнить жизнь ломателям.




Для второго варианта надо добавить в конфиг:




location /401.html {
   root   /usr/nginx;
            access_log   /usr/nginx/logs/denied.log  error401;
        }




Формат error401, у меня например такой:




log_format error401  '$remote_addr - $remote_user [$time_local] '
   '$status "$request"';



2022-04-14T17:32:32
Software

Деректива Nginx — location с примерами

Директива location служит для установки конфигурации в зависимости от URI-запроса. Синтаксис location в общем виде следующий:




Syntax:   location [=|~|~*|^~] uri { ... }
   location @name { ... }
Context:  server, location




Перед тем, как перейти к более детальному изучению, нужно заметить, что location определяется в контексте server (или в location в случае вложенной директивы), и в одном настраиваемом виртуальном хосте могут использоваться разные конфигурации в зависимости от обрабатываемого сервером URI.




Префикс «@» («собака») определяет именованные расположения. Такие location’ы не используются для обработки обычных запросов. Вместо этого они используются для перенаправления запросов (пример №6). Они не могут быть вложенными и содержать в себе вложенные.




Порядок обработки:




  1. = Строковые совпадения. Если найдено, проверка заканчивается. = значит полное совпадение шаблона и проверяемой строки, например = / — заход в секцию будет исключительно для корня, и даже файлы в корне уже сюда не подходят.
  2. ^~ Приоритетное строковое значение. Хотя по-моему было бы правильнее назвать «приоритетным регулярным выражением», поскольку в отличии от = требуется совпадение только начала. ^~ / полностью отключит регулярные выражения для секции server, если нет более точного location без ^~
  3. Строковые значения (/download/). Ищется максимальное совпадение, смотрится только с начала пути. Если нужно совпадение вида /*/download/, то это уже будет п.4, так что в уме можно читать такую запись как /download/* Но на этом проверка не заканчивается!
  4. ~, ~* Регулярные выражения, в порядке определения в конфиге. При совпадении — выполняется этот регэксп, проверка заканчивается. ~ — с учётом регистра, ~* — без.
  5. Если не было найдено подходящей регулярки, используется наибольшее совпадение из п.3.




Примеры использования location




Пример конфигурации №1. Для корневого URI «/»




location = / {
    # Расположение только для URI /
    # При совпадении дальнейший поиск не осуществляется
}




Пример конфигурации №2. Базовый location




location / {
    # Совпадает с URI всех запросов, т.к. они все начинаются с "/"
    # Но! Если будут найдены соответствия в расположениях
    # с регулярными выражениями или с другим более длинным
    # строковым литералом (например, "/data/"),
    # то конфигурация для "/" не будет применена.
}




Пример конфигурации №3. Для URI вида «/data/.*»




location /data/ {
    # Это расположение соответствует всем URI, начинающихся с "/data/"
    # и продолжает поиск по оставшимся location'ам.
    # В этом примере регулярные выражения и другие строковые литералы
    # также будут проверены, и "location /data/" будет использован,
    # если более конкретизирующие расположения не удовлетворят искомому ресурсу.
}




Пример конфигурации №4. Для URI вида «/img/.*»




location ^~ /img/ {
    # Соответствует любому URI, начинающемуся с "/img/".
    # Если соответствие установлено - останавливает дальнейший поиск,
    # не проверяя регулярные выражения, т.к. используется
    # префикс ^~ "крышечка/циркумфлекс тильда".
}




Пример конфигурации №5. Для графических форматов




location ~* .(png|ico|gif|jpg|jpeg)$ {
    # Данное расположение соответствует всем запрашиваемым URI,
    # оканчивающихся ".png", ".ico", ".gif", ".jpg" или ".jpeg".
    # При этом надо заметить, что запросы внутри расположения "/img/"
    # будут обработаны в location из примера №4
    # Т.е., если расположения из примеров №4 и №5 разместить в таком же
    # порядке в реальном конфиге, то до этого расположения ресурсов
    # дойдут только те картинки, которые лежат вне расположения "/img/"
}




Пример конфигурации №6. Именованный location




location / {
    error_page 404 = @fallback;
}
 
location @fallback {
    # Если при внутреннем перенаправлении не нужно менять URI,
    # то можно передать обработку ошибки в именованный location
}




Пример конфигурации №7. Выделение переменной




location ~ ^/a/(?[a-zA-Z]+) {
   # Тут можно использовать переменную $myvar,
   # которая представляет из себя строку из латиницы
   if ($myvar = "sth") { ... }
}




Примеры реальных nginx location’ов




Anti-hotlinking




Директива location для Anti-hotlinking (борьбы с использованием ресурсов с вашего сервера на сторонних ресурсах. Такой способ использования ваших сетевых ресурсов называется hotlinking). Такое поведение хитрых разработчиков может заметно увеличить нагрузку на ваш сервер. Конфигурация:




location ~ .(gif|png|jpe?g)$ {
    valid_referers none blocked mywebsite.com *.mywebsite.com;
    if ($invalid_referer) {
   return 403;
    }
}




Запрет на скрипты внутри директорий




Следующий пример — запрет на скрипты в разрешённых для записи директориях:




location ~* /(images|cache|media|logs|tmp)/.*.(php|pl|py|jsp|asp|sh|cgi)$ {
    error_page 403 /403.htm;
    return 403;
}




Включение autoindex




В следующем примере location используется для включения autoindex в nginx (Разрешение на вывод листинга каталога):




location /list_dir {
    autoindex on;
    autoindex_exact_size off;
    autoindex_localtime on;
}}




Проксирование Nginx на другой IP




server {
    listen   80;
    server_name домен;
    access_log off;
    error_log off;
    location / {
    # remote HTTP server
   proxy_pass http://IP:Порт;
    proxy_redirect http://IP:Порт /;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
        proxy_connect_timeout 600;
    }
}



2022-04-14T17:30:08
Software

Деректива Nginx — location с примерами

Директива location служит для установки конфигурации в зависимости от URI-запроса. Синтаксис location в общем виде следующий:




Syntax:   location [=|~|~*|^~] uri { ... }
   location @name { ... }
Context:  server, location




Перед тем, как перейти к более детальному изучению, нужно заметить, что location определяется в контексте server (или в location в случае вложенной директивы), и в одном настраиваемом виртуальном хосте могут использоваться разные конфигурации в зависимости от обрабатываемого сервером URI.




Префикс «@» («собака») определяет именованные расположения. Такие location’ы не используются для обработки обычных запросов. Вместо этого они используются для перенаправления запросов (пример №6). Они не могут быть вложенными и содержать в себе вложенные.




Порядок обработки:




  1. = Строковые совпадения. Если найдено, проверка заканчивается. = значит полное совпадение шаблона и проверяемой строки, например = / — заход в секцию будет исключительно для корня, и даже файлы в корне уже сюда не подходят.
  2. ^~ Приоритетное строковое значение. Хотя по-моему было бы правильнее назвать «приоритетным регулярным выражением», поскольку в отличии от = требуется совпадение только начала. ^~ / полностью отключит регулярные выражения для секции server, если нет более точного location без ^~
  3. Строковые значения (/download/). Ищется максимальное совпадение, смотрится только с начала пути. Если нужно совпадение вида /*/download/, то это уже будет п.4, так что в уме можно читать такую запись как /download/* Но на этом проверка не заканчивается!
  4. ~, ~* Регулярные выражения, в порядке определения в конфиге. При совпадении — выполняется этот регэксп, проверка заканчивается. ~ — с учётом регистра, ~* — без.
  5. Если не было найдено подходящей регулярки, используется наибольшее совпадение из п.3.




Примеры использования location




Пример конфигурации №1. Для корневого URI «/»




location = / {
    # Расположение только для URI /
    # При совпадении дальнейший поиск не осуществляется
}




Пример конфигурации №2. Базовый location




location / {
    # Совпадает с URI всех запросов, т.к. они все начинаются с "/"
    # Но! Если будут найдены соответствия в расположениях
    # с регулярными выражениями или с другим более длинным
    # строковым литералом (например, "/data/"),
    # то конфигурация для "/" не будет применена.
}




Пример конфигурации №3. Для URI вида «/data/.*»




location /data/ {
    # Это расположение соответствует всем URI, начинающихся с "/data/"
    # и продолжает поиск по оставшимся location'ам.
    # В этом примере регулярные выражения и другие строковые литералы
    # также будут проверены, и "location /data/" будет использован,
    # если более конкретизирующие расположения не удовлетворят искомому ресурсу.
}




Пример конфигурации №4. Для URI вида «/img/.*»




location ^~ /img/ {
    # Соответствует любому URI, начинающемуся с "/img/".
    # Если соответствие установлено - останавливает дальнейший поиск,
    # не проверяя регулярные выражения, т.к. используется
    # префикс ^~ "крышечка/циркумфлекс тильда".
}




Пример конфигурации №5. Для графических форматов




location ~* .(png|ico|gif|jpg|jpeg)$ {
    # Данное расположение соответствует всем запрашиваемым URI,
    # оканчивающихся ".png", ".ico", ".gif", ".jpg" или ".jpeg".
    # При этом надо заметить, что запросы внутри расположения "/img/"
    # будут обработаны в location из примера №4
    # Т.е., если расположения из примеров №4 и №5 разместить в таком же
    # порядке в реальном конфиге, то до этого расположения ресурсов
    # дойдут только те картинки, которые лежат вне расположения "/img/"
}




Пример конфигурации №6. Именованный location




location / {
    error_page 404 = @fallback;
}
 
location @fallback {
    # Если при внутреннем перенаправлении не нужно менять URI,
    # то можно передать обработку ошибки в именованный location
}




Пример конфигурации №7. Выделение переменной




location ~ ^/a/(?[a-zA-Z]+) {
   # Тут можно использовать переменную $myvar,
   # которая представляет из себя строку из латиницы
   if ($myvar = "sth") { ... }
}




Примеры реальных nginx location’ов




Anti-hotlinking




Директива location для Anti-hotlinking (борьбы с использованием ресурсов с вашего сервера на сторонних ресурсах. Такой способ использования ваших сетевых ресурсов называется hotlinking). Такое поведение хитрых разработчиков может заметно увеличить нагрузку на ваш сервер. Конфигурация:




location ~ .(gif|png|jpe?g)$ {
    valid_referers none blocked mywebsite.com *.mywebsite.com;
    if ($invalid_referer) {
   return 403;
    }
}




Запрет на скрипты внутри директорий




Следующий пример — запрет на скрипты в разрешённых для записи директориях:




location ~* /(images|cache|media|logs|tmp)/.*.(php|pl|py|jsp|asp|sh|cgi)$ {
    error_page 403 /403.htm;
    return 403;
}




Включение autoindex




В следующем примере location используется для включения autoindex в nginx (Разрешение на вывод листинга каталога):




location /list_dir {
    autoindex on;
    autoindex_exact_size off;
    autoindex_localtime on;
}}




Проксирование Nginx на другой IP




server {
    listen   80;
    server_name домен;
    access_log off;
    error_log off;
    location / {
    # remote HTTP server
   proxy_pass http://IP:Порт;
    proxy_redirect http://IP:Порт /;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
        proxy_connect_timeout 600;
    }
}



2022-04-14T17:30:08
Software

Ошибка NGINX — Число имен серверов или их длине — could not build the server_names_hash

Исправление ошибки в числе имен серверов или их длине




Если задано большое число имён серверов, либо заданы необычно длинные имена, возможно потребуется скорректировать значения директив
server_names_hash_max_size и server_names_hash_bucket_size на уровне http.
Значение по умолчанию директивы server_names_hash_bucket_size может быть равно 3264, либо другой величине, в зависимости от размера строки кэша процессора.
Если значение по умолчанию равно 32 и имя сервера задано как “too.long.server.name.example.org”, то nginx откажется запускаться и выдаст сообщение об ошибке:




could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32




В этом случае следует увеличить значение директивы до следующей степени двойки:




http {
    server_names_hash_bucket_size  64;
    ...




Если задано большое число имён серверов, то будет выдано другое сообщение об ошибке:




could not build the server_names_hash,
you should increase either server_names_hash_max_size: 512
or server_names_hash_bucket_size: 32




В таком случае сначала следует попробовать установить server_names_hash_max_size в величину, близкую к числу имён серверов, и только если это не поможет или время запуска nginx станет неприемлемо большим, следует попытаться увеличить server_names_hash_bucket_size.




Если сервер является единственным сервером для слушающего порта, то nginx не будет проверять имена сервера вообще (а также не будет строить хэш-таблицы для слушающего порта).




За одним исключением: если имя сервера задано регулярным выражением с выделениями, то nginx’у придётся выполнить это выражение, чтобы получить значения выделений.



2022-04-14T17:28:47
Software

Ошибка NGINX — Число имен серверов или их длине — could not build the server_names_hash

Исправление ошибки в числе имен серверов или их длине




Если задано большое число имён серверов, либо заданы необычно длинные имена, возможно потребуется скорректировать значения директив
server_names_hash_max_size и server_names_hash_bucket_size на уровне http.
Значение по умолчанию директивы server_names_hash_bucket_size может быть равно 3264, либо другой величине, в зависимости от размера строки кэша процессора.
Если значение по умолчанию равно 32 и имя сервера задано как “too.long.server.name.example.org”, то nginx откажется запускаться и выдаст сообщение об ошибке:




could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32




В этом случае следует увеличить значение директивы до следующей степени двойки:




http {
    server_names_hash_bucket_size  64;
    ...




Если задано большое число имён серверов, то будет выдано другое сообщение об ошибке:




could not build the server_names_hash,
you should increase either server_names_hash_max_size: 512
or server_names_hash_bucket_size: 32




В таком случае сначала следует попробовать установить server_names_hash_max_size в величину, близкую к числу имён серверов, и только если это не поможет или время запуска nginx станет неприемлемо большим, следует попытаться увеличить server_names_hash_bucket_size.




Если сервер является единственным сервером для слушающего порта, то nginx не будет проверять имена сервера вообще (а также не будет строить хэш-таблицы для слушающего порта).




За одним исключением: если имя сервера задано регулярным выражением с выделениями, то nginx’у придётся выполнить это выражение, чтобы получить значения выделений.



2022-04-14T17:28:47
Software