インターネットに公開された Web アプリケーションは、SQL インジェクション、認証情報の悪用、既知の脆弱性パターンを日常的に探られています。SafeLine は GPL-3.0 のセルフホスト型 WAF であり、Docker Compose スタックとして動作し、許可されたリクエストをオリジンに転送する前に HTTP/S トラフィックをフィルタリングします。その 無料の Personal プラン は最大 10 アプリケーションまで対応します。
このチュートリアルでは、インストールと、特に注意が必要な 3 つの領域を扱います。リバースプロキシのアーキテクチャの決定、SafeLine が Nginx Proxy Manager のような既存のプロキシの背後に配置される場合の Docker ネットワーク構成、そしてインストール後に実行して WAF が実際に攻撃を遮断していることを確認できる検証コマンドです。
短いバージョン
- Docker Compose を使って Linux VPS に SafeLine をインストールします。ワンラインインストーラーを使うか、スタックを起動する前に Compose 定義と環境構成を確認するために手動の Docker Compose 手順を選びます。
- インストールの前にリバースプロキシのアーキテクチャを決めます。SafeLine を唯一のプロキシとする、既存の Nginx Proxy Manager の背後に SafeLine を置く、または Caddy と同じサーバーで SafeLine を共存させる、のいずれかです。各構成では異なるポート割り当てと X-Forwarded-For 設定が必要になります。
- インストール後、保護対象の URL に curl で SQL インジェクションのプローブを送信して WAF を検証します。Balanced または Strict モードでは、403 レスポンスと一致する Attack Events エントリがブロックを裏付けます。Monitor モードでは、レスポンスが成功のままでも、一致するイベントが検出を裏付けます。
- 無料の Personal ティアは最大 10 アプリケーションとコア検出エンジンをカバーします。地域ブロック、攻撃ログのエクスポート、外部通知には Lite ティアが必要で、より強力な攻撃検出と負荷分散には Pro が必要です。
始める前に：前提条件とこのチュートリアルが扱う内容
このチュートリアルは、root または sudo アクセスで SSH できる Linux VPS があり、Docker がインストールされていることを前提とします。読み終える頃には、少なくとも 1 つのサイトを保護する動作中の SafeLine インスタンスと、いつでも再実行できる検証コマンドが手に入ります。
必要なもの：
- Linux VPS。以下のコマンドは systemd を備えた Debian または Ubuntu 系のシステムを前提としています。他のディストリビューションではパッケージ名とサービス名を確認してください。
- 少なくとも 1 vCPU、1 GB RAM、5 GB のディスク。これは 公式のデプロイ要件によります。実運用で余裕を持たせるため、本ガイドでは 2 vCPU、4 GB RAM、20 GB のディスクを推奨します。
- Docker 20.10.14 以降および Docker Compose 2.0 以降。
- SSSE3 をサポートする x86_64 CPU。次のコマンドで確認します
lscpu | grep ssse3命令が存在すると決めつけないでください。 - 保護対象アプリケーションを公開 HTTPS で公開する予定がある場合は、DNS が VPS のパブリック IP を指しているドメインまたはサブドメイン。
- 選択したトポロジーに適したポート。構成 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 には x86_64 の VPS を使用してください。
開始前に Docker を確認します：
docker --version
docker compose versionどちらのコマンドもインストール済みのバージョンを返すはずです。Docker がバージョン 20.10.14 以降で、Docker Compose がバージョン 2.0.0 以降の場合にのみ続行してください。そうでない場合は、SafeLine をインストールする前にアップグレードしてください。
まずリバースプロキシのアーキテクチャを選ぶ
新規の VPS なら SafeLine にポート 80 と 443 をそのまま所有させられます。すでに Nginx Proxy Manager、Caddy、またはアプリケーション自身の Nginx を実行している VPS ではそうはいかず、このアーキテクチャの決定が、スムーズなインストールと初回起動時のポート競合との分かれ目になります。最初に一度これを正しく決めておけば、残りのデプロイは機械的に進みます。
3 つの構成：
- 構成 A、SafeLine を唯一のリバースプロキシとする。 SafeLine がポート 80 と 443 を所有し、保護対象アプリケーションの TLS を管理します。 現行の CE リリース には Free Cert のワークフローが含まれ、手動での証明書アップロードも引き続き利用できます。正確な証明書オプションはインストール済みのリリースで確認してください。バックエンドは非公開ポートで動作し、SafeLine がそこへルーティングします。
- 構成 B、Nginx Proxy Manager（NPM）の背後に SafeLine を置く。 NPM がポート 80 と 443 を保持し、SSL を処理します。SafeLine はポート 10080 で待ち受けます（NPM がすでに TLS を終端しているため HTTP のみ）。NPM が SafeLine に転送し、SafeLine がバックエンドに転送します。これは NPM がすでにデプロイされている場合によくある構成です。
- 構成 C、Caddy と並べて SafeLine を置く。 Caddy の自動 HTTPS はポート 443 を巡って SafeLine と競合します。実用的な構成では SafeLine にポート 80 と 443 を割り当て、SafeLine から Caddy、アプリケーションへのホップのために、Caddy を 8080 などの非公開の内部 HTTP ポートに移します。
| 構成 | ポート 443 を所有 | SSL 管理 | 複雑性 | 向いている用途 |
|---|---|---|---|---|
| A、SafeLine のみ | SafeLine | SafeLine 内 | 低 | 新規の VPS、または移行をいとわない場合 |
| B、NPM の背後 | NPM | NPM 内（Let's Encrypt） | 中 | 既存の NPM デプロイ |
| C、Caddy と併用 | SafeLine | SafeLine 内 | 中から高 | 残しておきたい既存の Caddy |
重要なポイント: 構成 A は新規 VPS には最もシンプルです。構成 B は NPM がすでに動作している場合に適した選択です。構成 C では Caddy のポートを意図的に再割り当てする必要があります。
VPS に SafeLine をインストールする
インストール自体は簡単な部分です。SafeLine には 2 つのインストール手順があります。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 インストーラーを実行する
サブ手順が 2 つあります。どちらか 1 つを選んでください。
ステップ 2a、自動インストール。 root 権限でインストーラーを実行します：
sudo bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --enスクリプトは SafeLine のデータディレクトリの配置場所を尋ね、Docker イメージを取得してスタックを起動します。インストール後、次を実行します sudo docker exec safeline-mgt resetadmin 管理者の認証情報を取得またはリセットするためです。詳細は 公式デプロイガイドを参照してください。得られた認証情報は安全に保管してください。
注意: このコマンドは 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 pssafeline-mgt、safeline-detector、safeline-tengine、safeline-pg、safeline-fvm、safeline-luigi、safeline-chaos のコンテナが表示されるはずです。いずれかのコンテナに次が表示される場合は Exited最も一般的な 2 つの原因についてステップ 3 を参照してください。
ステップ 3：よくあるインストールエラーを解決する
2 つのエラーは十分に頻繁に発生するため、独立したステップを設ける価値があります。
サブネットの重複。 インストールが次のエラーで失敗する場合 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 -dIPv6 リゾルバーのエラー。 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 の管理ダッシュボードは HTTPS 上の TCP 9443 で待ち受けます。この管理ポートをインターネット全体に開放したままにしないでください。信頼できる送信元アドレスまたは 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 で直接待ち受け、クリーンにしたトラフィックを非公開ポート上のバックエンドアプリケーションに転送します。ダッシュボードで：
- に移動 Applications、続いて Add Application.
- 待ち受けポートを 443 に設定し、SSL を有効にします。インストール済みの SafeLine リリースで利用できる証明書ワークフローを使用します。 現行の CE リリース には Free Cert の申請と更新の処理が含まれ、手動での証明書アップロードも引き続き利用できます。
- アップストリームを次に設定します
http://127.0.0.1:8080。バックエンドが Docker で動作している場合は、そのポートをループバックのみで公開します。例えば"127.0.0.1:8080:8080"はサービスの ports セクションで指定します。次のようなハードコードされたコンテナ IP は避けてください172.17.0.5コンテナが再作成されると変わる可能性があるためです。 - アプリケーションを保存します。SafeLine はただちに 443 で待ち受けを開始し、クリーンにしたトラフィックをバックエンドに転送します。
- ドメインの DNS A レコードが VPS のパブリック IP を指していること、およびポート 80 と 443 が外部から到達可能であることを確認します。
ポート 443 がすでに別のプロセスにバインドされていた場合、SafeLine のコンテナはバインドに失敗し、ダッシュボードにそのアプリケーションのエラーが表示されます。アプリケーションを追加する前に、競合するプロセスを停止するか、別のポートを選んでください。
構成 B：Nginx Proxy Manager の背後に SafeLine を置く
構成 B では、NPM がすでに担っている役割（80 と 443 の所有、Let's Encrypt の処理）をそのまま維持し、その背後に SafeLine を専用のセキュリティ層として組み込みます。トラフィックの流れは、クライアント、次に NPM（ポート 443、TLS 終端）、次に SafeLine（ポート 10080、HTTP）、次にバックエンドアプリケーションです。
SafeLine ダッシュボード内で：
- Applications、続いて Add Application。 待ち受けポートを 10080 に設定し、SSL はオフのままにします（NPM がすでに TLS を終端しています）。
- 構成 A で説明したように、アップストリームをアプリケーションの内部アドレスに設定します。
- アプリケーションを保存します。
Nginx Proxy Manager で：
- Hosts、続いて Proxy Hosts、続いて Add Proxy Host。
- Details タブ：ドメイン名、スキームを設定します
httpそして転送ポート 10080 を設定します。NPM がホスト上で直接動作している場合は次を使用します127.0.0.1を転送ホスト名として使用します。NPM が Linux 上の Docker で動作している場合、127.0.0.1は VPS ホストではなく NPM コンテナを指します。Docker の host-gateway マッピング を NPM の Compose サービスに追加し、次を使用しますhost.docker.internalを転送ホスト名として使用します：
extra_hosts:
- "host.docker.internal:host-gateway"NPM の Compose ディレクトリから次を実行します sudo docker compose up -d これによりコンテナが新しいホストマッピングで再作成されます。
- SSL タブ： Let's Encrypt 証明書を要求し、SSL を強制し、HTTP/2 を有効にします。
- X-Forwarded-For については NPM の Advanced タブを空のままにします。 現行の 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;2 番目のディレクティブは、NPM が観測したアドレスをヘッダーの最も右の値として追加します。
- Proxy Host を保存します。
SafeLine に戻り、有効なヘッダーチェーンを確認した後にのみ送信元 IP の抽出を構成します。 SafeLine 9.3.1 では、方向とインデックスの選択が可能な柔軟な XFF 抽出が導入されました。
- Settings、続いて Advanced、続いて Real IP from Header。ヘッダー名を次に設定します
X-Forwarded-For. - ヘッダーの末尾からのカスタム抽出を使用し、NPM によって追加された最も右のアドレスを選択します。正確なインデックスのラベルはバージョンによって異なるため、Logs、続いて Access で結果を確認します。インストール済みのリリースが 9.3.1 より古い場合は、このトポロジーに従う前にアップデートしてください。
- Cloudflare や別の CDN が NPM の前にある場合は、まず NPM がそのプロバイダーの公開されたプロキシ範囲のみを信頼するように構成し、NPM が追加するアドレスが信頼できるものになるようにします。実際のヘッダーチェーンを確認しテストするまでは、固定位置を選択しないでください。
- アプリケーションを保存して再読み込みします。
VPS の外部にあるマシンから構成をテストします：
curl -H "X-Forwarded-For: 1.2.3.4" "https://yourdomain.com/"SafeLine のアクセスログには、次ではなく実際のパブリックアドレスが表示されるはずです 1.2.3.4 または NPM のブリッジアドレス。
バックエンドのリスナーを非公開に保つことで、ユーザーが SafeLine を迂回するのを防ぎます。Docker Compose のバックエンドの場合は、ポートをループバックのみで公開します：
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" が返る場合でも、ポートは公開されており到達可能であることを意味するため、保護が必要です。ループバックへのバインドが不可能な場合は、汎用的な DOCKER-USER ルールを適用するのではなく、実際のインターフェース、Docker ネットワーク、宛先コンテナに合わせたファイアウォールルールを作成してください。
構成 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 は 443 を巡って SafeLine と競合する代わりに、内部 HTTP ポートで待ち受けるようになります。 bind 127.0.0.1 行によって、そのリスナーは VPS 内にとどまります。次のコマンドで Caddy を再読み込みします sudo systemctl reload caddy そして次で確認します sudo ss -ltnp | grep -E ':(443|8080)' Caddy が 443 ではなく 8080 にバインドされていることを確認します。
SafeLine で、SSL を有効にして 443 で待ち受けるアプリケーションを追加し、アップストリームを次に設定します http://127.0.0.1:8080。Caddy は SafeLine の前ではなく背後にあるため、X-Forwarded-For の設定はデフォルトのネットワーク接続オプションのままで構いません。
保護モードを選び、WAF が攻撃をブロックしていることを検証する
SafeLine には、エンジンがリクエストを悪意あるものとしてフラグ付けしたときの動作を決める 3 つの保護モードがあります。適切な開始モードはアプリケーションによって異なりますが、検証のステップはどのモードでも同じです。
保護モード：Monitor、Balanced、Strict
SafeLine の各アプリケーションは独自の保護モード設定を持ち、次の場所で構成できます Applications、続いて自分のアプリ、続いて Protection Mode:
- Monitor。 SafeLine は本来ならブロックするリクエストを記録しますが、ブロックはしません。これは、入力フォームが豊富な複雑な本番アプリケーション（フォーラム、WYSIWYG フィールドを持つ管理パネル、自由形式の JSON ペイロードを受け付ける API など）にとって最も安全な開始点です。Monitor を数日間実行し、Attack Events ページを確認し、実際のユーザーに対する誤検知がないことを確認してから Balanced に昇格させます。
- Balanced。 デフォルトのモードです。SafeLine の ベンダーが公開している GitHub 上の数値 では、Balanced モードについて検出率 71.65%、精度 99.45%、誤検知率 0.07% が報告されています。Strict モードは検出率 76.17%、精度 99.38%、誤検知率 0.22% と報告されています。これらは独立したベンチマークではなくベンダーが報告した結果であり、README はデータセットを WAF-Eval として明示していません。これらは製品の比較用の数値として扱い、本番環境で保証される性能とは見なさないでください。
- Strict。 より積極的なルールセットで、より厳しいヒューリスティックと、上に示した検出率対誤検知のトレードオフを備えます。トラフィックを把握したうえで、Balanced が問題なく 1〜2 週間運用できてから試す価値があります。
推奨：乱すべきライブトラフィックがない新規デプロイには Balanced。既存の本番アプリケーションの場合は、まず Monitor で数日間開始し、Attack Events ログで誤検知を探し、例外を調整したうえで Balanced に昇格させます。Strict は、トラフィックを把握したうえで Balanced を 1〜2 週間運用してから試す価値があります。
curl の SQLi テストで WAF を検証する
インストール完了と見なす前の最後のステップは、WAF が実際に攻撃を遮断することを確認することです。VPS 外部の任意のマシンから、保護対象サイトに対して無害な SQL インジェクションのプローブを実行します：
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、curl を実行したマシンに一致する送信元 IP、リクエスト詳細内の問題のクエリ文字列を持つ新しいエントリが表示されるはずです。SafeLine が取得した完全なリクエストとレスポンスを見るには、そのイベントをクリックします。
curl リクエストが 200 OK を返した場合は、Attack Events ログと合わせて結果を解釈します：
- 一致する SQL Injection イベントがある場合、アプリケーションはおそらく Monitor モードです。ブロックせずに記録するのは想定どおりです。
- 一致するイベントがない場合は、DNS が意図した VPS に解決されることを確認し、SafeLine のリスナーとアップストリームの構成を検証し、リクエストの時刻を SafeLine のアクセスログと突き合わせます。
- また、保護が有効になっていること、そして IP ホワイトリスト、カスタム許可ルール、パス例外のいずれもテストリクエストに該当していないことを確認します。
重要なポイント: curl のプローブが SafeLine の遮断ページとともに 403 を返し、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。 より強力な攻撃検出、サービスごとおよびグローバルの構成、カスタム遮断ページ、アップストリームの負荷分散、マスター/スレーブノードの同期、無制限のアプリケーションを追加します。次を参照してください 現行の料金表 変更点については。
- Ultimate、カスタム料金。 各チャネルでの 1 対 1 サポートとカスタム機能開発を伴う、個別対応のエンタープライズ条件。
SafeLine はアプリケーションデータをローカルの Compose スタック内で処理し保存します。ただし、 現行の CE リリースノート には Threat Intelligence Sharing への言及があるため、運用者はデプロイをゼロエグレスと見なす前に、インストール済みバージョンの UEP、プライバシー、共有の設定を確認し、アウトバウンド接続を観察するべきです。
ここから先に進むには
インストールが完了し、WAF が検証されました。いくつかのフォローアップ作業がデプロイを健全に保つのに役立ちます。
- ユーザー入力が豊富な本番アプリケーション（フォーラム、管理パネル、自由形式の API）では、保護モードを次に設定します モニター 3〜7 日間実行し、Attack Events ページを毎日確認し、誤検知を調整したうえで Balanced に昇格させます。
- Lite ティアでは、攻撃アラートがダッシュボードの外でも届くように、Discord または Telegram の通知連携を設定します。
- 月次のメンテナンスウィンドウを予定します。アップグレードの前に、SafeLine のデータと環境構成をバックアップし、次を読みます 現行のリリースノートそして、インストール済みバージョンのサポートされたアップグレード手順を使用します。次だけに頼らないでください
docker compose pullに続いてdocker compose up -dCompose 定義や必要な環境変数がリリース間で変わる可能性があるためです。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 を置き換える必要はありません。よくある構成では、SSL とルーティングのために NPM を前面に残し、その背後に SafeLine を専用のセキュリティ層として重ねます。どちらも機能します。選択は、1 つのツールに両方の仕事をさせたいか、2 つのツールにそれぞれ 1 つの仕事をしっかりさせたいかによります。
無料ティアは単一の WordPress サイトや小規模な SaaS に十分か？
保護という点では、はい。無料の Personal ティアには、セマンティック検出エンジン、レート制限、ボット向け CAPTCHA チャレンジ、動的な HTML/JS 暗号化が含まれ、これらは単一サイトの中核的な防御です。有料ティアは、地域ブロック、攻撃ログのエクスポート、外部通知、より高いアプリケーション上限、より強力な検出、負荷分散などの運用機能を追加します。有料ティアが必要かどうかは、トラフィック量だけでなく、必要な機能とアプリケーション数によります。
SafeLine は 1 GB RAM の VPS で動作するか？
SafeLine の 公式の最小要件 は 1 GB RAM です。これはテストやごく軽いワークロードには十分な場合がありますが、本番のキャパシティはトラフィック、有効化された機能、ログの保持期間によります。小規模な本番デプロイでは、2 vCPU と 4 GB RAM が控えめな開始点です。メモリ使用量を監視し、計測した負荷に基づいてスケールしてください。
なぜ ARM64 には有料ライセンスが必要なのか？
SafeLine の 公式デプロイドキュメント には、ARM デプロイには Pro ライセンスが必要であり、Personal Edition は ARM でサポートされていないと記載されています。Personal Edition を利用したい場合は x86_64 の VPS を選んでください。ARM が必要な場合は Pro ライセンスを計画してください。
Chaitin Tech は自分の SafeLine インスタンスから何を受け取るのか？
正確なアウトバウンドデータは、リリースと有効化された機能によって異なります。 現行の CE リリースノート には Threat Intelligence Sharing への言及があり、インストール済みバージョンには UEP やその他の共有設定も含まれている場合があります。それらの設定とインストール済みバージョンのリリースノートを確認し、ネットワークレベルでエグレスを検証してください。SafeLine のローカルコンテナはアプリケーションデータを処理しますが、その事実だけでは、UEP を拒否すればすべてのアウトバウンドリクエストが止まることの証明にはなりません。
