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

К 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, лимиты трафика, доступные домены) применяются на лету без разрыва соединений.

Привет!

Эта статья о том, как собрать мобильного оператора «на столе» для тестов функциональности и взаимодействия компонентов ядра сети.

Меня зовут Алексей Червяков, я тимлид команды разработки мобильных продуктов в компании VAS Experts, и мы разрабатываем компоненты ядра сети, которые осуществляют контроль трафика, его подсчет, применяют правила тарификации для абонентов. Корректная работа этих элементов – залог прибыли и отсутствия убытков из-за неоплаченных услуг и трафика.

Приятного чтения!

В комментариях к "серверу точного времени" (https://habr.com/ru/articles/1023414) предлагали вдобавок к NTP и GPS подключить еще и DCF77, как еще один источник времени.
И я таки сделал это, хоть и в виде отдельной железки, а поскольку техника тут аналоговая - были свои нюансы.

В качестве справки:
DCF77 - это радиостанция, передающая точное время от атомных часов, собственно, это ее основное назначение.
Расположена в Европе, в Германии, неподалеку от Франкфурта. Вещает на длинных волнах на всю Европу, захватывая в том числе часть exUSSR. Передает сигнал, содержащий информацию о времени и дате, UTC+1/UTC+2 в зависимости от "летнего времени".
Также передает местную погоду и может быть использована как средство оповещения, но нас это мало касается.
Рабочая частота 77.5 кГц - поэтому и "DCF77".

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

Проблема простая: расстояние.
Несмотря на большую мощность передатчика и хорошее распространение длинных волн на большие расстояния - 2000 км это 2000 км.

Месяц искал VPN который не палит Россию перед ИИ. Нашёл - 24 часа бесплатно, попробовал. Написал в поддержку прямо во время установки. Три минуты — живой человек, сразу инструкция. Сработало. А потом понеслась …

Привет, Хабр! Меня зовут Сергей, я разработчик облачной платформы в Selectel. В прошлой статье я рассказал об использовании Terraform для создания глобального роутера и настройки сетевой связности между разными регионами облака. Сегодня продолжим тему и объединим в сеть выделенный и облачный серверы.

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. После большого релиза 🐙 userver прошло почти два года. За это время мы обзавелись большим количеством внешних пользователей — международных и российских. При этом и количество внутренних пользователей подросло: в Городских сервисах Яндекса появились стни новых сервисов на userver. Функциональность Такси, Еды, Лавки, Доставки, а также Маркета, Финтеха, Фантеха, Электро и Техплатформы обогатилась новыми возможностями и новыми пользователями. А значит, фреймворк стал ещё надёжнее и оттестированнее.

Мы не сидели сложа руки, и за два года реализовали, оптимизировали и добавили все обещанные в прошлой статье фичи, а также многое другое.