Як розгорнути 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. Не використовуйте наведені в цьому посібнику /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 до служби Compose для NPM, потім використовуйте 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 блок сайту — це важлива частина: 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 повідомляють про 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-адрес аналітики загроз, інтеграцію сповіщень 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 зупиняє кожен вихідний запит.