​​Обращаю ваше внимание на сервис по генерации конфигов для Nginx. Я когда-то давно уже о нём рассказывал, но с тех пор прошло много лет.

⇨ https://www.digitalocean.com/community/tools/nginx

Сам я на постоянку не пользуюсь такими сервисами, потому что у меня уже на все случаи жизни есть свои конфигурации. Но время от времени их имеет смысл проверять и актуализировать. Вот и в этот раз я решил этим заняться.

Указанный сервис очень удобен. Видно, что развивается. Раньше немного не так работал. Через форму на сайте указываете все нужные параметры и на выходе получается готовый набор конфигурационных файлов, разбитых по смыслу на части: отдельно общий конфиг, конфиг по безопасности, конфиг для специфических настроек wordpress, если укажите, что делаете конфигурацию для этой cms, отдельно настройки для letsencrypt и так далее.

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

◽генерации файла dhparam.pem, нужного для работы https с параметром ssl_dhparam:
◽создания каталога letsencrypt для подтверждения сертификатов;
◽инструкции по настройке certbot.

Я создал типовой для меня конфиг и сверился со своим. Увидел некоторые опции, которые раньше не использовал. Например:

▪ log_not_found - разрешает или запрещает записывать в error_log ошибки о том, что файл не найден. По умолчанию в nginx параметр включён и в error_log пишутся эти ошибки, сервис предлагает по умолчанию отключать. В принципе, смысл в этом есть. На практике error_log реально забивается этими записями, хотя чаще всего они не нужны, так как на работающий сайт постоянно кто-то стучится по несуществующим урлам. К себе тоже добавил этот параметр глобальноlog_not_found off; Раньше отключал только по месту для отдельных location, типа /favicon.ico или /robots.txt

▪ ssl_ciphers - обновил себе набор шифров. Я не вникаю в подробности набора, так как не особо в этом разбираюсь, да и не вижу большого смысла. Только учтите, что этот набор должен согласовываться с параметром ssl_protocols, где вы указываете список поддерживаемых версий TLS. Сейчас считается, что ниже TLSv1.2 использовать небезопасно.

▪ отдельно глобально вынесена блокировка всего, что начинается с точки, кроме директории .well-known, которую использует letsencrypt, и подключается ко всем виртуальным хостам:
location ~ /\.(?!well-known) {
  deny all;
Я обычно в каждом виртуальном хосте сначала разрешал .well-known, а потом блокировал всё, что начинается с точки:
location ~ /\.well-known\/acme-challenge {
  allow all;
}
location ~ /\. {
deny all;
  return 404;
}
То, как предлагает сервис, сделано удобнее. Тоже забрал себе.

Ну и так далее. Не буду всё расписывать, так как у каждого свои шаблоны. В общем, сервис удобный и полезный. Рекомендую не просто забрать в закладки, но и провести аудит своих конфигов на предмет улучшения. А если настраиваете nginx редко, то просто пользуйтесь этим сервисов. Он рисует абсолютно адекватные и качественные конфиги.

#nginx #webserver

​​Для быстрого доступа к СУБД Mysql очень удобно использовать небольшой скрипт Adminer, который представляет из себя ровно один php файл и запускается на любом хостинге. Я бы не писал о нём в очередной раз, если бы не столкнулся на днях с некоторыми нюансами при его использовании, так что решил оформить в заметку, чтобы самому потом не забыть.

С помощью Adminer можно создать пользователя и базу данных, назначить или изменить права, посмотреть содержимое таблиц, выгрузить или загрузить дамп. Лично мне для административных целей больше ничего и не надо. Разработчики, работая над сайтом, обычно просят phpmyadmin. Я не очень его люблю, потому что он монструозный, для него надо ставить дополнительные расширения php, поддерживать это дело.

Если я пользуюсь сам, то обычно просто закидываю adminer на сайт, делаю, что мне надо и потом сразу удаляю. В этот раз решил оставить на некоторое время и закрыть через basic_auth в Nginx (на самом деле в Angie). Вроде бы нет ничего проще:

# wget https://github.com/vrana/adminer/releases/download/v4.8.1/adminer-4.8.1-mysql-en.php
# mv adminer-4.8.1-mysql-en.php /var/www/html/adminer.php

Закрываем паролем. Создаём файл с учёткой:

# htpasswd -c /etc/nginx/.htpasswd admineruser21

Добавляем в Nginx:

location /adminer.php {
auth_basic "Administrator’s Area";
  auth_basic_user_file /etc/nginx/.htpasswd;
}

Перезапускаю Nginx, проверяю. Пароль не спрашивает, доступ прямой. Всё внимательно проверяю, ошибок нет. Я 100 раз это проделывал. Тут нет никаких нюансов. Но не работает.

Быстро догадался, в чём тут дело. В Nginx есть определённые правила обработки locations. Я с этой темой когда-то разбирался подробно и кое-что в памяти осело. Ниже для php файлов уже есть location:

location ~ \.php$ {
....
}

Он с регулярным выражением, поэтому обрабатывается раньше и при первом же совпадении поиск прекращается. Так что до моего location с паролем очередь просто не доходит. Сделать надо так:

location ~ adminer.php {
  auth_basic "Administrator’s Area";
  auth_basic_user_file /etc/nginx/.htpasswd;
.......................  
}

Тут надо указать все те же настройки, что у вас стоят для всех остальных php файлов в location ~ \.php$. И расположить location с adminer выше location для остальных php файлов. Это важно, так как судя по документации:

Затем nginx проверяет location’ы, заданные регулярными выражениями, в порядке их следования в конфигурационном файле. При первом же совпадении поиск прекращается и nginx использует совпавший location.

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

#webserver #nginx #mysql

Я ранее делал пару заметок на тему бесплатных инструментов для организации SSO: Keycloak и Authentik. Первый более навороченный и сложный для больших организаций. Второй попроще и больше подходит для небольших инфраструктур, в том числе личных сервисов. По настройке и возможностям мне Authentik понравился больше. Жду подходящий проект, чтобы его внедрить. Уже давно решил, что где-нибудь его попробую.

Тут как раз на днях посмотрел видео про настройку Basic Auth на базе Authentik. Очень востребованная лично для меня функциональность. Я люблю использовать Basic Auth в Nginx для того, чтобы скрыть от посторонних глаз то, что не должно быть в публичном доступе: различные управляющие веб панели, типа postfixadmin или phpmyadmin, веб доступ к 1С и т.д.

▶️ Authentik и basic http аутентификация

Автор по шагам показал, как это сделать на примере Traefik и Nginx. Там ничего особо сложного, но из-за скудной документации по этой теме некоторые вещи неочевидны. С инструкцией всё понятно. Посмотрел наглядно, как это выглядит. Мне понравилось. С учётом того, как часто я использую Basic Auth, точно пригодится. Вот ссылка на документацию по теме. Там реально всего пару предложений и пример конфига.

У автора серия из 3-х публикаций про Authentik:
▶️ Настройка authentik по-быстрому
▶️ OIDC авторизация с помощью Authentik на примере Portainer

Этой информации достаточно для базового внедрения основных возможностей. Материал свежий и пока актуальный.

#sso #nginx

Небезызвестный Василий Озеров открыл свой youtube канал (вовремя, как раз к блокировке ютуба) и выложил первое видео. Для тех, кто не знает, поясню. Василий - сооснователь школы Rebrain, рекламу которой вы тут периодически видите, и аутсорс компании Fevlake.

Ролик получился очень информативным, наглядным, нескучным, хоть и длинным - 50 минут. Я посмотрел его весь без перемотки и не в режиме только прослушивания. Большую часть того, что услышал, знал, но не всё. Почерпнул для себя новую информацию.

▶️ Разбор TLS параметров в Nginx: Подробная инструкция по настройке TLS

Для тех, у кого нет желания или времени всё смотреть, напишу несколько основных моментов, которые будут полезны даже в таком формате.

📌 Замена TLS 1.2 на TLS 1.3 даёт уменьшение времени отклика веб сервера. Тест Василия показал уменьшение со 170 мс до 130 мс только из-за смены версии протокола. Это связано с более быстрой инициализацией подключения клиента к серверу.

📌 Сертификат сервера, основанный на протоколе ECDSA, уменьшает при прочих равных условиях нагрузку на CPU сервера в сравнении с RSA где-то на 20-25%. Это связано с гораздо меньшей длиной сертификатов ECDSA.

📌 В конфигурацию Nginx можно добавить оба сертификата: ECDSA и RSA. Это обеспечит поддержку всех клиентов, и новых, и сильно старых, которые ECDSA не поддерживают.

📌 Если у вас только один веб сервер, то нет необходимости включать ssl_session_tickets, достаточно только ssl_session. Тикеты нужны, когда клиенту могут отвечать разные веб сервера с одинаковыми приватными ключами.

Очень подробно эти и некоторые другие моменты разобраны в видео. Рекомендую к просмотру. Реально полезная база, актуальная для любых сервисов, где используется TLS. Ну и не забывайте про лайк и подписку на канал, чтобы у Василия была мотивация записывать больше роликов. Видно, что для этого проделана большая работа.

#nginx #webserver

Если обратиться к веб серверу на базе Nginx по IP адресу, то увидите либо первый виртуальных хост в конфигурации, либо тот, где указана директива default в параметре listen. Показывать виртуальный хост не очень хочется, поэтому обычно на IP адрес ставят какую-то заглушку. Например, так:

server {
    listen 80 default_server;
    server_name _;
    return 404;
}

С 80-м портом и протоколом HTTP проблем обычно нет. А вот с HTTPS есть нюансы, так как нам нужно использовать сертификат. Доверенный сертификат на IP адрес получить нельзя. По крайней мере я не знаю, как это сделать. Если сертификат не указать, то будет использован сертификат первого в конфигурации виртуального хоста, где он указан. То есть если сделать вот так:

server {
    listen 443 ssl default_server;
    server_name _;
    return 404;
}

То пользователь, который зайдёт по IP адресу на сервер, увидит сначала предупреждение о том, что имя домена в сертификате не соответствует домену в адресной строке браузера. А когда согласится перейти по адресу, в свойствах сертификата можно будет увидеть адрес виртуального домена, сертификат которого использован.

Можно выйти из этой ситуации, выпустив самоподписанный сертификат-пустышку, не заполняя там вообще никаких полей:

# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/certs/nginx.key -out /etc/nginx/certs/nginx.crt

Используем его:

server {
    listen 443 ssl default_server;
    server_name _;
    ssl_certificate /etc/nginx/certs/nginx.crt;
    ssl_certificate_key /etc/nginx/certs/nginx.key;
    return 404;
}

Больше мы домены не светим, но пользователь по прежнему видит предупреждение о сертификате, что тоже не очень красиво. Хотя в целом можно оставить и так. Я всегда так и делал. А недавно увидел новое для себя решение этой же проблемы, чтобы пользователю показать сразу ошибку, без всяких предупреждений. Выглядит это вот так. Показываю сразу итоговый вариант:

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    ssl_reject_handshake on;
    return 404;
}

Объединил для удобства оба протокола. Ключевой момент тут в настройке ssl_reject_handshake on. Когда она включена, веб сервер отклоняет все попытки соединения, где адрес сервера не совпадает с тем, что указано в директиве server_name. Тут у нас в этой директиве _, так что все соединения будут сразу отклоняться. Пользователь сразу увидит ошибку без необходимости выполнять какие-либо действия.

Не увидел тут никаких подводных камней. Взял на вооружение, обновил свой стандартный конфиг default.conf для подобных настроек.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#nginx #webserver #angie

Решал на днях необычную для себя задачу. Нужно было определённые запросы к веб серверу Nginx сохранять отдельно. Можно общий лог обрабатывать, но есть более красивое и удобное решение - использовать возможности модуля map. Он универсальный и может много где использоваться. Покажу на примере с логом.

Пишем в отдельные файлы ошибку 404 и все коды 5XX. Добавляем в секцию http:

map $status $to404log {
404 1;
default 0;
}                
map $status $to5XXlog {
~^[5]  1;
default 0;
}

И потом в тот виртуальный хост, для которого это настаиваем:

access_log /var/log/nginx/404.log combined if=$to404log;
access_log /var/log/nginx/5XX.log combined if=$to5XXlog;

Теперь все запросы со статусом 404 будут писаться в лог 404.log, а все 500-е ошибки в лог 5XX.log. При этом в общий лог они тоже будут попадать.

Работает модуль map очень просто. В данном случае мы используем встроенную переменную $status, в которой хранится код ответа на запрос. Если код будет 404, то мы назначаем созданной нами переменной $to404log значение 1. А затем в виртуальном сервере указываем через if, что если значение 1, то пишем запрос в лог. А для 500-х ошибок используем регулярное выражение, которое будет включать их все.

По аналогии можно сделать блокировку определённых user-agent. Как раз для них я очень давно использую готовую конструкцию и баню наиболее известных ботов:

map $http_user_agent $block_useragent {
default 0;
~*semrushbot 1;
~*ahrefs 1;
~*rss2tg 1;
~*seznambot 1;
~*AspiegelBot 1;
~*BLEXBot 1;
~*MASHIAH 1;
  }

Добавляю в виртуальный хост:

if ($block_useragent) {
return 403;
}

Думаю, принцип понятен. По аналогии можно блокировать разные типы запросов через переменную $request_method, какие-то урлы для каких-то user agent. Модуль geoip тоже удобно через map использовать с помощью переменной $geoip_country_code, и т.д.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#nginx

На днях случился необычный для меня инцидент. Расскажу, как его преодолел. Сразу скажу, что это будет не инструкция, как надо делать, а то, как поступил я в конкретной ситуации. У меня есть в управлении одиночный сервер, где одна из виртуальных машин выполняет роль Nginx Proxy для других сервисов. Кто-то эту прокси решил ддоснуть. Немного растерялся от ситуации, так как сталкиваешься с ней нечасто и выверенного алгоритма действий нет.

Я не знаю, кем и для чего это делалось. Виртуалка проксировала доступ на неприметный публичный сайт, который давно не обновлялся и работал для галочки. Также проксировались соединения на мониторинг, 1С и некоторые другие внутренние сервисы для доступа к ним извне. На виртуалке внутри не было никакой защиты от ddos, внешняя, соответственно, тоже подключена не была. В этом не было необходимости. Ничего критичного там не стояло.

От мониторинга прилетел алерт на недоступность некоторых ресурсов, и на высокий LA виртуалки. По SSH хоть и небыстро, но подключился к ней. Заодно сразу зашёл на гипервизор. Он нормально переваривал нагрузку. Увидел, что на виртуалке CPU на четырёх ядрах в потолке. И все ядра нагрузил Nginx. Голым Nginx нагрузить практически пустыми соединениями на 100% 4 CPU не так просто. Я думал, что сейчас провайдер просто отрубит сервак и на этом всё закончится. Но нет, он переваривал, так что я стал разбираться на сервере локально.

Глянул лог Nginx и увидел массовые обращения на один конкретный URL публичного сайта с разных IP адресов. Вообще не понял, причём тут этот URL и почему в него долбят. Первое, что сделал, вообще отключил этот сайт. Nginx стал отдавать 502 ошибку, но серверу это слабо помогло.

Потом добавил параметр

limit_conn_zone $binary_remote_addr zone=perip:10m;

в nginx.conf и

limit_conn perip 50;

в настройки виртуального хоста. Хотел собирать айпишники тех, кто открывает более 50 соединений к сайту, чтобы потом их банить. Но там особо не собиралось, плюс лог ошибок рос с огромной скоростью, трудно было из него что-то выбирать. Виртуалка и так сильно тормозила. IP постоянно менялись, одновременных запросов, которые бы ловились Nginx, не было.

Решил мимо Nginx напрямую с iptables работать. У меня есть в закладках команда, которая сортирует и считает соединения с каждого IP адреса:

# netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//'

Тут уже было хорошо видно адреса, которые открыли много соединений. Немного изменил скрипт, чтобы выводить чистые списки IP адресов, открывших более 50-ти соединений и сохранять их в файл:

# netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|127.0.0.1)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//' | awk '{if ($1 > 50 ) print$2}' > ~/top_connect.txt

Дальше создал список ipset для использования списка IP адресов в правилах iptables. Напрямую большие списки в iptables направлять не надо, он их может не переварить.

# ipset -N top_connect nethash

Закинул туда список пойманных ранее IP адресов:

# cat ~/top_connect.txt | xargs -n1 ipset -A top_connect

И сделал правило в iptables для блокировки из этого списка:

# iptables -I INPUT 1 -m set --match-set top_connect src -j DROP

Блокировка заработала, счётчики правила пошли вверх, но помогло это слабо. Адреса постоянно менялись. Собрал всё это в скрипт и запускал по крону раз в минуту, тоже не помогло.

Решил забанить всех, кто обращается к урлу, который ддосят. Забирал IP ардеса, чтобы сильно не грузить сервак, так:

# tail -1000 /var/log/nginx/access.log | egrep "GET /url-for-ddos/" | awk '{print $1}' | sort -n | uniq -c | sort -n | tail -n100 | awk '{if ($1 > 2 ) print $2}' > ~/top_get.txt

Собрал их в ipset, добавил правило блокировки:

# ipset -N top_get nethash
# iptables -I INPUT 1 -m set --match-set top_get src -j DROP

Продолжение в следующей заметке 👇👇👇👇

#ddos #nginx #iptables

Решал на днях простую задачку. Нужно было сделать так, чтобы разработчики могли сами включать на сайте режим обслуживания, чтобы весь трафик пользователей шёл на страницу заглушку, а они могли с сайтом работать, как обычно. Такой режим есть в движке Битрикс. Довольно удобно, разработчики пользуются.

Хотелось сделать примерно то же самое на базе Nginx/Angie, но с помощью файла-флага, который можно положить в корень сайта и это будет включать режим обслуживания. Если файл есть – весь трафик пользователей идёт на заглушку, а IP адреса разработчиков или какие-то подсети видят сайт как обычно и работают с ним.

Задача в целом популярная, в сети легко находятся готовые примеры. Но там везде используется if. Хотелось сделать без него, но у меня не получилось. Долго мучал chatgpt. Он бодро предлагал неработающие решения, потом так же бодро сообщал, что действительно тут ошибка и так не работает. Надо делать вот так и тогда получится. В итоге простого красивого и удобного решения именно с файлом-флагом, без правки конфигурации и reload веб сервера сделать не получилось. Реализовал наиболее простой вариант с помощью пары if.

Создаём файл /etc/angie/allowed_ips.conf следующего содержания:

map $remote_addr $bypass_maintenance {
  default 0;
  187.192.238.175 1;
  192.168.0.0/24 1;
}

Указывать можно как одиночные IP адреса, так и подсети. Вынес эти настройки в отдельный файл для удобства. Добавляем в настройки виртуального хоста, для которого настраиваем режим обслуживания:

  location = /maintenance.html {
    try_files $uri =503;
  }

  location / {
    set $in_maintenance 0;
    if (-f $document_root/maintenance.flag) {
    set $in_maintenance 1;
    }
    set $maintenance_check "${in_maintenance}_${bypass_maintenance}";
    if ($maintenance_check = "1_0") {
      return 302 /maintenance.html;
    }
    try_files $uri $uri/ /index.php?$args;
  }

Теперь если в корне сайта создать файл maintenance.flag, то всем пользователям, кого нет в списке allowed_ips.conf будет отображаться содержимое файла maintenance.html, который надо добавить.

Это максимально простой и быстрый вариант. Но столкнулся с небольшим нюансом. Когда обслуживание закончено, желательно пользователей, кто остался на странице maintenance.html обратно вернуть на главную, когда они в очередной раз обновят страницу. Добавляем проверку в location /maintenance.html

  location = /maintenance.html {
    if (!-f $document_root/maintenance.flag) {
    return 302 /;
  }
    try_files $uri =503;
  }

Получилось относительно простое и эффективное решение. Не надо менять конфигурацию и дёргать веб сервер. Достаточно любым способом положить или переименовать заготовку для файла maintenance.flag, а потом обратно переименовать, когда работы закончены.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#nginx #angie