[Криптография, Сетевые технологии, I2P, Стандарты связи] Доступ к сайту по ключу. Защита от непрошеных гостей в I2P
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
DDoS (атака типа «отказ в обслуживании») – распространенная модель досаждения конкурентам. Самый простой ее вариант – максимальная загрузка сетевого канала, чтобы настоящие пользователи либо не могли достучаться до сервера, либо получали раздражающие задержки. Более толковый подход – искусственная нагрузка на сервисы, которые охотно потребляют ресурсы сервера. Например, шквал запросов, вызывающих обращение к базе данных и прочие ресурсоемкие вычислительные операции, которые перегружают машину.Существует много сервисов, задача которых заключается в защите клиентов от подозрительной сетевой активности извне. Как правило, они раскрывают и анализируют даже зашифрованный трафик, а также проводят некоторые аналитические действия с браузером пользователя, чтобы наверняка распознать злонамеренную нагрузку. В итоге злоумышленник получает капчу, либо вовсе не имеет возможность обратиться к целевому ресурсу.Как быть со скрытыми сетями, где пользователи не имеют IP-адреса, а анализ зашифрованного трафика неприемлем на уровне концепции технологии? В этой статье рассмотрим уникальный способ защиты от DDoS-атаки в сети I2P и в целом разберем технологию лизсетов с авторизацией.Материал статьи является логическим продолжением темы про зашифрованные лизсеты, которые служат дополнительным инструментом приватности скрытого ресурса. Для связи с анонимным сайтом I2P-роутер обращается к некоему справочному узлу, который возвращает лизсет – информацию о ключах шифрования и входящих туннелях сервиса. Это означает, что держатель флудфила (справочного узла) может узнать о вашем ресурсе путем простого наблюдения за лизсетами, которые на нем опубликовали. Использование зашифрованного лизсета предотвращает такую возможность.К такому ресурсу нельзя привязать человекочитаемый короткий адрес в зоне «.i2p», поэтому опция не является широко применимой, а используется только при действительной необходимости. Однако, остановиться на зашифрованном лизсете было бы нелогично: что делать, если вы скрываете свой ресурс, но в конце концов его адрес разгласит один из доверенных пользователей? В итоге получится, что приватный сервис, который администратор пытался спрятать, снова попадает под возможную DDoS-атаку и прочие теоретические неприятности.Апогеем темы является зашифрованный лизсет с авторизацией, который возможно расшифровать, имея персональный ключ помимо полного адреса. Эта концепция является уникальной в своем роде, т.к. позволяет администратору огородиться от злонамеренных пользователей на уровне протокола сети.Только вдумайтесь: защита от всевозможных атак не силами файрвола, настройками сервера, капчей и прочих сторонних сервисов, а на уровне самой сети. Пользователь, не допущенный администратором, не сможет обратиться к серверу, потому что не получил лизсет, в котором хранится информация о входящих туннелях скрытого ресурса. Следовательно, ни о каких атаках речи быть не может – ресурс существует вне досягаемости атакующего.Протоколом I2P предусмотрено два типа авторизации лизсетов: по паролю и по ключу. Пароль является более простым способом, однако не сильно сложнее использования настоящей криптографии. Ключи по безопасности многократно превосходят пароли, так как исключают даже умозрительную вероятность успешного брутфорса. Пароли для уважаемого джентльмена – это моветон.От слов к делуКлючи шифрования генерируются клиентом, после чего публичный ключ сообщается администратору целевого ресурса. Сервер шифрует лизсет каждым публичным ключом из списка. При получении зашифрованного лизсета пользователь пробует применить свой секретный ключ. Если публичный ключ пользователя не использовался при шифровании – лизсет остается нераскрытым.
Минимальная конфигурация туннеля с зашифрованным лизсетом и авторизацией выглядит так:
[SUPER-HIDDEN-SERVICE]
type = server
host = 127.0.0.1
port = 8080
inport = 80
keys = site.dat
signaturetype = 11
i2cp.leaseSetType = 5
i2cp.leaseSetAuthType = 1
i2cp.leaseSetClient.dh.NNN = User:PublicKey
В параметре i2cp.leaseSetClient.dh.NNN = User:PublicKey
- NNN – случайное целое число (нужно для указания нескольких ключей)
- User – имя или никнейм пользователя для удобства администратора (можно не указывать)
- PublicKey – публичный ключ в кодировке base64
Как использовать пароль вместо ключейЕсли параметру i2cp.leaseSetAuthType присвоить значение «2», будет использоваться авторизация по паролю. Последний параметр также изменится: i2cp.leaseSetClient.psk.NNN = User:Password. Пароль указывается в кодировке base64 и будет одинаков на обеих сторонах.В лизсетах с авторизацией используются ключи шифрования x25519, которые можно получить при помощи одноименной утилиты в i2pd-tools.
В клиентском туннеле, то есть на стороне пользователя, необходимо указать только один дополнительный параметр i2cp.leaseSetPrivKey = PrivateKey, содержащий приватный ключ в кодировке base64. 
Для наглядности эксперимента я закомментировал ключ на клиентской стороне и перезапустил I2P-роутер. Сколько бы ни ждал – мой компьютер не может найти входящие туннели заданной конечной точки. Если следить за работой роутера на уровне дебага, можно увидеть, что лизсет все-таки приходит. Однако его содержимое так и останется тайной.
Аналогичным образом ограничение может быть наложено администратором ресурса. Если обиженный пользователь захочет навести небесную кару на триклятого админа – у него не получится. Даже знание адреса ничем не поможет.Сейчас опция с авторизацией доступна только для отдельных туннелей. В основном пользовательском прокси, обычно используемом для серфинга сети, параметр отсутствует. Однако, в скором будущем такая возможность должна появиться. Это позволит использовать приватные ресурсы без дополнительных хлопот, лишь единожды указав свой ключ в основном конфигурационном файле роутера.Оригинальная статья опубликована в блоге дата-центра ITSOFT.
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование, Сетевые технологии] Делегирование почтовых папок и отправки писем в Zimbra OSE
- [Информационная безопасность, Криптография, Софт, Криптовалюты] Практическое руководство по анонимности в онлайне
- [Сетевые технологии, Реверс-инжиниринг, Разработка на Raspberry Pi, Сетевое оборудование, Игры и игровые приставки] Хакер создал сетевой адаптер для оригинального Game Boy
- [Информационная безопасность, Системное администрирование, Сетевые технологии] 5. Континент 4 Getting Started. Обнаружение и предотвращение вторжений (IDS/IPS)
- [Сетевые технологии, Беспроводные технологии, Разработка систем связи, Научно-популярное, Космонавтика] Всё о проекте «Спутниковый интернет Starlink». Часть 31. Сравнения сервиса StarLink с сервисами других операторов ШПД/
- [Сетевые технологии, Машинное обучение, Робототехника, Искусственный интеллект] OpenAI — SkyNet от Илона Маска. Разбор
- [Информационная безопасность, Криптография, DNS] Cloudflare пообещал избавить пользователей от каптчи системой ключей безопасности
- [Сетевые технологии, Беспроводные технологии, Разработка систем связи, Интернет вещей] Гетерогенные PLC/RF модемы для систем сбора данных
- [Информационная безопасность, Криптография] Хакерские форумы запретили рекламу и обсуждения вирусов-криптовымогателей
- [Криптография, I2P] Безопасное хранение ключей от сервиса в I2P
Теги для поиска: #_kriptografija (Криптография), #_setevye_tehnologii (Сетевые технологии), #_i2p, #_standarty_svjazi (Стандарты связи), #_leaseset, #_x25519, #_blog_kompanii_itsoft (
Блог компании ITSOFT
), #_kriptografija (
Криптография
), #_setevye_tehnologii (
Сетевые технологии
), #_i2p, #_standarty_svjazi (
Стандарты связи
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:47
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
DDoS (атака типа «отказ в обслуживании») – распространенная модель досаждения конкурентам. Самый простой ее вариант – максимальная загрузка сетевого канала, чтобы настоящие пользователи либо не могли достучаться до сервера, либо получали раздражающие задержки. Более толковый подход – искусственная нагрузка на сервисы, которые охотно потребляют ресурсы сервера. Например, шквал запросов, вызывающих обращение к базе данных и прочие ресурсоемкие вычислительные операции, которые перегружают машину.Существует много сервисов, задача которых заключается в защите клиентов от подозрительной сетевой активности извне. Как правило, они раскрывают и анализируют даже зашифрованный трафик, а также проводят некоторые аналитические действия с браузером пользователя, чтобы наверняка распознать злонамеренную нагрузку. В итоге злоумышленник получает капчу, либо вовсе не имеет возможность обратиться к целевому ресурсу.Как быть со скрытыми сетями, где пользователи не имеют IP-адреса, а анализ зашифрованного трафика неприемлем на уровне концепции технологии? В этой статье рассмотрим уникальный способ защиты от DDoS-атаки в сети I2P и в целом разберем технологию лизсетов с авторизацией.Материал статьи является логическим продолжением темы про зашифрованные лизсеты, которые служат дополнительным инструментом приватности скрытого ресурса. Для связи с анонимным сайтом I2P-роутер обращается к некоему справочному узлу, который возвращает лизсет – информацию о ключах шифрования и входящих туннелях сервиса. Это означает, что держатель флудфила (справочного узла) может узнать о вашем ресурсе путем простого наблюдения за лизсетами, которые на нем опубликовали. Использование зашифрованного лизсета предотвращает такую возможность.К такому ресурсу нельзя привязать человекочитаемый короткий адрес в зоне «.i2p», поэтому опция не является широко применимой, а используется только при действительной необходимости. Однако, остановиться на зашифрованном лизсете было бы нелогично: что делать, если вы скрываете свой ресурс, но в конце концов его адрес разгласит один из доверенных пользователей? В итоге получится, что приватный сервис, который администратор пытался спрятать, снова попадает под возможную DDoS-атаку и прочие теоретические неприятности.Апогеем темы является зашифрованный лизсет с авторизацией, который возможно расшифровать, имея персональный ключ помимо полного адреса. Эта концепция является уникальной в своем роде, т.к. позволяет администратору огородиться от злонамеренных пользователей на уровне протокола сети.Только вдумайтесь: защита от всевозможных атак не силами файрвола, настройками сервера, капчей и прочих сторонних сервисов, а на уровне самой сети. Пользователь, не допущенный администратором, не сможет обратиться к серверу, потому что не получил лизсет, в котором хранится информация о входящих туннелях скрытого ресурса. Следовательно, ни о каких атаках речи быть не может – ресурс существует вне досягаемости атакующего.Протоколом I2P предусмотрено два типа авторизации лизсетов: по паролю и по ключу. Пароль является более простым способом, однако не сильно сложнее использования настоящей криптографии. Ключи по безопасности многократно превосходят пароли, так как исключают даже умозрительную вероятность успешного брутфорса. Пароли для уважаемого джентльмена – это моветон.От слов к делуКлючи шифрования генерируются клиентом, после чего публичный ключ сообщается администратору целевого ресурса. Сервер шифрует лизсет каждым публичным ключом из списка. При получении зашифрованного лизсета пользователь пробует применить свой секретный ключ. Если публичный ключ пользователя не использовался при шифровании – лизсет остается нераскрытым.  Минимальная конфигурация туннеля с зашифрованным лизсетом и авторизацией выглядит так: [SUPER-HIDDEN-SERVICE]
type = server host = 127.0.0.1 port = 8080 inport = 80 keys = site.dat signaturetype = 11 i2cp.leaseSetType = 5 i2cp.leaseSetAuthType = 1 i2cp.leaseSetClient.dh.NNN = User:PublicKey
 В клиентском туннеле, то есть на стороне пользователя, необходимо указать только один дополнительный параметр i2cp.leaseSetPrivKey = PrivateKey, содержащий приватный ключ в кодировке base64.  Для наглядности эксперимента я закомментировал ключ на клиентской стороне и перезапустил I2P-роутер. Сколько бы ни ждал – мой компьютер не может найти входящие туннели заданной конечной точки. Если следить за работой роутера на уровне дебага, можно увидеть, что лизсет все-таки приходит. Однако его содержимое так и останется тайной.  Аналогичным образом ограничение может быть наложено администратором ресурса. Если обиженный пользователь захочет навести небесную кару на триклятого админа – у него не получится. Даже знание адреса ничем не поможет.Сейчас опция с авторизацией доступна только для отдельных туннелей. В основном пользовательском прокси, обычно используемом для серфинга сети, параметр отсутствует. Однако, в скором будущем такая возможность должна появиться. Это позволит использовать приватные ресурсы без дополнительных хлопот, лишь единожды указав свой ключ в основном конфигурационном файле роутера.Оригинальная статья опубликована в блоге дата-центра ITSOFT. =========== Источник: habr.com =========== Похожие новости:
Блог компании ITSOFT ), #_kriptografija ( Криптография ), #_setevye_tehnologii ( Сетевые технологии ), #_i2p, #_standarty_svjazi ( Стандарты связи ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:47
Часовой пояс: UTC + 5