セルフホストの WAF をアプリケーションの前面へ置くとき、先に壊れるのは検知ルールではなくホストの受け入れ判定である。SafeLine は Web アプリケーションとインターネットの間の HTTP をフィルタして監視し、リバースプロキシとして置く。クライアントはオリジンへ届く前にここを通過する（https://docs.waf.chaitin.com/en/home）。依存を満たさないマシンでは、その保護は始まらない。検索で拾いやすい確認観点は how to verify waf docker compose and ssse3 requirements だが、本稿は導入後の後始末ではなく、着手前チェックリストと切り分けの順で書く。
公開されている導入依存は、Linux、命令アーキテクチャ x86_64 または arm64、Docker 20.10.14 以上、Docker Compose 2.0.0 以上、CPU 1 コア以上、メモリ 1GB 以上、ディスク 5GB 以上、ssse3 を備えた CPU である（https://docs.waf.chaitin.com/en/GetStarted/Deploy）。ダッシュボードの場所は https://:9443 と案内できる。ただしその画面は、Compose や ssse3 の合格を証明しない。
受け入れチェックリスト
使う予定の Docker が見えるシェルで、対象ホストに対して次を実行する。行ごとに公開コマンドへ対応させ、別の棚卸し結果で読み替えない。
-
uname -mは命令アーキテクチャである。x86_64 か arm64 以外は公開マトリクスの外。 -
docker versionは Docker 本体である。20.10.14 未満、またはコマンド不在なら停止。 -
docker compose versionは Compose である。空白区切りのプラグイン形式だけを採用し、2.0.0 未満または不在なら停止。 -
cat /proc/cpuinfo | grep "processor"はプロセッサ行である。1 行もなければ下限未満。 -
free -hはメモリである。1GB 未満なら不足。 -
df -hはディスクである。SafeLine 用ディレクトリを置くファイルシステムに 5GB 以上の空きが要る。 -
lscpu | grep ssse3は CPU 命令である。一致行があればフラグは lscpu から見える。無ければ未確認。
文書はより大きい本番サイズを公開していない。推測のコア数やメモリ目標を足してチェックを盛らない。下限未満のホストは、容量を足すか別マシンにする。コンテナ起動は、足りないメモリやディスクを借りる方法として書かれていない。
番号付きの確認手順
- 自動導入も compose ファイルの取得も、この一覧が残るまで始めない。出力は変更記録へそのまま貼る。
-
uname -mを先に固定する。不一致のホストでイメージ取得へ進まない。コンテナがアーキテクチャ差を隠す、という期待は手順にない。 - Docker と Compose をバージョン行として分けて読む。文書の Compose 確認は
docker compose versionであり、ハイフンでつないだ未記載の置き換えではない。両方の下限を満たすまで、どちらの導入経路も仮定してはいけない。 - プロセッサ、メモリ、ディスクを下限と比較する。手動手順のディレクトリ例は
/data/safelineで、設定とデータはそこへ書かれる。同じ案内がディスク 5GB 以上を繰り返すのはこのためである。df -hは、そのディレクトリが載るファイルシステムで判定する。 - ssse3 をアーキテクチャ行から独立させる。
lscpu | grep ssse3に一致がなければ、文書化された CPU 要件は確認できていない。免除、ソフトウェアフォールバック、Compose の設定項目による置換は載っていない。出力は一致しても不一致でも保存する。 - arm64 だった場合だけ、手動導入の文書にある ARM 設定を足す。
ARCH_SUFFIX=-armとPOSTGRES_IMAGE=chaitin/safeline-postgres-arm:15.18である。ARM に入れた SafeLine が正しく動くには Pro ライセンスが必要で、Personal Edition は ARM 非対応である。既定の x86 イメージ名を arm64 へ向けない。アーキテクチャが一致しても ssse3 のコマンドは省略しない。表は両方を要求している。 - 全行が確認できてから導入経路を選ぶ。推奨は root が要る自動導入で、コマンドは
bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --enである。完走は導入成功を意味し、そのあと Web UI を開く。このスクリプトは、無い Docker や古い Compose を発見するための探りではない。新しい仮想マシンでも、バージョンコマンドが先である。 - 手動経路は順序がより厳しい。必要なら Docker を入れ、
/data/safelineのようなディレクトリを作り、compose.yaml を取得し、.env を書き、トークンを生成し、権限を設定し、最後にdocker compose up -dを実行する。起動には数分かかることがある。その瞬間に Compose 2.0.0 未満だと知るのは遅い。受け入れ理由が後から見えるよう、バージョン出力は変更記録に残す。 -
MGT_PORTを文書の既定 9443 のままにするなら、コンソールはhttps://<safeline-ip>:9443/である。初期管理者アカウントはdocker exec safeline-mgt resetadminが表示する。これらの後段は、失敗した事前チェックを直さない。
具体的な誤設定と、修正を示す画面
切り分け例を一つに固定する。検証用仮想マシンで、担当者は uname -m が x86_64 だったことだけを CPU 合格にし、lscpu | grep ssse3 を走らせなかった。Compose も docker-compose version というハイフン形式だけを見て、空白区切りの docker compose version を記録していない。下限を再現できないまま、root の自動導入へ進もうとした。
これはチェックリストの二行を、「Docker らしきものがある」へ潰した誤設定である。x86_64 は ssse3 の代わりにならない。ハイフン形式は、公開された確認コマンドの代理ではない。自動導入は推奨パスだが、依存の確認はその前にある。
修正では、インストーラも docker compose up -d も止めたまま公開コマンドをやり直す。確認になるのは管理画面ではなく、次の端末出力である。docker compose version が 2.0.0 以上を表示し、同じ記録の中で lscpu | grep ssse3 がフラグを含む一致行を表示すること。その二つの画面を変更記録へ貼って、初めてホストを受け入れてよい。一致行が無いなら、文書に無い例外を作らず、フラグが見える別マシンで同じコマンドを取り直す。後から https://<ip>:9443 が開いても、この事前ゲートの代わりにはならない。
アプリ追加と混同しない
保護対象の追加は別ページである。SafeLine は nginx を基に開発された Web アプリケーションファイアウォールで、元サイト向けの通信を受け、悪意のあるリクエストを除き、残りを上流へ転送する（https://docs.waf.chaitin.com/en/GetStarted/AddApplication）。追加するのはドメイン、待受ポート、上流で、そのドメインを SafeLine のサーバへ解決する。コンソールのこの作業は、Compose 2.0.0 も ssse3 も検証しない。
サイト側の設定が怪しく見えても、先に変更記録の七行へ戻る。記録が無ければ、コンテナの内側を掘る前にホストで公開コマンドを再実行する。Compose が古い、ssse3 の一致が無い、ディスクが 5GB 未満、のいずれかなら、アプリ設定の見直しはまだ早い。Compose が十分新しくても、ディスク行は省略できない。
七行が残っていて、なおコンソールだけが開かないときだけ、MGT_PORT の既定が 9443 か、開いている URL が https://<safeline-ip>:9443/ かを見る。初期アカウントが要るなら docker exec safeline-mgt resetadmin の表示を使う。ここから先が導入後の画面確認である。受け入れ判定のログは、その画面ではなく、導入前に保存したコマンド出力のほうである。
- Demo: https://demo.waf.chaitin.com:9443/statistics
- Official docs: https://docs.waf.chaitin.com/en/home
- GitHub: https://github.com/chaitin/SafeLine