🛡 Хочу поделиться с вами продуктом на базе Nginx, который мне понравился своей простотой и удобством. Речь пойдёт про Bunkerweb, который реализует в том числе функционал WAF (Web Application Firewall). Это собранный Docker контейнер с Nginx внутри и кучей дополнительного функционала для обеспечения безопасности.
Bunkerweb может работать как непосредственно локальный веб сервер, так и в режиме reverse proxy. Большая часть функционала реализована штатными средствами Nginx и модулями к нему. В качестве WAF используется ModSecurity, для защиты от ботов интеграция с различными каптчами.
📌 Для настройки есть мастер создания конфигурации. Оценить функционал и основные возможности проще всего через него, а не через просмотр описания или доков. Там сразу понятно, что он умеет и как настраивается. Перечислю основные фишки:
◽ есть встроенный веб интерфейс для управления (видео с демонстрацией)
◽ поддержка плагинов (уже есть интеграции с CrowdSec, ClamAV, Discord, Slack, VirusTotal)
◽ WAF на базе ModSecurity и набора правил OWASP
◽ распознавание ботов, их блокировка или показ каптчи
◽ блок ip по странам или внешним списками
◽ поддержка сертификатов let's encrypt
Весь функционал подробно описан в документации. Запускается Bunkerweb в Docker, Kubernetes, локально с ручной установкой или через Ansible. Доступны, по сути, все возможные способы, кому что ближе и удобнее.
Проект оставил очень хорошее впечатление. Он хорошо документирован, описан, понятно сделан, продуман. Мне показалось, что это хорошее решение не только с точки зрения безопасности, но и просто установки и управления Nginx. Можно через конструктор собрать набор опций, запустить Bunkerweb, а потом посмотреть в конфиге, как всё это реализовано. Так как всё собрано на базе open source продуктов, разобраться не трудно. При желании, можно что-то в свои наработки утащить.
Можно рассматривать этот продукт как панель управления для Nginx с базовым набором правил безопасности. Это если его просто с дефолтными настройками запустить. А дальше уже при желании можно наращивать функционал.
Сайт - https://docs.bunkerweb.io
Исходники - https://github.com/bunkerity/bunkerweb
Demo - https://demo.bunkerweb.io/
#waf #security #nginx
Bunkerweb может работать как непосредственно локальный веб сервер, так и в режиме reverse proxy. Большая часть функционала реализована штатными средствами Nginx и модулями к нему. В качестве WAF используется ModSecurity, для защиты от ботов интеграция с различными каптчами.
📌 Для настройки есть мастер создания конфигурации. Оценить функционал и основные возможности проще всего через него, а не через просмотр описания или доков. Там сразу понятно, что он умеет и как настраивается. Перечислю основные фишки:
◽ есть встроенный веб интерфейс для управления (видео с демонстрацией)
◽ поддержка плагинов (уже есть интеграции с CrowdSec, ClamAV, Discord, Slack, VirusTotal)
◽ WAF на базе ModSecurity и набора правил OWASP
◽ распознавание ботов, их блокировка или показ каптчи
◽ блок ip по странам или внешним списками
◽ поддержка сертификатов let's encrypt
Весь функционал подробно описан в документации. Запускается Bunkerweb в Docker, Kubernetes, локально с ручной установкой или через Ansible. Доступны, по сути, все возможные способы, кому что ближе и удобнее.
Проект оставил очень хорошее впечатление. Он хорошо документирован, описан, понятно сделан, продуман. Мне показалось, что это хорошее решение не только с точки зрения безопасности, но и просто установки и управления Nginx. Можно через конструктор собрать набор опций, запустить Bunkerweb, а потом посмотреть в конфиге, как всё это реализовано. Так как всё собрано на базе open source продуктов, разобраться не трудно. При желании, можно что-то в свои наработки утащить.
Можно рассматривать этот продукт как панель управления для Nginx с базовым набором правил безопасности. Это если его просто с дефолтными настройками запустить. А дальше уже при желании можно наращивать функционал.
Сайт - https://docs.bunkerweb.io
Исходники - https://github.com/bunkerity/bunkerweb
Demo - https://demo.bunkerweb.io/
#waf #security #nginx
Недавно попал в любопытную панель управления веб серверами. Интерфейс явно напоминал о том, что где-то я его уже видел. Довольно быстро через поиск понял, в чём тут дело. Уже давно я писал про веб панель для управления haproxy - haproxy-wi. Проект с тех пор активно развивается, сменил имя, нарастил функционал и обзавёлся платной версией.
Теперь он называется Roxy-WI. У него, судя по всему, русскоязычные разработчики. Как минимум от двоих есть целая серия статей на хабре про этот продукт (тут и тут). К сожалению, с появлением платной версии, исчезли готовые пакеты для автоматической установки. Это не является какой-то большой проблемой, потому что по своей сути это обычное веб приложение, написанное на Python. Работает на базе Apache. В репозитории есть все конфиги, так что их просто нужно будет вручную разложить по нужным местам и самому установить зависимости. Подробная инструкция прилагается.
Roxy-WI умеет управлять настройками HAProxy, Apache, Nginx, Keepalived, Grafana, Prometheus, а так же HAProxy и Nginx exporters от него. Это такое комплексное решение по установке (указанные программы он умеет устанавливать самостоятельно, подключаясь по SSH) и управлению веб или прокси серверами.
Помимо непосредственно настройки, в Roxy-WI можно просматривать логи, настраивать WAF (Web Application Firewall), следить за сервисами с помощью мониторинга и оповещений. Есть интеграция с Fail2Ban.
Продукт функциональный и интересный. Если у вас задача поднять прокси сервер под HAProxy и для вас это не профильное направление, то можете воспользоваться панелью. Там есть в том числе и генератор конфигов под разные задачи.
Посмотреть, как всё это выглядит на практике, можно в ютубе на канале продукта:
⇨ https://www.youtube.com/@roxy-wi2201/videos
Там много примеров того или иного функционала. Или воспользоваться публичным демо:
⇨ https://demo.roxy-wi.org
Учётка - admin / admin. Панелька реально приятно и удобно смотрится. Оцените, как выглядит просмотр логов или редактор конфигов.
Сам я не сторонник готовых панелей. Никогда их не использую, если обслуживаю инфраструктуру сам. Но люди пользуются. Постоянно их встречаю. Например, самому собрать весь этот функционал, что есть в панели, надо постараться. А если нет опыта, так вообще употеть. А тут всё в одном месте и сразу с нормальным мониторингом.
⇨ Сайт / Исходники
#webserver #nginx #haproxy
Теперь он называется Roxy-WI. У него, судя по всему, русскоязычные разработчики. Как минимум от двоих есть целая серия статей на хабре про этот продукт (тут и тут). К сожалению, с появлением платной версии, исчезли готовые пакеты для автоматической установки. Это не является какой-то большой проблемой, потому что по своей сути это обычное веб приложение, написанное на Python. Работает на базе Apache. В репозитории есть все конфиги, так что их просто нужно будет вручную разложить по нужным местам и самому установить зависимости. Подробная инструкция прилагается.
Roxy-WI умеет управлять настройками HAProxy, Apache, Nginx, Keepalived, Grafana, Prometheus, а так же HAProxy и Nginx exporters от него. Это такое комплексное решение по установке (указанные программы он умеет устанавливать самостоятельно, подключаясь по SSH) и управлению веб или прокси серверами.
Помимо непосредственно настройки, в Roxy-WI можно просматривать логи, настраивать WAF (Web Application Firewall), следить за сервисами с помощью мониторинга и оповещений. Есть интеграция с Fail2Ban.
Продукт функциональный и интересный. Если у вас задача поднять прокси сервер под HAProxy и для вас это не профильное направление, то можете воспользоваться панелью. Там есть в том числе и генератор конфигов под разные задачи.
Посмотреть, как всё это выглядит на практике, можно в ютубе на канале продукта:
⇨ https://www.youtube.com/@roxy-wi2201/videos
Там много примеров того или иного функционала. Или воспользоваться публичным демо:
⇨ https://demo.roxy-wi.org
Учётка - admin / admin. Панелька реально приятно и удобно смотрится. Оцените, как выглядит просмотр логов или редактор конфигов.
Сам я не сторонник готовых панелей. Никогда их не использую, если обслуживаю инфраструктуру сам. Но люди пользуются. Постоянно их встречаю. Например, самому собрать весь этот функционал, что есть в панели, надо постараться. А если нет опыта, так вообще употеть. А тут всё в одном месте и сразу с нормальным мониторингом.
⇨ Сайт / Исходники
#webserver #nginx #haproxy
На днях писал про CIS. Решил не откладывать задачу и проработать документ с рекомендациями по Nginx. Делюсь с вами краткой выжимкой. Я буду брать более ли менее актуальные рекомендации для среднетиповых веб серверов. Например, отключать все лишние модули и делать свою сборку в обход готовых пакетов я не вижу для себя смыла.
📌Проверяем наличие настройки autoindex. В большинстве случаев она не нужна. С её помощью работает автоматический обзор содержимого директорий, если в них напрямую зайти, минуя конкретный или индексный файл.
Не должно быть настройки
📌Обращения на несуществующие домены или по ip адресу лучше сразу отклонять. По умолчанию отдаётся приветственная страница. Проверить можно так:
Если в ответ показывает приветственную страницу или что-то отличное от 404, то надо добавить в самую первую секцию server следующие настройки:
Можно просто удалить конфиг с дефолтным хостом, а приведённый код добавить в основной nginx.conf. Тогда это точно будет первая секция server. В остальных секциях server везде должны быть явно указаны
📌Параметр keep-alive timeout имеет смысл сделать 10 секунд или меньше. По умолчанию он не указан и им управляет подключающийся.
То же самое имеет смысл сделать для send_timeout.
Скрываем версию сервера параметром server_tokens. Проверяем так:
Отключаем:
📌Дефолтные страницы index.html и error page лучше отредактировать, удалив всё лишнее. Обычно они хранятся в директориях /usr/share/nginx/html или /var/www/html.
📌Запрещаем доступ к скрытым файлам и директориям, начинающимся с точки. Для этого в добавляем в самое начало виртуального хоста location:
Если нужно исключение, например для директории .well-known, которую использует let's encrypt для выпуска сертификатов, то добавьте его выше предыдущего правила.
📌Скрываем proxy headers. Добавляем в location:
📌Не забываем про настройку логирования. Логи нужны, но настройка сильно индивидуальна. Если логи хранятся локально, то обязательно настроить ротацию не только с привязкой ко времени, но и к занимаемому объёму. В идеале, логи должны храниться где-то удалённо без доступа к ним с веб сервера.
📌Настраиваем передачу реального IP адреса клиента в режиме работы Nginx в качестве прокси.
📌Ограничиваем версию TLS только актуальными 1.2 и 1.3. Если используется режим проксирования, то надо убедиться, что эти версии совпадают на прокси и на сервере. Если не уверены, что все ваши клиенты используют современные версии TLS, то оставьте поддержку более старых, но это не рекомендуется. Настройка для секции http в nginx.conf
📌Настраиваем ssl_ciphers. Список нужно уточнять, вот пример из документа CIS:
Дальше идут более узкие рекомендации типа ограничения доступа по IP, отдельных методов, настройка лимитов, более тонкие настройки таймаутов и т.д. В общем случае это не всегда требует настройки.
Ничего особо нового в документе не увидел. Большую часть представленных настроек я и раньше всегда делал. В дополнение к этому материалу будет актуальна ссылка на предыдущую заметку по настройке Nginx. Надо будет всё свести в общий типовой конфиг для Nginx и опубликовать.
#cis #nginx #security
📌Проверяем наличие настройки autoindex. В большинстве случаев она не нужна. С её помощью работает автоматический обзор содержимого директорий, если в них напрямую зайти, минуя конкретный или индексный файл.
# egrep -i '^\s*autoindex\s+' /etc/nginx/nginx.conf # egrep -i '^\s*autoindex\s+' /etc/nginx/conf.d/*# egrep -i '^\s*autoindex\s+' /etc/nginx/sites-available/*Не должно быть настройки
autoindex on. Если увидите, отключите. 📌Обращения на несуществующие домены или по ip адресу лучше сразу отклонять. По умолчанию отдаётся приветственная страница. Проверить можно так:
# curl -k -v https://127.0.0.1 -H 'Host: invalid.host.com'Если в ответ показывает приветственную страницу или что-то отличное от 404, то надо добавить в самую первую секцию server следующие настройки:
server { return 404;}Можно просто удалить конфиг с дефолтным хостом, а приведённый код добавить в основной nginx.conf. Тогда это точно будет первая секция server. В остальных секциях server везде должны быть явно указаны
server_name. 📌Параметр keep-alive timeout имеет смысл сделать 10 секунд или меньше. По умолчанию он не указан и им управляет подключающийся.
keepalive_timeout 10;То же самое имеет смысл сделать для send_timeout.
send_timeout 10;Скрываем версию сервера параметром server_tokens. Проверяем так:
# curl -I 127.0.0.1 | grep -i serverОтключаем:
server { ... server_tokens off; ... }📌Дефолтные страницы index.html и error page лучше отредактировать, удалив всё лишнее. Обычно они хранятся в директориях /usr/share/nginx/html или /var/www/html.
📌Запрещаем доступ к скрытым файлам и директориям, начинающимся с точки. Для этого в добавляем в самое начало виртуального хоста location:
location ~ /\. { deny all; return 404; }Если нужно исключение, например для директории .well-known, которую использует let's encrypt для выпуска сертификатов, то добавьте его выше предыдущего правила.
location ~ /\.well-known\/acme-challenge { allow all; }📌Скрываем proxy headers. Добавляем в location:
location /docs { .... proxy_hide_header X-Powered-By; proxy_hide_header Server; .... }📌Не забываем про настройку логирования. Логи нужны, но настройка сильно индивидуальна. Если логи хранятся локально, то обязательно настроить ротацию не только с привязкой ко времени, но и к занимаемому объёму. В идеале, логи должны храниться где-то удалённо без доступа к ним с веб сервера.
📌Настраиваем передачу реального IP адреса клиента в режиме работы Nginx в качестве прокси.
server { ... location / { proxy_pass 127.0.0.1:8080); proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }}📌Ограничиваем версию TLS только актуальными 1.2 и 1.3. Если используется режим проксирования, то надо убедиться, что эти версии совпадают на прокси и на сервере. Если не уверены, что все ваши клиенты используют современные версии TLS, то оставьте поддержку более старых, но это не рекомендуется. Настройка для секции http в nginx.conf
ssl_protocols TLSv1.2 TLSv1.3;📌Настраиваем ssl_ciphers. Список нужно уточнять, вот пример из документа CIS:
ssl_ciphers ALL:!EXP:!NULL:!ADH:!LOW:!SSLv2:!SSLv3:!MD5:!RC4;Дальше идут более узкие рекомендации типа ограничения доступа по IP, отдельных методов, настройка лимитов, более тонкие настройки таймаутов и т.д. В общем случае это не всегда требует настройки.
Ничего особо нового в документе не увидел. Большую часть представленных настроек я и раньше всегда делал. В дополнение к этому материалу будет актуальна ссылка на предыдущую заметку по настройке Nginx. Надо будет всё свести в общий типовой конфиг для Nginx и опубликовать.
#cis #nginx #security
Обработал несколько материалов на тему Nginx и подготовил универсальный конфиг с общими параметрами и некоторыми примерами настроек для виртуального хоста. Перед применением конфиг обязательно правится под ваш сервер. Нужно сделать некоторые подготовительные действия, чтобы на нём завестись. Как минимум, получить сертификаты, создать нужные директории, сгенерировать dhparam.pem, какие-то пути подправить и т.д.
✅ https://pastebin.com/dHscS0Vi
Это компиляция из моих же настроек в постах про Nginx (1, 2). Настройки TLS частично подсмотрел в генераторе от Mozilla:
⇨ https://ssl-config.mozilla.org/
Также кое что посмотрел в генераторе конфигов от Digital Ocean:
⇨ https://www.digitalocean.com/community/tools/nginx
Проверил всё это дело на nginx playground:
⇨ https://nginx-playground.wizardzines.com
А также с помощью анализатора конфигов Nginx от Яндекса gixy:
⇨ https://github.com/yandex/gixy
Настройки TLS проверил тут:
⇨ https://www.ssllabs.com/ssltest
Параметры моего конфига поддерживают работу TLS 1.0 и 1.1. За это дают большой штраф. Можете отключить эти протоколы и соответствующие шифры, но тогда, к примеру, отвалятся все старые андроиды версии 4 и ниже. Смотрите сами, нужна ли вам поддержка максимального числа оборудования, или важнее соответствие современным протоколам безопасности.
Конфиг получился не сферическим конём в вакууме, а рабочим вариантом. Я сам постоянно его использую, поэтому обновил свой рабочий шаблон, которым сам буду пользоваться.
📌 В завершении несколько полезных ссылок на мои материалы по теме Nginx:
◽ Подробная установка и настройка Nginx с примерами
◽ Автоматическое тестирование конфигурации Nginx
◽ Правильный redirect 301 для SEO в Nginx
◽ Nginx в качестве балансировщика нагрузки
◽ Проксирование запросов в nginx с помощью proxy_pass
◽ Сборка rpm пакета nginx с дополнительными модулями
#nginx #webserver
✅ https://pastebin.com/dHscS0Vi
Это компиляция из моих же настроек в постах про Nginx (1, 2). Настройки TLS частично подсмотрел в генераторе от Mozilla:
⇨ https://ssl-config.mozilla.org/
Также кое что посмотрел в генераторе конфигов от Digital Ocean:
⇨ https://www.digitalocean.com/community/tools/nginx
Проверил всё это дело на nginx playground:
⇨ https://nginx-playground.wizardzines.com
А также с помощью анализатора конфигов Nginx от Яндекса gixy:
⇨ https://github.com/yandex/gixy
Настройки TLS проверил тут:
⇨ https://www.ssllabs.com/ssltest
Параметры моего конфига поддерживают работу TLS 1.0 и 1.1. За это дают большой штраф. Можете отключить эти протоколы и соответствующие шифры, но тогда, к примеру, отвалятся все старые андроиды версии 4 и ниже. Смотрите сами, нужна ли вам поддержка максимального числа оборудования, или важнее соответствие современным протоколам безопасности.
Конфиг получился не сферическим конём в вакууме, а рабочим вариантом. Я сам постоянно его использую, поэтому обновил свой рабочий шаблон, которым сам буду пользоваться.
📌 В завершении несколько полезных ссылок на мои материалы по теме Nginx:
◽ Подробная установка и настройка Nginx с примерами
◽ Автоматическое тестирование конфигурации Nginx
◽ Правильный redirect 301 для SEO в Nginx
◽ Nginx в качестве балансировщика нагрузки
◽ Проксирование запросов в nginx с помощью proxy_pass
◽ Сборка rpm пакета nginx с дополнительными модулями
#nginx #webserver
Ещё один пример защиты веб сервера с помощью fail2ban. На этот раз пример будет более универсальный, который защитит не только от брута, но и от любых множественных подключений к серверу.
Для этого нам понадобятся модули nginx limit_req и limit_conn. С их помощью можно ограничить скорость обработки запросов с одного IP адреса. Для этого в основной конфигурации nginx, в разделе http, нужно добавить одну или несколько зон с максимальной скоростью обработки запросов или количеством числа соединений с одного IP. Я обычно использую несколько зон, чаще всего четыре. Одна для общего ограничения соединений, вторая для статики, третья для легких динамических запросов (обычные php страницы), четвёртая для тяжёлых динамических запросов (аутентификация, поиск, формирование большого каталога и т.д.).
Выглядят настройки примерно так:
Зону лучше называть по разрешённому лимиту, чтобы проще было использовать в настройках. Далее идём в конфиг виртуального хоста и там расставляем зоны в общей настройке server и разных locations. Примерно так:
Здесь главное без фанатизма использовать лимиты, особенно на общие страницы и статику, чтобы не блокировать поисковые системы или какие-то другие полезные боты. После настройки некоторое время понаблюдайте за ограничениями.
Сработанные ограничения будут отображаться в error.log nginx. Его мы и будем проверять с помощью fail2ban. Для этого добавляем в директорию
nginx-limit-conn.conf:
nginx-limit-req.conf:
И в
nginx-limit-conn.conf
nginx-limit-req.conf
Теперь нарушители лимитов будут отправляться в бан. При этом не так критично разрастание логов, так как error лог редко растёт быстро, даже если вас ддосят. Но всё равно не нужно забывать про его ротацию.
Все лимиты и реакции настраивайте в зависимости от вашей ситуации. Не надо брать мои значения из примера. Они сильно зависят от типа сайта и производительности сервера. Главное, как я уже сказал, без фанатизма. Лимиты должны быть комфортными для легитимных пользователей и систем.
Есть более простой в плане нагрузки способ блокировать тех, кто открывает слишком много соединений. Использовать системную информацию о подключениях, например, с помощью netstat и если превышен лимит, отправлять IP в бан. Я не очень люблю этот способ и редко использую, так как нет гибкой настройки по сайтам, урлам и т.д. Его стоит использовать, если вас ддосят и вам надо максимально быстро и дёшево по ресурсам блокировать атакующих. Иногда это помогает, если ддос не очень сильный и провайдер вас не отключает. Если интересно посмотреть эту реализацию, то напишите в комментах, я расскажу с примером.
#security #fail2ban #webserver #nginx
Для этого нам понадобятся модули nginx limit_req и limit_conn. С их помощью можно ограничить скорость обработки запросов с одного IP адреса. Для этого в основной конфигурации nginx, в разделе http, нужно добавить одну или несколько зон с максимальной скоростью обработки запросов или количеством числа соединений с одного IP. Я обычно использую несколько зон, чаще всего четыре. Одна для общего ограничения соединений, вторая для статики, третья для легких динамических запросов (обычные php страницы), четвёртая для тяжёлых динамических запросов (аутентификация, поиск, формирование большого каталога и т.д.).
Выглядят настройки примерно так:
limit_conn_zone $binary_remote_addr zone=perip:10m;limit_req_zone $binary_remote_addr zone=lim_50r:10m rate=50r/s;limit_req_zone $binary_remote_addr zone=lim_10r:10m rate=10r/s; limit_req_zone $binary_remote_addr zone=lim_3r:10m rate=3r/s;Зону лучше называть по разрешённому лимиту, чтобы проще было использовать в настройках. Далее идём в конфиг виртуального хоста и там расставляем зоны в общей настройке server и разных locations. Примерно так:
server { ... limit_conn perip 100; ...# поискlocation /?s= { limit_req zone=lim_3r burst=5 nodelay; ...}# динамика location ~ \.php$ { limit_req zone=lim_10r burst=15 nodelay; ...}# всё остальное location / { limit_req zone=lim_50r burst=65 nodelay; ...}}Здесь главное без фанатизма использовать лимиты, особенно на общие страницы и статику, чтобы не блокировать поисковые системы или какие-то другие полезные боты. После настройки некоторое время понаблюдайте за ограничениями.
Сработанные ограничения будут отображаться в error.log nginx. Его мы и будем проверять с помощью fail2ban. Для этого добавляем в директорию
/etc/fail2ban/filter.d два конфига.nginx-limit-conn.conf:
[Definition]failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting connections by zone.*client: <HOST>ignoreregex =nginx-limit-req.conf:
[Definition]ngx_limit_req_zones = [^"]+failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting requests, excess: [\d\.]+ by zone "(?:%(ngx_limit_req_zones)s)", client: <HOST>,ignoreregex = datepattern = {^LN-BEG}И в
/etc/fail2ban/jail.d два файла конфигурации:nginx-limit-conn.conf
[nginx-limit-conn]enabled = truefilter = nginx-limit-connport = httpaction = iptables-multiport[name=ConnLimit, port="http,https", protocol=tcp]logpath = /web/sites/*/logs/error.logbantime = 3600maxretry = 20nginx-limit-req.conf
[nginx-limit-req]enabled = truefilter = nginx-limit-reqaction = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]logpath = /web/sites/*/logs/error.logbantime = 3600maxretry = 10Теперь нарушители лимитов будут отправляться в бан. При этом не так критично разрастание логов, так как error лог редко растёт быстро, даже если вас ддосят. Но всё равно не нужно забывать про его ротацию.
Все лимиты и реакции настраивайте в зависимости от вашей ситуации. Не надо брать мои значения из примера. Они сильно зависят от типа сайта и производительности сервера. Главное, как я уже сказал, без фанатизма. Лимиты должны быть комфортными для легитимных пользователей и систем.
Есть более простой в плане нагрузки способ блокировать тех, кто открывает слишком много соединений. Использовать системную информацию о подключениях, например, с помощью netstat и если превышен лимит, отправлять IP в бан. Я не очень люблю этот способ и редко использую, так как нет гибкой настройки по сайтам, урлам и т.д. Его стоит использовать, если вас ддосят и вам надо максимально быстро и дёшево по ресурсам блокировать атакующих. Иногда это помогает, если ддос не очень сильный и провайдер вас не отключает. Если интересно посмотреть эту реализацию, то напишите в комментах, я расскажу с примером.
#security #fail2ban #webserver #nginx
На днях в комментариях подсказали полезный ресурс для проверки настроек безопасности в заголовках веб сервера — securityheaders.com. Для теста проверил свой сайт, получилась неутешительная картинка. Многие полезные с точки зрения безопасности заголовки не настроены. Стал разбираться.
Ключевым заголовком в плане обеспечения безопасности является CSP (Content Security Policy). С его помощью можно указать, с каких доменов может загружаться контент при просмотре сайта. Значение этого заголовка передаётся браузеру. Если он видит, что какие-то скрипты или прочие объекты пытаются загрузится с домена, который не разрешён в CSP, то блокирует их. Подобная защита, к примеру, помогает от XSS (cross site scripting) атак.
На деле оказалось, что конкретно мне настроить CSP будет очень непросто. Сначала бодро взялся за написание правил, потом приуныл. У меня крутится реклама от Яндекса, счётчики от Яндекс Метрики и Google Analytics. Чтобы все их корректно разрешить, надо прилично заморочиться, чтобы ничего не упустить. Вот пример настроек для метрики и рекламной сети. Ошибку можно сразу не заметить, а это приведёт к некорректному сбору статистики или ошибок в ней. А у кого-то ещё и шрифты внешние грузятся, библиотеки. Надо всё аккуратно проверять и настраивать.
Пока отложил вопрос. Конкретно для моего блога это некритично, но если у вас коммерческий сайт, то рекомендую заморочить и всё аккуратно настроить. По остальным заголовкам в сервисе есть описание, можно настроить. Но они уже не так важны и настраиваются проще.
У меня в итоге получилось вот так:
#nginx #webserver
Ключевым заголовком в плане обеспечения безопасности является CSP (Content Security Policy). С его помощью можно указать, с каких доменов может загружаться контент при просмотре сайта. Значение этого заголовка передаётся браузеру. Если он видит, что какие-то скрипты или прочие объекты пытаются загрузится с домена, который не разрешён в CSP, то блокирует их. Подобная защита, к примеру, помогает от XSS (cross site scripting) атак.
На деле оказалось, что конкретно мне настроить CSP будет очень непросто. Сначала бодро взялся за написание правил, потом приуныл. У меня крутится реклама от Яндекса, счётчики от Яндекс Метрики и Google Analytics. Чтобы все их корректно разрешить, надо прилично заморочиться, чтобы ничего не упустить. Вот пример настроек для метрики и рекламной сети. Ошибку можно сразу не заметить, а это приведёт к некорректному сбору статистики или ошибок в ней. А у кого-то ещё и шрифты внешние грузятся, библиотеки. Надо всё аккуратно проверять и настраивать.
Пока отложил вопрос. Конкретно для моего блога это некритично, но если у вас коммерческий сайт, то рекомендую заморочить и всё аккуратно настроить. По остальным заголовкам в сервисе есть описание, можно настроить. Но они уже не так важны и настраиваются проще.
У меня в итоге получилось вот так:
add_header X-Frame-Options "SAMEORIGIN";add_header Strict-Transport-Security max-age=15768000;add_header X-Content-Type-Options "nosniff" always;add_header Referrer-Policy "origin-when-cross-origin";add_header Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),\microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=*,payment=()";#nginx #webserver
▶️ В интернете масса статей и видео по настройке одного из самых популярных веб серверов Nginx. Разработчики в какой-то момент озаботились тем, чтобы самим выпустить канонические руководства, по которым стоит настраивать их веб сервер. Эти руководства они поддерживают и по мере необходимости обновляют.
Если вы отдаёте предпочтение информации от вендора, то для поиска инструкций разумнее обратиться на его официальный канал. К тому же все основные темы они вынесли в отдельный плейлист:
⇨ https://youtube.com/playlist?list=PLGz_X9w9raXf748bzuGOV6XJv7q3wLxhZ
🎓 Список тем из него:
◽How to define and publish APIs using NGINX Controller
◽How to Set Quotas with NGINX Plus
◽How to Set Up SSL with NGINX
◽How to Serve Static Content
◽How to Install NGINX on Debian and Ubuntu
◽How to create an API Dev Portal using NGINX Controller
◽Key Files, Commands, and Directories with NGINX
◽How to Install NGINX on CentOS and Red Hat
◽How to Install NGINX Amplify on Linux
◽NGINX Unit: From Zero to Lift Off
◽Dynamic SSL Key Management with NGINX
◽Getting Started with NGINX Service Mesh
◽NGINX as an API Gateway
◽How to Configure NGINX Plus as a WAF Using NGINX App Protect
◽NGINX App Protect Denial of Service (DoS) Overview
◽Configure NGINX as a Reverse Proxy
◽How to Streamline API Operations with API Connectivity Manager
Все видео на английском. Если не знаете его, можно спокойно всё понять через переводчик в режиме реального времени от Яндекса, или с английскими субтитрами. Часть тем актуальна для только версии Plus.
#nginx #видео #обучение
Если вы отдаёте предпочтение информации от вендора, то для поиска инструкций разумнее обратиться на его официальный канал. К тому же все основные темы они вынесли в отдельный плейлист:
⇨ https://youtube.com/playlist?list=PLGz_X9w9raXf748bzuGOV6XJv7q3wLxhZ
🎓 Список тем из него:
◽How to define and publish APIs using NGINX Controller
◽How to Set Quotas with NGINX Plus
◽How to Set Up SSL with NGINX
◽How to Serve Static Content
◽How to Install NGINX on Debian and Ubuntu
◽How to create an API Dev Portal using NGINX Controller
◽Key Files, Commands, and Directories with NGINX
◽How to Install NGINX on CentOS and Red Hat
◽How to Install NGINX Amplify on Linux
◽NGINX Unit: From Zero to Lift Off
◽Dynamic SSL Key Management with NGINX
◽Getting Started with NGINX Service Mesh
◽NGINX as an API Gateway
◽How to Configure NGINX Plus as a WAF Using NGINX App Protect
◽NGINX App Protect Denial of Service (DoS) Overview
◽Configure NGINX as a Reverse Proxy
◽How to Streamline API Operations with API Connectivity Manager
Все видео на английском. Если не знаете его, можно спокойно всё понять через переводчик в режиме реального времени от Яндекса, или с английскими субтитрами. Часть тем актуальна для только версии Plus.
#nginx #видео #обучение
Веб сервер Nginx уже давно умеет писать логи в json формате. В настройке по умолчанию используются текстовые логи. Да и почти везде, где мне приходится видеть логи веб сервера, они в текстовом формате. Если ещё не используете json формат для логов, то предлагаю вам пересмотреть свои привычки и использовать. Это удобно и для ручного просмотра логов, и для парсинга в тех или иных системах.
Настроить json логи очень просто. Вот пример для привычного формата combined, только в json. Добавляем в основной конфиг в раздел http { }.
И дальше либо в общую настройку, либо в настройку логов виртуального хоста добавляем:
Теперь, если отправить логи в ELK или Zabbix, их обработка будет упрощена, так как для json формата там есть готовые обработчики. А в консоли логи удобно смотреть с помощью jq. Смотрим весь лог:
Смотрим только список урлов, к которым были обращения:
Выводим полные записи логов, где только 404 коды ответов:
Теперь то же самое, только выводим не полные строки, а урл, где код ответа был 404:
Добавим сюда же информацию о времени запроса:
Думаю, идею вы поняли. Json смотреть проще, быстрее и гибче, нежели грепать или обрабатывать утилитами типа sed, awk и т.д. Надо только немного изучить синтаксис jq. Если хотите получить значения без кавычек " ", то добавьте к jq ключ -r:
Все переменные, которые вы можете использовать в логе, перечислены в документации к модулю ngx_http_core_module. Я обычно добавляю некоторые переменные к стандартным, а именно:
◽$request_length, $upstream_addr,
◽$upstream_status,
◽$upstream_response_time,
◽$upstream_connect_time,
◽$upstream_header_time,
◽$server_name,
◽$ssl_protocol,
◽$ssl_cipher.
#nginx #jq
Настроить json логи очень просто. Вот пример для привычного формата combined, только в json. Добавляем в основной конфиг в раздел http { }.
log_format json_combined escape=json '{' '"time_local":"$time_local",' '"remote_addr":"$remote_addr",' '"remote_user":"$remote_user",' '"request":"$request",' '"status": "$status",' '"body_bytes_sent":"$body_bytes_sent",' '"request_time":"$request_time",' '"http_referrer":"$http_referer",' '"http_user_agent":"$http_user_agent"' '}';И дальше либо в общую настройку, либо в настройку логов виртуального хоста добавляем:
access_log /var/log/nginx/access.log json_combined;Теперь, если отправить логи в ELK или Zabbix, их обработка будет упрощена, так как для json формата там есть готовые обработчики. А в консоли логи удобно смотреть с помощью jq. Смотрим весь лог:
# jq '.' access.logСмотрим только список урлов, к которым были обращения:
# jq '.request' access.logВыводим полные записи логов, где только 404 коды ответов:
# jq '. | select(.status=="404")' access.logТеперь то же самое, только выводим не полные строки, а урл, где код ответа был 404:
# jq '. | select(.status=="404") | .request' access.logДобавим сюда же информацию о времени запроса:
# jq '. | select(.status=="404") | .time_local,.request' access.logДумаю, идею вы поняли. Json смотреть проще, быстрее и гибче, нежели грепать или обрабатывать утилитами типа sed, awk и т.д. Надо только немного изучить синтаксис jq. Если хотите получить значения без кавычек " ", то добавьте к jq ключ -r:
# jq -r '.request' access.logВсе переменные, которые вы можете использовать в логе, перечислены в документации к модулю ngx_http_core_module. Я обычно добавляю некоторые переменные к стандартным, а именно:
◽$request_length, $upstream_addr,
◽$upstream_status,
◽$upstream_response_time,
◽$upstream_connect_time,
◽$upstream_header_time,
◽$server_name,
◽$ssl_protocol,
◽$ssl_cipher.
#nginx #jq
Более двух лет назад я вам уже рассказывал про Nginx Proxy Manager. Это веб панель для управления Nginx в режиме proxy_pass. С той заметки прошло много времени, а панелька эта очень активно развивается. Недавно в одном из видео я увидел эту панель в работе. Автор её очень сильно нахваливал.
Посмотрел на неё ещё раз. Она с тех пор заматерела. Изменила адрес репозитория, собрала много звёзд на гитхабе (14,1k, было ~2k). Получила красивую документацию. При этом не обросла лишним функционалом, не стала платной. Автору явно нравится его детище. Постоянно видны исправления, выход новых версий.
Живёт всё в одном контейнере, если ваc устраивает хранить состояние панели в базе SQLite. В противном случае можете настроить хранение в MySQL. В документации автор предлагает docker-compose файл для запуска, но так как контейнер всего один, проще запустить напрямую через docker:
Далее идёте на 81-й порт своего сервера и логинитесь под учёткой admin@example.com / changeme. Не забудьте сразу поменять, если он смотрит в интернет. Вся конфигурация и сертификаты будут храниться в созданных директориях, так что их удобно бэкапить.
Это хобби-проект одного разработчика, так что в прод такое ставить не стоит. А себе домой или для тестов вполне сойдёт. Приятный продукт с красивым веб интерфейсом, который решает одну конкретную задачу. И делает это хорошо. Рекомендую, если вам нужна подобная функциональность.
⇨ Сайт / Исходники / Обзор / NPM vs Traefik
#nginx #webserver
Посмотрел на неё ещё раз. Она с тех пор заматерела. Изменила адрес репозитория, собрала много звёзд на гитхабе (14,1k, было ~2k). Получила красивую документацию. При этом не обросла лишним функционалом, не стала платной. Автору явно нравится его детище. Постоянно видны исправления, выход новых версий.
Живёт всё в одном контейнере, если ваc устраивает хранить состояние панели в базе SQLite. В противном случае можете настроить хранение в MySQL. В документации автор предлагает docker-compose файл для запуска, но так как контейнер всего один, проще запустить напрямую через docker:
# docker run -d --restart unless-stopped \-p 80:80 -p 81:81 -p 443:443 \-v ./data:/data -v ./letsencrypt:/etc/letsencrypt \jc21/nginx-proxy-manager:latestДалее идёте на 81-й порт своего сервера и логинитесь под учёткой admin@example.com / changeme. Не забудьте сразу поменять, если он смотрит в интернет. Вся конфигурация и сертификаты будут храниться в созданных директориях, так что их удобно бэкапить.
Это хобби-проект одного разработчика, так что в прод такое ставить не стоит. А себе домой или для тестов вполне сойдёт. Приятный продукт с красивым веб интерфейсом, который решает одну конкретную задачу. И делает это хорошо. Рекомендую, если вам нужна подобная функциональность.
⇨ Сайт / Исходники / Обзор / NPM vs Traefik
#nginx #webserver
Веб сервер Nginx поддерживает интеграцию с языком программирования Lua. Реализуется это с помощью специального модуля для Nginx. В стандартных пакетах с nginx чаще всего нет этого модуля. В Debian и Ubuntu его можно поставить с помощью пакета nginx-extras:
Также существует веб сервер на основе Nginx и Lua — OpenResty . Он полностью совместим с Nginx и следует за его релизами. Отличает его только наличие дополнительных модулей для работы с Lua.
Чаще всего в Nginx Lua используют для борьбы с ddos атаками. Вот навороченный пример готового скрипта на lua для этого — Nginx-Lua-Anti-DDoS. Я его попробовал, работает нормально. И очень удобно. У него куча возможностей по блокировке тех или иных клиентов. С базовыми настройками он блокирует некоторых ботов, подсети некоторых хостеров и осуществляет защиту от ботов с помощью страницы заглушки на javascript (пример на картинке), которая добавляет зашифрованную куку. Потом редиректит на основную страницу и проверяет эту куку.
Не буду расписывать установку и настройку этого скрипта. Всё необходимое есть в репозитории. Я немного повозился, но всё настроил. Если вас донимают какие-то боты, попробуйте, должно помочь. Скрипт позволяет в одном месте работать со всеми ограничениями и настройками, что удобно. Если не нужен, можно очень быстро его отключить. Все настройки прокомментированы в самом скрипте.
По теме nginx и lua очень много всего гуглится, если искать по словам nginx lua antiddos. Вот ещё пару примеров:
⇨ LUA в nginx: слегка интеллектуальный firewall
⇨ Защита от DDoS на уровне веб-сервера
Кстати, CloudFlare как раз и осуществляет свою защиту на базе Lua с помощью веб сервера OpenResty. Или осуществлял. Сейчас может уже на что-то другое перешли. Так что если работаете с веб серверами и не используете Lua, обратите на него внимание. Очень многие вещи с его помощью делать удобно.
#nginx #webserver
# apt install nginx-extrasТакже существует веб сервер на основе Nginx и Lua — OpenResty . Он полностью совместим с Nginx и следует за его релизами. Отличает его только наличие дополнительных модулей для работы с Lua.
Чаще всего в Nginx Lua используют для борьбы с ddos атаками. Вот навороченный пример готового скрипта на lua для этого — Nginx-Lua-Anti-DDoS. Я его попробовал, работает нормально. И очень удобно. У него куча возможностей по блокировке тех или иных клиентов. С базовыми настройками он блокирует некоторых ботов, подсети некоторых хостеров и осуществляет защиту от ботов с помощью страницы заглушки на javascript (пример на картинке), которая добавляет зашифрованную куку. Потом редиректит на основную страницу и проверяет эту куку.
Не буду расписывать установку и настройку этого скрипта. Всё необходимое есть в репозитории. Я немного повозился, но всё настроил. Если вас донимают какие-то боты, попробуйте, должно помочь. Скрипт позволяет в одном месте работать со всеми ограничениями и настройками, что удобно. Если не нужен, можно очень быстро его отключить. Все настройки прокомментированы в самом скрипте.
По теме nginx и lua очень много всего гуглится, если искать по словам nginx lua antiddos. Вот ещё пару примеров:
⇨ LUA в nginx: слегка интеллектуальный firewall
⇨ Защита от DDoS на уровне веб-сервера
Кстати, CloudFlare как раз и осуществляет свою защиту на базе Lua с помощью веб сервера OpenResty. Или осуществлял. Сейчас может уже на что-то другое перешли. Так что если работаете с веб серверами и не используете Lua, обратите на него внимание. Очень многие вещи с его помощью делать удобно.
#nginx #webserver
