Мне было интересно узнать, какие байты бегают по моей домашней сети. Я не нашёл простого инструмента, который можно было бы собрать за вечер и понять от начала до конца — и пришлось написать свой, на C.
Получилось ~500 строк кода, 95.6% распознавания протоколов и отличная возможность разобраться, как работает Deep Packet Inspection изнутри.
Без фреймворков, без зависимостей — только C, libpcap и алгоритм Ахо‑Корасик.
Пока идёт бинарный апгрейд nginx, systemctl reload nginx не применяет конфиг так, как вы думаете: в лучшем случае к половине процессов сервера, в худшем — вообще никуда. Код возврата ноль в обоих случаях, в error.log пусто. Что именно у вас — решает одна строчка в юните: -s reload бьёт по pid-файлу, а он после USR2 принадлежит новому мастеру; kill -s HUP $MAINPID бьёт по старому, а тот конфиг вообще не перечитывает, и это описано в документации nginx — в разделе про обновление исполняемого файла, куда по другому поводу не заходят.
Это первая из пяти проверок. Я взял пять ходовых утверждений про reload в nginx, померил каждое на стенде — и получил результаты по обе стороны: три подтвердились, два развалились. Развалившиеся оказались интереснее.
Не работают ровно те страшилки, что про слушающий сокет: listen ... reuseport бесшовность не ломает (inode’ы сокетов до и после reload одни и те же — их держит мастер, а не воркер), паузы в accept при reload не существует вовсе (msleep(100) стоит ПЕРЕД QUIT), а значит и арифметика про переполнение backlog на reload — про нагрузку, а не про reload.
Зато подтвердилось то, о чём почти не пишут. keepalive_min_timeout оставляет уходящего воркера в живых, и тот обслуживает запросы, которых в момент reload ещё не существовало — по старому конфигу. А ngx_close_idle_connections не различает направление соединения, поэтому каждый reload сбрасывает пул keepalive к бэкендам — и с 1.29.7 это касается всех, у кого есть блок upstream: пул там включён по умолчанию, 32 соединения на воркер.
Правило из первой части — «соединение, открытое до reload, нового конфига не увидит» — приходится переформулировать: держится старого конфига не соединение, а процесс.
В конце — Traefik, у которого reload’а нет вовсе, и который умеет не применить конфиг своим способом: кольцевой буфер на одно сообщение и двухсекундный дроссель.
nginx release-1.31.3, traefik v3.7.10, все опыты в репозитории, запуск одной командой.
Медные коммуникации дороги в обслуживании и энергозатратны — а в некоторых странах еще и регулярно становятся добычей охотников за металлом. Неудивительно, что телекомы массово переходят на оптоволокно: старую медь можно выгодно продать, а в бывших телефонных станциях устроить ЦОДы. На словах их поддерживают и руководства стран, но на деле не все так гладко: например, американскому AT&T отказаться от медных сетей в Калифорнии попросту не разрешили — дело дошло уже до суда. Посмотрим, что происходит с медной инфраструктурой в мире и при чем тут «поставщики последней инстанции».
В настройках Chrome появился переключатель «ИИ на устройстве». Он относится к моделям, которые запускаются прямо на компьютере, причем, для целей довольно разнообразных (в частности, даже для обнаружения мошеннических сайтов). В каталоге профиля браузера при этом действительно лежат несколько гигабайт весов Gemini Nano. Хочется сказать: раз модель уже скачана, то встроенный Gemini должен работать локально - например, читать и пересказывать открытую страницу без обращения в облако!
Увы, для Google это оказалось не самым логичным решением. Более того, они даже с неймингом не справились до конца, чем здорово всех запутали.
Под словом Gemini у компании скрываются две принципиально разные системы.
Ask Gemini / Gemini in Chrome — облачный сервис. Когда вы просите его пересказать страницу или ответить на вопрос по открытым вкладкам, их содержимое передаётся в инфраструктуру Google.
Gemini Nano — локальная модель. Chrome скачивает её на компьютер и запускает на CPU или GPU. Отдельной кнопки «спросить Gemini Nano» у пользователя нет. Этой моделью пользуются сайты и расширения через специальные API Chrome, а также сам браузер — например, при первичной проверке подозрительных страниц.
Представим что у вас есть свой сайт запущенный на VPS на голом HTTP, также вы уже купили домен и связали его со своим IP-адресом.
Но спустя время вы решили, что не хотите, чтоб весь трафик между клиентами и сервером был виден любому желающему.
Вспомнили, что есть протокол HTTPS, который по сути обычный HTTP, но на 5 и 6 уровне работает протокол SSL/TLS, который занимается шифрованием и аутентификацией.
Дело осталось за малым, перевести сайт с HTTP на HTTPS.
Привет, Хабр. Статья является напоминанием как уязвимы ваши личные данные при несоблюдении базовых правил цифровой гигиены. Материал создан исключительно в учебных целях, для специалистов по информационной безопасности и для пользователей, которые хотят более углубленно понимать, как защитить свои данные от утечек. Использование данных методов против других лиц без согласия — уголовно наказуемо (ст. 272 УК РФ).
Речь пойдет о том, что происходит, когда вы переходите по ссылке, минуя предупреждения браузера о "Небезопасном соединения", или устанавливаете в систему корневые сертификаты, полученные из сомнительных источников.
Последние пару лет я работаю в команде, которая занимается устойчивой к DPI (Deep Packet Inspection) туннельной инфраструктурой — по сути, альтернативой классическому VPN.
Когда начинаешь заниматься этим всерьёз, довольно быстро обнаруживается неприятная вещь: шифрование само по себе давно уже не означает, что трафик нельзя распознать. Содержимое пакетов действительно можно скрыть, но пакет от этого не исчезает. У него остаются размер, направление, время появления; соединение начинается с определённой последовательности сообщений, TLS-клиент определённым образом представляется серверу, поток ускоряется, замедляется, замирает и снова начинает передавать данные.
Для человека всё это выглядит как куча зашифрованных байтов. Для классификатора — как вполне пригодный набор признаков.
Поэтому значительная часть нашей работы в итоге свелась не к тому, чтобы «зашифровать ещё сильнее», а к более практическому вопросу: что именно видит наблюдатель снаружи и по каким признакам он может решить, что перед ним не браузерный трафик, а туннель.
Об этом и расскажу.
Меня зовут Артур Валиев. Я открыл исходники EvertyDesk Lite — и заодно EvertyDesk Next, то, что должно было стать следующей версией. Полностью. Без купюр.
Возможно тема эта избитая и многократно разжёванная в том числе и на Хабре. Но тем не менее актуальная, и кому-то может оказаться полезным краткий обзор.
Исторически так сложилось, что сертификаты для подтверждения подлинности веб-сайтов при шифровании были выстроены в иерархическую структуру.
Имеется корневой супер-надёжно охраняемый сертификат (а точнее его секретный ключ), хранящийся в изолированном от глобального Интернета контуре, за 5-ю заборами с колючей проволокой, с бронированными дверями и конечно надёжно зашифрованный и расшифровывающийся комбинацией из нескольких ключей, независимо хранящихся у разных людей - гарантов его секретности (это реализуется, например, схемой Шамира).
Далее корневым сертификатом подписывается (заверяется) менее, но всё ещё очень надёжный промежуточный сертификат, или несколько таких. От которых в свою очередь цепочка доверия распространяется на промежуточные сертификаты следующего уровня или уже на оконечные (листьевые) сертификаты, которые используются собственно сайтами и веб-порталами для шифрования трафика. Конкретно сертификат используется с целью подтверждения, что содержимое вам отдаёт именно удостоверенная сторона, именно тот сайт, адрес которого вы набирали в строке адреса в браузере, а не какой-то шпион или кракер.
И тут весь вопрос в том, кому вы доверяете.
Описанные выше корневые сертификаты с их поддеревьями заверенных иерархий образуют своеобразный лес: от каждого корня - отдельное дерево.
Стандартно браузеры либо используют свой список доверенных корневых сертификатов, либо пользуются средствами среды, то есть операционной системы (будь то Windows, iOS или Android). Как правило этот список можно дополнить или заменить на свой собственный. Например, можно выписать свой персональный (или корпоративный) сертификат, и только его оставить в списке. Это на случай, если вы доверяете только себе самому. При этом вы сами (или ваша организация) храните в тайне его секретный ключ, которым осуществляется подпись других сертификатов. И вы лично отвечаете тогда за безопасность.
Деплой делает nginx -s reload. Команда возвращает ноль, nginx -T показывает новый конфиг, в error.log ровно одна строка — reconfiguring. А keep-alive соединение, открытое секундой раньше, в этот момент закрывается.
Само по себе это не ошибка: сервер вправе закрыть простаивающий keep-alive когда угодно. Ошибку даёт гонка — FIN уходит в тот момент, когда клиент уже записал в сокет следующий запрос. Идемпотентный он повторит, POST — нет.
Разбор по исходникам на фиксированных тегах: nginx release-1.31.3, httpd 2.4.68, traefik v3.7.10, плюс замер всех четырёх (с HAProxy) на одном стенде в одном прогоне. Выясняется, что мастер nginx конфиг не перечитывает вообще: он строит новый цикл целиком и форкает новых воркеров, а старым остаётся ровно то, что у них было. Apache приходит к тому же контракту через счётчик поколений, HAProxy — через замену процесса. А у одного из четырёх второй запрос в том же самом сокете возвращает уже новый конфиг — и причина не та, о которой вы подумали.
Внутри: почему документация nginx сама создаёт половину недоразумения; почему WebSocket и SSE не попадают под ngx_close_idle_connections и держат старого воркера сколько угодно долго, а HTTP/2 попадает всегда и получает GOAWAY; как сигнал родителя у Apache доезжает до конкретного соединения через пять звеньев; и таблица из двенадцати клеток, в которой четыре реализации расходятся ровно в одной.
Со стендом (один docker build, один docker run), полными выводами ps и тремя claims-*.tsv, где каждое утверждение о коде проверяется скриптом.
Пока я собирал материал для этой статьи, мне казалось, что логика будет простой: без VPN сайт видит мой обычный IP, с VPN — адрес сервера выхода; cookies при этом никуда не деваются. На практике даже такой маленький эксперимент сразу подкинул вопросы. В DevTools при подключении через VPN на странице Хабра появился ещё один домен с Google-cookies. Значит ли это, что VPN начал собирать обо мне больше данных? Нет. Он меняет маршрут и IP, а сайт, рекламная сеть или аналитика могут из-за нового адреса отдать браузеру другую конфигурацию страницы.
С интернет-приватностью постоянно происходит то же самое. Фраза «провайдер всё видит» смешивает в одну кучу название сайта, содержимое страницы, IP-адрес и личность пользователя. А совет «включи VPN» часто звучит так, будто после этого исчезнут авторизация, cookies и браузерный отпечаток. Они не исчезают.
В статье я пройду путь одного запроса от адресной строки до сервера и обратно. Разберу, какие данные в этот момент остаются у браузера, что видят DNS-резолвер и провайдер, что получает сам сайт и какую новую роль берёт на себя VPN-сервис. Заодно покажу, почему HTTPS скрывает далеко не всё, а смена IP ещё не означает анонимность.
Гигабитный канал может быть загружен лишь наполовину, а пинг под нагрузкой всё равно взлетает до сотен миллисекунд.
Разбираемся, где копятся очереди, как распознать bufferbloat и какие механизмы действительно удерживают задержку под контролем.
Привет, Хабр! Как и обещали — вторая часть истории про то, как мы строим InfoWatch ARMA Стена (NGFW) в текущих реалиях. Первая часть — тут.
Сегодня про:
- ИИ и нейросети
- миграцию
- отечественное железо
- почему NGFW, а не data diode
- цены и пилотирование
ИИ сейчас почти из каждого утюга. Как у вас с этим дела в продукте?
С точки зрения технологий мы не отдаем обработку данных в облако или стороннему агенту — большинство заказчиков против подобного, а их политики безопасности вообще часто прямо запрещают подобную обработку, особенно при прохождении ПМИ и испытаний. Внутри системы мы агентов тоже не разворачиваем.
Да, для отдельных команд есть специальные службы и агенты, помогающие настроить предварительные сценарии эксплуатации и ускорить некоторые процессы — в основном исследовательские: поиск уязвимостей, описание уникальных конфигураций, способных вывести систему в аварийный режим, и подобное. Важно всегда помнить, что нейронка — это лишь инструмент помощи специалисту. Конечное решение всегда принимает человек — инженер, который и отвечает за конкретную ветку продукта.
Мы используем и собственные модели для обучения системы новым фидам. Когда появляются новые эксплойты, время реакции нашей команды безопасности заметно быстрее, чем у большинства игроков рынка. Наш приоритет тут — надежность и стабильность, а значит, в первую очередь безопасность. NGFW для нас — сначала инструмент безопасности, и только потом — инструмент сетевой связанности.
В первой статье я говорил, что безопасность — это свойство архитектуры, а во второй разложил по полочкам способы построить logical air gap. Теперь самое главное: «А зачем вообще это всё? У нас есть firewall, WAF, TLS и патч-менеджмент».
Привет, это Данил Киселев, сетевой инженер в Yandex Infrastructure. Представьте себе, что у вас не просто офис, а очень большой офис с тысячами пользователей, которые ходят с созвона на созвон, перемещаясь между переговорками. Разумеется, им хочется оставаться на связи в процессе и не думать о ближайших точках доступа к Wi‑Fi. Для сетевого инженера это не выглядит проблемой на небольших масштабах. Но что если скоро ваш офис вырастет и таких точек доступа в сетевой фабрике может стать уже 20 000 и больше?
В статье расскажу про опыт использования технологии VxLAN в корпоративных сетях Яндекса. В частности речь пойдёт про построение Wi‑Fi поверх VxLAN‑туннелей, которые таким образом смогли помочь нам с большим доменом и заодно избежать широковещательного шторма.
Поднял сервер за границей, всё летает - а потом маркетплейс просит капчу, банк отказывает в операции, сайт объявлений не открывается. Совет один: сделай обратный впн. Рецептов несколько, и работают они по-разному.
Собрал их у себя и посмотрел не на описания, а на то, что о вашем адресе видно снаружи. «Российский IP» оказался не одним свойством, а тремя, и закрывает все три только один вариант из четырёх.
Мы делаем RCQ, мессенджер со сквозным шифрованием и открытым кодом (Android, iOS, протокол). В нашем основном регионе приложение блокируют, поэтому обход встроен внутрь клиента: sing-box в самом приложении, пул релеев, подписанный конфиг с их списком, запасной путь через CDN.
Всё это писалось месяцами и ни разу не измерялось. Мы знали, что механизмы есть, а срабатывают ли они хоть когда-нибудь и в каком проценте случаев, никто из нас сказать не мог, потому что спрашивать было не у чего.
В начале августа ушло двое суток на приборы. Ни одной новой функции, только измерение уже написанного. Нашлось восемь мест одной и той же формы: механизм построен, задеплоен, в него верят, а в продакшене он либо не выполнялся ни разу, либо выполнялся не так, как все были уверены.
Дальше про приборы. Обход блокировок тут просто предметная область, приёмы работают на любом коде, который включается редко и по чужому расписанию: ретраи, фолбэки, аварийные переключения, резервные каналы доставки.
В прошлой статье было рассказано как “в три промпта” был получен shell для свитча SNR-2990X-24FQ (OEM DCN), в этой статье будет рассказано о более сложном реверс-инжиниринге свитча одного из топ-вендоров в мире сетевого оборудования.
Некоторое время назад мне пришла задача спроектировать высокопроизводительный балансировщик нагрузки для протокола Diameter. Через 3 месяца задача исчезла, так как как оказалось слишком долго и дорого, но в итоге балансировщик был сделан и имеется его MVP которое готово к установке как на реальное железо так и в облаке. В итоге продукт получился неплохим, и он с лихвой выигрывал имееющееся решение в той компании, по производительности был выигрыш раз в 6 по ресурсам раз в 100. Но суть не в этом, а в том что балансировщик был кластерным и умел хранить сессии в Redis. Решение было сделано, оно показало работоспособность, все хорошо, но меня не устраивала производительность. В тот момент я столкнулся с очень интересной проблемой - по каким то причинам я не мог пробить барьер в 5-7К Diameter Transactions per second. В принципе 5-7К TPS было неплохо, но проблемным участком как показал анализ был Redis. Проведя немного времени я смог добиться приемлемого результать и производительность поднялась до 20К TPS но там были другие проблемы.
Привет. Это снова Саша Басун. Я работаю в «Петрович-Тех» инженером направления пользовательских ИТ-сервисов. Моя предыдущая статья про FortiClient VPN нашла отклик, потому я решил рассказать о самых распространённых ошибках при установке или запуске FortiClient VPN.
Итак, обычный будний день. Админу приходит заявка от пользователя, который жалуется, что FortiClient не подключается к серверу. При этом шквала подобных заявок не наблюдается, из-за чего админ делает вывод, что проблема у пользователя локальная.
Он подключается на удалённый компьютер, чтобы провести диагностику. Открыв логи программы, админ понимает, что помимо бутылки тут может потребоваться ещё и тонометр. Всплывающие окна с предупреждениями выглядят хотя бы немного понятнее. О них я вам и расскажу.
