セキュリティ境界とベースライン
セキュリティを設定する前に、2 つの点を確認する必要があります。リクエストが必ず fn-knock を通過するか、そしてゲートウェイが実クライアント IP を取得できているかです。どちらか一方でも満たされなければ、認証、許可リスト、地域ルールが想定どおりに機能しない可能性があります。
最初に境界を確認
fn-knock が制御できるのは、ゲートウェイの入口を通過するトラフィックだけです。次の状況には、ゲートウェイの外側で対処する必要があります。
- ルーター、クラウドのセキュリティグループ、Docker でサービスの元のポートを公開している。
- CDN、リバースプロキシ、トンネルがサービスへ直接オリジン接続している。
- 前段のプロキシが自身のプライベートアドレスをクライアント IP として誤って伝達している。
- 管理画面、データベース、SSH を個別に公開している。
ゲートウェイは、ループバック、プライベートネットワーク、リンクローカル、CGNAT の各アドレスをローカルの送信元として扱い、認証の事前検査でそのまま許可します。このルールは、セッションと IP アクセス許可より先に適用されます。保護されたサービスを検証する際は、モバイルネットワークなど実際の外部経路を使用し、自宅の Wi-Fi だけでテストを終えないでください。
推奨セキュリティベースライン
- 外部へ公開するのはゲートウェイに必要なポートだけにします。管理用の入口は LAN、VPN、または信頼できるリバースプロキシの背後だけに配置します。
- ゲートウェイに正式な HTTPS 証明書を用意し、公開する各 Host に正しい DNS を設定します。
- 復旧に使用できるログイン認証情報を 2 つ以上作成し、普段使うデバイスにはパスキーも登録します。
- 新しいサービスではデフォルトで「ログインを必須にする」を有効にし、明確な必要がある場合にだけ公開します。
- リクエストログとイベント通知を有効にします。通常のトラフィックを確認してから、WAF、ゲートウェイのレート制限、スキャナー、ブラックリストのルールを厳しくします。
- ホスト、fn-knock、アップストリームサービスを定期的に更新し、更新前には保護したバックアップをエクスポートします。
各制御レイヤーの役割
| レイヤー | 対処する問題 | 主な設定場所 |
|---|---|---|
| ゲートウェイの公開範囲 | ゲートウェイへ到達できる地域または CIDR を制限する | システム設定 → ゲートウェイ |
| マッピングのアクセスポリシー | Host を公開するか、ログインを必須にするかを決める | サブドメインマッピング |
| サブドメインの高度な認証 | 送信元またはリクエストの特徴に基づき、現在の Host 用の一時認証情報を発行する | サブドメインマッピング → 高度な認証 |
| 認証とセッション | ID、セッションの有効期間、Cookie の共有、認証情報のサービススコープを管理する | 認証設定、セッションとセキュリティ |
| IP 許可リスト | 固定 IP／CIDR またはログイン後の IP にアクセスを許可する | IP 許可リスト |
| ログイン試行制限 | 同じ送信元でログイン失敗が続いた場合に、次の試行を遅延させる | セッションとセキュリティ → ログイン試行制限 |
| ゲートウェイのレート制限とクローラーブロック | 高頻度のリバースプロキシトラフィックを制限し、識別済みのクローラーを拒否する | システム設定 → ゲートウェイ |
| スキャナーのブロック | 通常とは異なるパスへのアクセスに基づき、独立したブラックリストを管理する | システム設定 → ブロック |
| 共通ブラックリスト | 確認済みの個別の送信元 IP を直ちに拒否する | セッションとセキュリティ → 共通ブラックリスト |
| WAF | ゲートウェイを通過する HTTP リクエストを検出またはブロックする | システム設定 → WAF |
| SSH ファイアウォール | 送信元とログイン失敗に基づいて、ホストの SSH を保護する | SSH セキュリティ。ホストを制御できるデプロイ方式のみ |
| ホストまたは上位のファイアウォール | サービスの元のポートと管理ポートを制限する | ホスト、ルーター、クラウドのセキュリティグループ |
これらの制御は相互に補完するもので、互いの代わりにはなりません。たとえば、WAF が公開済みのデータベースポートを閉じることはなく、許可リストでアップストリームアプリの脆弱性を修正することもできません。サブドメインの高度な認証に一致すると現在の Host 全体へのアクセスが許可されるため、継続的なパス単位の制限として使用しないでください。
実クライアント IP
CDN、リバースプロキシ、トンネルから届くリクエストを正しく識別できるかどうかは、前段から渡される実 IP ヘッダーによって決まります。fn-knock は、一般的な X-Forwarded-For、X-Real-IP、EO-Connecting-IP、Ali-Real-Client-IP の情報を順に処理します。
現在の設定画面には、受信側で信頼するプロキシの CIDR リストはありません。前段のプロキシで、外部クライアントが偽装できる実 IP ヘッダーを削除または上書きする必要があります。前段から 127.0.0.1、192.168.x.x などのアドレスが誤って渡されると、インターネットからのリクエストがローカル除外と誤認される可能性があります。EdgeOne、ESA、Cloudflare、セルフホストしたリバースプロキシへ接続した後は、外部ネットワークからリクエストログの「クライアント IP」と「接続元 IP」をそれぞれ確認してください。
管理画面の分離
管理画面では認証、証明書、プロキシ、ブラックリスト、ターミナルを変更できるため、通常のサービス用入口より厳しい境界を設ける必要があります。
- 認証設定で、管理画面のアクセス可能範囲を個別に設定します。
- LAN、VPN、または固定された信頼できる CIDR への制限を優先します。
- 公開サービスと強度の低いパスワードを共有しないでください。
- ターミナルを利用できるプラットフォームでは、サービスプロセスが持つホスト上の権限も考慮します。
- 2 つ目の管理者用認証情報と、ローカルコンソールからの復旧手段を残します。
- アクティブなセッション、IP 変更の記録、ログイン試行制限を定期的に確認します。
管理画面を非表示にしたり、パスを変更したりしても、アクセス制御にはなりません。入口には引き続き認証、ネットワーク制限、正式な HTTPS が必要です。
アップストリームポートの制限
リバースプロキシがセキュリティ境界として機能するのは、クライアントがプロキシを迂回できない場合だけです。
- アップストリームサービスは、
127.0.0.1または fn-knock だけが到達できるコンテナネットワークでリッスンすることを優先します。 - LAN 内のアドレスでリッスンする必要がある場合は、ホストのファイアウォールでゲートウェイからのアクセスだけを許可します。
- Docker の
ports、ルーターのポート転送、クラウドのセキュリティグループ、FRP、CDN のオリジン設定を確認します。 - プロトコルマッピングで公開される TCP／UDP トラフィックは HTTP 認証や WAF を通らないため、個別に制限します。
外部ネットワークから公開アドレスをスキャンし、サービスの元のポートが誤って公開されていないことを確認してください。同じ LAN 内だけのテストでは、インターネット側の境界が正しいことを確認できません。
問題が発生した場合
- 最初にリクエストログで、リクエストがゲートウェイへ到達したかを確認します。
- Host、パス、アップストリームの転送先、ルート種別が想定どおりかを確認します。
- クライアント IP がプロキシのアドレスではなく、実際のグローバルアドレスかを確認します。
- セッション、許可リスト、ログイン試行制限、スキャナーのブラックリスト、共通ブラックリスト、WAF ログを確認します。
- イベントセンターと照合し、設定変更、ログイン、ブロック、更新が発生した時刻を確認します。
- 元のポートが公開されている疑いがある場合は、ルーター、クラウドのセキュリティグループ、コンテナポート、ホストのファイアウォールを 1 つずつ確認します。
サービスを復旧する際は、問題のある 1 レイヤーのポリシーだけを一時的に緩和し、元の値を記録してください。原因を確認した後はセキュリティ設定を元に戻します。認証、WAF、ブラックリストを同時に無効にして、原因を特定する手掛かりを失わないようにしてください。