IPv4 全体からの SSH を許可する GCP ファイアウォール

説明

TCP 22 を 0.0.0.0/0 から許可すると、ネットワーク経路を持つすべての IPv4 送信元が SSH 接続を試みられます。実際の到達可能性は外部 IP やその他の経路にも依存し、SSH 認証は引き続き必要です。source_ranges と source_tags を両方指定すると、いずれかに一致する通信が許可されるため、タグによって IPv4 全体の範囲が狭まることはありません。

想定される影響

• 到達可能な SSH サービスが、自動化されたログイン試行や既知の脆弱性への攻撃を受ける可能性があります。
• 漏えいした鍵や弱い認証が悪用されると、VM と接続先のデータ・サービスが侵害されるおそれがあります。

対処方法

1. IPv4 全体の許可を削除し、承認済みの管理元または IAP・VPN 経路と必要な対象 VM に限定してください。
2. 他のファイアウォールルールや優先度によって SSH が広く許可されていないか確認してください。OS Login などの認証制御は、ネットワーク制限の代わりにはなりません。
3. 鍵と IAM の権限を最小限にし、変更後に許可すべき管理接続と拒否すべき接続をそれぞれテストしてください。

例

実際のプロジェクトと認証情報を用意し、適用先の VPC を確認してください。ネットワークを省略するとデフォルトネットワークが使われます。

google.cloud 1.14.0 モジュールは source_tags と target_tags の同時指定を拒否します。以下のタグの組み合わせは Compute Engine API の許可範囲を示すもので、そのモジュール版で実行するには対応する送信元・対象の組み合わせに調整してください。

変更前

- name: ssh_unrestricted
  google.cloud.gcp_compute_firewall:
    name: test-object
    allowed:
      - ip_protocol: tcp
        ports:
          - "22"
    target_tags:
      - test-ssh-server
      - staging-ssh-server
    source_tags:
      - test-ssh-clients
    project: "{{ project_id }}"
    auth_kind: serviceaccount
    service_account_file: "/tmp/auth.pem"
    state: present
    source_ranges:
      - "0.0.0.0/0"

送信元タグがあっても、0.0.0.0/0 に該当する接続は許可されます。対象タグは、このルールを適用する VM を限定します。

変更後

- name: ssh_restricted
  google.cloud.gcp_compute_firewall:
    name: test-object
    allowed:
      - ip_protocol: tcp
        ports:
          - "22"
    target_tags:
      - test-ssh-server
      - staging-ssh-server
    project: "{{ project_id }}"
    auth_kind: serviceaccount
    service_account_file: /tmp/auth.pem
    state: present
    source_ranges:
      - "203.0.113.10/32"

送信元を一つの IPv4 アドレスに限定しています。203.0.113.10/32 は文書用アドレスなので、承認済みの管理経路で実際に使われる送信元アドレスに置き換えてください。

参考資料

• CWE-732
• Ansible のファイアウォール設定
• ファイアウォールの送信元と対象
• OS Login の設定