chaitin

Activity

Stars and mentions · Last 30 days, Oct 6 – Nov 4

GitHub stars443

Mentions108

UTC days · repositories chaitin owns4 repositories

Top repositories

chaitin’s repositories ranked by pull request authors, as on trending.

#	Repository	Activity ⓘ	Stars	Forks	Contributors
1
2
3
4
5
6
7
8
9
10

Contributes to

Repositories outside chaitin’s account where chaitin opened or reviewed pull requests in the past 365 days.

Who noticed chaitin

Everyone who starred or forked chaitin’s repositories since the archive began in 2011.

Notable accounts

Ordered by the stars their own repositories have received.

Biggest fans

Accounts that starred the most of these repositories.

Breakout weeks

Each repository’s best week of new stars, with the release published around it.

Mentions

114posts

Nov 56 posts

Qiita · Nov 5 · @Karinbiubiu · chaitin/SafeLine
SafeLine WAF のアップストリームヘルスチェック間隔：設定前に確認するチェックリストとトラブルシューティング SafeLine は、Web アプリケーションとインターネットの間で HTTP トラフィックを監視・フィルタリングするセルフホスト型の WAF です。SQLインジェクション、XSS、コードインジェクション、OSコマンドインジェクション、CRLFインジェクション、LDAPインジェクション、XPathインジェクション、RCE、XXE、SSRF、パストラバーサル、バックドアなどの攻撃をブロックします。リバースプロキシとして動作し、クライアントの通信は本来のサーバーへ届く前に SafeLine を通過し、安全になったトラフィックだけが実際のアプリケーションへ転送されます。公式ドキュメント（docs.waf.chaitin.com セットアップ手順 1. ホストの依存関係を確認します。SafeLine は Linux の x86_64 または arm64 アーキテクチャ、Docker 20.10.14 以上、Docker Compose 2.0.0 以上、1 コア以上の CPU、1 GB 以上のメモリ、5 GB 以上のディスク、ssse3 対応が必要です。uname -m、docker version、docker compose version、free -h、df -h を実行して環境を確かめます。 2. root 権限で自動インストーラーを実行します。bash -c "$(curl -fsSLk waf.chaitin.com)" -- --en を実行すると、SafeLine がインストールされ、Web コンソールが使える状態になります。 3. 手動インストールの場合は、mkdir -p "/data/safeline" でデータディレクトリを作成し、wget "waf.chaitin.com" で compose ファイルを取得します。.env に SAFELINE_DIR、IMAGE_TAG、MGT_PORT、POSTGRES_PASSWORD、検出器管理トークンなどの必須値を書き込み、docker compose up -d で起動します。 4. Web コンソールを https://<safeline-ip>:9443/ で開きます。docker exec safeline-mgt resetadmin を実行すると初期ユーザー admin と生成されたパスワードが返るので、これで管理者アカウントを作成します。 5. アプリケーションを登録します。Applications ページで Add Application をクリックし、Domain、SafeLine が待ち受ける Port（80 や 443 など）、実際のアプリへ転送するための Upstream を入力します。HTTPS アプリケーションの場合は SSL オプションを有効にします。 6. ドメイン名を SafeLine が動作するサーバーの IP アドレスに解決し、そのドメイン経由でアプリケーションへアクセスしてプロキシ経路が生きていることを確認します。ヘルスチェックの判断チェックリスト SafeLine は nginx を基盤としており、Add Application の流れでは Upstream の値を転送先として扱います。提供されているドキュメントにはヘルスチェック間隔を個別に制御する項目が定義されていないため、隠れた既定値を勝手に想定しないでください。監視動作を変更する前に、次の点を確認します。 - アップストリームが、SafeLine が使うプローブ方式（TCP 接続チェックか HTTP リクエストか）を実際に受け付けられるか。 - チェックのタイムアウトを間隔より短く設定し、応答の遅いアップストリームが次のプローブと重ならずに確実に失敗扱いになるようにする。 - 間隔は、本来のサーバーをどれだけ早くダウンと判定したいかに合わせて選ぶ。間隔を短くすると障害検知は早いが、プローブのトラフィックは増える。 - 何回連続で失敗したらアップストリームを異常と見なし、何回成功したら復帰と見なすかを決める。 - デプロイ後にアップストリームの状態を監視し、推測ではなく実際の障害挙動で設定した間隔を検証する。よくある設定ミスもっとも多いのは、チェックのタイムアウトを間隔より長く設定してしまうケースです。たとえば、間隔を 5 秒にしたのにタイムアウトを 10 秒にすると、前のプローブの応答を待っている間に次のプローブが始まってしまいます。応答が遅いアップストリームではプローブが次々と重なり、一時的な遅延を恒常的な障害と誤判定したり、プローブの負荷が本来のサーバーを圧迫したりします。この場合、タイムアウトを間隔より短い値（例として間隔 10 秒に対してタイムアウト 3 秒など）に戻すことが修正の基本です。修正の確認方法修正後は、ドメインを SafeLine のサーバー IP に解決したうえで、そのドメイン経由でアプリケーションへアクセスします。攻撃テストのリクエストがブロックページを返すこと、そして Web コンソール（https://<ip>:9443）にブロックされた試行が一覧表示されることを確認してください。SafeLine は nginx ベースなので、アップストリーム接続の失敗やタイムアウトは nginx のログに現れるのが一般的です。コンソール上の表示とログの両方で、プローブが正常に完了し、アップストリームが想定どおりの間隔で監視されていることを確認できれば、修正は完了です。まとめ公式ドキュメントにはヘルスチェック間隔の専用項目がないため、まずは正しいセットアップと正しい Upstream 登録を済ませたうえで、プローブ方式・タイムアウト・間隔・失敗閾値・復帰閾値を自分の環境に合わせて決めることが大切です。設定変更の前には必ずチェックリストで確認し、変更後は Web コンソールとログで実動作を検証しましょう。 --- - Demo: demo.waf.chaitin.com - Official docs: docs.waf.chaitin.com - GitHub: chaitin/SafeLine
Zenn · Nov 5 · @aoi_sato8734 · chaitin/SafeLine
SafeLine WAF の upstream ヘルスチェック間隔を確認する実践ガイド SafeLine は、Web アプリケーションとインターネットの間で HTTP トラフィックを検査し、SQL インジェクションや XSS、コードインジェクション、OS コマンドインジェクション、CRLF インジェクション、LDAP インジェクション、XPath インジェクション、RCE、XXE、SSRF、パストラバーサル、バックドアといった攻撃を遮断する自己ホスト型の WAF です。リバースプロキシとして動作し、クライアントからの通信は最初に SafeLine を経由し、安全と判断されたトラフィックだけがオリジンサーバーへ転送されます。この記事では、upstream のヘルスチェック間隔を調整する前に知っておくべきことを、実際の運用者の視点から整理します。重要な前提として、公式ドキュメントには専用の「ヘルスチェック間隔」を設定する項目は公開されていません。そのため本記事では、ドキュメントに記載された設定手順と、upstream 監視を設計する際に自分で確認すべきチェックリストを分けて説明します。セットアップの確認手順まず、SafeLine が正常に動いていることを確認します。以下は番号付きの手順です。ホストの前提条件を確認する。SafeLine は x86_64 または arm64 の Linux、Docker 20.10.14 以上、Docker Compose 2.0.0 以上を必要とし、最低 1 コア CPU、1 GB メモリ、5 GB ディスク、ssse3 対応が求められます。uname -m、docker version、docker compose version、free -h、df -h を実行して環境を確認します。 root 権限で自動インストーラーを実行する。bash -c "$(curl -fsSLk waf.chaitin.com)" -- --en を実行します。完了後、Web コンソールが利用可能になります。手動インストールの場合は、mkdir -p "/data/safeline" でデータディレクトリを作成し、wget "waf.chaitin.com" で compose ファイルを取得し、.env に SAFELINE_DIR、IMAGE_TAG、MGT_PORT、POSTGRES_PASSWORD、および detector 管理トークンなどの必須値を記入して、docker compose up -d で起動します。ブラウザで https://<ip>:9443/ を開きます。管理者アカウントは docker exec safeline-mgt resetadmin で作成し、初期ユーザー名 admin と生成されたパスワードが返されます。アプリケーションを登録する。[Applications] ページで [Add Application] をクリックし、[Domain]、SafeLine が待ち受ける [Port]（例: 80 または 443）、実アプリの実アドレスを入れる [Upstream] を入力します。HTTPS の場合は [SSL] オプションを有効にします。ドメイン名を SafeLine が配置されたサーバーの IP アドレスに解決し、そのドメイン経由でアプリケーションにアクセスして、プロキシ経路が動作していることを確認します。 upstream ヘルスチェックの設計チェックリスト SafeLine は nginx を基盤としており、[Add Application] の [Upstream] が転送先として扱われます。ただし、公開されているドキュメントにはヘルスチェック間隔を直接変更する項目がありません。隠れた初期値があると思い込まず、監視動作を変える前に以下の点を確認してください。 upstream エンドポイントが、SafeLine が使う検査方式（TCP 接続確認または HTTP リクエスト）を実際に受け付けるか確認する。検査のタイムアウトを間隔より短く設定する。こうすることで、遅い upstream が次の検査と重ならずに確実に失敗扱いになります。オリジンをどれだけ早く「障害あり」と判定したいかに合わせて間隔を選ぶ。間隔を短くすると障害検知は速くなりますが、検査トラフィックは増えます。連続何回の失敗で「unhealthy」とみなし、連続何回の成功で復旧とみなすかを定義する。設定後は upstream の状態を監視し、設定した間隔を推測値ではなく実際の障害挙動と照らし合わせて検証する。失敗事例ある環境では、upstream のヘルスチェックに HTTP リクエスト方式を想定して設定したものの、実際のオリジンは特定のパス以外に応答しない設定でした。検査リクエストが想定したパスへ届かず、実際にはアプリケーションが正常でも「失敗」と判定される状態が続きました。また、タイムアウトが検査間隔より長いままだと、遅い応答と次の検査が重なり、障害判定が不安定になります。この例からも、方式・タイムアウト・間隔・閾値をセットで確認する必要があると分かります。よくある確認公式ガイドにヘルスチェック間隔の項目はありますか？いいえ。[Add Application] ガイドには [Domain]、[Port]、[Upstream]、HTTPS 用の [SSL] オプションしか記載されておらず、専用のヘルスチェック間隔は文書化されていません。 upstream アドレスはどこで設定しますか？ [Applications] ページの [Add Application] ダイアログです。[Upstream] に実アプリの実アドレスを入れ、SafeLine は検査後のトラフィックをそこへ転送します。待ち受けポートはどう決めますか？ SafeLine が待ち受けるポート（例: 80 または 443）を入力し、HTTPS なら [SSL] を有効にします。このポートはオリジンの upstream ポートとは別です。プロキシ経路の動作確認はどうしますか？ドメインを SafeLine サーバーの IP に解決し、そのドメイン経由でアクセスします。攻撃を模したリクエストにはブロックページが返り、Web コンソールに遮断履歴が記録されます。ヘルスチェック間隔を変える前に何を確認しますか？検査方式、タイムアウト、失敗閾値、復旧閾値、そしてオリジンが追加の検査負荷に耐えられるかを確認します。公開ドキュメントには間隔の値が示されていないため、これらは SafeLine の初期値ではなく、自分で確認すべき項目として扱います。まとめ upstream のヘルスチェック間隔を正しく運用するには、まず SafeLine のセットアップと [Upstream] の登録を確実に済ませ、そのうえで検査方式・タイムアウト・間隔・失敗閾値・復旧閾値を一つのセットとして設計することが大切です。公式ドキュメントに専用の間隔項目がない以上、推測に頼らず、実際の監視結果を見ながら検証を続けてください。 Demo: demo.waf.chaitin.com Official docs: docs.waf.chaitin.com GitHub: chaitin/SafeLine
Qiita · Nov 4 · @Karinbiubiu · chaitin/SafeLine
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
Qiita · Nov 3 · @Karinbiubiu · 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
Zenn · Nov 3 · @aoi_sato8734 · 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
Qiita · Nov 2 · @Karinbiubiu · 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
Zenn · Nov 1 · @aoi_sato8734 · 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
Qiita · Oct 31 · @Karinbiubiu · 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
Zenn · Oct 31 · @aoi_sato8734 · 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
X · Oct 30 · @realchendahuang · chaitin/PandaWiki
发现了一个完成度很高的开源知识库 PandaWiki。现在做知识库的重要性不用多说，大家都想把文档资产和大模型问答打通。丢链接或离线文件一键导入，自带排版与全局问答，能直接嵌进网页或接上飞书企微。想自己搭企业知识库或者参考实现方案的，很值得一看。 github：chaitin/PandaWiki
28 likes · 4 reposts · 3,021 views

Achievements

Awards earned by the repositories chaitin owns. Select an award to embed its badge.

Gold: 01st place finishes
Silver: 12nd place finishes
Bronze: 03rd place finishes
Awarded repositories: 1Owned by chaitin now

Repositories

Ordered by gold, then silver, then bronze.

SafeLineBest: 2nd by stars, 578 stars010

Every award

Top-three finishes of these repositories in completed trending days and weeks, newest first.

SafeLine

A repository earns an award for finishing first, second or third in a completed trending day or week, ranked by new stars, new forks or pull request authors. Awards follow a repository through renames and transfers and count toward its current owner. Weeks run Monday to Sunday, UTC.