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.me/opennews/art.shtml?num=54058

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

Оглавление

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

2. Сообщение от Аноним (2), 10-Ноя-20, 11:36   +9 +/
>WebRTC

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #60

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

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

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

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

5. Сообщение от Аноним (5), 10-Ноя-20, 11:42   +1 +/
>зная параметры фрагментации

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

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

6. Сообщение от Аноним (3), 10-Ноя-20, 11:46   –1 +/
ЧЁРНЫЙ список
     587,   // smtp (outgoing)
     601,   // syslog-conn
     636,   // ldap+ssl
     993,   // imap+ssl
     995,   // pop3+ssl
     2049,  // nfs
     3659,  // apple-sasl
     4045,  // lockd
+    5060,  // sip
+    5061,  // sips
     6000,  // x11
     6665,  // irc (alternate)
     6666,  // irc (alternate)
     6667,  // irc (default)
     6668,  // irc (alternate)
     6669,  // irc (alternate)
     6697,  // irc+tls
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #58

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

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

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

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

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

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

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

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

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

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

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

19. Сообщение от DildoZilla (?), 10-Ноя-20, 12:17   +8 +/
> Перестал читать

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #26

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #41

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

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

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

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

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

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

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

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

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

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

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

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

36. Сообщение от Аноним (36), 10-Ноя-20, 13:59   +3 +/
Нет, см conntrack
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #64

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

38. Сообщение от BorichL (?), 10-Ноя-20, 14:31   +2 +/

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #70

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

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

42. Сообщение от Аноним (2), 10-Ноя-20, 14:54   +3 +/
А он тут каким боком вообще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #53

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #77, #78

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

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

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

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

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

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

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

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

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

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

53. Сообщение от JL2001 (ok), 10-Ноя-20, 15:52   –1 +/
> А он тут каким боком вообще?

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #54

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #63, #69

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

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

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

58. Сообщение от Аноним (58), 10-Ноя-20, 17:03   +1 +/
network.security.ports.banned
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #101

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

60. Сообщение от anonymous (??), 10-Ноя-20, 17:13   +4 +/
Скорее javaScript. Ой как неожиданно!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #114

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #75, #97

66. Сообщение от Аноним (66), 10-Ноя-20, 17:37   –1 +/
>  RFC 2616
> The default port is TCP 80 [19], but other ports can be used.
> Своим фиксом они нарушают это.

Нет.
> Secondly, RFC 2616 has been replaced by the RFC 7230 family of RFCs in 2014. These RFCs define how HTTP is implemented, not how a web browser is using HTTP. Outgoing HTTP requests for the purpose of a web browser are standardized in https://fetch.spec.whatwg.org/ which has a list of blocked ports for a very long while. This change is merely updating that list of disallowed ports. The standard has been fixed and other browsers are implementing this block as well.

https://github.com/whatwg/fetch/issues/1108

> Все HTTP сервисы на нестандартных портах могут перестать работать после этого обновления.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #84

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #83

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #73

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

74. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #71 Ответы: #81

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

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #106

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #107

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

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

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

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

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

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

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

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

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

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

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

93. Сообщение от Ivan_83 (ok), 11-Ноя-20, 00:23   +5 +/
0. Этот ALG вообще мало где включен.

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #96

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #110

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По историческим причинам. Изначально протокол ipv4 не был спроектирован, чтобы выдержать такое количество устройств. Для решения задач адресации начался использовать NAT, и понеслось...

Что общего между стандартом/RFC описывающее трансляцию сетевых адресов для протокола ipv4 и розовыми единорогами? Правильно! Ни то ни другое не существует в объективной реальности =)
Даже в 2020-ом году мы имеем абсолютно несовместимую реализацию NAT между вендорами сетевого железа. Злодеи даже об именовании сущностей договориться не могут.

Чаще всего роутер реализует файрвол так, что, условно, есть 2 зоны, внешняя и внутренняя. Если соединение было исходящее из внутренней зоны, то нужно записать IP-адреса:порты в табличку на определенное время и разрешать входящие соединения. Так работает домашнее барахло. Это минимальный вариант, а то NAT часто бывает симметричный или вводятся дополнительные ограничения по IP внешнего источника или по IP порту. Причем узнать как это у вас реально работает и что на самом делается с пакетами можно только из документации производителя.

Если же протокол на третьем уровне, у протокола несколько взаимосвязанных соединений или, что еще хуже, взаимосвязанные соединения более чем с двумя источниками (пиринговые сети), то NAT все ломает. Когда вендоры сделали аппаратные реализации NAT они обнаружили, что 1001 протокол не поддерживает их костыли. И вместо того чтобы прийти к стандарту они сделали еще большие костыль под названием ALG.

ALG - это когда косорылые бараны, сделавшие ваш роутер лезут в траффик, разбирают несколько типов протоколов, читают как минимум заголовки и делают какую-нибудь странную нестандартную ерунду часто недокументированную, которая по их мнению поможет вам по их идее пройти сквозь NAT (чаще всего нет).
Набор доступных ALG тоже у всех разных, но собаки включают их по умолчанию и убирать их не хотят.

> Причём тут SIP? Почему только его? Почему 5060?

Ха. SIP ALG, пожалуй, единственный ALG, который предоставляют все вендоры без исключения.
SIP - это P2P-протокол установки сессий, применяют его обычно для мультимедиа, но так-то вообще любых. Он жестко стандартизирован, он большой и сложный, там много RFC. Настолько много что сетевики не могут столько прочитать. Суть протокола в том, что клиенты аутентифицировавшись на сервере могут инициировать соединение друг с другом напрямую, описать его, управлять им, пересоздать, изменить. 5060 TCP/UDP  - это стандартный порт SIP, есть еще 5061 TCP для TLS. SIP имеет свои сессии, но существует для того чтобы создавать другие сессии. И SDP (протокол описания сессий) будет их описывать в рамках SIP. Чтобы создать вторую сессию с реальными данными, необходимо согласовать параметры подключения между клиентами. Не только IP-порты, но и кучу всего, потому что сессия бывает не только мультимедийная, но и на передачу файла или канальная обёртка траффика приложения, хоть RDP, вообще что угодно. Получается, что внутри заголовков SIP и в тексте SDP находятся IP/порты/протоколы, а не только как IP-заголовки. А еще набор портов для второй сессии у обоих клиентов случайный и одна сессия SIP может породить вторую сессию с переменным количеством соединений (занятых портов).

Так вот. При использовании NAT заголовки IP-части пакета будут заменены файрволом, но внутри с точки зрения самого протокола IP будут данные от SIP. И вот оно будет не совпадать. IP-заголовки с SIP-заголовками и содержимым SDP.

В SIP есть 4 ключевых подхода по работе с NAT:
1. Расширения Symmetric Responce/RTP.
Описывает в заголовках дополнительно, откуда на самом деле шли пакеты. Некоторые клиенты и сервера можно настроить на принудительное использование rport, даже если о нем не было и речи. А некоторые можно даже вынудить заставить вторую сессию строить таким же образом. Проблема в том, что инфраструктура в общем случае должна быть готова. Оно спасает от части сетевых выкрутасов, но не ото всех. Подходит в простых клиент-серверных сценариях.
2. STUN
STUN - это вспомогательный сервер с двумя белыми IP, на который можно натравить клиента и который сообщит ему, что наворотили у него на роутере. Он позволяет удерживать временные пробосы портов, проверяет типы NAT, и сообщает клиенту всё что может, чтобы установить все сессии. Проблема в том, что если роутеры двух клиентов имеют симметричный NAT, то соединить их нельзя.
3. TURN - Решение проблемы, которую недорешал STUN.
Если 2 клиента имеют симметричный NAT, то можно соединить их обоих с белым TURN который примет данные от первого клиента и передаст второму клиенту. Если же клиенты математически далеки от TURN, то можно построить медиапроксикластер и прокинуть вторую сессию через несколько взаимосвязанных TURN. Недостатки: дорого, медленно.
4. ICE - Протокол, который собирает кандидатов на установку сессий внутрь SDP.
Если взять все возможные способы пройти NAT, начиная от STUN, TURN и заканчивая богомерзким UPnP, посмотреть на все сетевые адаптеры клиента и собрать пары IP:порт не забывая про ipv6, опубликовать их и еще и перепробовать, то тогда-то точно клиенты соединятся, причем надёжнее чем через полное проксирование потока в TURN.

Современный стандарт предполагает использовать ICE. Собственно WebRTC (это все около-SIP-протоколы, только без самой сигнализации SIP) его и использует, поэтому у вас локальный IP видно. ICE нашел всевозможных кандидатов. ICE решает все проблемы (хоть он и толстоват и сложен).

А что делают вендоры железа. А им не нужны билеты на самолёт, когда есть проездной на трамвай. Они предполагают, что вместо применения стандарта нужно:
1. Отключить шифрование TLS/DTLS по-возможности
2. Проинспектировать пакеты
3. Заменить содержимое под то, как это видит вендор, пытаясь обмануть приложение-клиент.
Факт в том, что при одновременном использовании Symmetric Responce/RTP на прокси сервере и ICE на всех клиентах при наличии собственного STUN+TURN никто без DPI не может заблокировать сессию. NAT вообще не проблема. Но если у вас Cisco ASA/ASR вместо файрвола/роутера, и вы всю инфраструктуру строите на стандартных 5060,5061 то она как раз вам включит свою ALG и сломает обход NAT-а в рьяной попытке помочь. А TP-Link не сломает. А Mikrotik сломает только медиапотоки и только раз в час. А D-Link один из немногих, кто держит ALG выключенным.

> Почему проблему в ALG решают в браузере?

Еще раз. Разработчики сетевого железа решили, что они лучше знают как устроены все возможные клиенты и какие бывают юзкейсы для SIP и они сделают лучше, чем английским по белому написанные и официально принятые стандарты IETF. Злодеи не просто не хотят удалить SIP ALG, они включают его всем принудительно по-дефолту. Переписывать ALG под современные стандарты тем более не хотят. Вы что думаете, они почему на ipv6 переходить не могут? Потому что не хотят. Вот и решают проблемы через браузер. Зайдите к себе на роутер и отключите всё ALG, которым не пользуетесь.

Я когда писал этот комментарий хотел как-то поверхностно, не сильно углубляясь в технические детали описать проблематику и посмотрите что вышло... Как людям объяснить что не "WebRTC палит ваш локальный IP", а ICE работает именно так как и должен и это не страшно? У них паранойя от неграмотности.
Как объяснить сетевикам хоть что-то выше уровнем чем VLAN/VXLAN? Они стандарты читать не умеют.

> Переходить на сафари?

Это решение. Поезжайте в Африку, посмотрите природу, поохотьтесь, отдохните от компа. =)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #121, #130, #131

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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




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

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