Как развернуть SafeLine WAF на Linux VPS

Веб-приложения с доступом из интернета регулярно сканируются на SQL-инъекции, злоупотребление учётными данными и шаблоны известных уязвимостей. SafeLine — это самостоятельно размещаемый WAF под лицензией GPL-3.0 который работает как стек Docker Compose и фильтрует HTTP/S-трафик, прежде чем переслать разрешённые запросы на источник. Его бесплатный тариф Personal поддерживает до 10 приложений.

Это руководство охватывает установку и три момента, требующих особого внимания: выбор архитектуры обратного прокси, настройку Docker-сети, когда SafeLine находится за уже существующим прокси вроде Nginx Proxy Manager, и команду проверки, которую можно запустить после установки, чтобы убедиться, что WAF действительно перехватывает атаки.

Кратко

• Установите SafeLine на Linux VPS с помощью Docker Compose. Воспользуйтесь установщиком в одну строку или выберите ручной путь через Docker Compose, чтобы изучить определение Compose и настройку окружения до запуска стека.
• Определите архитектуру обратного прокси до установки: SafeLine как единственный прокси, SafeLine за уже существующим Nginx Proxy Manager или SafeLine на одном сервере с Caddy. Каждая схема требует разных назначений портов и настроек X-Forwarded-For.
• После установки проверьте WAF, отправив с помощью curl тестовую SQL-инъекцию на защищённый URL. В режиме Balanced или Strict ответ 403 вместе с соответствующей записью в Attack Events подтверждает блокировку. В режиме Monitor соответствующее событие подтверждает обнаружение, даже если ответ остаётся успешным.
• Бесплатный тариф Personal охватывает до 10 приложений и основной движок обнаружения. Геоблокировка, экспорт журналов атак и внешние уведомления требуют тарифа Lite; более мощное обнаружение атак и балансировка нагрузки требуют Pro.

Перед началом: предварительные требования и что охватывает это руководство

В этом руководстве предполагается, что у вас есть Linux VPS, к которому можно подключиться по SSH с правами root или sudo, и что Docker установлен. В итоге вы получите работающий экземпляр SafeLine, защищающий хотя бы один сайт, и команду проверки, которую можно запустить в любой момент.

Вам понадобится:

• Linux VPS. Приведённые ниже команды рассчитаны на систему в стиле Debian или Ubuntu с systemd; на других дистрибутивах проверьте имена пакетов и служб.
• Минимум 1 vCPU, 1 GB RAM и 5 GB диска согласно официальным требованиям к развёртыванию. Для практического запаса в продакшене это руководство рекомендует 2 vCPU, 4 GB RAM и 20 GB диска.
• Docker 20.10.14 или новее и Docker Compose 2.0 или новее.
• Процессор x86_64 с поддержкой SSSE3; проверьте это командой lscpu | grep ssse3 вместо того чтобы предполагать, что инструкция присутствует.
• Домен или поддомен с DNS, указывающим на публичный IP VPS, если вы планируете открыть защищённое приложение по публичному HTTPS.
• Порты, соответствующие выбранной топологии. Схемы A и C обычно отдают SafeLine порты 80 и 443, тогда как схема B оставляет эти порты за Nginx Proxy Manager и назначает SafeLine другой слушатель, например 10080.
• Доступ root или sudo.

В межсетевом экране или группе безопасности провайдера VPS открывайте только те публичные порты, которые нужны выбранной топологии. Ограничьте SSH и TCP 9443 доверенными источниками администрирования. В схеме B держите TCP 10080 закрытым для публичного IPv4 и IPv6, а серверные порты, такие как 8080, — приватными в любой топологии. Прямой доступ к 10080 обошёл бы NPM и нарушил бы границу доверия X-Forwarded-For.

Примечание: Для ручного развёртывания на ARM64 задайте ARCH_SUFFIX=-arm. официальная документация по развёртыванию SafeLine указывает, что ARM требует лицензию Pro и что Personal Edition не поддерживается на ARM. Для Personal Edition используйте VPS на x86_64.

Проверьте Docker перед началом:

docker --version
docker compose version

Обе команды должны вернуть установленные версии. Продолжайте, только если Docker версии 20.10.14 или новее, а Docker Compose версии 2.0.0 или новее; в противном случае обновите их перед установкой SafeLine.

Сначала выберите архитектуру обратного прокси

На чистом VPS SafeLine может полностью занять порты 80 и 443. На VPS, где уже работает Nginx Proxy Manager, Caddy или собственный Nginx приложения, это не так, и выбор архитектуры — это разница между гладкой установкой и конфликтом портов при первом запуске. Сделайте это правильно один раз в начале, и остальная часть развёртывания будет механической.

Три схемы:

• Схема A, SafeLine как единственный обратный прокси. SafeLine занимает порты 80 и 443 и управляет TLS для защищённого приложения. Текущие релизы CE включают рабочий процесс Free Cert, при этом ручная загрузка сертификата остаётся доступной; проверьте точные параметры сертификатов в установленном релизе. Бэкенд работает на непубличном порту, и SafeLine маршрутизирует трафик к нему.
• Схема B, SafeLine за Nginx Proxy Manager (NPM). NPM сохраняет за собой порты 80 и 443 и обрабатывает SSL. SafeLine слушает порт 10080 (только HTTP, поскольку NPM уже завершил TLS). NPM пересылает трафик в SafeLine; SafeLine пересылает его на бэкенд. Это распространённая конфигурация, когда NPM уже развёрнут.
• Схема C, SafeLine рядом с Caddy. Автоматический HTTPS у Caddy конкурирует с SafeLine за порт 443. Рабочий вариант отдаёт SafeLine порты 80 и 443 и переносит Caddy на непубличный внутренний HTTP-порт, например 8080, для перехода SafeLine → Caddy → приложение.

Главный вывод: Схема A проще всего для чистого VPS; схема B — верный выбор, когда NPM уже работает; схема C требует осознанного переназначения порта Caddy.

Установите SafeLine на своём VPS

Сама установка — это простая часть. SafeLine предлагает два способа установки: автоматический установщик, который загружает удалённый скрипт с waf.chaitin.com, и ручной путь через Docker Compose, позволяющий изучить всё до запуска. Выберите тот, который соответствует вашей политике безопасности.

Шаг 1: убедитесь, что Docker готов

Ещё раз проверьте версию Docker и то, что демон Docker запущен:

docker --version
docker compose version
sudo systemctl status docker

Ожидаемый вывод включает active (running) для демона Docker. Если он не запущен, запустите его командой sudo systemctl start docker и включите автозапуск командой sudo systemctl enable docker.

Шаг 2: запустите установщик SafeLine

Есть два подпути. Выберите один.

Шаг 2a, автоматическая установка. Запустите установщик с правами root:

sudo bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Скрипт спрашивает, куда поместить каталог данных SafeLine, загружает образы Docker и запускает стек. После установки выполните sudo docker exec safeline-mgt resetadmin чтобы получить или сбросить учётные данные администратора, как описано в официальном руководстве по развёртыванию. Надёжно сохраните полученные учётные данные.

Примечание: Эта команда загружает и выполняет удалённый shell-скрипт с waf.chaitin.com от имени root. Официальная однострочная команда включает curl -k, что отключает проверку TLS-сертификата. Изучите загруженный скрипт перед выполнением или воспользуйтесь шагом 2b, если такой риск неприемлем. SafeLine также доступен как развёртывание Cloudzy в один клик, но этот образ использует /opt/safeline, /opt/safeline/.env, и /opt/safeline/docker-compose.yml. Не используйте на образе Cloudzy /data/safeline пути без изменений на образе Cloudzy.

Шаг 2b, ручная установка через Docker Compose. Загрузите и изучите официальный файл Compose, затем запустите стек:

sudo mkdir -p /data/safeline
cd /data/safeline
sudo wget -O /data/safeline/compose.yaml "https://waf.chaitin.com/release/latest/compose.yaml"
POSTGRES_PASSWORD="$(openssl rand -hex 32)"
sudo tee .env >/dev/null <<EOF
SAFELINE_DIR=/data/safeline
IMAGE_TAG=latest
MGT_PORT=9443
POSTGRES_PASSWORD=$POSTGRES_PASSWORD
SUBNET_PREFIX=172.22.222
IMAGE_PREFIX=chaitin
ARCH_SUFFIX=
RELEASE=
REGION=-g
MGT_PROXY=0
EOF
unset POSTGRES_PASSWORD
# Also adjust SUBNET_PREFIX if your VPS already uses 172.22.222.0/24.
sudo chmod 600 /data/safeline/.env
sudo docker compose up -d

После docker compose up -d завершится, выведите список запущенных контейнеров для проверки:

sudo docker compose ps

Вы должны увидеть контейнеры safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi и safeline-chaos. Если какой-либо контейнер показывает Exited, см. шаг 3, где описаны две наиболее частые причины.

Шаг 3: устраните распространённые ошибки установки

Две ошибки встречаются достаточно часто, чтобы заслужить отдельный шаг.

Пересечение подсетей. Если установка завершается с ошибкой Pool overlaps with other one on this address space, подсеть SafeLine по умолчанию конфликтует с существующей сетью Docker. Как описано в разборе устранения неполадок при установке SafeLine, исправьте это, отредактировав /data/safeline/.env:

sudo nano /data/safeline/.env
# Find the line:
#   SUBNET_PREFIX=172.22.222
# Change to an unused range, for example:
#   SUBNET_PREFIX=172.30.30
sudo docker compose -f /data/safeline/compose.yaml down
sudo docker compose -f /data/safeline/compose.yaml up -d

Ошибка резолвера IPv6. Если safeline-tengine аварийно завершается с ошибкой nginx: [emerg] invalid IPv6 address in resolver, сначала изучите файл резолвера и определите, кто им управляет:

readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Не редактируйте /etc/resolv.conf напрямую, если он создаётся systemd-resolved, NetworkManager или провайдером VPS. Исправьте некорректное значение nameserver в конфигурации управляющей службы, перегенерируйте файл резолвера и затем перезапустите Tengine:

sudo docker restart safeline-tengine

Шаг 4: доступ к панели управления

Панель управления SafeLine слушает TCP 9443 по HTTPS. Не оставляйте этот административный порт открытым для всего интернета. Ограничьте его доверенным адресом-источником или VPN либо заблокируйте публичный доступ и используйте SSH-туннель:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Откройте https://localhost:9443 через туннель. Предупреждение о самоподписанном сертификате ожидаемо при первом доступе; прежде чем продолжить, убедитесь, что SSH-соединение достигло нужного сервера.

Если вы потеряли начальные учётные данные, сбросьте пароль администратора с хоста:

sudo docker exec safeline-mgt resetadmin

Команда выводит учётные данные администратора, с которыми можно снова войти.

Настройте SafeLine под свою архитектуру

SafeLine теперь запущен, но пока ничего не защищает. Страница Applications в панели — это место, где вы указываете SafeLine, какие сайты защищать и куда пересылать очищенный трафик. Настройка различается в зависимости от выбранной ранее архитектуры, поэтому каждой схеме отведён свой подраздел. Проработайте только тот, который соответствует вашей конфигурации.

Схема A: SafeLine как единственный обратный прокси

В схеме A SafeLine слушает порты 80 и 443 напрямую и пересылает очищенный трафик вашему серверному приложению на непубличном порту. В панели управления:

1. Перейдите в Applications, затем Add Application.
2. Задайте порт прослушивания 443 и включите SSL. Используйте рабочий процесс сертификатов, доступный в вашем установленном релизе SafeLine. Текущие релизы CE включают запрос и обновление Free Cert, при этом ручная загрузка сертификата остаётся доступной.
3. Задайте upstream как http://127.0.0.1:8080. Если бэкенд работает в Docker, публикуйте его порт только на loopback, например "127.0.0.1:8080:8080" в разделе ports службы. Избегайте жёстко заданного IP контейнера, например 172.17.0.5 поскольку он может измениться при пересоздании контейнера.
4. Сохраните приложение. SafeLine сразу начинает слушать порт 443 и пересылать очищенный трафик на бэкенд.
5. Убедитесь, что DNS-запись A вашего домена указывает на публичный IP VPS и что порты 80 и 443 доступны извне.

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

Схема B: SafeLine за Nginx Proxy Manager

Схема B оставляет за NPM то, что он уже делает (занимает 80 и 443, обрабатывает Let's Encrypt), и вставляет SafeLine за ним как отдельный уровень безопасности. Поток трафика такой: клиент, затем NPM (порт 443, завершение TLS), затем SafeLine (порт 10080, HTTP), затем серверное приложение.

В панели управления SafeLine:

1. Applications, затем Add Application. Задайте порт прослушивания 10080 и оставьте SSL отключённым (NPM уже завершил TLS).
2. Задайте upstream как внутренний адрес приложения, как описано в схеме A.
3. Сохраните приложение.

В Nginx Proxy Manager:

1. Hosts, затем Proxy Hosts, затем Add Proxy Host.
2. Вкладка Details: задайте доменное имя, схему http и порт пересылки 10080. Если NPM работает напрямую на хосте, используйте 127.0.0.1 в качестве имени хоста пересылки. Если NPM работает в Docker на Linux, 127.0.0.1 указывает на контейнер NPM, а не на хост VPS. Добавьте в сопоставление host-gateway от Docker к службе NPM в Compose, затем используйте host.docker.internal в качестве имени хоста пересылки:

extra_hosts:
  - "host.docker.internal:host-gateway"

Из каталога Compose для NPM выполните sudo docker compose up -d чтобы контейнер был пересоздан с новым сопоставлением хоста.

3. Вкладка SSL: запросите сертификат Let's Encrypt, включите принудительный SSL и активируйте HTTP/2.
4. Оставьте вкладку Advanced в NPM пустой в отношении X-Forwarded-For. В текущем шаблоне NPM содержимое Advanced вставляется на уровне server и не переопределяет сгенерированные заголовки уровня location согласно правилам наследования NGINX. Сгенерированный location отправляет:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Вторая директива добавляет адрес, наблюдаемый NPM, как крайнее правое значение в заголовке.

5. Сохраните Proxy Host.

Вернувшись в SafeLine, настройте извлечение исходного IP только после того, как убедитесь в фактической цепочке заголовков. SafeLine 9.3.1 ввёл гибкое извлечение XFF с выбором направления и индекса.

1. Settings, затем Advanced, затем Real IP from Header. Задайте имя заголовка X-Forwarded-For.
2. Используйте пользовательское извлечение с конца заголовка и выберите крайний правый адрес, добавленный NPM. Точные обозначения индексов различаются по версиям, поэтому проверьте результат в Logs, затем Access. Если установленный релиз старше 9.3.1, обновите его, прежде чем следовать этой топологии.
3. Если перед NPM стоит Cloudflare или другой CDN, сначала настройте NPM так, чтобы он доверял только опубликованным прокси-диапазонам этого провайдера, тогда адрес, добавляемый NPM, будет заслуживающим доверия. Не выбирайте фиксированную позицию, пока не изучите и не протестируете реальную цепочку заголовков.
4. Сохраните и перезагрузите приложение.

Протестируйте конфигурацию с машины за пределами VPS:

curl -H "X-Forwarded-For: 1.2.3.4" "https://yourdomain.com/"

Журнал доступа SafeLine должен показывать ваш реальный публичный адрес, а не 1.2.3.4 или адрес моста NPM.

Не дайте пользователям обходить SafeLine, оставив серверный слушатель приватным. Для бэкенда на Docker Compose публикуйте порт только на loopback:

ports:
  - "127.0.0.1:8080:8080"

Для службы, работающей напрямую на хосте, настройте её на прослушивание 127.0.0.1:8080 вместо 0.0.0.0:8080. Проверьте оба внутренних порта с машины за пределами VPS:

curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:10080"
curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:8080"

TCP-соединения должны отклоняться или завершаться по таймауту. Ошибка HTTP или «Empty reply from server» всё равно означает, что порт доступен публично и должен быть защищён. Если привязка к loopback невозможна, создайте правила межсетевого экрана, настроенные под конкретный интерфейс, сеть Docker и контейнер назначения, вместо применения общего правила DOCKER-USER.

Схема C: SafeLine с Caddy

В схеме C SafeLine занимает порты 80 и 443; Caddy переходит на непубличный внутренний HTTP-порт. Поток трафика такой: клиент, затем SafeLine (443, TLS), затем Caddy (8080, внутренний HTTP), затем серверная часть приложения.

Изменить /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

Удалённый :8080 блок site — это важная часть: Caddy теперь слушает внутренний HTTP-порт вместо конкуренции с SafeLine за 443. Строка bind 127.0.0.1 удерживает этот слушатель локальным для VPS. Перезагрузите Caddy командой sudo systemctl reload caddy и подтвердите командой sudo ss -ltnp | grep -E ':(443|8080)' что Caddy привязан к 8080, а не к 443.

В SafeLine добавьте приложение, которое слушает 443 с включённым SSL, затем задайте upstream как http://127.0.0.1:8080. Настройку X-Forwarded-For можно оставить на варианте сетевого соединения по умолчанию, поскольку Caddy находится за SafeLine, а не перед ним.

Выберите режим защиты и убедитесь, что WAF блокирует атаки

У SafeLine три режима защиты, которые определяют, что происходит, когда движок помечает запрос как вредоносный. Правильный начальный режим зависит от приложения; шаг проверки одинаков в любом режиме.

Режимы защиты: Monitor, Balanced, Strict

Каждое приложение в SafeLine имеет собственную настройку режима защиты, задаваемую в Applications, затем ваше приложение, затем Protection Mode:

• Monitor. SafeLine регистрирует запросы, которые в ином случае заблокировал бы, но не блокирует их. Это самая безопасная отправная точка для сложного продакшен-приложения с богатыми формами ввода (форум, админ-панель с WYSIWYG-полями, API, принимающий произвольные JSON-данные). Поработайте в режиме Monitor несколько дней, просмотрите страницу Attack Events и убедитесь в отсутствии ложных срабатываний по реальным пользователям, прежде чем переходить на Balanced.
• Balanced. Режим по умолчанию. опубликованные вендором на GitHub цифры SafeLine сообщают о 71.65% обнаружения, 99.45% точности и 0.07% ложных срабатываний для режима Balanced. Для режима Strict указаны 76.17% обнаружения, 99.38% точности и 0.22% ложных срабатываний. Это результаты, заявленные вендором, а не независимый бенчмарк, и README не идентифицирует набор данных как WAF-Eval. Рассматривайте их как сравнительные показатели продукта, а не как гарантированную производительность в продакшене.
• Strict. Более агрессивный набор правил с более строгими эвристиками и показанным выше компромиссом между обнаружением и ложными срабатываниями. Стоит попробовать после недели-двух чистой работы в режиме Balanced, когда вы поймёте свой трафик.

Рекомендация: Balanced для нового развёртывания, где нет живого трафика, который можно нарушить. Для уже работающего продакшен-приложения начните с Monitor на несколько дней, ищите ложные срабатывания в журнале Attack Events и переходите на Balanced после того, как настроите исключения. Strict стоит попробовать после недели-двух работы в Balanced, когда вы поймёте свой трафик.

Проверьте WAF с помощью теста SQLi через curl

Последний шаг перед тем, как считать установку завершённой, — убедиться, что WAF действительно перехватывает атаку. Запустите безобидную тестовую SQL-инъекцию по вашему защищённому сайту с любой машины за пределами VPS:

curl -i "https://yourdomain.com/?id=1%20and%201=2%20union%20select%201"

Это опубликованный SafeLine тестовый вектор SQL-инъекции. В режиме Balanced или Strict ожидайте статус 403 и ответ SafeLine о блокировке. В режиме Monitor ожидайте, что запрос будет зарегистрирован без блокировки. Версия HTTP и точное тело ответа могут различаться, поэтому подтвердите результат соответствующей записью в Attack Events.

Затем откройте панель управления через метод ограниченного доступа из шага 4 и перейдите в Logs, затем Attack Events. Вы должны увидеть новую запись с соответствующей меткой времени, типом атаки SQL Injection, IP-адресом источника, совпадающим с машиной, с которой вы запускали curl, и содержащей нарушение строкой запроса в деталях запроса. Кликните по событию, чтобы увидеть полный запрос и ответ, зафиксированные SafeLine.

Если запрос curl вернул 200 OK, интерпретируйте результат вместе с журналом Attack Events:

• Соответствующее событие SQL Injection означает, что приложение, вероятно, работает в режиме Monitor; регистрация без блокировки ожидаема.
• Если соответствующего события нет, убедитесь, что DNS разрешается в нужный VPS, проверьте настройку слушателя и upstream в SafeLine и сопоставьте время запроса с журналом доступа SafeLine.
• Также убедитесь, что защита включена и что тестовый запрос не покрыт белым списком IP, пользовательским разрешающим правилом или исключением по пути.

Главный вывод: Если проба curl возвращает 403 со страницей перехвата SafeLine и в Attack Events появляется запись с типом атаки SQL Injection, значит WAF корректно перехватывает трафик.

Что охватывает бесплатный тариф и что требует платного плана

Бесплатного тарифа Personal достаточно для защиты большинства развёртываний на одном VPS. Платные тарифы начинают иметь значение, когда вам нужны эксплуатационные возможности (уведомления, экспорт журналов, геоблокировка) или вы перерастаете лимит в 10 приложений.

Разбивка, взятая с страницы цен CyberServal:

• Personal, бесплатно. До 10 приложений. Включает семантический движок обнаружения (SQLi, XSS, инъекции команд, обход путей, SSRF, XXE, CRLF), ограничение частоты запросов, CAPTCHA-проверку для ботов, динамическое шифрование HTML/JS против автоматических скрейперов, правила web ACL и управление сертификатами. Текущие релизы CE также включают запрос и обновление Free Cert.
• Lite, $10/месяц или $100/год. Добавляет геоблокировку, IP-базу данных threat intelligence, интеграцию уведомлений с Discord и Telegram, экспорт журналов атак и повышает лимит приложений до 20.
• Pro, $100/месяц или $1,000/год. Добавляет более мощное обнаружение атак, настройки на уровне отдельной службы и глобальные, пользовательские страницы перехвата, балансировку нагрузки upstream, синхронизацию узлов master-slave и неограниченное число приложений. См. актуальную таблицу цен для изменений.
• Ultimate, индивидуальная цена. Индивидуальные корпоративные условия с персональной поддержкой по всем каналам и разработкой пользовательских функций.

SafeLine обрабатывает и хранит данные приложений внутри своего локального стека Compose. Однако заметки к текущему релизу CE упоминают Threat Intelligence Sharing, поэтому операторам следует изучить настройки UEP, приватности и обмена данными в установленной версии и понаблюдать за исходящими соединениями, прежде чем считать развёртывание не имеющим исходящего трафика.

Что делать дальше

Установка завершена, и WAF проверен. Несколько последующих задач помогут поддерживать развёртывание в исправном состоянии.

• Для любого продакшен-приложения с богатым пользовательским вводом (форум, админ-панель, произвольный API) установите режим защиты Монитор на срок от трёх до семи дней, ежедневно просматривайте страницу Attack Events и переходите на Balanced после того, как настроите все ложные срабатывания.
• На тарифе Lite настройте интеграцию уведомлений с Discord или Telegram, чтобы оповещения об атаках доходили до вас за пределами панели управления.
• Запланируйте ежемесячное окно обслуживания. Перед обновлением сделайте резервную копию данных и конфигурации окружения SafeLine, прочитайте заметки к текущему релизу, и используйте поддерживаемую процедуру обновления для вашей установленной версии. Не полагайтесь только на docker compose pull затем выполните docker compose up -d, поскольку определение Compose или необходимые переменные окружения могут меняться между релизами. Пользователям развёртывания Cloudzy в один клик следует работать из /opt/safeline и следовать инструкциям образа из маркетплейса.
• Подпишитесь на страницу релизов SafeLine для получения уведомлений о патчах безопасности и на репозиторий проекта для отслеживания проблем.

Если у вас ещё нет VPS для этого развёртывания, SafeLine доступен как развёртывание в один клик в Маркетплейс Cloudzy. План с 4 GB RAM обеспечивает практический запас, рекомендованный в этом руководстве; перепроверьте актуальную таблицу цен на Cloudzy на момент публикации, поскольку характеристики плана могут меняться. Образ, устанавливаемый в один клик, использует /opt/safeline и /opt/safeline/docker-compose.yml, поэтому инструкции по архитектуре и панели управления применимы, но приведённые в этом руководстве /data/safeline команды применяются не идентично.

Часто задаваемые вопросы

Заменяет ли SafeLine WAF Nginx Proxy Manager или их запускают вместе?

SafeLine может заменить Nginx Proxy Manager при развёртывании в качестве единственного обратного прокси. Однако заменять NPM не обязательно. Распространённая конфигурация оставляет NPM впереди для SSL и маршрутизации и располагает SafeLine за ним как отдельный уровень безопасности. Оба варианта работают; выбор зависит от того, хотите ли вы, чтобы один инструмент выполнял обе задачи, или два инструмента, каждый из которых хорошо делает одну задачу.

Достаточно ли бесплатного тарифа для одного сайта WordPress или небольшого SaaS?

Да, для защиты. Бесплатный тариф Personal включает семантический движок обнаружения, ограничение частоты запросов, CAPTCHA-проверку для ботов и динамическое шифрование HTML/JS — это основные средства защиты для одного сайта. Платные тарифы добавляют эксплуатационные возможности, такие как геоблокировка, экспорт журналов атак, внешние уведомления, более высокие лимиты приложений, более мощное обнаружение и балансировку нагрузки. Нужен ли платный тариф, зависит от требуемых функций и числа приложений, а не только от объёма трафика.

Работает ли SafeLine на VPS с 1 GB RAM?

SafeLine официальный минимум составляет 1 GB RAM. Этого может хватить для тестирования или очень лёгкой нагрузки, но продакшен-ёмкость зависит от трафика, включённых функций и хранения журналов. Для небольшого продакшен-развёртывания 2 vCPU и 4 GB RAM — это консервативная отправная точка; отслеживайте использование памяти и масштабируйтесь исходя из измеренной нагрузки.

Почему ARM64 требует платной лицензии?

SafeLine официальная документация по развёртыванию SafeLine указывает, что развёртывания на ARM требуют лицензию Pro и что Personal Edition не поддерживается на ARM. Если вам нужен Personal Edition, выберите VPS на x86_64; если вам требуется ARM, планируйте лицензию Pro.

Что Chaitin Tech получает от моего экземпляра SafeLine?

Точный состав исходящих данных может различаться в зависимости от релиза и включённых функций. Заметки к текущему релизу CE упоминают Threat Intelligence Sharing, при этом установленная версия может также предоставлять UEP или другие настройки обмена данными. Изучите эти настройки и заметки к релизу для вашей установленной версии, затем проверьте исходящий трафик на сетевом уровне. Локальные контейнеры SafeLine обрабатывают данные приложений, но один этот факт не доказывает, что отказ от UEP останавливает каждый исходящий запрос.