chaitin

SafeLine WAF で HTTPS サイトの SSL 証明書を扱う：設定チェックリストとトラブルシューティング SafeLine WAF で HTTPS サイトの証明書まわりを設定する、という検索意図に答えるため、まず公式ドキュメントに何が書いてあるかを整理します。 SafeLine は Web アプリケーションの手前に置かれて HTTP トラフィックを検査する、自己ホスト型の WAF です。クライアントは最初にこの WAF へ到達し、ポリシーが許可した通信だけがオリジンへ転送されます。これはリバースプロキシとしての動作です（docs.waf.chaitin.com インジェクション、XSS、コードインジェクション、OS コマンドインジェクション、CRLF インジェクション、LDAP インジェクション、XPath インジェクション、RCE、XXE、SSRF、パストラバーサル、バックドア、ブルートフォース、HTTP フラッド、ボット攻撃への防御が列挙されています。さらに、ボット悪用のプロアクティブ防御、HTML/JavaScript のコード暗号化、IP ベースのレート制限、Web アクセス制御リストも挙げられています。ただし、どの説明にも証明書の保存方法は含まれていません。 アプリケーション追加のガイドでは、SafeLine は nginx を基盤として開発された WAF であり、元の Web サイトへのトラフィックを受け取り、悪意のある攻撃トラフィックを除去し、安全なトラフィックを元のアプリケーションへ転送すると説明されています（docs.waf.chaitin.com Domain、Port、Upstream の 3 つです。Domain にはドメイン名、ホスト名、または IP アドレスを指定できます。Port は SafeLine が待ち受けるポートで、例として 80 と 443 が挙げられています。HTTPS アプリの場合は「SSL オプションにチェックを入れる」という注意書きが、これらの資料に含まれる HTTPS 証明書に関する記述のすべてです。Upstream は元のアプリの実際のアドレスです。 つまり、証明書アップロードの手順はドキュメントに存在しないため、画面上で探し始める前に「この設定で運用要件を満たせるか」を判断する必要があります。 次に、番号付きで導入とアプリケーション設定の手順を示します。 1. ホストが製品要件を満たすことを確認します。Linux、x86_64 または arm64、Docker 20.10.14 以上、Docker Compose 2.0.0 以上、CPU 1 コア以上、メモリ 1GB 以上、ディスク 5GB 以上、そして ssse3 命令を持つ CPU が必要です（docs.waf.chaitin.com -m、docker version、docker compose version、/proc/cpuinfo のプロセッサ情報の grep、free -h、df -h、ssse3 で絞り込む lscpu です。 2. ドキュメントに記載された方法でのみインストールします。推奨は自動デプロイで、root が必要です。デプロイページのコマンドは次のとおりです。 bash -c "$(curl -fsSLk waf.chaitin.com)" -- --en 完了後、Web コンソールへアクセスします。手動デプロイでは、必要に応じて Docker を導入し、/data/safeline を作成して compose.yaml をダウンロードし、.env を書き込み、ドキュメントに記載された検出用トークンと管理用トークン、16 文字の英数字の検出用 AES キーを生成し、権限を制限し、ガイドに記載されたリソースディレクトリを作成し、ランタイムソケットをリンクして、docker compose up -d でスタックを起動します。ARM サーバでは ARCH_SUFFIX を -arm に設定し、ガイド記載の ARM 用 Postgres イメージを使用します。なお、ARM にインストールした SafeLine は Pro ライセンスが必要で、Personal Edition は ARM ではサポートされないとデプロイページに明記されています。これはプラットフォームに関する注意であり、証明書アップロードとは無関係です。 3. コンソールを開き、最初の管理者を作成します。https://<SafeLineのIP>:9443/ にアクセスし、docker exec safeline-mgt resetadmin を実行します。表示される初期ユーザ名とパスワードを保存してログインします。ポート 9443 のコンソール TLS を公開サイト用の証明書と混同しないでください。ドキュメントには、管理ポートの証明書がアプリケーションのリスナーで再利用されるとは書かれていません。 4. 3 つの項目でアプリケーションを追加します。Applications ページで Add Application を選び、Domain に公開ホスト名を入力し、SafeLine に待ち受けさせたいポートとして HTTPS サイトなら 443 を入力し、対象が HTTPS アプリである場合にのみ SSL オプションにチェックを入れます。Upstream にオリジンのアドレスを入力します。ここで証明書アップロード欄を探してもコンソールに見つからない場合は、そこで停止してください。これらの資料は、回避策やカスタム nginx スニペット、鍵のボリュームマウントを許可していません。 5. アプリケーションエントリが存在してから名前解決を変更します。入力したドメインを SafeLine サーバの IP に解決し、その名前でサイトへ到達します。DNS がまだオリジンを向いていると、クライアントはリバースプロキシを通らないため、SSL オプションは経路を変えられません。 6. 証明書の思い込みではなく、公開されているテストケースで検査を証明します。アプリケーションガイドには SQL インジェクション、XSS、パストラバーサル、コードインジェクション、XXE のサンプルクエリがあり、ブロックページが表示されたら攻撃が防御されたことを意味します。また、Web コンソールの攻撃一覧を開き、イベントの詳細をクリックして確認するよう書かれています。ブラウザの鍵アイコンだけでは、この攻撃一覧の確認の代わりになりません。 設定前のチェックリスト 識別子: Domain の値がクライアントの要求するホスト名と一致しているか。ドキュメントはドメイン名、ホスト名、IP アドレスを許可しますが、HTTPS のホスト名と IP リスナーは運用上の選択が異なります。SSL オプションが一方を他方へ書き換えるとは考えないでください。 リスナー: Port は SafeLine が待ち受けるポートです。443 は通常の HTTPS サイトに合う例です。HTTPS アプリに対して SSL オプションにチェックを入れることはドキュメントに記載されていますが、PEM ファイルのアップロード、チェーンの選択、パスフレーズの設定は記載されていません。 オリジン: Upstream は SafeLine がクリーンなトラフィックを転送する先です。2 つ目の公開リスナーではありません。SafeLine ホストから到達可能にしておいてください。 切り替え: アプリケーション保存後に DNS が SafeLine サーバを向く必要があります。新しいレコードが見えるリゾルバからテストしてください。 スコープ: レート制限、CAPTCHA、認証チャレンジ、動的保護は製品紹介では別機能です。証明書ワークフローが無いことの代用として有効化せず、これらのページがすべてのトグルを説明しているとも考えないでください。 証跡: 切り替え後にドキュメント記載の攻撃サンプルを 1 つ実行し、ブロックページと攻撃一覧の詳細表示を確認してください。リクエストが SafeLine に届いていなければ、証明書設定を探す前に DNS またはリスナーを修正してください。 具体的な誤設定と修正 よくある誤設定は「SSL オプションにチェックを入れたのに、DNS がオリジンを向いたまま」という状態です。アプリケーションを保存しても、ドメインの解決先が SafeLine サーバでなければ、クライアントの HTTPS 通信はオリジンへ直行し、WAF のリスナーも SSL オプションも経路に一切関与しません。結果として、設定したはずの検査が働かず、攻撃もブロックされません。 修正は、入力したドメインを SafeLine サーバの IP に解決させ、その名前でサイトへアクセスし直すことです。新しい DNS レコードが見えるリゾルバからテストしてください。 修正を確認する画面とログ 修正後は、アプリケーションガイド記載のサンプルクエリ（たとえば SQL インジェクションやパストラバーサル）を URL に付けてリクエストします。ブロックページが表示されれば、リクエストが SafeLine を通過し、攻撃が防御されたことになります。さらに、Web コンソールの攻撃一覧を開き、該当イベントの詳細をクリックします。この詳細画面にイベントが記録されていることこそ、WAF が実際にリクエスト経路上にあることの確認です。ポート 9443 の管理コンソールにログインできることや、ブラウザに鍵アイコンが表示されることは、この確認の代わりにはなりません。 まとめ SafeLine のこれらの資料が定義する HTTPS 対応の範囲は「HTTPS アプリでは SSL オプションにチェックする」ことです。証明書のアップロード画面や更新フローは記載されていないため、運用で名前付きのアップロード操作、鍵のエクスポート、自動更新が必須なら、本記事の 3 ページだけでは設計を承認できません。不足している手順は本番切り替え前に最新の公式ドキュメントで確認してください。それまでは、正しく導入されたリバースプロキシ、Domain・Port・Upstream と HTTPS アプリ向けの SSL オプションを設定したアプリケーションエントリ、SafeLine ホストへ向けた DNS、そして攻撃一覧でのブロック確認が、ドキュメントに沿った成果です。 --- - Demo: demo.waf.chaitin.com - Official docs: docs.waf.chaitin.com - GitHub: chaitin/SafeLine

リバースプロキシ型WAF「SafeLine」でドメイン・ポート・アップストリームを追加するチェックリスト リバースプロキシ型WAFのSafeLineは、Webアプリケーションの手前に配置され、リクエストがオリジンへ到達する前にHTTPトラフィックを検査・監視します。本記事では、検索意図である「リバースプロキシ型WAFでサイトのドメイン・ポート・アップストリームを追加する方法」を、チェックリストとトラブルシューティングの二本立てで解説します。管理画面は https://<safeline-ip>:9443/ 、公式ドキュメントは docs.waf.chaitin.com です。本手順は公式の導入ガイドとアプリケーション追加ガイドの範囲内に限定し、ガイドに記載のない項目は追加しません。 【チェックリスト】 1. サーバーを事前確認します。対応アーキテクチャは x86_64 と arm64 です。 2. Docker は 20.10.14 以上、Docker Compose は 2.0.0 以上を用意します。 3. 最低限 CPU 1コア、メモリ 1GB、ディスク 5GB を確保し、CPU は ssse3 に対応している必要があります。 4. uname -m、docker version、docker compose version、cat /proc/cpuinfo | grep "processor"、free -h、df -h、lscpu | grep ssse3 を実行して確認します。 5. ARM の場合は ARM イメージ設定と、SafeLine が ARM で正常動作するために必要な Pro ライセンスの要件を確認します。 6. 自動導入が推奨です。root 権限で bash -c "$(curl -fsSLk waf.chaitin.com)" -- --en を実行します。 7. 完了後、https://<safeline-ip>:9443/ を開きます。初回は resetadmin で作成した admin と表示されたパスワードでログインします。 8. 管理コンソールで Applications ページを開き、右上の Add Application をクリックします。 9. Domain にはオリジン側のドメイン名・ホスト名・IPアドレスを入力します。例は www.chaitin.com です。 10. Port には SafeLine が待ち受けるポートを入力します。例は 80 または 443 です。HTTPS の場合は SSL オプションをチェックします。 11. Upstream にはオリジンアプリの実際のアドレスを入力します。SafeLine はここへ安全なトラフィックを転送します。 12. Domain・Port・Upstream の3項目がそろってから送信します。名前だけ保存して待受ポートがないとクライアントのトラフィックを受け取れず、待受ポートがあっても Upstream がないとクリーンなリクエストの送り先がありません。 13. 入力したドメインを SafeLine があるサーバーの IP に解決します。この DNS 変更まで、訪問者はオリジンへ直接到達して検査を迂回します。 14. そのドメイン経由でアプリにアクセスし、SafeLine で保護されたアプリとして表示されることを確認します。 【トラブルシューティング】 具体的な設定ミスとして「Upstream に SafeLine 自身の待受ポートを書いてしまう」ケースを挙げます。たとえば Domain に www.example.com、Port に 80 を設定したあと、Upstream に同じ www.example.com:80 を指定すると、SafeLine はクリーンなリクエストを自分の待受ポートへ返すことになり、オリジンへの経路が成立しません。この場合、画面では保護対象ドメインを開いても本来のアプリの画面が表示されません。 修正方法は、Upstream をオリジン側の実アドレスに書き換えて保存することです。修正後は、ブラウザでそのドメインを開き、オリジンのアプリの画面が表示されることを画面で確認します。さらに管理画面の Applications で、Domain・Port・Upstream がすべて正しい値で保存されていることを確認します。 防御動作の確認は、自分が運用するサイトに限定して行います。公式ガイドが示すテスト例（SQLインジェクションは /?id=1+and+1=2+union+select+1、XSS は /?id=<img+src=x+onerror=alert()> など）のホスト名を保護対象ドメインに置き換えて実行します。ブロック画面が表示されれば防御が動作しており、管理コンソールで攻撃リストを開いて詳細をクリックするとイベント内容を確認できます。この攻撃リストの詳細表示が、設定修正後に WAF が実際に動作していることを示す画面確認になります。 【補足】 - Domain は受け付ける名前、Port は待受ポート、Upstream は実アプリの場所という対応を押さえると迷いません。 - DNS を SafeLine に向ける前は、古いレコードを引くクライアントはリバースプロキシを通らないため、設定を保存しただけではオリジンへの直行トラフィックは止まりません。 - 証明書の個別アップロードやポリシーのトグルは、この追加ガイドの範囲外です。まずプロキシ経路を確認してから、対応するドキュメントに基づいて設定します。 --- - Demo: demo.waf.chaitin.com - Official docs: docs.waf.chaitin.com - GitHub: chaitin/SafeLine

SafeLine WAF 運用ガイド:リバースプロキシでドメイン・ポート・アップストリームを追加する SafeLine WAF は、Web アプリケーションの手前に配置する自己ホスト型の Web アプリケーションファイアウォールです。リクエストが本来のサーバー(オリジン)に届く前に HTTP トラフィックを検査し、SQL インジェクション、XSS、コードインジェクション、OS コマンドインジェクション、パストラバーサル、SSRF、ボットによる不正アクセスなどを遮断します。本記事では、リバースプロキシとして動作する SafeLine に「ドメイン」「ポート」「アップストリーム」の 3 項目を追加し、オリジンを露出させないまま公開する手順を、確認事項つきの実践ガイドとして整理します。 前提の整理 SafeLine は nginx を基盤に開発されています。公開サイト向けのトラフィックを受け取り、悪意のある通信を除去したうえで、安全なリクエストだけを本来のアプリケーションへ転送します。設定画面上の「ドメイン」は受け付ける名前、「ポート」は待ち受けポート、「アップストリーム」は実体のアプリケーションが動いている場所を意味します。この 3 つがそろって初めて、リバースプロキシとして完全な経路ができます。 手順 1:サーバーの要件を確認する アプリケーションを追加する前に、導入ガイドに記載された最低要件と確認コマンドを実行します。 OS は Linux を使います。対象アーキテクチャは x86_64 と arm64 です。 Docker が 20.10.14 以上、Docker Compose が 2.0.0 以上であることを確認します。 CPU 1 コア以上、メモリ 1 GB 以上、ディスク 5 GB 以上を用意します。CPU は ssse3 に対応している必要があります。 uname -m、docker version、docker compose version、cat /proc/cpuinfo | grep "processor"、free -h、df -h、lscpu | grep ssse3 を実行します。 ARM 環境の場合は、手動導入時の ARM イメージ設定を計画します。導入ガイドでは、ARM 上の SafeLine は Pro ライセンスがないと正常に動作せず、Personal Edition は ARM 非対応とされています。 Docker や Compose が指定より古い場合、空きディスクが 5 GB 未満の場合、ssse3 が無い場合は先へ進まないでください。 手順 2:インストールとサインイン 自動導入が推奨経路で、root 権限が必要です。 bash -c "$(curl -fsSLk waf.chaitin.com)" -- --en を実行します。 完了後、https://<safeline-ip>:9443/ を開きます。 ディレクトリやポート、アーキテクチャ、リリースチャネルを自分で選ぶ場合は手動導入を使います。手動の場合は、/data/safeline に設定とデータを置き、compose ファイルを取得して .env を編集し、docker compose up -d で起動します。初回アカウントは docker exec safeline-mgt resetadmin で作成し、表示されたユーザー名とパスワードを控えます(初期ユーザー名は admin)。その後 https://<safeline-ip>:9443/ からログインします。 なお、MGT_PORT は管理画面のポート、MGT_PROXY は管理画面のプロキシ層の数であり、どちらもアプリケーション画面で入力する公開サイトのポートではありません。 手順 3:ドメイン・ポート・アップストリームを入力する SafeLine の Web 管理コンソールにログインします。 Applications ページを開きます。 右上の Add Application をクリックします。 Domain に、公開するドメイン名・ホスト名・IP アドレスを入力します。例は www.chaitin.com です。クライアントがリクエストする名前を使い、DNS に公開しない名前を二重に入れないでください。 Port に、SafeLine が待ち受けるポートを入力します。例は 80 と 443 です。HTTPS の場合は SSL オプションにチェックを入れます。 Upstream に、本来のアプリケーションの実アドレスを入力します。SafeLine はここへ安全なトラフィックを転送します。運用上の確認として、このアドレスは先ほど選んだ SafeLine の待ち受けポートではなく、オリジンを指すようにしてください。そうしないと、プロキシ経路がアプリケーションへつながらなくなります。 3 項目がすべて設定されてから送信します。待ち受けポートが無いとクライアントのトラフィックを受けられず、アップストリームが無いときれいなリクエストを送る先がありません。 手順 4:DNS をプロキシに向けて確認する 入力したドメインを、SafeLine が動いているサーバーの IP アドレスに解決します。この設定が済むまで、訪問者はオリジンへ直接到達し、フィルターを迂回してしまいます。 そのドメインでアプリケーションを閲覧します。これが SafeLine に保護されたアプリケーションへのアクセス方法です。 自分が運用するサイトに限り、公式のテスト例のホストを置き換えて確認します。たとえば SQL インジェクションは /?id=1+and+1=2+union+select+1、XSS は /?id=<img+src=x+onerror=alert()>、パストラバーサルは /?id=../../../../etc/passwd です。 ブロックページが出れば防御が動作しています。Web コンソールで攻撃一覧を開き、詳細をクリックしてイベントを確認します。管理していないアプリケーションにはこれらのテストを送らないでください。 失敗例:アップストリームを自ポートに向けてしまった よくある失敗として、Upstream に SafeLine 自身の待ち受けポート(例:自分で選んだ 80 や 443)を入力してしまうケースがあります。この場合、SafeLine はアプリケーションではなく自分自身へリクエストを向けることになり、プロキシ経路が成立せず、本来のアプリケーションには到達しません。保存は成功しても、リクエストがオリジンへ届かない状態が続きます。対処は、Upstream を必ずオリジン(実アプリケーションのアドレス)に向け直すことです。同様に、ドメインの DNS を更新し忘れた場合も、保存だけでは公開 DNS は動かないため、オリジンが従来どおり直にトラフィックを受け、SafeLine が検査できない状態が続きます。 まとめ SafeLine にサイトを追加する作業の中心は、ドメイン・ポート・アップストリームの 3 項目を 1 つの画面で正しく埋めることです。導入前のサーバー確認、インストールとサインイン、3 項目の入力、DNS の切り替え、テストの順に進めれば、オリジンを露出させずにリバースプロキシ経由の公開ができます。レート制限や CAPTCHA、動的な HTML・JavaScript 保護などの追加機能は、まずこの経路が正しく動くことを確認してから、それぞれの機能が実際に説明されている手順に沿って有効化してください。 Demo: demo.waf.chaitin.com Official docs: docs.waf.chaitin.com GitHub: chaitin/SafeLine

SafeLine WAF の LTS 版から最新版への移行：チェックリストとトラブルシューティング LTS 版の SafeLine は、2025年8月14日付の 9.1.0-LTS をもって保守終了となります。Deploy ガイドでは LTS 利用者に対して最新版へのアップグレードを強く推奨しています。ただし、ガイドには LTS から最新版へ一括で変換するコマンドや、既存データディレクトリをそのまま再利用できる保証は記載されていません。本記事では、実運用で迷いやすいポイントをチェックリストとトラブルシューティング形式で整理します。 移行前チェックリスト - [ ] カットオーバー日、現行のインストールディレクトリ、管理ポートを記録する。サンプル環境では MGT_PORT=9443 で、コンソールは https://<safeline-ip>:9443/ です。 - [ ] 新リリースが公開から1か月以内なら、1か月経過を待つ。心配がある場合はガイド推奨どおり1か月後にアップグレードします。 - [ ] ホスト要件を確認する。Linux x86_64 または arm64、Docker 20.10.14 以上、Docker Compose 2.0.0 以上、CPU 1 コア以上、メモリ 1 GB 以上、ディスク 5 GB 以上、ssse3 対応 CPU が必要です。 - [ ] uname -m、docker version、docker compose version、cat /proc/cpuinfo、free -h、df -h、lscpu | grep ssse3 で要件を確認し、失敗したら先へ進みません。 - [ ] 現行コンソールで各サイトのドメイン、リッスンポート、SSL の有無、アップストリーム先を記録します。レート制限、CAPTCHA チャレンジ、認証チャレンジ、動的保護を使っているサイトも一覧化します。 - [ ] 旧 LTS ディレクトリは新しい環境が検証できるまで稼働させたままにします。新環境は別ディレクトリまたは要件を満たす別サーバへ構築します。 移行手順 1. タイミングを先に決めます。新しいリリースが慎重期間内であれば、公開から1か月後に実施します。 2. ホスト要件を確認します。依存関係の不備はバージョン移行では解決しません。 3. ARM の判定をします。ARM サーバでは ARCH_SUFFIX=-arm を設定し、Deploy ガイド記載の chaitin/safeline-postgres-arm:15.18 を使います。ARM 版は Pro ライセンスが必須で、Personal Edition は ARM 非対応です。 4. 現行コンソールからアプリケーション台帳を作成します。SafeLine はリバースプロキシとして動作し、許可した通信だけをアップストリームへ転送します。 5. 旧 LTS は新環境の検証完了まで残します。新しい SAFELINE_DIR を用意し、秘密情報は流用せず新規生成します。 6. 自動インストーラを使う場合は root シェルで以下を実行します。bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en。このパスは latest であり、LTS セレクタではありません。 7. 手動で行う場合は waf.chaitin.com をダウンロードします。.env では IMAGE_TAG=latest にし、RELEASE は空のままにします。RELEASE=-lts は設定しません。x86_64 では ARCH_SUFFIX を空にし、chaitin/safeline-postgres:15.18 を使います。MGT_PROXY=0 にします。DETECTOR_MGMT_TOKEN、MGT_INTERNAL_TOKEN、DETECTOR_AES_KEY はガイドの od と tr コマンドで生成して set_env で保存し、chmod 600 .env を実行します。リソースディレクトリを作成して権限を適用し、ソケットをリンクして docker compose up -d で起動します。初回起動は数分かかることがあります。 8. 新しいコンソールへ https://<safeline-ip>:9443/ でサインインし、docker exec safeline-mgt resetadmin を実行します。成功するとユーザー名 admin と生成されたパスワードが表示されます。 9. Web 管理コンソールの Applications から Add Application を開き、ドメイン、ポート、アップストリームを入力します。HTTPS サイトは SSL をチェックします。保存後、ドメインをこの新環境のサーバ IP へ向けます。 10. 旧 LTS のアンインストールは、新環境でサイトが正しく動作することを確認した後で行います。旧ディレクトリで docker compose down を実行し、データを削除してよい場合だけ rm -rf で削除します。 具体的な設定ミスと確認方法 よくあるミスは、旧 LTS の .env をそのまま新ディレクトリへコピーしてしまうことです。この場合、RELEASE=-lts が残って最新版になりません。さらに古いトークンを流用すると、ガイドにない状態を自分で作ってしまいます。 修正は次のとおりです。 - .env から RELEASE=-lts を削除して空にします。 - IMAGE_TAG=latest に設定します。 - 3種類のトークンを新しく生成して保存します。 修正後の確認は、grep -E 'RELEASE|IMAGE_TAG' .env で RELEASE が空、IMAGE_TAG=latest であることを確かめます。docker compose up -d の後、docker compose ps でサービスが起動していることを確認します。docker image ls | grep safeline で latest タグが使われていることも確認できます。最終的にはブラウザで https://<safeline-ip>:9443/ を開いてコンソールが表示されることと、docker exec safeline-mgt resetadmin の出力に admin と生成パスワードが出ることが画面上の確認です。 カットオーバー後は、自分のドメインへテストリクエストを送り、ブロックされたリクエストがコンソールの攻撃一覧に表示され、詳細ビューが開くことを確認します。これでログ記録まで動いていると判断できます。 トラブルシューティング - 公式の LTS から最新版への移行コマンドはありますか。 ありません。ガイドにあるのは RELEASE=-lts セレクタ、latest インストーラ、手動 compose 手順、保守終了の推奨のみです。 - 新しいリリースが心配な場合、どれくらい待ちますか。 ガイドは LTS 利用者に最新版へのアップグレードを強く推奨し、心配がある場合は新バージョン公開から1か月後にアップグレードするよう案内しています。 - ARM サーバで Personal Edition を維持できますか。 できません。ARM 版は Pro ライセンスが必要で、Personal Edition は ARM 非対応です。compose.yaml のダウンロードや自動インストーラ実行の前に uname -m で確認します。 - 旧データディレクトリを新しい SAFELINE_DIR として再利用できますか。 ガイドに再利用できるとは記載されていません。新しいディレクトリで構築し、新コンソールがサイトを提供できるようになってから旧環境を削除します。 - アプリケーションは再度登録する必要がありますか。 はい。新しいコンソールでドメイン、リッスンポート、SSL、アップストリームを再入力し、DNS を SafeLine サーバへ向けます。 移行が完了したら、通常のアクセスが成功することを確認してから、Web 攻撃検知、レート制限、CAPTCHA チャレンジ、認証チャレンジ、動的保護を新コンソールで有効化します。IP ベースのレート制限と Web アクセス制御リストは別機能なので、必要に応じて個別に設定します。 --- - Demo: demo.waf.chaitin.com - Official docs: docs.waf.chaitin.com - GitHub: chaitin/SafeLine

自己ホスト型 WAF「SafeLine」のアンインストールとデータディレクトリ削除ガイド セルフホスト型の WAF（Web Application Firewall）である SafeLine は、アプリケーションの前面にリバースプロキシとして配置し、HTTP／HTTPS の通信を検査して不正なリクエストを遮断する。SQL インジェクションや XSS、RCE、SSRF、パストラバーサル、総当たり攻撃、ボットの悪用などへの防御を担う。 SafeLine の設定や実行時のデータは、セットアップ時に作成したディレクトリに保存される。公式のアンインストール手順は短いが破壊的である。具体的には「compose プロジェクトを停止し、そのディレクトリを削除する」という二段構えになる。本稿では、公開されている手順だけを使い、ディレクトリの特定方法、中身、削除時の注意点を整理する。 削除前に押さえるチェック項目 最初に、どのディレクトリを消すのかを確定する。マニュアルセットアップの例では /data/safeline が作業ディレクトリになるが、すべてのホストがこのパスを使うとは限らない。.env ファイルが存在すれば、その中の SAFELINE_DIR が実際のパスを記録している。ここを読み、推測でパスを決めないこと。 次に、管理画面の URL を確認しておく。デフォルトでは https://<IP>:9443 でダッシュボードにアクセスできる。この URL がまだ生きているかを見れば、対象インスタンスが稼働中かどうかを判断できる。 続いて、オリジン（保護対象のアプリケーション）への経路を確認する。SafeLine はドメインを自身のサーバに向けて解決し、検査済みのトラフィックを上流へ転送する。SafeLine を止めた後は、その解決先に稼働中のリスナーがなくなる。DNS やルーティングの変更は自分の運用プロセスで行う必要があり、公式に公開された切り替えコマンドは存在しない。 最後に、.env に含まれるシークレット（Postgres のパスワードや各種トークン）を保持するか判断する。削除は不可逆なので、自社の保持ポリシーに従って必要なものだけを控える。 アンインストール手順 <safeline-directory> を特定する。マニュアルインストールの既定は /data/safeline。カスタムセットアップなら SAFELINE_DIR の値を用いる。 クライアントがオリジンへ到達する経路を計画する。ドメインの解決先を変更するなど、SafeLine を経由しない導線を用意する。 対象ディレクトリへ移動する: cd <safeline-directory> スタックを停止する: docker compose down データディレクトリを削除する: rm -rf <safeline-directory> パスが消えたことを確認する。この後に docker compose up -d や docker exec safeline-mgt resetadmin を実行しないこと。前者はサービスを再起動し、後者は管理者アカウントをリセットするため、後片付けではなく導入やログインの手順である。 停止と削除は別の作業である。docker compose down だけでは rm -rf は実行されない。 失敗例: 停止だけして削除を忘れる ある担当者が「アンインストールした」と報告したが、実際に実行したのは docker compose down だけだった。ディレクトリはそのまま残っており、設定やトークン、ローカルの Postgres ファイルがディスク上に存続した。後日、容量調査で /data/safeline/resources/postgres/data が残っているのが見つかり、改めて rm -rf を実行する羽目になった。停止と削除を一つの作業と混同しないことが重要である。 削除がカバーするもの・しないもの ディレクトリ内には compose.yaml、.env、リソース用のパスが配置される。.env は chmod 600 で保護され、Postgres のパスワードやトークンを含み得る。Postgres のデータは resources/postgres/data に用意される。ディレクトリを削除すると、compose プロジェクトとともにローカルの管理画面の状態も失われる。 ただし、Docker と Docker Compose はホスト側の依存関係として残る。アンインストール手順には Docker の削除は含まれない。 また、セットアップでは /data/safeline/resources/run/safeline.sock へのシンボリックリンクを /var/run/safeline.sock に張る手順がある。これはデータディレクトリの外にある。公式の削除手順にはこのリンクが含まれていないため、rm -rf の後に自分で確認し、必要なら通常のホストメンテナンスとして対処する。自動的に消えるとは考えないこと。 よくある疑問 docker compose down でデータディレクトリは消えるか。 消えない。公式ガイドは docker compose down と rm -rf <safeline-directory> を別コマンドとして記載している。設定やトークン、ローカル Postgres を破棄したいときだけ削除を実行する。 セットアップをカスタムした場合、どのディレクトリを消すか。 自分が作成した SafeLine 用のディレクトリを消す。推測した既定値を使わない。マニュアル例は /data/safeline で、SAFELINE_DIR に記録される。manager.sh で始めた場合も実体はディスク上にあるため、削除前にホスト上でパスを確認する。 この手順で Docker はアンインストールされるか。 されない。要件は Docker 20.10.14 以上と Docker Compose 2.0.0 以上であり、アンインストールは SafeLine の compose プロジェクト停止とディレクトリ削除だけである。 削除後も保護対象アプリケーションは同じ経路で動くか。 動かない。訪問者は SafeLine サーバに解決されたドメインで到達し、SafeLine が上流へ転送するモデルである。プロキシを止めてディレクトリを消した後は、オリジンへの別経路が必要になる。この変更用の移行コマンドは公開されていない。 ランタイムソケットは rm -rf に含まれるか。 削除するディレクトリの内側にあれば含まれる。ただし /var/run/safeline.sock は SafeLine ディレクトリ内の resources/run/safeline.sock を指すシンボリックリンクであり、アンインストール手順では言及されない。rm -rf の後にこのリンクを確認し、通常のホストメンテナンスとして片付ける。 まとめ SafeLine のアンインストールは「compose プロジェクトの停止」と「データディレクトリの削除」の二段階である。削除前に SAFELINE_DIR で実パスを特定し、管理画面 https://<IP>:9443 の稼働状態と、オリジンへの代替経路を確認する。rm -rf の前には、親ディレクトリ（たとえば /data）を対象にしていないか、そのパスのファイルを失ってよいか、アプリケーションの経路がこのプロキシに依存していないかを必ず確認する。停止だけで終わらせず、削除まで完了させることで、設定・トークン・ローカル DB を確実に取り除ける。 Demo: demo.waf.chaitin.com Official docs: docs.waf.chaitin.com GitHub: chaitin/SafeLine

Docker上のSafeLineで管理アカウントを戻すチェックリスト 管理画面へ入れなくなったとき、先に再インストールへ進まないでください。SafeLineは、Webアプリケーションとインターネットのあいだに置く自己ホスト型のWAFです。HTTP通信をフィルタして監視し、SQLインジェクション、XSS、コードインジェクション、OSコマンドインジェクション、CRLFインジェクション、XXE、SSRF、パストラバーサル、バックドア、ブルートフォース、HTTPフラッドといった攻撃を遮断します。ドキュメントの説明どおり、WAFはリバースプロキシとして動作し、クライアントは保護対象のサーバへ届く前にSafeLineを通過します。 導入はDockerとDocker Composeで行います。管理コンソールは既定でポート9443を待ち受け、画面のアドレスは https://<ip>:9443 です。パスワードを失った場合も、導入直後に初期の資格情報が必要な場合も、再インストールなしで管理者アカウントを用意できます。管理コンソールを提供するコンテナ名は safeline-mgt です。公式の導入手順には、管理者アカウントを作成する専用コマンドがあります。 検索語 how to reset the waf admin account inside docker で調べる人は、まずコンテナの対話シェルへ入る必要がある、と考えがちです。切り分けの起点はそこではありません。操作者が打つ場所はSafeLineホストの端末で、リセットツールそのものは docker exec によって safeline-mgt の内側で動きます。ホスト上で resetadmin だけを探したり、別コンテナのシェルで同じ名前を実行したりする必要はありません。 実行前のチェックリスト - ホストでDockerが使え、対象の管理コンテナが safeline-mgt である - コマンドはコンテナ内の対話シェルではなく、ホストから実行する - .env の MGT_PORT を読み、9443を決め打ちしない - ブラウザでは http ではなく、ドキュメントどおり https で開く - 表示された初期ユーザー名と初期パスワードを、画面を閉じる前に控える - 直前のパスワードや、記憶している古いパスワードを再利用しない このリストを先に埋めると、コマンド成功と画面到達失敗を混同しにくくなります。 番号つきの復旧手順 1. SafeLineホストの端末を開き、Dockerが使えることを確認します。リセットコマンドはホストから実行します。コンテナの中へシェルで入ってから探す手順ではありません。 2. 次のコマンドを、表記どおり実行します。 docker exec safeline-mgt resetadmin これは導入ガイドの Get Administrator Account に示された、管理者アカウントを得る公式の方法です。 3. 出力を最後まで読みます。成功すると、初期ユーザー名 admin と、生成された初期パスワードが表示され、続けて Done と出ます。ユーザー名とパスワードの両方を、その場で安全な場所へ控えます。表示を流したまま次へ進まないでください。 4. ブラウザで管理コンソールを開きます。既定のアドレスは次のとおりです。 https://<safeline-ip>:9443/ <safeline-ip> はSafeLineサーバのIPアドレスに置き換えます。導入時に .env の MGT_PORT を変更している場合は、9443ではなく、そのカスタムポートを使います。 5. ユーザー名 admin と、手順3で印字された初期パスワードを入力してログインします。ここで管理を再開できます。導入ガイドは、この操作を管理者アカウントを得る手順として載せており、新規導入の直後にも同じ流れを使えます。印字されたパスワードは控え、コンソールへ入れなくなったときだけリセットを再実行します。 具体的な設定ミス 現場で混同しやすい設定ミスは、MGT_PORT を9443以外へ変えたのに、リセット後も https://<ip>:9443 を開き続けることです。コマンドはホスト上で成功し、端末には admin、生成された初期パスワード、そして Done が出ます。それでもブラウザはコンソールへ届かず、ログイン画面が表示されません。この見え方を、パスワード拒否やアカウント作成失敗とまとめて扱うと、同じリセットを繰り返すだけで時間を失います。 対処は単純です。.env に書いた MGT_PORT の値を確認し、https://<ip>:<そのポート>/ を開きます。既定のままならポートは9443です。アドレスの形は https://<ip>:9443 であり、スキームやポートを記憶で補完しないことが、このミスを再発させない要点です。 もう一つの操作ミスは、ホストのシェルで resetadmin だけを実行することです。リセットツールはホストのコマンドではなく、safeline-mgt の内側で動かすものです。打つべき完全な形は docker exec safeline-mgt resetadmin です。対話シェルへ入ってから別の管理コマンドを探す必要は、公式手順にはありません。 修復を確認する画面と出力 修復の確認は二段階です。第一に、ホスト端末のコマンド出力が初期ユーザー名 admin、生成された初期パスワード、Done の順で終わっていることです。Done が出るまでを成功とみなし、途中の行だけを控えてブラウザへ移らないでください。第二に、正しいポートの管理画面で、その admin と初期パスワードが受け付けられ、コンソールへ入れることです。ログイン画面が表示され、資格情報の入力後に管理画面へ遷移すれば、アカウントの復旧は完了です。 導入ガイドは、リセットの前にSafeLineを止める必要を書いていません。通常のセットアップ手順として、コンソール資格情報を得る操作に位置づけられています。Webコンソールへ到達できない状態でも、リセットはDockerホスト上で実行できるため、ログイン不能そのものはこの手順の障害になりません。 うまくいかないときの切り分け - Done は出たが画面が開かない。MGT_PORT と、ブラウザに入力したポートが一致しているかを見ます。一致していない場合、アカウントではなく待受ポートの指定が誤っています。 - 画面は開くがログインできない。ユーザー名は出力どおり admin か、パスワードは直前の初期パスワードかを照合します。古いパスワードは使いません。 - コマンドが見つからない。ホストで resetadmin 単体を打っていないか、コンテナ名を safeline-mgt 以外にしていないかを確認します。 - どの確認でも、再インストールは最終手段です。公式手順は、失った管理パスワードや導入直後の初期資格情報を、このリセットで取り戻せると示しています。 ドキュメントの入口は docs.waf.chaitin.com です。ポートと出力の二点をチェックリストに残してからログインすれば、同じロックアウトを短時間で切り分けられます。 --- - Demo: demo.waf.chaitin.com - Official docs: docs.waf.chaitin.com - GitHub: chaitin/SafeLine

SafeLine WAF の管理画面にログインできないとき：Docker 上で admin アカウントを再設定する運用メモ SafeLine WAF の管理画面にログインできないとき：Docker 上で admin アカウントを再設定する運用メモ SafeLine は、Web アプリケーションの手前に配置する WAF です。リバースプロキシとして動作し、クライアントからの HTTP トラフィックを検査して、SQL インジェクションや XSS、コマンドインジェクション、SSRF、パストラバーサル、総当たり、HTTP フラッドなどの攻撃を遮断します。Docker と Docker Compose で構築でき、管理コンソールは既定で 9443 番ポートを待ち受けます。SafeLine はクライアントと保護対象サーバーの間に挟まる形で動くため、管理コンソールにログインできないと運用確認や設定変更が滞ります。ただ、今回の復旧手順は再インストール不要で、Docker ホストに接続できれば数分で完了します。 運用していてよく困るのが、管理コンソールの admin パスワードを失念するケースです。初期構築直後に初回パスワードがわからない場合も同様です。この記事では、再インストールせずに管理用アカウントを復旧する手順を、実際の確認コマンドと失敗例を交えて整理します。 まず前提として、復旧作業は Web コンソールからではなく、SafeLine を動かしている Docker ホスト上で実行します。コンソールにアクセスできなくても問題ありません。管理コンソールを提供するコンテナの名前は safeline-mgt です。 事前チェック リセットの前に、次の点を確認しておくと作業がスムーズです。 Docker が使えること。docker version または docker ps を実行し、エラーが出ないことを確認します。 対象コンテナが存在すること。docker ps --filter name=safeline-mgt で、safeline-mgt が一覧に表示されることを確認します。停止中のコンテナも含めて探す場合は docker ps -a を使います。 管理ポートの設定。インストール時に MGT_PORT を変更した場合は、その値を控えておきます。.env ファイルがあれば grep MGT_PORT .env で確認できます。 待受ポートの確認。変更していなければ、ホストで ss -lntp | grep 9443 などを使い、9443 番ポートが待ち受けていることを確認します。ポートが空いていなければ、ファイアウォールやセキュリティグループ、コンテナの起動状態を先に確認します。 リセット手順 ホストのターミナルを開き、次を実行します。コマンドはコンテナ内部ではなく、ホスト側から実行します。 docker exec safeline-mgt resetadmin コマンドの出力を最後まで読みます。成功時には、初期ユーザー名 admin と生成された初期パスワードが表示され、続けて Done と出力されます。この admin と初期パスワードを、その場で安全な場所に控えます。出力はスクロールで見失いやすいため、端末のバッファを遡って丁寧に確認します。 ブラウザで次のアドレスを開きます。 https://<safeline-ip>:9443/ safeline-ip は SafeLine サーバーの IP アドレスに置き換えます。MGT_PORT をカスタマイズした場合は、9443 の代わりにそのポートを使います。 ユーザー名 admin と、手順 2 で控えた初期パスワードでログインします。ログインできれば、管理画面から SafeLine の運用を再開できます。 失敗例：コンテナ名の違い よくあるのが、docker exec safeline-mgt resetadmin を実行して「そのようなコンテナはない」というエラーになるケースです。原因の多くは、コンテナ名の先頭にプロジェクト名が付いている、または別のホストで実行していることです。まず docker ps で表示名を確認し、実際の名前が safeline-mgt になっているかを確かめます。コンテナが停止している場合は docker ps -a も確認します。コンテナが動いていない状態では resetadmin が実行できないため、必要に応じて起動してから再実行します。 失敗例：出力の見落とし もうひとつ多いのが、パスワードの見落としです。出力は長くないものの、初期パスワードが表示された直後に Done が出るため、慌てて端末を閉じると控え損ねます。まずは出力全体を確認し、admin と初期パスワードの両方を記録してからブラウザへ進みます。 運用のヒント このコマンドは公式ドキュメントの導入ガイドで「管理者アカウントの取得」として案内されている手順です。新規インストール直後の初回ログインにも使えます。出力された初期パスワードは安全な場所に保管し、画面共有やチャットへそのまま貼り付けることは避けます。リセットは本当に必要なときだけ実行し、むやみに再実行しないようにします。管理コンソールは https://<safeline-ip>:9443/ です。詳細は公式ドキュメント（docs.waf.chaitin.com）を参照してください。 Demo: demo.waf.chaitin.com Official docs: docs.waf.chaitin.com GitHub: chaitin/SafeLine

发现了一个完成度很高的开源知识库 PandaWiki。 现在做知识库的重要性不用多说，大家都想把文档资产和大模型问答打通。 丢链接或离线文件一键导入，自带排版与全局问答，能直接嵌进网页或接上飞书企微。 想自己搭企业知识库或者参考实现方案的，很值得一看。 github：chaitin/PandaWiki

SafeLine 導入前に Docker Compose と ssse3 を確認するチェックリスト セルフホストの WAF をアプリケーションの前面へ置くとき、先に壊れるのは検知ルールではなくホストの受け入れ判定である。SafeLine は Web アプリケーションとインターネットの間の HTTP をフィルタして監視し、リバースプロキシとして置く。クライアントはオリジンへ届く前にここを通過する（docs.waf.chaitin.com 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 である（docs.waf.chaitin.com https://<ip>: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 から見える。無ければ未確認。 文書はより大きい本番サイズを公開していない。推測のコア数やメモリ目標を足してチェックを盛らない。下限未満のホストは、容量を足すか別マシンにする。コンテナ起動は、足りないメモリやディスクを借りる方法として書かれていない。 番号付きの確認手順 1. 自動導入も compose ファイルの取得も、この一覧が残るまで始めない。出力は変更記録へそのまま貼る。 2. uname -m を先に固定する。不一致のホストでイメージ取得へ進まない。コンテナがアーキテクチャ差を隠す、という期待は手順にない。 3. Docker と Compose をバージョン行として分けて読む。文書の Compose 確認は docker compose version であり、ハイフンでつないだ未記載の置き換えではない。両方の下限を満たすまで、どちらの導入経路も仮定してはいけない。 4. プロセッサ、メモリ、ディスクを下限と比較する。手動手順のディレクトリ例は /data/safeline で、設定とデータはそこへ書かれる。同じ案内がディスク 5GB 以上を繰り返すのはこのためである。df -h は、そのディレクトリが載るファイルシステムで判定する。 5. ssse3 をアーキテクチャ行から独立させる。lscpu | grep ssse3 に一致がなければ、文書化された CPU 要件は確認できていない。免除、ソフトウェアフォールバック、Compose の設定項目による置換は載っていない。出力は一致しても不一致でも保存する。 6. arm64 だった場合だけ、手動導入の文書にある ARM 設定を足す。ARCH_SUFFIX=-arm と POSTGRES_IMAGE=chaitin/safeline-postgres-arm:15.18 である。ARM に入れた SafeLine が正しく動くには Pro ライセンスが必要で、Personal Edition は ARM 非対応である。既定の x86 イメージ名を arm64 へ向けない。アーキテクチャが一致しても ssse3 のコマンドは省略しない。表は両方を要求している。 7. 全行が確認できてから導入経路を選ぶ。推奨は root が要る自動導入で、コマンドは bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en である。完走は導入成功を意味し、そのあと Web UI を開く。このスクリプトは、無い Docker や古い Compose を発見するための探りではない。新しい仮想マシンでも、バージョンコマンドが先である。 8. 手動経路は順序がより厳しい。必要なら Docker を入れ、/data/safeline のようなディレクトリを作り、compose.yaml を取得し、.env を書き、トークンを生成し、権限を設定し、最後に docker compose up -d を実行する。起動には数分かかることがある。その瞬間に Compose 2.0.0 未満だと知るのは遅い。受け入れ理由が後から見えるよう、バージョン出力は変更記録に残す。 9. 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 アプリケーションファイアウォールで、元サイト向けの通信を受け、悪意のあるリクエストを除き、残りを上流へ転送する（docs.waf.chaitin.com SafeLine のサーバへ解決する。コンソールのこの作業は、Compose 2.0.0 も ssse3 も検証しない。 サイト側の設定が怪しく見えても、先に変更記録の七行へ戻る。記録が無ければ、コンテナの内側を掘る前にホストで公開コマンドを再実行する。Compose が古い、ssse3 の一致が無い、ディスクが 5GB 未満、のいずれかなら、アプリ設定の見直しはまだ早い。Compose が十分新しくても、ディスク行は省略できない。 七行が残っていて、なおコンソールだけが開かないときだけ、MGT_PORT の既定が 9443 か、開いている URL が https://<safeline-ip>:9443/ かを見る。初期アカウントが要るなら docker exec safeline-mgt resetadmin の表示を使う。ここから先が導入後の画面確認である。受け入れ判定のログは、その画面ではなく、導入前に保存したコマンド出力のほうである。 --- - Demo: demo.waf.chaitin.com - Official docs: docs.waf.chaitin.com - GitHub: chaitin/SafeLine

SafeLine WAF 導入前の Docker Compose と ssse3 確認ガイド SafeLine WAF を自前のサーバに載せる場合、コンテナを作成しただけでは保護は始まりません。まずホストが公開済みの前提条件を満たしているかを確認します。SafeLine は Web アプリケーションの手前にリバースプロキシとして配置され、HTTP トラフィックを監視・フィルタする WAF です。導入ガイド(docs.waf.chaitin.com)に記載された要件は、Linux、x86_64 または arm64、Docker 20.10.14 以上、Docker Compose 2.0.0 以上、CPU 1 コア以上、メモリ 1 GB 以上、ディスク 5 GB 以上、ssse3 対応 CPU です。 Docker Compose と ssse3 の確認は、コンテナ作成後の後始末ではなく、導入前の最初のゲートです。以下、実際にホストで実行する手順に沿って説明します。 1. 公開された確認コマンドを順に実行する 導入先ホストのシェルで、次のコマンドを実行します。 uname -m docker version docker compose version cat /proc/cpuinfo | grep "processor" free -h df -h lscpu | grep ssse3 それぞれの出力は要件表の行と一対一で対応します。uname -m は命令セット、docker version は Docker 本体、docker compose version は Compose、processor は CPU コア、free -h はメモリ、df -h はディスク、lscpu | grep ssse3 は CPU 命令の確認です。別の資産棚卸しスクリプトに置き換えず、このコマンドで確認してください。 2. Docker と Docker Compose を先に確認する Docker は 20.10.14 以上、Docker Compose は 2.0.0 以上が条件です。Compose はスペース入りの docker compose version で確認します。コマンド自体がない場合、または表示されたバージョンが下限より古い場合は、その場で作業を止めます。docker version が下限より古い場合も同様です。 自動導入スクリプトも手動導入も、この下限が満たされている前提で進みます。新しい VM では先にバージョン確認を行い、不足していれば Docker と Compose の更新を済ませてから次へ進みます。 3. アーキテクチャと ssse3 を別々に扱う 対応する命令セットは x86_64 と arm64 です。uname -m がこれ以外を返したら、公開された対応表の外です。コンテナイメージが差を吸収してくれることを期待して compose ファイルの取得や起動に進まないでください。 ssse3 は別の行です。lscpu | grep ssse3 で該当行が出れば、そのフラグが lscpu から見えていることを確認できます。何も返らない場合は要件未達です。導入ガイドには免除、ソフトウェア代替、Compose の設定による回避策は記載されていません。どちらの結果も出力を保存してください。 arm64 だからといって ssse3 の確認を省略できません。手動で ARM に導入する場合は、ARCH_SUFFIX=-arm と POSTGRES_IMAGE=chaitin/safeline-postgres-arm:15.18 を設定します。ARM 上では Pro ライセンスが必要で、Personal Edition はサポートされません。まず uname -m を確認し、その後に記載された ARM 向け設定だけを適用します。arm64 のホストを既定の x86 イメージ名に向けないでください。 4. 容量を公表された下限と比較する 最小構成は CPU 1 コア、メモリ 1 GB、ディスク 5 GB です。cat /proc/cpuinfo | grep "processor" でプロセッサ、free -h でメモリ、df -h でファイルシステム容量を確認します。手動導入では SafeLine が書き込むディレクトリに 5 GB 以上が必要と繰り返し示されています。 下限を下回る場合は、容量を追加するか別のホストを選びます。想定コア数や想定メモリ量を勝手に上乗せしないでください。コンテナの起動が不足したメモリやディスクを補う手段として記載されているわけでもありません。 5. 失敗例 新規 VM で docker compose version が 1.29 を返していたのに、先に自動導入スクリプトを実行したケースがあります。イメージ取得の途中で Compose プラグインの差に起因するエラーが発生し、作業がどの段階まで進んだか分かりにくくなりました。また、lscpu | grep ssse3 が何も返さない旧い仮想化基盤では、コンテナを立ち上げてから初めて CPU フラグの未達に気づくことになります。事前にコマンド出力を控えておけば、このような手戻りを避けられます。 6. ゲートを通過してから導入する アーキテクチャ、Docker、Compose、CPU、メモリ、ディスク、ssse3 をすべて確認できたら、導入パスを選びます。自動導入は推奨されており root が必要です。手動導入は最後に docker compose up -d を実行します。MGT_PORT を既定の 9443 のままにした場合、コンソールは https://<ip>:9443/ で開きます。初期管理者アカウントは docker exec safeline-mgt resetadmin で確認します。 アプリケーション保護はコンソール上の別の作業です。ドメイン、待受ポート、アップストリームを指定して追加し、そのドメインを SafeLine サーバへ向けます。ただし、これらの作業が Compose 2.0.0 や ssse3 を検証してくれるわけではありません。先にホスト側の確認を済ませ、コマンド出力を保存してから、インストーラまたは compose ファイルを開いてください。 Demo: demo.waf.chaitin.com Official docs: docs.waf.chaitin.com GitHub: chaitin/SafeLine