Последние пару лет я работаю в команде, которая занимается устойчивой к DPI (Deep Packet Inspection) туннельной инфраструктурой — по сути, альтернативой классическому VPN.

Когда начинаешь заниматься этим всерьёз, довольно быстро обнаруживается неприятная вещь: шифрование само по себе давно уже не означает, что трафик нельзя распознать. Содержимое пакетов действительно можно скрыть, но пакет от этого не исчезает. У него остаются размер, направление, время появления; соединение начинается с определённой последовательности сообщений, TLS-клиент определённым образом представляется серверу, поток ускоряется, замедляется, замирает и снова начинает передавать данные.

Для человека всё это выглядит как куча зашифрованных байтов. Для классификатора — как вполне пригодный набор признаков.

Поэтому значительная часть нашей работы в итоге свелась не к тому, чтобы «зашифровать ещё сильнее», а к более практическому вопросу: что именно видит наблюдатель снаружи и по каким признакам он может решить, что перед ним не браузерный трафик, а туннель.

Об этом и расскажу.

Как безопасно опубликовать домашний сервер без белого IP и проброса портов: домашний сервер сам устанавливает исходящее SSH-соединение к VPS, на VPS создаётся локальный endpoint обратного SSH-туннеля, а внешний доступ к сервисам отдаётся через Caddy по HTTPS. Backend-порты вроде Nextcloud, Home Assistant или Jellyfin не открываются напрямую в интернет, а остаются доступными только через loopback и reverse proxy. Отдельное внимание уделено hardening: ограниченный пользователь tunneluser, SSH-ключи, autossh, systemd, UFW, проверка sshd_config и диагностика типовых ошибок.

systemd unit‑файл часто начинается с пары строк из чужого примера, а заканчивается сервисом, который странно рестартует, пишет логи куда попало и работает с лишними правами.

В этой статье разбираем, как собрать unit‑файл для своего Linux‑сервиса: от минимального скелета до production‑настроек с рестартами, зависимостями, hardening‑параметрами, лимитами ресурсов и journald.

В 2026 году серия уязвимостей класса page-cache write вновь поставила под удар практически все актуальные дистрибутивы Linux. Их особенность в том, что злоумышленник может изменить содержимое файла в page cache, не затрагивая данные на диске. Из-за этого классические средства контроля целостности файлов не способны обнаружить такую компрометацию.

В этой статье рассмотрим две наиболее показательные уязвимости этого класса — Dirty Frag и Copy Fail, а затем настроим Wazuh так, чтобы он помогал выявлять признаки их эксплуатации и связанные с ними аномалии.

Как часто нам приходится читать в бюллетенях безопасности «Уязвимость... позволяющая нарушителю выполнить произвольный код с помощью специально сформированного запроса». Но что на самом деле скрывается за этой фразой? Что это за специальные запросы и как наша программа может выполнять чужой код, если мы досконально знаем в ней каждую строчку и каждую библиотеку?

И почему тогда Apple платит до двух миллионов долларов за одну найденную уязвимость и выстраивает многоуровневую аппаратную защиту — а айфоны всё равно взламывают по нажатию одной кнопки?

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

Перед нами — Data-Only атаки, где взлом превращается в программирование на «невидимом» процессоре. Процессоре, команды которого — лишь побочный эффект работы нашей собственной программы.

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

Я написал с нуля инструмент для изоляции Linux‑приложений на Rust — Hajiz. Это учебный проект по системной безопасности, который вырос во что‑то, чем можно реально пользоваться. Хочу рассказать, как он устроен изнутри: почему порядок применения механизмов изоляции критичен, как работает eBPF‑аудит с privilege separation, и зачем всё это когда есть Docker.

→ github.com/hag19/hajiz

Привет, Хабр! Хочется поделиться инструментами и практиками для работы с GIT, о которых не все знают, но которые сильно упрощают жизнь вам и вашей команде. Если кто-то хочет чтобы ваша история коммитов была читаемой, легкой для понимания и с возможностью заглянуть в любой коммит и понять, какие были произведены изменения, то эта статья для вас.
Здесь не будет базовых понятий и терминов, так как предполагается, что с основами GIT вы уже знакомы. 

История о том, как один странный git push оказался началом расследования, которое вывело меня не на один взломанный аккаунт, а на цепочку зараженных репозиториев и проектов.

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

Первой версией был взлом моего GitHub, но смена ключей и паролей ничего не решила.

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

Это оказалась PolinRider-like supply chain атака, которая использует сам developer workflow как транспорт.

В статье я разбираю, какие мелкие странности помогли заметить проблему и почему им нельзя махать рукой.

Показываю реальные скриншоты, подозрительные изменения в .gitignore и payload внутри babel.config.js.

В конце оставил скрипты, которые могут помочь быстро проверить свои проекты и логи на PolinRider похожие признаки.

Команда Supply Chain Security экспертного центра безопасности (PT ESC) отправила отчет администрации реестра npm о занятной маленькой кампании против Apple, среди них:

• apple-infra-network-v2 (170 скачиваний на момент репорта)
• apple-infra-final-escape (326 скачиваний)
• apple-infra-gcp-leak (165 скачиваний)
• apple-infra-ultimate-bypass (153 скачивания)
• agents-a365-runtime — мимикрия под пакет @microsoft/agents-a365-runtime (447 скачиваний)
• apple-security-internal-scanner-v3 (185 скачиваний)
• apple-coredata-internal-service (367 скачиваний)

Часть проектов первой волны лаконична и состоит из одного файла package.json весом менее 1 килобайта.

Продолжаю серию подборок неочевидных ресурсов. Недавно рассказывал про 15 онлайн-сервисов, которые должен знать каждый сисадмин. Сегодня собрал инструменты для случаев, когда dig, mtr и traceroute недостаточно, но ставить софт не очень хочется. Под катом — подборка для сетевиков.

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

Почему сайт вообще может понять, что пять аккаунтов сидят из одного браузера, если у них разные cookies, разные почты и разные прокси? Почему обычная подмена User-Agent давно почти ничего не решает? Почему один профиль выглядит нормально, а другой палится на Canvas, WebGL, timezone, TLS или странной связке параметров? И почему антидетект-браузер иногда действительно помогает мультиаккаунтингу жить дольше, хотя никакой невидимости он не даёт?

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

Цель: сделать мобильный прокси.

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

За последние несколько недель я отправил довольно много репортов об уязвимостях. Небольшая их часть уже исправлена и раскрыта через бюллетени безопасности. Все они найдены исключительно с помощью LLM, без какого-либо ручного ревью исходного кода. Проекты, в которых я нашел эти проблемы, хорошо известны и широко используются. Среди них есть известные вроде Parse Server, HonoJS, ElysiaJS, Harden Runner и еще около десятка заметных проектов.

На мой взгляд, это доказывает: агентные CLI/TUI-инструменты вроде OpenAI Codex без всяких сомнений могут помогать находить серьезные уязвимости. Но как именно использовать их так, чтобы выявлять неочевидные проблемы? По итогам экспериментов и тысяч и тысяч промптов, отправленных в попытках найти уязвимости, я пришел к нескольким выводам. Возможно, они небезупречны с теоретической точки зрения, но это самые практичные выводы, к которым я смог прийти.

Все русскоязычные гайды по GitLab CI/CD — это «сделай вот так под Node.js/Java/.NET». А как оно вообще работает? Написал подробный туториал: термины, схемы, разбор .gitlab-ci.yml, логи runner’а построчно. Первая часть из трёх — от простейшего pipeline до понимания, что конкретно вам нужно в вашем случае.

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Atomic Heart делали 200 человек с бюджетом $50 млн. Hail to the Rainbow — один разработчик, 6 лет, почти без бюджета. Я взял интервью у Сергея Носкова и разобрал этот кейс как руководитель отдела разработки: продуктивность, деньги, выгорание и результат, который сложно отличить от AAA.

Когда начал разбираться с веб-версией Max, первая мысль была — как бы его изолировать, чтобы он не ходил куда попало. Обычно в таких случаях советуют поднимать прокси, городить контейнеры или хотя бы использовать PAC-файлы.

Но если всё упростить, то оказывается, что в любом современном браузере (для примера, в Firefox) уже есть всё, чтобы сделать это в пару кликов. Мы будем использовать стандартный функционал немного нестандартным способом.

Когда мои сайты положили DDoS-атакой, я не смог нормально воспользоваться бесплатной защитой CloudFlare. Из-за ограничений со стороны РКН часть его подсетей в России заблокирована у многих интернет-провайдеров, включая мобильных операторов.

Чтобы не потерять российских пользователей, пришлось срочно переходить на российское решение и платить за проксирование трафика. Цена вопроса — десятки тысяч рублей в месяц всего за два домена. И это за минимальный, самый дешевый тариф. Из-за этого я сильно сгорел, потому что на CloudFlare я бы отбился бесплатно. А теперь — ежемесячный, неприятный для меня счет, потому что альтернатив просто нет.

Но самое интересное на мой взгляд произошло дальше. Пытаясь разобраться, кто и как организовывает DDoS-атаки в 2026 году, я обнаружил массу специализрованных сервисов: так называемых DDoS-стрессеров — сервисов, где можно запустить атаку на любой ресурс в пару кликов за небольшие деньги.

Пока в мире с такими незаконными сервисами борются, проводя крупные международные операции вроде Operation PowerOFF, в России — из-за необъяснимой лояльности ряда крупных компаний — они чувствуют себя вполне комфортно.

Чем закончилось мое взаимодействие с этими компаниями, предоставляющими инфраструктуру DDoS-стрессерам, в попытке прекратить их работу — вы узнаете в этом материале.

Думаю, вы уже в курсе, что происходит в РФ с белыми списками: работают белые списки, ТСПУ в режиме drop-all пропускает только одобренные IP + SNI, рунет медленно, но верно становится интранетом

Мы просканировали 46 млн российских IP-адресов, нашли 63 тысячи выживших, разобрали работу ТСПУ. И главное - актуальные методы пробива (от Serverless-функций и покупки VPS с белым IP до туннелей через WebRTC).