Ключ luks вводится до запуска всего описанного гербария при включении VM. Отношения к logind и getty не имеет, т.к. на стадии ввода ключа диск с упомянутыми утилитами еще зашифрован.
В первую очередь, возможность брутфорса пароля. Конечно, в современных реалиях брутфорс серверного пароля навряд ли увенчается успехом, но спится так всё же спокойнее :)
Помимо всего описанного, нянкэт вместо эмулятора терминала — это всё же своего рода юмор.
Отключение или изменение вывода консоли системы не влияет на безопасность, связанную с авторизацией на машине. Теме авторизации как раз посвящена эта статья.
Параметры grub также не являются критичными в плане утечки информации, а ваше переключение на последовательный порт, как уже отмечено, не является решением вами же обозначенной уязвимости.
Абсолютной защиты не бывает, но ее наличие увеличивает шанс на выживаемость. Это сопоставимо с бронежелетом, который часто закрывает около 60% торса, не предусматривая попадание в слабые места, а также сбоку, в ноги, руки и голову.
Менеджер ключей GPA упомянут в статье со словом "упрощенный", т.к. имеет ощутимо меньше функций. Честно говоря, я никогда не встречал людей, использующих этот пакет, и удивляюсь, почему он идет вместе с Клеопатрой, т.к. по концепции с ней схож, а по реализации сильно отстает.
Да, я понимаю. Это близкая идея, но непонятная в части "постоянного майнинга ключа, чтобы его не перехватили" :) Блокчейн в этом плане лучше, потому что намайнил — оно твое, и всё тут.
Пожалуй, вас заинтересует обзор упомянутой в статье технологии ALFIS DNS. Он в планах на этот месяц. В вашем предложении я усматриваю криптографическую составляющую и майнинг ключей, а всё это признаки широкоизвестной технологии под названием блокчейн. Реализаций и идей DNS на блокчейне много, но ALFIS, пожалуй, самая перспективная и легковесная.
… не хватает своей реализации доменных имен, без которых не способны работать сервисы вроде Email и XMPP
… вместо альтернативных костылей в виде ipv6-literal.net или добавления адресов IPv6 в файл hosts для работы Windows Active Directory, а также любых других программ, не поддерживающих синтаксис IPv6 из-за двоеточий и квадратных скобок.
Q: Meshname domains are ugly.
A: Yes, if you want decentralization, you either have ugly names or a blockchain. Meshname has ugly names, but it works at least!
— Домены уродливы.
— Да. Если вы хотите децентрализации, у вас либо нечитабельные имена, либо блокчейн. У мешнейма уродливые имена, но он работает!
Спасибо за комментарий! Если вас смутило упоминание IPv4 в официальном заявлении разработчиков, то это высказывание справдливо для подключений к публичным пирам, что упомянуто в статье.
Возможно, я не понял ваш вопрос. В таком случае прошу дать более развернутое замечание.
Популярность набирает минималистичный торрент-клиент XD, работающий по протоколу SAM — стандартному API для обоих клиентов I2P. Так как i2pd имеет по умолчанию включенный SAM, названный торрент-клиент заведется "из коробки". Также я встречал standalone сборку торрент-клиента Snark, используемого в Java-роутере. Навскидку ссылку не нашел, можете поспрашивать в чатах, посвященных I2P. Рекомендую ILITA IRC (irc.ilita.i2p), если доберетесь. Там в отличие от телеграмов с креветками (никому не в обиду) сидят компетентные люди.
Так как i2pd поддерживает все протоколы взаимодействия внешних приложений, в том числе I2CP, на i2pd можно завести всё, что может работать в связке с Java-роутером. Вопрос навыков и знания теории.
Из лично испробованных торрент-клиентов, поддерживающих I2P-торренты, могу посоветовать BiglyBT. Весьма тяжеловесный комбайн, но комбайн!
В столь сложной теме любой вопрос и интерес заслуживает уважения.
Java-роутер развивается, но крайне медленно, и прироста в его производительности нет (и не будет). Из бытовых проблем: Java-роутер не умеет работать через прокси (развивается с 2003 года, лол), а также отказывается от перспективных решений вроде работы через меш-сети (Yggdrasil), а также, что самое главное, годами не исправляет уже обозначенные угрозы безопасности, т.к. "разработчик боится что-то поломать", либо просто глуп и не догоняет местами, а может быть он не закрывает одну дыру, пока не напишет другую.
I2Pd активно развивается и изначально имеет лучшую стабильность работы и не требователен к ресурсам, так как реализован на C++, то есть работает напрямую с операционной системой и нативными криптографическими библиотеками в отличие от Java, где всё крутится внутри специальной виртуальной машины (так обеспечивается кросс-платформенность приложений на Java и этот факт сделал ее крайне популярной "заменой C++" в нулевых, когда начиналась разработка первого I2P-роутера). Как показывает практика, производительность Java-роутера не спасает даже криптографическая библиотека на Си, т.к. обращения к ней всё равно просаживают производительность.
I2Pd может оттолкнуть новичков лишь в первый момент, т.к. нужно найти конфигурационный файл и открыть документацию, чтобы понять, что в него писать. В Java-роутере веб-консоль превращена в сложную панель полноценного управления, что подкупает неопытных пользователей.
Рекомендую к просмотру моё небольшое видео про протокол I2P: https://www.youtube.com/watch?v=ItkdvFocCQs После описания принципов работы, там упоминается история создания обоих клиентов сети.
Вопрос достаточно острый для единоличных крупных меш-провайдеров в удаленных регионах. В случае многоквартирного дома невозможно узнать кто был транзитным узлом во время загрузки (потому что вокруг десятки и сотни меш-узлов). И даже для смельчаков, которые организуют магистральные кабеля без особого разрешения на то: невозможно будет утверждать, что пользователь загрузил что-то именно по этому кабелю. Вполне вероятно, он подключился к некоему публичному пиру через интернет и скачал свой контент таким образом.
Наверное, это красивая составляющая меш-сетей: предъявлять некому, потому что меш — общая децентрализованная технология, держащаяся на плечах тысяч и миллионов пользователей.
В официальном списке сервисов всего две Wiki: англоязычная полумертвая и приведенная выше :) А вот IRC-чатов во истину много, глаза разбегаются. На многие заходил, где-то активность хорошая. В частности, русскоязычное сообщество более всего восседает в ILITA IRC.
Попытка упростить быстрый старт: В статью добавлена ссылка на внутрисетевую викию "HowToYgg" под заголовком "Начало использования". Кладезь информации от русскоязычного сообщества.
Даёшь мануал на Хабр :)
Было бы любопытно ознакомиться!
Ключ luks вводится до запуска всего описанного гербария при включении VM. Отношения к logind и getty не имеет, т.к. на стадии ввода ключа диск с упомянутыми утилитами еще зашифрован.
В первую очередь, возможность брутфорса пароля. Конечно, в современных реалиях брутфорс серверного пароля навряд ли увенчается успехом, но спится так всё же спокойнее :)
Помимо всего описанного, нянкэт вместо эмулятора терминала — это всё же своего рода юмор.
Отключение или изменение вывода консоли системы не влияет на безопасность, связанную с авторизацией на машине. Теме авторизации как раз посвящена эта статья.
Параметры grub также не являются критичными в плане утечки информации, а ваше переключение на последовательный порт, как уже отмечено, не является решением вами же обозначенной уязвимости.
Абсолютной защиты не бывает, но ее наличие увеличивает шанс на выживаемость. Это сопоставимо с бронежелетом, который часто закрывает около 60% торса, не предусматривая попадание в слабые места, а также сбоку, в ноги, руки и голову.
Шифрование упомянуто в статье, как основной способ защиты. Сама же заметка посвящена ликвидации доступа к терминалу.
Менеджер ключей GPA упомянут в статье со словом "упрощенный", т.к. имеет ощутимо меньше функций. Честно говоря, я никогда не встречал людей, использующих этот пакет, и удивляюсь, почему он идет вместе с Клеопатрой, т.к. по концепции с ней схож, а по реализации сильно отстает.
Да, я понимаю. Это близкая идея, но непонятная в части "постоянного майнинга ключа, чтобы его не перехватили" :) Блокчейн в этом плане лучше, потому что намайнил — оно твое, и всё тут.
Пожалуй, вас заинтересует обзор упомянутой в статье технологии ALFIS DNS. Он в планах на этот месяц. В вашем предложении я усматриваю криптографическую составляющую и майнинг ключей, а всё это признаки широкоизвестной технологии под названием блокчейн. Реализаций и идей DNS на блокчейне много, но ALFIS, пожалуй, самая перспективная и легковесная.
А в России обязана?
https://github.com/zhoreeq/meshname#faq
Спасибо за комментарий! Если вас смутило упоминание IPv4 в официальном заявлении разработчиков, то это высказывание справдливо для подключений к публичным пирам, что упомянуто в статье.
Возможно, я не понял ваш вопрос. В таком случае прошу дать более развернутое замечание.
Популярность набирает минималистичный торрент-клиент XD, работающий по протоколу SAM — стандартному API для обоих клиентов I2P. Так как i2pd имеет по умолчанию включенный SAM, названный торрент-клиент заведется "из коробки". Также я встречал standalone сборку торрент-клиента Snark, используемого в Java-роутере. Навскидку ссылку не нашел, можете поспрашивать в чатах, посвященных I2P. Рекомендую ILITA IRC (irc.ilita.i2p), если доберетесь. Там в отличие от телеграмов с креветками (никому не в обиду) сидят компетентные люди.
Так как i2pd поддерживает все протоколы взаимодействия внешних приложений, в том числе I2CP, на i2pd можно завести всё, что может работать в связке с Java-роутером. Вопрос навыков и знания теории.
Из лично испробованных торрент-клиентов, поддерживающих I2P-торренты, могу посоветовать BiglyBT. Весьма тяжеловесный комбайн, но комбайн!
В столь сложной теме любой вопрос и интерес заслуживает уважения.
Java-роутер развивается, но крайне медленно, и прироста в его производительности нет (и не будет). Из бытовых проблем: Java-роутер не умеет работать через прокси (развивается с 2003 года, лол), а также отказывается от перспективных решений вроде работы через меш-сети (Yggdrasil), а также, что самое главное, годами не исправляет уже обозначенные угрозы безопасности, т.к. "разработчик боится что-то поломать", либо просто глуп и не догоняет местами, а может быть он не закрывает одну дыру, пока не напишет другую.
I2Pd активно развивается и изначально имеет лучшую стабильность работы и не требователен к ресурсам, так как реализован на C++, то есть работает напрямую с операционной системой и нативными криптографическими библиотеками в отличие от Java, где всё крутится внутри специальной виртуальной машины (так обеспечивается кросс-платформенность приложений на Java и этот факт сделал ее крайне популярной "заменой C++" в нулевых, когда начиналась разработка первого I2P-роутера). Как показывает практика, производительность Java-роутера не спасает даже криптографическая библиотека на Си, т.к. обращения к ней всё равно просаживают производительность.
I2Pd может оттолкнуть новичков лишь в первый момент, т.к. нужно найти конфигурационный файл и открыть документацию, чтобы понять, что в него писать. В Java-роутере веб-консоль превращена в сложную панель полноценного управления, что подкупает неопытных пользователей.
Рекомендую к просмотру моё небольшое видео про протокол I2P: https://www.youtube.com/watch?v=ItkdvFocCQs После описания принципов работы, там упоминается история создания обоих клиентов сети.
Если так, попробую посодействовать развеиванию незнаний. Зеркало держит один из ведущих разработчиков i2pd с ником R4SAS. Держит давно и надежно :)
Вопрос достаточно острый для единоличных крупных меш-провайдеров в удаленных регионах. В случае многоквартирного дома невозможно узнать кто был транзитным узлом во время загрузки (потому что вокруг десятки и сотни меш-узлов). И даже для смельчаков, которые организуют магистральные кабеля без особого разрешения на то: невозможно будет утверждать, что пользователь загрузил что-то именно по этому кабелю. Вполне вероятно, он подключился к некоему публичному пиру через интернет и скачал свой контент таким образом.
Наверное, это красивая составляющая меш-сетей: предъявлять некому, потому что меш — общая децентрализованная технология, держащаяся на плечах тысяч и миллионов пользователей.
В официальном списке сервисов всего две Wiki: англоязычная полумертвая и приведенная выше :) А вот IRC-чатов во истину много, глаза разбегаются. На многие заходил, где-то активность хорошая. В частности, русскоязычное сообщество более всего восседает в ILITA IRC.
Попытка упростить быстрый старт: В статью добавлена ссылка на внутрисетевую викию "HowToYgg" под заголовком "Начало использования". Кладезь информации от русскоязычного сообщества.