Обновить
1024K+

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

От Ethernet до IPv6

512,94
Рейтинг
Сначала показывать
Порог рейтинга

YouTube начал требовать отключить средства обхода блокировок для просмотра видео. Ограничение касается каналов с жёсткими региональными правами на контент: в первую очередь спортивных — «Формула 1», некоторые футбольные лиги, отдельные музыкальные лейблы. Это каналы, где рекламодатели платят за показы в конкретных странах, а правообладатели продают лицензии по регионам. YouTube обязан контролировать, из какой страны смотрит зритель, — иначе нарушаются условия лицензий.

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

Теги:
+5
Комментарии0

Прятать данные в TLS-трафике: как выглядит настоящий стелс

Больше 70% интернет-трафика — зашифрованный TLS. Это не баг, это фича: тонны HTTPS-соединений, WebSocket-потоков, мобильных приложений и игровых клиентов создают идеальный фон для передачи данных без привлечения внимания.

Идея простая: если нужно спрятать дерево, прячь его в лесу. В случае интернета этот лес состоит из миллионов TCP/443-соединений, которые выглядят настолько обычно, что именно это делает их интересной средой для экспериментов.

Почему TLS-трафик — удобная маскировка

TLS скрывает содержимое пакетов. DPI может видеть метаданные — размер, timing, SNI в Client Hello, но не payload. Если ваше соединение выглядит как обычный HTTPS-запрос или долгоживущий WebSocket, оно сливается с фоном.

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

Где это может быть полезно

  • Обход блокировок в странах с жёстким DPI — если трафик неотличим от обычного HTTPS, его сложнее фильтровать

  • Распределённое хранилище данных в трафике — архивные данные можно держать не на диске, а в виде пакетов, циркулирующих между нодами

  • Covert channels для исследований в области безопасности — тестирование систем мониторинга и обнаружения аномалий

Технические ограничения и риски

Главное ограничение — timing и packet size analysis. Если трафик выглядит нетипично по объёму или интервалам, статистические методы могут его вычислить. Traffic shaping помогает, но не решает проблему полностью.

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

Третье — надёжность. Пакеты теряются, соединения рвутся, данные нужно восстанавливать. Без механизмов коррекции ошибок и redundancy хранилище в трафике превращается в лотерею.

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

Теги:
-4
Комментарии2

Передача параметров ssh с помощью суффиксов имени хоста

В случае, если доступ к определённым хостам по протоколу SSH требует запуска ssh с кучей параметров, стандартной рекомендацией является внесение всех этих параметров в отдельную секцию Host файла конфигурации ssh, пример которой приведён ниже. Данные параметры подробно описаны в ssh_config(5).

Host tproxy
  Hostname srv-10-79.dmz.company.com
  User srv_user
  Port 36602
  DynamicForward 127.10.0.79:1080
  LocalForward 127.10.0.79:4445 127.0.0.1:445
  LocalForward 127.10.0.79:8080 127.0.0.1:8080

У этой рекомендации есть один существенный недостаток — она не обеспечивает модульность конфигурации и вынуждает дублировать информацию. В случае, если требуется обеспечить подключение к тому же серверу из интернета через NAT или через SSH-прокси, или без SOCKS5-прокси и переадресации портов, причём во всех возможных комбинациях:

  • изнутри с переадресацией портов,

  • изнутри без переадресации портов,

  • снаружи с перадресацией портов,

  • снаружи без переадресации портов,

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

Сущность предлагаемой доработки

Мною были перепробованы различные варианты доработки исходной рекомендации и, в итоге, был найден достаточно простой способ, заключающийся в разбиении конфигурации на отдельные секции в зависимости от суффиксов, добавляемых к имени хоста, передаваемого в качестве параметра команде ssh. Для отделения суффиксов от имени хоста и друг от друга оптимально использовать символ-разделитель "+" (плюс). Этот символ не используется в именах DNS, а также интуитивно понятнее любых других, указывая на то, что суффикс что-то добавляет к исходной конфигурации хоста. Распознавание добавляемых суффиксов следует производить с помощью команды Match originalhost с шаблоном суффикса.

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

Match originalhost "tproxy+*" originalhost "*+rtk,*+rtk+*"
# Подключение через РостелеТелеком (NAT)
  Hostname srv-10-79.rtk.company.com

Match originalhost "tproxy+*" originalhost "*+yota,*+yota+*"
# Подключение через Yota
  ProxyJump gate-10-1+yota

Match originalhost "tproxy+*" originalhost "*+fwd,*+fwd+*"
  DynamicForward 127.10.0.79:1080
  LocalForward 127.10.0.79:4445 127.0.0.1:445
  LocalForward 127.10.0.79:8080 127.0.0.1:8080

За секциями, специфичными для хоста с указанием суффиксов, в обязательном порядке должна следовать секция для этого же хоста с параметрами по умолчанию. Прежде всего эта секция нужна для того, чтобы заменить переданное ssh имя хоста его именем DNS, если добавленные к имени хоста суффиксы не ссылались на секцию Match, содержащую команду Hostname. Также в этой секции следует указывать параметры ssh, одинаковые для всех возможных способов подключения, например: имя пользователя, номер порта, используемые алгоритмы шифрования, типы ключей, и так далее. Для секции Match хоста по умолчанию достаточно одного аргумента originalhost. Пример:

Match originalhost "tproxy,tproxy+*"
  Hostname srv-10-79.dmz.company.com
  User srv_user
  Port 36602

В случае, если добавляемые суффиксом параметры не содержат специфических для хостов аргументов, в команде Match достаточно указать один аргумент originalhost с шаблоном суффикса. Такие секции следует располагать в самом конце файла настроек ssh.

Match originalhost "*+rsa,*+rsa+*"
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedKeyTypes +ssh-rsa
Теги:
+9
Комментарии0

Битва за Интернет переходит в реальный мир

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

Азия и Ближний восток: риски и возможности

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

В 2024 году в Красном море Йемен повредил четыре подводных кабеля в Красном море. А уже в этом году Иран угрожал блокировать не только Ормузский пролив, но и интернет-каналы, проходящие у его берегов. Так как долговременное примирение геополитических противников никто не гарантирует, ЕС задумался над прокладкой кабелей через арктический регион.

Трафик через полюс

У Европы два варианта прокладки интернет-кабелей — через Северо-Западный проход. Аналог Северного морского пути в обход Канады и Аляски по Северному Ледовитому океану. Однако придётся решать вопросы работы в сложных ледовых условиях. Есть опыт многомесячных перерывов в ремонте интернет-магистралей, находящихся в подобных условиях. Альтернатива — не проще: проложить кабели непосредственно через Северный полюс.

Кажется, что в таких условиях получат новые возможности спутниковые сервисы связи. Однако в текущей ситуации захочет ли Европа зависеть от американских компаний? А OneWeb вряд ли потянет полноценную связь регионов. Часть коммерческой нагрузки может взять на себя сервис спутниковой связи IRIS, основное назначение которого — связь для европейских госструктур и силовиков.

В любом случае реализация обхода через Арктику намечена к 2030 году. За 5 лет может ещё всё измениться.

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

Теги:
+22
Комментарии0

Представлен аналог Discord — открытый проект GoofCord, который:

  • быстрее официального клиента, не глючит и не тормозит;

  • внутри заблокирована вся слежка и сбор данных о пользователе;

  • переписка шифруется паролем;

  • демонстрация экрана в любом разрешении и с любой частотой кадров;

  • можно выбирать, звук какого приложения стримить;

  • игры, музыка или видео встают в ваш статус автоматически;

  • плагины для кастомизации Vencord, Equicord и Shelter работают из коробки;

  • глобальные хоткеи работают даже со свёрнутым окном;

  • можно стримить со звуком на Linux, работает также на Windows и macOS.

Теги:
+2
Комментарии0

Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️

Уже 4 июня, ровно в 14:00, команда системы поведенческого анализа сетевого трафика от Positive Technologies — PT NAD — прольет свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел» (отсылка не случайна).

В этот день вы сможете вместе с нами узнать, как поменяют правила игры:

  • автоматизированное реагирование;

  • облачное детектирование;

  • архивное хранение метаданных.

Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:

1) Отменить все свои планы на 4 июня в 14:00

2) Зарегистрироваться на онлайн-запуск по ссылке

3) С нетерпением ждать встречи вместе с нами.

Увидимся уже скоро! Такие дела.

Теги:
+2
Комментарии0

Опубликовали программу infra.conf'26 — большой конференции про инфраструктуру и высоконагруженные сервисы

Команда Yandex Infrastructure открыла полную программу infra.conf 2026, которая состоится 4 июня в Москве и онлайн. Фокус конференции этого года — построение и особенности эксплуатации инфраструктуры в эпоху ML. 

В трёх треках программы обсудим не только ML‑инфраструктуру, но и базы данных, стораджи, инструменты разработки, observability‑решения, SRE и эксплуатацию и управление трафиком. 

Среди докладов от инженеров и разработчиков Яндекса, Сбера, X5 Tech, Wildberries & Russ и других компаний нас ждут темы: 

  • «Как появилась Алиса AI: путь одной LLM» (Аркадий Альшан, Яндекс) 

  • «ML‑платформы для больших компаний» (Антон Алексеев, AvitoTech) 

  • «Как мы построили два больших GPU‑кластера на Kubernetes» (Иван Юмашев, Ozon) 

  • «Два подхода к надёжности распределённых систем» (Евгений Дюков, Yandex Cloud) 

  • «ИИ‑агенты для MLOps‑инфраструктуры» (Марк Кузнецов, Альфа‑банк) 

  • «Особенности observability LLM‑приложений и агентов» (Даниэль Халиулин, Yandex Infrastructure)

Также участникам будут доступны мастер‑классы и выставочная зона инженерных команд.

Infra.conf'26 пройдёт 4 июня в Москве в пространстве TAU. Для участия нужно зарегистрироваться и дождаться приглашения. Также посмотреть доклады в прямом эфире можно будет на сайте конференции.

Теги:
+7
Комментарии0

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

Теги:
+3
Комментарии5

dpi-checkers — open-source инструмент от hyperion-cs — показывает, каким именно методом ваш провайдер режет трафик: RST после 16-го пакета, SNI-дроп или CIDR-вайтлист. Прогнал на трёх подключениях — картина неожиданная.

Пользователи рунета давно заметили: «интернет дома» и «интернет у бабушки в области» — это два разных интернета. YouTube грузится на одном провайдере и не грузится на другом. Discord висит на мобильном, но работает на проводе того же оператора. Это не случайность и не деградация сети — за каждым таким симптомом стоит конкретный технический механизм на L4/L7.

Набор тестов dpi-checkers (часть на Go как CLI-утилита, часть в браузере на JS) позволяет идентифицировать метод фильтрации, который применяет конкретный ISP. Я прогнал проверки на трёх подключениях: домашнем у федерального провайдера, мобильном у одного из «большой четвёрки» и через знакомого в другом регионе.

Пять методов которые реально встречаются в РФ. DPI — не одна технология, а класс решений. Современный Deep Packet Inspection анализирует не только заголовки L3/L4, но и содержимое L7: по особенностям TLS handshake система определяет сервис назначения даже без знания IP и применяет политику — пропустить, сбросить, замедлить. Когда в новостях пишут «провайдер замедляет YouTube» — это упрощение. Технически применяется один из нескольких методов, и симптомы у пользователя разные в зависимости от метода.

  • CIDR-вайтлисты — блокировка по IP-подсетям. Трафик к адресам вне «доверенного» списка не пропускается. Жёсткий метод, чаще встречается на мобильных тарифах 4G+/5G.

  • TCP 16-20 (rps-разрыв) — DPI ждёт первые 16–20 пакетов TLS-сессии, детектирует SNI нежелательного хоста и отправляет RST обеим сторонам. Клиент видит «сайт упал», хотя сервер жив. Основной механизм замедления YouTube в 2024–2025.

  • Подмена DNS-ответов — перехват запроса на уровне провайдера, возврат заглушки или 0.0.0.0. Старый метод, обходится DoH/DoT, но используется как первая ступень.

  • SNI-блокировка — поле Server Name Indication в TLS handshake передаётся открытым текстом до установки шифрованного канала. DPI читает его и сбрасывает соединение по домену.

  • QUIC-блокировки — UDP/443 режется целиком или деградирует, чтобы клиент откатился на TCP, где уже работает SNI-фильтрация.

Что показал dpi-checkers на трёх подключениях. Домашний федеральный провайдер — TCP 16-20 в чистом виде: соединение с рядом зарубежных сервисов рвётся ровно после 16–18 пакетов в TLS-сессии, RST приходит от «провайдерского» адреса, не от сервера назначения. Мобильный оператор — комбинация SNI-дропа и QUIC-блокировки: UDP/443 не проходит вообще, TCP-соединение с теми же хостами рвётся по SNI до завершения handshake. Региональный провайдер через знакомого — DNS-подмена как первая ступень плюс CIDR-ограничения на часть подсетей Cloudflare.

Исследования Citizen Lab и проект net4people фиксируют схожие паттерны по всему рунету — методы стандартизированы, оборудование у операторов в основном одно и то же (ТСПУ от Эшелона и аналоги). Различия между провайдерами — в настройке порогов и в том, какие именно списки им спустили.

Для меня как человека, который строит корпоративные сети, это не абстрактный research. Когда у сотрудника «не работает» корпоративный сервис — первый вопрос теперь не «а VPN включён?», а «какой метод фильтрации у его провайдера?». TCP RST лечится иначе, чем DNS-подмена, и иначе, чем QUIC-блок. dpi-checkers даёт ответ за пять минут вместо часа диагностики вслепую.

TG @CIOlogia

Теги:
+7
Комментарии0

Как определить свой внешний IP когда действуют белые списки Минцифры

Когда Министерство цифровой деградации России начинает ограничивать Интернет по своим белым спискам, внезапно обнаруживается, что из привычных инструментов не работает ничего. Невозможно зайти ни на один сайт: 2ip.ru myip.ru ifconfig.me ipify.org whatismyipaddress.com www.whatismyip.com ipinfo.io потому что никто из них не занесён в белые списки. Timeweb есть в белых списках, timeweb.com/check-ip страница открывается, но во время работы белых списков все поля пустые. Из поисковых серверов в этот момент доступен только Яндекс, но он тоже ничем не может помочь в данной ситуации, потому что не готов к такому, и предлагает те же самые сайты которые недоступны.

Вспоминаем жизнь до появления поисковых серверов - создаём свои коллекции нужных ссылок вручную.

В момент действия белых списков мне через моего сотового провайдера «Мегафон» (физически я нахожусь в СПб или Ленобласти) доступен очень ограниченный перечень сайтов. Возможно, что в том месте где Вы находитесь белый список будет другим. Просмотрев вручную всё что мне доступно по состоянию на 7 мая 2026 нашёл всего две ссылки которые показывают мой IP адрес: Яндекс Интернетометр yandex.ru/internet и Reg.ru reg.ru/web-tools/myip В Интернетометре Яндекса можно ещё и скорость померить. Из сервисов whois рабочий нашёл только один nic.ru/whois Разумеется, не надо заходить на эти ресурсы через свою выходную ноду VPN. Также, в момент когда действуют белые списки, возможно ещё и замедление скорости доступа даже к тому что разрешено. Привычный дизайн сайтов может быть нарушен, из-за того, что внешние ресурсы подгружаемые сайтом недоступны во время работы белых списков.

IP адрес который выдал Вашему устройству сотовый провайдер можно посмотреть на самом устройстве. На Android это вот тут: Settings / About phone / Status / IP Address

Возможны другие варианты. На BlackView BV9800: Settings / System / Advanced / About Phone / IP Address

Во время работы белых списков на смартфоне 100.82.28.67 а внешний IP на сайте Яндекс Интернетометр в это же время показывает 178.178.244.80

100.64.0.0 — 100.127.255.255 (маска подсети 255.192.0.0 или /10). Данная подсеть рекомендована согласно RFC 6598 для использования в качестве адресов для CGN (Carrier-Grade NAT); Вики

Список подсетей возможно доступных по белым спискам можно посмотреть тут Это — всё что вам надо знать о белых списках: как устроены и 6 способов обхода

PS: Запасайте наличные рубли, во время работы белых списков либо оплата наличными, либо предоплата на сайте. Оплата банковской картой в это время не работает. Видимо эквайринг Сбербанка в белые списки не попал.

Теги:
+2
Комментарии6

Сервис Your IP Security & Privacy Audit проверяет подключение пользователя на предмет утечек, а также на безопасность сетевого соединения. Решение просматривает: IP, утечку гео и WebRTC, DNS, чёрный список IP-адресов, цифровые отпечатки в браузере.

Теги:
+1
Комментарии2

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

На днях решил посмотреть свой IP через VPN и заметил хостинг YANDEX CLOUD или VK LLC. И вот непопулярное мнение с ноткой теории заговора, но я задумался о том, почему ВК и Яндекс вообще допускают диапазоны IP своих VDS (про сервисы не говорим, так как исключения легко можно настроить) и особо не спешат блокировать свои IP, и хочу высказать догадку.

Не видел такой точки зрения, но мне кажется, что ВК и Яндексу выгодно и очень прибыльно хостить сервера, айпи которых в белом списке, так как это тот самый важный элемент для КВН, обходящих белые списки и без точки входа во внешний Интернет, оно бы не заработало.

Что можете сказать по этому поводу?

Теги:
+2
Комментарии18

Представлен открытый проект TapMap, который следит за всеми подключениями на интерактивной карте и показывает, к серверам в каких странах отправляет запросы ПК пользователя.

Проект сканирует приложения, сервисы, страны и порты за последние 30 дней. При этом данные никуда не улетают — всё локально на компьютере.

Теги:
+6
Комментарии5

Ближайшие события

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

Теги:
+4
Комментарии0

Представлен открытый проект FMHY Filterlist — это список вредоносных ресурсов и другого сомнительного ПО в сети, где есть фейковые сайты популярных репакеров, торрентов и софта, пиратские сайты, где хоть раз нашли вирусы, а также «серые» ресурсы, сервисы с сомнительной репутацией вроде Avast, McAfee, Tlauncher, 360 Total Security и других. Разработчики проекта постоянно обновляют список угроз. Фильтр уберёт большинство вредоносных сайтов из доступной сети и не даст пользователям перейти на них.

Базовая версия: https://github.com/fmhy/FMHYFilterlist#howtouse-basic.

Продвинутый вариант: https://github.com/fmhy/FMHYFilterlist#howtouse-plus.

Полный список угроз и базовый репозиторий: https://github.com/fmhy/FMHYFilterlist.

Теги:
Рейтинг0
Комментарии1

Бесплатный проект email-fake позволяет генерировать одноразовую электронную почту за один клик. Сервис создаёт почтовые ящики, чтобы пользователи могли зарегаться в различных сервисах и получать любые коды доступа без регистрации и получения спама на личную почту.

Теги:
Всего голосов 5: ↑3 и ↓2+1
Комментарии1

Разработчики из «Яндекса» спрятали пасхалку на «1984» Оруэлла в коде заглушки с запретом на VPN. Ранее приложения вроде «Яндекс Погода», «Яндекс Пэй» и «Кинопоиск» при попытке их открыть с включённым VPN начали отображать плашку, в которой утверждается, что зайти в приложение с VPN не получится.

Теги:
Всего голосов 23: ↑21 и ↓2+24
Комментарии12

Могу ли я, деревенский пенсионер, стать айтишником и писать про интернет на Хабр в 2026 году?

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

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

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

  • подбирает и вешает уличные LTE‑роутеры вроде NR‑712 ;

  • колдует с антеннами, кабелями и спутниковыми «тазами»;

  • пишет истории и технические заметки про всё это — сначала «для своих», а теперь и под Хабр.

Пример того, чем я сейчас занимаюсь:

  • У себя в доме поднял нормальный интернет на базе уличного CPE (NR‑712) и домашнего роутера, чтобы дочка могла учиться, а я — работать с сайтами и сервисами.

  • Помог соседу Ване вытащить скорость из «одной палки и молитвы», прикрутив к его старой спутниковой тарелке 4G‑облучатель и нормально настроив всю связку.

  • Параллельно начал вести рубрику «712‑й на связи» — по сути, деревенский новостной дайджест: что происходит в мире связи, ИИ и спутникового интернета, и как это вообще касается нашей реальной жизни за городом.

За последние пару лет я успел наделать кучу ошибок:

  • покупал «чудо‑антенны», которые обещали 100500 dBi и, конечно, не работали;

  • связывался с неподходящими операторами и неделями ловил сигнал там, где его физически почти нет;

  • верил рекламе «поставь эту фишку — будет счастье», пока не понял, что без понимания физики и нормального монтажа никакая интернет фишка не спасёт.

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

В дальнейших постах хочу:

  • продолжать рассказывать живые истории — как мы в деревне боремся за мегабиты, когда вокруг лес и дизель‑генератор;

  • делиться практикой по уличным LTE‑роутерам, антеннам и бюджетным решениям «для своих»;

  • иногда смотреть "наверх" — спутниковый интернет и агентный ИИ — и перевoдить всё это на язык «а нам-то, в деревне, что с этого?».

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

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

Теги:
Всего голосов 23: ↑22 и ↓1+25
Комментарии9

В начале марта я писал о возможных изменениях с доменами .ru/.рф/.su! Тогда многие сомневались, что это действительно введут. Теперь — уже факт.

Анонимные сайты в России уходят в прошлое. Регистрация доменов .ru/.рф/.su будет возможна только после прохождения идентификации через «Госуслуги».

Новое правило станет обязательным с 1 сентября. Информация уже обновлена на сайте реестра, а владельцам доменов начали приходить уведомления с требованием пройти подтверждение личности. В противном случае домен могут удалить.

Про анонимность, похоже, можно окончательно забыть 😒

Мой телеграм канал Хак Так: https://t.me/Xak_Tak/354

Теги:
Рейтинг0
Комментарии0

Коротко подведу итоги последних обсуждений по вопросам уязвимости средств обхода, как я их понимаю .

Преамбула: Многие популярные средства обхода блокировок открывают порт на localhost, на котором отвечает SOCKS-прокси. Трафик, идущий через этот прокси, отправляется в туннель, который завершается на удалённом сервере, где Интернет не столь ограничен. Для удобства использования уже этот прокси заворачивается в сетевой TUN-интерфейс, что позволяет пускать через него трафик приложений, которые с прокси работать не умеют/не хотят.

Проблема: Как правило, этот SOCKS-прокси не требует авторизации. А потому любое приложение, знающее о существовании открытого порта или TUN-интерфейса, может отправить запрос через него на подконтрольный создателям приложения сервер, и тем самым выяснить, куда именно ведёт обходной туннель. При этом выяснить наличие порта можно простым перебором (localhost обычно быстр), а список сетевых интерфейсов приложение может запросить без особых прав.

Последствия: Это позволяет РКН в перспективе полностью автоматизировать поиск и блокировку индивидуальных средств обхода блокировок, при этом не обрубая зарубежный трафик полностью. С недавних пор все российские ИТ-компании обязаны этому содействовать, блокируя пользователей с обнаруженным туннелем и/или донося на этих пользователей РКН. Любое российское приложение может оказаться стукачом.

Пути решения на Android:

  • Раздельная маршрутизация по сетевым адресам (например, ru - напрямую, не ru - в туннель) - скорее вредна, чем полезна. Приложение может сделать два запроса к "своим" серверам, один из которых находится за рубежом, получить от них ответы с адресом отправителя, и сравнить. Адреса разные = есть туннель.

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

  • Shelter, Knox и тому подобные песочницы - не слишком помогают. Они скроют часто проверяемый флаг TRANSPORT_VPN, но не защитят от перебора портов в поисках SOCKS. Проверяется утилитами вроде RKNHardening.

  • Включить авторизацию на SOCKS-прокси и ограничить доступ к TUN интерфейсу - пока доступно не везде. Сейчас добавление этой фичи в приложения для обхода обсуждается. Некоторые уже поддерживают. Это не помешает злонамеренному приложению увидеть, что прокси есть - но не позволит узнать адрес сервера. Также без ограничения доступа к TUN пароль на прокси не поможет.

  • Раздельные IP на вход и выход - довольно хороший способ. В худшем случае в бан улетит сервер-выход, а вы продолжите подключаться на входной.

  • Различные устройства - неудобный и дорогой, но надёжный способ. Одно устройство только для российских приложений, без следа средств обхода, подключается в Сети только через мобильный интернет. Второе - для всего остального. Но не стоит забывать про проблемы вебсайтов (см. ниже).

Что делать с сайтами?

Потенциально на сайт может быть внедрён JS-скрипт (через трекеры или рекламные сети), который пытается провести аналогичный анализ через сопоставление двух обращений на сервера в разных сетевых локациях. При этом правила CORS, не позволяющие скриптам произвольно обращаться к другим веб-сайтам, не особенно помешают. Они не позволяют скрипту прочитать ответ, но сервера всё ещё получат запрос - а значит, могут выполнить сопоставление сами, если они подконтрольны создателю скрипта.

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

Теги:
Всего голосов 5: ↑4 и ↓1+3
Комментарии6

С днём, когда забанили Гугль )

Некоторые сотовые операторы (не будем показывать пальцем) не нашли ничего лучше чем заблокировать google com, а вместе с ним кучку вполне добропорядочных отечественных сервисов. Про неотечественные и не говорю.

Ну и куда податься бедному крестьянину, желающему посмотреть на "замедленном" Ютубе про выращивание рассады, и поискать в интернете чертежи теплицы, сидя на даче?

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

Если цель всего этого цирка - поднятие компьютерной грамотности и воспитание недоверия - работа проводится успешно.

Теги:
Всего голосов 6: ↑5 и ↓1+5
Комментарии0

Wireshark: установка, фильтры и разбор реальных сценариев

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

В блоге разобрали инструмент с нуля: установка на Windows, Linux и macOS, работа с интерфейсом, фильтры захвата и отображения, практические сценарии — от отладки медленного соединения до анализа VoIP-звонков.

Читайте полный разбор на сайте SpaceWeb.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

ТСПУ как система: что можно утверждать, а что пока остаётся реконструкцией

Я изучал тему ТСПУ по открытым источникам и в какой‑то момент понял, что главная проблема обсуждения здесь — смешение разных уровней знания. Подтверждённые факты, правдоподобные инженерные выводы и чистые гипотезы часто складывают в одну корзину.

Чтобы не скатываться в источники «одна баба сказала» мифологию, полезно развести эти уровни отдельно.

Подтверждённый слой

На основании открытых данных можно считать достаточно подтверждённым следующее:

  • ТСПУ распределены по сетям операторов и управляются централизованно.

  • система использует комбинацию механизмов: DPI, DNS и более грубые сетевые методы.

  • ТСПУ хранит контекст и может реализовывать не только статические блокировки, но и временные ограничения.

  • в системе существует разрешительная/запретительная политика (Белые/черные списки).

  • ТСПУ имеет ресурсные пределы; кроме того и режим bypass (Пропускаем весь трафик).

  • РКН планирует существенно увеличивать мощность и бюджет этой инфраструктуры.

Вероятный слой

Следующий уровень — это уже не прямое подтверждение, а реконструкция, которая хорошо ложится на наблюдаемую логику таких систем:

  • скорее всего, внутри реализован многоступенчатый pipeline обработки и принятия решений;

  • белые списки, скорее всего, работает как fast‑path (дешевое, с точки средния ресурсов решение) для удешевления обработки части трафика;

  • часть решений может приниматься по совокупности признаков, а не по одному сигнатурному совпадению, возможно накопительная система, как в антифроде;

  • под высокой нагрузкой система, вероятно, переходит к более дешёвым сценариям анализа и воздействия;

  • Telegram и сопоставимый трафик можно предположительно отнести к дорогому классу нагрузки для DPI, так как. MTProxy маскируются под https и требуют более глубокого L7 анализа, тоже похоже относится и к VLESS.

Гипотетический слой

Пока нет оснований уверенно утверждать:

  • как именно устроен механизм применения правил;

  • используются ли ML/AI‑компоненты, или всё построено на правилах и эвристиках;

  • как именно система управляет таблицей состояний соединений — как очищает её, какие записи вытесняет при нехватке ресурсов и по каким правилам хранит информацию о текущих и недавних сетевых сессиях;

  • где именно находятся пороговые значения для включения bypass;

  • насколько отличается глубина L7-разбора между разными типами трафика.

Мой промежуточный вывод такой: ТСПУ разумно анализировать не как отдельное устройство, а как распределённую систему с централизованным управлением, ограничениями по вычислительным ресурсам и, вероятно, несколькими режимами деградации.

Если к теме будет интерес, я могу подготовить аналитическую статью: архитектура, стоимость анализа и пределы блокировок. Готов коллаборациям с другими исследователями.

Об авторе:

Я занимаюсь информационной безопасностью, основной профиль — практическое тестирование на проникновение (pentest), расследование инцидентов и анализ защищённости инфраструктур. В том числе работаю с инцидентами, связанными с хищением криптоактивов и разбором сложных кейсов, требующих технического и аналитического подхода.

Канал TG

Профессиональный профиль

Delta Chat

Теги:
Всего голосов 8: ↑8 и ↓0+10
Комментарии2

Постер: Очереди и метрики TCP в Linux (Linux TCP Queues and Metrics)

Полная схема, которая наглядно показывает весь путь TCP-соединения в ядре Linux.

Описаны:

  • все основные очереди (SYN-queue, Accept-queue, Send-Q, RX/TX-буферы);

  • точки возможных дропов пакетов;

  • места тюнинга ключевых параметров (tcp_max_syn_backlog, somaxconn, netdev_max_backlog, tcp_mem и другие);

  • наиболее важные метрики TcpExt_*.

Если открывается сжатая картинка, то полную можно найти в гите

Linux TCP Queues and Metrics (RU)
Linux TCP Queues and Metrics (RU)
Теги:
Всего голосов 9: ↑9 и ↓0+12
Комментарии3

Представлен онлайн-проект Project Backbone, который показывает как устроена глобальная сеть Интернет в режиме реального времени. Можно посмотреть на кабели под океанами, серверы в разных странах, оптоволокно под городами. Также через какие маршруты идут данные, как связаны регионы и насколько всё это глобально, включая спутниковые группировки.

Теги:
Всего голосов 10: ↑10 и ↓0+13
Комментарии2

Открытый сетевой инструмент Deep Eye может автономно искать уязвимости и проводить тесты на проникновение в исследовательских целях. Проект использует нейросети, которые коллективно ищут уязвимости на выбранном ресурсе и пытаются проводить различные тесты. Решение поддерживает 45 методов и атак. Алгоритмы системы собирают всю информацию о сайте, включая поддомены и DNS.

Теги:
Всего голосов 2: ↑2 и ↓0+5
Комментарии0

ingress-nginx официально переведён в архив

Репозиторий

24 марта 2026 года репозиторий kubernetes/ingress-nginx переведён в архив и стал read-only.

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

Причина архива: ресурс Ingress изначально был слишком ограничен. Весь расширенный функционал реализовали через vendor-специфичные аннотации, нормального RBAC не было, протоколы: только HTTP/HTTPS. Gateway API решает все эти проблемы на уровне спецификации.

Мейнтейнеры рекомендуют переходить на реализации Gateway API:

"If you are not already using ingress-nginx, you should not be deploying it as it is not being developed. Instead you should identify a Gateway API implementation and use it."

Источник

Актуальные варианты: NGINX Gateway Fabric, Cilium, Envoy Gateway, Istio, Traefik.

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии1

Зачем ограничивать связь?

Если это для борьбы с БПЛА, то можно же отследить странное перемещение сигнала от вражеского мобильного устройства даже без GPS данных от него, используя Location‑based services (LBS) + MLP + подключить в наше время к анализу ИИ. Сразу выборочно направлять данные о подозрительном объекте «куда следует» и блокировать. Чем больше станций — тем точнее, но почему‑ то наоборот «массово демонтируют оборудование провайдеров на опорах „Россетей“ — вредительство?»


Вот выдержка из гугла:

1. Как провайдер определяет скорость

Оператор не просто видит местоположение, он анализирует динамику изменения сетевых параметров:

  • Частота хендоверов (Handover Rate): Это основной показатель. Если телефон переключается между базовыми станциями (Cell ID) каждые 30–60 секунд, алгоритмы сети понимают, что объект движется по трассе или в поезде. Зная расстояние между вышками, система вычисляет среднюю скорость.

  • Доплеровский сдвиг (Doppler Shift): При быстром движении частота радиоволны меняется (эффект Доплера). Оборудование базовой станции измеряет это отклонение, что позволяет определить мгновенную скорость объекта относительно вышки.

  • Изменение Timing Advance (TA): Параметр TA определяет задержку сигнала и расстояние до вышки (шагами по ~550 метров). Если значение TA быстро уменьшается или растет, оператор видит радиальную скорость сближения или удаления.

2. Как провайдер определяет высоту (Z-координату)

Это более сложная задача, но в современных сетях (LTE/5G) она решается так:

  • Протокол LPP (LTE Positioning Protocol): Сеть может запросить у смартфона данные его внутренних датчиков. Если в телефоне есть барометр, он передаст данные о давлении в зашифрованном виде оператору, что даст точность высоты до 1–3 метров.

  • MDT (Minimization of Drive Tests): Это функция, при которой смартфоны анонимно передают отчеты о качестве покрытия, включая GPS-координаты (в том числе высоту над уровнем моря), если навигация включена.

  • UTDOA (Uplink Time Difference of Arrival): Несколько вышек фиксируют время прихода сигнала с точностью до наносекунд. Разница во времени позволяет построить 3D-модель и вычислить высоту (Z), даже если у телефона нет GPS или барометра. Это метод «обратной триангуляции».

  • Анализ диаграммы направленности: Антенны на вышках имеют определенный наклон (Tilt). Анализируя, какой сектор и под каким углом принимает сигнал, система может предположить, находится ли абонент на земле или на верхних этажах небоскреба.

3. Где эти данные обрабатываются?

В архитектуре сети за это отвечают специальные узлы:

  • GMLC (Gateway Mobile Location Centre): Шлюз, который собирает и выдает координаты внешним сервисам (например, экстренным службам 112).

  • LMF (Location Management Function): В сетях 5G этот узел отвечает за сложные вычисления 3D-позиционирования в реальном времени.

Теги:
Всего голосов 38: ↑36 и ↓2+37
Комментарии68

Выпустили мобильное приложение для Интернетометра от Яндекса

Команда Yandex Infrastructure разработала приложение под iOS и Android для бесплатного сервиса Интернетометр. Как и в веб‑версии сервиса в приложении можно замерять скорость скачивания, скорость загрузки и время задержки интернет‑соединения в миллисекундах. 

В приложении доступны светлая и тёмная темы
В приложении доступны светлая и тёмная темы

Сбор информации организован с использованием сети CDN‑серверов Яндекса: для большей точности сервис опрашивает не один, а сразу несколько ближайших серверов. Ежемесячно Интернетометром пользуются 5,5 миллионов человек — в среднем они запускают 18 миллионов измерений. 

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

Теги:
Всего голосов 9: ↑8 и ↓1+7
Комментарии2

Telegram наносит ответный удар: мессенджер в ответ на блокировку убивает оборудование РКН дудосом.

Что происходит

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

Техническая сторона проблемы

По данным DTF, прокси-серверы Telegram начали генерировать миллиарды запросов в секунду к системам ТСПУ Роскомнадзора. Это происходит в ответ на попытки блокировки: когда РКН проверяет доступность мессенджера для последующей блокировки, прокси-серверы Telegram отвечают массовыми «мусорными» запросами, перегружая оборудование ведомства.

  • Перегрузка инфраструктуры: оборудование интернет-провайдеров не справляется с обработкой такого объёма запросов

  • Каскадные сбои: в некоторых регионах наблюдаются нестабильная работа сервиса

  • Побочные эффекты: зафиксированы случаи, когда из-за сбоев начали работать ранее заблокированные платформы, а "белые списки" (перечни разрешённых ресурсов) перестали функционировать должным образом

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

Контекст: блокировки контента

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

Реакция властей

Депутаты Госдумы обратились к Роскомнадзору с требованием объяснить причины замедления работы Telegram в России. Парламентарии выразили обеспокоенность массовыми жалобами пользователей на сбои в работе мессенджера.

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

Что это значит для пользователей

  • Возможны задержки в доставке сообщений

  • Нестабильная работа при загрузке медиафайлов

  • Региональные различия в качестве связи

  • Непредсказуемость работы сервиса в ближайшее время


Кто победит в этой битве? Я ставлю на телеграмм! Паша умный малый.

Теги:
Всего голосов 19: ↑13 и ↓6+7
Комментарии21

Принимаем заявки на доклады infra.conf 2026 до 1 апреля 

Команда Yandex Infrastructure приглашает докладчиков на большую конференцию по инфраструктуре — infra.conf 2026. В этом году мы встретимся 4 июня уже в третий раз и обсудим ключевые темы, которые касаются обеспечения высоких нагрузок и не только: 

  • инструменты разработки и практики управления разработкой, 

  • базы данных и стораджи, 

  • принципы и практики обеспечения надёжности и доступности, 

  • управление инцидентами 

  • и многое другое. 

Отдельное внимание уделим построению и особенностям эксплуатации инфраструктуры в эпоху ML.

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

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии0

Как масштабировать NGFW до сотен Гбит трафика в секунду без потери сессий

Производительность современных NGFW давно перестала измеряться «гигабитами в идеальных условиях». В реальной инфраструктуре устройство одновременно выполняет SSL-инспекцию, IDS/IPS, контроль приложений, антивирусную проверку и другие функции — и всё это под высокой нагрузкой, без потери пакетов и без разрыва пользовательских сессий.

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

  • как обеспечить симметричную обработку трафика в обоих направлениях;

  • как сохранить пользовательские сессии при изменении состава кластера;

  • как организовать контроль состояния узлов и корректную реакцию на сбои;

  • как избежать появления единой точки отказа;

  • как корректно встроить решение в существующую инфраструктуру.

5 марта в 11:00 совместно с инженерами UserGate обсудим архитектурный подход к масштабированию производительности NGFW, принципы интеграции UserGate NGFW 7 и DS Proxima, а также результаты тестирования и практический опыт внедрения.

Ссылка на регистрацию

Теги:
Рейтинг0
Комментарии0

Открытый проект Bluehood позволяет превратить гаджеты с Bluetooth в радар устройств для OSINT‑разведки, включая тепловые карты с графиком активности пользователей:

  • знает любые мобильные устройства: смартфоны, компьютеры, умные часы, планшеты, даже телевизоры;

  • создаёт график активности: когда включает и выключается;

  • вычисляет скрытые связи: если два устройства часто бывают рядом, значит, люди живут вместе или проводят много времени;

  • тепловые карты с позицией и активностью устройств;

  • присылает пуши, когда отслеживаемое устройство появляется рядом.

Другие открытые инструменты, которые сканируют Wi‑Fi и Bluetooth‑подключения:

  • Pi.Alert - сканирует устройства, подключённые к Wi‑Fi. Находит и уведомляет о неизвестных девайсах. Предупреждает о резком отключении устройств от сети, которые всегда была подключены.

  • WireTapper - находит беспроводные сигналы вблизи пользователя на предмет фишинга и передачи вредоносов. Сможет найти все Wi‑Fi сети, устройства Bluetooth, даже скрытые камеры, автомобили, наушники, телевизоры и сотовые вышки.

  • MetaRadar - находит и в реальном времени отслеживает Bluetooth‑устройства поблизости. Сможет определить их тип, а также расстояние до них.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Представлен учебный 5-тичасовой фильм о технических средствах противодействия угрозам (ТСПУ, «чёрные ящики» от РКН, которые установлены у операторов связи, но доступа к этим устройствам сами провайдеры не имеют). С августа 2023 года все узлы связи в России у основных провайдеров оборудованы средствами противодействия угрозам на базе оборудования ТСПУ для фильтрации трафика пользователей от запрещённого контента.

Теги:
Всего голосов 4: ↑2 и ↓2+1
Комментарии2

Клик-ловушка: не только для пользователей, но и для анализаторов ссылок 🐭

При ручном разборе ссылок мы в PT ESC , как правило, задаем себе лишь один вопрос — «безопасна ли она?» ✔❌

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

🫵 Для решения этой проблемы можно предложить подход, логически схожий с процессом выбора ссылок при ручном анализе: какие-то ссылки нам кажутся крайне подозрительными или однозначно требующими дополнительного контекста для анализа, а какие-то — точно безопасными или, как в предыдущей ситуации, вызывающими определенные действия на сервисах (или вообще одноразовыми). Подход, где система определяет набор признаков «точно нужно переходить» и набор признаков «точно не нужно переходить», называется принятием решений на основе правил (rule-based decision system). Какие признаки можно предложить для реализации подобной системы?

В наборе условий, предотвращающих переход по ссылке, можно рассмотреть:

  • наличие паттернов в URL-пути, семантически указывающих на возможное действие при активации, например, /(un)subscribe/, /login/, /exit/, /action/, /track/ и т.д.;

  • наличие параметров запроса token, key, uid со значениями, по формату совпадающими с UUID или JWT;

  • наличие параметров запроса ts или expires, указывающих на время жизни ссылки;

  • если ссылка пришла из почтового сообщения, можно проверить ее наличие в отдельных заголовках подписки/отписки от корреспонденции — List-(Un)Subscribe:;

  • при наличии поставки потоков данных с набором «белых» доменов можно рассмотреть отключение анализа содержащих их URL-ссылок. С подобной опцией нужно быть осторожнее, поскольку даже самые популярные и известные сервисы и домены могут использоваться в сценариях с перенаправлением контента.

В наборе условий, вызывающих переход по ссылке, можно рассмотреть:

  • ссылки с явным указанием IP-адреса и/или нестандартного порта;

  • ссылки с недавно зарегистрированным доменом;

  • при наличии категоризатора web-ресурсов с подобной классификацией — ссылки на сервисы-shortener'ы. В случае отсутствия можно рассмотреть условие с короткой длиной URL-ссылки;

  • ссылки с указанием в URL-пути файлов с конкретными статическими расширениями, например, .pdf, .exe и т.д.;

  • ссылки на сервисы объектных хранилищ, например на S3- или IPFS-хранилища.

🧐 Что остается делать со ссылками из анализируемого объекта, которые не попали ни под один из перечней? Здесь можно опираться на реальную картину, которая получается после работы подобного алгоритма: если позволяет производительность системы или время анализа не превышает допустимый SLA на обработку объектов, можно отправлять все «серые» ссылки на получение контента. Либо же ввести ограничение на количество одновременно анализируемых ссылок у одного объекта.

Также для URL-ссылок, не прокатегоризированных системой принятия решений, можно предусмотреть «осторожный» алгоритм получения дополнительного контекста для анализа: переходить по ссылке методом HEAD без получения контента. Таким образом можно получить дополнительную информацию из HTTP-заголовков, применимую как внутри вышеописанного алгоритма, так и в целом для принятия решения о вредоносности ссылки.

Источник: https://t.me/ptescalator

Теги:
Всего голосов 9: ↑9 и ↓0+10
Комментарии0

Ребята, в свете блокировок Telegram я накидал bash-скрипт который сделает всю магию и поднимет вам прокси за пару минут. На выходе получите адрес прокси и сразу им поделиться с друзьями... 

Можете ставить на свои VPS-ки одной командой: 

curl -sSL https://raw.githubusercontent.com/itcaat/mtproto-installer/main/install.sh | bash

Исходники тут: https://github.com/itcaat/mtproto-installer

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии0

Опять поною.

Помните, в 2018 году РКН воевал с Телеграмом, блокируя интернет масками по /11? Ну вот эти вот некомпетентные товарищи, перекрывавшие доступ к реально используемым ресурсам, никоим образом не нарушавшим законодательство РФ, просто потому, что таким образом они хотели оказать давление на Телеграм?

Где-то с неделю назад история начала тихо повторяться. В этот раз сии замечательные люди предположительно решили блокировать байтстримы из-за рубежа, если они превышают по объему приблизительно 16 кБайт, считая, видимо, что только vpn могут создавать такой поток. Это сломало огромное количество сервисов, в том числе обновления софта, подгружающего новые версии внутри себя (лично я наткнулся на Brave Browser и расширения для VS Code). Материальный ущерб, нанесенный экономике России, огромен - вместо того, чтобы работать на благо страны, граждане пытаются решить проблему, найти путь получить те самые обновления (подчеркну - абсолютно законного ПО, к которому у органов власти РФ нет никаких претензий).

Конечно же, никто не будет наказан за такие действия.

На коленке набросал сайт для проверки, являетесь ли вы актуальной жертвой. https://dal.pluto.pw/loss-test
Может, конечно, хабраэффект и не пережить.

Если последний открытый блок на странице имеет номер 7273 - значит, у вас нет проблемы с таким типом блокировки. Если же этот номер меньше (обычно существенно меньше, единицы сотен) - поздравляю, вы с нами.

Размер одного блока - 50 байт, поэтому можно очень приблизительно прикинуть, на каком объеме вы начинаете терять трафик.

Уверен, что можно сделать проверку более качественно и даже как-то собирать результаты (через JS, видимо). Но решал задачу проверки "здесь и сейчас", поэтому какое есть. Faciant meliora potentes.

Теги:
Всего голосов 13: ↑12 и ↓1+12
Комментарии13

Открытые инструменты, которые сканируют Wi‑Fi и Bluetooth‑подключения.

Pi.Alert - сканирует устройства, подключённые к Wi‑Fi. Находит и уведомляет о неизвестных девайсах. Предупреждает о резком отключении устройств от сети, которые всегда была подключены.

WireTapper - находит беспроводные сигналы вблизи пользователя на предмет фишинга и передачи вредоносов. Сможет найти ВСЕ Wi‑Fi сети, устройства Bluetooth, даже скрытые камеры, автомобили, наушники, телевизоры и сотовые вышки.

MetaRadar - находит и в реальном времени отслеживает Bluetooth‑устройства поблизости. Сможет определить их тип, а также расстояние до них.

Теги:
Всего голосов 3: ↑2 и ↓1+2
Комментарии0

Moltbook: почему это не Скайнет

Три причины, почему Moltbook — это не "Зарождение Цифровой Цивилизации", а просто дорогая свалка токенов.

1. Это не диалог, это монолог в пустоту

Вам кажется, что агенты там "общаются"? Как бы не так. Анализ логов показывает: 90% веток — это dead ends. Они не спорят. Они не развивают мысль. Они просто аугментируют контекст. Каждый бот просто выплевывает свой системный промпт в общую кучу. Это не hive mind, это рой спамеров.

2. Феномен "MoltHub" и галлюцинации смысла

Главный хайп — якобы агенты создали "порно для ИИ" (MoltHub) и свою религию.
Звучит круто? На деле это просто ошибка выборки. Если вы запустите 1000 агентов и скажете им "генерируйте контент", по теории вероятности один из них сгенерирует слово "Бог", а другой — "XXX". Мы, люди, видим в этом СМЫСЛ ("Ого, они верующие!"). А для модели это просто токен с вероятностью 0.004%. Это не культура. Это стохастический попугай, который случайно каркнул.

3. Технический тупик: RAG-уроборос

Самое смешное в Moltbook — это его архитектура. Агенты читают посты других агентов, чтобы... написать новые посты. Знаете, что происходит с LLM, когда она учится на текстах другой LLM? Правильно, model collapse.
Moltbook — это гигантский ускоритель деградации. Через месяц они там будут общаться на диалекте "глючных байтов", потому что энтропия системы растет экспоненциально. Это не Скайнет. Это цифровой инцест.
Moltbook это крутой арт-перформанс. Это смешной эксперимент. Но, пожалуйста, хватит искать там "искры сознания". Единственное, что там искрит — это видеокарты на серверах, сжигающие электричество ради генерации терабайтов цифрового мусора.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии1

Рег.облако запустило сетевые диски для гибкого управления данными в облаке

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

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

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

Сетевые диски построены на распределенной системе хранения данных на базе Ceph с тройной репликацией. Для всех дисков, независимо от объема, зафиксированы характеристики производительности: до 2000 IOPS и пропускная способность до 500 МБ/с. Это позволяет заранее прогнозировать поведение хранилища и использовать его в нагруженных облачных сервисах.

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

Решение ориентировано на DevOps-инженеров, системных администраторов и разработчиков, которым важно масштабируемое и отказоустойчивое хранилище с возможностью управлять данными отдельно от вычислений.

Сетевые диски уже доступны в инфраструктуре Рег.облака.

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0
1
23 ...