説明
受信ルールで全アドレスから TCP 22 を許可すると、SSH サービスが不要な接続試行にさらされる場合があります。実際の接続可否は、対象 VM、経路、他のファイアウォールポリシー、SSH サービスの待ち受けにも左右されます。
SSH は管理用の経路です。公開インターネットに開放せず、承認された管理ネットワークや踏み台ホストを通る接続に制限してください。
想定される影響
- 外部のスキャンやパスワード推測の対象になるおそれがあります。
- 漏えいした認証情報や認証・サービスの脆弱性によって、サーバーが侵害されるおそれがあります。
対処方法
- TCP 22 に対する
0.0.0.0/0と不要な IPv6 全体の許可を削除し、承認された管理元と対象だけを許可してください。 - VPN、踏み台、IAP など必要な経路を先に用意してください。OS Login と適切な多要素認証を検討し、必要な接続が成功して不要な接続が遮断されることをテストしてください。
例
10.10.0.0/24 を実際の承認済み管理範囲に置き換え、その範囲からの接続経路を用意してください。両方の例では対象タグを省略しているため、必要な VM だけに適用されることも別途確認してください。
変更前
hcl
resource "google_compute_firewall" "ssh" {
name = "public-ssh"
network = google_compute_network.default.name
direction = "INGRESS"
source_ranges = ["0.0.0.0/0"]
allow {
protocol = "tcp"
ports = ["22"]
}
}
変更後
hcl
resource "google_compute_firewall" "ssh" {
name = "restricted-ssh"
network = google_compute_network.default.name
direction = "INGRESS"
source_ranges = ["10.10.0.0/24"]
allow {
protocol = "tcp"
ports = ["22"]
}
}
補足:
- 変更前: 全 IPv4 送信元から TCP 22 を許可します。
- 変更後: 送信元範囲を制限します。他のルールで不要なアクセスが再び許可されないか、実際の SSH 認証も確認してください。