LINUX.ORG.RU

В общем случае, если каждый клиент обслуживается отдельно и невозможно отличить злоумышленника от нормального клиента, задача нерешаема.

Я думаю, менее подвержена такой атаке схема с предварительной подпиской на обновление базы торрентов, когда трекер сам рассылает обновления ранее подписавшимся пользователям. При использовании такой схемы в случае DDoS очень просто закрыть подписку для новых абонентов и обслуживать только ранее подписавшихся.

Альтернативный вариант — распределённые P2P-сети, каждый клиент которых является мини-трекером (Freenet бы подошёл). Такую сеть чисто физически тяжело заDDoSить, т.к. для этого пришлось бы заDDoSить большинство узлов сети.

Sadler ★★★
()
Последнее исправление: Sadler (всего исправлений: 3)

Какой-нибудь Freenet.

Medar ★★★★★
()

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

abraziv_whiskey ★★★★★
()

как говорится самая надежная связь - «половая»

nexus86
()
Ответ на: комментарий от Sadler

ранее подписавшимся пользователям.

Ранее подписаться могут и боты. Я где-то видел левые аккаунты нареганые «впрок».

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Может помочь фильтр пользователей по их активности

dartvedroid
() автор топика
Ответ на: комментарий от true_admin

Ранее подписаться могут и боты.

Ну и ладно. Суть не в том, чтобы избежать ботов. Суть в том, чтобы не прекращать обслуживание старых абонентов, т.к. среди них количество ботов точно меньше, чем среди новичков.

Плюс в такой схеме возможна широковещательная рассылка, которая проводится ровно один раз сразу для всех абонентов, независимо от их количества.

Sadler ★★★
()
Последнее исправление: Sadler (всего исправлений: 1)
Ответ на: комментарий от Sadler

А как устроена рассылка, обновление базы, закрытие подписки? Т.е. (пусть примером будет рутрекер) в случае ддоса, как я понял, трекер переходит на Реад Онли режим и отсылает всю свою базу на почту юзерам? Новые раздачи не создать, комментарии не запилить?

dartvedroid
() автор топика
Ответ на: комментарий от dartvedroid

Новые раздачи не создать, комментарии не запилить?

Необязательно. Так мы избавляемся от основной нагрузки, связанной с поиском и скачиванием торрентов. Все более редкие события, вроде создания новых торрентов и комментирования, могут работать по гибридной схеме и дополнительно модерироваться вручную. Хотя, имхо, комментарии — это вообще не задача трекера, их можно отдать на откуп третьих лиц, вроде соц. сетей.

Sadler ★★★
()

сайт лежит, но трекер вроде работает, + есть lpd

wakuwaku ★★★★
()
Ответ на: комментарий от Sadler

В этих рассуждениях есть слабое звено - предположение о том, что ложимся мы из-за нагрузки на аппликацию.

Однако, существует еще одна точка отказа - толщина канала. Даже если наш сервак будет идеально отличать ботов и давать им отлуп, какая-нибудь атака в десяток - другой гигабит начисто забьет мощности доступные простым сайтам и сервисам, не гигантам вроде гугла и яндеха.

Лично мне не видится никакого решения такой проблемы при современной архитектуре интернета. Более того, даже i2p тут не спасет. Тут выход только распределять данные по всей сети - freenet.

DiKeert ★★
()
Ответ на: комментарий от DiKeert

Однако, существует еще одна точка отказа - толщина канала.

В этой точке есть лишь один очевидный способ уменьшения влияния DDoS'а — наращивать ширину канала. Распределённые сети — это из той же оперы. Поэтому рассматривать это не очень интересно.

Sadler ★★★
()
Ответ на: комментарий от DiKeert

По опыту спамхауса, если система распределена правильно, то подобная атака забьёт канал не только вам, но и всем остальным, отчего вам будет не так обидно.

ya-betmen ★★★★★
()

Есть ли архитектура сети устойчивая к ддосу?

Loopback

Pavval ★★★★★
()

Часто достаточно сделать две сотни зеркал в разных странах мира, поддерживаемых добровольцами.

Deleted
()

Есть вот такие интересные технологии: http://en.wikipedia.org/wiki/Proof-of-work_system.

Вкратце суть идеи: сделать формирование запроса к серверу не дармовой операцией, а чтобы на это надо было потратить некоторые выч. ресурсы. При этом подобрать сложность вычислительной задачи такой, чтобы при «нормальной» эксплуатации сервиса это было не тяжелой «ношей» для клиента. А вот возможность штормов запросов свела к очень дорогой (= невыгнодной) операции.

Sectoid ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.