Псевдоузел и предполагаемые векторы атак в сети

Большое количество взаимосвязанных псевдоузлов значительно упрощает запуск атаки с исчерпанием полосы пропускания. Bitcoin Core проверяет большую часть информации перед ее передачей, но псевдо-узлы не проверяют ее, поэтому, если вы можете соединить несколько псевдо-узлов вместе, вероятно, легко заставить их тратить тонны полосы пропускания, ретранслируя ненужные данные друг другу. а потом и своим сверстникам.

Например, если имеется 101 псевдоузел (PN), соединенных вместе, вы можете отправить PN1 действительно выглядящий invпакет , объявляющий об одной поддельной транзакции (около 61 байта плюс служебные данные TCP-пакета). Каждый PN ретранслирует это invкак минимум на 6100 потерянных байтов загрузки.

Но эти PN также подключены к реальным узлам. Допустим, 500 реальных узлов, так что теперь потерянная пропускная способность загрузки PN составляет 36 600 байт (плюс накладные расходы TCP) — и все потому, что злоумышленник создал один 61-байтовый файл inv. Хуже того, настоящие узлы будут запрашивать транзакцию, используя 61-байтовый getdataпакет , что приведет к потере 30 500 байт пропускной способности загрузки реального узла.

Если злоумышленник отправляет 1 МБ поддельных данных в секунду в течение всего дня, он использует 86 гигабайт собственной пропускной способности, но теряет 52 терабайта совокупной пропускной способности загрузки PN и, возможно, 43 терабайта пропускной способности загрузки реального узла.

(В зависимости от того, как написаны PN, они могут тратить еще больше пропускной способности на ретрансляцию getdataпакета.)

Сравните это со стоимостью проведения атаки на один реальный узел. На каждый 61-байтовый invпакет, загружаемый злоумышленником, реальный узел отвечает, загружая один 61-байтовый файл getdata. Таким образом, атака с исчерпанием полосы пропускания против реального узла требует примерно 1:1 потерянной полосы пропускания. Реальный узел не ретранслирует дальше, invпока не получит и не подтвердит транзакцию, на которую он ссылается, поэтому никакой другой узел не теряет пропускную способность.

Есть ли в протоколе возможные непредвиденные обстоятельства для разграничения между PN и узлом? Например, будут ли разные версии Bitcoincore идентифицировать PN (или простую модификацию протокола)?

В протоколе уже есть понятие оценки блокировки DoS, в которой каждый узел Bitcoin Core присваивает частную оценку каждому из своих пиров за любое плохое поведение, которое они совершают. Как только оценка запрета DoS для определенного узла достигает порогового значения (по умолчанию 100), узел отключается от узла и отказывается от дальнейших подключений со своего IP-адреса на некоторое время (один день по умолчанию). Плохое поведение включает в себя отправку недопустимых транзакций и блоков.

Поскольку PN не проверяют данные, они с радостью передают неверные данные. Если они станут обычным явлением, кто-то, кто хочет навредить PN, может просто подключиться к любому объявленному узлу и отправить ему кучу неверных данных. Если это был настоящий полный узел, он отключится (DoS-бан). Если бы это был PN, он передал бы эти данные на настоящие полные узлы, в результате чего настоящие полные узлы запретили бы их DoS. Это сделало бы PN бесполезным и позволило бы гриферу определить, какие узлы являются PN — грифер мог бы затем опубликовать (неаутентифицируемую) базу данных IP-адресов PN.

Этот метод лучше всего работает против долгосрочных PN. Чтобы затруднить выполнение краткосрочных атак Sybil из множества облегченных PN, можно использовать что-то вроде доказательства хранилища Грега Максвелла, чтобы сделать потребление распределенных ресурсов дорогостоящим .