Nginx *

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

Прежде чем погрузиться в рассмотрение Nginx и Keycloak, давайте вернемся к некоторым основополагающим концепциям безопасности.

Понимание разницы: Аутентификация vs Авторизация

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

1. Аутентификация

Определение: Аутентификация - это процесс проверки подлинности личности пользователя, системы или приложения. Она отвечает на вопрос: «Вы тот, за кого себя выдаете?»

Как это работает: Наиболее распространенной формой аутентификации является комбинация имени пользователя и пароля. Когда пользователь вводит эти учетные данные, система сравнивает их с сохраненными данными, чтобы подтвердить его личность. Другие методы включают биометрию (например, распознавание отпечатков пальцев или лица), OTP (одноразовые пароли) и аппаратные токены.

Читая такие статьи как про Капибару, мне хочется упомянуть один свой старый/новый проект, в изначальном виде я затеял как проект реставрации старого форума сети Минска (uruchie.org) из далеких 2006-2012 годов, который хранился у меня в замороженном виде последние 10 лет. Не так давно я решил его расконсервировать и заняться реставрацией в свободное время, того, фактически, что осталось еще со времен локальных сетей. 

Я сразу отбросил почти все что было, это старый движок vBulletin - на тот момент крайне перспективный и развивающийся движок форума на PHP, и убрав почти все, оставив только базу данных из 250 000 сообщений и 5000 пользователей начал реализовывать новые концепции которые хотелось видеть. Если кому-то интересно то, кстати, одна из причин гибели такого старого и долгого проекта был именно vBulletin и безопасность.

Ссылка на рабочую версия нового ресурса: https://talkvio.com (заходим, регистрируемся, пишем, предлагаем идеи)

За основу взял что душе угодно для таких целей:

Backend: NodeJS + MySQL + Redis + Manticore (у меня с ним был крайне приятный опыт на других своих старых проектах) + Bash + отдельные модули на Python + Nginx

UI: React

Дальше в статье будет рассказываться как в проекте организован серверный рендеринг исключительно для поисковиков, и как вы можете повторить опыт для своего JS проекта не выполнял почти никаких модификаций проекта на основе пакета Puppeteer + Nginx.

Nginx — прекрасный и надёжный обратный прокси-сервер. Уже много лет он является самым популярным инструментом обслуживания огромного количества веб-сайтов. Но его бесплатная версия имеет ряд ограничений в части работы с серверами-бэкендами. Давайте поговорим об этих ограничениях и о том, можем ли мы, не меняя Nginx как основную платформу, качественно улучшить наши возможности по распределению трафика между бэкендами.

Всем читателям, привет! Хочется поделиться своим опытом по созданию Nginx reverse proxy для интересного кейса.

• Есть 1 ip и на него нацелено n доменов
• Есть n серверов (за NAT)
• Когда пользователь заходит на домен_1 попадает на сервер_1
• Когда пользователь заходит на домен_2 попадает на сервер_2
• Когда пользователь заходит на домен_n попадает на сервер_n

Главная идея была в том, чтобы проверить возможно ли из старого Android устройства сделать "полноценный" сервер с nginx, php-fpm, MariaDB и запустить на этом Wordpress. Оказывается можно и при этом с хорошим результатом.

Устройство: Xiaomi Mi 4c 2015 года, разблокирован разгрузчик, TWRP, Android 10 (Havoc OS 3.0), Gapps не устанавливались для экономии ресурсов, root отсутствует.

Здравствуй, дорогой читатель. Меня зовут Дмитрий. Я — системный инженер компании «Веб-сервер». На протяжении моего опыта оказания услуг технической поддержки сначала в компании Nginx, а теперь и в компании разработчика российского веб-сервера Angie, мы отвечаем на очень популярный вопрос: «Как организовать мониторинг состояния веб-сервера?». А вот так.

Привет уважаемые, хабровчане!

Иногда возникает потребность выдать доступ пользователям только к одному веб ресурсу в компании. Самый очевидный вариант сделать это через урезанный VPN, но тут возникают препятствия в виде девайсов, с которых подключаются пользователи, и качество интернета, которым они пользуются. OpenVPN, который мы пробовали использовать для этих целей, не дал желаемого результата, подключение было медленным и нестабильным. Поэтому было найдено альтернативное решение.

Эта статья — заключительная (наконец‑то!) из моего огромного цикла про недетектируемые инструменты для обхода блокировок. В предыдущих публикациях я упоминал, что клиенты и серверы XRay (форк V2Ray) и Sing‑box при использовании протоколов VLESS/VMess/Trojan могут работать через веб‑сокеты и gRPC, что позволяет подключаться к даже заблокированным Роскомнадзором прокси‑серверам через CDN (content delivery или content distribution network) и дает дополнительные преимущества. Сегодня мы поговорим об этом поподробнее.

Content Security Policy (CSP) - это механизм безопасности веб-приложений, который используется для сокращения рисков, связанных с атаками, такими как внедрение скриптов (XSS) и выполнение нежелательного кода (инъекция). CSP позволяет веб-разработчикам указывать браузерам, из каких источников разрешено загружать ресурсы, такие как скрипты, стили, изображения, шрифты и другие элементы.

• Заливка проекта на GitHub.
• Аренда и настройка облачного сервера по SSH.
• Настройка nginx для раздачи статических файлов.
• Сжатие бандла.
• Подключение домена.
• Настройка HTTPS.
• Настройка Docker.

Nginx, универсальный веб-сервер, имеет ключевое значение для многочисленных интернет-инфраструктур, занимает доминирующую долю рынка с момента своего создания в 2004 году, получил широкое распространение на веб-сайтах и в контейнерах Docker. В этой статье рассматриваются тонкости Nginx, основное внимание уделяется директивам location и alias, которые играют центральную роль в том, как Nginx обрабатывает определенные URL-адреса. Мы также изучим потенциальные уязвимости, возникающие из-за неправильных конфигураций, и продемонстрируем, как они могут привести к эксплойтам безопасности, опираясь на исследования, представленные Orange Tsai на конференции BlackHat 2018.

Руководство дополнительно проиллюстрирует эти моменты посредством тщательного изучения популярных репозиториев с открытым исходным кодом, с использованием GitHub Code Search для выявления потенциальных уязвимостей конфигурации Nginx. Реальные тематические исследования с участием Bitwarden и Google HPC Toolkit подчеркнули значительный риск раскрытия данных, если эти уязвимости не будут устранены. Кроме того, мы представим NavGix, автоматизированный инструмент, предназначенный для обнаружения этих уязвимостей методом «черного ящика», предоставляющий исчерпывающую информацию о сложностях, уязвимостях и возможных неправильных конфигурациях Nginx.

В статье рассказывается о новом веб-сервере Nginx Unit. В ней можно узнать подробнее о самом веб-сервере, его установке и настройке: как использовать слушатели, маршрутизацию, как устанавливать сертификаты TLS. Статья покажет насколько работать с ним легко и что огромные конфиги потихоньку уходят в прошлое.

Привет, Хабр. Я — Влад Климанов, бэкенд-разработчик в ДАЛЕЕ. В декабре 2022 года мы запустили сайт Финзачета — самого массового зачета по финансовой грамотности в стране. Собрал в статью историю о том, как мы работали с проектом, основной особенностью которого был сжатый срок: всего 1,5 месяца для реализации сайта, который выдержит поток миллионов пользователей. Бонусом внутри немного статистики о финансовой грамотности

Актуальной задачей для веб-ресурса в нынешних реалиях является установка ограничений доступа по регионам, либо географическая привязка выдаваемой информации с учетом региона. Одним из решений, которые можно использовать для этих целей, является база данных и американский сервис MaxMind GeoIP2. Сервис привлекает огромным объемом и детальностью информации, но имеет свои особенности. Так, Крым, ДНР, ЛНР, Запорожская и Херсонская области а также Севастополь указаны в базе как регионы Украины. Соответственно, если, скажем, разрешить доступ к ресурсу только с территории РФ, то эти регионы останутся не у дел.

Так я, первоначально настроив свой ресурс только на доступ с территории РФ, обнаружил, что мои друзья из Крыма и ДНР не могут получить доступ (получают специальную версию страницы, с ограниченным объемом информации). Проблема эта легко решается, и в этой статье я покажу, как именно можно простым спососбом ее решить, а также покажу действующий пример конфигурации сервера.

Данная статья описывает утилиту для генерации статических страниц ошибок, используемых в качестве замены стандартным страницам. В статье подробно описаны возможности утилиты, среди которых шаблонизация, стилизация, локализация, генерация сниппетов для настройки сервера. Проект является Open Source, и открыт для новых идей и запросов.

Я backend разработчик с опытом около 3-х лет, пишу в основном на Golang. Проработал в нескольких крупных российских компаниях. Сейчас я параллельно со своей работой пытаюсь сделать удобный, дешевый VPN сервис с высокой пропускной способностью. В этой статье я хочу просто рассказать про жизненный цикл своего проекта. Возможно кому-то будет просто интересно почитать, а кто-то может почерпнуть что-то новое для себя.

В этой статье я покажу, как организовать простейший автодеплой на сервере. Для автодеплоя через Bitbucket Webhooks и PHP не нужно использовать какие-то сложные решения.

Для начала можно подумать, что git pull выполняется через PHP с помощью этого куска кода:

В интернете много информации о том, как развернуть MinIO на хосте по порту, но практически нет о том, что делать, если порт наружу открывать не хочется, а файлы загрузить надо? Потратив пару дней на разбирательство, получился вполне "рабочий велосипед". Я решил воспользоваться Законом Каннингема и разместить своё решение. Надеюсь, оно не ложное. 🙂

Этот небольшой гайд для тех, кто давно хотел сделать свой сайт на своем домене и разместить на своем сервере, но все никак.

С чем будем работать далее: 

• Узнаем, что такое доменное имя и как оно связано с DNS.

• Зарегистрируем свой домен и узнаем, что это быстро, легко и может стоить 199 рублей за первый год.

• Настроим ресурсные записи, чтобы привязать доменное имя сайта к вашему IP‑адресу. Дополнительно рассмотрим, как при помощи DDNS автоматизировать обновление адресов, если у вас нет выделенного IP.

• Развернем виртуальную машину, на которой будет работать сайт. (аналогичные действия можно проделать и на каком‑нибудь специально выделенном для этого физическом железе или VPS).

• Развернем http‑сервер NGINX.

• Настроим конфигурацию для размещения сайта и проверим, что сайт‑лендинг открывается.

• Узнаем, как прикрутить ssl сертификаты и https.

• Если используются какие‑то другие сервисы, например, nodered, узнаем, как использовать купленный домен в своих сервисах в варианте, например, nodered.mydomainhere.ru и т.д., вместо 77.88.111.222:1880 или mydomainhere.ru:1880 (т. е. поработаем с доменами третьего уровня).

• Получим бесплатные Wildcard SSL сертификаты от Lets Encrypt при помощи утилиты Cerbot, и настроим их для использования в NGINX.

Тех, кому интересно, приглашаю далее.

NGINX подготовил бинарники для предварительной версии реализации QUIC+HTTP/3: "Мы рады сообщить, что наша предварительная реализация поддержки NGINX для QUIC+HTTP/3 теперь доступна в виде предварительно собранных бинарных пакетов для двух дистрибутивов: Red Hat Enterprise Linux 9 и Ubuntu 22.04"

Подробности под катом.