pingを飛ばして試すネットワークACLとセキュリティグループ
先日、AWS認定Security Specialty=SCSに合格しました🎉
SCSの勉強中にセキュリティグループとネットワークACLの使い方で混乱することが多かったです。その中で、ネットワークACLとセキュリティグループを実際に設定したインスタンスに通信を送ってみることで理解が深まりました。
その結果をまとめてみます。
ネットワークACLとセキュリティグループ
ネットワークACL(=NACL)とセキュリティグループはどちらもネットワークトラフィックを制御するために使用されます。
トラフィックの制限対象
- NACLはサブネットレベル
トラフィックがサブネットに出入りする際に評価される。NACLの制限は関連付けられたサブネット内のリソース全てに適用されるとも言える。 - セキュリティグループはリソース単位
トラフィックがリソースに到達する際またはリソースから離れる際に評価される。
また一つのリソースに複数のセキュリティグループを割り当てることもできる。
設定できるルール
- NACLは許可・拒否のルールを設定できる
- セキュリティグループは許可のみ
ステートフル?ステートレス?
- NACLはステートレス
インバウンドとアウトバウンドは独立してそれぞれで設定する必要がある - セキュリティグループはステートフル
インバウンドで評価されたルールはその戻り通信(アウトバウンド)においても保持される
NACLとセキュリティグループの設定
NACL
インバウンドルール、アウトバウンドルールについてそれぞれ独立して以下を設定します。
- ルール番号:インバウンドルール内またはアウトバウンドルール内で番号が低い順に評価される
- トラフィックのタイプ:SSHやHTTPなど
- プロトコル
- ポート範囲
- [インバウンド]送信元IPアドレス範囲:CIDR表記で指定
- [アウトバウンド]送信先IPアドレス範囲:CIDR表記で指定
- 許可/拒否
セキュリティグループ
インバウンドルール、アウトバウンドルールをそれぞれ以下のように設定します。
- トラフィックのタイプ:SSHやHTTPなど
- プロトコル
- ポート範囲
- [インバウンド]ソース:インスタンスに到達可能なトラフィックを単一のIPアドレスまたはCIDR表記で範囲を指定
- [アウトバウンド]送信先:インスタンスから送信できる場所を単一のIPアドレスまたはCIDR表記で範囲を指定
やってみる
パブリックサブネットにEC2を立て、パブリックIPアドレスに対してpingで通信を確認します。
意味がなさそうなパターンもやってみます。
pingとは
ネットワークの疎通確認に使われるコマンド。
通信ができるとバイト数、時間、TTLが応答として表示され、通信できなかった場合はタイムアウトとされます。
ICMPプロトコルを使用しているため、NACLおよびセキュリティグループのルールで通信許可が必要になります。
ここでは以下のルールをNACLおよびセキュリティグループ(=SG)のインバウンド・アウトバウンドにそれぞれ設定してみます。
- IPバージョン:
IPv4
- タイプ:
すべてのICMP-IPv4
- プロトコル:
ICMP
- ポート範囲:
全て
- ソース・送信先:
0.0.0.0/0
NACLは両方設定・SGはインバウンドのみ設定
SGのアウトバウンドルールを設定しないパターン。
【結果】
通信できました。
セキュリティグループはステートフルなので、インバウンドを許可することで戻り通信も許可されます。
NACLは両方設定・SGはアウトバウンドのみ設定
SGのインバウンドルールを設定しないパターン。
【結果】
通信できません。
pingを飛ばすには行き方向の許可が必要です。戻り通信を許可していても意味がありません。
NACLはインバウンドのみ設定・SGは両方設定
NACLのアウトバウンドルールを設定しないパターンです。(SGのアウトバウンドルールはなくてよい)
【結果】
通信できません。
NACLはステートレスなので、インバウンドのみ許可していてもアウトバウンドが許可されていないと通信できません。
NACLは両方設定・SGは設定しない
空のセキュリティグループを関連付けた状態です。
このようにルールがないSGをEC2に関連付けています。
【結果】
通信できません。
NACLは設定しない・SGは設定
NACLはルール番号「*」というルール番号が最も高い(優先度が最も低い)ルールで全てのトラフィックを拒否するルールがあり、以下のように削除ができません。
NACLを設定しない=全てのトラフィックを拒否するということになります。
【結果】
通信できません。
SGで許可していても、NACLで全ての通信を拒否しているため期待通りの結果です。
まとめ
- NACLはステートレスなのでIN/OUT両方の許可が必要
- SGはステートフルなのでINを許可すればOUT(戻り通信)の許可は不要
- 通信の許可にはNACLとSGの両方でルール設定が必要(どちらかの許可ルールが全くない場合は通信できない)
NACLとSGのIN/OUTの設定パターンを複数試すことで通信の許可・拒否の挙動を理解することができました。
セキュリティグループのアウトバウンドルールはいつ設定する?
サーバー側から外に向かって通信したいというケース(EC2インスタンスからCloudWatchにログを送信する等)でアウトバウンドルールの許可が必要です。
またインバウンドとアウトバウンドのそれぞれの通信が独立している場合にもIN/OUTどちらも許可する必要があります。
必ずしも「インバウンドルールで許可しているからアウトバウンドルールの設定は必要ない」というわけではないので、ユースケースに応じてそれぞれの設定を考慮することになります。
NACLとSGの使い道(使い分け)
セキュリティグループのみ使用してインスタンスを保護することができます。またセキュリティグループはリソース単位で関連づけるため、サブネット内での細かいトラフィック制御が可能です。
セキュリティグループで細かな制御をした上で、NACLを追加の防御レイヤーとして大まかに(サブネット単位で)設定するといった使い方が考えられます。(もちろん要件によってどちらをどのように設定するかは変わってきます。)
参考
Discussion