VPCのおさらい/最初にまとめ
- 仕様的には以下の記述がすべてであり、今回の検証結果も以下の記述の内容を確認する内容となっている。
- 送信元/送信先チェックを無効化すればインスタンスのIPアドレス以外の送信元/宛先のパケットも送受信できる
Network Address Spoofing
Network MAC addresses are dynamically assigned to Amazon Elastic Compute Cloud (Amazon EC2) instances by the AWS network infrastructure. IP addresses are either dynamically assigned by the AWS network infrastructure or statically assigned by an EC2 administrator through authenticated API requests. The AWS network only allows EC2 instances to send traffic from IP and MAC addresses specifically assigned to them, or the traffic will be dropped.
By default, AWS also protects EC2 instances by treating an instance as a standalone network host, not a router or network gateway, and drops any traffic not specifically addressed to the instance. Customers who need EC2 network appliances to run network address translation, routing, or firewall services can change this default behavior by disabling the Source/Destination Check attribute and configuring VPC route tables to send outbound traffic through the network appliance.
VPC Security Capabilities – AWS Answers https://aws.amazon.com/jp/answers/networking/vpc-security-capabilities/?nc1=h_ls
検証構成、検証内容
- VPC内にEC2インスタンス×2
- ICMP疎通確認
- 送信元のIPアドレスを偽装できるか確認（hpingを利用）
- 送信先のIPアドレスを偽装（？）できるか確認（ARPキャッシュを変数し、正しいMACアドレスに対して誤ったIPアドレスを指定し、パケットが宛先まで届くか確認する）
コマンド例
送信元IP偽装
$ sudo hping -C 8 -a [偽装した送信元IPアドレス] [宛先IPアドレス]
送信先IP偽装（というか宛先ホストのIPアドレスではないIPアドレスに送信。MACアドレスは宛先ホスト）
要はルータ介して別のホストに送信するのと同じだけど、今回は宛先IPアドレスをVPC内のアドレスにしてみる。
$ sudo arp -s [宛先IPアドレス（実際には無いアドレス）] [MACアドレス（）] -i eth0
結果
- デフォルトの状態ではどちらの場合も宛先のホストには届かない
- クライアント側で送信元先チェックを無効化すれば、送信元IPを偽装したパケットは宛先ホストに届く（ただし、応答時に宛先アドレスの解決ができないため、応答には失敗する）
- サーバ側で送信元先チェックを無効化すれば、自身の宛先ではないパケットも受信できる。自身宛ではないので、自分からは応答はしない
以下結果表。チェックの列は「○」が無効化。接続性が「→」は送信には成功（応答は失敗）。
関連
VPC内におけるアドレス解決（ARP）を確認してみた（キャプチャ付き） - Qiita https://qiita.com/kure/items/d6e5a71689784dae029f