Загадочная сетевая ошибка
Когда я работал над техническим постом о ресолвинге DNS, то столкнулся с чем-то неожиданным. Каждый раз, когда я вводил пути к файлу hosts (/etc/h*sts — здесь я намеренно его обфусцировал, чтобы не вызвать ту самую ошибку), редактор Substack показывал «Network Error» и отказывался автоматически сохранять черновик.
Поначалу я решил, что возник сбой на сервере Substack. Однако на странице статуса было видно, что все системы работают. Случилось нечто другое.
Начинаем расследование
Я заметил, что ошибка стабильно возникала, когда я вводил этот конкретный путь к файлу; но когда я вводил разные его вариации наподобие /etc/h0sts или /etchosts, редактор работал без проблем. Заинтересовавшись этим паттерном, я протестировал другие системные пути:
Путь Результат
/etc/h*sts ❌ Ошибка
/etc/h0sts ✅ Работает
/etchosts ✅ Работает
/etc/pass*d ❌ Ошибка
/etc/password ✅ Работает
/etc/ssh/sshd_conf*g ❌ Ошибка
/etc/ssh ✅ Работает
/etc/h*sts.allowed ❌ Ошибка
/etc/h*sts.foo ❌ Ошибка(Примечание: * использована для замены символа в путях, иначе бы возникла ошибка)
Обнаружился некий паттерн: ошибки возникали из-за путей к стандартным файлам конфигурации системы в Linux, а после внесения в них незначительных изменений всё работало без проблем.
Что там происходит внутри?
В браузерных инструментах разработчика обнаружилось нечто любопытное:
Редактор выполнял запросы PUT к Substack API, чтобы сохранить черновик, но если контент содержал определённые системные пути, запрос получал ответ 403 Forbidden.
Судя по заголовкам ответов, это как-то связано с Cloudflare:
Server: cloudflare
Cf-Ray: 935d70ff6864bcf5-ATLРазбираемся с фильтрами безопасности веб-приложения
Подобное поведение даёт нам понять, что это как-то связано с работой Web Application Firewall (WAF). Но что же такое WAF, и почему он блокирует эти пути?
Краткое объяснение WAF
Можно считать Web Application Firewall системой безопасности веб-сайтов. Он находится между пользователями и веб-приложением, исследует весь трафик и блокирует всё подозрительное.
У WAF есть правила о том, какие типы запросов выглядят опасными. Когда он встречает что-то из «списка подозрительных действий», то отклоняет запрос.
Атаки обходом путей: причина осторожности
Одна из распространённых атак, от которых WAF обеспечивает защиту — это атака обходом путей. Вот простое объяснение:
Представим, что файлы веб-сайта упорядочены по папкам, например:
/images/profile.jpg
/docs/report.pdfХакер может попытаться «вырваться наружу» из этих папок, отправив запросы следующего вида:
/images/../../../etc/pass*dЭто попытка подняться вверх по уровням папок, чтобы добраться до конфиденциальных системных файлов, например, до файла с паролями на сервере.
Системные пути наподобие /etc/h*sts и /etc/pass*d — это популярные цели для подобных атак, потому что в них содержится ценная информация о системе. Получивший к ним доступ хакер может найти имена пользователей, хэши паролей или сетевые конфигурации, позволяющие ещё больше скомпрометировать систему.
[Более подробную информацию об атаках обходом путей можно изучить в руководстве OWASP]
Инъецирование команд: ещё одна проблема безопасности
Ещё один вектор атак — это «инъецирование команд», при котором нападающий пытается заставить веб-приложение исполнять системные команды. Указание системных путей вида /etc/h*sts может привести к срабатыванию фильтров, предназначенных для защиты от попыток инъецирования команд.
При атаке инъецированием команд нападающий может ввести что-то типа:
; cat /etc/pass*dЕсли веб-приложение не санирует правильно этот ввод перед его использованием в системной команде, то она сможет выполнить код нападающего и раскрыть конфиденциальную информацию.
[Подробнее о инъецировании команд можно прочитать в PortSwigger Web Security Academy]
Загадка становится сложнее: исторические примеры
Заинтересовавшись тем, не сталкивались ли с этой проблемой другие, я поискал посты на Substack, содержащие эти системные пути. Любопытно, что я нашёл пост за 4 марта 2025 года, в котором без проблем сохранилась строка /etc/h*sts.allowed.
В ещё одном посте за 30 марта 2025 года использовалась любопытная формулировка etc -> hosts — возможно, автор так пытался обойти ту же самую проблему?
Можно прийти к выводу, что фильтрация была реализована или модифицирована между этими двумя датами.
Безопасность и удобство пользования: тонкий баланс
Этот случай напоминает нам об интересной проблеме веб-безопасности: балансе между защитой и удобством пользования.
Фильтр Substack включили с вполне благими намерениями — чтобы защитить платформу от потенциальных атак. Но это создало раздражающее препятствие для технических писателей, рассказывающих о системных конфигурациях.
Кроме того, реализация неидеальна:
Обобщённое сообщение «Network Error» неинформативно
Фильтр блокирует допустимый технический контент
У авторов, пишущих на подобные темы, нет понятного обходного решения
Изучим HTTP-ответ
Запрос к https://scalewithlee.substack.com/api/v1/drafts/162118646 завершается сбоем со следующими параметрами:
Status Code: 403 Forbidden
Request Method: PUT
Content-Type: application/json
Всё это чётко говорит нам, что всё происходит на уровне API, а не просто в UI редактора.
Более качественные решения для платформ с техническим контентом
Как Substack может улучшить ситуацию для технических писателей?
Контекстная фильтрация: определение ситуаций, когда системные пути встречаются в блоках кода или в технических обсуждениях
Понятные сообщения об ошибках: нужно заменить «Network Error» на что-то типа «Этот контент содержит паттерны, на которые могут реагировать наши фильтры безопасности»
Задокументированные способы обхода проблемы: инструкции для технических авторов о том, как писать о конфиденциальных путях
Заключение: на пересечении безопасности и технического контента
Эта особенность редактора Substack стала примером сложных проблем, возникающих при создании защищённых платформ, которыми пользуются и технические писатели. То, что фильтр безопасности расценивает, как паттерн атаки, может быть вполне допустимым контентом автора, пишущего о системном администрировании или DevOps.
Я DevOps-инженер, поэтому подобные пограничные случаи восхищают меня; они подчёркивают то, что меры безопасности иногда могут иметь незапланированные последствия в вполне допустимых сценариях использования.
Пока я продолжу пользоваться обходными решениями наподобие "/etc/h*sts" (с кавычками) или альтернативным написанием в своих постах на Substack, посвящённых системным путям. Возможно, моё исследование поможет другим техническим писателям разобраться, что происходит, когда в редакторе возникают подобные загадочные «Network Error».
