chaitin/SafeLine — 優良食堂詳しい解説

01 / 概要

何をするものか一文で言うと

ひとことで自社ホストできるWebアプリケーションファイアウォール(WAF)で、SQLインジェクションやXSSなど多様な攻撃から保護します。

SafeLineは自己ホスト型のWebアプリケーションファイアウォール(WAF)兼リバースプロキシです。SQLインジェクションやXSSなど、Webアプリへの攻撃をトラフィック段階で検知・遮断します。管理画面(webserver)、nginx設定生成デーモン(tcontrollerd)、検知エンジン連携用SDK、AIエージェント向けMCPサーバーという複数コンポーネントで構成されています。

02 / 構造

どう動くのか中核のしくみ

読み方動きの流れを図と一緒にほどきました。

実際のトラフィック検査は、OpenResty上で動く sdk/lua-resty-t1k モジュールが担っています。リクエストごとにT1Kという独自プロトコルで検知エンジンへ問い合わせ、許可・遮断を判断する仕組みです。同じロジックはKong用プラグイン(sdk/kong)やingress-nginx用SDKにも移植されており、既存ゲートウェイへの組み込みも可能です。管理側では management/webserver がGin製REST APIとPostgres(gorm)でwebsite・policygroup・policyruleなどのモデルを保持し、pkg/fvm 配下でFSL(ルール表現)を生成します。生成結果は management/tcontrollerd がgRPC(proto/website)経由で受け取り、nginx設定テンプレートを書き出したうえで ngcmd.go の `nginx -t` と `nginx -s reload` を呼んで反映します。cron(pkg/cron)は forbidden_page など定期処理も担当します。加えて mcp_server は create_rule や get_attack_events といったMCPツールを提供し、AIエージェントがHTTP経由でwebserverのAPIを操作できるようにしています。ただし、SQLi/XSS判定の中核ロジックそのもの(検知エンジン本体)は本リポジトリには含まれておらず、closed sourceの別コンポーネントである点に注意が必要です。

03 / 体験

入れるとこんな体験になりますギット飯が実際にたどった順序

所要ギット飯が実際に導入・実行しながらたどった順序です。

STEP 01
compose.yamlを使い docker compose up でmanagement・tengine・postgresなど複数コンテナを起動する体験になります。
STEP 02
初回アクセス時に管理画面の初期アカウント設定画面が表示され、パスワードなどを設定します(images/auth-1.gifに近い流れ)。
STEP 03
保護したいWebサイトをwebsite APIまたは管理画面から登録し、リバースプロキシ先を指定します。
STEP 04
擬似的な攻撃リクエスト(SQLi文字列など)を送ると、images/blocked-for-attack-detected.pngのような遮断ページが返る想定です。
STEP 05
ダッシュボード(api/dashboard.go、api/detectlog.go)で検知ログや統計情報を確認できます。
STEP 06
mcp_server/README.mdの手順に沿ってMCPサーバーを別途起動すると、AIエージェントからcreate_ruleやget_attack_eventsを呼び出せます。

04 / 成果物

何が手に入るのか導入後に手元に残るもの

稼働させると、リバースプロキシ経由でWebアプリを保護しつつ、管理画面から攻撃検知ログ・ポリシールール・レートリミット設定を確認・操作できる状態が手に入ります。KongやNGINX Ingressに組み込む場合はSDK配下のプラグインをそのまま利用できます。MCPサーバーを併用すれば、AIエージェント経由でのルール作成や攻撃イベント取得も可能になります。

05 / 注意

ここは先に知っておいてください先に知っておくとよいこと

正直なところ誰にでも合うとは言いにくいところです。

攻撃判定の中核となる検知エンジン本体はこのリポジトリに含まれておらず、closed sourceの別コンポーネントに依存しています。

compose.yamlは複数コンテナイメージの起動を前提とした構成で、ソースから全コンポーネントをビルドして動かす想定にはなっていないようです。

webserverはPostgres・gRPC・gormを組み合わせた構成のため、実運用には相応のインフラ理解とリソースが必要です。

READMEとソース構造から挙動を推測している部分があり、実際のダッシュボードUIの細部はスクリーンショットからの推測にとどまります。

06 / 結論

ギット飯の結論食べてみる価値のある一膳か

ギット飯の最終判断優良食堂

自前でWebアプリの前段にWAFを置きたい個人・組織で、Docker運用に慣れているなら試す価値があります。KongやNGINX Ingressユーザーは既存SDKをそのまま流用できる点も強みです。一方、検知精度を左右する核心エンジンが非公開のため、遮断ロジックの中身まで検証したい人には限界があります。ソースの分業構造(webserver・tcontrollerd・SDK・mcp_server)が一貫しており、README記載の機能とファイル実装が対応しているため、インストールしなくてもおおよその挙動判断は可能です。