Потому что это чья-то отсебятина, которую копируют по цепочке из статьи в статью по этой проблеме. В коммите фикса ни слова о каком-либо бренде или вообще типе накопителя.
Для воспроизведения проблемы достаточно было иметь 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.
Централизованно построенный дороги не необходимы, можно и просёлок самостоятельно создавать. Так что только еда и воздух действительно необходимость, а дороги — роскошь.
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.
Ваше утверждение истинно в общем виде. Однако конкретно для RSA при подписи хеш шифруется приватным ключом, а при проверке расшифровывется публичным. https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Signing_messages
Для других алгоритмов это не так.
Если что-то им не позволяет это понять сейчас то что позволит в будущем?
Да, но аудитории это понимать не обязательно.
Виноваты в том, что из-за веерных блокировок блокируется всё что угодно кроме Телеграма.