Nginx *

Количество DDoS-атак растёт экспоненциально. В этой статье мы разберём практические приёмы настройки Nginx и Linux, которые помогут вашему сервису не рухнуть в самый неподходящий момент.

Привет, Хабр! Меня зовут Сергей Черкашин, и я — руководитель команды по эксплуатации систем и защиты от DDoS-атак в Wildberries & Russ.

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

За выходные поднял «свой Dropbox/Google Drive» на Raspberry Pi 5 через Docker-compose: Nextcloud + PostgreSQL + Redis + Nginx Proxy Manager + автокрон. Бонусом — SMTP-уведомления, капча на регистрации и аккуратный config.php. Ключевой инсайт: даже без специфических знаний это реально, если уметь правильно «разговаривать» с ИИ и копипастить команды не глядя в дебри мануалов.

Контроль основных метрик веб‑сервера или балансировщика — основа надежной работы системы. Ранее мы разбирали работу с мониторингом через API и Angie Console Light, но это не единственный вариант, доступный в Angie. Использование встроенного экспортера Prometheus и визуализация через Grafana дают принципиально другие возможности. Итак, в этой статье мы запустим полноценную систему мониторинга Angie.

Наряду с развитием искусственного интеллекта, облачные вычисления названы основополагающей технологией будущего. Наверное, многие слышали, как важны и ценны знания Docker и Kubernetes в современном мире ИТ. Но как подступиться к этим технологиям, если ранее с ними вы не сталкивались?

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

Я — Bitrix-разработчик со стажем 8+ лет.
Начинал дружить с битрой ещё с версии 12 — когда всё было максимально квадратно, можно сказать что я тот самый "проженный" битриксоид, а любой деплой превращался в ночной марафон из консоли, логов и bash-скриптов.

Со временем стало понятно: BitrixEnv решает задачу,
но не решает боль инженера.
Он требует привыкания, ручной рутины и десятков часов конфигурации.

Поэтому я переписал его заново — на Python + HTML5 + Vanilla JS.
Без bash-магии запрещенной в хогвартсе и с прозрачной архитектурой собрав все года боли общения в единую точку невозврата возрождение Битрикс!

Современная инфраструктура приложений динамична и требует гибкости от конфигурации ключевых элементов. В этой статье мы разберём все варианты реализации динамических групп серверов (upstream) в Angie. С помощью этих методов вы сможете изменять состав и статус серверов без вмешательства в конфигурацию Angie. 

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

Изначально решение виделось простым — настроить Nginx и прописать правила маршрутизации. Ключевые трудности скрывались в деталях: тонкой настройке редиректов, работе с access token и интеграции с бэкенд-сервисами, потребовавших значительного внимания.

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

Один из самых простых способов ускорить работу сайтов и снизить нагрузку на инфраструктуру — корректно использовать клиентское кэширование. Механизм одновременно и простой, и сложный. В этой статье посмотрим, как можно управлять клиентским кэшированием в веб‑сервере Angie.

Когда вы работаете с распределённой системой — будь то микросервисы, фронтенд + бэкенд или nginx + приложение — жизненно важно иметь возможность «протянуть» один и тот же идентификатор запроса через все её компоненты. Это позволяет сопоставлять логи из разных источников, быстро находить ошибки и проводить корреляционный анализ.

В nginx для этого из коробки есть переменная $request_id — 32-символьный hex-идентификатор (например, a1b2c3d4e5f678901234567890abcdef). Его можно передать бэкенду через proxy_set_header X-Request-ID $request_id; или fastcgi_param HTTP_X_REQUEST_ID $request_id;, а также сохранить в access-логах.

Однако стандартный $request_id — это просто случайная строка без временной привязки и без структуры, удобной для аналитики. В этой статье мы рассмотрим, как улучшить ситуацию с помощью ULID и UUIDv7.

Возможности Angie в качестве веб‑сервера и обратного прокси довольно известны. Но кроме работы на уровне L7 (HTTP), мы можем применять его на L4 (TCP и UDP) в качестве балансировщика и прокси‑сервера. Именно об этой функциональности мы и поговорим в сегодняшней статье.

Привет, друзья! Сегодня расскажу вам, как я установил n8n (крутой инструмент для автоматизации процессов) и Nginx Proxy Manager на свой VPS-сервер в Beget. Если вы читали мою предыдущую статью, то уже знаете, что у меня уже установлен Portainer.io , который делает работу с Docker контейнерами намного проще. Если нет — не переживайте, я всё объясню так, будто это мой первый раз (и, честно говоря, так оно и есть 😅).

Буду хвастаться своим прекрасным рабочим столом на macOS.

От читателей жду комментарии на тему того, как это можно улучшить, потому что мои решения далеки от идеала — сделано «на коленке».

Часть этого процесса я уже описывал в предыдущей статье.

Как и многие, я понял, что рабочий стол — это не место для файлов и папок.

Это не секрет, что возможность класть туда всё нужное и ненужное — ужасная практика, порождающая хаос.

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

Примерно 10 лет назад я понял, что хочу видеть там канбан-доску.

Зачем? Чтобы это постоянно включало в работу.

Как я это сделал:
Основной template, — Vite + Tailwind, с вертикальными фреймами и кнопкой для открытия меню. Plash опенсерсная утилита которая заменяет рабочий стол на safari с любой ссылкой или локальным html. и любые веб приложения.

Безусловно, тема обхода ограничений изнутри страны сейчас актуальна. Но что делать, если нужно открыть сайты, которые заблокировали пул IP-адресов из РФ? Например, было интересно создать аналог DNS‑сервера вроде comss, который открывает доступ к заблокированным AI, игровым серверам и тому подобному, с чем не смогут помочь обходы DPI (Возможно, эксперты напишут замечания в комментариях).

Один из возможных способов, который получилось реализовать у меня, представлен ниже.

Нам понадобится VPS в локации, через которую мы хотим быть видимы для нужных нам сервисов.

Для примера можно вспомнить Twitch, который заблокировал доступ к просмотру стримов в качестве 1080p и 1440p для пользователей из РФ.

Идём на страницу справки по бета‑тестированию качества 2k на Twitch и смотрим регионы, в которых оно доступно.

Не секрет, что штатные возможности мониторинга Nginx довольно скромны. Решалась эта задача различными способами: либо парсингом логов, либо сторонними модулями. При создании Angie эту проблему решили радикально и сразу несколькими способами. Начнём с исторического модуля stub_status.

Всем привет 👋

Врываюсь на Хабр с двух ног со своей первой статьей.

Всё чаще меня посещала мысль: а где на самом деле лежат наши фотографии, документы и личные переписки? Кто имеет к ним доступ и на каких условиях, точно ли все мои данные конфиденциальны? Любознательность и стремление к независимости хранения данных привела меня к идее своего облака, не где-то в далеком ЦОД, а здесь, дома, в гостиной, тихо жужжа в корпусе размером с книгу. Но есть один критически важный нюанс, который отделяет любительскую поделку от полноценной замены коммерческим сервисам — безопасный доступ извне. Зачем нам HTTPS, если для внутренней сети хватило бы и простого HTTP?

Привет! Я Ваня, системный администратор в Selectel. Представим ситуацию: вам нужно организовать доступ к удаленному офису через Cisco AnyConnect, который по какой-либо причине должен работать на стандартном 443 порте. При этом на том же порте развернут веб-сервер, а позже понадобится там же развернуть FTPS, SSTP и еще 100 500 сервисов, которые используют TLS. Под катом рассмотрим, как решить проблему безопасно и относительно быстро.

Так уж вышло, что я сел писать статью о нашем с Саней (@MrKaban4ik) приключении в багбаунти. Сразу предупреждаю: бывалым исследователям наша история покажется не самой захватывающей. Она не о сложных цепных эксплойтах, а о самом начале пути — о том, как ты делаешь первый шаг на площадке и, затаив дыхание, ждешь вердикта по своему первому отчету. Именно эти первые «хваты» вселяют ту самую уверенность, что ты на правильном пути.

{Багбаунти-кидди презенс}

Чуть предыстории. НЕБОЛЬШАЯ ИСТОРИЧЕСКАЯ СПРАВКА НА 5 МИНУТ. Февраль 2025 года.

Мы с Александром часто участвуем в CTF в рамках студенческой команды Capybaras. Недавно закончился Чемпионат России по спорт проге ИБ, мы написали квалы на чемпионат банка РФ и нас зовут в Екатеринбург на Уральский форум. Вуз платит — едем. К этому моменту мы знаем о вебе что он существует и что если нет никаких ограничений на загрузку можно загрузить файлик.php который может быть шелом и как то магически команды на OS исполняет. О багбаунти мы слышали, но не седели особо — потому что просто не знаешь что искать. Мы с Александром собираем вещи, едим в Сочи и оттуда летим в Екатиб. Хотя давайте меньше деталей, вы же тут не до вечера собрались читать. В общем‑то первый наш форум по ИБ, много вендоров и лекций в молодежной программе. Знакомлюсь с ДВФУ‑шниками, до сих пор {heart}. Но вернемся к форуму. Среди вендоров был и BI.ZONE. Интерес конечно же у меня к нему был потому что они недавно выпускают Threat Zone и как только открылась выставка, а у нас шла кибербитва — я решаю незаметно сбежать и сходить залутать заветный журнальчик. Подхожу к стенду, решаю потыкать стендик и подходит какой‑то тип в черном костюме и начинает спрашивать знаком ли я с продуктами компании, я жестко говорю что знаю EDR и какой то прикол с жуками, называемый bugbounty. А этот тип говорит: «Я глава этого продукта». Таким образом мы познакомились с человеком по имени Андрей Левкин — который сыграет на самом деле большую роль в том, чтоб мы начали багхантить. Форум заканчивается и мы едем домой.

Привет, Хабр!

Сегодня разберём то, что обычно остаётся в уголке конфигов и редких комментов в тикетах. Sticky-сессии в stream для RDP и SSH. В частности, как в Angie вытащить RDP-cookie на preread-стадии и привязать пользователя к одному backend’у без плясок с костылями в L4.

В реальных RDP-фермах два симптома встречаются чаще всего. Первый — периодический разлёт сессий: пользователь переподключается и попадает на другой сервер, там у него пустой рабочий стол, злость, звонок в поддержку. Второй — попытки лечить это на уровне клиентского IP, которые ломаются при NAT и мобильных операторах. Решение простое: читать RDP-cookie до принятия решения о балансировке и привязывать сессию к серверу. Angie это умеет из коробки модулем rdp_preread и sticky в stream-upstream.

Привет, Хабр!

Сегодня я хочу разобрать одну конкретную, но до безобразия полезную задачу, с которой мы столкнулись, когда наш сервис стал обрастать клиентами. Задача простая на словах, но с изюминкой: маршрутизировать входящие TLS-соединения в stream-модуле Nginx на разные бэкенд-пулы в зависимости от имени сервера SNI, которое клиент указывает в самом начале рукопожатия. Причем арендаторов могут добавлять каждую пятницу, а перезагружать Nginx каждый раз — это не наш метод. Конфиги должны быть статичными, а вот список арендаторов — динамическим, живущим где-то в Redis или etcd.

Привет, Хабр!

Вы, наверно, привыкли к стандартным HTTP-ответам – 200, 301, 404, 500 и т. д. А тут подкрался новый статус 103 – Early Hints. Это небольшой пинок браузеру: сервер шлет код 103 с заголовками Link: rel=preload ещё до того, как сформировал основной HTML. Пока бэкенд думает над ответом, браузер параллельно начинает грузить критические ресурсы (CSS, JS, шрифты и т. д.). Звучит просто, но эффект на производительность и LCP может быть весьма значительным.