AWSを低いレイヤーから調べてみようのコーナー！
今日はSNSとSQSの通信についてパケットキャプチャしてみました！
SNS
IAM roles for EC2でPowerUsersに設定したEC2から、AWS command line toolsでaws sns publishしたものをtcpdumpでキャプチャしてWiresharkに食わせました。
まず、SNSにPublishするのは大きく以下のような流れでした。
まずEC2からIAMサーバに「GET /latest/meta-data/iam/security-credentials/ HTTP/1.1\r\n」リクエストが行われています。
ここでIAMサーバからEC2にリターンされたのは、自身に設定されたIAM rolesの名前でした。今回は「powerec2」という名前にしてありましたので、その名前が返却されています。
次にEC2からIAMサーバに「GET /latest/meta-data/iam/security-credentials/powerec2 HTTP/1.1\r\n」リクエストが行われています。自分の設定されたIAM rolesの名前が権限情報のURIになっているようですね。
結果、IAMサーバからEC2に権限情報がリターンされています。
ここでちょっと気になるのが、期限(Expiration参照、6時間くらい？)付きとは言えACCESSKEYとSECRETACCESSKEYが平文で送られてるってところなんですが...AWS::EC2インスタンスではPromiscuous modeが利用不可になっているとはいえ、ちょっと気持ち悪いですね。
(2)SNSサーバのホスト名からIPアドレス(Aレコード、AAAAレコード)をDNSサーバに問い合わせする。
普通のDNSのQueryなので面白くないから割愛。
(3)SNSサーバにPublishする。
PublishはHTTPSで行われていました。暗号化プロトコルはTLS 1.0です。
つまりSNS Topic Publish自体は、通信経路の秘匿性は担保されているということですね。
そうするとSNSからSQSにPublishした後、EC2がSQSからqueueを取り出すときも暗号化されていれば、SNSとSQSを使ったEC2間のデータのやり取りにおいては通信経路の秘匿性が担保されている、と言えそうです。
SQS
SQSについてもSNSと同様に、IAM roles for EC2でPowerUsersに設定したEC2から、AWS command line toolsでaws sqs receive-messageしたものをtcpdumpでキャプチャしてWiresharkに食わせました。
SQSからreceive-messageするのも、SNSとほぼ同様の流れでした。
今日はSNSとSQSの通信についてパケットキャプチャしてみました！
SNS
IAM roles for EC2でPowerUsersに設定したEC2から、AWS command line toolsでaws sns publishしたものをtcpdumpでキャプチャしてWiresharkに食わせました。
まず、SNSにPublishするのは大きく以下のような流れでした。
- IAM管理サーバからroleについての情報を取得する。
- SNSサーバのホスト名からIPアドレス(Aレコード、AAAAレコード)をDNSサーバに問い合わせする。
- SNSサーバにPublishする。
(1)IAM管理サーバからroleについての情報を取得する。
まずEC2からIAMサーバに「GET /latest/meta-data/iam/security-credentials/ HTTP/1.1\r\n」リクエストが行われています。
ここでIAMサーバからEC2にリターンされたのは、自身に設定されたIAM rolesの名前でした。今回は「powerec2」という名前にしてありましたので、その名前が返却されています。
次にEC2からIAMサーバに「GET /latest/meta-data/iam/security-credentials/powerec2 HTTP/1.1\r\n」リクエストが行われています。自分の設定されたIAM rolesの名前が権限情報のURIになっているようですね。
結果、IAMサーバからEC2に権限情報がリターンされています。
ここでちょっと気になるのが、期限(Expiration参照、6時間くらい？)付きとは言えACCESSKEYとSECRETACCESSKEYが平文で送られてるってところなんですが...AWS::EC2インスタンスではPromiscuous modeが利用不可になっているとはいえ、ちょっと気持ち悪いですね。
(2)SNSサーバのホスト名からIPアドレス(Aレコード、AAAAレコード)をDNSサーバに問い合わせする。
普通のDNSのQueryなので面白くないから割愛。
(3)SNSサーバにPublishする。
PublishはHTTPSで行われていました。暗号化プロトコルはTLS 1.0です。
そうするとSNSからSQSにPublishした後、EC2がSQSからqueueを取り出すときも暗号化されていれば、SNSとSQSを使ったEC2間のデータのやり取りにおいては通信経路の秘匿性が担保されている、と言えそうです。
SQS
SQSについてもSNSと同様に、IAM roles for EC2でPowerUsersに設定したEC2から、AWS command line toolsでaws sqs receive-messageしたものをtcpdumpでキャプチャしてWiresharkに食わせました。
SQSからreceive-messageするのも、SNSとほぼ同様の流れでした。
- IAM管理サーバからroleについての情報を取得する。
- SQSサーバのホスト名からIPアドレス(Aレコード、AAAAレコード)をDNSサーバに問い合わせする。
- SQSサーバからmessageを取得する。
1、2についてはSNSと同様なので割愛。3についてですが、やはりこちらもHTTPS通信となっていました。ということで、EC2→SNS→SQS→EC2のデータのやり取りについては、多少センシティブな情報を流すことも出来そうです。
感想
AWSで色々なサービスを組み合わせて遊ぶのはもちろん楽しいのですが、やはり根っこの部分が見えづらくいまいちしっくり来ない部分があります。その辺が今回のような調査で色々見えてくると、もっとAWSの理解度が高まるかなぁと思うので、今後も色々試してみたいと思います！
 | Amazon Web Services クラウドデザインパターン実装ガイド 大澤 文孝,玉川 憲,片山 暁雄,鈴木 宏康 日経BP社 売り上げランキング : 17216 Amazonで詳しく見る by AZlink |