Я устал каждый раз гуглить одно и то же в nginx — и сделал инструмент, который объясняет конфиги на русском
Очередной генератор nginx-конфигов? Нет. Ну, почти нет.
Данный таск был частью 5 сезона CTF, который проходил на площадке ACLabs. Машина необычная с увлекательным сюжетом и интересными уязвимостями.
Условие задачи:
Борис — старый почтовый голубь. Катя, его голубка, улетела к наглому Воробью. Три дня Борис пил дешёвое пойло и строчил план мести. Теперь этот план у тебя. Помоги Борису пробраться в цифровое гнездо Воробья, украсть его аккаунт и стать рутом. Следуй за пьяными записками — там всё сказано и даже больше. Внимание, стенд будет полностью готов только по истечении обратного времени отсчета, даже если адрес появился раньше!
Цепочка атаки
Атакующая цепочка «PigeonsRevenge» комбинирует одну реальную критическую CVE (Webmin 1.910 — CVE-2019-15107, 9.8 CRITICAL) с набором классических техник ATT&CK: активная разведка → port knocking → эксплуатация публичного приложения → Metasploit reverse-shell → туннелирование Ligolo-ng → инъекция через переменную окружения в кастомный бинарник → обход фильтра табуляцией → закрепление с root-привилегиями.
Ваши логи забиты попытками входа в .env, .git и wp-login.php? Пока бот стучится в Nginx, ваш сервер уже тратит драгоценные ресурсы. Я решил перенести фильтрацию в ядро Linux и делюсь рабочим кейсом эшелонированной обороны на базе ipset и CrowdSec.
В предыдущей статье я рассказал о том с какими проблемами столкнулся при создании своего решения для управления прокси. Как я понял из комментариев, прокси довольно быстро отлетали не только из-за того что я что-то не так делал, но в том числе из-за проблем телеги. Но РКН не стоит на месте и появилась новая проблема - на горизонте показался лимит в 15Гб зарубежного трафика. Как я понял, по слухам в начале он будет распространяться на мобильный интернет, так что я сразу решил добавить в свою панель возможность создания цепочки подключений.
Я решил погрузиться в мир собственных VPN серверов, после того как очередной раз сервис, за который я платил деньги перестал качественно работать, а поддержка из-за перегруженности отвечала шаблонами, в духе "Надо подождать, мы скоро все починим".
Набрав в поиске "VDS в Германии аренда" я с удивлением обнаружил, что арендовать такой сервер можно с российской карты и за вполне вменяемые деньги. Арендовав сервер на неделю, я принялся поднимать собственный MTProto для телеги. Использовал я образ https://github.com/telemt/telemt
Я поднял свой контейнер с прокси, проверил, что все работает и обрадовался. Но сразу же встал следующий вопрос - CLI это хорошо, но хотелось бы какой-то GUI для управления прокси. Я перепробовал несколько панелей и остановился на https://github.com/MaksimTMB/mtg-adminpanel. её суть в том, что панель можно установить на любой сервер или вообще локально, а на сервер, где будет развернут прокси ставится агент, который будет выполнять команды панели. Такое решение мне понравилось, так как в будущем можно будет расширить сеть до нескольких узлов, во избежание тотальной блокировки.
WP умер, перевёл все сайты на OpenClaw
Раньше часто использовал WordPress с кучей плагинов для создания сайтов и лендингов. Сейчас поставил DarwinClaw на чистую машину Ubuntu и сказал ему сделать всю инфраструктуру для сайтов. Он поставил nginx + node.js.
Потом попросил перенести сайты, указав ссылки на них. Он создал все сайты.
Попросил добавить git и репозиторий для хранения этих сайтов. То есть всегда можно быстро откатить изменения.
Теперь полностью управляю этим зоопарком лендингов через TG команды типа:
Убери с сайта X вот это
Добавь на сайт Y вот то
Поменяй стиль сайта Z на …
Откати последние изменения на сайте XM
Замени икноку на сайте XS на более современную
Собери статистику по заполнению форм с сайтов X, Y, Z в формате
Раньше это либо делали люди за деньги, либо WP с его тяжёлой инфраструктурой, теперь всё делает бот на OpenClaw.
Привет, Хабр!
В прошлой статье я рассказывал, что с недавнего времени я развлекаюсь в мире highload тем что создаю для себя и своих близких мессенджер (Plumb). И несмотря на то, что клиент для него собран практически из цифровой изоленты, которую хорошенько искупали в бочонке с красками — он на удивление стабильно работает (и мессаджинг, и звонки) даже в текущих непростых реалиях.
В той статье я предложил Хабру попытаться сломать сервер моего мессенджера. Было потно, но мы выстояли. Спасибо всем, кто участвовал!
Но сегодня я хочу поговорить о другом. На примере одной реальной массированной автоматизированной атаки на мой сервер хочу показать как боты и специализированное ПО пытаются атаковать ваши веб-приложения и серверы в 2026 году. Эта реальная атака - идеальный, хрестоматийный пример того, как именно сегодня сканируют современную инфраструктуру. Никакой магии, только голые логи, разбор векторов и механика защиты. Поехали.
Сервер лагает. Смотришь на диск — df -h говорит 95% занято. Запускаешь du -sh /* — в сумме набирается 20%. Куда делись остальные 75%? Файлы не найти, место не освободить, сервис падает.
Это не баг и не магия. Это фундаментальная особенность того как Linux работает с файлами. Разберём почему так происходит и как это чинить за две команды.
Почему я решил сделать свой платёжный бот
Я просто хотел принимать платежи и донаты в своём Telegram-канале. Ничего сложного: кинул ссылку — получил деньги. Но когда начал смотреть существующие сервисы (Трибьюн, BotPay и подобные), столкнулся с одним и тем же: регистрация, паспорт, ИП, привязка карт. Мне это было неприятно — как будто чужой дядька лезет в интимные места.
Я не хотел светить данные, не хотел оформлять юридическое лицо, не хотел возиться с налоговой. Хотел просто продавать мануалы и принимать донаты, используя встроенную валюту Telegram — Stars.
Так родилась идея сделать своего бота: анонимного, без регистраций, без паспортов. Чтобы любой человек, у которого есть Telegram, мог создать товар, кинуть ссылку и получить деньги.
Привет, меня зовут Камиль, мне 23, я из Москвы и работаю аналитиком/инженером данных в банке. И не смотря на душную итшную работу, у меня есть еще более душное увлечение: homelabbing. Это хобби, когда люди создают у себя дома небольшие (кто-то и большие) серверные лаборатории и переносят часть личных задач, которые обычные люди решают сторонними сервисами, туда.
У меня нет цели доказать кому-то, что надо так упарываться, но для меня это имеет смысл. Почти все критически важные мне данные и сервисы развернуты на моей личной инфраструктуре и я по мере своих знаний обеспечиваю их надежность. Я никого не призываю делать так же, но получаю огромное удовольствие от того, что делаю это сам.
Почему я вообще про это рассказываю? Все мы видим, что сейчас происходит с интернетом и политиками распространения ПО, блокировками (подписки, зависимость от чужих серверов даже там, где это вообще не нужно и т. д). Меня это пугает и поэтому последний +- пол года-год я занимался тем, что по сути растил собственную сеть и инфраструктуру сервисов для себя самого.
Если такой туториал уже был на Хабре — не вините строго, я не нашел, и мне, на удивление, понадобился большой бубен и пол дня чтобы настроить сабж.
Вводные:
1) у вас есть крохотная виртуалка на которой крутится nginx и пара сайтов. Конечно https и скорее всего let's encrypt — короче стандартный набор рядового девелопера.
2) вы бы хотели поднять телеграм-прокси, но так чтобы трафик на него был максимально похож на обычный https, а это значит 443 порт — но вы хотите чтобы nginx и ваши сайты продолжили работать как и раньше.
Если это про вас и для вас — вот объяснение механизма и небольшой туториал.
Начну с небольшого вступления: зачем вообще нужен .htaccess файл?
.htaccess — это конфигурационный файл, который использует веб‑сервер Apache для задания специфических настроек для каждой отдельной папки сайта. Благодаря ему можно:
24 контейнера на одном VPS за $30/мес: Elasticsearch, Redis, MySQL, nginx, headless Chrome, llama.cpp и еще 18 сервисов. Реальные docker-compose файлы, конфиги nginx, потребление RAM каждого контейнера и честный список того, что не работает. Сравнение стоимости с managed-сервисами в облаке.
Наверняка вы слышали о новых версиях HTTP — второй и третьей. Что за этими версиями? Зачем они были разработаны? Чем они отличаются от классического HTTP/1.1 и где могут быть полезны? Какие настройки предоставляет веб‑сервер Angie для этих протоколов? Все эти вопросы мы будем разбирать в этой статье.
Начнём с краткой истории развития протокола HTTP.
Привет, я Александр Хренников, руководитель DevOps-юнита в KTS.
Нам тут, оказывается, 5 лет стукнуло. Точнее, нашему блогу на Хабре. Подарков мы не дождались, так что решили сами вручить их вам. Дарить будем футболки с нашим фирменным принтом — Котзиллой. Это как Годзилла, только кот.
Но подарок получат не все, а десять DevOps-инженеров, которые справятся с нашим испытанием быстрее остальных. Суть проста: мы даем вам тестовый стенд с кластером Kubernetes с ArgoCD и отдельный GitLab-сервер. В ArgoCD добавлено приложение — простой Nginx, обернутый в Helm-чарт. И оно не запускается. Надо запустить.
DevOps-челленджи мы проводим не впервые: уже были этот, этот и еще несколько до них. Опытные участники уже знают механику, а для новых энтузиастов я расскажу ниже, как все устроено.
В этой статье посмотрим на модуль ACME веб‑сервера Angie. Модуль позволяет с минимальными усилиями получить TLS‑сертификаты и автоматически их обновлять. Наверняка вы уже работали с бесплатными сертификатами от Let«s Encrypt и можете задать закономерный вопрос: зачем это делать веб‑сервером, когда есть утилиты вроде certbot, acme.sh и acmebot? Для ответа нужно хотя бы один раз попробовать модуль ACME и удобство конфигурации станет очевидным.»
Начнём с краткого введения в тему ACME.
Высоконагруженная система. Несколько миллионов страниц. Много сервисов, много данных. Имеются кэши разного уровня. Возникла идея сделать полный html кэш страницы. Достаем с полки nginx, ставим перед системой, включаем кэширование запросов. Работает. Но как быть, если данные изменяются? Надо сбрасывать кэш.
В этой статье мы продолжаем разбирать возможности веб‑сервера Angie по борьбе с DoS (и немного DDoS) атаками. В предыдущей части мы разобрали стандартные средства, а в этой обсудим возможности сторонних модулей и системы Fail2Ban.
🚀 Nginx на автопилоте: Как я перестал тратить время на конфиги и SSL
Бывает так: у тебя есть крутая идея для проекта, ты быстро кодишь бэкенд, но когда дело доходит до деплоя... Вечер превращается в бесконечную настройку Nginx, борьбу с Certbot, прописывание HSTS-заголовков и попытки вспомнить, как там правильно настраивается кеширование.
Знакомо? Мне — да. Именно поэтому я собрал nginx-template — инструмент, который превращает администрирование сервера в удовольствие. 🛠
Это не просто набор файлов, это полноценный пульт управления вашим сервером через один скрипт — manage.sh.
Почему вам стоит это попробовать:
🔹 Скорость деплоя: Добавление нового домена с автоматической выдачей Let's Encrypt занимает ровно одну команду. Без правок конфигов руками и перезагрузок.
🔹 Image Proxy из коробки: Хотите ресайзить аватарки на лету прямо через Nginx? Теперь это делается одной командой без сторонних микросервисов.
🔹 Умный CDN: Поднимайте кеширующие узлы для статики за секунды. Разгружайте основной сервер и радуйте пользователей мгновенной загрузкой.
🔹 Профессиональная безопасность: Конфиги уже оптимизированы под требования SSL Labs (рейтинг A+), включают защиту от эксплойтов и автообновление IP Cloudflare.
Никаких тяжелых интерфейсов и лишних абстракций. Только чистый, производительный Nginx в Docker и удобная автоматизация на Bash. Вы сохраняете полный контроль над каждым байтом конфига, но избавляетесь от всей рутины.
Пора тратить время на код, а не на настройку прокси. ⚡
🔗 Забирайте готовый стек здесь: github.com/Arlandaren/nginx-template
Понравился подход? Ставьте ⭐ на GitHub — это лучший способ сказать «спасибо» и поддержать развитие Open Source!
Как мне удалось создать свой полноценный продукт с функционалом и системой лицензирования с нуля без навыков программирования используя и IDE Cursor. Полный разбор в статье по шагам с инсайтами.
