こんにちは。
皆さんの多くはWebサーバを運用した経験がお有りですよね。
多くのサーバでは、リモートから接続するときにはSSHでログインします。
僕らがダイスキなAmazon Web Services、AWSでも、作成したサーバにSSHで接続可能です。
SSHでサーバを操作することで世の中に便利なソフトウェアサービスを提供することができます。
が、しかし、その便利なSSHを使って、悪い人がサーバにアクセスを仕掛けてきたらどうでしょう？もし万が一乗っ取られてしまったら？あなたの便利なソフトウェアやサービスが書き換えられ、世の中の害悪になってしまうかもしれません。
不正アクセスを検知しましょう。AWSの機能を使って。
僕らがダイスキ（2回目）AWSの機能を使って、SSHへの不正アクセスがあった時にそれを検知して、通知を受け取ることができます。
本投稿では、その手順をご紹介します。
なお、この投稿を実施することですべての不正アクセスが検知できる/防止できるわけではもちろんありませんのでご了承ください。
本投稿で登場するAWSのサービス
- EC2 - この上でWebサーバを運用することを仮定します。EC2でなくても可ですが、本投稿とはCloudWatch Logsのエージェントインストール方式が替わります。
- CloudWatch Logs - ログ収集＋保持サービス
- IAM - EC2やAWSアカウントの権限管理。本投稿ではEC2にIAMロールを割り当てます。
- SNS 僕らがダイスキAWSの通知機能。本投稿ではメール通知するように設定したSNSに連携しています。本投稿では詳しくは説明しませんが、SNSを使えばHTTP発呼や、メールやスマフォに通知することができます。
不正アクセス検知手順
さて、実際の手順をご説明します。
概要
- CloudWatch Logs投稿用IAMロールを作成
- ロールを持ったEC2立てる。
- 不正アクセス時のログ確認
- EC2上にCloudWatch Logsをインストール・設定する。
- SNSを作成する。（本投稿ではメールが飛ぶように。）
- AWSコンソールからCloudWatch Logsを設定し、通知が飛ぶようにする。
手順
1. CloudWatch Logs投稿用IAMロールを作成
公式の手順はこちらで、こちらにそって実行していきます。
AWSコンソールにログインし、IAMロールを作成します。
コンソールに入り・・・
Identity & Access Management（IAM）を選択し、
ロールを選択し、
「新しいロールを作成」を押し、
ロールタイプを適当に選択します。（ロールタイプはあとから削除するので適当につけます。本投稿ではAmazon EC2→ CloudWatchLogsFullAccessを選択しました。）
次の画面でロールの作成ボタンを押します。
作成したロールを選択し、インラインポリシーを押して、「ここをクリックしてください。」を押します。
カスタムポリシーの選択を押し、こちらのポリシーを入力します。
ポリシーの適用を押します。
CloudWatchLogsFullAccessの方は「ポリシーのデタッチ」をしておきます。
ロールポリシーを直接作りたかったのですが、やり方がワカリマセンでした。できた方はコメントください。
これでロールの作成は完了です。
引き続きまして、このロールをもつEC2を作成します。
2. ロールを持ったEC2立てる。
いろいろすっ飛ばしますが、IAMロールに先ほど作ったロールを設定しておきます。
引き続きまして、取得するログの確認です。
3. 不正アクセス時のログ確認
引き続きまして、今回引っ掛けたいログを確認しておきます。
作成したEC2にログインして、
[ec2-user@ip-10-0-0-169 ~]$ sudo tail -f /var/log/secure
します。そして、他のサーバからSSHでアクセスします。
うまくいくと
Nov 26 08:23:07 ip-10-0-0-169 sshd[14178]: Accepted publickey for ec2-user from 10.0.0.167 port 52047 ssh2: RSA XXXXXXXXXXXXXXXXXXXXX
Nov 26 08:23:07 ip-10-0-0-169 sshd[14178]: pam_unix(sshd:session): session opened for user ec2-user by (uid=0)
のようなログが、
変な鍵やカギ無しでアクセスすると
Nov 25 08:21:45 ip-10-0-0-169 sshd[24078]: Connection closed by 10.0.0.167 [preauth]
のようなログが出ることがわかりました。
今回は[preauth]という文字を引っ掛けてエラーと判断します。
今回は説明の簡易化のために、未設定で出力されるログから引っ掛けるようにしていますが、本番設定するときは適切な設定及びログを設計してください。
4. EC2上にCloudWatch Logsをインストール・設定する。
EC2上で、以下のコマンドでインストールを行います。
[ec2-user@ip-10-0-0-169 ~]$ sudo yum update -y
[ec2-user@ip-10-0-0-169 ~]$ sudo yum install -y awslogs
これでインストールは完了、引き続き設定を行います。
sudo vi /etc/awslogs/awscli.conf
[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-1
regionはログを入れたいリージョンの場所を入れます。上記はみんな大好き東京です。
引き続きどのログを CloudWatch Logs で収集するかを設定します。
sudo vi /etc/awslogs/awslogs.conf
[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/messages
デフォルトでは[/var/log/messages]を収集しています。ここに[/var/log/secure]を設定します。以下を追記。
[/var/log/secure]
datetime_format = %b %d %H:%M:%S
file = /var/log/secure
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/secure
logsエージェントを起動、サービス化します。
sudo service awslogs start
sudo chkconfig awslogs on
これで/var/log/secureが収集されるようになりました。
5. SNSを作成する。（本投稿ではメールが飛ぶように。）
SNSを作成して、メールが来るようにします。
AWSコンソールのCloudWatchを開きます。
SNSを選択して、
Create Topicを選択して、
適当な名前をつけます。この名前をあとからCloudWatch Logsのアラートにひも付けます。
Create topicを押して、
Create Subscriptionを押します。
Emailを選択して、Endpointに送信したいメールアドレスを入力し、Create Subscriptionを押します。
Endpointに設定したメールアドレスに送信していいかを確認するメールが届いているので、メール中のConfirm subscriptionリンクを押して完成です。
これでSNSに通知があるとメールが送信されるようになります。
6. AWSコンソールからCloudWatch Logsを設定し、通知が飛ぶようにする。
AWSコンソールのCloudWatchを開きます。
ログを押します。
/var/log/secureの「0フィルタ」リンクを押します。
メトリックスフィルタの追加を押します。
フィルタパターンに引っ掛けたい文字を""でくくった、"[preauth]"を入力して、メトリックスの割当を押します。
メトリックス名を入れて、フィルタの作成ボタンを押します。
引き続いて、アラームの作成リンクを押します。
適切な入力します。キモは、「間隔」「統計」と「次の時」です。「間隔（１分）」の間に「統計（合計）」「次の時（１回以上）」を「次の時（１回連続したら）」のようなしきい値を設定し、それが発生したらアクションを起こします。アクションにはSNSを設定しておくと良いです。myTopicは予め設定しておいたSNSトピックです。私にメールが来るようになっています。
これで変なSSHアクセスが来たら私にメールが来るようになりました。
実験
カギ無しでsshしてみます。
ssh root@localhost
しばらくすると、私にメールが飛んできました。
Alarm Details:
- Name: 変なSSHアクセスがありましたよ。
- Description:
- State Change: INSUFFICIENT_DATA -> ALARM
- Reason for State Change: Threshold Crossed: 1 datapoint (6.0) was greater than or equal to the threshold (1.0).
- Timestamp: Monday 30 November, 2015 02:04:10 UTC
- AWS Account: XXXXXXXXXXXX
いいですねいいですね。(XXXXXXXXは伏せ字)
これでサーバがやばそうな雰囲気だったら察知することができます。
応用編
本投稿で説明した手順を実行すると、ログ出力を拾って、サーバに集め、特定のログが特定の状況で発生していたら通知を受けることができます。したがって、SSHの不正アクセスだけではなく、Webサーバで500エラーがあった時や、sudoイベントを拾って変なsudoがされた時も検知することができます。応用してみてください。
ログ監視も簡単！そう、僕らがダイスキAWSならね！(何回目？)