Сами Камкар (Samy Kamkar), исследователь безопасности, известный созданием различных замысловатых устройств для проведения атак, таких как кейлоггер в USB-зарядке телефона, представил новую технику атаки "NAT slipstreaming". Атака позволяет при открытии страницы в браузере организовать соединение сервера атакующего с любым портом UDP или TCP на системе пользователя, находящейся за транслятором адресов. Инструментарий для проведения атаки опубликован на GitHub...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54058
>WebRTCОй, как неожиданно!
> если WebRTC отключен, через перебор адресов с измерением времени откликаДействительно, неожиданно
WebRTC всё упрощает в разы. Даже перебирать не надо. Но ты дальше давай сиди на дырявом стуле.
> дальше давай сиди на дырявом стуле.Кто о чем, как говорится :) Ну это, давай, поосторожней там.. а то уже главная суть статей на опеннете доходить перестает
Скорее javaScript. Ой как неожиданно!
> Атака может быть совершена независимо от используемого браузераКак неожиданно и приятно
Почему всегда костыли? Причём тут SIP? Почему только его? Почему 5060? А если у меня сервер на этом порту, то как мне зайти? Переходить на сафари?
Почему проблему в ALG решают в браузере?
Тут ошибка не в самом НАТе или АЛГ, тут ошибка в самом браузере, который запускает код, который может открывать порты и т.д. Может следует отключить джаваскрипт?
Код в браузере не открывает порты. Браузер лишь делает запросы - то что и должен делать. Это NAT доверяет любому коду в запросе и начинает пробрасывать порты изнаружи вовнутрь.
Давайте еще и в NAT обязательные сертификаты добавим, сгорел сарай гори и хата.
Браузер должен открывать страницы и их рендерить. И нечего пихать в браузер системные функции, вроде открытия портов и т.д. А так же выполнять недоверенный по умолчанию код и не надо будет потом в браузер подписать костылями в виде загрубления таймеров и т.д.
А как ему их рендерить если кода нет? опять упихаться в 5 стандартных тегов и заставлять юзера закликивать их, было такое да не взлетело.Что за непонятные догмы, браузер никому ничего не должен, он ровно такой каким его хотят видеть пользователи, захотят с удаленным управлением, значит так и будет, какой смысл об этом ныть, лучше иди расскажи какому нибудь хомячку, что современные браузеры байдизайн уязвимы, и что он должен отказаться от интернета теперь, ну это же просто глупо.
Это не пользователи хотят видеть такими браузеры, а разработчики.
html оброс раковыми опухолями со всех сторон.
жду не дождусь, когда волны упрощений докатится и до веба. и сделают какой-нибудь simple html без скриптов и прочих свистоперделок.
И даже не разработчики, а менеджеры корпораций. "Веб это платформа" и вот это всё.
пфф, вэб это среда и ей нужны свисторверделки, так же как этим вашим питонам рубям и прочему чем вы собираетесь си заменить, никто и никогда не придумает ничего универсальнее, этого просто нельзя, чтобы можно было попиксельно окна делать такиеже как в хп и чтобы безопасно.
Хоть кто-то на opennet понимает как все работает и почему.
Вам нужно полностью запретить браузеру открывать порты, чтобы спасти себя от уязвимостей и бэкдоров.
На редкость уникальный аноном)) 80 Да?? Ржу не могу
И 443. Если проблема вызвана тем что браузер умеет открывать порты, то ему нужно запретить открывать порты и проблема решится.
Вы же не будете отрицать что запрет открывать приведет к невозможности совершить указанную в новости атаку. И любую другу заодно.
Ух какие сложные вопросы у вас...> Почему всегда костыли?
По историческим причинам. Изначально протокол ipv4 не был спроектирован, чтобы выдержать такое количество устройств. Для решения задач адресации начался использовать NAT, и понеслось...
Что общего между стандартом/RFC описывающее трансляцию сетевых адресов для протокола ipv4 и розовыми единорогами? Правильно! Ни то ни другое не существует в объективной реальности =)
Даже в 2020-ом году мы имеем абсолютно несовместимую реализацию NAT между вендорами сетевого железа. Злодеи даже об именовании сущностей договориться не могут.Чаще всего роутер реализует файрвол так, что, условно, есть 2 зоны, внешняя и внутренняя. Если соединение было исходящее из внутренней зоны, то нужно записать IP-адреса:порты в табличку на определенное время и разрешать входящие соединения. Так работает домашнее барахло. Это минимальный вариант, а то NAT часто бывает симметричный или вводятся дополнительные ограничения по IP внешнего источника или по IP порту. Причем узнать как это у вас реально работает и что на самом делается с пакетами можно только из документации производителя.
Если же протокол на третьем уровне, у протокола несколько взаимосвязанных соединений или, что еще хуже, взаимосвязанные соединения более чем с двумя источниками (пиринговые сети), то NAT все ломает. Когда вендоры сделали аппаратные реализации NAT они обнаружили, что 1001 протокол не поддерживает их костыли. И вместо того чтобы прийти к стандарту они сделали еще большие костыль под названием ALG.
ALG - это когда косорылые бараны, сделавшие ваш роутер лезут в траффик, разбирают несколько типов протоколов, читают как минимум заголовки и делают какую-нибудь странную нестандартную ерунду часто недокументированную, которая по их мнению поможет вам по их идее пройти сквозь NAT (чаще всего нет).
Набор доступных ALG тоже у всех разных, но собаки включают их по умолчанию и убирать их не хотят.> Причём тут SIP? Почему только его? Почему 5060?
Ха. SIP ALG, пожалуй, единственный ALG, который предоставляют все вендоры без исключения.
SIP - это P2P-протокол установки сессий, применяют его обычно для мультимедиа, но так-то вообще любых. Он жестко стандартизирован, он большой и сложный, там много RFC. Настолько много что сетевики не могут столько прочитать. Суть протокола в том, что клиенты аутентифицировавшись на сервере могут инициировать соединение друг с другом напрямую, описать его, управлять им, пересоздать, изменить. 5060 TCP/UDP - это стандартный порт SIP, есть еще 5061 TCP для TLS. SIP имеет свои сессии, но существует для того чтобы создавать другие сессии. И SDP (протокол описания сессий) будет их описывать в рамках SIP. Чтобы создать вторую сессию с реальными данными, необходимо согласовать параметры подключения между клиентами. Не только IP-порты, но и кучу всего, потому что сессия бывает не только мультимедийная, но и на передачу файла или канальная обёртка траффика приложения, хоть RDP, вообще что угодно. Получается, что внутри заголовков SIP и в тексте SDP находятся IP/порты/протоколы, а не только как IP-заголовки. А еще набор портов для второй сессии у обоих клиентов случайный и одна сессия SIP может породить вторую сессию с переменным количеством соединений (занятых портов).Так вот. При использовании NAT заголовки IP-части пакета будут заменены файрволом, но внутри с точки зрения самого протокола IP будут данные от SIP. И вот оно будет не совпадать. IP-заголовки с SIP-заголовками и содержимым SDP.
В SIP есть 4 ключевых подхода по работе с NAT:
1. Расширения Symmetric Responce/RTP.
Описывает в заголовках дополнительно, откуда на самом деле шли пакеты. Некоторые клиенты и сервера можно настроить на принудительное использование rport, даже если о нем не было и речи. А некоторые можно даже вынудить заставить вторую сессию строить таким же образом. Проблема в том, что инфраструктура в общем случае должна быть готова. Оно спасает от части сетевых выкрутасов, но не ото всех. Подходит в простых клиент-серверных сценариях.
2. STUN
STUN - это вспомогательный сервер с двумя белыми IP, на который можно натравить клиента и который сообщит ему, что наворотили у него на роутере. Он позволяет удерживать временные пробосы портов, проверяет типы NAT, и сообщает клиенту всё что может, чтобы установить все сессии. Проблема в том, что если роутеры двух клиентов имеют симметричный NAT, то соединить их нельзя.
3. TURN - Решение проблемы, которую недорешал STUN.
Если 2 клиента имеют симметричный NAT, то можно соединить их обоих с белым TURN который примет данные от первого клиента и передаст второму клиенту. Если же клиенты математически далеки от TURN, то можно построить медиапроксикластер и прокинуть вторую сессию через несколько взаимосвязанных TURN. Недостатки: дорого, медленно.
4. ICE - Протокол, который собирает кандидатов на установку сессий внутрь SDP.
Если взять все возможные способы пройти NAT, начиная от STUN, TURN и заканчивая богомерзким UPnP, посмотреть на все сетевые адаптеры клиента и собрать пары IP:порт не забывая про ipv6, опубликовать их и еще и перепробовать, то тогда-то точно клиенты соединятся, причем надёжнее чем через полное проксирование потока в TURN.Современный стандарт предполагает использовать ICE. Собственно WebRTC (это все около-SIP-протоколы, только без самой сигнализации SIP) его и использует, поэтому у вас локальный IP видно. ICE нашел всевозможных кандидатов. ICE решает все проблемы (хоть он и толстоват и сложен).
А что делают вендоры железа. А им не нужны билеты на самолёт, когда есть проездной на трамвай. Они предполагают, что вместо применения стандарта нужно:
1. Отключить шифрование TLS/DTLS по-возможности
2. Проинспектировать пакеты
3. Заменить содержимое под то, как это видит вендор, пытаясь обмануть приложение-клиент.
Факт в том, что при одновременном использовании Symmetric Responce/RTP на прокси сервере и ICE на всех клиентах при наличии собственного STUN+TURN никто без DPI не может заблокировать сессию. NAT вообще не проблема. Но если у вас Cisco ASA/ASR вместо файрвола/роутера, и вы всю инфраструктуру строите на стандартных 5060,5061 то она как раз вам включит свою ALG и сломает обход NAT-а в рьяной попытке помочь. А TP-Link не сломает. А Mikrotik сломает только медиапотоки и только раз в час. А D-Link один из немногих, кто держит ALG выключенным.> Почему проблему в ALG решают в браузере?
Еще раз. Разработчики сетевого железа решили, что они лучше знают как устроены все возможные клиенты и какие бывают юзкейсы для SIP и они сделают лучше, чем английским по белому написанные и официально принятые стандарты IETF. Злодеи не просто не хотят удалить SIP ALG, они включают его всем принудительно по-дефолту. Переписывать ALG под современные стандарты тем более не хотят. Вы что думаете, они почему на ipv6 переходить не могут? Потому что не хотят. Вот и решают проблемы через браузер. Зайдите к себе на роутер и отключите всё ALG, которым не пользуетесь.
Я когда писал этот комментарий хотел как-то поверхностно, не сильно углубляясь в технические детали описать проблематику и посмотрите что вышло... Как людям объяснить что не "WebRTC палит ваш локальный IP", а ICE работает именно так как и должен и это не страшно? У них паранойя от неграмотности.
Как объяснить сетевикам хоть что-то выше уровнем чем VLAN/VXLAN? Они стандарты читать не умеют.> Переходить на сафари?
Это решение. Поезжайте в Африку, посмотрите природу, поохотьтесь, отдохните от компа. =)
Спасибо за ликбез. Прочитал с интересом.
Ещё пара таких комментов, и я смогу сдать CCIE, как минимум
Я думаю дело не просто в том, что не хотят, а в том, что это реально сложно, особенно для бытовых железок с ограниченной памятью и железом.
И опять таки встаёт вопрос совместимости с обратной стороны софта, который уже вероятно ожидает конкретную реализацию ната.
Ну и не только в НАТе дело, попробуйте такого монстра протокольного банально разрешить или запретить в фаерволле.
бгага, лол какой == у меня внутренняя сетка 1.0.0.0/24согласен - не правильно. но, как оказалось, я не подвержен данной атаке.)
Бугага, теперь тебе не доступны сервисы из CDN cloudflare
Идея, использую-ка я у себя в локалке адреса Netflix'а.
Это не защищает от атаки, просто атакующему нужно будет цзнать твою сетку заранее
Адреса гугла надо пользовать, чтоб ютуб не показывал.
да ты чЁ, правда? вот это да)
>зная параметры фрагментацииВ BSD есть scrub, а что делать в линуксе?
ЧЁРНЫЙ список
587, // smtp (outgoing)
601, // syslog-conn
636, // ldap+ssl
993, // imap+ssl
995, // pop3+ssl
2049, // nfs
3659, // apple-sasl
4045, // lockd
+ 5060, // sip
+ 5061, // sips
6000, // x11
6665, // irc (alternate)
6666, // irc (alternate)
6667, // irc (default)
6668, // irc (alternate)
6669, // irc (alternate)
6697, // irc+tls
Эй гугл, мозилла! Я у себя разместил сервис SIP на 80 и 443 порту. Заблокируйте их пожалуйста в своих браузерах немедленно!!!!!
мне тоже это понравилось. Надеюсь, в коммит пойдёт с комментерием HACK )
Эй, аноним! Ваш SIP-сервис на нестандартных портах не представляет никакой опасности, поскольку модуль ядра nf_nat_sip, используемый в данной атаке, не смотрит на пакеты на этих портах. Поэтому основания для блокировки указанных портов в браузерах нет.
Закрытие, жесткая привязка и проброс портов - это хорошо, но не является панацеей от атак на дырявый линукс ... Делать постоянные рекавери диска и посматривать в директорию /usr/... дабы обнаружить там чужие программные файлы будет не лишним.
network.security.ports.banned
Давайте сразу добавим 443й порт как самый опасный . Сколько же через него вредоносов проходит, ужас просто !
"Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
Перестал читать
> Перестал читатьИ перестал пользоваться интернетиком?
И перестал писать комментарии.. Он теперь не может вам ответить.
> "Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
> Перестал читатьПредлагаю все новости начинать с предложения: "Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
Число неадекватов в комментариях должно резко сократится
Это вряд ли, скорее, наоборот!
аноним выше перестал читать,
но писать не перестал...
учитывая, что js обычно надо при посещении 702FAA-сервисов, можно сказать что пользователь сам запускает чужие программы (хоть на си, хоть на обфускрипте), альтернативы заботливо вытираются из памяти. неадекватна это как раз глобальная социопатия, а не, например, словарный перевод (овладение языком) вместо js cloud api.
RFC 2616
The default port is TCP 80 [19], but other ports can be used.
Своим фиксом они нарушают это. Все HTTP сервисы на нестандартных портах могут перестать работать после этого обновления. Но им плевать.
> RFC 2616
> The default port is TCP 80 [19], but other ports can be used.
> Своим фиксом они нарушают это.Нет.
> Secondly, RFC 2616 has been replaced by the RFC 7230 family of RFCs in 2014. These RFCs define how HTTP is implemented, not how a web browser is using HTTP. Outgoing HTTP requests for the purpose of a web browser are standardized in https://fetch.spec.whatwg.org/ which has a list of blocked ports for a very long while. This change is merely updating that list of disallowed ports. The standard has been fixed and other browsers are implementing this block as well.https://github.com/whatwg/fetch/issues/1108
> Все HTTP сервисы на нестандартных портах могут перестать работать после этого обновления.
Не могут. Достаточно не использовать порты из блеклиста.
Поправьте меня, но насколько я понял https://fetch.spec.whatwg.org/ описывает поведение fetch JS API а также политики загрузки картинок CSS и прочего. Но это не относится к самим HTML страницам.
Что касается "Не могут. Достаточно не использовать порты из блеклиста." Дело в том что достаточно не использовать уязвимые реализации NAT. А вот сайты на портах из блеклиста не уязвимы и порты менять никому не обязаны. Недефолтные порты популярны на разных админках, роутерах и т д. И вот однажды вы не сможете зайти на них потому что хром захотел решить проблемы SIPa c NATом.
Не понял необходимости хвостоманипуляции с HTTP-запросом. Далее говорится, что JavaScript-код генерирует корректный SIP-пакет, в котором указан внутренний IP жертвы, и отправляет его на TCP-порт 5060 сервера атакующего. А сразу нельзя послать пакет с компа жертвы на TCP-порт 5060 сервера, если уж отправка на этот порт явно не заблокирована в исходящей цепочке файервола?
Я так понял что из браузера можно послать только HTTP запрос. Браузер сам добавит заголовки, куки и т д. Поэтому делается большой запрос, который фрагментируется на два. Первая часть с этим мусором, а вторая начинается с SIP REGISTER на которую доверчивые NAT ALG и клюют.
Но вторая часть не будет иметь в заголовке установленного флага SYN. Поэтому принимающая сторона не будет воспринимать это как новое TCP-соединение и отбросит этот пакет, как не принадлежащий какому-либо сеансу.
Замотали изолентой и типа норм. Лол.
У них там уже 15 портов закрыты изолентой. Поэтому на 16-ый раз даже думать не стали, достали заготовленный рулон. Только я бы это не изолентой, а туалетной бумагой назвал. Ну или пищевой плёнкой.
Может, просто хватит уже считать, что NAT защищает от чего-то?
локалхост может эмулировать сеть любой сложности и глубины, а неуловимые джо за пачкой роутеров и связкой телефонов навряд читают провокации в комментах под блэком, ходящим по краю.
Может просто надо прочитать не только заголовок?
И то что NAT не защищает - расскажи ка Cisco ASA...
Ты баклажан. Cisco ASA делает не только NAT. NAT сам по себе даже у Cisco ни от чего не защищает.
Вообще-то вся защита в Cisco ASA - сделана именно на NAT. Есть трансляция - трифак проходит, нет трансляции - не проходит :)
Циска в Иран уже поставляла своё поделие...
workstation->airgap->fpg(General_Purpose_Device_With_Ability_To_Plug-In_ Removable_Drive_and_Siemens_Step_7_PLC-Programming_Software_?Win95/98?)->plc->ics
realtek/jmicron-devcerts, ms{spoolsv,rpc,smb}.
Циска только пушистая жертва, после того как дракон развернулся в ответ, или вы не про stuxnet?
https://www.schneier.com/blog/archives/2014/01/jetplow_nsa_e...
ага, нашёл, устанавливался только на целевые экземпляры, "случайно" попавшие в Иран? и прям так в видимости центрифуг?
> Циска в Иран уже поставляла своё поделие...Циски и в 2008 году отваливались "где нужно"...
>> Циска в Иран уже поставляла своё поделие...
> Циски и в 2008 году отваливались "где нужно"...И не только кошки... но это к делу отношения не имеет.
Проблема в косых NAT ALG - не нужно открывать канал только по фрагменту.
Пакетный фильтр разбирает пакеты по отдельности. Для него просто не существует чего-то более целого, чем "фрагменты".
Ну значит придётся учить.
Ну значит дыры надо пробивать не через отслеживание соединений, а через upnp явно.
Пакетный фильтр ты этому не научишь. То есть, если научишь, он уже перестанет быть пакетным фильтром. Ну и ресурсов станет жрать больше на несколько порядков, конечно же.
Нет, см conntrack
Да. Conntrack, грубо говоря, поворачивает ручку, ориентируясь на содержимое единственного пакета.
fwcmd="/sbin/ipfw"
${fwcmd} add reass all from any to any in
${fwcmd} add deny all from any to any frag
А в чем проблема, крутая фича же. Можно решить часть типичных нат-проблем без перехода на ipv6. Или кто-то все ещё думает, что нат, он для безопасности?
Cisco ASA знаешь? NAT однако... Как у большинства сетевых фаерволов
> А в чем проблема, крутая фича же. Можно решить часть типичных нат-проблем
> без перехода на ipv6. Или кто-то все ещё думает, что нат,
> он для безопасности?это не проход ната, инициируемый снаружи, для подключения, это очередной WebRTC - требуется действие, инициируемое изнутри ната
Очень теоретический вопрос. А если внутренняя сеть только по IPv6 шарашится?
> Очень теоретический вопрос. А если внутренняя сеть только по IPv6 шарашится?предполагаю, что дырявый нат так же откроет порт
сложнее будет только получить внутренний айпишник перебором
Эм, что-то я не понял. При чём тут SIP? И при чём тут данные? Я думал, что NAT пробрасывает соединения по заголовкам пакета, а не по данным...// А, понял, это как раз ALG так делают. Ну и изврат.
А я вот не до конца понял... Linux подвержен?Там не просто "содержимое пакета"! В iptables (conntrack) вообще-то есть "состояние": new, established, related и еще можно counters добавить, если не хватает.
Может нужно более корректные conntrack-обработчики протоколов написать? Или пофиксить проблему более жёсткими правилами iptables на стороне NAT?
Сам по себе нет, это работает только если на роутере стоит ALG - софт, который анализирует содержимое пакетов, смотрит, когда, скажем, FTP просит открыть входящий порт, и открывает ему этот порт автоматом сквозь NAT. Чтобы типа работали соединения FTP через NAT. То есть, по-видимому, чтобы работали FTP ACTIVE соединения, т.к. PASSIVE-то и так работают.А анализ получается смотрит на отдельные пакеты и поэтому уязвим к фрагментации.
Ну и аналогично видимо с SIP. В OpenWrt, например, как я понял, это реализовано через siproxd. Если такой или подобной хрени в роутере нет - то и дырки такой нет... По ссылке в статье у автора в каком-то нетгире это через какие-то модули ядра вообще работает.
Вот с ftp отличный пример. В том же nf_conntrack_ftp учтено, что PORT может оказаться между двух пакетов и еще много разных "состояний" пакета учтено - "будущие" (перепутанные) пакеты не сразу анализируются, соединения должны быть установлены и т.д. Внедрить PORT посреди HTTP-пакета (в какие-нибудь заголовки) вполне можно и conntrack на это вполне может среагировать, ждать "начала пакета" не нужно...А здесь... - либо определение MSS в уязвимости надо нафиг выкинуть, либо поправить реализацию CONFIG_NF_CONNTRACK_SIP в ядре... либо я чего-то не понимаю (или очень замороченный этот протокол SIP, да еще и поверх TCP).
Приехали, statefull файерволы обманывают. Возвращаемся на stateless - NO TRACK!!!
Ну что где там то махровое профрепригодное ламерьё что не любит IPv6 потому что привыкло защищаться NAT'ом?
А он тут каким боком вообще?
> А он тут каким боком вообще?так главный аргумент у них против ipv6 - "нат нас защищает!! нат вороги не пройдут!!1"
хотя в обсуждениях ipv4+nat vs ipv6 регулярно приводят даже методы открытия ната снаружи
Вполне себе защищает, что не так то? Ломают через троян в виде браузера.
Интересно посмотреть где этого "трояна" нету.Смешнее другое - сейчас костылей понаставят, а завтра окажется что то же самое можно сделать простым пингом.
Нет браузера - нет трояна. Найти другой способ выполнить свой код на стороне клиента за натом ещё постараться надо.
Справжнє(tm) махровое профнепригодное ламерьё даже статью не осилило и вектор атаки не осознало, а уже в каминаут ринулось.
А сейчас Шигорин удалит комментарий Шигорина как офтопик. Хотя нет, не удалит, кто бы сомневался...
> А сейчас Шигорин удалит комментарий Шигорина как офтопик.
> Хотя нет, не удалит, кто бы сомневался...Не, пока есть шанс, что человек уязвится, но намёк поймёт, что не те три буквы полез рубить -- не офтопик. Но в целом Вы, конечно, правы (и по теме).
Я смотрю, шигорин на парашу убежал, но даже там его антиукраинская анусная боль не отпускает. Это хорошо.
>что не любит IPv6 потому что привыкло защищаться NAT'омКак-будто для IPv6 нету NAT'а.
UPnP выключайте в роутере и будет вам счастье
Тоже дыра дырой
А еще у меня NAT провайдера и потом NAT роутера и firewall в убунточке включен (и в десяточке), так что давайте вперед!
Насколько я понимаю, тот факт, что PF по умолчанию работает в stateful-режиме уже не первый год, делает маршрутизаторы на базе OpenBSD по умолчанию (пока кто-то специально не начнёт использовать no state) неуязвимыми к данной атаке?
Там вообще alg нет. Поэтому и защищает 😁
ну так дропать соединения по портам 5060(1) в наружу от пользаков, не?
На всякий случай лучше все порты заблочить.
Достаточно только 5060/5061 TCP закрыть, UDP можно для SIP оставить.
> пакет с HTTP-заголовками и частью данных и корректный SIP-пакет, в котором указан внутренний IP жертвыА что, NATящий шлюз не смотрит, что у "корректного SIP-пакета" в заголовке Sequence Number field указывает на его принадлежность к другому соединению, и обрабатывать его как пакет SIP не следует?
Не, не смотрит. Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять, а вот какой там номер будет у первого пакета ему пофигу. То есть этот номер _не_ говорит о принадлежности к другому соединению, соединение идентифицируется адресами и портами источника/приёмника. Тут занятно иное -- файрволл по идее должен отслеживать состояние как-то, и наверное должен помнить, что это вроде http был, но он "не помнит". Непонятно как там это сделано так: тут помню, а тут не помню.
> Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверятьПутаешь. Таки TCP.
>> Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять
> Путаешь. Таки TCP.А, ну да, точно. Путаю.
Firewall без DPI зачастую вообще не знает что там за трафик, обычно по портам ориентируется.
Видимо, кривые реализации ALG этого не учитывают.
Многие сервисы, банки эту какаху юзают, что тут НОВОГО ?
ой да ладно вам - замажут заплаткой
Ну, правильное решение это настроенный как для сервера файрвол локалхоста. Либо запускать браузер из ВМ. Рутковская это предвидела.
Угу, и так для всей локалки и всем пользователям...Не проще, запретить весь исходящий трафик на гейте, и выпускать машины с браузерами через прокси с аутенфикацией?
Лучше поставить терминальный сервер приложений и запускать браузер на нем. А на машинах конечных пользователей интернет ни к чему.
В самом деле. Чтобы если проломили терминальный сервер - проломили всех сразу.
Терминальный сервер ? В домаших и малых бизнесах сетках? А вы знаете толк как экономить чужие деньги!
Не проще и дешевле поставить + прокси ?
> Не проще и дешевле поставить pfsense/opnsense/any-linux+ прокси ?
И чем это решение проще для рядовых пользователей? Более того, на гейте же тоже надо настраивать файрвол. Ваше решение норм, но кому как удобнее...
>И чем это решение проще для рядовых пользователей?Тем, что проксик на бесплатном pfsense, который взлетит на любом старом компе (который в свою очередь будет значительно мощнее чем самая расфуфыренная мыльница) в отличие он терминального сервера на который еще и CAL прикупить будет надо, плюс клиентам в любом случае нужен комп, смысл их превращать в тонких клиентов?
перекрытие исходящего всего трафика - самая надежная защита. Выход в мир только через контролируемый прокси, на котором можно анализировать и защищать хомяков даже на шифрованном трафике
А ничего, что SIP висит на UDP-порту 5060? Каким образом хвост HTTP-запроса, отправляемого по TCP, превратится в отдельный UDP-пакет на порт 5060? Я чего-то не понял в этой уязвимости.
SIP может работать как через TCP, так и через UDP порт 5060. При отправке по UDP используется WebRTC TURN, о чем в скобках написано.
В общем случае данная "атака" упрётся в файрвол на машине пользователя.
Да, роутер-то пакет обратно пробросит. Но поскольку файрвол на машине пользователя коннектов снаружи не разрешает, а об открытом в сторону сервера атакующего коннекте ничего не знает - давай, до свидания.
Ребята, подскажите, надо ли мне бояться, есть у меня безайпишное pppoe соединение без NAT-а, локалка подключена через вторую сетевуху, а все пакеты, входящие по первой карте на адрес второй карты, дропятся?
При использовании ufw на https://2ip.ru/privacy/ всё хорошо. При использовании nftables с аналогичными правилами - утечка IP адресa через заголовки HTTP proxy и определение туннеля (двусторонний пинг) совсем не радует. Профи, пару дополнительных правил подскажите, плиз...
0. Этот ALG вообще мало где включен.1. Зачем держать у себя запущенными сервисы которые слушают за пределами lo чтото и при этом не безопасны?
2. Почему просто не выставить TTL=1 для всех сервисов которые не должны покидать локалку?
3. Зачем вообще что то фильтровать после этого или думать что NAT не пустит?
Очевидно что разработчики браузеров и сетевых сервисов слишком глупы чтобы догадаться то такой простой вещи как установка ttl=1 для всех сервисов которые не должны покидать локалку.
Скорее всего они даже не в состоянии додуматься какие сервисы не должны покидать локалку, а какие должны. Вот дурачки, да?
Да, потому что мало кто вообще умеет пользоваться сетевым API в операнционках, обычно дальше socket()/connect()/send()/close() не идут.
А через setsockopt() можно очень много всего накрутить, что кардинально меняет некоторые аспекты и влияет на производительность.Потому да, авторы браузеров и сервисов - идиоты, в большинстве своём.
Если сервис больше пары строчек и без setsockopt() - значит авторы таки недалёкие люди, или в лучшем случае не осознали потребности либо руки ещё не дошли.В том же nginx - setsockopt() используется активно, но до ttl руки там не дошли.
Авторы UPnP/DLNA серверов - идиоты, потому что там TTL=1 просто мастхэв не только для мультикаста но и для порта с http.
Притом они часто юзают старое корявое API для мультикаста, я вообще мало видел софта где используется setsockopt(MCAST_JOIN_GROUP).
Некоторое время назад думалось по поводу NAT Traversal между двумя компьютерами за nat засчет имитации ftp сеанса, но казалось что это никак не сделать
"Система отслеживания соединений в сетевом стеке посчитает"
Разве ошибка не тут?
Может быть, а может и нет. Сложно сказать. NAT -- это костыль, который, забивая на идеи заложенные в модель и уровни OSI, работает сразу на нескольких уровнях OSI. В этом смысле, он сам весь с начала и до конца большое архитектурное недоразумение. Ну или ошибка, если тебе это слово больше нравится. Если мы не считаем это ошибкой, то тогда процесс назначения ответственных размазывается и виноватым может оказаться кто угодно.
Модель OSI в принципе плохо применима к стеку протоколов интернета, т.к. он был разработан "конкурирующей" организацией с другого континента. Да, и там, и там используются похожие принципы, но все же, интернет изначально проектировался вовсе не теми людьми, что изобрели OSI где-то параллельно.
Какая разница? NAT не вписывается также и в модель с уровнями TCP/IP.
Может быть получиться проделать эти манипуляции без javascript
на втором этапе можно установить клиенту "большой" cookie, нужно то всего чуть больше килобайта. Потом клиент отправит его и получится превышениедля третьего этапа все данные отдать клиенту в виде формы. Но наверное потребуется чтобы пользователь кликнул и произошла отправка формы
> потребуется чтобы пользователь кликнулда легко, пишешь на странице: "Ваш браузер устарел", и кнопка "обновить до Хром ver. 100500".