IPv6対応のSSHサーバをCloudFormationで作成してみた
はじめに
AWSチームのすずきです。
先日紹介させて頂いたIPv6対応VPCに続き、 VPC内部への踏台(Bastion)となる、IPv6に対応したSSHサーバを設置するテンプレートについて紹介させて頂きます。
構成図
- Internet Gatewayを利用可能なサブネットに、SSH接続用のEC2インスタンスを設置します。
CloudFormation テンプレート
ipv6-validation-basion-ec2.yaml
Parameters
- IPv6対応のVPCの設置に利用したCloudFormationのスタック名を指定します。
VpcStack: Description: VPC Cloudformation Stack Type: String Default: ipv6-test
IAM
- SSH接続用のEC2で利用するIAMロールを設定しています。
- ログ退避を想定し、Kinesis、CloudwatchLogsなどの権限を設定しています。
EC2
- インスタンスファミリーはIPv6に対応した「t2」を利用しました。
- IPv6アドレスの割当を有効としたセグメント「t1.micro」等、旧世代のインスタンスの起動は失敗します。
- パブリックIPで提供されるAWSのAPIの利用を可能とするため、EC2インスタンスにはパブリックIPを付与しています。
- 事前に別テンプレートで作成済みのVPC情報(サブネット、セキュリティグループ)は、「Fn::ImportValue:」を利用して指定しました。
NetworkInterfaces: - AssociatePublicIpAddress: 'true' DeviceIndex: '0' GroupSet: - Fn::ImportValue: !Sub "${VpcStack}-BastionSecurityGroup" SubnetId: Fn::ImportValue: !Sub "${VpcStack}-FrontendSubnet1"
利用例
- 以下のMAC OSX (High Sierra)環境をクライアントとし、IPv6を利用したSSH接続を試みました。
$ sw_vers ProductName: Mac OS X ProductVersion: 10.13 $ ssh -V OpenSSH_7.5p1, LibreSSL 2.5.4 BuildVersion: 17A405
直接接続
- 起動したEC2のIPv6アドレスを確認します。
- IPv6のアドレス指定で、SSH接続できました。
$ ssh -i xxxxxx.pem -l ec2-user 2406:da14:***:****:****:****:***:557e Last login: Tue Oct 10 12:31:15 2017 from 240b:11:****:****:****:****:****:**** __| __|_ ) _| ( / Amazon Linux AMI ___|\___|___| https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/
踏台接続
- 踏台となるSSHサーバにIPv6で接続し、VPC内の別EC2への接続も可能です。
-
事前にクライアントのSSH設定ファイル「~/.ssh/config」を設定します
Host Bastion HostName 2406:da14:***:****:****:****:***:557e User ec2-user IdentityFile ~/xxxxxx.pem Host Application HostName 192.168.4.*** User ec2-user Port 22 ProxyCommand ssh -W %h:%p Bastion IdentityFile ~/xxxxxx.pem
- IPv6接続のSSHサーバを踏台とし、VPC内のEC2インスタンスにリモート接続できました。
$ ssh Application Last login: Tue Oct 10 13:19:57 2017 from 192.168.4.*** __| __|_ ) _| ( / Amazon Linux AMI ___|\___|___| https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/
ログ確認
2台のEC2を起動し、SSH(TCP22)のセキュリティグループ設定を異なる設定で用意しました。
- IPv6用: 「::/0」全IPv6アドレスに開放。
- IPv4用: 「0.0.0.0/0」全IPv4アドレスに開放しました。
一日経過した後、SSHの接続ログ(/var/log/secure)を確認、正規接続以外のログ記録を確認しました。
IPv6
- 第三者によるSSH接続が試みられた記録、確認出来ませんでした。
[ec2-user@ip-192-168-0-*** ~]$ sudo cat /var/log/secure | grep -v ec2-user Oct 9 13:12:52 ip-192-168-0-*** sshd[2337]: Server listening on 0.0.0.0 port 22. Oct 9 13:12:52 ip-192-168-0-*** sshd[2337]: Server listening on :: port 22. Oct 10 12:14:20 ip-192-168-0-*** su: pam_unix(su-l:session): session closed for user root Oct 10 12:31:14 ip-192-168-0-*** sshd[12808]: Received disconnect from 240b:11:****:****:****:****:****:**** port 59585:11: disconnected by user Oct 10 12:31:14 ip-192-168-0-*** sshd[12808]: Disconnected from 240b:11:****:****:****:****:****:**** port 59585
IPv4
- 1日分で約9000件が確認されました。
[ec2-user@ip-10-37-31-*** log]$ sudo cat /var/log/secure | grep -v ec2-user| grep 'Oct 9' | tail -n 10 Oct 9 23:34:26 ip-10-37-31-*** sshd[14892]: Received disconnect from 121.**.***.125: 11: [preauth] Oct 9 23:34:48 ip-10-37-31-*** sshd[14898]: Invalid user pi from 78.***.***.74 Oct 9 23:34:48 ip-10-37-31-*** sshd[14900]: Invalid user pi from 78.***.***.74 Oct 9 23:34:48 ip-10-37-31-*** sshd[14900]: input_userauth_request: invalid user pi [preauth] Oct 9 23:34:48 ip-10-37-31-*** sshd[14898]: input_userauth_request: invalid user pi [preauth] Oct 9 23:34:48 ip-10-37-31-*** sshd[14898]: Connection closed by 78.***.***.74 [preauth] Oct 9 23:34:48 ip-10-37-31-*** sshd[14900]: Connection closed by 78.***.***.74 [preauth] Oct 9 23:35:29 ip-10-37-31-*** sshd[14931]: reverse mapping checking getaddrinfo for 79.***.***113.adsl-pool.jx.chinaunicom.com [113.***.***.79] failed - POSSIBLE BREAK-IN ATTEMPT! Oct 9 23:35:30 ip-10-37-31-*** sshd[14931]: Received disconnect from 113.***.***.79: 11: [preauth] Oct 9 23:46:41 ip-10-37-31-*** sshd[15298]: Received disconnect from 59.***.***.67: 11: [preauth]
[ec2-user@ip-10-37-31-*** log]$ sudo cat /var/log/secure | grep -v ec2-user | grep 'Oct 9' | wc -l 9085
まとめ
AmazonLinux環境へのSSH接続、IPv4、IPv6ともと大きな違いなく利用できました。
セキュリティグループにより接続元のIPアドレスを制限できない場合、 AWSの公開IPアドレスを対象とした総当り攻撃に晒される事になります。
SSHの場合総当り攻撃は、充分な強度な鍵とパッチなどの適切な管理により直ちに脅威とはなりませんが、 広大なIP範囲をもつIPv6であればそのリスクの軽減が期待できます。
またIPv4網の混雑により、AWSへのインターネット接続の帯域が不足する場合にも、 IPv6網の迂回が効果を発揮する事もあります。
AWSのVPCは、追加費用なくIPv6を有効化する事ができます。 先日紹介させて頂いたVPCテンプレートとあわせ、AWSのIPv6環境の検証の機会があればお試しください。