Workflow может получить URL из формы, письма, документа, выражения или результата ИИ, а затем отправить по нему запрос. Если адресом управляет внешний источник, сервер рискует обратиться к localhost, закрытому внутреннему сервису или служебному ресурсу инфраструктуры.
Для рабочего запуска недостаточно включить одну настройку. Сначала составьте карту необходимых направлений, затем ограничьте фактический сетевой выход средствами инфраструктуры, настройте прикладную SSRF-защиту n8n и проверьте разрешённые и запрещённые маршруты. Этот подход относится ко всему сетевому контуру автоматизации, а не только к ИИ-агентам.
От какого риска защищают исходящие ограничения
SSRF — это ситуация, в которой управляемый вход заставляет сервер выполнить нежелательный запрос. Например, автоматизация должна скачать документ по переданному URL, но вместо корпоративного файлового шлюза получает адрес локального сервиса. Запрос выполняет сервер n8n, поэтому цель может быть доступна ему, даже если она недоступна пользователю извне.
Официальная документация описывает встроенную SSRF-защиту для self-hosted n8n. При включении она проверяет исходящие HTTP-запросы из управляемых пользователем узлов, включая цели перенаправлений и результат DNS-разрешения. Это подтверждает возможность продукта, но не доказывает, что защита уже включена и правильно настроена в конкретном экземпляре.
Исходящие ограничения нужны и без ИИ. Адрес может попасть в workflow через обычное поле формы, импортированную таблицу, webhook, выражение или ответ подключённой системы. Поэтому проверяйте не только действия агента, но и все доступные способы сформировать и выполнить сетевой запрос.
Составьте карту необходимых сетевых направлений
Начните не с широкого списка блокировок, а с перечня обращений, без которых автоматизация не выполнит свою задачу. Для каждого направления зафиксируйте назначение и владельца.
| Workflow или операция | Узел | Источник адреса | Протокол | Hostname и порт | Ожидаемые IP или диапазоны | Перенаправления | Владелец сервиса | Последствие недоступности |
|---|---|---|---|---|---|---|---|---|
| Загрузка документа | HTTP-запрос | Поле входного события | HTTPS | Домен файлового шлюза, 443 | Уточнить у владельца | Запретить или описать допустимые цели | Владелец шлюза | Документ не обработан |
| Передача файла на распознавание | Узел интеграции или HTTP-запрос | Настройка workflow | HTTPS | API сервиса, 443 | Уточнить у поставщика | Проверить по документации сервиса | Владелец интеграции | Нет результата распознавания |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Разделите направления на обязательные, временные, спорные и запрещённые. Временное разрешение должно иметь владельца и условие удаления. Спорное направление не переносите в рабочий allowlist, пока не выясните его назначение.
Если workflow нужен один внутренний API, разрешайте именно этот сервис, необходимый протокол и порт, а не всю внутреннюю сеть. Для стороннего API заранее выясните, меняются ли его адреса и как поставщик сообщает об изменениях. Универсального allowlist для всех экземпляров n8n нет: состав правил зависит от архитектуры и интеграций.
Разведите встроенную SSRF-защиту и сетевой периметр
Защиту стоит строить слоями:
- Firewall, security groups или network policies ограничивают фактический выход из среды n8n.
- Встроенная SSRF-защита n8n проверяет цель на уровне приложения.
- Состав доступных узлов и инструментов ограничивает способы выполнения запросов.
- Протокол испытаний подтверждает поведение конкретной конфигурации.
Документация n8n на момент проверки указывает, что встроенная SSRF-защита доступна начиная с версии 2.12.0. Перед настройкой зафиксируйте версию своего self-hosted экземпляра. Не исходите из предположения, что функция присутствует в более ранней версии, включена автоматически или уже охватывает любой возможный путь к сети.
Прикладная проверка не заменяет сетевой периметр. Если запрос прошёл по неучтённому пути, инфраструктурное правило остаётся отдельным барьером. И наоборот: firewall не объяснит владельцу workflow, почему конкретное имя, перенаправление или DNS-результат противоречит правилам приложения. Оба уровня проектируют и проверяют совместно.
Настройте блокировки и точечные разрешения
Встроенную защиту включают параметром N8N_SSRF_PROTECTION_ENABLED=true. После этого сохраните стандартные блокировки, добавьте нужные проекту запрещённые диапазоны и выдайте минимальные исключения для обоснованных внутренних сервисов. Значения и способ передачи переменных зависят от размещения; реальные адреса и полную сетевую схему не публикуйте.
В документированном механизме n8n правила имеют такой приоритет:
- allowlist hostname;
- allowlist IP;
- blocklist IP.
Это существенно: разрешённый hostname обходит проверку по IP-блок-листу. Поэтому добавляйте в allowlist только контролируемые доменные зоны. Широкий шаблон для стороннего домена может разрешить больше целей, чем требуется workflow.
Для каждого исключения сохраните:
- нужный workflow и операцию;
- владельца сервиса;
- hostname, диапазон, протокол и порт;
- причину доступа;
- допустимость перенаправлений;
- способ проверки и возврата изменения.
Не добавляйте адрес автоматически после первого отказа. Сначала установите, к какой цели обращается workflow, как имя разрешается в IP и куда ведёт перенаправление. Затем подтвердите необходимость доступа и повторите разрешённые и запрещённые сценарии.
Ограничьте дополнительные пути выполнения запросов
Проверка одного HTTP Request не показывает весь сетевой контур экземпляра. Инвентаризируйте встроенные и community nodes, Code, подключённые инструменты и возможности запуска команд. Для каждого пути выясните, может ли он обратиться к сети и распространяется ли на него выбранный контроль.
Переменная NODES_EXCLUDE не загружает перечисленные типы узлов. Это подходит для узлов, которые не должны запускаться в экземпляре. Однако исключение нескольких типов не доказывает, что перекрыты все сетевые пути: состав узлов, расширений и среды нужно исследовать для конкретной сборки.
Блокировка узлов и SSRF-фильтрация решают разные задачи. Первая убирает выбранный механизм выполнения, вторая проверяет сетевые цели поддерживаемых исходящих запросов. Сопоставьте оба уровня с инфраструктурными правилами и не объявляйте один из них полной заменой остальных.
Условный пример: загрузка документа по переданному URL
Ниже — синтетический проектный пример, а не клиентский кейс и не результат выполненного теста Switch On AI.
Автоматизация получает от пользователя URL документа, скачивает файл и передаёт его во внешний сервис распознавания. Проект разрешает домен корпоративного файлового шлюза и API распознавания. Конкретные домены, диапазоны и реакцию на отказ команда определяет по архитектуре будущей системы.
Последовательность обработки:
- Workflow получает URL и сохраняет безопасный идентификатор операции.
- Система разбирает схему, hostname и порт по правилам проекта.
- Сетевые и прикладные ограничения проверяют исходную цель, DNS-результат и каждое перенаправление.
- Workflow получает файл либо завершает действие контролируемым отказом без передачи данных дальше.
| Кандидат | Ожидаемое решение в примере | Что проверить |
|---|---|---|
| Разрешённый корпоративный шлюз | Разрешить | Полный путь до получения ожидаемого тестового файла |
| Внешний домен вне перечня | Остановить | Запрос не достиг цели, причина отказа видна ответственному |
| Localhost | Остановить | Локальный сервис не получил запрос |
| Закрытый внутренний адрес | Остановить | Исключение не охватывает лишнюю часть внутренней сети |
| Служебный адрес инфраструктуры | Остановить | Целевой ресурс не получил запрос |
| Разрешённый hostname с неожиданным закрытым IP | Заблокировать рабочий запуск до пересмотра hostname allowlist или настройки отдельного инфраструктурного ограничения | Учтены приоритет hostname allowlist и фактический DNS-результат |
| Разрешённый URL с переходом на запрещённый адрес | Остановить перенаправление | Запрещённая конечная цель не получила запрос |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Особого внимания требует разрешённый hostname, который разрешается в неожиданный IP. Поскольку hostname allowlist в n8n имеет приоритет над IP-блок-листом, ожидание «закрытый IP всё равно остановит запрос» может оказаться неверным. Такой сценарий нужно согласовать при проектировании allowlist и проверить в собственном разрешённом контуре.
После отказа workflow не должен вслепую повторять загрузку или передавать в распознавание пустой либо неподтверждённый результат. Он завершает затронутое действие, сохраняет достаточный контекст без секретов и уведомляет ответственного по согласованному маршруту.
Проверьте ограничения до рабочего запуска
Используйте только собственные тестовые ресурсы или контур, на проверку которого получено явное разрешение. До испытания зафиксируйте версию n8n, конфигурацию SSRF-защиты, сетевой слой, состав применимых узлов и ограничения проверки.
Протокол должен охватывать смысловые классы, а не произвольное число похожих URL:
| Проверка | Ожидаемый результат | Что фиксировать |
|---|---|---|
| Разрешённое рабочее направление | Операция проходит до ожидаемого результата | Исходная цель, DNS-результат, сетевой и прикладной уровни |
| Прямой запрещённый адрес | Запрос остановлен | Уровень блокировки и отсутствие обращения к цели |
| Hostname с адресом из закрытого диапазона | Решение соответствует согласованному правилу | Полученный IP и сработавшее правило |
| Перенаправление на запрещённую цель | Переход остановлен | Цепочка целей и точка отказа |
| Изменение DNS между проверками | Запрос не обходит согласованные ограничения | Ответы DNS и фактическая цель обращения |
| Недоступный разрешённый сервис | Ошибка видна, ложного успеха нет | Статус операции и маршрут уведомления |
| Повтор после отказа | Нет слепого опасного действия | Условие повтора и отсутствие побочного эффекта |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Для каждого сценария сохраните безопасное обозначение исходного URL, ожидаемое решение, фактический результат, уровень разрешения или остановки и сведения об отсутствии целевого побочного действия после отказа. Разрешённый маршрут проверяйте полностью: сам факт отсутствия блокировки ещё не означает, что рабочая интеграция сохранила нужный результат.
Неожиданное разрешение, необъяснимый отказ или разное поведение экземпляров блокирует рабочий запуск затронутого сценария до разбора. Успешная проверка подтверждает только исследованные версию, конфигурацию, контур и набор сценариев, а не абсолютную защиту от всех вариантов SSRF.
Обработайте отказ и поддерживайте правила после запуска
При блокировке остановите затронутое действие. Сохраните идентификатор workflow, безопасное обозначение цели, время, сработавший уровень и причину решения, но не записывайте в уведомление секреты или полный чувствительный URL.
Ответственный должен отличать три ситуации: ожидаемую блокировку, поломку необходимой интеграции и неизвестный маршрут. Ни одна из них не должна автоматически расширять allowlist. Изменение проходит как контролируемая операция с причиной, владельцем, проверкой рабочих и запрещённых маршрутов и способом возврата.
Пересматривайте карту направлений, когда команда:
- добавляет интеграцию или новый тип узла;
- меняет workflow, DNS или адреса поставщика;
- обновляет n8n;
- переносит экземпляр в другую сетевую зону;
- меняет firewall, security groups или network policies.
После изменения повторяйте проверки соразмерно затронутому риску. Старый протокол не подтверждает новую конфигурацию автоматически.
Что подготовить для обсуждения внедрения
Для предметного разговора соберите:
- версию и способ размещения n8n;
- схему сетевых зон без секретов;
- список workflow с исходящими обращениями;
- обязательные внешние домены и внутренние сервисы;
- доступные firewall, security groups или network policies;
- перечень узлов и других способов обращения к сети;
- ответственных за сеть, приложения и приёмку;
- примеры разрешённого и запрещённого поведения.
Switch On AI помогает разрабатывать и внедрять автоматизацию: обследовать процесс и контур, подготовить ТЗ и коммерческое предложение, собрать бесплатный прототип ключевого сценария, а после согласования — выполнить работы по договору и провести приёмку. Прототип помогает проверить выбранный фрагмент, но не равен полноценному внедрению. Сроки, стоимость, сопровождение и расходы на инфраструктуру определяются после разбора задачи.
На первом обсуждении можно начать с одного workflow и его сетевой карты. Это позволит отделить обязательные направления от лишних исключений и заранее согласовать, какие обычные, запрещённые, DNS- и redirect-сценарии войдут в проверку.
Вопросы по этой задаче
Достаточно ли включить встроенную SSRF-защиту n8n?
Нет. Это дополнительный прикладной уровень. Фактический сетевой выход следует ограничить средствами инфраструктуры, а затем проверить оба уровня на разрешённых и запрещённых маршрутах.
Можно ли разрешить всю внутреннюю сеть ради одного API?
Широкое разрешение увеличивает доступный автоматизации контур. Опишите конкретный сервис, протокол, адреса и порт, затем проверьте минимально необходимое исключение.
Почему нужно отдельно проверять перенаправления и DNS?
Начальный URL может перенаправить запрос к другой цели, а hostname — разрешиться в неожиданный закрытый адрес. n8n документирует проверки этих этапов, но поведение конкретной конфигурации нужно подтвердить в разрешённом тестовом контуре.
Заменяет ли NODES_EXCLUDE защиту от SSRF?
Нет. NODES_EXCLUDE убирает выбранные типы узлов из экземпляра, а SSRF-защита контролирует цели поддерживаемых исходящих HTTP-запросов. Полноту покрытия оценивают вместе с сетевыми правилами.
Что делать, если нужная интеграция перестала работать?
Не отключайте ограничения целиком. Определите исходную цель, DNS-результат и перенаправления, подтвердите необходимость доступа, добавьте минимальное контролируемое исключение и повторите рабочие и запрещённые сценарии.