AWS EC2へのSSHに対する攻撃をハニーポットで分析してみた (2015年4月〜6月)

数ヶ月間、私のお小遣いを貪り続けてきたAWS EC2上のハニーポットですが、さすがに財布へのダメージが蓄積してきたのでいったん停止させました。停止させたもののそれなりにデータを蓄積していたので、さてどうしようかなと思っていたのですが、 先日、長崎で開催された情報処理学会のコンピュータセキュリティシンポジウム2015で聞いた講演の一つに SSHの新しい攻撃方法について触れられていてちょっと気になったので、収集したデータのうちSSHに関しての通信のみちょっと分析してみました。

ハニーポットの構成やデータの収集方法については過去のエントリを参照していただきたいのですが、 今回はAWS Asia Pacific (Tokyo)上でEC2のインスタンス4つを4月頭から6月末まで動かしてデータを取得しました。財布へのダメージも4倍！ しかしおかげで複数のIPアドレスで観測した時に生じる差分について知ることができました。

アクセス件数の推移

2015年4月から6月までEC2の4インスタンスで観測したSSHサーバへのアクセス件数

まずはベタに各インスタンスに対するアクセス件数を時間軸で見たものです。A, B, C, Dがそれぞれのインスタンスになりますが、 4つともアクセス件数の傾向にそれほど大きなブレ方はしていないことがわかります。これらのインスタンスが使っているIPアドレスは どこにも広告していないので基本的には全て無差別に打ち込まれている攻撃であると言えます。そのため特定の組織などに対する 攻撃とは異なるかもしれませんが、このようなアクセスは使用しているIPアドレスに関わらず、安定（？）して日々起きていることがわかります。

アクセス先ポート番号の件数

2015年4月から6月までEC2の4インスタンスで観測したSSHサーバに対するアクセス先ポート番号の件数

つづいてアクセス先ポート番号の分布です。4インスタンスの合計値から上位20件をグラフにしてみました。 当然ながらデフォルトポートである22番へのアクセスがダントツですが、それ以外にも様々なポート番号に対して アクセスが来ていることがわかります。ちなみに観測されたポート番号は合計56種類となっており、 5050、18080 などといったSSHとは全く関係なさそうなポート番号もターゲットとなっていました。

今回利用したハニーポットは特にSSHサーバを偽装するわけではなく、 アクセスしてきた接続元のホストに対してSYN-ACKを返すだけで、あとは勝手に相手が送ってくれたデータをせっせと回収します。 ではなぜ22番ポート以外もSSHだとわかったのか？というとSSHの接続確立時に相手が勝手にバナーとして SSH-2.0-PUTTY のような文字列を送ってきてくれるので、そこからSSHをターゲットにしているということがわかります。 なかにはSSH-2.0-paramiko_1.15.2やSSH-2.0-libssh2_1.4.2のように、あからさまにツール使ってますぜと宣伝してくれている やつもいたりします。 しかし先に述べたとおりこちらからは何も情報を渡していないため、相手は攻撃先がSSHサーバであるかどうかを確認などせずに22番以外の ポートに接続をしにきているということがわかります。「ポート番号を変えているからパスワード認証でも大丈夫だよね」とか 「ポートスキャンを止めているからどこがSSHのポート番号かわからないよね」と考えている管理者の方はぜひ設定の見直しをお勧めいたします。

アクセス先IPアドレスと攻撃元IPアドレスの関係

2015年4月から6月までEC2の4インスタンスで観測した攻撃元IPアドレスの件数（アクセス先IPアドレス毎）

それではようやく複数のインスタンスを使ってデータ収集した強みをみたいと思います。 気になることの一つとして「攻撃者はIPアドレスのレンジを舐めるように攻撃しているのでは？」ということだと思います。 実際にSSHにかぎらずport sweep（アドレスレンジに対して特定のポートが空いていないか順番に確認するタイプのスキャン）などでは そういった挙動も見られます。

上の表は各インスタンス（A, B, C, D）で観測されたかどうかと、それぞれで観測されたIPアドレスのユニークな数になります。 観測されたIPアドレスは全部で6,669件ですが、そのうちの約80%にあたる5344件の攻撃元IPアドレスがどれか一つのインスタンスでのみ 観測されているということになります。それぞれのインスタンスはある程度同じレンジにおさまっていたため、 このことから 攻撃者は近接するアドレスに対して何度も出現する可能性が高いとは言えない ということがわかります。 先ほどのポート番号に比べると直接的な対策ができるような類のものではありませんが、例えば自組織で管理されている サーバでSSHの不審なアクセス（Brute forceなど）が発生したさいに他のサーバも利用するブラックリストに追加する、 というような対策はそれほど効果的ではないかもしれません。（もちろん、残り20%は複数インスタンスで観測されているので 無意味ということはありませんが、それでも全インスタンスで観測されたアドレスは約6.5%ほどになっています）

攻撃元IPアドレス毎の接続試行回数

2015年4月から6月までEC2の4インスタンスで観測した攻撃元IPアドレス毎の接続試行回数の分布（n<10)

最後にご紹介するのが1つの攻撃元IPアドレスからやってくるSSHアクセスは何回まで試行されるか？ということをグラフにしたものです。 先述したとおり、このデータ収集はあくまでTCPセッションが確立したとみせかけてデータを送信させるだけという仕様になっているため、 本当にBrute force attackのようなパスワード試行された回数をカウントしているわけではありません。 しかし、通信状態の問題などでうまく接続できないなどのケースが考えられるため、相手がどれくらいしつこかったのかということを 知る指標にできるかと思います。

このグラフでは1つのインスタンスでのみ観測された5344件のIPアドレスに対してそれぞれのアドレスは何度接続試行したのかを ヒストグラムで表したものとなります。一番左のバーが1回だけの試行だった攻撃元IPアドレスのかたまりになるのですが、 これを見るとほとんどの攻撃元IPアドレスが試行1回目でダメそうだったらその時点で諦めているということがわかります。 このグラフは試行10回までの分布しか表示していませんが、10回以上試行してきたIPアドレスは16件だけでした。 全体的に非常に諦めがよい、ということを読み取ることができます。

しかし、ここで最初にふれた情報処理学会のコンピュータセキュリティシンポジウム2015の話に戻ってくるのですが、 富士通研究所の齊藤さんが発表された「SSHログインセンサによるSTBF(Brute Force attacks with Single Trials)の観測」において 一つのIPアドレスからパスワード試行が1回だけ実施されて、次は別のIPアドレスから試行されて、というのを繰り返すBrute force攻撃が確認されたという 事例が報告されていました。これは、一つのホストからパスワード試行を繰り返すと防御側に目立って接続拒否されたり、 共有されているブラックリストに掲載されてしまい他の環境に対しても攻撃ができなるなることを攻撃者が警戒した結果、 ボットネットのように悪性ホストを大量に所有（またはレンタル）している攻撃者が目立たないように1回だけパスワード試行をして去る、という 一撃離脱型の攻撃が連続して発生しているということだと考えられます。 この攻撃に対してはIPアドレスを基準としたパスワード試行回数制限による対策がほぼ無効化されてしまうということが言えます。

実際にこの攻撃がどのくらい世の中に蔓延しているかについては発表者の方も今後調査を継続していくとおっしゃられていましたが、 ここで紹介した分析からもそのような種類の攻撃が発生している可能性を示唆する結果となりました。 AWSでのインスタンスに限りませんが、SSHでリモートアクセスをしているホストについては 今一度設定の見直しなどをしたほうがよいかもしれません。