Pascal's Homepage

Децентрализованный веб против DDoS Интернет / Информационные технологии / Избранное / 10.01.2017


На дворе 21 век. Интернет процветает. Создано уже почти всё, что только можно себе представить. Почти для любой задачи в интернете есть готовый софт. Есть спрос на обмен большими файлами - сделали торренты. Есть спрос на анонимность в вебе - сделали tor. И заметьте, это примеры сложного софта который доступен любому человеку абсолютно бесплатно. Но есть одна проблема принципиальным решением которой почему-то никто не озадачивается. А именно - пробелма ддоса. Вернее ей очень даже озадачиваются, особенно те, кого атакуют. Но никто не решает эту проблему в корне. На ддосе все только зарабатывают. Зарабатывают те кто ддосит и те, кто предоставляет защиту от ддоса. С каждым годом проблема с ддосом всё более усугубляется и доставляет всё больше убытков. От ддоса терпит убытки даже средний бизнес. Почти любой сайт/бизнес который активно работает в интернете хотябы раз подвергался ддосу. При этом такие организации как W3C, IETF молча закрывают на это глаза и бездействуют. Проблему ддоса хотябы частично можно решить техническим путём, что в компетенции вышеуказанных организаций. Ведь можно разработать стандарты/протоколы позволяющие устранить ддос принципиально, как явление.

Есть такая хорошая фраза "Критикуя предлагай". Так вот, у меня появилась идея как можно решить эту проблему. В последнее время набирают обороты различные децентрализованные технологии, такие как tor и bitcoin. Причём сложные, как на уровне протокола, так и в реализации. Это вам не текстовый HTTP сервер под который накодит даже студент :) В общем, я думаю, чтобы побороть ддос хотябы в вебе - надо этот веб сделать децентрализованным. Надо сделать так, чтобы сайт был разбросан по всему интернету, т.е. по множеству других сайтов. Картинки, css-стили, яваскрипты - все они должны быть разбросаны случайным образом по случайным серверам. Со статическим контентом всё просто, а как-же быть с серверными скриптами? На самом деле и серверные скрипты вполне можно разбрасывать по интернету. Например, вы написали свой движок на php, упаковали его скрипты в PHAR-архив и дальше уже этот архив можно разбрасывать по интернету. Базы данных сайта можно хранить, например, в виде файлов sqlite которые опять-же разбрасывать. А что если в БД приватные данные? Например паспортные данные? В этом случае клиент должен шифровать и подписывать свои приватные данные на стороне браузера. Например ФИО можно зашифровать браузерным яваскриптом публичным ключём клиента и публичным ключём админа. Т.е. в БД ФИО будет храниться в двух экземплярах - зашифрованным ключём клиента и ключём админа. Это конечно повышает расход дискового пространства, но диски-то сейчас многотерабайтные. Да и некоторые данные доступные публично (например комментарии) можно совсем не шифровать а только подписывать их ключём клиента. Проект сложный и на пути к его реализации нужно решить много проблем. А что в этом мире легко? Двигать прогресс было тяжело всегда. Итак, предлагаю на конкретном примере рассмотреть процесс загрузки браузером сайта сделанного по децентрализованной технологии. Предполагается, что читатель уже знаком с процессом загрузки сайта в обычном случае.

  1. Начнём с малого. DNS-запрос.
    Итак, рядовой посетитель Вася Пупкин заходит на сайт mygreatblog.ru. Вася знать не знает что такое децентрализованный веб и для него наш сайт выглядит точно так-же как и остальные. Никаких плагинов и прочего софта Вася на свой комп не устанавливал. Первым делом браузер Васи делает dns-запрос A-записи сайта mygreatblog.ru. В ответ браузеру прилетает DNS-ответ сразу с несколькими A-записями, т.е. с несколькими ip-адресами. Браузер может подключиться к любому ip-адресу, но на всех них сайт один. То-же самое происходит со всеми крупными сайтами, например vk.com, yandex.ru, google.com и т.д. В общем для выбора сервера я предлагаю использовать round robin dns которым мы сами того не зная пользуемся каждый день.
  2. IP-адрес сайта определён. Ура. Теперь браузер делает HTTP-запрос индексной страницы:
    GET / HTTP/1.0
    Host: mygreatblog.ru
    И тут возникает вопрос: а откуда на сервере с этим ip-адресом взялся наш сайт? Ответ: а целиком сайта на нём и нет. На данном сервере имеется только PHAR-архивчик со скриптами сайта и sqlite-база с данными сайта. Скрипт из PHAR-архива отдаёт браузеру HTML-страницу статический контент в которой имеет ссылки с абсолютно рандомно взятыми именами хостов. Например пусть заголовок сайта подгрузится отсюда http://somebody.com/decentralized-web/mygreatblog.ru/static-content/images/header.jpg
    Статический контент, PHAR-архивы и sqlite-базы были заранее разосланы по сайтам использующем данную технологию.
  3. Вася Пупкин читает статью и без регистрации (анонимно) оставляет свой комментарий. Браузер Васи вызывает на сервере скрипт из PHAR-архива и его комментарий записывается в локальную sqlite-базу изменения в которой рассылаются по остальным серверам.
  4. Васе Пупкину понравился наш блог и он решил зарегистрироваться, чтобы писать комментарии от своего имени. Однако форма регистрации в нашем блоге необычная. Вместо классического пароля сайт генерирует приватный ключ и убедительно просит Васю сохранить его в надёжном месте. В последующем вместо пароля для авторизации на сайте Вася должен будет ввести свой приватный ключ.
  5. У Васи есть тайна, которой он не хочет делиться со всем миром а рассказать её может только админу сайта которому он доверяет. А тайна эта - его номер телефона. Как обычно, при заполнении анкеты на сайте Вася указывает номер телефона. Но он (номер телефона) шифруется прямо в браузере публиыным ключём Васи и публиыным ключём админа. В зашифрованном виде телефон отправляется в sqlite-базу и рассылается по остальным серверам. И если недобросовестный участник сети децентрализованных сайтов решит посмотреть содержимое sqlite-базы то увидит только два зашифрованных блока данных расшифровать которые не сможет. Если вы не очень хорошо разбираетесь в методах шифрования то напомню, что публичный ключ можно выделить из приватного ключа.
  6. !!ВНИМАНИЕ!! Негодяи атакуют наш сайт mygreatblog.ru http-флудом! Что делать? Ничего не делать :) Децентрализованный веб регулируется автоматически. Серверные скрипты в нашем PHAR-архиве обнаружили ненормально высокую нагрузку и послали сигнал бедствия соседним серверам. Соседние серверы обращаются к атакуемому серверу и видят что он не отвечает или отвечает медленно. В этом случае атакуемый ip-адрес автоматически убирается из DNS а все данные которые есть на нём копируются на ip-адреса других серверов. Плюс новые ip-адреса добавляются в DNS. Один ip-адрес накрыло ддосом - система скопировала сайт на 2 сервера. Таким образом чем злее ддосер и чем больше ip-адресов он атакует тем на большее количество серверов раскидывается сайт. Если сеть децентрализованных сайтов большая то ддосер просто не сможет атаковать целую кучу ip-адресов.

Вцелом как-то так. Но чтоб всё это сделать нужно решить много сложностей:

  1. Допустим я хочу выложить свой сайт в сеть децентрализованных сайтов. Какие DNS-серверы мне прописать своему домену? Как другие сайты будут добавлять свои ip-адреса на DNS-серверы моего хостера?
  2. Вопрос распределения ресурсов. Допустим у меня есть хостинг с 10гб дискового пространства. Сколько места я должен отдать сети и на сколько гигабайт я могу претендовать на серверах других участников сети?
  3. Если на сайте и без ддоса высокая нагрузка то как с ней должна справляться сеть? Как отличить легальную высокую нагрузку от ддоса? Могут появиться халявщики не желающие покупать серверы, выдавать высокую нагрузку за ддос и справляться с ней за счёт сети.
  4. Как быть с безопасностью сайта? Недобросовестные админы могут подменить мой PHAR или вставить вредоносный код в яваскрипты сайта. Решение этой проблемы мне видится в списке контрольных сумм файлов сайта. Допустим, админ загрузил сайт на 10 серверов а при посещении сайта браузерный яваскрипт сверяет контрольные суммы скаченных им файлов с остальными 10 серверами. Если с одного из серверов получен изменённый файл то такому серверу ставится минус к репутации а контент подгружается с другого сервера.

Придётся писать целую кучу софта. Придётся вкорне менять подход к разработке сайта, писать яваскриптовые и серверные апи чтобы другие программисты посредством них могли разрабатывать сайты под децентрализованный веб. Радует то, что всю эту систему можно сделать разными способами. Даже реализовать работу с DNS можно разными способами. Можно написать скрипты которые будут поддерживать работу с основными панелями управления хостингом (cPanel, ISPmanager). Можно написать какой-то софт для установки на сервер (например если у вас не шаред а vps) или вообще написать пакет софта для хостинга.

Ресурсы сети должны распределяться по принципу "сколько берёшь, столько отдаёшь". Если файлы сайта весят 20мб а БД 30мб то суммарно ваш сайт занимает 50мб. Размещение сайта на 10 серверах потребует от сети 500мб дискового пространства. Поэтому вы должны быть готовы отдать 500мб своего дискового пространства другим участникам сети. Если на ваш сайт заходит много посетителей, то ваш сервер должен мочь обработать столько-же посетителей для других сайтов сети. На протяжении некоторого времени (например 7 дней) сеть подсчитывает среднюю посещаемость вашего сайта. Ддосом считается резкое повышение нагрузки на сайт которое приводит к падению некоторых серверов. Каким-то образом (каким - ещё не придумал) надо определять какое время сеть будет терпеть ддос-атаку на конкретный сайт. Я думаю, если сеть будет достаточно надёжно отбивать ддос то у ддосера быстро исчезнет желание беспорядочно атаковать кучу разных ip-адресов. Один ip заддосил - появилось несколько других. Рядового ддосера это будет быстро выматывать, но профессионалы точно будут как-то пытаться автоматизировать атаку. Вероятно, такая сеть не получит большого распространения среди высоконагруженных проектов, но зато сайты с неочень высокой посещалкой будут спасены. Ддос бывает и не на сайты а на другие сервисы. Но для начала предлагаю решить проблему с вебом а потом уже будем думать об остальном.

Комментарии

Ник:
E-mail: 
URL:
Ваш комментарий:

Комментариев нет. Ваш будет первый.