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

"Новый вариант атаки SAD DNS для подстановки фиктивных данных в кэш DNS "	+/–
Сообщение от opennews (ok), 17-Ноя-21, 20:06
Группа исследователей из Калифорнийского университета в Риверсайде опубликовала новый вариант атаки SAD DNS (CVE-2021-20322), работающий несмотря на защиту, добавленную в прошлом году для блокирования уязвимости CVE-2020-25705. Новый метод в целом аналогичен прошлогодней уязвимости и отличается лишь использованием другого типа ICMP-пакетов для проверки активных UDP-портов. Предложенная атака позволяет осуществить подстановку фиктивных данных в кэш DNS-сервера, что можно использовать для подмены в кэше IP адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56176
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от QwertyReg (ok), 17-Ноя-21, 20:06	–20 +/–
>Предложенный метод работоспособен только в сетевом стеке Linux Дякую, Б-же, що на магистральных маршрутизаторах стоит IOS, а не вот это вот.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #11

4. Сообщение от Урри (ok), 17-Ноя-21, 21:01	+1 +/–
Патч зачетный, из двух строк. Замена -    hval = jhash_1word((__force u32)daddr, fnhe_hashrnd); -    return hash_32(hval, FNHE_HASH_SHIFT); на +    hval = siphash_1u32((__force u32)daddr, &fnhe_hash_key); +    return hash_64(hval, FNHE_HASH_SHIFT);
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5

5. Сообщение от Аноним (5), 17-Ноя-21, 21:51	+1 +/–
Дай ссылку на патч.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #9

6. Сообщение от YetAnotherOnanym (ok), 17-Ноя-21, 21:56	+2 +/–
Типа, если DNS-сервер с отравленным кэшем получит запрос от магистрального маршрутизатора на IOS, то сумеет выдать правильный ответ несмотря на неверные данные, хранящиеся в кэше? Или IOS не обращается к кэширующим DNS-серверам и любое имя резолвит самостоятельно, запрашивая только авторитетные сервера и спускаясь каждый раз от *.root-servers.net?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

7. Сообщение от Онаним (?), 17-Ноя-21, 22:02	+2 +/–
Ждём DE SADE DNS
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26

8. Сообщение от Аноним (8), 17-Ноя-21, 22:03	–1 +/–
У меня сегодня прикол. На свежеустановленной Arch pacman без проблем устанавливает любые пакеты из реп, а chromium и firefox не открывают ни один сайт. DNS_PROBE_FINISHED_NO_INTERNET. Куда копать? Причем на другом компе с практически теми же настройками всё работает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #12, #13, #30

9. Сообщение от Аноним (9), 17-Ноя-21, 22:42	+2 +/–
В тексте новости ссылки на словах "приняты в состав".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #35

10. Сообщение от Аноним (10), 17-Ноя-21, 23:05	+2 +/–
В systemd
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #22

11. Сообщение от AntonAlekseevich (ok), 17-Ноя-21, 23:09	+/–
Магистралы пользуются теми решениями которые продвигали сертифицированные сетевые профессионалы. (И не уровня CCNP:ENCOR, выше.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

12. Сообщение от AntonAlekseevich (ok), 17-Ноя-21, 23:11	+/–
Если поставил NetworkManager то nmtui и вперед. Если ничего то проверь /etc/resolv.conf
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #23

13. Сообщение от microcoder (ok), 17-Ноя-21, 23:14	+/–
Открывает, но оооочень долго. Ютуб без кеша DNS в самом firefox, открывает секунд 40. И кажется только с ютубом такие жестокие задержки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #24

15. Сообщение от IZh. (?), 18-Ноя-21, 00:27	+2 +/–
DNSSEC.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18

17. Сообщение от Аноним (17), 18-Ноя-21, 00:52	+2 +/–
DoH или DoT в браузере проверить
Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от leap42 (ok), 18-Ноя-21, 04:28	+/–
> DNSSEC Нет конечно. Оно никогда не было 100% рабочим и уже скорее всего не будет. Иногда корректные ответы развалидируются и всё, приплыли. Поэтому и появились DoT и DoH. cat /etc/systemd/resolved.conf: DNS=1.1.1.1#one.one.one.one 9.9.9.10#dns10.quad9.net FallbackDNS= Domains=lan local ~. DNSSEC=no DNSOverTLS=yes MulticastDNS=yes LLMNR=yes Cache=yes CacheFromLocalhost=yes DNSStubListener=udp DNSStubListenerExtra= ReadEtcHosts=yes ResolveUnicastSingleLabel=no ll /etc/resolv.conf /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf cat /etc/NetworkManager/NetworkManager.conf: [main] plugins=ifupdown,keyfile dns=none rc-manager=unmanaged systemd-resolved=false [ifupdown] managed=true [connection] connection.llmnr=1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #19, #20, #27, #28, #32

19. Сообщение от leap42 (ok), 18-Ноя-21, 04:30	+/–
[morph@wrkstation] ~$ cat /etc/nsswitch.conf: passwd:         files systemd group:          files systemd shadow:         files gshadow:        files hosts:          resolve [!UNAVAIL=return] dns myhostname
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

20. Сообщение от Аноним (20), 18-Ноя-21, 06:38	+1 +/–
DoH не защитит сам сервер 1.1.1.1 от этой атаки. Если отравить его кеш, то все пользователи DoH получат ядовитый ответ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #21

21. Сообщение от leap42 (ok), 18-Ноя-21, 08:33	+1 +/–
> DoH не защитит сам сервер 1.1.1.1 от этой атаки. Если отравить его > кеш, то все пользователи DoH получат ядовитый ответ. Справделиво. Но вероятность успешной атаки на Клаудфлару ничтожна. Я раньше тож был фанатом DNSSEC и постоянно использовал его. И именно он не пускал на легитимные сайты (ох и не сразу я это понял, но когда понял, нагуглил что это норма).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #25

22. Сообщение от Аноним (22), 18-Ноя-21, 09:16	+/–
Не... systemd-networkd и systemd-resolved использую, да. Но pacman же работает без проблем. DNSSEC и DNSOverTLS отключал в настройках там - не помогает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

23. Сообщение от Аноним (22), 18-Ноя-21, 09:18	+/–
Не... Не ставил.  /etc/resolv.conf такой же, как и на рабочем компе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #37

24. Сообщение от Аноним (22), 18-Ноя-21, 09:22	+/–
Отключал DNSoverHTTPS, запускал с чистыми профилями - не помогло. Интернет то работает. Почему только браузеры не хотят?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

25. Сообщение от Аноним (20), 18-Ноя-21, 10:01	+2 +/–
> Справделиво. Но вероятность успешной атаки на Клаудфлару ничтожна. Сервера у всех одинаковые. Вероятность отравления кеша cloudflare столько же высока как и кеша провайдера. Сервер сам нам скажет, сколько времени будет жить его кеш для определённого домена и в этот момент нужно отправить ему запрос этого домена и ответ на правильно угаданный порт. Строго говоря особо гадать и не нужно, можно отправить на все порты, благо их всего лишь 65000. Главное для атаки это возможность отправлять трафик с произвольного ip-адреса и к сожалению, есть ещё довольно много мест где это возможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #34

26. Сообщение от Аноним (26), 18-Ноя-21, 10:55	+3 +/–
SODOM DNS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #29

27. Сообщение от Аноним (27), 18-Ноя-21, 13:45	–1 +/–
Не поэтому. Провайдеры его просто никогда не внедрят, ибо им предписано блокировать сайты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

28. Сообщение от нах.. (?), 18-Ноя-21, 13:50	+1 +/–
MulticastDNS=yes LLMNR=yes Ахахахахаохохо... ох уж эти локалхосты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #33

29. Сообщение от Robin Bobin (?), 18-Ноя-21, 14:15	+2 +/–
Для доменов и сервисов в целом, но для https мимо. В любом случае, какой ip не получишь, а сервер должен будет подписать хендшейк приватником, которому соответствует единственный публичник этого домена, который апрувлен/подписан всей цепочкой до корневых сертификатов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

30. Сообщение от Robin Bobin (?), 18-Ноя-21, 14:18	+/–
Stubby через TLS? обнови finger pin
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #31

31. Сообщение от Аноним (22), 18-Ноя-21, 19:21	+/–
Stubby с systemd-resolved не нужен. Не установлен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

32. Сообщение от Sem (??), 18-Ноя-21, 22:50	+1 +/–
DNSSEC в systemd-resolved был сломан (не знаю как сейчас). Не стоит делать заключений о DNSSEC только в этой реализации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

33. Сообщение от leap42 (ok), 19-Ноя-21, 07:02	+1 +/–
> Ахахахахаохохо... ох уж эти локалхосты. Да, на всех домашних тачках Linux. А что не так? К чему коммент? Тут далеко не все с десяточки через pussy.exe работают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

34. Сообщение от Аноним (34), 19-Ноя-21, 21:05	+/–
А если я использую 5-ь ДНС серверов от разных провайдеров, и все они вернули различные IP адреса, что делать, открывать 5-ь вкладок в браузере??? ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #36

35. Сообщение от d (??), 20-Ноя-21, 01:20	+/–
Оставлю ссылку на новость, а то мало ли. https://www.opennet.ru/opennews/art.shtml?num=56176
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

36. Сообщение от Аноним (20), 20-Ноя-21, 06:12	+/–
> А если я использую 5-ь ДНС серверов от разных провайдеров, и все > они вернули различные IP адреса Это кстати штатная ситуация для Google с его CDN. Как поступать в такой странной ситуации решать тому, кто настроил эту проблему с 5 серверами. В штатной ситуации несколько серверов настраиваются для отказоустойчивости, а не для верификации. Подлинность ответа можно проверить только через DNSSEC, но оказывается есть горе-админы, что умудряются слать ответы за свой домен с неправильными подписями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

37. Сообщение от AntonAlekseevich (ok), 20-Ноя-21, 12:59	+/–
> Не... Не ставил.  /etc/resolv.conf такой же, как и на рабочем компе. До 53/UDP порта любого хоста из resolv.conf трасса есть? `traceroute -U -4 -p 53 1.1.1.1` + отдельно проверить трассу до хоста без указания протокола. `traceroute -4 1.1.1.1`
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

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

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