The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Атака NAT slipstreaming для отправки запросов на внутренний IP"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Атака NAT slipstreaming для отправки запросов на внутренний IP"  +/
Сообщение от opennews (?), 10-Ноя-20, 11:29 
Сами Камкар (Samy Kamkar), исследователь безопасности, известный созданием различных замысловатых устройств для проведения атак, таких как кейлоггер в USB-зарядке телефона, представил новую технику атаки  "NAT slipstreaming". Атака позволяет при открытии страницы в браузере организовать соединение сервера атакующего с любым портом  UDP или TCP на системе пользователя, находящейся за транслятором адресов. Инструментарий для проведения атаки опубликован на GitHub...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54058

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


2. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +9 +/
Сообщение от Аноним (2), 10-Ноя-20, 11:36 
>WebRTC

Ой, как неожиданно!

Ответить | Правка | Наверх | Cообщить модератору

25. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +6 +/
Сообщение от Lex (??), 10-Ноя-20, 12:47 
> если WebRTC отключен, через перебор адресов с измерением времени отклика

Действительно, неожиданно

Ответить | Правка | Наверх | Cообщить модератору

41. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –6 +/
Сообщение от Аноним (2), 10-Ноя-20, 14:51 
WebRTC всё упрощает в разы. Даже перебирать не надо. Но ты дальше давай сиди на дырявом стуле.
Ответить | Правка | Наверх | Cообщить модератору

61. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +4 +/
Сообщение от Lex (??), 10-Ноя-20, 17:13 
> дальше давай сиди на дырявом стуле.

Кто о чем, как говорится :) Ну это, давай, поосторожней там.. а то уже главная суть статей на опеннете доходить перестает

Ответить | Правка | Наверх | Cообщить модератору

60. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +4 +/
Сообщение от anonymous (??), 10-Ноя-20, 17:13 
Скорее javaScript. Ой как неожиданно!
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

114. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (114), 12-Ноя-20, 02:30 
> Атака может быть совершена независимо от используемого браузера

Как неожиданно и приятно

Ответить | Правка | Наверх | Cообщить модератору

3. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +16 +/
Сообщение от Аноним (3), 10-Ноя-20, 11:37 
Почему всегда костыли? Причём тут SIP? Почему только его? Почему 5060? А если у меня сервер на этом порту, то как мне зайти? Переходить на сафари?
Почему проблему в ALG решают в браузере?
Ответить | Правка | Наверх | Cообщить модератору

9. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –2 +/
Сообщение от Аноним (9), 10-Ноя-20, 11:55 
Тут ошибка не в самом НАТе или АЛГ, тут ошибка в самом браузере, который запускает код, который может открывать порты и т.д. Может следует отключить джаваскрипт?
Ответить | Правка | Наверх | Cообщить модератору

11. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +8 +/
Сообщение от Аноним (3), 10-Ноя-20, 12:00 
Код в браузере не открывает порты. Браузер лишь делает запросы - то что и должен делать. Это NAT доверяет любому коду в запросе и начинает пробрасывать порты изнаружи вовнутрь.
Ответить | Правка | Наверх | Cообщить модератору

28. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +13 +/
Сообщение от Аноним (28), 10-Ноя-20, 13:07 
Давайте еще и в NAT обязательные сертификаты добавим, сгорел сарай гори и хата.
Ответить | Правка | Наверх | Cообщить модератору

47. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +9 +/
Сообщение от Аноним (47), 10-Ноя-20, 15:33 
Браузер должен открывать страницы и их рендерить. И нечего пихать в браузер системные функции, вроде открытия портов и т.д. А так же выполнять недоверенный по умолчанию код и не надо будет потом в браузер подписать костылями в виде загрубления таймеров и т.д.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

95. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –3 +/
Сообщение от 1 (??), 11-Ноя-20, 01:59 
А как ему их рендерить если кода нет? опять упихаться в 5 стандартных тегов и заставлять юзера закликивать их, было такое да не взлетело.

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

Ответить | Правка | Наверх | Cообщить модератору

96. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +3 +/
Сообщение от gogo (?), 11-Ноя-20, 04:14 
Это не пользователи хотят видеть такими браузеры, а разработчики.
html оброс раковыми опухолями со всех сторон.
жду не дождусь, когда волны упрощений докатится и до веба. и сделают какой-нибудь simple html без скриптов и прочих свистоперделок.
Ответить | Правка | Наверх | Cообщить модератору

102. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от mustdie (?), 11-Ноя-20, 10:38 
И даже не разработчики, а менеджеры корпораций. "Веб это платформа" и вот это всё.
Ответить | Правка | Наверх | Cообщить модератору

117. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от 1 (??), 13-Ноя-20, 11:10 
пфф, вэб это среда и ей нужны свисторверделки, так же как этим вашим питонам рубям и прочему чем вы собираетесь си заменить, никто и никогда не придумает ничего универсальнее, этого просто нельзя, чтобы можно было попиксельно окна делать такиеже как в хп и чтобы безопасно.
Ответить | Правка | Наверх | Cообщить модератору

99. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +3 +/
Сообщение от Аноним (99), 11-Ноя-20, 08:19 
Хоть кто-то на opennet понимает как все работает и почему.
Вам нужно полностью запретить браузеру открывать порты, чтобы спасти себя от уязвимостей и бэкдоров.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

108. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –2 +/
Сообщение от srgazh (ok), 11-Ноя-20, 17:02 
На редкость уникальный аноном)) 80 Да?? Ржу не могу
Ответить | Правка | Наверх | Cообщить модератору

112. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (112), 12-Ноя-20, 00:13 
И 443. Если проблема вызвана тем что браузер умеет открывать порты, то ему нужно запретить открывать порты и проблема решится.
Вы же не будете отрицать что запрет открывать приведет к невозможности совершить указанную в новости атаку. И любую другу заодно.
Ответить | Правка | Наверх | Cообщить модератору

119. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +6 +/
Сообщение от Аноним (119), 14-Ноя-20, 02:26 
Ух какие сложные вопросы у вас...

> Почему всегда костыли?

По историческим причинам. Изначально протокол 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 | Наверх | Cообщить модератору

121. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +2 +/
Сообщение от Другой Аноним (?), 15-Ноя-20, 16:24 
Спасибо за ликбез. Прочитал с интересом.
Ответить | Правка | Наверх | Cообщить модератору

130. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Noname (??), 13-Апр-21, 13:42 
Ещё пара таких комментов, и я смогу сдать CCIE, как минимум
Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

131. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноньимъ (ok), 10-Июн-21, 18:51 
Я думаю дело не просто в том, что не хотят, а в том, что это реально сложно, особенно для бытовых железок с ограниченной памятью и железом.
И опять таки встаёт вопрос совместимости с обратной стороны софта, который уже вероятно ожидает конкретную реализацию ната.


Ну и не только в НАТе дело, попробуйте такого монстра протокольного банально разрешить или запретить в фаерволле.

Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

4. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –11 +/
Сообщение от Cyber100email (ok), 10-Ноя-20, 11:39 
бгага, лол какой == у меня внутренняя сетка 1.0.0.0/24

согласен - не правильно. но, как оказалось, я не подвержен данной атаке.)

Ответить | Правка | Наверх | Cообщить модератору

10. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +7 +/
Сообщение от Аноним (9), 10-Ноя-20, 11:56 
Бугага, теперь тебе не доступны сервисы из CDN cloudflare
Ответить | Правка | Наверх | Cообщить модератору

12. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +3 +/
Сообщение от Аноним (12), 10-Ноя-20, 12:00 
Идея, использую-ка я у себя в локалке адреса Netflix'а.
Ответить | Правка | Наверх | Cообщить модератору

20. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +4 +/
Сообщение от Рева RarogCmex Денисemail (?), 10-Ноя-20, 12:19 
Это не защищает от атаки, просто атакующему нужно будет цзнать твою сетку заранее
Ответить | Правка | Наверх | Cообщить модератору

48. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (47), 10-Ноя-20, 15:38 
Адреса гугла надо пользовать, чтоб ютуб не показывал.
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

23. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –2 +/
Сообщение от Cyber100email (ok), 10-Ноя-20, 12:39 
да ты чЁ, правда? вот это да)
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

5. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (5), 10-Ноя-20, 11:42 
>зная параметры фрагментации

В BSD есть scrub, а что делать в линуксе?

Ответить | Правка | Наверх | Cообщить модератору

6. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от Аноним (3), 10-Ноя-20, 11:46 
ЧЁРНЫЙ список
     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
Ответить | Правка | Наверх | Cообщить модератору

8. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +16 +/
Сообщение от Аноним (3), 10-Ноя-20, 11:47 
Эй гугл, мозилла! Я у себя разместил сервис SIP на 80 и 443 порту. Заблокируйте их пожалуйста в своих браузерах немедленно!!!!!
Ответить | Правка | Наверх | Cообщить модератору

37. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от InuYasha (??), 10-Ноя-20, 14:24 
мне тоже это понравилось. Надеюсь, в коммит пойдёт с комментерием HACK )
Ответить | Правка | Наверх | Cообщить модератору

86. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –2 +/
Сообщение от Аноним (86), 10-Ноя-20, 20:08 
Эй, аноним! Ваш SIP-сервис на нестандартных портах не представляет никакой опасности, поскольку модуль ядра nf_nat_sip, используемый в данной атаке, не смотрит на пакеты на этих портах. Поэтому основания для блокировки указанных портов в браузерах нет.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

126. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Витя_Витя (?), 19-Ноя-20, 19:55 
Закрытие, жесткая привязка и проброс портов - это хорошо, но не является панацеей от атак на дырявый линукс ... Делать постоянные рекавери диска и посматривать в директорию /usr/... дабы обнаружить там чужие программные файлы будет не лишним.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

58. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (58), 10-Ноя-20, 17:03 
network.security.ports.banned
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

101. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +2 +/
Сообщение от Аноним (-), 11-Ноя-20, 10:35 
Давайте сразу добавим 443й порт как самый опасный . Сколько же через него вредоносов проходит, ужас просто !
Ответить | Правка | Наверх | Cообщить модератору

7. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –3 +/
Сообщение от КО (?), 10-Ноя-20, 11:46 
"Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
Перестал читать
Ответить | Правка | Наверх | Cообщить модератору

19. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +8 +/
Сообщение от DildoZilla (?), 10-Ноя-20, 12:17 
> Перестал читать

И перестал пользоваться интернетиком?

Ответить | Правка | Наверх | Cообщить модератору

26. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +13 +/
Сообщение от Аноним (3), 10-Ноя-20, 12:54 
И перестал писать комментарии.. Он теперь не может вам ответить.
Ответить | Правка | Наверх | Cообщить модератору

55. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (55), 10-Ноя-20, 16:19 
> "Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
> Перестал читать

Предлагаю все новости начинать с предложения: "Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующим JavaScript-код"
Число неадекватов в комментариях должно резко сократится

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

63. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +5 +/
Сообщение от fuzzi (ok), 10-Ноя-20, 17:29 
Это вряд ли, скорее, наоборот!
аноним выше перестал читать,
но писать не перестал...
Ответить | Правка | Наверх | Cообщить модератору

69. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (-), 10-Ноя-20, 17:45 
учитывая, что js обычно надо при посещении 702FAA-сервисов, можно сказать что пользователь сам запускает чужие программы (хоть на си, хоть на обфускрипте), альтернативы заботливо вытираются из памяти. неадекватна это как раз глобальная социопатия, а не, например, словарный перевод (овладение языком) вместо js cloud api.
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

13. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +6 +/
Сообщение от Аноним (3), 10-Ноя-20, 12:03 
RFC 2616
The default port is TCP 80 [19], but other ports can be used.
Своим фиксом они нарушают это. Все HTTP сервисы на нестандартных портах могут перестать работать после этого обновления. Но им плевать.
Ответить | Правка | Наверх | Cообщить модератору

66. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от Аноним (66), 10-Ноя-20, 17:37 
>  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 сервисы на нестандартных портах могут перестать работать после этого обновления.

Не могут. Достаточно не использовать порты из блеклиста.

Ответить | Правка | Наверх | Cообщить модератору

84. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +2 +/
Сообщение от Аноним (3), 10-Ноя-20, 19:58 
Поправьте меня, но насколько я понял  https://fetch.spec.whatwg.org/ описывает поведение fetch JS API а также политики загрузки картинок CSS и прочего. Но это не относится к самим HTML страницам.
Что касается "Не могут. Достаточно не использовать порты из блеклиста." Дело в том что достаточно не использовать уязвимые реализации NAT. А вот сайты на портах из блеклиста не уязвимы и порты менять никому не обязаны. Недефолтные порты популярны на разных админках, роутерах и т д. И вот однажды вы не сможете зайти на них потому что хром захотел решить проблемы SIPa c NATом.
Ответить | Правка | Наверх | Cообщить модератору

15. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (12), 10-Ноя-20, 12:09 
Не понял необходимости хвостоманипуляции с HTTP-запросом. Далее говорится, что JavaScript-код генерирует корректный SIP-пакет, в котором указан внутренний IP жертвы, и отправляет его на TCP-порт 5060 сервера атакующего. А сразу нельзя послать пакет с компа жертвы на TCP-порт 5060 сервера, если уж отправка на этот порт явно не заблокирована в исходящей цепочке файервола?
Ответить | Правка | Наверх | Cообщить модератору

17. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +5 +/
Сообщение от Аноним (3), 10-Ноя-20, 12:14 
Я так понял что из браузера можно послать только HTTP запрос. Браузер сам добавит заголовки, куки и т д. Поэтому делается большой запрос, который фрагментируется на два. Первая часть с этим мусором, а вторая начинается с SIP REGISTER на которую доверчивые NAT ALG и клюют.
Ответить | Правка | Наверх | Cообщить модератору

123. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (12), 17-Ноя-20, 11:59 
Но вторая часть не будет иметь в заголовке установленного флага SYN. Поэтому принимающая сторона не будет воспринимать это как новое TCP-соединение и отбросит этот пакет, как не принадлежащий какому-либо сеансу.
Ответить | Правка | Наверх | Cообщить модератору

16. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +12 +/
Сообщение от Аноним (16), 10-Ноя-20, 12:10 
Замотали изолентой и типа норм. Лол.
Ответить | Правка | Наверх | Cообщить модератору

18. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +7 +/
Сообщение от Аноним (3), 10-Ноя-20, 12:16 
У них там уже 15 портов закрыты изолентой. Поэтому на 16-ый раз даже думать не стали, достали заготовленный рулон. Только я бы это не изолентой, а туалетной бумагой назвал. Ну или пищевой плёнкой.
Ответить | Правка | Наверх | Cообщить модератору

21. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +6 +/
Сообщение от Аноним (21), 10-Ноя-20, 12:22 
Может, просто хватит уже считать, что NAT защищает от чего-то?
Ответить | Правка | Наверх | Cообщить модератору

31. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (31), 10-Ноя-20, 13:24 
локалхост может эмулировать сеть любой сложности и глубины, а неуловимые джо за пачкой роутеров и связкой телефонов навряд читают провокации в комментах под блэком, ходящим по краю.
Ответить | Правка | Наверх | Cообщить модератору

32. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –5 +/
Сообщение от pofigist (?), 10-Ноя-20, 13:33 
Может просто надо прочитать не только заголовок?
И то что NAT не защищает - расскажи ка Cisco ASA...
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

40. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +3 +/
Сообщение от Аноним (40), 10-Ноя-20, 14:50 
Ты баклажан. Cisco ASA делает не только NAT. NAT сам по себе даже у Cisco ни от чего не защищает.
Ответить | Правка | Наверх | Cообщить модератору

105. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от pofigist (?), 11-Ноя-20, 15:37 
Вообще-то вся защита в Cisco ASA - сделана именно на NAT. Есть трансляция - трифак проходит, нет трансляции - не проходит :)
Ответить | Правка | Наверх | Cообщить модератору

71. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (71), 10-Ноя-20, 18:15 
Циска в Иран уже поставляла своё поделие...
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

74. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (-), 10-Ноя-20, 19:04 
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?
Ответить | Правка | Наверх | Cообщить модератору

81. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (-), 10-Ноя-20, 19:32 
https://www.schneier.com/blog/archives/2014/01/jetplow_nsa_e...
ага, нашёл, устанавливался только на целевые экземпляры, "случайно" попавшие в Иран? и прям так в видимости центрифуг?
Ответить | Правка | Наверх | Cообщить модератору

82. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от Michael Shigorinemail (ok), 10-Ноя-20, 19:50 
> Циска в Иран уже поставляла своё поделие...

Циски и в 2008 году отваливались "где нужно"...

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

106. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от pofigist (?), 11-Ноя-20, 15:39 
>> Циска в Иран уже поставляла своё поделие...
> Циски и в 2008 году отваливались "где нужно"...

И не только кошки... но это к делу отношения не имеет.

Ответить | Правка | Наверх | Cообщить модератору

22. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +7 +/
Сообщение от none (??), 10-Ноя-20, 12:22 
Проблема в косых NAT ALG - не нужно открывать канал только по фрагменту.
Ответить | Правка | Наверх | Cообщить модератору

24. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от К. О. (?), 10-Ноя-20, 12:43 
Пакетный фильтр разбирает пакеты по отдельности. Для него просто не существует чего-то более целого, чем "фрагменты".
Ответить | Правка | Наверх | Cообщить модератору

35. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Crazy Alex (ok), 10-Ноя-20, 13:51 
Ну значит придётся учить.
Ответить | Правка | Наверх | Cообщить модератору

62. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (58), 10-Ноя-20, 17:14 
Ну значит дыры надо пробивать не через отслеживание соединений, а через upnp явно.
Ответить | Правка | Наверх | Cообщить модератору

67. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от К. О. (?), 10-Ноя-20, 17:38 
Пакетный фильтр ты этому не научишь. То есть, если научишь, он уже перестанет быть пакетным фильтром. Ну и ресурсов станет жрать больше на несколько порядков, конечно же.
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

36. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +3 +/
Сообщение от Аноним (36), 10-Ноя-20, 13:59 
Нет, см conntrack
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

64. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от К. О. (?), 10-Ноя-20, 17:36 
Да. Conntrack, грубо говоря, поворачивает ручку, ориентируясь на содержимое единственного пакета.
Ответить | Правка | Наверх | Cообщить модератору

38. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +2 +/
Сообщение от BorichL (?), 10-Ноя-20, 14:31 

fwcmd="/sbin/ipfw"
${fwcmd} add reass all from any to any in
${fwcmd} add deny  all from any to any frag
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

27. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +2 +/
Сообщение от Аноним (27), 10-Ноя-20, 13:05 
А в чем проблема, крутая фича же. Можно решить часть типичных нат-проблем без перехода на ipv6. Или кто-то все ещё думает, что нат, он для безопасности?
Ответить | Правка | Наверх | Cообщить модератору

33. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –8 +/
Сообщение от pofigist (?), 10-Ноя-20, 13:35 
Cisco ASA знаешь? NAT однако... Как у большинства сетевых фаерволов
Ответить | Правка | Наверх | Cообщить модератору

50. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от JL2001 (ok), 10-Ноя-20, 15:47 
> А в чем проблема, крутая фича же. Можно решить часть типичных нат-проблем
> без перехода на ipv6. Или кто-то все ещё думает, что нат,
> он для безопасности?

это не проход ната, инициируемый снаружи, для подключения, это очередной WebRTC - требуется действие, инициируемое изнутри ната

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

29. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от ryoken (ok), 10-Ноя-20, 13:07 
Очень теоретический вопрос. А если внутренняя сеть только по IPv6 шарашится?
Ответить | Правка | Наверх | Cообщить модератору

52. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от JL2001 (ok), 10-Ноя-20, 15:48 
> Очень теоретический вопрос. А если внутренняя сеть только по IPv6 шарашится?

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

Ответить | Правка | Наверх | Cообщить модератору

30. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от vitalif (ok), 10-Ноя-20, 13:17 
Эм, что-то я не понял. При чём тут SIP? И при чём тут данные? Я думал, что NAT пробрасывает соединения по заголовкам пакета, а не по данным...

// А, понял, это как раз ALG так делают. Ну и изврат.

Ответить | Правка | Наверх | Cообщить модератору

39. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (39), 10-Ноя-20, 14:32 
А я вот не до конца понял... Linux подвержен?

Там не просто "содержимое пакета"! В iptables (conntrack) вообще-то есть "состояние": new, established, related и еще можно counters добавить, если не хватает.

Может нужно более корректные conntrack-обработчики протоколов написать? Или пофиксить проблему более жёсткими правилами iptables на стороне NAT?

Ответить | Правка | Наверх | Cообщить модератору

70. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от vitalif (ok), 10-Ноя-20, 17:58 
Сам по себе нет, это работает только если на роутере стоит ALG - софт, который анализирует содержимое пакетов, смотрит, когда, скажем, FTP просит открыть входящий порт, и открывает ему этот порт автоматом сквозь NAT. Чтобы типа работали соединения FTP через NAT. То есть, по-видимому, чтобы работали FTP ACTIVE соединения, т.к. PASSIVE-то и так работают.

А анализ получается смотрит на отдельные пакеты и поэтому уязвим к фрагментации.

Ну и аналогично видимо с SIP. В OpenWrt, например, как я понял, это реализовано через siproxd. Если такой или подобной хрени в роутере нет - то и дырки такой нет... По ссылке в статье у автора в каком-то нетгире это через какие-то модули ядра вообще работает.

Ответить | Правка | Наверх | Cообщить модератору

83. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (39), 10-Ноя-20, 19:57 
Вот с ftp отличный пример. В том же nf_conntrack_ftp учтено, что PORT может оказаться между двух пакетов и еще много разных "состояний" пакета учтено - "будущие" (перепутанные) пакеты не сразу анализируются, соединения должны быть установлены и т.д. Внедрить PORT посреди HTTP-пакета (в какие-нибудь заголовки) вполне можно и conntrack на это вполне может среагировать, ждать "начала пакета" не нужно...

А здесь... - либо определение MSS в уязвимости надо нафиг выкинуть, либо поправить реализацию CONFIG_NF_CONNTRACK_SIP в ядре... либо я чего-то не понимаю (или очень замороченный этот протокол SIP, да еще и поверх TCP).

Ответить | Правка | Наверх | Cообщить модератору

107. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Павел Отредиезemail (?), 11-Ноя-20, 15:55 
Приехали, statefull файерволы обманывают. Возвращаемся на stateless - NO TRACK!!!
Ответить | Правка | Наверх | Cообщить модератору

34. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (34), 10-Ноя-20, 13:45 
Ну что где там то махровое профрепригодное ламерьё что не любит IPv6 потому что привыкло защищаться NAT'ом?
Ответить | Правка | Наверх | Cообщить модератору

42. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +3 +/
Сообщение от Аноним (2), 10-Ноя-20, 14:54 
А он тут каким боком вообще?
Ответить | Правка | Наверх | Cообщить модератору

53. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от JL2001 (ok), 10-Ноя-20, 15:52 
> А он тут каким боком вообще?

так главный аргумент у них против ipv6 - "нат нас защищает!! нат вороги не пройдут!!1"

хотя в обсуждениях ipv4+nat vs ipv6 регулярно приводят даже методы открытия ната снаружи

Ответить | Правка | Наверх | Cообщить модератору

54. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +3 +/
Сообщение от Аноним (2), 10-Ноя-20, 15:57 
Вполне себе защищает, что не так то? Ломают через троян в виде браузера.
Ответить | Правка | Наверх | Cообщить модератору

72. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (34), 10-Ноя-20, 18:28 
Интересно посмотреть где этого "трояна" нету.

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

Ответить | Правка | Наверх | Cообщить модератору

73. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (2), 10-Ноя-20, 19:01 
Нет браузера - нет трояна. Найти другой способ выполнить свой код на стороне клиента за натом ещё постараться надо.
Ответить | Правка | Наверх | Cообщить модератору

51. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –5 +/
Сообщение от Michael Shigorinemail (ok), 10-Ноя-20, 15:48 
Справжнє(tm) махровое профнепригодное ламерьё даже статью не осилило и вектор атаки не осознало, а уже в каминаут ринулось.
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

89. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Урри (ok), 10-Ноя-20, 20:30 
А сейчас Шигорин удалит комментарий Шигорина как офтопик. Хотя нет, не удалит, кто бы сомневался...
Ответить | Правка | Наверх | Cообщить модератору

90. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –2 +/
Сообщение от Michael Shigorinemail (ok), 10-Ноя-20, 21:06 
> А сейчас Шигорин удалит комментарий Шигорина как офтопик.
> Хотя нет, не удалит, кто бы сомневался...

Не, пока есть шанс, что человек уязвится, но намёк поймёт, что не те три буквы полез рубить -- не офтопик.  Но в целом Вы, конечно, правы (и по теме).

Ответить | Правка | Наверх | Cообщить модератору

120. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от OpenVMS (?), 14-Ноя-20, 22:37 
Я смотрю, шигорин на парашу убежал, но даже там его антиукраинская анусная боль не отпускает. Это хорошо.
Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

122. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (12), 17-Ноя-20, 11:51 
>что не любит IPv6 потому что привыкло защищаться NAT'ом

Как-будто для IPv6 нету NAT'а.

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

43. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +5 +/
Сообщение от Аноним (43), 10-Ноя-20, 14:58 
UPnP выключайте в роутере и будет вам счастье
Тоже дыра дырой
А еще у меня NAT провайдера и потом NAT роутера и firewall в убунточке включен (и в десяточке), так что давайте вперед!
Ответить | Правка | Наверх | Cообщить модератору

44. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +3 +/
Сообщение от Аноним (44), 10-Ноя-20, 15:00 
Насколько я понимаю, тот факт, что PF по умолчанию работает в stateful-режиме уже не первый год, делает маршрутизаторы на базе OpenBSD по умолчанию (пока кто-то специально не начнёт использовать no state) неуязвимыми к данной атаке?
Ответить | Правка | Наверх | Cообщить модератору

49. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +4 +/
Сообщение от Аноним (47), 10-Ноя-20, 15:41 
Там вообще alg нет. Поэтому и защищает 😁
Ответить | Правка | Наверх | Cообщить модератору

45. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –2 +/
Сообщение от An (??), 10-Ноя-20, 15:01 
ну так дропать соединения по портам 5060(1) в наружу от пользаков, не?
Ответить | Правка | Наверх | Cообщить модератору

85. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (3), 10-Ноя-20, 20:04 
На всякий случай лучше все порты заблочить.
Ответить | Правка | Наверх | Cообщить модератору

124. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от aaaa (??), 18-Ноя-20, 10:53 
Достаточно только 5060/5061 TCP закрыть, UDP можно для SIP оставить.
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

46. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +5 +/
Сообщение от YetAnotherOnanym (ok), 10-Ноя-20, 15:03 
> пакет с HTTP-заголовками и частью данных и корректный SIP-пакет, в котором указан внутренний IP жертвы

А что, NATящий шлюз не смотрит, что у "корректного SIP-пакета" в заголовке Sequence Number field указывает на его принадлежность к другому соединению, и обрабатывать его как пакет SIP не следует?

Ответить | Правка | Наверх | Cообщить модератору

77. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от Ordu (ok), 10-Ноя-20, 19:17 
Не, не смотрит. Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять, а вот какой там номер будет у первого пакета ему пофигу. То есть этот номер _не_ говорит о принадлежности к другому соединению, соединение идентифицируется адресами и портами источника/приёмника. Тут занятно иное -- файрволл по идее должен отслеживать состояние как-то, и наверное должен помнить, что это вроде http был, но он "не помнит". Непонятно как там это сделано так: тут помню, а тут не помню.
Ответить | Правка | Наверх | Cообщить модератору

109. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (109), 11-Ноя-20, 17:58 
> Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять

Путаешь. Таки TCP.

Ответить | Правка | Наверх | Cообщить модератору

110. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Ordu (ok), 11-Ноя-20, 17:59 
>> Если я не путаю ничего, TCP/IP (точнее IP) от этих номеров ждёт лишь последовательности, чтоб на потери проверять
> Путаешь. Таки TCP.

А, ну да, точно. Путаю.

Ответить | Правка | Наверх | Cообщить модератору

125. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от aaaa (??), 18-Ноя-20, 10:55 
Firewall без DPI зачастую вообще не знает что там за трафик, обычно по портам ориентируется.
Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

78. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +4 +/
Сообщение от Аноним (78), 10-Ноя-20, 19:25 
Видимо, кривые реализации ALG этого не учитывают.
Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

56. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (56), 10-Ноя-20, 16:31 
Многие сервисы, банки эту какаху юзают, что тут НОВОГО ?

Ответить | Правка | Наверх | Cообщить модератору

57. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (57), 10-Ноя-20, 17:02 
ой да ладно вам - замажут заплаткой
Ответить | Правка | Наверх | Cообщить модератору

59. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (59), 10-Ноя-20, 17:13 
Ну, правильное решение это настроенный как для сервера файрвол локалхоста. Либо запускать браузер из ВМ. Рутковская это предвидела.
Ответить | Правка | Наверх | Cообщить модератору

65. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от OpenEcho (?), 10-Ноя-20, 17:37 
Угу, и так для всей локалки и всем пользователям...

Не проще, запретить весь исходящий трафик на гейте, и выпускать машины с браузерами через прокси с аутенфикацией?

Ответить | Правка | Наверх | Cообщить модератору

75. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (75), 10-Ноя-20, 19:11 
Лучше поставить терминальный сервер приложений и запускать браузер на нем. А на машинах конечных пользователей интернет ни к чему.
Ответить | Правка | Наверх | Cообщить модератору

79. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +2 +/
Сообщение от Аноним (79), 10-Ноя-20, 19:27 
В самом деле. Чтобы если проломили терминальный сервер - проломили всех сразу.
Ответить | Правка | Наверх | Cообщить модератору

87. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от OpenEcho (?), 10-Ноя-20, 20:11 
Терминальный сервер ? В домаших и малых бизнесах сетках? А вы знаете толк как экономить чужие деньги!
Не проще и дешевле поставить + прокси ?
Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

88. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от OpenEcho (?), 10-Ноя-20, 20:12 
> Не проще и дешевле поставить pfsense/opnsense/any-linux+ прокси ?
Ответить | Правка | Наверх | Cообщить модератору

97. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (59), 11-Ноя-20, 06:05 
И чем это решение проще для рядовых пользователей? Более того, на гейте же тоже надо настраивать файрвол. Ваше решение норм, но кому как удобнее...
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

113. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от OpenEcho (?), 12-Ноя-20, 00:46 
>И чем это решение проще для рядовых пользователей?

Тем, что проксик на бесплатном pfsense, который взлетит на любом старом компе (который в свою очередь будет значительно мощнее чем самая расфуфыренная мыльница) в отличие он терминального сервера на который еще и CAL прикупить будет надо, плюс клиентам в любом случае нужен комп, смысл их превращать в тонких клиентов?

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

Ответить | Правка | Наверх | Cообщить модератору

68. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (68), 10-Ноя-20, 17:44 
А ничего, что SIP висит на UDP-порту 5060? Каким образом хвост HTTP-запроса, отправляемого по TCP, превратится в отдельный UDP-пакет на порт 5060? Я чего-то не понял в этой уязвимости.
Ответить | Правка | Наверх | Cообщить модератору

76. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +3 +/
Сообщение от Аноним (76), 10-Ноя-20, 19:13 
SIP может работать как через TCP, так и через UDP порт 5060. При отправке по UDP используется WebRTC TURN, о чем в скобках написано.
Ответить | Правка | Наверх | Cообщить модератору

80. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (79), 10-Ноя-20, 19:29 
В общем случае данная "атака" упрётся в файрвол на машине пользователя.
Да, роутер-то пакет обратно пробросит. Но поскольку файрвол на машине пользователя коннектов снаружи не разрешает, а об открытом в сторону сервера атакующего коннекте ничего не знает - давай, до свидания.
Ответить | Правка | Наверх | Cообщить модератору

91. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (71), 10-Ноя-20, 21:57 
Ребята, подскажите, надо ли мне бояться, есть у меня безайпишное pppoe соединение без NAT-а, локалка подключена через вторую сетевуху, а все пакеты, входящие по первой карте на адрес второй карты, дропятся?
Ответить | Правка | Наверх | Cообщить модератору

92. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (92), 10-Ноя-20, 22:52 
При использовании ufw на https://2ip.ru/privacy/ всё хорошо. При использовании nftables с аналогичными правилами - утечка IP адресa через заголовки HTTP proxy  и определение туннеля (двусторонний пинг) совсем не радует. Профи, пару дополнительных правил подскажите, плиз...
Ответить | Правка | Наверх | Cообщить модератору

93. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +5 +/
Сообщение от Ivan_83 (ok), 11-Ноя-20, 00:23 
0. Этот ALG вообще мало где включен.

1. Зачем держать у себя запущенными сервисы которые слушают за пределами lo чтото и при этом не безопасны?

2. Почему просто не выставить TTL=1 для всех сервисов которые не должны покидать локалку?

3. Зачем вообще что то фильтровать после этого или думать что NAT не пустит?

Ответить | Правка | Наверх | Cообщить модератору

116. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  –1 +/
Сообщение от Аноним (112), 12-Ноя-20, 22:18 
Очевидно что разработчики браузеров и сетевых сервисов слишком глупы чтобы догадаться то такой простой вещи как установка ttl=1 для всех сервисов которые не должны покидать локалку.
Скорее всего они даже не в состоянии додуматься какие сервисы не должны покидать локалку, а какие должны. Вот дурачки, да?
Ответить | Правка | Наверх | Cообщить модератору

118. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +2 +/
Сообщение от Ivan_83 (ok), 13-Ноя-20, 20:14 
Да, потому что мало кто вообще умеет пользоваться сетевым API в операнционках, обычно дальше socket()/connect()/send()/close() не идут.
А через setsockopt() можно очень много всего накрутить, что кардинально меняет некоторые аспекты и влияет на производительность.

Потому да, авторы браузеров и сервисов - идиоты, в большинстве своём.
Если сервис больше пары строчек и без setsockopt() - значит авторы таки недалёкие люди, или в лучшем случае не осознали потребности либо руки ещё не дошли.

В том же nginx - setsockopt() используется активно, но до ttl руки там не дошли.

Авторы UPnP/DLNA серверов - идиоты, потому что там TTL=1 просто мастхэв не только для мультикаста но и для порта с http.
Притом они часто юзают старое корявое API для мультикаста, я вообще мало видел софта где используется setsockopt(MCAST_JOIN_GROUP).

Ответить | Правка | Наверх | Cообщить модератору

94. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (112), 11-Ноя-20, 01:13 
Некоторое время назад думалось по поводу NAT Traversal между двумя компьютерами за nat засчет имитации ftp сеанса, но казалось что это никак не сделать
Ответить | Правка | Наверх | Cообщить модератору

98. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +2 +/
Сообщение от Аноним (98), 11-Ноя-20, 07:18 
"Система отслеживания соединений в сетевом стеке посчитает"
Разве ошибка не тут?
Ответить | Правка | Наверх | Cообщить модератору

100. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Ordu (ok), 11-Ноя-20, 10:18 
Может быть, а может и нет. Сложно сказать. NAT -- это костыль, который, забивая на идеи заложенные в модель и уровни OSI, работает сразу на нескольких уровнях OSI. В этом смысле, он сам весь с начала и до конца большое архитектурное недоразумение. Ну или ошибка, если тебе это слово больше нравится. Если мы не считаем это ошибкой, то тогда процесс назначения ответственных размазывается и виноватым может оказаться кто угодно.
Ответить | Правка | Наверх | Cообщить модератору

103. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Аноним (27), 11-Ноя-20, 12:33 
Модель OSI в принципе плохо применима к стеку протоколов интернета, т.к. он был разработан "конкурирующей" организацией с другого континента. Да, и там, и там используются похожие принципы, но все же, интернет изначально проектировался вовсе не теми людьми, что изобрели OSI где-то параллельно.
Ответить | Правка | Наверх | Cообщить модератору

104. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +/
Сообщение от Ordu (ok), 11-Ноя-20, 13:12 
Какая разница? NAT не вписывается также и в модель с уровнями TCP/IP.
Ответить | Правка | Наверх | Cообщить модератору

111. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +2 +/
Сообщение от Аноним (111), 11-Ноя-20, 18:50 
Может быть получиться проделать эти манипуляции без javascript
на втором этапе можно установить клиенту "большой" cookie, нужно то всего чуть больше килобайта. Потом клиент отправит его и получится превышение

для третьего этапа все данные отдать клиенту в виде формы. Но наверное потребуется чтобы пользователь кликнул и произошла отправка формы

Ответить | Правка | Наверх | Cообщить модератору

115. "Атака NAT slipstreaming для отправки запросов на внутренний ..."  +1 +/
Сообщение от Аноним (71), 12-Ноя-20, 07:40 
> потребуется чтобы пользователь кликнул

да легко, пишешь на странице: "Ваш браузер устарел", и кнопка "обновить до Хром ver. 100500".

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру