GuardDutyでSSHスキャナーを検知する

GuardDutyにはRecon:EC2/PortProbeUnprotectedPortというイベントがあります。既知のスキャナーがSSHやRDP接続を試みていることを知らせるイベントです。このイベントが本当に発動するのかSSHを0.0.0.0/0で許可したEC2を立てて確認しました。

EC2の起動

SSHとNetwork ACLで0.0.0.0/0を許可しているLinuxインスタンスを起動します。日本時間22:49に起動しました。

攻撃の発生とGuardDutyでの検知

sudo tail -f /var/log/secureでログを見ていると、日本時間22:52にrootユーザーの認証が試みられていることがわかりました。 インスタンスが起動してから3分しか経っていません。 175.xx.xx.xxのIPアドレスから最大試行回数を超えるrootユーザーの接続があったようです。

Aug  5 13:52:14 ip-172-31-22-86 sshd[2641]: error: maximum authentication attempts exceeded for root from 175.xx.xx.xx port 50711 ssh2 [preauth]
Aug  5 13:52:14 ip-172-31-22-86 sshd[2641]: Disconnecting: Too many authentication failures [preauth]

GuardDutyを見ると、Recon:EC2/PortProbeUnprotectedPortが発生しています。

アクターを確認すると、103.xxx.xxx.xxxのIPアドレスからSSH接続があったことがわかります。 GuardDutyは103.xxx.xxx.xxxを既知のスキャナーとして認識しており、ログに残った175.xx.xx.xxは既知のスキャナーとしては認識されていないようです。

VPCフローログを見てみる

外部からのSSH通信は具体的にどのぐらいあったのか、VPCフローログを確認します。Amazon VPC フローログのクエリを参考にVPCフローログをAthenaで解析します。ユーザーガイドの「Amazon VPC テーブルを作成するには」を行い、テーブルを作成します。集計クエリは以下を実行しました。

SELECT SUM(numpackets) AS packetcount,
sourceaddress,
destinationaddress
FROM vpc_flow_logs
WHERE destinationport = 22
GROUP BY sourceaddress,destinationaddress
ORDER BY packetcount DESC

クエリの結果、自宅以外に5つのIPアドレスからTCP22ポートへの接続が認められました。 ここまでEC2の起動から1時間経過していません。 セキュリティグループの受信ルールでSSHを制限しないとスキャンを受ける様子がわかります。

セキュリティグループを制限しないとすぐにスキャンされる

今回の検証でセキュリティグループでSSHを0.0.0.0/0で許可すると、数分後にはTCP:22でのスキャンが発生することがわかりました。鍵認証と最新のOSを利用していれば、認証に成功することはほとんどないと思われますが、セキュリティグループを制限しておけばそもそもこのようなスキャンを防げます。 セキュリティグループのSSH無制限ルールは、AWS Configルールのrestricted-sshや、Trusted Advisor、insightwatchで気が付けます。

さいごに

SSHを無制限に許可したLinuxインスタンスを作成すると、すぐに外部ホストからTCP:22での接続を受けることがわかりました。 セキュリティグループをきちんと管理するのはもちろんですが、GuardDutyを有効化しておけば、攻撃や攻撃の予兆に気がつくことができます。またVPCフローログを有効化しておけば、ご紹介したようにAthenaでログを解析できます。GuardDutyとVPCフローログはセットで追加していただければと思います。

参照

• Recon:EC2/PortProbeUnprotectedPort