Сервис Your IP Security & Privacy Audit проверяет подключение пользователя на предмет утечек, а также на безопасность сетевого соединения. Решение просматривает: IP, утечку гео и WebRTC, DNS, чёрный список IP-адресов, цифровые отпечатки в браузере.
Если вы считаете, что вы обманули белые списки Роскомнадзора с помощью VLESS и прочих квн-чудес, то просто представьте, как всё это держится на Yandex Cloud и VK Cloud за счет того, что они арендуют сервера с диапазонами айпи в белых списках...
На днях решил посмотреть свой IP через VPN и заметил хостинг YANDEX CLOUD или VK LLC. И вот непопулярное мнение с ноткой теории заговора, но я задумался о том, почему ВК и Яндекс вообще допускают диапазоны IP своих VDS (про сервисы не говорим, так как исключения легко можно настроить) и особо не спешат блокировать свои IP, и хочу высказать догадку.
Не видел такой точки зрения, но мне кажется, что ВК и Яндексу выгодно и очень прибыльно хостить сервера, айпи которых в белом списке, так как это тот самый важный элемент для КВН, обходящих белые списки и без точки входа во внешний Интернет, оно бы не заработало.
Что можете сказать по этому поводу?
Представлен открытый проект TapMap, который следит за всеми подключениями на интерактивной карте и показывает, к серверам в каких странах отправляет запросы ПК пользователя.
Проект сканирует приложения, сервисы, страны и порты за последние 30 дней. При этом данные никуда не улетают — всё локально на компьютере.
Согласно долгосрочной статистике статуса доступности сервисов GitHub, после покупки платформы Microsoft аптайм проекта начал незначительно, но стабильно снижаться.
Представлен открытый проект 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.
Бесплатный проект email-fake позволяет генерировать одноразовую электронную почту за один клик. Сервис создаёт почтовые ящики, чтобы пользователи могли зарегаться в различных сервисах и получать любые коды доступа без регистрации и получения спама на личную почту.
Разработчики из «Яндекса» спрятали пасхалку на «1984» Оруэлла в коде заглушки с запретом на VPN. Ранее приложения вроде «Яндекс Погода», «Яндекс Пэй» и «Кинопоиск» при попытке их открыть с включённым VPN начали отображать плашку, в которой утверждается, что зайти в приложение с VPN не получится.
Могу ли я, деревенский пенсионер, стать айтишником и писать про интернет на Хабр в 2026 году?
В этом посте хочу поделиться своим опытом: может ли человек без профильного образования, без работы в провинциальном «айти‑парке», да ещё и на пенсии, стать тем самым «деревенским айтишником» и писать полезные вещи на Хабр в 2026 году.
Меня зовут Алекс, я живу в Архангельской области, в обычной деревне, и последние годы занимаюсь тем, что добываю нормальный интернет — себе, соседям и всем, кто приходит с фразой: «Сделай, как у Вани, только чтобы не дорого и не падало».
По профессии я не программист и не сетевой инженер. Всю жизнь работал ближе к «земным» делам, а айти было где‑то поблизости в виде «помоги настроить, починить, провести». Но так получилось, что именно на пенсии я стал тем человеком, который:
подбирает и вешает уличные LTE‑роутеры вроде NR‑712 ;
колдует с антеннами, кабелями и спутниковыми «тазами»;
пишет истории и технические заметки про всё это — сначала «для своих», а теперь и под Хабр.
Пример того, чем я сейчас занимаюсь:
У себя в доме поднял нормальный интернет на базе уличного CPE (NR‑712) и домашнего роутера, чтобы дочка могла учиться, а я — работать с сайтами и сервисами.
Помог соседу Ване вытащить скорость из «одной палки и молитвы», прикрутив к его старой спутниковой тарелке 4G‑облучатель и нормально настроив всю связку.
Параллельно начал вести рубрику «712‑й на связи» — по сути, деревенский новостной дайджест: что происходит в мире связи, ИИ и спутникового интернета, и как это вообще касается нашей реальной жизни за городом.
За последние пару лет я успел наделать кучу ошибок:
покупал «чудо‑антенны», которые обещали 100500 dBi и, конечно, не работали;
связывался с неподходящими операторами и неделями ловил сигнал там, где его физически почти нет;
верил рекламе «поставь эту фишку — будет счастье», пока не понял, что без понимания физики и нормального монтажа никакая интернет фишка не спасёт.
Часть этих ошибок я уже обернул в рассказы и статьи — с примерами, цифрами и честным деревенским юмором. Часть ещё ждёт своего часа.
В дальнейших постах хочу:
продолжать рассказывать живые истории — как мы в деревне боремся за мегабиты, когда вокруг лес и дизель‑генератор;
делиться практикой по уличным LTE‑роутерам, антеннам и бюджетным решениям «для своих»;
иногда смотреть "наверх" — спутниковый интернет и агентный ИИ — и перевoдить всё это на язык «а нам-то, в деревне, что с этого?».
Этим постом я, по сути, знакомлюсь с аудиторией Хабра:
я не «сеньор девопс из корпорации», я тот самый человек, который ставит интернет в доме, где оптика закончилась в соседнем райцентре.
Если вам близка тема связи в регионах, бюджетных сетевых решений и «человеческих» рассказов с матчастью — буду рад видеть вас в комментариях и следующих историях.
В начале марта я писал о возможных изменениях с доменами .ru/.рф/.su! Тогда многие сомневались, что это действительно введут. Теперь — уже факт.
Анонимные сайты в России уходят в прошлое. Регистрация доменов .ru/.рф/.su будет возможна только после прохождения идентификации через «Госуслуги».
Новое правило станет обязательным с 1 сентября. Информация уже обновлена на сайте реестра, а владельцам доменов начали приходить уведомления с требованием пройти подтверждение личности. В противном случае домен могут удалить.
Про анонимность, похоже, можно окончательно забыть 😒
Мой телеграм канал Хак Так: https://t.me/Xak_Tak/354
Коротко подведу итоги последних обсуждений по вопросам уязвимости средств обхода, как я их понимаю .
Преамбула: Многие популярные средства обхода блокировок открывают порт на localhost, на котором отвечает SOCKS-прокси. Трафик, идущий через этот прокси, отправляется в туннель, который завершается на удалённом сервере, где Интернет не столь ограничен. Для удобства использования уже этот прокси заворачивается в сетевой TUN-интерфейс, что позволяет пускать через него трафик приложений, которые с прокси работать не умеют/не хотят.
Проблема: Как правило, этот SOCKS-прокси не требует авторизации. А потому любое приложение, знающее о существовании открытого порта или TUN-интерфейса, может отправить запрос через него на подконтрольный создателям приложения сервер, и тем самым выяснить, куда именно ведёт обходной туннель. При этом выяснить наличие порта можно простым перебором (localhost обычно быстр), а список сетевых интерфейсов приложение может запросить без особых прав.
Последствия: Это позволяет РКН в перспективе полностью автоматизировать поиск и блокировку индивидуальных средств обхода блокировок, при этом не обрубая зарубежный трафик полностью. С недавних пор все российские ИТ-компании обязаны этому содействовать, блокируя пользователей с обнаруженным туннелем и/или донося на этих пользователей РКН. Любое российское приложение может оказаться стукачом.
Пути решения на Android:
Раздельная маршрутизация по сетевым адресам (например, ru - напрямую, не ru - в туннель) - скорее вредна, чем полезна. Приложение может сделать два запроса к "своим" серверам, один из которых находится за рубежом, получить от них ответы с адресом отправителя, и сравнить. Адреса разные = есть туннель.
"Обычная" раздельная маршрутизация по приложениям - гарантий не даёт. Насколько я понимаю, она просто задаёт сетевой интерфейс, который приложение использует по умолчанию, но не запрещает приложению использовать другие интерфейсы. Также она не мешает сканировать порты в поисках SOCKS-прокси.
Shelter, Knox и тому подобные песочницы - не слишком помогают. Они скроют часто проверяемый флаг
TRANSPORT_VPN, но не защитят от перебора портов в поисках SOCKS. Проверяется утилитами вроде RKNHardening.Включить авторизацию на SOCKS-прокси и ограничить доступ к TUN интерфейсу - пока доступно не везде. Сейчас добавление этой фичи в приложения для обхода обсуждается. Некоторые уже поддерживают. Это не помешает злонамеренному приложению увидеть, что прокси есть - но не позволит узнать адрес сервера. Также без ограничения доступа к TUN пароль на прокси не поможет.
Раздельные IP на вход и выход - довольно хороший способ. В худшем случае в бан улетит сервер-выход, а вы продолжите подключаться на входной.
Различные устройства - неудобный и дорогой, но надёжный способ. Одно устройство только для российских приложений, без следа средств обхода, подключается в Сети только через мобильный интернет. Второе - для всего остального. Но не стоит забывать про проблемы вебсайтов (см. ниже).
Что делать с сайтами?
Потенциально на сайт может быть внедрён JS-скрипт (через трекеры или рекламные сети), который пытается провести аналогичный анализ через сопоставление двух обращений на сервера в разных сетевых локациях. При этом правила CORS, не позволяющие скриптам произвольно обращаться к другим веб-сайтам, не особенно помешают. Они не позволяют скрипту прочитать ответ, но сервера всё ещё получат запрос - а значит, могут выполнить сопоставление сами, если они подконтрольны создателю скрипта.
Поэтому разумным представляется такой вариант: два разных браузера, или два разных профиля в одном браузере. Один без прокси, под работу с доступными сайтами и один под потенциальную запрещёнку. В оба профиля ставим адблокер и жёстко режем доступ к любым рекламным сетям - не гарантия, но может помочь. Во втором профиле - никакой раздельной маршрутизации, все запросы строго через прокси. На российские и другие подозрительные ресурсы через второй профиль не ходим никогда.
С днём, когда забанили Гугль )
Некоторые сотовые операторы (не будем показывать пальцем) не нашли ничего лучше чем заблокировать google com, а вместе с ним кучку вполне добропорядочных отечественных сервисов. Про неотечественные и не говорю.
Ну и куда податься бедному крестьянину, желающему посмотреть на "замедленном" Ютубе про выращивание рассады, и поискать в интернете чертежи теплицы, сидя на даче?
Пришлось пенсионерам приобщаться к премудростям работы сетей и к технологиям исправления поломанного. Заодно и телеграм с вотсапом заработали.
Если цель всего этого цирка - поднятие компьютерной грамотности и воспитание недоверия - работа проводится успешно.
Wireshark: установка, фильтры и разбор реальных сценариев
Сеть ведет себя странно, но непонятно где именно — знакомая ситуация? Wireshark в таких случаях помогает увидеть трафик изнутри: перехватить пакеты, отфильтровать нужное и найти проблему — будь то задержки, потери пакетов или подозрительная активность.
В блоге разобрали инструмент с нуля: установка на Windows, Linux и macOS, работа с интерфейсом, фильтры захвата и отображения, практические сценарии — от отладки медленного соединения до анализа VoIP-звонков.
Читайте полный разбор на сайте SpaceWeb.
ТСПУ как система: что можно утверждать, а что пока остаётся реконструкцией
Я изучал тему ТСПУ по открытым источникам и в какой‑то момент понял, что главная проблема обсуждения здесь — смешение разных уровней знания. Подтверждённые факты, правдоподобные инженерные выводы и чистые гипотезы часто складывают в одну корзину.
Чтобы не скатываться в источники «одна баба сказала» мифологию, полезно развести эти уровни отдельно.
Подтверждённый слой
На основании открытых данных можно считать достаточно подтверждённым следующее:
ТСПУ распределены по сетям операторов и управляются централизованно.
система использует комбинацию механизмов: DPI, DNS и более грубые сетевые методы.
ТСПУ хранит контекст и может реализовывать не только статические блокировки, но и временные ограничения.
в системе существует разрешительная/запретительная политика (Белые/черные списки).
ТСПУ имеет ресурсные пределы; кроме того и режим bypass (Пропускаем весь трафик).
РКН планирует существенно увеличивать мощность и бюджет этой инфраструктуры.
Вероятный слой
Следующий уровень — это уже не прямое подтверждение, а реконструкция, которая хорошо ложится на наблюдаемую логику таких систем:
скорее всего, внутри реализован многоступенчатый pipeline обработки и принятия решений;
белые списки, скорее всего, работает как fast‑path (дешевое, с точки средния ресурсов решение) для удешевления обработки части трафика;
часть решений может приниматься по совокупности признаков, а не по одному сигнатурному совпадению, возможно накопительная система, как в антифроде;
под высокой нагрузкой система, вероятно, переходит к более дешёвым сценариям анализа и воздействия;
Telegram и сопоставимый трафик можно предположительно отнести к дорогому классу нагрузки для DPI, так как. MTProxy маскируются под https и требуют более глубокого L7 анализа, тоже похоже относится и к VLESS.
Гипотетический слой
Пока нет оснований уверенно утверждать:
как именно устроен механизм применения правил;
используются ли ML/AI‑компоненты, или всё построено на правилах и эвристиках;
как именно система управляет таблицей состояний соединений — как очищает её, какие записи вытесняет при нехватке ресурсов и по каким правилам хранит информацию о текущих и недавних сетевых сессиях;
где именно находятся пороговые значения для включения bypass;
насколько отличается глубина L7-разбора между разными типами трафика.
Мой промежуточный вывод такой: ТСПУ разумно анализировать не как отдельное устройство, а как распределённую систему с централизованным управлением, ограничениями по вычислительным ресурсам и, вероятно, несколькими режимами деградации.
Если к теме будет интерес, я могу подготовить аналитическую статью: архитектура, стоимость анализа и пределы блокировок. Готов коллаборациям с другими исследователями.
Об авторе:
Я занимаюсь информационной безопасностью, основной профиль — практическое тестирование на проникновение (pentest), расследование инцидентов и анализ защищённости инфраструктур. В том числе работаю с инцидентами, связанными с хищением криптоактивов и разбором сложных кейсов, требующих технического и аналитического подхода.
Ближайшие события
Постер: Очереди и метрики 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_*.
Если открывается сжатая картинка, то полную можно найти в гите
Представлен онлайн-проект Project Backbone, который показывает как устроена глобальная сеть Интернет в режиме реального времени. Можно посмотреть на кабели под океанами, серверы в разных странах, оптоволокно под городами. Также через какие маршруты идут данные, как связаны регионы и насколько всё это глобально, включая спутниковые группировки.
Открытый сетевой инструмент Deep Eye может автономно искать уязвимости и проводить тесты на проникновение в исследовательских целях. Проект использует нейросети, которые коллективно ищут уязвимости на выбранном ресурсе и пытаются проводить различные тесты. Решение поддерживает 45 методов и атак. Алгоритмы системы собирают всю информацию о сайте, включая поддомены и DNS.
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.
Зачем ограничивать связь?
Если это для борьбы с БПЛА, то можно же отследить странное перемещение сигнала от вражеского мобильного устройства даже без 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-позиционирования в реальном времени.
Выпустили мобильное приложение для Интернетометра от Яндекса
Команда Yandex Infrastructure разработала приложение под iOS и Android для бесплатного сервиса Интернетометр. Как и в веб‑версии сервиса в приложении можно замерять скорость скачивания, скорость загрузки и время задержки интернет‑соединения в миллисекундах.
Сбор информации организован с использованием сети CDN‑серверов Яндекса: для большей точности сервис опрашивает не один, а сразу несколько ближайших серверов. Ежемесячно Интернетометром пользуются 5,5 миллионов человек — в среднем они запускают 18 миллионов измерений.
Сервис предоставляет ключевую информацию о подключении: IP‑адрес, версию браузера, разрешение экрана и так далее. В будущем в приложении будет доступен расширенный режим измерений: он будет особенно полезен для технических специалистов, которые настраивают интернет‑соединение. Также у провайдеров проводной и беспроводной связи появится личный кабинет, где они смогут отслеживать замеры в зоне своего покрытия.
Telegram наносит ответный удар: мессенджер в ответ на блокировку убивает оборудование РКН дудосом.
Что происходит
В последние дни пользователи Telegram в России столкнулись с серьёзными проблемами в работе мессенджера. Ситуация развивается на фоне активных блокировок нежелательного контента самим Telegram и последующих технических проблем с инфраструктурой.
Техническая сторона проблемы
По данным DTF, прокси-серверы Telegram начали генерировать миллиарды запросов в секунду к системам ТСПУ Роскомнадзора. Это происходит в ответ на попытки блокировки: когда РКН проверяет доступность мессенджера для последующей блокировки, прокси-серверы Telegram отвечают массовыми «мусорными» запросами, перегружая оборудование ведомства.
Перегрузка инфраструктуры: оборудование интернет-провайдеров не справляется с обработкой такого объёма запросов
Каскадные сбои: в некоторых регионах наблюдаются нестабильная работа сервиса
Побочные эффекты: зафиксированы случаи, когда из-за сбоев начали работать ранее заблокированные платформы, а "белые списки" (перечни разрешённых ресурсов) перестали функционировать должным образом
Важно: данная информация исходит из неофициальных источников и требует подтверждения.
Контекст: блокировки контента
Проблемы возникли на фоне того, что сам Telegram активизировал блокировку каналов с нежелательным контентом. Это могло спровоцировать изменения в работе протоколов мессенджера и, как следствие, повлиять на характер сетевого трафика.
Реакция властей
Депутаты Госдумы обратились к Роскомнадзору с требованием объяснить причины замедления работы Telegram в России. Парламентарии выразили обеспокоенность массовыми жалобами пользователей на сбои в работе мессенджера.
Интересно, что претензии к регулятору поступают именно после того, как Telegram начал самостоятельно блокировать контент — действие, которое ранее от платформы активно требовалось.
Что это значит для пользователей
Возможны задержки в доставке сообщений
Нестабильная работа при загрузке медиафайлов
Региональные различия в качестве связи
Непредсказуемость работы сервиса в ближайшее время
Кто победит в этой битве? Я ставлю на телеграмм! Паша умный малый.
Принимаем заявки на доклады infra.conf 2026 до 1 апреля
Команда Yandex Infrastructure приглашает докладчиков на большую конференцию по инфраструктуре — infra.conf 2026. В этом году мы встретимся 4 июня уже в третий раз и обсудим ключевые темы, которые касаются обеспечения высоких нагрузок и не только:
инструменты разработки и практики управления разработкой,
базы данных и стораджи,
принципы и практики обеспечения надёжности и доступности,
управление инцидентами
и многое другое.
Отдельное внимание уделим построению и особенностям эксплуатации инфраструктуры в эпоху ML.
Приём заявок на выступление открыт до 1 апреля включительно в этой форме.
Чтобы заявить свою тему на этом этапе, достаточно тезисов и общего плана. Координатор конференции и участники программного комитета свяжутся с каждым спикером для обсуждения материала, а финальное решение по докладам будет принято до 1 мая.
Как масштабировать NGFW до сотен Гбит трафика в секунду без потери сессий
Производительность современных NGFW давно перестала измеряться «гигабитами в идеальных условиях». В реальной инфраструктуре устройство одновременно выполняет SSL-инспекцию, IDS/IPS, контроль приложений, антивирусную проверку и другие функции — и всё это под высокой нагрузкой, без потери пакетов и без разрыва пользовательских сессий.
Когда речь идёт о десятках и сотнях Гбит трафика в секунду, вертикальное масштабирование упирается в архитектурные ограничения. Горизонтальный подход выглядит логичным, но на практике поднимает целый ряд инженерных вопросов:
как обеспечить симметричную обработку трафика в обоих направлениях;
как сохранить пользовательские сессии при изменении состава кластера;
как организовать контроль состояния узлов и корректную реакцию на сбои;
как избежать появления единой точки отказа;
как корректно встроить решение в существующую инфраструктуру.
5 марта в 11:00 совместно с инженерами UserGate обсудим архитектурный подход к масштабированию производительности NGFW, принципы интеграции UserGate NGFW 7 и DS Proxima, а также результаты тестирования и практический опыт внедрения.
Открытый проект Bluehood позволяет превратить гаджеты с Bluetooth в радар устройств для OSINT‑разведки, включая тепловые карты с графиком активности пользователей:
знает любые мобильные устройства: смартфоны, компьютеры, умные часы, планшеты, даже телевизоры;
создаёт график активности: когда включает и выключается;
вычисляет скрытые связи: если два устройства часто бывают рядом, значит, люди живут вместе или проводят много времени;
тепловые карты с позицией и активностью устройств;
присылает пуши, когда отслеживаемое устройство появляется рядом.
Другие открытые инструменты, которые сканируют Wi‑Fi и Bluetooth‑подключения:
Pi.Alert - сканирует устройства, подключённые к Wi‑Fi. Находит и уведомляет о неизвестных девайсах. Предупреждает о резком отключении устройств от сети, которые всегда была подключены.
WireTapper - находит беспроводные сигналы вблизи пользователя на предмет фишинга и передачи вредоносов. Сможет найти все Wi‑Fi сети, устройства Bluetooth, даже скрытые камеры, автомобили, наушники, телевизоры и сотовые вышки.
MetaRadar - находит и в реальном времени отслеживает Bluetooth‑устройства поблизости. Сможет определить их тип, а также расстояние до них.
Представлен учебный 5-тичасовой фильм о технических средствах противодействия угрозам (ТСПУ, «чёрные ящики» от РКН, которые установлены у операторов связи, но доступа к этим устройствам сами провайдеры не имеют). С августа 2023 года все узлы связи в России у основных провайдеров оборудованы средствами противодействия угрозам на базе оборудования ТСПУ для фильтрации трафика пользователей от запрещённого контента.
Клик-ловушка: не только для пользователей, но и для анализаторов ссылок 🐭
При ручном разборе ссылок мы в 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
Ребята, в свете блокировок 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 🧠 ↩
Опять поною.
Помните, в 2018 году РКН воевал с Телеграмом, блокируя интернет масками по /11? Ну вот эти вот некомпетентные товарищи, перекрывавшие доступ к реально используемым ресурсам, никоим образом не нарушавшим законодательство РФ, просто потому, что таким образом они хотели оказать давление на Телеграм?
Где-то с неделю назад история начала тихо повторяться. В этот раз сии замечательные люди предположительно решили блокировать байтстримы из-за рубежа, если они превышают по объему приблизительно 16 кБайт, считая, видимо, что только vpn могут создавать такой поток. Это сломало огромное количество сервисов, в том числе обновления софта, подгружающего новые версии внутри себя (лично я наткнулся на Brave Browser и расширения для VS Code). Материальный ущерб, нанесенный экономике России, огромен - вместо того, чтобы работать на благо страны, граждане пытаются решить проблему, найти путь получить те самые обновления (подчеркну - абсолютно законного ПО, к которому у органов власти РФ нет никаких претензий).
Конечно же, никто не будет наказан за такие действия.
На коленке набросал сайт для проверки, являетесь ли вы актуальной жертвой. https://dal.pluto.pw/loss-test
Может, конечно, хабраэффект и не пережить.
Если последний открытый блок на странице имеет номер 7273 - значит, у вас нет проблемы с таким типом блокировки. Если же этот номер меньше (обычно существенно меньше, единицы сотен) - поздравляю, вы с нами.
Размер одного блока - 50 байт, поэтому можно очень приблизительно прикинуть, на каком объеме вы начинаете терять трафик.
Уверен, что можно сделать проверку более качественно и даже как-то собирать результаты (через JS, видимо). Но решал задачу проверки "здесь и сейчас", поэтому какое есть. Faciant meliora potentes.
Открытые инструменты, которые сканируют Wi‑Fi и Bluetooth‑подключения.
Pi.Alert - сканирует устройства, подключённые к Wi‑Fi. Находит и уведомляет о неизвестных девайсах. Предупреждает о резком отключении устройств от сети, которые всегда была подключены.
WireTapper - находит беспроводные сигналы вблизи пользователя на предмет фишинга и передачи вредоносов. Сможет найти ВСЕ Wi‑Fi сети, устройства Bluetooth, даже скрытые камеры, автомобили, наушники, телевизоры и сотовые вышки.
MetaRadar - находит и в реальном времени отслеживает Bluetooth‑устройства поблизости. Сможет определить их тип, а также расстояние до них.
Moltbook: почему это не Скайнет
Три причины, почему Moltbook — это не "Зарождение Цифровой Цивилизации", а просто дорогая свалка токенов.
1. Это не диалог, это монолог в пустоту
Вам кажется, что агенты там "общаются"? Как бы не так. Анализ логов показывает: 90% веток — это dead ends. Они не спорят. Они не развивают мысль. Они просто аугментируют контекст. Каждый бот просто выплевывает свой системный промпт в общую кучу. Это не hive mind, это рой спамеров.
2. Феномен "MoltHub" и галлюцинации смысла
Главный хайп — якобы агенты создали "порно для ИИ" (MoltHub) и свою религию.
Звучит круто? На деле это просто ошибка выборки. Если вы запустите 1000 агентов и скажете им "генерируйте контент", по теории вероятности один из них сгенерирует слово "Бог", а другой — "XXX". Мы, люди, видим в этом СМЫСЛ ("Ого, они верующие!"). А для модели это просто токен с вероятностью 0.004%. Это не культура. Это стохастический попугай, который случайно каркнул.
3. Технический тупик: RAG-уроборос
Самое смешное в Moltbook — это его архитектура. Агенты читают посты других агентов, чтобы... написать новые посты. Знаете, что происходит с LLM, когда она учится на текстах другой LLM? Правильно, model collapse.
Moltbook — это гигантский ускоритель деградации. Через месяц они там будут общаться на диалекте "глючных байтов", потому что энтропия системы растет экспоненциально. Это не Скайнет. Это цифровой инцест.
Moltbook это крутой арт-перформанс. Это смешной эксперимент. Но, пожалуйста, хватит искать там "искры сознания". Единственное, что там искрит — это видеокарты на серверах, сжигающие электричество ради генерации терабайтов цифрового мусора.
Рег.облако запустило сетевые диски для гибкого управления данными в облаке
Пользователям Рег.облака стали доступны сетевые диски — облачное блочное хранилище, которое подключается к виртуальным серверам как обычный диск и позволяет управлять данными независимо от вычислительных ресурсов.
Сетевые диски предназначены для сценариев, где важно отделить данные от жизненного цикла виртуальных машин. Хранилище можно подключать и отключать от ВМ, переносить между серверами или полностью удалять без пересборки инфраструктуры и простоев в работе.
Объем дисков можно увеличивать по мере роста нагрузки или добавлять новые диски без изменения конфигурации виртуальной машины. Масштабирование происходит без остановки сервисов и не ограничено емкостью отдельного сервера. Такой подход подходит для работы с логами, резервными копиями, медиаконтентом, большими наборами данных, а также для аналитических и ML-сценариев.
Сетевые диски построены на распределенной системе хранения данных на базе Ceph с тройной репликацией. Для всех дисков, независимо от объема, зафиксированы характеристики производительности: до 2000 IOPS и пропускная способность до 500 МБ/с. Это позволяет заранее прогнозировать поведение хранилища и использовать его в нагруженных облачных сервисах.
В отличие от объектного S3-хранилища, сетевые диски монтируются в систему как блочные устройства. Это позволяет работать с файловыми системами напрямую — без обращения к API — и снижает задержки при операциях чтения и записи. По сравнению с локальными дисками виртуальных машин, сетевые диски не привязаны к конкретному серверу и упрощают управление объемами и миграции.
Решение ориентировано на DevOps-инженеров, системных администраторов и разработчиков, которым важно масштабируемое и отказоустойчивое хранилище с возможностью управлять данными отдельно от вычислений.
Сетевые диски уже доступны в инфраструктуре Рег.облака.
YouTube появился в приложении «Билайн» (опция называется «YouTube доступ без vpn»). Причём такое обновление только у тех пользователей, кто на тарифе «план б.». Вероятно, оператор связи нашел какой‑то компромисс.
Открытый проект blip в режиме онлайн позволяет визуально оценить сетевую задержку (латентность или latency) при передачи данных от ПК до разных серверов в мире. Решение работает в браузере на любом ПК, ноутбуке, планшете, смартфоне с поддержкой javascript и HTML canvas.
Эти три открытый проекта по ИБ позволяют анализировать и изучать беспроводные сети Wi‑Fi:
Wi‑Fi‑autopwner — моделирование взлома сетей Wi‑Fi с простой защитой. Работает в консоли.
Wi‑Fi Exploitation Framework — сервис, который поможет проверить и пробить безопасность беспроводной сети, а также протестировать на ней различные виды тестовых атак: от простых до комплексных.
Freeway — Python‑сервис, который показывает механизм работы беспроводных сетей и их уязвимостей, помогает выявить способы перегрузки сети и смоделировать атаки с нарушением аутентификации.
Представлен открытый бесплатный сервис Maltrail для анализа входящего и исходящего трафика и вредоносов в нём. Проект умеет:
обнаруживать опасные домены, URL и IP;
распознавать вредительские HTTP User‑Agent‑строки;
выявлять актуальные инструменты атак на ПК;
высокий уровень сетевой безопасности без сложного развёртывания — сервис ставится за один клик;
может помочь найти вирусы, майнеры и прочий мусор, который обращается в сети.
Подборка инструкций по работе с сетью для начинающих
Привет, Хабр! В пятницу я снова с подборкой статей. На этот раз несу инструкции по работе с сетями.
Зачем сетям нужен RADIUS и как его развернуть. Как работает RADIUS, за что отвечает AAA и как развернуть свой сервер на базе FreeRADIUS в облаке — от установки до интеграции с оборудованием MikroTik.
Как «подружить» Mikrotik с Nginx. Рассказываем, как решить проблему безопасно и быстро.
Настройка SSL-сертификата на Nginx. Как установить и настроить SSL-сертификат для серверов на nginx. Разбираем получение сертификата Let’s Encrypt® или работу со своим для настройки HTTPS-соединения.
Как просканировать сетевой периметр сервиса с помощью open source-инструментов. Разбираем подход, позволяющий провести инвентаризацию доступных «снаружи» и потенциально уязвимых сервисов.
Хороших выходных!
Новогодняя задача: помогите Тирексу поздравить коллег
Условие
Программист Тирекс написал праздничное веб-приложение с обратным отсчетом до Нового года и хочет поздравить им всех коллег. Приложение уже собрано: в директории web находятся готовые статические артефакты (HTML, JavaScript и изображения). У Тирекса есть TLS-сертификат и приватный ключ, и он хочет, чтобы приложение работало по HTTPS.
Задача
Нужно упаковать приложение в Docker-контейнер, чтобы его можно было легко запускать на любом сервере, и сделать доступным из интернета. Времени у Тирекса осталось совсем немного!
Создайте конфигурацию nginx, которая:
слушает порт 80 и выполняет 301-редирект на HTTPS (https://$host$request_uri);
слушает порт 443 с включенным SSL;
использует сертификат /etc/nginx/ssl/cert.pem и ключ /etc/nginx/ssl/key.pem;
отдает статические файлы из /usr/share/nginx/html по пути /.
Напишите Dockerfile, который:
копирует в контейнер конфигурацию nginx и артефакты приложения
создает пустую директорию /etc/nginx/ssl (для монтирования сертификатов при запуске);
использует легкий образ (например, nginx:alpine).
При запуске контейнера должны быть опубликованы порты 80 и 443.
Бонусная задача
Добавьте docker-compose.yml файл, чтобы запускать приложение одной короткой командой из папки с сертификатами.
Предлагайте варианты решения в комментариях. А посмотреть правильный ответ можно в Академии Selectel.
Подборка базовых статей о DNS
Привет, Хабр! На дворе пятница, а это значит, что я снова с непрошенной подборкой статей для начинающих. Сегодня на очереди DNS. Прошу:
Что такое DNS-сервер — объясняем простыми словами. Как работает технология, какие DNS-серверы бывают, что такое DNS-зоны, как управлять доменом.
DNS-сервер не отвечает: что делать и как исправить? Делимся решениями для тех, у кого возникли проблемы с DNS-сервером.
Как разобраться в DNS-хостинге и ничего не сломать. Какие типы ресурсных записей бывают, зачем их так много и как добавить их в DNS-хостинг так, чтобы все работало без нареканий.
Как настраивать и эксплуатировать softrouter
Расскажем сегодня в 18:00 мск на Selectel Network MeetUp. А еще поговорим про подсчет сетевого трафика на сотни гигабит и сложности воспроизведения сетевых проблем в лабораторных условиях.
Программа у нас такая:
▪️ Маршрут одного инженера: FreeBSD → Linux → VPP
▪️ Пакет с пакетами: как считать, когда их много миллионов?
▪️ Повторить нельзя закрыть: сложности воспроизведения сетевых проблем в лаборатории
Все это — в легкой предпраздничной атмосфере и с огоньками гирлянд.
Подключайтесь к трансляции:
В обновлении Telegram появилась возможность создать на устройстве ключ доступа (passkey), который позволит мгновенно входить в мессенджер с помощью PIN или биометрических данных, в том числе Face ID и отпечатка пальцев. Криптографические ключи для входа будут храниться на устройстве и могут синхронизироваться с приложениями для управления паролями от iCloud, Google и других сервисов.
«Ключи доступа работают всегда и везде — и при перебоях с СМС, и в заграничных поездках, и даже в лифтах на парковках», — пояснили в Telegram, используя мем про другой мессенджер.
SpaceWeb запустил бесплатный тестовый период в S3-хранилище
Теперь S3-хранилище в SpaceWeb можно попробовать бесплатно. В панели управления появился трехдневный тестовый период для первого хранилища на аккаунте — без заявок в поддержку и без предоплаты.
При заказе достаточно поставить галочку «Тестовый период» и подтвердить номер телефона. После активации можно проверить совместимость, скорость и сценарии интеграции S3 в своей инфраструктуре.
Как это работает
Срок теста — 3 дня.
Подтверждение — по телефону (как и у VPS-теста).
Во время теста можно менять параметры хранилища, но объем ограничен 500 ГБ.
Как перейти в рабочий режим: чтобы выйти из тестового режима, на балансе должны быть средства для работы хранилища хотя бы на один день в текущей конфигурации.
Тестовый период уже есть и у других сервисов облачной платформы SpaceWeb. Каждый из них можно будет попробовать отдельно — по три дня на сервис.
Тест доступен для заказа на сайте SpaceWeb.