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-роутер. Сколько бы ни ждал – мой компьютер не может найти входящие туннели заданной конечной точки. Если следить за работой роутера на уровне дебага, можно увидеть, что лизсет все-таки приходит. Однако его содержимое так и останется тайной.

Аналогичным образом ограничение может быть наложено администратором ресурса. Если обиженный пользователь захочет навести небесную кару на триклятого админа – у него не получится. Даже знание адреса ничем не поможет.

Сейчас опция с авторизацией доступна только для отдельных туннелей. В основном пользовательском прокси, обычно используемом для серфинга сети, параметр отсутствует. Однако, в скором будущем такая возможность должна появиться. Это позволит использовать приватные ресурсы без дополнительных хлопот, лишь единожды указав свой ключ в основном конфигурационном файле роутера.

Доступ к сайту по ключу. Защита от непрошеных гостей в I2P