| |
| 2.25, Lex (??), 12:47, 10/11/2020 [^] [^^] [^^^] [ответить]
| +6 +/– | |
> если WebRTC отключен, через перебор адресов с измерением времени отклика
Действительно, неожиданно
| | |
| |
| 3.41, Аноним (2), 14:51, 10/11/2020 [^] [^^] [^^^] [ответить]
| –6 +/– |
WebRTC всё упрощает в разы. Даже перебирать не надо. Но ты дальше давай сиди на дырявом стуле.
| | |
| |
| 4.61, Lex (??), 17:13, 10/11/2020 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> дальше давай сиди на дырявом стуле.
Кто о чем, как говорится :) Ну это, давай, поосторожней там.. а то уже главная суть статей на опеннете доходить перестает
| | |
|
|
| |
| 3.114, Аноним (114), 02:30, 12/11/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Атака может быть совершена независимо от используемого браузера
Как неожиданно и приятно
| | |
|
|
| 1.3, Аноним (3), 11:37, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +16 +/– |
Почему всегда костыли? Причём тут SIP? Почему только его? Почему 5060? А если у меня сервер на этом порту, то как мне зайти? Переходить на сафари?
Почему проблему в ALG решают в браузере?
| | |
| |
| 2.9, Аноним (9), 11:55, 10/11/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Тут ошибка не в самом НАТе или АЛГ, тут ошибка в самом браузере, который запускает код, который может открывать порты и т.д. Может следует отключить джаваскрипт?
| | |
| |
| 3.11, Аноним (3), 12:00, 10/11/2020 [^] [^^] [^^^] [ответить]
| +8 +/– |
Код в браузере не открывает порты. Браузер лишь делает запросы - то что и должен делать. Это NAT доверяет любому коду в запросе и начинает пробрасывать порты изнаружи вовнутрь.
| | |
| |
| 4.28, Аноним (28), 13:07, 10/11/2020 [^] [^^] [^^^] [ответить]
| +13 +/– |
Давайте еще и в NAT обязательные сертификаты добавим, сгорел сарай гори и хата.
| | |
| 4.47, Аноним (47), 15:33, 10/11/2020 [^] [^^] [^^^] [ответить]
| +9 +/– |
Браузер должен открывать страницы и их рендерить. И нечего пихать в браузер системные функции, вроде открытия портов и т.д. А так же выполнять недоверенный по умолчанию код и не надо будет потом в браузер подписать костылями в виде загрубления таймеров и т.д.
| | |
| |
| 5.95, 1 (??), 01:59, 11/11/2020 [^] [^^] [^^^] [ответить]
| –3 +/– | |
А как ему их рендерить если кода нет? опять упихаться в 5 стандартных тегов и заставлять юзера закликивать их, было такое да не взлетело.
Что за непонятные догмы, браузер никому ничего не должен, он ровно такой каким его хотят видеть пользователи, захотят с удаленным управлением, значит так и будет, какой смысл об этом ныть, лучше иди расскажи какому нибудь хомячку, что современные браузеры байдизайн уязвимы, и что он должен отказаться от интернета теперь, ну это же просто глупо.
| | |
| |
| 6.96, gogo (?), 04:14, 11/11/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Это не пользователи хотят видеть такими браузеры, а разработчики.
html оброс раковыми опухолями со всех сторон.
жду не дождусь, когда волны упрощений докатится и до веба. и сделают какой-нибудь simple html без скриптов и прочих свистоперделок.
| | |
| |
| 7.102, mustdie (?), 10:38, 11/11/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
И даже не разработчики, а менеджеры корпораций. "Веб это платформа" и вот это всё.
| | |
| |
| 8.117, 1 (??), 11:10, 13/11/2020 [^] [^^] [^^^] [ответить] | +/– | пфф, вэб это среда и ей нужны свисторверделки, так же как этим вашим питонам руб... текст свёрнут, показать | | |
|
|
|
|
|
| 3.99, Аноним (99), 08:19, 11/11/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Хоть кто-то на opennet понимает как все работает и почему.
Вам нужно полностью запретить браузеру открывать порты, чтобы спасти себя от уязвимостей и бэкдоров.
| | |
| |
| |
| 5.112, Аноним (112), 00:13, 12/11/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
И 443. Если проблема вызвана тем что браузер умеет открывать порты, то ему нужно запретить открывать порты и проблема решится.
Вы же не будете отрицать что запрет открывать приведет к невозможности совершить указанную в новости атаку. И любую другу заодно.
| | |
|
|
|
| 2.119, Аноним (119), 02:26, 14/11/2020 [^] [^^] [^^^] [ответить]
| +6 +/– | |
Ух какие сложные вопросы у вас...
> Почему всегда костыли?
По историческим причинам. Изначально протокол 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? Они стандарты читать не умеют.
> Переходить на сафари?
Это решение. Поезжайте в Африку, посмотрите природу, поохотьтесь, отдохните от компа. =)
| | |
| |
| 3.131, Аноньимъ (ok), 18:51, 10/06/2021 [^] [^^] [^^^] [ответить]
| +/– |
 Я думаю дело не просто в том, что не хотят, а в том, что это реально сложно, особенно для бытовых железок с ограниченной памятью и железом.
И опять таки встаёт вопрос совместимости с обратной стороны софта, который уже вероятно ожидает конкретную реализацию ната.
Ну и не только в НАТе дело, попробуйте такого монстра протокольного банально разрешить или запретить в фаерволле.
| | |
|
|
| 1.4, Cyber100 (ok), 11:39, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –11 +/– |
 бгага, лол какой == у меня внутренняя сетка 1.0.0.0/24
согласен - не правильно. но, как оказалось, я не подвержен данной атаке.)
| | |
| 1.5, Аноним (5), 11:42, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>зная параметры фрагментации
В BSD есть scrub, а что делать в линуксе?
| | |
| 1.6, Аноним (3), 11:46, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
ЧЁРНЫЙ список
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
| | |
| |
| 2.8, Аноним (3), 11:47, 10/11/2020 [^] [^^] [^^^] [ответить]
| +16 +/– |
Эй гугл, мозилла! Я у себя разместил сервис SIP на 80 и 443 порту. Заблокируйте их пожалуйста в своих браузерах немедленно!!!!!
| | |
| |
| 3.37, InuYasha (??), 14:24, 10/11/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
мне тоже это понравилось. Надеюсь, в коммит пойдёт с комментерием HACK )
| | |
| 3.86, Аноним (86), 20:08, 10/11/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Эй, аноним! Ваш SIP-сервис на нестандартных портах не представляет никакой опасности, поскольку модуль ядра nf_nat_sip, используемый в данной атаке, не смотрит на пакеты на этих портах. Поэтому основания для блокировки указанных портов в браузерах нет.
| | |
| 3.126, Витя_Витя (?), 19:55, 19/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Закрытие, жесткая привязка и проброс портов - это хорошо, но не является панацеей от атак на дырявый линукс ... Делать постоянные рекавери диска и посматривать в директорию /usr/... дабы обнаружить там чужие программные файлы будет не лишним.
| | |
|
| |
| 3.101, Аноним (-), 10:35, 11/11/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Давайте сразу добавим 443й порт как самый опасный . Сколько же через него вредоносов проходит, ужас просто !
| | |
|
|
| 1.7, КО (?), 11:46, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
"Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
Перестал читать
| | |
| |
| |
| 3.26, Аноним (3), 12:54, 10/11/2020 [^] [^^] [^^^] [ответить]
| +13 +/– |
И перестал писать комментарии.. Он теперь не может вам ответить.
| | |
|
| 2.55, Аноним (55), 16:19, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
> "Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
> Перестал читать
Предлагаю все новости начинать с предложения: "Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
Число неадекватов в комментариях должно резко сократится
| | |
| |
| 3.63, fuzzi (ok), 17:29, 10/11/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Это вряд ли, скорее, наоборот!
аноним выше перестал читать,
но писать не перестал...
| | |
| 3.69, Аноним (-), 17:45, 10/11/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
учитывая, что js обычно надо при посещении 702FAA-сервисов, можно сказать что пользователь сам запускает чужие программы (хоть на си, хоть на обфускрипте), альтернативы заботливо вытираются из памяти. неадекватна это как раз глобальная социопатия, а не, например, словарный перевод (овладение языком) вместо js cloud api.
| | |
|
|
| 1.13, Аноним (3), 12:03, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
RFC 2616
The default port is TCP 80 [19], but other ports can be used.
Своим фиксом они нарушают это. Все HTTP сервисы на нестандартных портах могут перестать работать после этого обновления. Но им плевать.
| | |
| |
| 2.66, Аноним (66), 17:37, 10/11/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> 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 сервисы на нестандартных портах могут перестать работать после этого обновления.
Не могут. Достаточно не использовать порты из блеклиста.
| | |
| |
| 3.84, Аноним (3), 19:58, 10/11/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Поправьте меня, но насколько я понял https://fetch.spec.whatwg.org/ описывает поведение fetch JS API а также политики загрузки картинок CSS и прочего. Но это не относится к самим HTML страницам.
Что касается "Не могут. Достаточно не использовать порты из блеклиста." Дело в том что достаточно не использовать уязвимые реализации NAT. А вот сайты на портах из блеклиста не уязвимы и порты менять никому не обязаны. Недефолтные порты популярны на разных админках, роутерах и т д. И вот однажды вы не сможете зайти на них потому что хром захотел решить проблемы SIPa c NATом.
| | |
|
|
| 1.15, Аноним (12), 12:09, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не понял необходимости хвостоманипуляции с HTTP-запросом. Далее говорится, что JavaScript-код генерирует корректный SIP-пакет, в котором указан внутренний IP жертвы, и отправляет его на TCP-порт 5060 сервера атакующего. А сразу нельзя послать пакет с компа жертвы на TCP-порт 5060 сервера, если уж отправка на этот порт явно не заблокирована в исходящей цепочке файервола?
| | |
| |
| 2.17, Аноним (3), 12:14, 10/11/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
Я так понял что из браузера можно послать только HTTP запрос. Браузер сам добавит заголовки, куки и т д. Поэтому делается большой запрос, который фрагментируется на два. Первая часть с этим мусором, а вторая начинается с SIP REGISTER на которую доверчивые NAT ALG и клюют.
| | |
| |
| 3.123, Аноним (12), 11:59, 17/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Но вторая часть не будет иметь в заголовке установленного флага SYN. Поэтому принимающая сторона не будет воспринимать это как новое TCP-соединение и отбросит этот пакет, как не принадлежащий какому-либо сеансу.
| | |
|
|
| |
| 2.18, Аноним (3), 12:16, 10/11/2020 [^] [^^] [^^^] [ответить]
| +7 +/– |
У них там уже 15 портов закрыты изолентой. Поэтому на 16-ый раз даже думать не стали, достали заготовленный рулон. Только я бы это не изолентой, а туалетной бумагой назвал. Ну или пищевой плёнкой.
| | |
|
| |
| 2.31, Аноним (31), 13:24, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
локалхост может эмулировать сеть любой сложности и глубины, а неуловимые джо за пачкой роутеров и связкой телефонов навряд читают провокации в комментах под блэком, ходящим по краю.
| | |
| 2.32, pofigist (?), 13:33, 10/11/2020 [^] [^^] [^^^] [ответить]
| –5 +/– |
Может просто надо прочитать не только заголовок?
И то что NAT не защищает - расскажи ка Cisco ASA...
| | |
| |
| 3.40, Аноним (40), 14:50, 10/11/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Ты баклажан. Cisco ASA делает не только NAT. NAT сам по себе даже у Cisco ни от чего не защищает.
| | |
| |
| 4.105, pofigist (?), 15:37, 11/11/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вообще-то вся защита в Cisco ASA - сделана именно на NAT. Есть трансляция - трифак проходит, нет трансляции - не проходит :)
| | |
|
| |
| 4.74, Аноним (-), 19:04, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
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?
| | |
| |
| 5.106, pofigist (?), 15:39, 11/11/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Циска в Иран уже поставляла своё поделие...
> Циски и в 2008 году отваливались "где нужно"...
И не только кошки... но это к делу отношения не имеет.
| | |
|
|
|
|
| 1.22, none (??), 12:22, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
Проблема в косых NAT ALG - не нужно открывать канал только по фрагменту.
| | |
| |
| 2.24, К. О. (?), 12:43, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Пакетный фильтр разбирает пакеты по отдельности. Для него просто не существует чего-то более целого, чем "фрагменты".
| | |
| |
| |
| 4.62, Аноним (58), 17:14, 10/11/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну значит дыры надо пробивать не через отслеживание соединений, а через upnp явно.
| | |
| 4.67, К. О. (?), 17:38, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Пакетный фильтр ты этому не научишь. То есть, если научишь, он уже перестанет быть пакетным фильтром. Ну и ресурсов станет жрать больше на несколько порядков, конечно же.
| | |
|
| |
| 4.64, К. О. (?), 17:36, 10/11/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да. Conntrack, грубо говоря, поворачивает ручку, ориентируясь на содержимое единственного пакета.
| | |
|
| 3.38, BorichL (?), 14:31, 10/11/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
fwcmd="/sbin/ipfw"
${fwcmd} add reass all from any to any in
${fwcmd} add deny all from any to any frag
| | |
|
|
| 1.27, Аноним (27), 13:05, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
А в чем проблема, крутая фича же. Можно решить часть типичных нат-проблем без перехода на ipv6. Или кто-то все ещё думает, что нат, он для безопасности?
| | |
| |
| 2.50, JL2001 (ok), 15:47, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
 > А в чем проблема, крутая фича же. Можно решить часть типичных нат-проблем
> без перехода на ipv6. Или кто-то все ещё думает, что нат,
> он для безопасности?
это не проход ната, инициируемый снаружи, для подключения, это очередной WebRTC - требуется действие, инициируемое изнутри ната
| | |
|
| 1.29, ryoken (ok), 13:07, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Очень теоретический вопрос. А если внутренняя сеть только по IPv6 шарашится?
| | |
| |
| 2.52, JL2001 (ok), 15:48, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Очень теоретический вопрос. А если внутренняя сеть только по IPv6 шарашится?
предполагаю, что дырявый нат так же откроет порт
сложнее будет только получить внутренний айпишник перебором
| | |
|
| 1.30, vitalif (ok), 13:17, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Эм, что-то я не понял. При чём тут SIP? И при чём тут данные? Я думал, что NAT пробрасывает соединения по заголовкам пакета, а не по данным...
// А, понял, это как раз ALG так делают. Ну и изврат.
| | |
| |
| 2.39, Аноним (39), 14:32, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– | |
А я вот не до конца понял... Linux подвержен?
Там не просто "содержимое пакета"! В iptables (conntrack) вообще-то есть "состояние": new, established, related и еще можно counters добавить, если не хватает.
Может нужно более корректные conntrack-обработчики протоколов написать? Или пофиксить проблему более жёсткими правилами iptables на стороне NAT?
| | |
| |
| 3.70, vitalif (ok), 17:58, 10/11/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Сам по себе нет, это работает только если на роутере стоит ALG - софт, который анализирует содержимое пакетов, смотрит, когда, скажем, FTP просит открыть входящий порт, и открывает ему этот порт автоматом сквозь NAT. Чтобы типа работали соединения FTP через NAT. То есть, по-видимому, чтобы работали FTP ACTIVE соединения, т.к. PASSIVE-то и так работают.
А анализ получается смотрит на отдельные пакеты и поэтому уязвим к фрагментации.
Ну и аналогично видимо с SIP. В OpenWrt, например, как я понял, это реализовано через siproxd. Если такой или подобной хрени в роутере нет - то и дырки такой нет... По ссылке в статье у автора в каком-то нетгире это через какие-то модули ядра вообще работает.
| | |
| |
| 4.83, Аноним (39), 19:57, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Вот с ftp отличный пример. В том же nf_conntrack_ftp учтено, что PORT может оказаться между двух пакетов и еще много разных "состояний" пакета учтено - "будущие" (перепутанные) пакеты не сразу анализируются, соединения должны быть установлены и т.д. Внедрить PORT посреди HTTP-пакета (в какие-нибудь заголовки) вполне можно и conntrack на это вполне может среагировать, ждать "начала пакета" не нужно...
А здесь... - либо определение MSS в уязвимости надо нафиг выкинуть, либо поправить реализацию CONFIG_NF_CONNTRACK_SIP в ядре... либо я чего-то не понимаю (или очень замороченный этот протокол SIP, да еще и поверх TCP).
| | |
|
|
|
| 1.34, Аноним (34), 13:45, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну что где там то махровое профрепригодное ламерьё что не любит IPv6 потому что привыкло защищаться NAT'ом?
| | |
| |
| |
| 3.53, JL2001 (ok), 15:52, 10/11/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А он тут каким боком вообще?
так главный аргумент у них против ipv6 - "нат нас защищает!! нат вороги не пройдут!!1"
хотя в обсуждениях ipv4+nat vs ipv6 регулярно приводят даже методы открытия ната снаружи
| | |
| |
| 4.54, Аноним (2), 15:57, 10/11/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Вполне себе защищает, что не так то? Ломают через троян в виде браузера.
| | |
| |
| 5.72, Аноним (34), 18:28, 10/11/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Интересно посмотреть где этого "трояна" нету.
Смешнее другое - сейчас костылей понаставят, а завтра окажется что то же самое можно сделать простым пингом.
| | |
| |
| 6.73, Аноним (2), 19:01, 10/11/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Нет браузера - нет трояна. Найти другой способ выполнить свой код на стороне клиента за натом ещё постараться надо.
| | |
|
|
|
|
| 2.51, Michael Shigorin (ok), 15:48, 10/11/2020 [^] [^^] [^^^] [ответить]
| –5 +/– |
 Справжнє(tm) махровое профнепригодное ламерьё даже статью не осилило и вектор атаки не осознало, а уже в каминаут ринулось.
| | |
| |
| 3.89, Урри (ok), 20:30, 10/11/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 А сейчас Шигорин удалит комментарий Шигорина как офтопик. Хотя нет, не удалит, кто бы сомневался...
| | |
| |
| 4.90, Michael Shigorin (ok), 21:06, 10/11/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
> А сейчас Шигорин удалит комментарий Шигорина как офтопик.
> Хотя нет, не удалит, кто бы сомневался...
Не, пока есть шанс, что человек уязвится, но намёк поймёт, что не те три буквы полез рубить -- не офтопик. Но в целом Вы, конечно, правы (и по теме).
| | |
|
| 3.120, OpenVMS (?), 22:37, 14/11/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я смотрю, шигорин на парашу убежал, но даже там его антиукраинская анусная боль не отпускает. Это хорошо.
| | |
|
| 2.122, Аноним (12), 11:51, 17/11/2020 [^] [^^] [^^^] [ответить]
| +/– | |
>что не любит IPv6 потому что привыкло защищаться NAT'ом
Как-будто для IPv6 нету NAT'а.
| | |
|
| 1.43, Аноним (43), 14:58, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
UPnP выключайте в роутере и будет вам счастье
Тоже дыра дырой
А еще у меня NAT провайдера и потом NAT роутера и firewall в убунточке включен (и в десяточке), так что давайте вперед!
| | |
| 1.44, Аноним (44), 15:00, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Насколько я понимаю, тот факт, что PF по умолчанию работает в stateful-режиме уже не первый год, делает маршрутизаторы на базе OpenBSD по умолчанию (пока кто-то специально не начнёт использовать no state) неуязвимыми к данной атаке?
| | |
| 1.45, An (??), 15:01, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
ну так дропать соединения по портам 5060(1) в наружу от пользаков, не?
| | |
| |
| 2.124, aaaa (??), 10:53, 18/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Достаточно только 5060/5061 TCP закрыть, UDP можно для SIP оставить.
| | |
|
| 1.46, YetAnotherOnanym (ok), 15:03, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
 > пакет с HTTP-заголовками и частью данных и корректный SIP-пакет, в котором указан внутренний IP жертвы
А что, NATящий шлюз не смотрит, что у "корректного SIP-пакета" в заголовке Sequence Number field указывает на его принадлежность к другому соединению, и обрабатывать его как пакет SIP не следует?
| | |
| |
| 2.77, Ordu (ok), 19:17, 10/11/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Не, не смотрит. Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять, а вот какой там номер будет у первого пакета ему пофигу. То есть этот номер _не_ говорит о принадлежности к другому соединению, соединение идентифицируется адресами и портами источника/приёмника. Тут занятно иное -- файрволл по идее должен отслеживать состояние как-то, и наверное должен помнить, что это вроде http был, но он "не помнит". Непонятно как там это сделано так: тут помню, а тут не помню.
| | |
| |
| 3.109, Аноним (109), 17:58, 11/11/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять
Путаешь. Таки TCP.
| | |
| |
| 4.110, Ordu (ok), 17:59, 11/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять
> Путаешь. Таки TCP.
А, ну да, точно. Путаю.
| | |
|
| 3.125, aaaa (??), 10:55, 18/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Firewall без DPI зачастую вообще не знает что там за трафик, обычно по портам ориентируется.
| | |
|
|
| 1.59, Аноним (59), 17:13, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну, правильное решение это настроенный как для сервера файрвол локалхоста. Либо запускать браузер из ВМ. Рутковская это предвидела.
| | |
| |
| 2.65, OpenEcho (?), 17:37, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Угу, и так для всей локалки и всем пользователям...
Не проще, запретить весь исходящий трафик на гейте, и выпускать машины с браузерами через прокси с аутенфикацией?
| | |
| |
| 3.75, Аноним (75), 19:11, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Лучше поставить терминальный сервер приложений и запускать браузер на нем. А на машинах конечных пользователей интернет ни к чему.
| | |
| |
| 4.79, Аноним (79), 19:27, 10/11/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
В самом деле. Чтобы если проломили терминальный сервер - проломили всех сразу.
| | |
| 4.87, OpenEcho (?), 20:11, 10/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Терминальный сервер ? В домаших и малых бизнесах сетках? А вы знаете толк как экономить чужие деньги!
Не проще и дешевле поставить + прокси ?
| | |
|
| 3.97, Аноним (59), 06:05, 11/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
И чем это решение проще для рядовых пользователей? Более того, на гейте же тоже надо настраивать файрвол. Ваше решение норм, но кому как удобнее...
| | |
| |
| 4.113, OpenEcho (?), 00:46, 12/11/2020 [^] [^^] [^^^] [ответить]
| +/– | |
>И чем это решение проще для рядовых пользователей?
Тем, что проксик на бесплатном pfsense, который взлетит на любом старом компе (который в свою очередь будет значительно мощнее чем самая расфуфыренная мыльница) в отличие он терминального сервера на который еще и CAL прикупить будет надо, плюс клиентам в любом случае нужен комп, смысл их превращать в тонких клиентов?
перекрытие исходящего всего трафика - самая надежная защита. Выход в мир только через контролируемый прокси, на котором можно анализировать и защищать хомяков даже на шифрованном трафике
| | |
|
|
|
| 1.68, Аноним (68), 17:44, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А ничего, что SIP висит на UDP-порту 5060? Каким образом хвост HTTP-запроса, отправляемого по TCP, превратится в отдельный UDP-пакет на порт 5060? Я чего-то не понял в этой уязвимости.
| | |
| |
| 2.76, Аноним (76), 19:13, 10/11/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
SIP может работать как через TCP, так и через UDP порт 5060. При отправке по UDP используется WebRTC TURN, о чем в скобках написано.
| | |
|
| 1.80, Аноним (79), 19:29, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
В общем случае данная "атака" упрётся в файрвол на машине пользователя.
Да, роутер-то пакет обратно пробросит. Но поскольку файрвол на машине пользователя коннектов снаружи не разрешает, а об открытом в сторону сервера атакующего коннекте ничего не знает - давай, до свидания.
| | |
| 1.91, Аноним (71), 21:57, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Ребята, подскажите, надо ли мне бояться, есть у меня безайпишное pppoe соединение без NAT-а, локалка подключена через вторую сетевуху, а все пакеты, входящие по первой карте на адрес второй карты, дропятся?
| | |
| 1.92, Аноним (92), 22:52, 10/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
При использовании ufw на https://2ip.ru/privacy/ всё хорошо. При использовании nftables с аналогичными правилами - утечка IP адресa через заголовки HTTP proxy и определение туннеля (двусторонний пинг) совсем не радует. Профи, пару дополнительных правил подскажите, плиз...
| | |
| 1.93, Ivan_83 (ok), 00:23, 11/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
 0. Этот ALG вообще мало где включен.
1. Зачем держать у себя запущенными сервисы которые слушают за пределами lo чтото и при этом не безопасны?
2. Почему просто не выставить TTL=1 для всех сервисов которые не должны покидать локалку?
3. Зачем вообще что то фильтровать после этого или думать что NAT не пустит?
| | |
| |
| 2.116, Аноним (112), 22:18, 12/11/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Очевидно что разработчики браузеров и сетевых сервисов слишком глупы чтобы догадаться то такой простой вещи как установка ttl=1 для всех сервисов которые не должны покидать локалку.
Скорее всего они даже не в состоянии додуматься какие сервисы не должны покидать локалку, а какие должны. Вот дурачки, да?
| | |
| |
| 3.118, Ivan_83 (ok), 20:14, 13/11/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Да, потому что мало кто вообще умеет пользоваться сетевым API в операнционках, обычно дальше socket()/connect()/send()/close() не идут.
А через setsockopt() можно очень много всего накрутить, что кардинально меняет некоторые аспекты и влияет на производительность.
Потому да, авторы браузеров и сервисов - идиоты, в большинстве своём.
Если сервис больше пары строчек и без setsockopt() - значит авторы таки недалёкие люди, или в лучшем случае не осознали потребности либо руки ещё не дошли.
В том же nginx - setsockopt() используется активно, но до ttl руки там не дошли.
Авторы UPnP/DLNA серверов - идиоты, потому что там TTL=1 просто мастхэв не только для мультикаста но и для порта с http.
Притом они часто юзают старое корявое API для мультикаста, я вообще мало видел софта где используется setsockopt(MCAST_JOIN_GROUP).
| | |
|
|
| 1.94, Аноним (112), 01:13, 11/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Некоторое время назад думалось по поводу NAT Traversal между двумя компьютерами за nat засчет имитации ftp сеанса, но казалось что это никак не сделать
| | |
| 1.98, Аноним (98), 07:18, 11/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
"Система отслеживания соединений в сетевом стеке посчитает"
Разве ошибка не тут?
| | |
| |
| 2.100, Ordu (ok), 10:18, 11/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Может быть, а может и нет. Сложно сказать. NAT -- это костыль, который, забивая на идеи заложенные в модель и уровни OSI, работает сразу на нескольких уровнях OSI. В этом смысле, он сам весь с начала и до конца большое архитектурное недоразумение. Ну или ошибка, если тебе это слово больше нравится. Если мы не считаем это ошибкой, то тогда процесс назначения ответственных размазывается и виноватым может оказаться кто угодно.
| | |
| |
| 3.103, Аноним (27), 12:33, 11/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Модель OSI в принципе плохо применима к стеку протоколов интернета, т.к. он был разработан "конкурирующей" организацией с другого континента. Да, и там, и там используются похожие принципы, но все же, интернет изначально проектировался вовсе не теми людьми, что изобрели OSI где-то параллельно.
| | |
| |
| 4.104, Ordu (ok), 13:12, 11/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Какая разница? NAT не вписывается также и в модель с уровнями TCP/IP.
| | |
|
|
|
| 1.111, Аноним (111), 18:50, 11/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Может быть получиться проделать эти манипуляции без javascript
на втором этапе можно установить клиенту "большой" cookie, нужно то всего чуть больше килобайта. Потом клиент отправит его и получится превышение
для третьего этапа все данные отдать клиенту в виде формы. Но наверное потребуется чтобы пользователь кликнул и произошла отправка формы
| | |
| |
| 2.115, Аноним (71), 07:40, 12/11/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> потребуется чтобы пользователь кликнул
да легко, пишешь на странице: "Ваш браузер устарел", и кнопка "обновить до Хром ver. 100500".
| | |
|
|
