標準のAmazon Linux AMIを前提に進めていきます。
AWS EC2はデフォルトでrootログイン禁止、オプトイン方式のインバウンドセキュリティポリシー、公開鍵認証のキーペア生成など、適当に使っていてもある程度セキュアになりますが、少しの手間でより堅牢なサーバーにできます。是非取り組んで欲しいです。
とりあえずアップデート
AmazonLinuxの場合大抵最新のパッケージが入っていますが、念のために更新しておきます。
|
1 |
sudo yum update -y |
以下の指定にすることでセキュリティパッケージの更新のみを適用できるため、すべてのパッケージを更新したくない場合、最低限こちらだけでも実行しましょう。
|
1 |
sudo yum update -y --security |
タイムゾーンの変更
EC2は起動したリージョンにかかわらずUTCの設定になっています。最近は世界を目指すプロダクトではアプリケーションやDBクロックを日本時間に変えずUTCのまま使用し、表示時にアプリケーションが変換するなど、UTCスタンダードなモデルもよく聞きますね。とはいえ日本に住む以上日本時間で統一したくなるのも事実。
|
1 2 |
sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime sudo vim /etc/sysconfig/clock |
|
1 2 3 |
- ZONE="UTC" + ZONE="Asia/Tokyo" UTC=true |
設定が終わったら再起動して全てのプロセスに反映させます。
再起動後はdateコマンドで日本時間になっているのを確認します。
|
1 2 |
date # 2015年 11月 18日 水曜日 01:31:33 JST |
rootパスワードの設定
適切にインスタンスを起動した場合、接続に必要な鍵が適切に管理されていれば通常安心ですが、万が一の漏洩に備えてrootにパスワードを設定しておきましょう。
|
1 2 |
sudo passwd # 新rootパスワードを入力 |
管理用ユーザーの変更
デフォルトではec2-userというユーザーが管理用に作られていますが、セキュリティを高めるために別の名前のユーザーを使うことをお勧めします。その際、AmazonLinuxでは他Linuxによくあるwheelグループなどの管理グループ全体にsudoを付与しているわけではなくユーザー単位に設定されているため、新規で追加したユーザーにも個別にsudo権限を付与するようにしましょう。
まずは新しいユーザーを追加して、管理（sudo）権限を付与します。
|
1 2 3 4 5 6 7 8 9 10 |
# 新規ユーザー追加 sudo useradd newuser # 鍵などをec2-userからコピー＆権限設定 sudo cp -arp /home/ec2-user/.ssh /home/newuser/ sudo chown -R newuser /home/newuser/.ssh # 新しいユーザーのパスワードを設定 sudo passwd newuser # sudoersファイルを編集 sudo visudo -f /etc/sudoers.d/cloud-init |
cloud-initファイルを次のように変更します。
|
1 2 3 4 5 6 7 |
+newuser ALL = (ALL) ALL -ec2-user ALL = NOPASSWD: ALL +#ec2-user ALL = NOPASSWD: ALL # User rules for ec2-user -ec2-user ALL=(ALL) NOPASSWD:ALL +#ec2-user ALL=(ALL) NOPASSWD:ALL |
ec2-userのsudo権限は /etc/sudoers.d/cloud-init に書かれており、/etc/sudoersからロードされています。引数なしのvisudoでは編集できません。また、sudoersファイルを直接viなどで編集するのは危険なのでやめましょう。ここではec2-userの権限を剥奪し、またsudo実行時にパスワードを求めるように（NOPASSWD非設定）しました。
すべて完了したら、一度ログアウトして外部からnewuserでログインしてみましょう。鍵もコピーされていますので、ssh接続時はユーザー名だけを変更すればOKです。正しく接続できて、sudoがパスワード入力後に実行できれば完了です。
最後にec2-userを削除して終わりです。ec2-userでログインできないことを確認しましょう。
|
1 |
sudo userdel -r ec2-user |
ポート番号の変更
定番のセキュリティ対策ですね。SSHのポート番号をデフォルトの22番から別のものに変更します。簡単で単純ですが、効果は高いです。
ここでは仮に22922に変更します。また、待ち受けポートは1つという縛りはないため、下記例のように変更前のポート22でも待ち受けるようにしたまま進めると万が一の特に困らないでしょう。
|
1 |
sudo vim /etc/ssh/sshd_config |
|
1 2 3 |
-#Port 22 +Port 22 # 安全のために22でも待ち受け +Port 22922 |
終わったらreloadして設定を反映させます。また、iptablesが稼働中であれば不正なルーティングによって弾かれる可能性があるので停止されているのを確認してください。
|
1 2 |
sudo service sshd reload sudo service iptables stop |
SSHのポートを変更しますので、AWSのEC2に紐付いているセキュリティポリシーも変更する必要があります。新しく設定したポート番号のTCPを、自分のIPアドレスから通すように設定を変更しましょう。
これで新しいポートを用いて接続できるようになりました。一度ログアウトして、新しいポートへのSSH接続が成功すれば完了です。sshd_configを開いて Port 22 の記述を削除したあとでreloadしましょう。AWSのセキュリティポリシーからもTCP:22のルールを削除して完了です。
万が一新しいポートで接続できない場合は、落ち着いて22ポートで接続して、設定を再確認してください。ポートが正しく待ち受けられているかチェックするにはnetstatコマンドが有効です。
|
1 |
sudo netstat -anp | grep sshd |
SSHをもっとセキュアに
- iptablesでアクセスできる回数を制限
- 認証試行回数の設定
- アクセス試行ログの通知
もろもろ考えましたが次の観点からこれらを講じる意味はないと思っているので割愛します。
- 鍵認証が強制になっていること（デフォルト）
- rootログインができないこと（デフォルト）
- ユーザー名を変更したこと
- SSHポートを変更したこと
- EC2のセキュリティポリシーにより、SSHポートは信頼されたIPにしか公開されていないこと
これだけの対策を講じていれば、上述の更なる対策はあまり意味がありません。
鍵の管理だったり、権限を持つ内部からの不正アクセスリスクの方が高いはずなので、その辺の対策（運用体制などの整備）に時間を割く方が良いでしょう。
そのほか
nginxやその他サーバー類の個別なセキュリティ対策についてはまた別に書こうと思います。
特にエンタープライズでのウェブサイト改竄や情報流出などの危機管理が取り沙汰されている昨今、エンジニアである以上最前線で食い止めていきたいですね。
- 2015-11-18 公開
- 2015-11-25 加筆