Это возможно. Но это нерелевантно в контексте статьи, которая призывает строить публичную mesh-сеть на основе Yggdrasil. В своей приватной mesh-сети можно конечно сделать что угодно.
Yggdrasil использует x509-сертификаты с ed25519 вместо RSA или ECDSA. Популярные браузеры должны принимать эти алгоритмы, но публичным центрам сертификации не разрешено выпускать сертификаты с ed25519:
6.1.5 Key sizes
For RSA key pairs the CA SHALL:
• Ensure that the modulus size, when encoded, is at least 2048 bits, and;
• Ensure that the modulus size, in bits, is evenly divisible by 8.
For ECDSA key pairs, the CA SHALL:
• Ensure that the key represents a valid point on the NIST P‐256, NIST P‐384 or NIST P‐521
elliptic curve.
No other algorithms or key sizes are permitted.
В чём именно заключается маскировка Yggdrasil под обычный трафик? Yggdrasil использует ed25519 x509-сертификаты. Ни один браузер такие не использует согласно требованиям CA/B форума. Это позволяет легко заблокировать Yggdrasil трафик замедляя соединения со всеми ServerHello с ed25519-сертификатами без последствий для обычных сайтов.
Потому что это чья-то отсебятина, которую копируют по цепочке из статьи в статью по этой проблеме. В коммите фикса ни слова о каком-либо бренде или вообще типе накопителя.
Для воспроизведения проблемы достаточно было иметь device mapper-based блочное устройство, поддерживающее TRIM, у которого непоследовательно были расположены блоки, например LV с количеством сегментов более одного. Иными словами фрагментированные LV и thin-provisioned тома могли быть так же повреждены даже если они лежали на жёстких дисках.
Я правильно понимаю, что зарезервированный диапазон (for future use) 240.0.0.0/4 не используют из-за того что много оборудования не будет с ним работать или есть какая-то другая причина?
Достаточно сделать аутентификацию по ключам, отключить аутентификацию по паролю и выставить LogLevel ERROR в /etc/ssh/sshd_config, чтобы флуд перебора не шёл в логи. В итоге только для ssh уже не нужно оставлять fail2ban.
Подобный подход используется в подписи модулей ядра Linux с целью получить модульное ядро, которое не загрузит в себя левые модули. Это автоматизировано если включены опции:
Но удалять приватный ключ после сборки нужно явно. Конечно если надо загружать какой-то out-of-tree модуль то придется сохранить приватный ключ до момента подписи этого модуля.
Даже после того как на этом адресе 22 порт недоступен с год — боты продолжают в него намеренно долбить, что как бы намекает, что адрес попал в список
Нет нужды в списках, просто сканируют и пробуют всё IPv4 пространство. Таким же образом тыкаются на всякие URL на 80 и 443 порты независимо от вообще какого-либо ответа от самого веб-сервера или наличия каких-либо файлов в DocumentRoot.
-rand /var/log/messages — рандомное значения из любой папки, лучше взять логи, т.к. с /dev/random или /dev/urandom может все повиснуть наглухо
Во-первых: нет причин указывать -rand параметр если точно не знаете зачем указываете.
Во-вторых: любой лог файл это плохой источник энтропии.
В-третьих: /dev/urandom блокируется только во время инициализации генератора случайных числе (crng init done в dmesg) (CVE-2018-1108), после этого он никогда не блокируется. Ядра, не запатченные от этого CVE, не блокируют urandom.
Нет, это прямое следствие стандартизации. Разрешено то, что было оценено и проверено на пригодность.
Это возможно. Но это нерелевантно в контексте статьи, которая призывает строить публичную mesh-сеть на основе Yggdrasil. В своей приватной mesh-сети можно конечно сделать что угодно.
Yggdrasil использует x509-сертификаты с ed25519 вместо RSA или ECDSA. Популярные браузеры должны принимать эти алгоритмы, но публичным центрам сертификации не разрешено выпускать сертификаты с ed25519:
Источник: https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.2.5.pdf
Из-за этого сейчас заморожен этот запрос в Let's Encrypt: https://community.letsencrypt.org/t/support-ed25519-and-ed448/69868
Такие соединения РКН может заблокировать без ущерба для обычных TLS-соединений.
Да, мимикрировать под что-то правдоподобное, тот же naive proxy. Либо как предложил litalen спрятать это в вебсокетах сайта.
В чём именно заключается маскировка Yggdrasil под обычный трафик? Yggdrasil использует ed25519 x509-сертификаты. Ни один браузер такие не использует согласно требованиям CA/B форума. Это позволяет легко заблокировать Yggdrasil трафик замедляя соединения со всеми ServerHello с ed25519-сертификатами без последствий для обычных сайтов.
Трафик Yggdrasil очень легко отличить от обычного TLS-трафика. Если посмотреть на его трафик в Wireshark то отличия очевидны.
Я не вижу смысла призывать здесь делать на его основе публичную mesh-сеть. РКН заблокирует его моментально как только обратит на него внимание.
Doka 2 https://www.youtube.com/watch?v=Xf-8anqrIJ4
929 Chris Mason <chris.mason@oracle.com>655 David Sterba <dsterba@suse.com>
394 Linus Torvalds <torvalds@linux-foundation.org>
392 Nikolay Borisov <nborisov@suse.com>
357 Filipe Manana <fdmanana@suse.com>
312 Liu Bo <bo.li.liu@oracle.com>
312 Miao Xie <miaox@cn.fujitsu.com>
303 Josef Bacik <josef@redhat.com>
265 Josef Bacik <jbacik@fusionio.com>
208 Anand Jain <anand.jain@oracle.com>
205 David Sterba <dsterba@suse.cz>
155 Qu Wenruo <wqu@suse.com>
147 Jeff Mahoney <jeffm@suse.com>
147 Qu Wenruo <quwenruo@cn.fujitsu.com>
142 Josef Bacik <jbacik@fb.com>
128 Al Viro <viro@zeniv.linux.org.uk>
113 Chris Mason <clm@fb.com>
105 Stefan Behrens <sbehrens@giantdisaster.de>
Для воспроизведения проблемы достаточно было иметь device mapper-based блочное устройство, поддерживающее TRIM, у которого непоследовательно были расположены блоки, например LV с количеством сегментов более одного. Иными словами фрагментированные LV и thin-provisioned тома могли быть так же повреждены даже если они лежали на жёстких дисках.
Начиная с версии 2.4 есть в виде опции tls-crypt (не путать с tls-auth), которая обфусцирует TLS-хендшейк: https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt
Проверил что происходит дальше:
Если нажать кнопку то отображается это:
Кнопка Reset account не активна.
На почту приходит такое письмо:
На сам аккаунт телеграма приходит такое сообщение:
Какова гарантия, что эти действия повредят непосредственно чипы с информацией, а не просто сожгут интерфейс подключения?
Достаточно сделать аутентификацию по ключам, отключить аутентификацию по паролю и выставить LogLevel ERROR в /etc/ssh/sshd_config, чтобы флуд перебора не шёл в логи. В итоге только для ssh уже не нужно оставлять fail2ban.
Зависит от конкретных обстоятельств. Я не в курсе про железо в серьёзных вендорных серверах, но из обычного применения разве что nvidia и zfs.
Подобный подход используется в подписи модулей ядра Linux с целью получить модульное ядро, которое не загрузит в себя левые модули. Это автоматизировано если включены опции:
Но удалять приватный ключ после сборки нужно явно. Конечно если надо загружать какой-то out-of-tree модуль то придется сохранить приватный ключ до момента подписи этого модуля.
Нет нужды в списках, просто сканируют и пробуют всё IPv4 пространство. Таким же образом тыкаются на всякие URL на 80 и 443 порты независимо от вообще какого-либо ответа от самого веб-сервера или наличия каких-либо файлов в DocumentRoot.
Во-первых: нет причин указывать -rand параметр если точно не знаете зачем указываете.
Во-вторых: любой лог файл это плохой источник энтропии.
В-третьих: /dev/urandom блокируется только во время инициализации генератора случайных числе (crng init done в dmesg) (CVE-2018-1108), после этого он никогда не блокируется. Ядра, не запатченные от этого CVE, не блокируют urandom.