Технология блокчейн для веб-приложений

Блокчейн как база данных обладает рядом замечательных свойств, среди которых на обывательском уровне выделяются:

• невозможность изменить запись в этой базе данных;
• распределенный характер.

«Почему бы нам не применить эти замечательные свойства к веб-приложениям», - задумались мы, и оказались не единственными. На блокчейн-форумах регулярно поднимается эта тема (например:[1],[2],[3]найдено по поиску за 10 минут), и даже рассматривается экспертами[4].

Считается, что первое свойство позволит обезопасить веб-сайт от взлома, а второе – от DDoS-атак (Distributed Denial of Service – распределенный отказ в обслуживании). Мы разработали технологию блокчейн-сайтов, которая с конца 2018 г. нашла коммерческое применение.

1. Вектор риска

1. Киберугрозы

По запросу «как взломать сайт» Яндекс выдаст 45 млн результатов и 750 тыс.видео. Что более интересно, на протяжении 2017-2018 г.г. эту фразу искали от 16 до 26 тыс. пользователей поисковой системы – спрос не иссякает! Да, они найдут сперва «детские» инструкции как пользоваться SQL-инъекциями с помощью программ, загруженных с просторов интернета. Но даже если 5% от этой массы праздно интересующихся продолжат с практическими примерами, мы получим порядка 800-900 человек, которые приступили к тренировкам – а это уже заметное количество и заметный риск, в первую очередь для веб-ресурсов, которые находятся «на виду». Это правительственные сайты, СМИ, поисковые системы, банки, маркетплейсы и «доски объявлений».

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

Например, в сентябре 2018 г. на выборах в Свердловской области была зафиксирована DDoS-атака на сервер Избирательной комиссии[5], но системные администраторы ГБУ «Оператор электронного правительства» не смогли ей эффективно противостоять.

В 2018 г. с мая по декабрь почти 28 млрд попыток злоупотребления учетными данными пользователей зарегистрировала компания Akamai, уточнив, что e-Commerce стала наиболее частотной целью атак (10 млрд)[6].

Сбербанк отметил, что в 2018 г. по сравнению с 2017 г. число DDoS-атак высокой мощности возросло в 1,5 раза[7].

Классифицируем векторы риска.

1. Взлом веб-ресурса

«Взлом сайта» - понятие аморфное. «Меня взломали» говорят, когда на сайте подменили главную страницу, или когда посетителя веб-сайта переадресуют на страницу с порно, а еще – когда с сайта украли личные данные пользователей – как это было уже с тысячами сайтов по всему миру, включая Facebook, Adobe и прочих. Эти явления, а также иные, могут быть сгруппированы следующим образом, начиная с формы их проявления:

1. DoS / DDoS

(Распределенный) отказ в обслуживании – один из наиболее распространенных приемов блокировки ресурсов, состоящий в создании такого числа и объема запросов, при котором атакуемый ресурс будет недоступен для обычных пользователей, или по крайней мере доступ к нему будет существенно затруднен. Основные направления атаки:

• переполнение полосы пропускания – flood-атаки;
• атаки, нацеленные на захват системных ресурсов (оперативной и (или) физической памяти, ресурсов процессора;
• атаки, нацеленные на DNS-сервера.

Мощность DDoS-атак измеряется в Гбит/с или числе соединений в секунду. Наиболее известные атаки – на сервис CloudFare (65 Гбит/с) в 2012 г., на Spamhouse (120-300 Гбит/с) в 2013 г.

Считается, что полностью защититься от DoS/DDoS атак невозможно [10].

1. Угрожаемые ресурсы и способы атаки на них

Суммируя предыдущее, видим, что:

• взлом, как правило, состоит в загрузке определенных скриптов, которые будут исполняться на самом сервере или на стороне клиента, замене или дополнении содержимого файлов и базы данных информацией злоумышленника, чтении содержимого файлов или базы данных;
• DoS/DDoS, как правило, состоит в создании нагрузки на один или несколько процессов, что делает их недоступными, или переполнение полосы пропускания интернет-канала.

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

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

Мы намеренно разделили сервер системы администрирования (3) и сервер веб-приложения (5), хотя в большинстве классических сайтов CMS (content management system) объединена с самим сайтом. В то же время это идеологически различные системы: первая – приватная, вторая – публичная. Первая позволяет изменять содержание веб-ресурса (и в ряде случаев менять верстку и внедрять скрипты, исполняемые на стороне клиента и на стороне сервера). Вторая предназначена для доставки пользователям контента и предоставления им определенных сервисов, в том числе редактировать собственные данные пользователя. И как раз эти данные, а также возможность выполнять действия от имени пользователя, являются наиболее «лакомой» добычей.

Публичная сеть (интернет) практически не поддается контролю, поэтому общепринятой практикой является обеспечение невозможности чтения данных начиная с сетевой инфраструктуры сервера и до сетевой инфраструктуры клиента. В части противодействия DDoS-атакам на DNS-инфраструктуру, атакуемые веб-ресурсы мало что могут сделать – разве что поддерживать собственный DNS-сервер со всеми вытекающими.

1. «Классические» веб-сайты

Мы считаем, что частично за столь существенные риски взлома и DDoSна базовом уровне ответственна сама концепция веб-сайтов. Как правило, веб-ресурс рассматривается как нечто не зависящее от публичной интернет-инфраструктуры (например, DNS), а также – часто – и не зависящее от хостинга. В последнем случае часть моральной ответственности лежит на хостинг-провайдерах, которые в угоду прибыли предоставляют пользователям виртуальный хостинг, самостоятельно его администрируют и позволяют как владельцам и администраторов сайтов, так и веб-разработчикам просто не думать о качестве сетевой инфраструктуры, настроек и администрирования сервера.

«Классический» веб-сайт обслуживают множество процессов. Рассмотрим распространенную конструкцию вебсайта, написанного на языке PHP и размещенного на хостинге под управлением ОС Linux:

• веб-сервер Apache или связка Nginx+Apache. Веб-сервер Apache через расширение php*.so связан с интерпретатором PHP;
• сервер баз данных MySQL;
• почтовый сервер (например, sendmail или Postfix) – как правило, авторы сайтов пользуются функцией PHP mail(), которая требует наличия внешнего процесса;
• набор PHP скриптов – файлы, сохраненные на жестком диске, и которые интерпретатор PHP должен прочитать с жесткого диска и обработать;
• набор файлов jаvascript, CSS и изображений, которые необходимо прочитать и передать на сторону клиента при обращении к ним.

Как видим, одно соединение поддерживают суммарно 4 или 5 разных процессов, и их число увеличивается при каждом новом соединении. Каждое соединение сопровождается большим числом операций чтений файлов, перекрестных обращений к разным сервисам, которые занимают оперативную память и требуют ожидания основного процесса, пока не будет получен ответ на промежуточном этапе. Это время ожидания усугубляется тем, что разработчики на языке PHP редко используют многопоточность – хотя соответствующее решение имеется[8]. Как результат, одно соединение обрабатывается очень долго. В хорошем случае это могут быть десятки миллисекунд, но часто время ответа превышает и секунду, и три.

Большое число процессов = занятая память и процессорное время (ведь процессор занят не только тем, что обрабатывает сайт, – существуют еще и поддерживающие процессы).

Большое число процессов = расходы на транспорт и логирование данных. При этом популярные в последнее время микросервисы требуют запуска множества основных и поддерживающих процессов (напр.,[9]).

Большое число процессов, которые занимают порты (Apache – 80 + 443, MySQL – 3306, sendmail/Postfix – 25 + если выбранный почтовый сервер поддерживает входящие - 110) создает множественные точки входа для внешних соединений. А т.к. на сервер необходимо загружать скрипты и вообще как-то им управлять – мы имеем FTP или SSH (а часто и то и другое) на 20/21 и 22 портах. Микросервисы, реализованные как программы, могут не требовать собственных портов – но, если они вынесены на отдельные сервера, число портов и сложность перекрестных обращений растет многократно.

«Интерпретируемость» PHP, Python и C# как часто применяемых технологий означает, что каждый раз при обработке обращений клиента следует что-то прочитать с диска и, доверяя этому скрипту, выполнить его. Необходимо также получить данные из СУБД и, точно так же доверяя им, отдать клиенту. И то же со скриптами и файлами оформления, которым предстоит работать на стороне клиента – мы им доверяем и позволяем работать.

Перечисленное ни в коем случае не упоминается в «плохом» или «хорошем» контексте: это – факт, важный при проектировании системы с веб-приложением. Это общая логика: то, что находится на сервере, является доверенным. Мы позволяем оказаться «этому» у клиента, и более того – выполняться на самом сервере.

Отсюда формируются два главных вектора риска:

• если злоумышленнику требуется добиться неработоспособности сайта – он может:
  • нагружать любой из процессов на сервере, и даже все вместе;
  • использовать ограничение пропускной способности сетевой карты;

• если злоумышленнику требуется получить доступ к информации в базе данных, использовать веб-ресурс для выполнения «полезной» работы на стороне клиента или на стороне сервера – требуется сохранить необходимые скрипты в подходящем хранилище. Таким хранилищем может быть как файловая система, так и база данных.

Интерпретируемые языки не позволяют обеспечить «инкапсуляцию» веб-ресурса в запущенном процессе, и одновременно они не имеют надежного инструмента для проверки файлов на сервере.

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

1. Постановка задачи

Определим круг задач следующим образом:

1. обеспечить невозможность несанкционированно изменить скрипты, файлы и данные веб-приложения;
2. обеспечить использование данных посетителей в исключительно доверенном режиме;
3. обеспечить производительность системы, превосходящую максимально прогнозируемые атаки;
4. обеспечить обработку входящих соединений и надежную фильтрацию реальных посетителей от злонамеренных подключений.

Из этих размышлений у нас родилась идея создать веб-приложения со следующими свойствами:

1. изоляция CMS от «фронта»;
2. распределение всего объема входящих соединений между большим количеством устройств, которые будут отвечать посетителю всегда одинаковым образом;
3. неизменяемость всего набора объектов, составляющих веб-приложение в его «фронте»: скриптов, базы данных, файлов для загрузки и выполнения на стороне клиента, включая:
4. возможность отслеживания и купирования попыток редактирования таких файлов;
5. разделение пользовательских данных и данных веб-приложения между разными хранилищами.

1. Блокчейн

1. Технология

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

Технология распределенного реестра (DLT, Distributed Ledger Technology) – это способ хранения информации, при котором цифровые данные имеют множество равнозначных копий и хранятся на множестве географически распределенных устройств. Соответственно, распределенный реестр – база данных, организованная таким способом.

Технология блокчейн – это способ хранения информации в базе данных, при котором записи объединяются в массивы (блоки), которые сохраняются с определенным интервалом, причем блок, и только этот блок, наследует информацию предыдущего, а также имеется механизм проверки такого наследования.

Мы понимаем «записи» как структурированную информацию, которую тот или иной пользователь базы данных передал для сохранения в ней – по сути, это транзакции.

Распространенный подход к блокчейну как к в прямом смысле «цепочке блоков», которые объединяют транзакции в блоки и обеспечивают наследование уже множества транзакций предыдущему множеству, является в нашем понимании частным случаем (хоть и распространенным, но не единственно возможным) механизма наследования.

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

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

1. Блокчейн для веб-приложений

Привычная реакция на выражение «блокчейн-сайт» - ожидание, что зашифрованные данные будут храниться разбитыми на части на множестве различных устройств. И если первое – естественно, то второе выглядит забавно. Деление совокупности данных веб-приложения на множество частей, которые будут «собираться» в одну страницу и при том могут оказаться недоступны в любой момент является явно ошибочным решением.

Напротив, использование множества идентичных копий веб-приложения и его базы данных создает многочисленные возможности:

1. значительное количество одновременных соединений с веб-приложением можно распределить среди множества устройств;
2. существует возможность произвольным образом менять количество таких копий – например, добавлять новые экземпляры веб-приложения и базы данных;
3. при распознавании атаки – возможность изоляции атакуемых копий от основной сети при сохранении нормального функционирования системы в целом.

Непосредственно блокчейн обеспечивает неизменность хранимых данных. При этом, как правило, неверно понимается само выражение «неизменяемость»: в действительности, на одном или нескольких устройствах данные как раз могут быть изменены. Однако блокчейн располагает встроенными механизмами как для проверки записей, так и для проверки узлов (мы посчитали разумным встроить механизм регулярной проверки образа ноды, который был запущен и находится в оперативной памяти). Используя эти механизмы, возможно строить полезные сервисы, например:

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

1. Блокчейн-сайты

Технология использует свойство блокчейна, позволяющее отследить факт не разрешенного изменения ранее сохраненной информации, а также децентрализованный характер сети для распределения нагрузки (потенциально – злонамеренной DDoS-нагрузки) среди множества устройств. Для этого на множестве устройств размещаются идентичные экземпляры веб-сайта и базы данных, и обеспечивается равномерное распределение входящих соединений среди всех нод, которые содержат не измененный экземпляр веб-сайта. Обеспечивается автоматическое восстановление экземпляра в случае изменения, инициированного не администратором сайта.

Технология блокчейн-сайта предусматривает:

• прием входящих соединений на специальный балансирующий узел, который ведет учет нагрузки на множество идентичных экземпляров веб-сайта, а также отслеживает случае не разрешенного их изменения. Этот «балансировщик» может быть объединен с DNS-сервером, работающим по технологии DNSSEC, для купирования рисков атаки на DNS-серверы. Таких «балансировщиков» предусматривается несколько в блокчейн-сети, они не читают входящие данные и обеспечивают (текущая версия, по результатам нагрузочного тестирования) свыше 30,000 соединений в секунду независимо от объема входящего траффика;
• доступ к CMS и загрузка исходных файлов веб-приложения на доверенной ноде блокчейн-сети через интерфейс, доступный только на локальной машине (через localhost). Этот узел блокчейн-сети выпускает транзакции, которые затем добавляются в блоки и распространяются по всей сети;
• специализированные блокчейн-узлы, на которых размещаются публичные копии веб-сайта, принимают транзакции, определяют, какие из этих транзакций содержат изменения для размещенных на данной ноде сайтах, и производят обновления;
• публичные ноды принимают только соединения от «балансировщика», блокируя прочие соединения. Они также могут вносить такие недоверенные соединения в бан-лист, пресекая попытки многократного использования скомпрометированных (подозреваемых в DDoS или попытке взлома) клиентов;
• на всех нодах предусматривается отказ от приема входящих соединений из публичной сети на порты, помимо портов веб-сервера, так же обеспечивая бан скомпрометированных клиентов.

Мы рассматриваем блокчейн в контексте веб-приложений как совокупность хранилищ: компонентов веб-приложения (скрипты, файлы оформления и скриптов и т.п.), данных приложения и данных пользователя. Веб-приложение на основе технологии блокчейн может быть реализовано как публичная сеть (по сути – блокчейн-хостинг), так и приватная. Во всех случаях необходимо жестко отделить систему администрирования как доверенный (относительно администратора веб-приложения) ресурс от публичных ресурсов, доступных обычным посетителям.

Веб-приложение может быть выполнено как:

• часть блокчейна (компилируемая библиотека, в настоящее время мы выполняем такие проекты на C++; 1 блокчейн-нода в таком случае на нагрузочных тестах обслуживала 12,000 соединений в секунду);
• содержимое записи в блокчейне (веб-сайт, разработанный на интерпретируемом языке (PHP или Python), со всеми скриптами, файлами оформления и содержания, дампом SQL сохраняется в блокчейне). В этом случае на устройстве с узлом блокчейна может быть автоматически развернута требуемая инфраструктура (напр., Nginx+Apache, MySQL, PHP). Программное обеспечение блокчейн-ноды обеспечивает автоматическое управление этой инфраструктурой.

Варианты представлены в таблице:

Вариант компилируемого веб-приложения позволяет обеспечить высокую производительность по сравнению с «классическими» технологиями, проверку соединений на уровне ядра и жестко ограничить объем принимаемого траффика. Этот вариант имеет недостатки – сложность разработки и необходимость тщательно проектировать все функции, о которых даже не привыкли задумываться разработчики на PHP, Python и C#. Веб-ресурсы, переносимые на блокчейн-технологию с использованием компилируемого приложения, потребуют переписать их полностью. В то же время, мы считаем именно этот подход наиболее верным в плане безопасности, поскольку он позволяет инкапсулировать веб-сайт напрямую в блокчейне и предусмотреть тщательный мониторинг событий на публичном сервере.

Вариант интерпретируемого веб-приложения сохраняет все риски и недостатки «классических» веб-сайтов, однако блокчейн позволяет распределить нагрузку среди множества экземпляров, отследить факт взлома и прекратить использование данного узла до тех пор, пока он не будет восстановлен – автоматически или администратором. Этот вариант может потребовать проектировать проект как высоконагруженный, а также использовать большее число блокчейн-узлов для распределения нагрузки по сравнению с компилируемым. «Классический» сайт, размещенный на блокчейн-хостинге, позволяет пользоваться преимуществами технологии, сохранив привычный уровень требований к разработчикам.

Применение «балансировщиков» и бана клиентов, подозреваемых в злонамеренной активности, не отменяет использование анти-DDoS сервисов, брандмауэров, антивирусных программ – напротив, мощности блокчейн-приложений следует сочетать с существующими инструментами защиты.

Ссылки

1. Как создать сайт или приложение на blockchain? -https://toster.ru/q/486393
2. Интернет сайты в блокчейне -https://bitcointalk.org/index.php?topic=2062667.0
3. [BOUNTY] 3% up to $ .5 mln★A BLOCKCHAIN-POWERED USER-CENTRIC WEB 3.0 PLATFORM -https://bitcointalk.org/index.php?topic=2897802.0
4. Is Blockchain suitable for web applications? -https://www.quora.com/Is-Blockchain-suitable-for-web-applications
5. Чайников дал Тунгусову преимущество над областной властью -https://m.ura.news/articles/1036276202
6. Хакеры занялись торговлей -https://www.kommersant.ru/doc/3897106
7. «КИБЕРПРЕСТУПНИКИ ЧАЩЕ ВЗЛАМЫВАЮТ НЕ IT-СИСТЕМУ, А ЧЕЛОВЕКА» -http://marrket.org/novosti/kiberprestupniki-chasche-vzlamyvayut-ne-it-sistemu-a-cheloveka
8. Многопоточные вычисления в PHP: pthreads -https://habr.com/en/post/300952/
9. Jaeger Opentracing и Microservices в реальном проекте на PHP и Golang - https://habr.com/ru/company/carprice/blog/340946/
10. Поиск и редактирование значений в памяти сторонней программы на C++ -https://habr.com/en/post/93437/
11. Криминалистический анализ слепков оперативной памяти -https://xakep.ru/2013/11/16/forensic-ram-ringerprints/
12. DoS-атака -https://ru.wikipedia.org/wiki/DoS-атака
13. Ну и ответ кто есть МЫ тут