SafeLineをWebアプリの前段へ置く前に確認したい防御範囲

Webアプリの前段に置く自己ホスト型WAF

SafeLineは、Webアプリを攻撃や悪用から守る自己ホスト型のWAFであり、リバースプロキシとして動作するとREADMEに説明されています。WAFはWebアプリとインターネットの間のHTTPトラフィックをフィルタリング、監視する役割を持ち、クライアントはアプリサーバーへ直接到達する前にSafeLineを通ります。サーバーの公開面を前段のポリシーへ集約する構成です。\n\nREADMEは、SQLインジェクション、XSS、コードインジェクション、OSコマンドインジェクション、CRLF、LDAP、XPath、RCE、XXE、SSRF、パストラバーサル、ブルートフォース、HTTPフラッド、ボット悪用などを想定攻撃として挙げています。列挙された攻撃を扱えることと、すべての攻撃を防げることは同じではありません。アプリの経路、認証、API、ファイルアップロードを含む実際の入口を洗い出し、WAFを置いた後もアプリ側の修正を残します。

検知ポリシーを通過点の判断へ使う

リバースプロキシとしてのSafeLineは、HTTPとHTTPSの通信をポリシーに従ってフィルタリング、監視、遮断し、不正なデータがアプリから外へ出ることも防ぐとREADMEは説明しています。つまり、受信側だけでなく、何を許可し、何を遮断し、どのログを残すかが運用の中心になります。\n\nREADMEにある五つの中核機能は、Web攻撃防御、積極的なボット悪用防御、HTMLとJavaScriptコードの暗号化、IPベースのレート制限、Webアクセス制御リストです。機能名だけでポリシーを有効にすると、正規のAPIクライアント、検索クローラー、画像取得、管理画面まで巻き込む可能性があります。最初は観測を中心に設定し、正常な利用パターンを記録してから遮断へ移す手順が必要です。\n\n動的保護では、訪問のたびにWebサーバーのHTMLとJavaScriptコードを動的に暗号化するとREADMEに書かれています。ブラウザ、キャッシュ、監視、障害調査への影響は素材から確認できないため、重要画面を限定して挙動を確かめます。

レート制限とチャレンジを別の防御線にする

Rate Limitingは、定義した上限を超える通信を抑制し、DoS攻撃、ブルートフォース試行、急なトラフィック増加などに対抗すると説明されています。上限は単なる数字ではなく、利用者、IP、認証状態、エンドポイント、時間帯の組み合わせで意味が変わります。ログイン、検索、決済、公開コンテンツを同じ閾値に置かず、業務の正常なピークを先に把握します。\n\nAnti-Bot Challengeは人間の利用者を通し、クローラーやボットを遮断する機能です。Authentication Challengeを有効にした場合は、訪問者がパスワードを入力しなければブロックされるとREADMEにあります。これらは不正なアクセスを減らす手段ですが、正規クローラー、支援技術、社内自動化、モバイル回線の共有IPに影響し得ます。対象範囲、例外、失敗時の連絡手段を決め、チャレンジ導入後のアクセス減少を防御成功と早合点しないようにします。

導入手順はREADMEから公式ガイドへ移る

QuickstartにはSafeLineのインストールコマンドは掲載されていません。READMEはInstall Guideと、Webアプリを保護するためのConfigurationページへリンクしています。正確なシステム要件、配置、初期設定は、この外部ドキュメントで確認する構成です。\n\n中国本土の利用者には、国際版を導入するとクラウドサービスへ接続できない可能性があるという警告があり、中国語版のインストールドキュメントを参照するよう案内されています。これは環境によって導入経路が変わることを示す注意点です。導入前に管理画面が必要とする外部接続、名前解決、更新元、ログの送信先を確認します。\n\nREADMEにはdemo.waf.chaitin.comの9443番ポートで動くLive Demoへのリンクもあります。デモで画面や概念を把握できても、自分の証明書、アップストリーム、認証、データ量における結果とは別です。まず隔離環境で一つのWebアプリを通し、遮断前後のリクエストとログを比較します。

READMEの評価表は条件付きの自報値として読む

READMEのEffect Evaluationには、ModSecurity Level 1、CloudFlare Free、SafeLine Balance、SafeLine Strictを比較する表があります。合計サンプル数は各条件で33,669とされ、検知率はそれぞれ69.74%、10.70%、71.65%、76.17%、誤検知率は17.58%、0.07%、0.07%、0.22%、精度は82.20%、98.40%、99.45%、99.38%と記載されています。\n\nこの表はSafeLine READMEが掲げる結果です。サンプルの出所、テスト期間、環境、再現手順は表だけでは分からず、外部の独立測定として扱うことはできません。Strictが検知率で高いからといって、すべての利用環境で最良とは限りません。BalanceとStrictの閾値、正常リクエストの種類、検知後の業務影響を自分のデータで測ります。\n\nREADMEは本番対応を主張し、世界で40万以上のインストール、100万以上のWebサイト、毎日300億以上のHTTPリクエストという数字を挙げています。これもREADMEに記載された主張であり、導入判断では自社のトラフィック、誤検知許容度、サポート体制へ置き換えて検討します。

Ingress-NGINX、Kong、MCPとの接続を切り分ける

SafeLineのREADMEには、三つのエコシステム統合が記載されています。SafeLine MCP ServerはAIを使った管理と制御、Ingress-NGINXプラグインはKubernetesのIngressトラフィック、Kong GatewayプラグインはAPIとサービスの保護を対象にしています。接続先の層が違うため、どの入口へSafeLineを置くのかを先に図にします。\n\nKubernetesでIngress-NGINXを使っている場合、既存のTLS終端、ルーティング、リトライ、タイムアウトとWAFの役割が重なる可能性があります。Kong Gatewayでも、認証、レート制限、ルーティングをどちらが担当するかを決めます。MCP Serverを管理へ使う場合は、管理操作の権限、対象範囲、監査ログ、外部通信を別のリスクとして点検します。READMEが統合の入口を示すことと、既存構成へ安全に組み込めることは同じではありません。

GPL-3.0と運用責任を一緒に確認する

SafeLineのリポジトリはGPL-3.0でライセンスされています。READMEの説明では、プログラムの版を共有、変更する自由と、受領者がソースコードを取得できる条件が示され、無保証で提供されます。社内利用、改変、再配布、コンテナやプラグインの組み合わせで義務が変わり得るため、配布物と依存物のライセンスを個別に確認します。\n\nコミュニティ経路としてDiscordが案内され、READMEにはHelloGitHubの評価、awesome-selfhostedへの掲載、Product Huntでの紹介、Cyber Pressの記事へのリンクが並びます。これらは認知や利用例の手掛かりになりますが、障害対応時間や修正を保証する契約ではありません。リリース一覧にはv9.4.0などが示されているため、採用時はタグを固定し、設定、ルール、証明書、アップストリーム、バックアップを更新前に保存します。正常系、攻撃模擬、誤検知、復旧の記録を残せる体制がある場合に、SafeLineの適用範囲を広げます。

編集部の結論

SafeLineは、Webアプリとインターネットの間に自己管理型のWAFを置き、攻撃トラフィック、過剰なリクエスト、ボットをポリシーで扱いたい運用者の候補です。READMEの検知率や導入数は自報または外部記事に基づく主張であり、保証ではありません。導入前に実際のアプリで正常系と攻撃模擬を分け、誤検知、ログ、復旧、クラウド接続、ライセンスを確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes