mcpField
F
firewall-configuration

firewall-configuration

github.com/mikr13セキュリティ673 回インストール2 週間前に更新
リポジトリ

firewall-configuration について

UFW のファイアウォール変更を計画、適用、検証するスキルです。サーバーのネットワークアクセスを設定する運用担当者向けで、SSH の到達性を確認し、既存ルールの維持やロールバック、IPv4／IPv6 の検証に対応します。

主な機能

  1. 01リスナーとファイアウォールポリシーの確認
  2. 02送信元を限定した管理ルールの追加
  3. 03UFW 変更のプレビューと適用
  4. 04既存ルールの維持とロールバック状態の保存
  5. 05許可経路と遮断経路の検証

活用シーン

  1. 01SSH を承認済みの送信元範囲に限定
  2. 02必要なサービスポートの許可
  3. 03有効化前のファイアウォール変更の確認
  4. 04失敗したファイアウォール更新からの復旧

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mikr13/secure-server-setup-skills --skill firewall-configuration

インストール後、Claude Code で/firewall-configurationを入力して読み込まれたか確認します。

同梱ファイルreferences/ufw-rules.mdscripts/setup-firewall.sh

詳細

ファイアウォールの設定

必要なネットワーク経路のみを設定してください。デフォルト設定を変更する前に、既存の有効なポリシーとルールを把握する必要があります。SSH の許可ルールがあっても、新しい接続が確立できるとは限りません。

インベントリ

  • ss -ltnup、有効な SSH ポート、存在する場合は ssh.socket、ufw status verbose、ufw show added、プロバイダーのセキュリティグループ、およびコンテナーで公開されているポートを確認してください。
  • 実際の管理ポートと、承認済みの送信元 IPv4／IPv6 範囲を特定してください。ソケットアクティベーションまたはカスタムデーモンの起動方法を使用している場合は、sshd_config だけに頼らず、リスナーを確認してください。
  • /etc/default/ufw の IPv6 処理を確認してください。IPv4 のフィルタリングだけでは IPv6 の分離を確認できないため、関連する外部 IPv6 テストも実施してください。
  • コンソールからの復旧経路と現在のルール／ポリシーを記録してください。通常のトラブルシューティングとして UFW をリセットしないでください。

送信元を制限したルール、ルーティング、Docker、復旧については、references/ufw-rules.md を参照してください。

設定

承認されたセットアップで必要な場合は、まず UFW／iproute2 をインストールしてください。scripts/setup-firewall.sh の実行内容を確認します。

sudo bash scripts/setup-firewall.sh --ssh-source 203.0.113.10/32 --allow-port 443/tcp --dry-run

ソケット／カスタムリスナーを使用する場合は、実際のポートごとに --ssh-port を指定してください。承認済みの送信元（IPv6 を含む）ごとに --ssh-source を繰り返し指定します。--public-ssh は、すべての送信元からのアクセスを明示的に選択するオプションです。情報がないことを理由に、その選択を推測してはいけません。

ルールセットと有効化が承認されたら、次を実行します。

sudo bash scripts/setup-firewall.sh --ssh-source 203.0.113.10/32 --allow-port 443/tcp --apply --enable

このヘルパーは、ポート／送信元／リスナーを検証し、ルールを変更する前に、現在の SSH クライアントが指定された送信元 CIDR に含まれているか確認します。そのクライアントが許可範囲外である場合、または無効な UFW を有効化する際にクライアントのアドレスを取得できない場合は、テスト済みの帯域外復旧手段があることを --console-recovery-confirmed で明示的に確認しない限り、操作を拒否します。必要に応じて、権限昇格時に SSH_CONNECTION を引き継いでください。アクセス確認の失敗を回避するためだけに、このオプションを追加してはいけません。管理アクセスを先に追加し、ロールバック用に UFW の設定をスナップショットとして保存します。無効な UFW に対してのみ、着信拒否／送信許可のデフォルト設定を適用します。有効な UFW の既存のデフォルト設定とルールは維持されるため、不要な広範な許可ルールは別途確認してください。--enable を指定しない場合、無効なファイアウォールは無効のままです。公開サービス用のフラグは、意図的にすべての送信元を許可します。内部データベース／サービスには、送信元を制限した手動ルールを使用してください。

検証と復旧

  • 有効なルールとポリシーを確認し、実際の管理経路から再接続してください。該当する場合は、両方のアドレスファミリーで、許可／拒否対象のネットワークから、許可されるサービスとブロックされる経路をテストしてください。
  • コンテナーで公開されているポートとプロバイダーのルールを、それぞれ個別に確認してください。Docker の転送／NAT 経路は、ホストの入力フィルタリングを迂回することがあります。
  • コマンドが失敗した場合、ヘルパーは保存済みのファイルと以前の有効状態を復元します。その後の復旧には、プロバイダーのコンソールと出力されたバックアップディレクトリを使用してください。スナップショット作成後に行われたサービス／ルールの変更も考慮してください。
  • 設定、有効化、到達可能性の証拠は、それぞれ分けて報告してください。デフォルト拒否ポリシーを設定しても既存の許可ルールは削除されません。また、UFW サービスが実行中であることは、外部からの露出テストにはなりません。

コメント

Markdown 対応