Сетевые технологии *

«Мне прислали фишинг под MAX. Внутри оказался MITM в их API» «Не ты ли на фото?» — пришло поздно вечером, в обычной переписке, от знакомого, который пишет редко. К сообщению приложена короткая ссылка. Я понял, что у него увели аккаунт, и захотел разобраться, что внутри. Через пять дней я смотрел на инфраструктуру из 179 фишинговых доменов, четырёх хостингов, через которые оператор переезжал каждые сутки, и обнаружение, что фишинг-кит работает не как сборщик паролей, а как MITM-прокси к настоящему API мессенджера MAX. Жертва получает реальный SMS от реального MAX и не может распознать атаку. CVSS 8.8. VK молчит уже неделю.

30 апреля в сети появилась информация, что глобальная IT-компания и оператор крупной интернет-инфраструктуры Cloudflare присвоила домену национального мессенджера Max классификацию Spyware (шпионское ПО). Прежде чем мысленно ухмыльнуться и подумать «а я же говорил», давайте объективно разберемся, что это за шум.

В этой статье мы расскажем: кто такая компания Cloudflare, почему она ставит подобные метки, что значит «spyware», на основании каких признаков Cloudflare принимает такие решения, а также какие последствия такая метка может иметь.

Привет, Хабр! Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен».

В этом посте расскажу, что изменилось в версии 7.0, какие задачи мы решали в релизе и почему эти доработки важны для команд, которые занимаются учетом, инвентаризацией и контролем ИТ-активов.

При развитии «Инферит ИТМен» мы фокусируемся не только на расширении функциональности, но и на том, чтобы система оставалась удобной, безопасной и масштабируемой по мере роста инфраструктуры. В версии 7.0 основное внимание уделили развитию ролевой модели, усилению контроля доступа и дальнейшему улучшению инструментов инвентаризации.

Москва говорит, что rbc.ru открывается за 47 мс. Из Новосибирска — за 594 мс. Это не баг сервера, а реальность Рунета — и из одной точки мониторинга вы её не увидите. Прогнал 27 ресурсов с двух проб в Москве и Новосибирске за 5 суток, разобрал 278 эпизодов расхождений между ними, нашёл живые трёхчасовые блоки telegram.org из Сибири. С графиками, цифрами и Naruto-метафорой внутри.

В 2026 для VPN нужна маскировка. А нет никакой лучшей маскировки, чем уже работающий легитимный сервис. Силами NGINX-streams и HTTP2 это сделать довольно легко.

К 2028 году в корпоративных средах будет работать 1,3 млрд AI‑агентов, а классическая модель identity по‑прежнему исходит из допущения «один деятель — один человек». Разбираем, что ломается в аутентификации, почему service account и OAuth‑токен больше не закрывают задачу, и как мы в Ideco смотрим на ближайшее развитие средств защиты: непрерывная биометрия для людей и делегированные токены для агентов.

Цифры, которые ломают ИБ‑ландшафт

На RSAC 2026 Microsoft, опираясь на прогноз IDC, заявила о 1,3 млрд AI‑агентов в корпоративных средах к 2028 году (Windows Forum, RSAC 2026, Lantern Studios). Это не «копилоты, которые помогают писать письма» или «чатики» — это автономные исполнители, у которых есть права, токены и доступ к продуктовым системам.

Мы сами уже видим лавинообразное «нашествие агентов» как в собственной, так и в чужих корпоративных сетях.

Атакующая сторона тоже меняется. В отчёте о кампании GTG-1002 Anthropic зафиксировала первую массовую AI‑оркестрированную операцию: взломанная версия Claude, подключённая к набору MCP‑серверов, выполнила 80–90% тактических операций самостоятельно — разведку, поиск уязвимостей, эксплуатацию, сбор учётных данных, латеральное движение (Anthropic, Disrupting the first reported AI‑orchestrated cyber espionage campaign, Paul, Weiss разбор). Человек был нужен на 4–6 точках принятия решений за всю кампанию.

И последняя цифра, без которой картина неполная. По 2025 Identity Security Landscape от CyberArk (опрос 2 600 ЛПР‑ов в сфере ИБ), на каждую человеческую идентичность в средней организации приходится 82 машинных; 42% этих NHI имеют привилегированный доступ или доступ к чувствительным данным, при этом 88% респондентов всё ещё относят определение «привилегированный пользователь» исключительно к людям. 87% компаний за последние 12 месяцев пережили минимум два успешных identity‑центричных инцидента.

Когда говорят о балансировщике нагрузки, чаще всего имеют в виду распределение трафика между серверами. Но в реальной инфраструктуре его ключевая роль проявляется в другом — в способности системы продолжать работать, когда что-то ломается. Причём ломаться может всё: отдельные серверы, сервисы, целые дата-центры.

В этой статье разбираем, как балансировщик становится точкой принятия решений в сценариях отказоустойчивости — от health checks до переключения между ЦОД — и почему без этих механизмов одной «балансировки» недостаточно.

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

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

К утру инфраструктура так и не полыхнула синим пламенем, зато система оповещений просто разрывалась. Так я впервые узнал об «усталости от алертов» и начал искать способ справиться с этой проблемой.

Привет, Хабр! Меня зовут Артём Чуйков, я инженер компании Innostage — первого кибериспытанного интегратора сервисов и решений в области цифровой безопасности. Я занимаюсь внедрением межсетевых экранов на промышленных предприятиях, и сегодня хочу поделиться практическим опытом.

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

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

Именно поэтому внедрение систем обеспечения информационной безопасности позволяет эффективно противостоять подобным угрозам.

Для объектов критической информационной инфраструктуры внедрение СОИБ является не просто рекомендацией, а требованием регуляторов — ФСТЭК, ФСБ, а также стандартов, таких как ГОСТ Р ИСО/МЭК 27 001 и других.

Большинство компаний уже умеют делать «нормальные» рассылки: есть шаблон, темы писем, календарь и какие‑то метрики. На этом уровне всё обычно и останавливается: письма что‑то рассказывают, но слабо влияют на процессы и не используют свой потенциал. Внутри всё выглядит прилично: open rate «нормальный», люди иногда переходят по ссылкам, новая политика безопасности или свежий релиз продукта формально донесены до адресатов. Но ощущение такое, будто рассылка живёт сама по себе, а жизнь компании — сама по себе.

В этой статье я соберу несколько нетривиальных методик корпоративных рассылок — не про то, «как правильно верстать в таблицах» или «почему нужен SPF/DKIM/DMARC», а про вещи, которые лежат чуть глубже. Как использовать прехедер и автоответы как инструмент, превратить статистику в личные письма, не бояться ошибок в рассылках, заставить письма двигать внутренние процессы, подружиться с отпиской и оживить самые скучные служебные уведомления. Каждый кейс дальше можно будет развернуть в отдельную статью, а сейчас — обзор с небольшими анонсами.

История о том, как сисадмин борется с конторой с бюджетом в 60 млрд.
В продолжение комментария.

Глава 1. Первые блокировки, obfs4proxy

Глава 2. Вторая волна, вынос части инфры из AWS.

Глава 3. Попытка попасть в белые списки.

Глава 4. Появление cloak/trojan/hysteria/vless.

Глава 5. Белые списки, поднятие серверов в РФ

Глава 6. Отрыв IP, резервирование

Глава 7. Multihop

В первой статье я рассказывал историю «деда из деревни», который вместе с внуком поднял свой почтовый сервер вместо Gmail — на обычном VPS, с доменом, DNS‑записями и всеми сопутствующими приключениями. Эта иллюстрация продолжает ту линию: дед‑айтишник и внук уже не просто радуются первому письму, а разбираются, что происходит с их маленьким сервером в большом почтовом мире.

В данном руководстве приведена инструкция по внедрению двухфакторной аутентификации (2FA/TOTP) для VPN-доступа на базе OCSERV (OpenConnect Server) в связке с FreeRADIUS и FreeIPA.

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

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

В прошлой статье я разобрал, как устроена сеть Yggdrasil. Теперь - про Yggdrasil-ng: рерайт с Go на Rust за 3,5 дня, неделя на один баг в пяти строках, новые фитчи (включая CKR - VPN через mesh), и мобильный клиент, в котором перенос работы с TUN внутрь Rust дал прирост скорости почти в десять раз. В статье бонус - новое приложение, которое вам понравится ;)

Привет. Полгода назад я выложил singbox-launcher — десктопный GUI для управления ядром sing-box. По фидбеку стало понятно: идея зашла, людям удобно собирать и отлаживать конфиги на ноутбуке, а потом переносить их на роутеры и другие сетевые устройства. Подробнее о десктопной версии я писал на Хабре.

Пару слов для тех, кто не в контексте. Есть небольшой класс кроссплатформенных сетевых ядер, которые умеют гибкую маршрутизацию трафика и поддерживают современный набор протоколов: WireGuard, VLESS, SOCKS5, Shadowsocks, Hysteria2, TUIC и так далее. Sing-box в этом списке — не самый раскрученный, но для меня он оказался наиболее интересным: быстрая эволюция, внимание к деталям, чистый код, живое общение мейнтейнеров с пользователями, классно организованный по логике конфиг.

Довольно быстро стали приходить запросы на Android-порт. Первое время казалось, что это будет прямое переиспользование десктопного кода. На практике сценарии потребления на мобильных оказались сильно другими: другой UX, другой lifecycle, Doze и background-лимиты, OEM-специфика, ограниченный экран, другие ожидания от автозапуска и обновлений. В итоге пришлось переписать практически всё с нуля.

Результат этой работы — LxBox, и сегодня я хочу рассказать, чем он отличается от существующих Android-клиентов и как устроен изнутри.

На старых Intel Mac установка proxy-клиента часто превращается в странный квест: если приложение ставится, подписка импортируется, серверы вроде бы появляются, но рабочего подключения всё равно нет. На macOS Catalina 10.15.8 эта проблема ощущается особенно остро: часть современных клиентов уже не поддерживает систему, часть формально запускается, но ломается на встроенном core, а автоматический импорт VLESS/Reality-конфигов может создавать пустую заглушку вместо рабочего профиля.

Эта инструкция написана не экспертом по сетям, а обычным пользователем для таких же обычных пользователей. Я собрал в одном месте весь путь, который реально сработал у меня на старом Intel iMac: как понять, какая версия клиента вообще подходит для Catalina, где брать старые релизы, как распознать сломанный импорт, как вручную собрать рабочий config и почему Telegram Desktop может не заработать, даже когда браузер уже работает.

NAC-системы долгое время ассоциировались с “монстрами” вроде Cisco ISE или Aruba ClearPass. Но что, если собрать российский NAC из модулей «Медведь», «Лиса» и «Заяц», поставить их на страже сети и попробовать закрыть те же сценарии?

Привет, Хабр! С решениями NAC наша команда работает больше 19 лет. Последние годы особенно интересны: российский сегмент NAC заметно вырос, новые продукты появляются регулярно, а интерес со стороны заказчиков подталкивает нас на постоянный анализ рынка. 

Эта статья — часть цикла о NAC-решениях, которые мы разбираем в нашей сетевой лаборатории. На этот раз в фокусе Eltex NAICE — новичок в области контроля доступа, но далеко не новичок в мире сетей.  Разберёмся, как он устроен, какие задачи реально закрывает и насколько уверенно чувствует себя на фоне более привычных NAC-систем. 

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

Причина в том, что речь идёт не об одной точке контроля, а о распределённой системе, где итоговое поведение формируется на пересечении трёх слоёв: централизованного управления, DPI/ТСПУ как контура распознавания и сети оператора как среды исполнения. Именно эта многослойность и объясняет наблюдаемую неравномерность.

Если коротко: После дефейса сайта нашего знакомого из-за утекшего пароля от админки мы поняли, что управлять доступами нетехнической команды (редакторы, SEO, подрядчики) через VPN или статические IP - это боль. Существующие proxy требовали рестартов и рулились конфигами. В итоге мы написали свой forward-proxy на Go, где доступ выдается токеном через расширение браузера, а правила (TTL, лимиты трафика, доступные домены) применяются на лету без разрыва соединений.