Jak wdrożyć SafeLine WAF na serwerze VPS z systemem Linux

Aplikacje internetowe dostępne publicznie są rutynowo skanowane pod kątem wstrzyknięć SQL, nadużyć poświadczeń i wzorców znanych podatności. SafeLine to samodzielnie hostowany WAF na licencji GPL-3.0 który działa jako stos Docker Compose i filtruje ruch HTTP/S, zanim przekaże dozwolone żądania do serwera źródłowego. Jego darmowy plan Personal obsługuje do 10 aplikacji.

Ten poradnik obejmuje instalację oraz trzy obszary wymagające szczególnej uwagi: decyzję o architekturze reverse proxy, konfigurację sieci Docker, gdy SafeLine działa za istniejącym proxy takim jak Nginx Proxy Manager, oraz polecenie weryfikacyjne, które możesz uruchomić po instalacji, aby potwierdzić, że WAF faktycznie przechwytuje ataki.

Krótka wersja

• Zainstaluj SafeLine na VPS z systemem Linux przy użyciu Docker Compose. Skorzystaj z jednowierszowego instalatora lub wybierz ręczną ścieżkę Docker Compose, aby przejrzeć definicję Compose i konfigurację środowiska przed uruchomieniem stosu.
• Zdecyduj o architekturze reverse proxy przed instalacją: SafeLine jako jedyne proxy, SafeLine za istniejącym Nginx Proxy Manager lub SafeLine współdzielący serwer z Caddy. Każdy wariant wymaga innego przydziału portów i innych ustawień X-Forwarded-For.
• Po instalacji sprawdź WAF, wysyłając za pomocą curl próbne wstrzyknięcie SQL na chroniony adres URL. W trybie Balanced lub Strict odpowiedź 403 wraz z pasującym wpisem w Attack Events potwierdza blokowanie. W trybie Monitor pasujące zdarzenie potwierdza wykrycie, nawet jeśli odpowiedź pozostanie pomyślna.
• Darmowy poziom Personal obejmuje do 10 aplikacji oraz podstawowy silnik detekcji. Blokowanie geograficzne, eksport dzienników ataków i powiadomienia zewnętrzne wymagają poziomu Lite; skuteczniejsze wykrywanie ataków i równoważenie obciążenia wymagają Pro.

Zanim zaczniesz: wymagania wstępne i zakres tego poradnika

Ten poradnik zakłada, że masz VPS z systemem Linux, do którego możesz zalogować się przez SSH z dostępem root lub sudo, oraz że Docker jest zainstalowany. Na koniec będziesz mieć działającą instancję SafeLine chroniącą co najmniej jedną witrynę oraz polecenie weryfikacyjne, które możesz uruchomić w dowolnym momencie.

Potrzebujesz:

• VPS z systemem Linux. Poniższe polecenia zakładają system w stylu Debian lub Ubuntu z systemd; na innych dystrybucjach sprawdź nazwy pakietów i usług.
• Co najmniej 1 vCPU, 1 GB RAM i 5 GB dysku zgodnie z oficjalnymi wymaganiami wdrożeniowymi. Aby zapewnić praktyczny zapas na potrzeby produkcyjne, ten przewodnik zaleca 2 vCPU, 4 GB RAM i 20 GB dysku.
• Docker 20.10.14 lub nowszy oraz Docker Compose 2.0 lub nowszy.
• Procesor x86_64 z obsługą SSSE3; sprawdź to za pomocą lscpu | grep ssse3 zamiast zakładać, że instrukcja jest dostępna.
• Domenę lub subdomenę z DNS wskazującym na publiczny adres IP VPS, jeśli planujesz udostępniać chronioną aplikację przez publiczne HTTPS.
• Porty odpowiednie do wybranej topologii. Warianty A i C zwykle przydzielają SafeLine porty 80 i 443, natomiast wariant B pozostawia te porty przy Nginx Proxy Manager i przypisuje SafeLine inny nasłuch, taki jak 10080.
• Dostęp root lub sudo.

Na zaporze lub w grupie zabezpieczeń dostawcy VPS udostępnij tylko te porty publiczne, których wymaga wybrana topologia. Ogranicz SSH i TCP 9443 do zaufanych źródeł administracyjnych. W wariancie B pozostaw TCP 10080 zamknięty dla publicznego IPv4 i IPv6, a porty backendu takie jak 8080 utrzymuj jako prywatne w każdej topologii. Bezpośredni dostęp do 10080 omijałby NPM i unieważniał granicę zaufania X-Forwarded-For.

Uwaga: W przypadku ręcznego wdrożenia na ARM64 ustaw ARCH_SUFFIX=-arm. Dokumentacja oficjalna dokumentacja wdrożeniowa SafeLine stwierdza, że ARM wymaga licencji Pro oraz że edycja Personal nie jest obsługiwana na ARM. W przypadku edycji Personal użyj VPS x86_64.

Sprawdź Docker przed rozpoczęciem:

docker --version
docker compose version

Oba polecenia powinny zwrócić zainstalowane wersje. Kontynuuj tylko wtedy, gdy Docker jest w wersji 20.10.14 lub nowszej, a Docker Compose w wersji 2.0.0 lub nowszej; w przeciwnym razie zaktualizuj je przed instalacją SafeLine.

Najpierw wybierz architekturę reverse proxy

Świeży VPS pozwala SafeLine w pełni przejąć porty 80 i 443. VPS, na którym już działa Nginx Proxy Manager, Caddy lub własny Nginx aplikacji, tego nie umożliwia, a decyzja o architekturze stanowi różnicę między płynną instalacją a konfliktem portów przy pierwszym uruchomieniu. Zrób to raz dobrze na starcie, a reszta wdrożenia będzie czysto mechaniczna.

Trzy warianty:

• Wariant A, SafeLine jako jedyne reverse proxy. SafeLine przejmuje porty 80 i 443 oraz zarządza TLS dla chronionej aplikacji. Bieżące wydania CE obejmują proces Free Cert, przy czym ręczne przesyłanie certyfikatu pozostaje dostępne; sprawdź dokładne opcje certyfikatów w zainstalowanym wydaniu. Backend działa na porcie niepublicznym, a SafeLine kieruje do niego ruch.
• Wariant B, SafeLine za Nginx Proxy Manager (NPM). NPM zachowuje porty 80 i 443 oraz obsługuje SSL. SafeLine nasłuchuje na porcie 10080 (tylko HTTP, ponieważ NPM już zakończył obsługę TLS). NPM przekazuje ruch do SafeLine; SafeLine przekazuje go do backendu. To częsta konfiguracja, gdy NPM jest już wdrożony.
• Wariant C, SafeLine obok Caddy. Automatyczne HTTPS w Caddy rywalizuje z SafeLine o port 443. Działające rozwiązanie przydziela SafeLine porty 80 i 443 oraz przenosi Caddy na niepubliczny wewnętrzny port HTTP, taki jak 8080, dla przeskoku SafeLine do Caddy do aplikacji.

Kluczowy wniosek: Wariant A jest najprostszy dla świeżego VPS; wariant B to właściwy wybór, gdy NPM już działa; wariant C wymaga świadomej zmiany przydziału portów Caddy.

Zainstaluj SafeLine na swoim VPS

Sama instalacja to najprostsza część. SafeLine udostępnia dwie ścieżki instalacji: zautomatyzowany instalator, który pobiera zdalny skrypt z waf.chaitin.com, oraz ręczną ścieżkę Docker Compose, która pozwala sprawdzić wszystko przed uruchomieniem. Wybierz tę, która odpowiada Twojej polityce bezpieczeństwa.

Krok 1: Potwierdź, że Docker jest gotowy

Ponownie sprawdź wersję Docker oraz to, czy demon Docker działa:

docker --version
docker compose version
sudo systemctl status docker

Oczekiwane dane wyjściowe zawierają active (running) dla demona Docker. Jeśli nie działa, uruchom go za pomocą sudo systemctl start docker i włącz jego uruchamianie przy starcie za pomocą sudo systemctl enable docker.

Krok 2: Uruchom instalator SafeLine

Istnieją dwie ścieżki podrzędne. Wybierz jedną.

Krok 2a, instalacja automatyczna. Uruchom instalator z uprawnieniami root:

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

Skrypt pyta, gdzie umieścić katalog danych SafeLine, pobiera obrazy Docker i uruchamia stos. Po instalacji uruchom sudo docker exec safeline-mgt resetadmin aby pobrać lub zresetować poświadczenia administratora, jak opisano w oficjalnym przewodniku wdrożeniowym. Przechowuj uzyskane poświadczenia w bezpiecznym miejscu.

Uwaga: To polecenie pobiera i wykonuje zdalny skrypt powłoki z waf.chaitin.com z uprawnieniami root. Oficjalny jednowierszowiec zawiera curl -k, co wyłącza weryfikację certyfikatu TLS. Przejrzyj pobrany skrypt przed wykonaniem lub skorzystaj z kroku 2b, jeśli to ryzyko jest nie do przyjęcia. SafeLine jest również dostępny jako wdrożenie Cloudzy jednym kliknięciem, ale ten obraz używa /opt/safeline, /opt/safeline/.env oraz /opt/safeline/docker-compose.yml. Nie stosuj z tego przewodnika /data/safeline ścieżek bez zmian na obrazie Cloudzy.

Krok 2b, ręczna instalacja Docker Compose. Pobierz i przejrzyj oficjalny plik Compose, a następnie uruchom stos:

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

Po docker compose up -d zakończy się, wyświetl listę działających kontenerów, aby to potwierdzić:

sudo docker compose ps

Powinieneś zobaczyć kontenery safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi oraz safeline-chaos. Jeśli którykolwiek kontener pokazuje Exited, zobacz krok 3, aby poznać dwie najczęstsze przyczyny.

Krok 3: Rozwiąż typowe błędy instalacji

Dwa błędy pojawiają się na tyle często, że zasługują na osobny krok.

Nakładanie się podsieci. Jeśli instalacja kończy się niepowodzeniem z komunikatem Pool overlaps with other one on this address space, domyślna podsieć SafeLine koliduje z istniejącą siecią Docker. Jak udokumentowano w przewodniku rozwiązywania problemów z instalacją SafeLine, napraw to, edytując /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

Błąd resolvera IPv6. Jeśli safeline-tengine ulega awarii z komunikatem nginx: [emerg] invalid IPv6 address in resolver, najpierw sprawdź plik resolvera i ustal, kto nim zarządza:

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

Nie edytuj /etc/resolv.conf bezpośrednio, jeśli jest generowany przez systemd-resolved, NetworkManager lub dostawcę VPS. Popraw błędną wartość nameservera w konfiguracji zarządzającej usługi, wygeneruj ponownie plik resolvera, a następnie zrestartuj Tengine:

sudo docker restart safeline-tengine

Krok 4: Uzyskaj dostęp do panelu

Panel zarządzania SafeLine nasłuchuje na TCP 9443 przez HTTPS. Nie pozostawiaj tego portu administracyjnego otwartego dla całego internetu. Ogranicz go do zaufanego adresu źródłowego lub VPN albo zablokuj dostęp publiczny i użyj tunelu SSH:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Otwórz https://localhost:9443 przez tunel. Ostrzeżenie o certyfikacie z podpisem własnym jest oczekiwane przy pierwszym dostępie; przed kontynuacją sprawdź, czy połączenie SSH dotarło do właściwego serwera.

Jeśli utraciłeś początkowe poświadczenia, zresetuj hasło administratora z poziomu hosta:

sudo docker exec safeline-mgt resetadmin

Polecenie wyświetla poświadczenia administratora, których możesz użyć, aby ponownie się zalogować.

Skonfiguruj SafeLine dla swojej architektury

SafeLine już działa, ale nie chroni jeszcze niczego. Na stronie Applications w panelu wskazujesz SafeLine, które witryny chronić i dokąd przekazywać oczyszczony ruch. Konfiguracja różni się w zależności od architektury wybranej wcześniej, dlatego każdy wariant ma własną podsekcję. Przejdź tylko przez tę, która odpowiada Twojej konfiguracji.

Wariant A: SafeLine jako jedyne reverse proxy

W wariancie A SafeLine nasłuchuje bezpośrednio na portach 80 i 443 oraz przekazuje oczyszczony ruch do aplikacji backendowej na porcie niepublicznym. W panelu:

1. Przejdź do Applications, następnie Add Application.
2. Ustaw port nasłuchu na 443 i włącz SSL. Skorzystaj z procesu certyfikatów dostępnego w zainstalowanym wydaniu SafeLine. Bieżące wydania CE obejmują aplikowanie o Free Cert i obsługę odnawiania, przy czym ręczne przesyłanie certyfikatu pozostaje dostępne.
3. Ustaw upstream na http://127.0.0.1:8080. Jeśli backend działa w Dockerze, publikuj jego port tylko na loopbacku, na przykład "127.0.0.1:8080:8080" w sekcji ports usługi. Unikaj zakodowanego na stałe adresu IP kontenera, takiego jak 172.17.0.5 ponieważ może się on zmienić przy ponownym utworzeniu kontenera.
4. Zapisz aplikację. SafeLine natychmiast zaczyna nasłuchiwać na 443 i przekazywać oczyszczony ruch do backendu.
5. Potwierdź, że rekord DNS A Twojej domeny wskazuje na publiczny adres IP VPS oraz że porty 80 i 443 są osiągalne z zewnątrz.

Jeśli port 443 był już zajęty przez inny proces, kontener SafeLine nie zdoła się do niego podłączyć, a panel wyświetli błąd dla tej aplikacji. Przed dodaniem aplikacji zatrzymaj kolidujący proces lub wybierz inny port.

Wariant B: SafeLine za Nginx Proxy Manager

Wariant B pozostawia NPM przy tym, co już robi (przejmowanie portów 80 i 443, obsługa Let's Encrypt) i umieszcza SafeLine za nim jako dedykowaną warstwę zabezpieczeń. Przepływ ruchu wygląda tak: klient, następnie NPM (port 443, zakończenie TLS), następnie SafeLine (port 10080, HTTP), następnie aplikacja backendowa.

W panelu SafeLine:

1. Applications, następnie Add Application. Ustaw port nasłuchu na 10080 i pozostaw SSL wyłączony (NPM już zakończył obsługę TLS).
2. Ustaw upstream na wewnętrzny adres aplikacji, jak opisano w wariancie A.
3. Zapisz aplikację.

W Nginx Proxy Manager:

1. Hosts, następnie Proxy Hosts, następnie Add Proxy Host.
2. Zakładka Details: ustaw nazwę domeny, schemat http, oraz port przekierowania 10080. Jeśli NPM działa bezpośrednio na hoście, użyj 127.0.0.1 jako nazwy hosta przekierowania. Jeśli NPM działa w Dockerze na Linuksie, 127.0.0.1 wskazuje na kontener NPM, a nie na hosta VPS. Dodaj do usługi NPM Compose mapowanie host-gateway Dockera , a następnie użyj host.docker.internal jako nazwy hosta przekierowania:

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

Z katalogu NPM Compose uruchom sudo docker compose up -d aby kontener został ponownie utworzony z nowym mapowaniem hosta.

3. Zakładka SSL: poproś o certyfikat Let's Encrypt, wymuś SSL i włącz HTTP/2.
4. Pozostaw zakładkę Advanced w NPM pustą w odniesieniu do X-Forwarded-For. W bieżącym szablonie NPM, zawartość Advanced jest wstawiana na poziomie server i nie nadpisuje wygenerowanych nagłówków na poziomie location zgodnie z regułami dziedziczenia NGINX. Wygenerowana lokalizacja wysyła:

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

Druga dyrektywa dołącza adres zaobserwowany przez NPM jako skrajnie prawą wartość w nagłówku.

5. Zapisz Proxy Host.

Wracając do SafeLine, skonfiguruj wyodrębnianie źródłowego IP dopiero po potwierdzeniu rzeczywistego łańcucha nagłówków. SafeLine 9.3.1 wprowadził elastyczne wyodrębnianie XFF z wyborem kierunku i indeksu.

1. Settings, następnie Advanced, następnie Real IP from Header. Ustaw nazwę nagłówka na X-Forwarded-For.
2. Użyj niestandardowego wyodrębniania od końca nagłówka i wybierz skrajnie prawy adres dodany przez NPM. Dokładne etykiety indeksów różnią się w zależności od wersji, dlatego sprawdź wynik w Logs, następnie Access. Jeśli zainstalowane wydanie jest starsze niż 9.3.1, zaktualizuj je przed zastosowaniem tej topologii.
3. Jeśli przed NPM znajduje się Cloudflare lub inny CDN, najpierw skonfiguruj NPM tak, aby ufał wyłącznie opublikowanym zakresom proxy tego dostawcy, dzięki czemu adres dołączony przez NPM będzie wiarygodny. Nie wybieraj stałej pozycji, dopóki nie sprawdzisz i nie przetestujesz rzeczywistego łańcucha nagłówków.
4. Zapisz i przeładuj aplikację.

Przetestuj konfigurację z komputera spoza VPS:

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

Dziennik dostępu SafeLine powinien pokazywać Twój rzeczywisty adres publiczny, a nie 1.2.3.4 ani adres mostka NPM.

Uniemożliw użytkownikom ominięcie SafeLine, utrzymując nasłuch backendu jako prywatny. W przypadku backendu Docker Compose publikuj port tylko na loopbacku:

ports:
  - "127.0.0.1:8080:8080"

W przypadku usługi działającej bezpośrednio na hoście skonfiguruj ją tak, aby nasłuchiwała na 127.0.0.1:8080 zamiast 0.0.0.0:8080. Sprawdź oba wewnętrzne porty z komputera spoza VPS:

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

Połączenia TCP powinny zostać odrzucone lub przekroczyć limit czasu. Błąd HTTP lub „Empty reply from server" nadal oznacza, że port jest publicznie osiągalny i musi zostać zabezpieczony. Jeśli powiązanie z loopbackiem jest niemożliwe, utwórz reguły zapory dostosowane do rzeczywistego interfejsu, sieci Docker i kontenera docelowego, zamiast stosować ogólną regułę DOCKER-USER.

Wariant C: SafeLine z Caddy

W wariancie C SafeLine przejmuje porty 80 i 443; Caddy przenosi się na niepubliczny wewnętrzny port HTTP. Przepływ ruchu wygląda tak: klient, następnie SafeLine (443, TLS), następnie Caddy (8080, wewnętrzne HTTP), następnie backend aplikacji.

Edytuj /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

Zdalny :8080 blok witryny jest istotną częścią: Caddy nasłuchuje teraz na wewnętrznym porcie HTTP zamiast rywalizować z SafeLine o port 443. Linia bind 127.0.0.1 utrzymuje ten nasłuch lokalnie na VPS. Przeładuj Caddy za pomocą sudo systemctl reload caddy i potwierdź za pomocą sudo ss -ltnp | grep -E ':(443|8080)' że Caddy jest powiązany z portem 8080, a nie 443.

W SafeLine dodaj aplikację, która nasłuchuje na 443 z włączonym SSL, a następnie ustaw upstream na http://127.0.0.1:8080. Ustawienie X-Forwarded-For może pozostać na domyślnej opcji połączenia sieciowego, ponieważ Caddy znajduje się za SafeLine, a nie przed nim.

Wybierz tryb ochrony i sprawdź, czy WAF blokuje ataki

SafeLine ma trzy tryby ochrony, które decydują o tym, co dzieje się, gdy silnik oznaczy żądanie jako złośliwe. Właściwy tryb startowy zależy od aplikacji; krok weryfikacji jest taki sam w każdym trybie.

Tryby ochrony: Monitor, Balanced, Strict

Każda aplikacja w SafeLine ma własne ustawienie trybu ochrony, konfigurowalne w Applications, następnie Twoja aplikacja, następnie Protection Mode:

• Monitor. SafeLine rejestruje żądania, które w przeciwnym razie by zablokował, ale ich nie blokuje. To najbezpieczniejszy punkt startowy dla złożonej aplikacji produkcyjnej z rozbudowanymi formularzami wejściowymi (forum, panel administracyjny z polami WYSIWYG, API przyjmujące dowolne ładunki JSON). Uruchom Monitor na kilka dni, przejrzyj stronę Attack Events i potwierdź brak fałszywych alarmów wobec prawdziwych użytkowników, zanim przejdziesz na Balanced.
• Balanced. Tryb domyślny. opublikowane przez dostawcę na GitHub dane podają 71.65% wykrywalności, 99.45% dokładności i 0.07% wskaźnika fałszywych alarmów dla trybu Balanced. Dla trybu Strict podawane jest 76.17% wykrywalności, 99.38% dokładności i 0.22% wskaźnika fałszywych alarmów. Są to wyniki zgłoszone przez dostawcę, a nie niezależny benchmark, a plik README nie identyfikuje zbioru danych jako WAF-Eval. Traktuj je jako porównawcze dane produktowe, a nie gwarantowaną wydajność produkcyjną.
• Strict. Bardziej agresywny zestaw reguł ze ściślejszymi heurystykami i kompromisem między wykrywalnością a fałszywymi alarmami przedstawionym powyżej. Warto go wypróbować po tygodniu lub dwóch bezproblemowego działania w trybie Balanced, gdy już rozumiesz swój ruch.

Zalecenie: Balanced dla świeżego wdrożenia bez ruchu produkcyjnego, który mógłby zostać zakłócony. Dla istniejącej aplikacji produkcyjnej zacznij od trybu Monitor na kilka dni, szukaj fałszywych alarmów w dzienniku Attack Events i przejdź na Balanced po dostrojeniu ewentualnych wyjątków. Strict warto wypróbować po tygodniu lub dwóch działania w trybie Balanced, gdy już rozumiesz swój ruch.

Sprawdź WAF za pomocą testu SQLi z curl

Ostatnim krokiem przed uznaniem instalacji za zakończoną jest potwierdzenie, że WAF faktycznie przechwytuje atak. Uruchom nieszkodliwą próbę wstrzyknięcia SQL wobec chronionej witryny z dowolnego komputera spoza VPS:

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

To opublikowany przez SafeLine wektor testowy wstrzyknięcia SQL. W trybie Balanced lub Strict oczekuj statusu 403 i odpowiedzi blokującej SafeLine. W trybie Monitor oczekuj, że żądanie zostanie zarejestrowane bez blokowania. Wersja HTTP i dokładna treść odpowiedzi mogą się różnić, dlatego potwierdź wynik pasującym wpisem w Attack Events.

Następnie otwórz panel za pomocą metody ograniczonego dostępu z kroku 4 i przejdź do Logs, następnie Attack Events. Powinieneś zobaczyć nowy wpis z pasującym znacznikiem czasu, typem ataku SQL Injection, źródłowym IP odpowiadającym komputerowi, z którego uruchomiłeś curl, oraz problematycznym ciągiem zapytania w szczegółach żądania. Kliknij zdarzenie, aby zobaczyć pełne żądanie i odpowiedź przechwycone przez SafeLine.

Jeśli żądanie curl zwróciło 200 OK, zinterpretuj wynik w połączeniu z dziennikiem Attack Events:

• Pasujące zdarzenie SQL Injection oznacza, że aplikacja jest prawdopodobnie w trybie Monitor; rejestrowanie bez blokowania jest oczekiwane.
• Jeśli nie ma pasującego zdarzenia, potwierdź, że DNS rozwiązuje się do właściwego VPS, sprawdź nasłuch SafeLine i konfigurację upstream oraz skoreluj czas żądania z dziennikiem dostępu SafeLine.
• Potwierdź również, że ochrona jest włączona i że żadna biała lista IP, niestandardowa reguła zezwalająca ani wyjątek ścieżki nie obejmuje testowego żądania.

Kluczowy wniosek: Jeśli próba curl zwraca 403 ze stroną przechwycenia SafeLine, a w Attack Events pojawia się wpis z typem ataku SQL Injection, WAF poprawnie przechwytuje ruch.

Co obejmuje poziom darmowy, a co wymaga planu płatnego

Darmowy poziom Personal wystarcza do ochrony większości wdrożeń na pojedynczym VPS. Poziomy płatne zaczynają mieć znaczenie, gdy potrzebujesz funkcji operacyjnych (powiadomienia, eksport dzienników, blokowanie geograficzne) lub przekraczasz limit 10 aplikacji.

Zestawienie na podstawie strony cennika CyberServal:

• Personal, darmowy. Do 10 aplikacji. Obejmuje semantyczny silnik detekcji (SQLi, XSS, wstrzykiwanie poleceń, path traversal, SSRF, XXE, CRLF), ograniczanie liczby żądań, wyzwanie CAPTCHA dla botów, dynamiczne szyfrowanie HTML/JS przeciw automatycznym scraperom, reguły ACL dla sieci web oraz zarządzanie certyfikatami. Bieżące wydania CE obejmują również aplikowanie o Free Cert i obsługę odnawiania.
• Lite, $10/miesiąc lub $100/rok. Dodaje blokowanie geograficzne, bazę IP threat intelligence, integrację powiadomień Discord i Telegram, eksport dzienników ataków oraz podnosi limit aplikacji do 20.
• Pro, $100/miesiąc lub $1,000/rok. Dodaje skuteczniejsze wykrywanie ataków, konfiguracje per-usługa i globalne, niestandardowe strony przechwytujące, równoważenie obciążenia upstream, synchronizację węzłów master-slave oraz nieograniczoną liczbę aplikacji. Zobacz bieżącą tabelę cennika aby poznać zmiany.
• Ultimate, cennik indywidualny. Dostosowane warunki korporacyjne z indywidualnym wsparciem w wielu kanałach i rozwojem funkcji na zamówienie.

SafeLine przetwarza i przechowuje dane aplikacji w swoim lokalnym stosie Compose. Jednak bieżące uwagi do wydania CE wspominają o Threat Intelligence Sharing, dlatego operatorzy powinni przejrzeć w zainstalowanej wersji ustawienia UEP, prywatności i udostępniania oraz obserwować połączenia wychodzące, zanim uznają wdrożenie za pozbawione ruchu wychodzącego.

Co dalej

Instalacja jest zakończona, a WAF sprawdzony. Kilka dalszych zadań pomoże utrzymać wdrożenie w dobrej kondycji.

• Dla każdej aplikacji produkcyjnej z rozbudowanym wejściem użytkownika (forum, panel administracyjny, dowolne API) ustaw tryb ochrony na Monitor na okres od trzech do siedmiu dni, codziennie przeglądaj stronę Attack Events i przejdź na Balanced po dostrojeniu ewentualnych fałszywych alarmów.
• Na poziomie Lite skonfiguruj integrację powiadomień Discord lub Telegram, aby alerty o atakach docierały do Ciebie poza panelem.
• Zaplanuj comiesięczne okno konserwacji. Przed aktualizacją wykonaj kopię zapasową danych i konfiguracji środowiska SafeLine, przeczytaj bieżące uwagi do wydania, i zastosuj obsługiwaną procedurę aktualizacji dla zainstalowanej wersji. Nie polegaj wyłącznie na docker compose pull następnie docker compose up -d, ponieważ definicja Compose lub wymagane zmienne środowiskowe mogą się zmieniać między wydaniami. Użytkownicy Cloudzy jednym kliknięciem powinni działać w oparciu o /opt/safeline i postępować zgodnie z instrukcjami obrazu z marketplace.
• Subskrybuj stronę wydań SafeLine aby otrzymywać powiadomienia o poprawkach zabezpieczeń, oraz repozytorium projektu aby śledzić zgłoszenia.

Jeśli nie masz jeszcze VPS pod to wdrożenie, SafeLine jest dostępny jako wdrożenie jednym kliknięciem w Marketplace Cloudzy. Plan z 4 GB RAM zapewnia praktyczny zapas zalecany w tym przewodniku; sprawdź ponownie bieżącą tabelę cennika na Cloudzy w momencie publikacji, ponieważ specyfikacje planów mogą się zmieniać. Obraz jednym kliknięciem używa /opt/safeline oraz /opt/safeline/docker-compose.yml, więc instrukcje dotyczące architektury i panelu mają zastosowanie, ale zawarte w tym przewodniku /data/safeline polecenia nie mają identycznego zastosowania.

Często zadawane pytania

Czy SafeLine WAF zastępuje Nginx Proxy Manager, czy uruchamiam oba?

SafeLine może zastąpić Nginx Proxy Manager, gdy jest wdrożony jako jedyne reverse proxy. Nie musi jednak zastępować NPM. Częsta konfiguracja pozostawia NPM z przodu do obsługi SSL i routingu, a SafeLine umieszcza za nim jako dedykowaną warstwę zabezpieczeń. Oba podejścia działają; wybór zależy od tego, czy chcesz jednego narzędzia wykonującego oba zadania, czy dwóch narzędzi, z których każde dobrze wykonuje jedno zadanie.

Czy poziom darmowy wystarcza dla pojedynczej witryny WordPress lub małego SaaS?

Tak, jeśli chodzi o ochronę. Darmowy poziom Personal obejmuje semantyczny silnik detekcji, ograniczanie liczby żądań, wyzwanie CAPTCHA dla botów oraz dynamiczne szyfrowanie HTML/JS, które są podstawowymi mechanizmami obronnymi dla pojedynczej witryny. Poziomy płatne dodają funkcje operacyjne, takie jak blokowanie geograficzne, eksport dzienników ataków, powiadomienia zewnętrzne, wyższe limity aplikacji, skuteczniejsze wykrywanie i równoważenie obciążenia. To, czy poziom płatny jest konieczny, zależy od wymaganych funkcji i liczby aplikacji, a nie od samego natężenia ruchu.

Czy SafeLine działa na VPS z 1 GB RAM?

Oficjalne minimum SafeLine to 1 GB RAM. To może wystarczyć do testów lub bardzo lekkiego obciążenia, ale wydajność produkcyjna zależy od ruchu, włączonych funkcji i retencji dzienników. Dla małego wdrożenia produkcyjnego 2 vCPU i 4 GB RAM to ostrożny punkt wyjścia; monitoruj zużycie pamięci i skaluj na podstawie zmierzonego obciążenia.

Dlaczego ARM64 wymaga płatnej licencji?

Oficjalne oficjalna dokumentacja wdrożeniowa SafeLine stwierdza, że wdrożenia na ARM wymagają licencji Pro oraz że edycja Personal nie jest obsługiwana na ARM. Jeśli chcesz korzystać z edycji Personal, wybierz VPS x86_64; jeśli potrzebujesz ARM, zaplanuj licencję Pro.

Co Chaitin Tech otrzymuje z mojej instancji SafeLine?

Dokładny zakres danych wychodzących może się różnić w zależności od wydania i włączonych funkcji. Bieżące uwagi do wydania CE wspominają o Threat Intelligence Sharing, a zainstalowana wersja może również udostępniać UEP lub inne mechanizmy udostępniania. Przejrzyj te ustawienia i uwagi do wydania dla zainstalowanej wersji, a następnie zweryfikuj ruch wychodzący na poziomie sieci. Lokalne kontenery SafeLine obsługują dane aplikacji, ale sam ten fakt nie dowodzi, że odrzucenie UEP zatrzymuje każde żądanie wychodzące.