Привет всем,
В связи с ростом блокировок, в том числе необоснованных, сайтов со стороны государства, вашему вниманию предлагается описание идеи, а также прототип настроек сайта, защищенного от блокировок по конкретному пути и доменному имени. Идеи по защите от блокировок:
- со звездочкой
- по адресу IP
будут изложены в других постах. Кому интересна тема, заходите под кат.
Ссылка
https://github.com/http-abs/http-abs/
Описание идеи
Принцип защиты заключается в том, что каждый пользователь получает уникальную пару из индивидуального (под)домена и префикса пути для просмотра сайта. Назовем эту пару идентификатором агента.
Если по каким-то причинам, вы можете управлять только ограниченным набором поддоменов, пользователь будет конечно, разделять свой поддомен с некоторыми другими пользователями.
Как это защитит от блокировки?
- Если блокировка ограничивается путем и/или точным доменом, то отправив заявку на блокировку такого пути и/или домена, оператор блокировок заблокирует только свой собственный доступ, не затрагивая интересов других пользователей.
Конечно, в случае ограничения, указанного выше, жизнь станет сложнее у тех пользователей, которым не повезло разделить поддомен с оператором блокировок. Но не сильно.
- Когда и если вы, как администратор сайта, обнаружите блокировку, вы можете исключить (допустим, заменить на котиков) выдачу спорного материала по данному адресу: это никак не повлияет на выдачу того же материала другим пользователям.
При условии предыдущего примечания.
- Локальная замена контента даст вам возможность попытаться исключить ссылку из списка блокировок, избегая например тотальной блокировки по доменному имени.
А как же тогда делиться ссылками?
Легко. Идентификатор агента, выделенный пользователю для просмотра сайта, сохраняется у него в куках. Пользователь просто делится ссылкой из аресной строки.
- Если у пользователя еще нет соответствующей куки, переход по ссылке, содержащей чужлой идентификатор, инициирует процесс выделения нового идентификатора агента, с редиректом на индивидуальный URL просмотра материала, включающий в себя этот идентификатор.
- Если у пользователя уже есть кука с идентификатором агента, переход по ссылке, содержащей чужой идентификатор, инициирует редирект на индивидуальный URL просмотра материала для данного пользователя, с его собственным идентификатором.
А зачем сохранять куку?
Чтобы изолировать оператора блокировок. Если повезет, после нескольких блокировок, его можно будет даже идентифицировать.
Не усложнит ли это жизнь пользователю?
Ничуть, от него не требуется в буквальном смысле ничего. Он заходит на сайт обычным образом, читает материалы и делится ссылками. В его жизни меняется только вид адресной строки.
Усложнит ли это жизнь разработчику сервера?
Возможно. Ему не придется учитывать префикс пути и поддомен, входящие в идентификатор агента: их будет обрезать обработчик на первой стадии обработки входящего URL. Однако, чтобы сделать процесс совершенно прозрачным, возможно придется еще потрудиться.
Сможет ли оператор блокировок обойти изоляцию?
Конечно. Но ему будет гораздо труднее доказывать необходимость блокировки бесконечного количества ссылок на материал, сформированных по замысловатому правилу, при том, что правила могут и измениться на еще более замысловатые.
Оператор просто заблокирует все нафиг со звездочкой и адресом IP
Такое развитие событий не исключено, но эти случаи я хочу рассмотреть отдельно в другой статье. Возможно, мы с вами вместе придумаем что-то дополнительно в комментариях.
Реализация
Архитектура
Для того, чтобы сделать процесс максимально прозрачным, код сосредоточен в сервере фронтенда nginx. Это позволяет ставить под защиту самые разнообразные прикладные серверы практически без ограничений.
Поскольку обработка запроса будет весьма нетривиальной, использован дополнительный пакет libnginx-mod-http-lua, внедряющий язык lua в процесс обработки запросов под nginx.
Дополнительные условия
В идеале, обработка должна производиться так, чтобы бакенд (аплинк, прикладной сервер) — вовсе не был озабочен тем, поставили ли его под защиту. Ему приходят запросы по URL, из которого убраны все элементы идентификатора агента (назовем такие чистыми URL). Чтобы не переделывать возвращаемые страницы, переход по чистому URL с установленной кукой идентификатора агента, вызывает редирект на индивидуальный URL.
Фронтенд не хранит состояние нигде, кроме куки идентификатора агента.
На браузере не задействовано ни одной строки кода javascript. Используется только протокол HTTP.
Ограничения альфа-реализации
Фактически, реализован лишь proof-of-concept, позволяющий наблюдать реальную работу алгоритма. Не решено множество деталей, связанных с упаковкой продукта: модульность, выделение и проверка параметров и так далее.
Для поддоменов, выбрана схема с фиксированным набором поддоменов, пригодная для использования в паре с файлом hosts, без инсталляции дополнительного сервера DNS.
Формат префикса пути предопределен и представляет из себя 32 цифры по основанию 16.
Установленные параметры запуска
Параметры запуска установлены пока прямо в коде.
Набор поддоменов (a, b, c) установлен в переменной и может быть расширен.
Домен установлен, как example.com.
Бакенд ожидается на точке http://127.0.0.1:8000
Выводы
Растущая угроза внезапных блокировок заставляет готовиться заранее и изобретать методы защиты от них владельцев даже вполне лояльных сайтов. Такая защита вполне возможна, не требует никаких телодвижений со стороны пользователя и может быть реализована вполне скромным объемом усилий со стороны администратора сайта.
Автор: nnseva
