forum.opennet.ru - "Атака NAT slipstreaming для отправки запросов на внутренний IP" (126)

"Атака 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ообщить модератору

Оглавление

Ой, как неожиданно , Аноним (2), 11:36 , 10-Ноя-20, (2) +9

Действительно, неожиданно, Lex (??), 12:47 , 10-Ноя-20, (25) +6

WebRTC всё упрощает в разы Даже перебирать не надо Но ты дальше давай сиди на , Аноним (2), 14:51 , 10-Ноя-20, (41) –6

Кто о чем, как говорится Ну это, давай, поосторожней там а то уже главная с, Lex (??), 17:13 , 10-Ноя-20, (61) +4

Скорее javaScript Ой как неожиданно , anonymous (??), 17:13 , 10-Ноя-20, (60) +4

Как неожиданно и приятно, Аноним (114), 02:30 , 12-Ноя-20, (114)

Почему всегда костыли Причём тут SIP Почему только его Почему 5060 А если у , Аноним (3), 11:37 , 10-Ноя-20, (3) +16

Тут ошибка не в самом НАТе или АЛГ, тут ошибка в самом браузере, который запуска, Аноним (9), 11:55 , 10-Ноя-20, (9) –2

Код в браузере не открывает порты Браузер лишь делает запросы - то что и должен, Аноним (3), 12:00 , 10-Ноя-20, (11) +8

Давайте еще и в NAT обязательные сертификаты добавим, сгорел сарай гори и хата , Аноним (28), 13:07 , 10-Ноя-20, (28) +13
Браузер должен открывать страницы и их рендерить И нечего пихать в браузер сист, Аноним (47), 15:33 , 10-Ноя-20, (47) +9

А как ему их рендерить если кода нет опять упихаться в 5 стандартных тегов и за, 1 (??), 01:59 , 11-Ноя-20, (95) –3

Это не пользователи хотят видеть такими браузеры, а разработчики html оброс рако, gogo (?), 04:14 , 11-Ноя-20, (96) +3

И даже не разработчики, а менеджеры корпораций Веб это платформа и вот это вс, mustdie (?), 10:38 , 11-Ноя-20, (102) –1

пфф, вэб это среда и ей нужны свисторверделки, так же как этим вашим питонам руб, 1 (??), 11:10 , 13-Ноя-20, (117)

Хоть кто-то на opennet понимает как все работает и почему Вам нужно полностью з, Аноним (99), 08:19 , 11-Ноя-20, (99) +3

На редкость уникальный аноном 80 Да Ржу не могу , srgazh (ok), 17:02 , 11-Ноя-20, (108) –2

И 443 Если проблема вызвана тем что браузер умеет открывать порты, то ему нужно, Аноним (112), 00:13 , 12-Ноя-20, (112) +1

Ух какие сложные вопросы у вас По историческим причинам Изначально протокол i, Аноним (119), 02:26 , 14-Ноя-20, (119) +6

Спасибо за ликбез Прочитал с интересом , Другой Аноним (?), 16:24 , 15-Ноя-20, (121) +2
Ещё пара таких комментов, и я смогу сдать CCIE, как минимум, Noname (??), 13:42 , 13-Апр-21, (130)
Я думаю дело не просто в том, что не хотят, а в том, что это реально сложно, осо, Аноньимъ (ok), 18:51 , 10-Июн-21, (131)

бгага, лол какой у меня внутренняя сетка 1 0 0 0 24согласен - не правильно н, Cyber100 (ok), 11:39 , 10-Ноя-20, (4) –11

Бугага, теперь тебе не доступны сервисы из CDN cloudflare, Аноним (9), 11:56 , 10-Ноя-20, (10) +7

Идея, использую-ка я у себя в локалке адреса Netflix а , Аноним (12), 12:00 , 10-Ноя-20, (12) +3

Это не защищает от атаки, просто атакующему нужно будет цзнать твою сетку заране, Рева RarogCmex Денис (?), 12:19 , 10-Ноя-20, (20) +4
Адреса гугла надо пользовать, чтоб ютуб не показывал , Аноним (47), 15:38 , 10-Ноя-20, (48)

да ты чЁ, правда вот это да , Cyber100 (ok), 12:39 , 10-Ноя-20, (23) –2

В BSD есть scrub, а что делать в линуксе , Аноним (5), 11:42 , 10-Ноя-20, (5) +1
ЧЁРНЫЙ список 587, smtp outgoing 601, syslog-conn 636, , Аноним (3), 11:46 , 10-Ноя-20, (6) –1

Эй гугл, мозилла Я у себя разместил сервис SIP на 80 и 443 порту Заблокируйте , Аноним (3), 11:47 , 10-Ноя-20, (8) +16

мне тоже это понравилось Надеюсь, в коммит пойдёт с комментерием HACK , InuYasha (??), 14:24 , 10-Ноя-20, (37) –1
Эй, аноним Ваш SIP-сервис на нестандартных портах не представляет никакой опасн, Аноним (86), 20:08 , 10-Ноя-20, (86) –2
Закрытие, жесткая привязка и проброс портов - это хорошо, но не является панацее, Витя_Витя (?), 19:55 , 19-Ноя-20, (126)

network security ports banned, Аноним (58), 17:03 , 10-Ноя-20, (58) +1

Давайте сразу добавим 443й порт как самый опасный Сколько же через него вредон, Аноним (-), 10:35 , 11-Ноя-20, (101) +2

Для проведения атаки достаточно, чтобы жертва запустила подготовленный атакующи, КО (?), 11:46 , 10-Ноя-20, (7) –3

И перестал пользоваться интернетиком , DildoZilla (?), 12:17 , 10-Ноя-20, (19) +8

И перестал писать комментарии Он теперь не может вам ответить , Аноним (3), 12:54 , 10-Ноя-20, (26) +13

Предлагаю все новости начинать с предложения Для проведения атаки достаточно, , Аноним (55), 16:19 , 10-Ноя-20, (55)

Это вряд ли, скорее, наоборот аноним выше перестал читать,но писать не перестал , fuzzi (ok), 17:29 , 10-Ноя-20, (63) +5
учитывая, что js обычно надо при посещении 702FAA-сервисов, можно сказать что по, Аноним (-), 17:45 , 10-Ноя-20, (69) +1

RFC 2616The default port is TCP 80 19 , but other ports can be used Своим фикс, Аноним (3), 12:03 , 10-Ноя-20, (13) +6

Нет https github com whatwg fetch issues 1108Не могут Достаточно не использов, Аноним (66), 17:37 , 10-Ноя-20, (66) –1

Поправьте меня, но насколько я понял https fetch spec whatwg org описывает п, Аноним (3), 19:58 , 10-Ноя-20, (84) +2

Не понял необходимости хвостоманипуляции с HTTP-запросом Далее говорится, что J, Аноним (12), 12:09 , 10-Ноя-20, (15)

Я так понял что из браузера можно послать только HTTP запрос Браузер сам добави, Аноним (3), 12:14 , 10-Ноя-20, (17) +5

Но вторая часть не будет иметь в заголовке установленного флага SYN Поэтому при, Аноним (12), 11:59 , 17-Ноя-20, (123)

Замотали изолентой и типа норм Лол , Аноним (16), 12:10 , 10-Ноя-20, (16) +12

У них там уже 15 портов закрыты изолентой Поэтому на 16-ый раз даже думать не с, Аноним (3), 12:16 , 10-Ноя-20, (18) +7

Может, просто хватит уже считать, что NAT защищает от чего-то , Аноним (21), 12:22 , 10-Ноя-20, (21) +6

локалхост может эмулировать сеть любой сложности и глубины, а неуловимые джо за , Аноним (31), 13:24 , 10-Ноя-20, (31)
Может просто надо прочитать не только заголовок И то что NAT не защищает - расск, pofigist (?), 13:33 , 10-Ноя-20, (32) –5

Ты баклажан Cisco ASA делает не только NAT NAT сам по себе даже у Cisco ни от , Аноним (40), 14:50 , 10-Ноя-20, (40) +3

Вообще-то вся защита в Cisco ASA - сделана именно на NAT Есть трансляция - триф, pofigist (?), 15:37 , 11-Ноя-20, (105) –1

Циска в Иран уже поставляла своё поделие , Аноним (71), 18:15 , 10-Ноя-20, (71) +1

workstation- airgap- fpg General_Purpose_Device_With_Ability_To_Plug-In_ Removab, Аноним (-), 19:04 , 10-Ноя-20, (74)

https www schneier com blog archives 2014 01 jetplow_nsa_exp htmlага, нашёл, у, Аноним (-), 19:32 , 10-Ноя-20, (81)

Циски и в 2008 году отваливались где нужно , Michael Shigorin (ok), 19:50 , 10-Ноя-20, (82) –1

И не только кошки но это к делу отношения не имеет , pofigist (?), 15:39 , 11-Ноя-20, (106) +1

Проблема в косых NAT ALG - не нужно открывать канал только по фрагменту , none (??), 12:22 , 10-Ноя-20, (22) +7

Пакетный фильтр разбирает пакеты по отдельности Для него просто не существует ч, К. О. (?), 12:43 , 10-Ноя-20, (24)

Ну значит придётся учить , Crazy Alex (ok), 13:51 , 10-Ноя-20, (35)

Ну значит дыры надо пробивать не через отслеживание соединений, а через upnp явн, Аноним (58), 17:14 , 10-Ноя-20, (62) +1
Пакетный фильтр ты этому не научишь То есть, если научишь, он уже перестанет бы, К. О. (?), 17:38 , 10-Ноя-20, (67)

Нет, см conntrack, Аноним (36), 13:59 , 10-Ноя-20, (36) +3

Да Conntrack, грубо говоря, поворачивает ручку, ориентируясь на содержимое един, К. О. (?), 17:36 , 10-Ноя-20, (64) –1

fwcmd sbin ipfw fwcmd add reass all from any to any in fwcmd add deny al, BorichL (?), 14:31 , 10-Ноя-20, (38) +2

А в чем проблема, крутая фича же Можно решить часть типичных нат-проблем без пе, Аноним (27), 13:05 , 10-Ноя-20, (27) +2

Cisco ASA знаешь NAT однако Как у большинства сетевых фаерволов, pofigist (?), 13:35 , 10-Ноя-20, (33) –8
это не проход ната, инициируемый снаружи, для подключения, это очередной WebRTC , JL2001 (ok), 15:47 , 10-Ноя-20, (50)

Очень теоретический вопрос А если внутренняя сеть только по IPv6 шарашится , ryoken (ok), 13:07 , 10-Ноя-20, (29) +1

предполагаю, что дырявый нат так же откроет портсложнее будет только получить вн, JL2001 (ok), 15:48 , 10-Ноя-20, (52)

Эм, что-то я не понял При чём тут SIP И при чём тут данные Я думал, что NAT п, vitalif (ok), 13:17 , 10-Ноя-20, (30) +1

А я вот не до конца понял Linux подвержен Там не просто содержимое пакета , Аноним (39), 14:32 , 10-Ноя-20, (39)

Сам по себе нет, это работает только если на роутере стоит ALG - софт, который а, vitalif (ok), 17:58 , 10-Ноя-20, (70) +1

Вот с ftp отличный пример В том же nf_conntrack_ftp учтено, что PORT может оказ, Аноним (39), 19:57 , 10-Ноя-20, (83)

Приехали, statefull файерволы обманывают Возвращаемся на stateless - NO TRACK , Павел Отредиез (?), 15:55 , 11-Ноя-20, (107)

Ну что где там то махровое профрепригодное ламерьё что не любит IPv6 потому что , Аноним (34), 13:45 , 10-Ноя-20, (34)

А он тут каким боком вообще , Аноним (2), 14:54 , 10-Ноя-20, (42) +3

так главный аргумент у них против ipv6 - нат нас защищает нат вороги не пройд, JL2001 (ok), 15:52 , 10-Ноя-20, (53) –1

Вполне себе защищает, что не так то Ломают через троян в виде браузера , Аноним (2), 15:57 , 10-Ноя-20, (54) +3

Интересно посмотреть где этого трояна нету Смешнее другое - сейчас костылей по, Аноним (34), 18:28 , 10-Ноя-20, (72) +1

Нет браузера - нет трояна Найти другой способ выполнить свой код на стороне кли, Аноним (2), 19:01 , 10-Ноя-20, (73) +1

Справжн 1108 tm махровое профнепригодное ламерьё даже статью не осилило и век, Michael Shigorin (ok), 15:48 , 10-Ноя-20, (51) –5

А сейчас Шигорин удалит комментарий Шигорина как офтопик Хотя нет, не удалит, к, Урри (ok), 20:30 , 10-Ноя-20, (89) +1

Не, пока есть шанс, что человек уязвится, но намёк поймёт, что не те три буквы п, Michael Shigorin (ok), 21:06 , 10-Ноя-20, (90) –2

Я смотрю, шигорин на парашу убежал, но даже там его антиукраинская анусная боль , OpenVMS (?), 22:37 , 14-Ноя-20, (120) –1

Как-будто для IPv6 нету NAT а , Аноним (12), 11:51 , 17-Ноя-20, (122)

UPnP выключайте в роутере и будет вам счастьеТоже дыра дыройА еще у меня NAT про, Аноним (43), 14:58 , 10-Ноя-20, (43) +5
Насколько я понимаю, тот факт, что PF по умолчанию работает в stateful-режиме уж, Аноним (44), 15:00 , 10-Ноя-20, (44) +3

Там вообще alg нет Поэтому и защищает 128513 , Аноним (47), 15:41 , 10-Ноя-20, (49) +4

ну так дропать соединения по портам 5060 1 в наружу от пользаков, не , An (??), 15:01 , 10-Ноя-20, (45) –2

На всякий случай лучше все порты заблочить , Аноним (3), 20:04 , 10-Ноя-20, (85)
Достаточно только 5060 5061 TCP закрыть, UDP можно для SIP оставить , aaaa (??), 10:53 , 18-Ноя-20, (124)

А что, NATящий шлюз не смотрит, что у корректного SIP-пакета в заголовке Seque, YetAnotherOnanym (ok), 15:03 , 10-Ноя-20, (46) +5

Не, не смотрит Если я не путаю ничего, TCP IP точнее IP от этих номеров ждёт , Ordu (ok), 19:17 , 10-Ноя-20, (77) –1

Путаешь Таки TCP , Аноним (109), 17:58 , 11-Ноя-20, (109) +1

А, ну да, точно Путаю , Ordu (ok), 17:59 , 11-Ноя-20, (110)

Firewall без DPI зачастую вообще не знает что там за трафик, обычно по портам ор, aaaa (??), 10:55 , 18-Ноя-20, (125)

Видимо, кривые реализации ALG этого не учитывают , Аноним (78), 19:25 , 10-Ноя-20, (78) +4

Многие сервисы, банки эту какаху юзают, что тут НОВОГО , Аноним (56), 16:31 , 10-Ноя-20, (56)
ой да ладно вам - замажут заплаткой, Аноним (57), 17:02 , 10-Ноя-20, (57)
Ну, правильное решение это настроенный как для сервера файрвол локалхоста Либо , Аноним (59), 17:13 , 10-Ноя-20, (59)

Угу, и так для всей локалки и всем пользователям Не проще, запретить весь исхо, OpenEcho (?), 17:37 , 10-Ноя-20, (65)

Лучше поставить терминальный сервер приложений и запускать браузер на нем А на , Аноним (75), 19:11 , 10-Ноя-20, (75)

В самом деле Чтобы если проломили терминальный сервер - проломили всех сразу , Аноним (79), 19:27 , 10-Ноя-20, (79) +2
Терминальный сервер В домаших и малых бизнесах сетках А вы знаете толк как эк, OpenEcho (?), 20:11 , 10-Ноя-20, (87)

Атака NAT slipstreaming для отправки запросов на внутренний ..., OpenEcho (?), 20:12 , 10-Ноя-20, (88)

И чем это решение проще для рядовых пользователей Более того, на гейте же тоже , Аноним (59), 06:05 , 11-Ноя-20, (97)

Тем, что проксик на бесплатном pfsense, который взлетит на любом старом компе к, OpenEcho (?), 00:46 , 12-Ноя-20, (113)

А ничего, что SIP висит на UDP-порту 5060 Каким образом хвост HTTP-запроса, отп, Аноним (68), 17:44 , 10-Ноя-20, (68)

SIP может работать как через TCP, так и через UDP порт 5060 При отправке по UDP, Аноним (76), 19:13 , 10-Ноя-20, (76) +3

В общем случае данная атака упрётся в файрвол на машине пользователя Да, роуте, Аноним (79), 19:29 , 10-Ноя-20, (80) +1
Ребята, подскажите, надо ли мне бояться, есть у меня безайпишное pppoe соединени, Аноним (71), 21:57 , 10-Ноя-20, (91) +1
При использовании ufw на https 2ip ru privacy всё хорошо При использовании n, Аноним (92), 22:52 , 10-Ноя-20, (92)
0 Этот ALG вообще мало где включен 1 Зачем держать у себя запущенными сервисы , Ivan_83 (ok), 00:23 , 11-Ноя-20, (93) +5

Очевидно что разработчики браузеров и сетевых сервисов слишком глупы чтобы догад, Аноним (112), 22:18 , 12-Ноя-20, (116) –1

Да, потому что мало кто вообще умеет пользоваться сетевым API в операнционках, о, Ivan_83 (ok), 20:14 , 13-Ноя-20, (118) +2

Некоторое время назад думалось по поводу NAT Traversal между двумя компьютерами , Аноним (112), 01:13 , 11-Ноя-20, (94)
Система отслеживания соединений в сетевом стеке посчитает Разве ошибка не тут , Аноним (98), 07:18 , 11-Ноя-20, (98) +2

Может быть, а может и нет Сложно сказать NAT -- это костыль, который, забивая , Ordu (ok), 10:18 , 11-Ноя-20, (100)

Модель OSI в принципе плохо применима к стеку протоколов интернета, т к он был , Аноним (27), 12:33 , 11-Ноя-20, (103)

Какая разница NAT не вписывается также и в модель с уровнями TCP IP , Ordu (ok), 13:12 , 11-Ноя-20, (104)

Может быть получиться проделать эти манипуляции без javascriptна втором этапе мо, Аноним (111), 18:50 , 11-Ноя-20, (111) +2

да легко, пишешь на странице Ваш браузер устарел , и кнопка обновить до Хром , Аноним (71), 07:40 , 12-Ноя-20, (115) +1

Сообщения [Сортировка по времени | 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 +/–

Сообщение от Cyber100 (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 Денис (?), 10-Ноя-20, 12:19

Это не защищает от атаки, просто атакующему нужно будет цзнать твою сетку заранее

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

48. "Атака NAT slipstreaming для отправки запросов на внутренний ..." +/–

Сообщение от Аноним (47), 10-Ноя-20, 15:38

Адреса гугла надо пользовать, чтоб ютуб не показывал.

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

23. "Атака NAT slipstreaming для отправки запросов на внутренний ..." –2 +/–

Сообщение от Cyber100 (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 Shigorin (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 для отправки запросов на внутренний ..." +/–

Сообщение от Павел Отредиез (?), 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 Shigorin (ok), 10-Ноя-20, 15:48

Справжнє(tm) махровое профнепригодное ламерьё даже статью не осилило и вектор атаки не осознало, а уже в каминаут ринулось.

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

89. "Атака NAT slipstreaming для отправки запросов на внутренний ..." +1 +/–

Сообщение от Урри (ok), 10-Ноя-20, 20:30

А сейчас Шигорин удалит комментарий Шигорина как офтопик. Хотя нет, не удалит, кто бы сомневался...

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

90. "Атака NAT slipstreaming для отправки запросов на внутренний ..." –2 +/–

Сообщение от Michael Shigorin (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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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 +/–
Сообщение от Cyber100 (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 Денис (?), 10-Ноя-20, 12:19
	Это не защищает от атаки, просто атакующему нужно будет цзнать твою сетку заранее
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	23. "Атака NAT slipstreaming для отправки запросов на внутренний ..."	–2 +/–
	Сообщение от Cyber100 (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ообщить модератору