ハニーポットサーバ（EC2）にログインできなくなったので復旧までの道のりを書く

先日SFTPクライアントでいつもどおり、Glastopfのログを取得しようとしたところ、接続できない事象が発生しました。

SSHで接続しようとしても、

こんな感じで、

Operation timed out

となってしまいます。

僕の場合、AWS上にハニーポットを構築しているので、早速調査してみました。

とりあえずの再起動

とりあえず、何かハングしているのではないかと思い、AWSコンソール上から対象のEC2を再起動してみました。

ダメでした。 再起動しても接続できない状況は変わりませんでした。

EBSをデタッチ

こりゃダメだと思い、対象のEC2を停止させてEBSをデタッチしました。

調査用のEC2インスタンスを作成

その次に調査用のEC2をAWSコンソールから作成しました。

ハニーポットで使用していたOSはUbuntuだったので、それに合わせてEC2を作成しました。

使用していたEBSを調査用EC2にアタッチ

調査用のEC2が作成できたら、先ほどデタッチしたEBSをアタッチします。

その後、調査用EC2を起動します。

調査用EC2にログインして、使用していたEBSボリュームをマウント

このままではアタッチしたEBSボリュームがマウントされていない状態なので、ログインしてマウントさせていきます。

まずは、マウント先のディレクトリを作成します。

sudo mkdir /mnt/ebs

その後は、mountコマンドを使用して対象デバイスを上記で作成したディレクトリにマウントさせます。

sudo mount /dev/xvdf1 /mnt/ebs/

ここで注意が必要なのは、デバイス名です。

上記でEBSをアタッチした際に、下記のような注意書きがありました。

注: ここで入力された (および詳細情報に表示される) デバイス名が /dev/sdf から /dev/sdp であっても、新しい Linux カーネルによっては内部でデバイスの名前が /dev/xvdf から /dev/xvdp に変更されることがあります。

デバイス名が変更されているので、そこを考慮してブロックデバイスをマウントさせます。

調査開始

ここまでできたら、何が起こったか調査開始です。

僕の当初の予想では何か不正なファイルを大量にアップロードされて、ファイルシステム容量が一杯になってしまったのではないかと予想してたので、dfコマンドで容量を確認してみました。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            229M     0  229M   0% /dev
tmpfs            48M  736K   48M   2% /run
/dev/xvda1      7.7G  1.1G  6.7G  14% /
tmpfs           240M     0  240M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           240M     0  240M   0% /sys/fs/cgroup
/dev/loop0       88M   88M     0 100% /snap/core/5328
/dev/loop1       13M   13M     0 100% /snap/amazon-ssm-agent/495
tmpfs            48M     0   48M   0% /run/user/1000
/dev/xvdf1      7.8G  3.8G  3.6G  52% /mnt/ebs

一番下が対象の領域なのですが、使用率が52%といっぱいではありませんでした。

じゃあ何がだめだったのかをシステムログから確認します。

/mnt/ebs/var/log配下に残っていたsyslogを見てみます。

すると、

Oct  2 20:31:33 ip-XXX-XXX-XXX-XXX dhclient: fork: Cannot allocate memory

こんな感じのログが連続して吐かれていました。

なんとなくメモリ領域が不足しているような感じでした。

ググっても同じような記事を見かけたので、とりあえず原因はメモリ不足と判断しました。

aws wordpressを構築したt2.microが反応しなくなる件 | Kikudai Blog

とりあえず元のEC2のメモリを増やして起動

元のEC2で使用していたインスタンスタイプがt2.micro（メモリ1GB）だったので、t2.small（メモリ2GB）に変更してみます。

その後、元のEBSをアタッチしてEC2を起動します。

ログインできるか確認

その後、ログインできるかどうか確認してみたところ、正常にログインできました。

まあメモリ1GBのしょぼしょぼサーバで運用していたので、こんな状況もあるかなと思いましたが、なんでメモリ不足になったかまでは調査していないので、今後調査すると共に、CloudWatchを使用したメモリ監視の機能も考慮したいと思います。

残念なことに、GlastopfやCorwieの自動起動設定もやっていなかったし、NATの設定も消えてしまったので、そのあたりも設定したいと思います。

とりあえず、乗っ取られてなくてよかった。笑