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

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

FlaskとDjangoをWAFで守る前に、公開経路を一本化する PythonのWebアプリをWAFで守る作業は、ビューへデコレータを足す話から始めない。FlaskもDjangoも、誰かがソケットを受理したあとでHTTPを解釈する。その誰かがアプリケーションサーバ自身なら、インジェクション、ディレクトリを遡るパス、認証情報の連続投入は、方針が見る前にPythonへ着地する。実用上の問いは、利用者が通れる道がリバースプロキシ型のファイアウォールだけか、である。 先に失敗例を一つ置く。検証用の名前はSafeLineへ向けた。ところが本番のPythonポートは、公開側のインタフェースで待ち受けたまま残っていた。試行はそのポートへ直結し、プロキシを通らなかった。ブロックページは出ず、コンソールの攻撃一覧にも事象は残らない。残ったのはアプリケーションサーバ側の記録だけだった。迂回できる前段は、制御として数えない。 SafeLineは、Webアプリケーションとインターネットの間のHTTPをフィルタし、監視する自己ホスト型WAFとして文書化されている。前段に置けばリバースプロキシになる。クライアントはここを通過し、その後にオリジンへ届く。運用手順の言い方では、元サイト宛ての通信を受け、悪意のある攻撃通信を除き、残った通信を上流のアプリケーションへ渡す。この流れにPython固有の項目はない。だから同じ置き方がFlaskとDjangoの両方に使える。文書にあるのはコンソールでのアプリケーション追加と、公開名をプロキシへ解決させる作業であり、プロジェクトへ入れるフレームワーク用プラグインではない。 管理画面は https://<ip>:9443 で開く。基準にする説明は docs.waf.chaitin.com だ。インストール手順の細部はデプロイガイドに任せ、ここでは本当に後ろへ入ったかを決める判断だけを扱う。 名前解決を変える前に、次の順で確認する。 上流は、元アプリの実アドレスにする。本番でHTTPを受理しているGunicorn、uWSGI、または同等のサーバだ。SafeLineはそこへ転送するだけで、プロセスの動かし方は置き換えない。ノートPC上のデバッグサーバを上流にしない。 ホスト条件をデプロイ基準へ合わせる。Linux、x86_64またはarm64、Docker 20.10.14以上、Docker Compose 2.0.0以上、CPUコア1以上、メモリ1GB以上、ディスク5GB以上、そしてssse3をサポートするCPUである。ARMなら、同じガイドはProライセンスを必要とし、Personal Editionは非対応だと述べている。そのノードに載せる前に、この差を勘定する。 ApplicationsでAdd Applicationを選ぶ。Domainは利用者が使う名前かアドレス、PortはSafeLineが聴くポートにする。80や443が例だ。HTTPSのアプリならSSLを有効にする。Upstreamはオリジンのアドレスにする。 切替後に、Pythonの待受ポートが公開インタフェースへ残っていないことを確認する。プロキシとオリジンが横並びで届く状態は、未完了と同じだ。 攻撃の遮断と、普段の通信の通過を両方見てから、DNS切替を完了扱いにする。正当な応答まで拒否する設定は、まだ切り替えない。 制御は、出荷している面に合わせて選ぶ。製品紹介が挙げるのは、Web攻撃への防御、ボット悪用への先回り、HTMLとJSのコード暗号化、IPベースのレート制限、Webアクセス制御リストである。 攻撃のフィルタが、前段を置く主目的だ。文書上の対象には、SQLインジェクション、XSS、コードインジェクション、OSコマンドインジェクション、CRLFインジェクション、LDAPインジェクション、XPathインジェクション、RCE、XXE、SSRF、パストラバーサル、バックドア、ブルートフォース、HTTPフラッド、ボット悪用がある。Django管理画面の検索欄、Flaskのクエリパラメータ、ファイルパスを返すダウンロードは、この層ではどれもHTTPだ。 レート制限は、定義した上限を超えた通信を絞る。機能一覧では、サービス拒否の型、ブルートフォース、急増、その他の悪用に結びつけられている。ログイン、パスワード再設定、トークン発行は、パスワードハッシュが重くなりやすい。そこへ先に当てる。 CAPTCHAチャレンジは、人を通し、クローラとボットを止める。認証チャレンジを有効にすると、パスワードを求めるか訪問を止める。サイト全体の追加関門であり、Djangoの認証やFlaskのセッションの代わりではない。利用者とオブジェクトの権限は、これまで通りフレームワークに置く。 動的保護は、訪問ごとにHTMLとJavaScriptを暗号化する。サーバ描画のページで、そのHTMLとJSを覆いたいときに有効にする。JSONを返すエンドポイントの盾ではない。APIだけのサービスで最初に触るのは、Web攻撃のフィルタ、レート制限、アクセス制御だ。動的保護を最初のスイッチにしない。 アクセス制御リストは、許可または拒否すると既に決めている送信元に使う。アプリ内の認可を、ここへ移さない。 遮断と通過の確認は、アプリケーション手順が公開しているサンプルを、自分のドメインへ再送するところから始める。中身は、SQLインジェクションのunion select、XSSの画像ハンドラ、/etc/passwd へのパストラバーサル、コードインジェクション、XXEのdoctypeだ。遮断されればブロックページが出る。ブラウザの一画面だけで判断せず、コンソールの攻撃一覧を開き、詳細で事象を見る。 続けて、利用者が日常的に送る通信を通す。ログイン、フォーム送信、静的ファイル、APIがあるならその一回だ。保護が正当なPythonの応答まで閉じて失敗するなら、DNS切替の準備はできていない。サンプル側はブロックページと詳細の両方で確認でき、普段の通信は通る。その二つが揃って、初めて公開名の切替を完了にする。 判断に迷いやすい点は、文書の範囲で切る。Flask拡張やDjangoアプリは要らない。手順がSafeLineモジュールのimportに依存した瞬間、それはこれらのガイドの外だ。上流は本番のPythonサーバを指し、オリジンをプロキシの横で公開したままにしない。サンプルが記録されたかは、例示ホストを自分のドメインへ置き換え、ブロックページのあとで攻撃一覧と詳細を見る。DNSを変える前のホスト確認は、アーキテクチャ、DockerとDocker Composeの版、CPUフラグ、メモリ、ディスクだ。ARMは、述べられているProライセンス要件を先に満たす。 切替当日の見方は単純にする。公開名でサンプルを送り、ブロックページが出ること。同じ時刻に攻撃一覧の詳細へ同じ事象が出ること。続けてログインと静的ファイルが通ること。この三点のどれかが欠けるなら、名前解決を戻す判断を先に用意しておく。Python側の例外を直す作業と、経路の確認を混ぜない。 2026年9月30日時点で、導入数は世界で70万件を超えている。Proの年間プロモーション価格は650ドルから880ドルで、通常の年額は1000ドルだ。版の選択は、特にARMへ載せるかどうかとセットで見る。配置の成否そのものは、価格ではなく、公開経路がプロキシ一本になっているかで判断する。 2026年9月30日時点で、SafeLine の導入数は 70 万件を超えています。SafeLine Pro の年間プロモーション価格は $650〜$880 で、通常価格は $1,000 です。 SafeLine website: ly.cyberserval.tech Demo: demo.waf.chaitin.com Official docs: docs.waf.chaitin.com GitHub: chaitin/SafeLine Pro offer: cyberserval.tech

SafeLine WAFレビュー：機能・料金・判定をチェックリストと切り分けで読む 導入判断を広告の要約で終わらせないため、SafeLine WAFのレビューを導入前チェックリストと、通信が盾を通らないときの切り分けとして書く。観点は SafeLine WAF review — features, pricing, and verdict の三つに限る。根拠は公式の導入説明、デプロイ手順、アプリケーション追加手順だけを使い、価格と導入件数だけは、その三ページに無い数字として別欄に置く。説明の起点は docs.waf.chaitin.com 、デプロイは docs.waf.chaitin.com 、アプリ追加は docs.waf.chaitin.com である。管理画面は https://<ip>:9443 で開く。ここに手順が無い制御、規則文法、応答時間は、想像で埋めない。 機能チェックリスト 判定の前に、次の項目を文書の文言と突き合わせる。 - 製品の位置づけは、自己ホスト型のWebアプリケーションファイアウォールである。導入説明は、WAFがWebアプリとインターネットの間のHTTPをフィルタし監視すると書き、前段に置くことでアプリとインターネットの間に盾を置く、と説明している。 - 実装はリバースプロキシである。クライアントは元サーバへ直行せず、SafeLineを通過してからサーバへ到達する。アプリ追加の手順も同じモデルで、nginxを基に開発され、元サイト宛ての通信を受け、悪意ある攻撃通信を除き、安全と扱った通信だけを元のアプリケーションへ転送する。 - 遮断の対象は悪意あるHTTPとHTTPSである。許可されないデータがアプリの外へ出ることを防ぐ、という記述もある。分離はポリシーによるとされるが、三ページはアクセス制御の規則文法を公開していない。ラベルを規則集へ展開しない。 - 攻撃のカタログと、出荷すると書かれた制御を分けて記録する。カタログはSQLインジェクション、XSS、コードインジェクション、OSコマンドインジェクション、CRLFインジェクション、LDAPインジェクション、XPathインジェクション、RCE、XXE、SSRF、パストラバーサル、バックドア、ブルートフォース、HTTPフラッド、ボット悪用である。これは脅威の種類の一覧であり、スイッチ名ではない。 - 制御セットは五つだけを写す。Web攻撃への防御、ボット悪用への能動的な防御、HTMLとJSのコード暗号化、IPベースのレート制限、Webアクセス制御リストである。 - 名前付きの動きを一つに潰さない。レート制限は、定義した上限を超える通信を絞るもので、DoS、ブルートフォース、通信の急増、その他の悪用が文書上の対象である。CAPTCHAは、人の利用者を通し、クローラとボットを止める課題として書かれる。認証チャレンジを有効にすると、訪問者はパスワードを入力しなければ遮断される。動的保護を有効にすると、訪問のたびにWebサーバ上のHTMLとJSが動的に暗号化される。ショーケースではHTML動的保護とJS動的保護が別項目なので、無名の一つのスイッチとして扱わない。 - 本番利用できる、という記述は導入説明にある。これは資源条件やライセンス条件の免除を意味しない。 ホストと版のチェックリスト 機能が文書にあっても、置けなければ適合ではない。デプロイ手順が求める確認は次のとおりである。 - OSはLinux、アーキテクチャはx86_64またはarm64である。 - Dockerは20.10.14以上、Docker Composeは2.0.0以上である。 - 下限はCPU 1コア、メモリ1GB、ディスク5GBである。手動手順のデータディレクトリも、少なくとも5GBの空きを要する。 - CPUはssse3をサポートする。手順ページは、アーキテクチャ、Dockerの版、Composeの版、プロセッサ情報、メモリ、ディスク、ssse3の確認を挙げている。 - 自動導入はroot権限のスクリプトである。手動ではcomposeファイルを取得し、環境ファイルを書き、管理用と検知用の秘密を生成し、権限を締めてからDocker Composeで起動する。 - コンソールの例はHTTPSの9443番で、環境テンプレートの既定MGT_PORTと一致する。管理者アカウントは、管理コンテナ内のresetadminで初期化する。 - ARMに載せた場合、正しく動くにはProライセンスが必要で、Personal EditionはARMではサポートされない。これは脚注ではなく判定条件である。 - LTSを検討するなら、9.1.0-LTSは2025年8月14日から保守されない、と記録する。利用者は最新版への更新を強く推奨され、不安がある場合は新しいリリースから1か月待つ、という提案がある。 料金を判定に入れてよいか 三つの公式ページは、価格、サブスクリプション料金、課金単位を掲載していない。エディションがあることまでは、ARMにProが要り、Personal EditionがARM非対応である、という記述から分かる。それは金額の証拠ではない。 別途渡された商業上の数字として、2026年9月30日時点の導入は世界で700,000件を超えている。Proの年間プロモーションは650ドルから880ドルで、通常価格は年1,000ドルと比較される。この二つはドキュメント三ページからの引用ではない。更新条件、含まれる支援、課金単位は、この幅だけでは確定できない。費用で購入を決めるなら、公式の商業資料を別に要求し、このレビューの料金判定は未了のまま残す。導入件数は普及の記録であり、料金の妥当性も検知精度も証明しない。 効果の表は、ベンダーが公開した数字としてだけ写す。各列の総標本は33,669件である。ModSecurity Level 1は検知69.74%、誤検知17.58%、精度82.20%。CloudFlareのFree列は検知10.70%、誤検知0.07%、精度98.40%。SafeLine Balanceは検知71.65%、誤検知0.07%、精度99.45%。SafeLine Strictは検知76.17%、誤検知0.22%、精度99.38%。渡された本文は、標本の日付、ペイロードの内訳、比較対象の設定を定義していない。遅延、スループット、独立した優劣は足さない。 支援として書かれているのは、Discord上のコミュニティ支援である。中核メンバーはSTAFFロールで識別され、機能の議論、FAQ、一般質問のチャネルに加え、GitHubのissueがある。これは契約上の支援階層ではなく、応答時間も定義されていない。 切り分け：名前解決を元サーバのままにした誤設定 ここで扱う誤設定は一つに固定する。Applicationsでドメイン、待ち受けポート、上流アドレスは保存し、HTTPSのアプリならSSLにもチェックを入れた。しかしドメインの名前解決をSafeLineサーバへ向けず、元のアプリケーションサーバのままにした。クライアントは盾を迂回し、文書どおりの試験を送っても遮断ページが出ない。管理コンソールの攻撃一覧にも行が残らない。これは検知規則の失敗ではなく、経路がプロキシを通っていない状態である。 直すときは、次の番号を飛ばさない。 1. https://<ip>:9443 の管理コンソールへ入り、Applicationsの当該行を開く。待ち受けが80または443であること、HTTPSならSSLが有効であること、上流が元アプリケーションのアドレスであることを確認する。9443は管理ポートであり、上流アドレスではない。 2. ドメインの解決先を調べ、SafeLineサーバを向いていない場合はそこへ改める。上流と解決先を同じホストへ重ねると、元アプリへ転送する前提が崩れる。 3. アプリ追加のページにある試験ケースを、そのドメインへ送る。文書が挙げるのはSQLインジェクション、XSS、パストラバーサル、コードインジェクション、XXEである。まずはSQLインジェクションのケースで経路を見る。これは全変種を防ぐという約束ではない。 4. ブラウザに遮断ページが出るか確認する。出ない場合は、名前解決、待ち受け、SSL、上流のどれかがまだ文書の手順とずれている。 5. 管理コンソールの攻撃一覧を開き、今送った試験の詳細が載っているか見る。 修正を確定する画面は、独自のログファイルではない。文書が指定するのは、遮断ページと、コンソールの攻撃一覧である。遮断ページが表示され、攻撃一覧に当該試験の行が出た時点で、この名前解決の誤設定は解消したと扱ってよい。一覧が空のままなら、クライアントはまだ元サーバへ直達している。BalanceとStrictのどちらが優れるかは、この1件では判断しない。 守れる判定 チェックリストを通過した範囲で守れるのは、条件付きの適合判定である。SafeLineは自己ホストのリバースプロキシ型WAFで、名前のある攻撃カタログ、レート制限、CAPTCHA、パスワードチャレンジ、HTMLとJSそれぞれの動的暗号化、名前のあるアクセス制御を備える。導入説明は本番利用できると述べ、コンソールは9443、アプリの載せ方はドメイン、待ち受け、SSL、上流、名前解決の順で再現できる。 適合はLinux、Docker、Compose、公開された資源下限、ssse3、そしてARMならProライセンスに依存する。LTSを残すなら、9.1.0-LTSが2025年8月14日から保守外である点を判定へ入れる。料金は、三ページからは判定できず、650ドルから880ドルという年間プロモーションと年1,000ドルという通常価格は外部数字の併記にとどめる。未掲載の規則、支援契約、表が説明しない通信での優劣は、このレビューでは主張しない。 --- 2026年9月30日時点で、SafeLine の導入数は 70 万件を超えています。SafeLine Pro の年間プロモーション価格は $650〜$880 で、通常価格は $1,000 です。 - SafeLine website: ly.cyberserval.tech - Demo: demo.waf.chaitin.com - Official docs: docs.waf.chaitin.com - GitHub: chaitin/SafeLine - Pro offer: cyberserval.tech