クラウドネイティブハニーポット on AWS 2022春の陣
前回のあらすじ
3年ほど前にAWS上にハニーポット環境を作成しました。
大雑把に説明すると、（主に）AWSのEC2インスタンスあてにどのようなexploitが飛んでくるのか？というのを知るために、
- EC2インスタンスに管理用、および観測用のElastic IP addressを設定し、そこでハニーポットを動かす
- ハニーポットで取得した生データ（pcap）をS3に保存し、Lambdaで分析する
- 分析結果は CloudWatch Logs Insights で閲覧できるようにする
という構成にしていました。これはこれでマネージドサービスを使った面白い構成だったと当時は思っていたのですが、実際に動かしてみるといくつかの課題があり、最終的には運用を止めてしまいました。
前回の課題
1) Elastic IP addressの制限でスケールしにくい
EC2は自前で2つ以上のネットワークインターフェースを接続すると標準で割り当てられるパブリックIPアドレスが使えなくなってしまうため、Elastic IP Address を2つ確保し、それぞれを管理用、監視用として使っていました。これは以前使っていたハニーポットの実装がすべての通信をキャプチャしてしまい、インターフェースを分ける必要があったためです。しかし、Elastic IP addressはリージョンごとに5つしか使えないという厳しい成約があり、同じリージョン内に同じ構成のEC2インスタンスは多くて2つまでしか作れません。
また、価格も $0.005/hour となっており、月換算だと1インスタンスあたり$7.2になります[1]。これに加えてEC2インスタンスの料金も加算されるため、趣味で使うにはまあまあいい価格にはなってしまいます。
2) CloudWatch Logs Insights を見に行くのがだるい
収集・分析した結果を見るためのインターフェースとして CloudWatch Logs Insights は必要な機能を概ね満たしているのですが、これを日々見に行くのはかなり面倒に感じました。AWS console自体が一定時間で自動ログアウトしてしまうので「ちょっと今日の様子を覗く」みたいなユースケースとは相性が悪いといえます。
また、これは慣れと言えば慣れなのですが、独自のクエリについて毎回調べないと思い通りの調査ができない、というのもややストレスな部分でした。
3) データ保全のための構造が冗長
現状、学術研究の分野に身をおいてない自分としては、とりあえず「どのようなexploitが日々とんできているか」ということがわかればいいので、生pcapデータをS3に保存するというのは冗長でした。ログ収集・ログ分析において「S3に一度データを保存してその後にLambdaで分析する」というのは可用性の観点で鉄板のアーキテクチャです。しかし、趣味でやっている範囲なんでそこまでの可用性は必要ないし、分析についてもせいぜいTCPのペイロードがわかればいいぐらいでした[2]。
そのため、データの保存・分析のアーキテクチャをもう少し軽量にしたいと考えていました。
クラウドネイティブハニーポット2022春バージョン
ということでゴールデンウィークの長期休暇を利用して少しテコ入れし、2022年春バージョンを構築して再起動させました。
アーキテクチャ
EC2上でハニーポットソフトウェア lurker を動かして外部からの通信を監視する、という全体像は引き続き変わりありません。その代わりに以下のような変更をしました。
- Elastic IP addressの利用をやめる: EC2インスタンスにデフォルトで割り当てられる public IP address だけを利用するようにしました。
- Lambdaによる定期的なインスタンスの破壊と起動: ハニーポットは長時間同じIPアドレスで動作させると攻撃者から「ハニーポットである」ということを認識されて、攻撃を敬遠される可能性があります。そのため、定期的（現在は1時間ごと）にEC2インスタンスを削除＆同じAMIから新たに別インスタンスを起動することで断続的に異なるIPアドレスを付与する[3]、ということが実現でき、収集するデータに偏りがないようにしました。
- 複数インスタンスの利用によるスケールアウト: Elastic IP addressの制約がなくなったため、EC2のquote範囲内であればスケールアウトができるようになり、より効率的にexploitデータを収集できるようになりました。
この構成の場合、t3.nano のような格安インスタンスを使えば時間あたり $0.0052 = 1ヶ月あたり $3.744（500円弱）ほどで1台のハニーポットを運用できます。また、追加の Elastic IP address を使っていないことで容易に複数台のホストを構成できるようになりました。現在では3台ほどを同時に動かしてデータ収集をしています。
ハニーポットソフトウェア
アーキテクチャの一新にともない、ハニーポットソフトウェア lurker も実装を大幅に更新しました。基本的な動作（TCP SYNパケットに対して、偽装したSYN-ACKパケットを返し、送信されてきたデータを記録する）は過去に作ったものとほぼ変わりありません。しかし、過去の実装は自分がGo言語覚えたてでコードの整理も十分でなかったので、全面的に構造なども含めて見直しました。機能的には以下のような変更を加えています。
- 監視対象となるIPアドレスあての通信のみ記録する: 以前はoutgoingな通信も記録してしまったため、監視用のインターフェースと管理用のインターフェースを分離する必要がありました。しかし、監視用のIPアドレスを明示するようにして、そのアドレス宛の通信のみ記録するようにしたことで、1つのIPアドレスだけで運用できるようになりました
- BigQueryへデータを（直接）保存する: 補足したデータと送信元IPアドレスやポート番号などだけ記録していれば良い、ということでBigQueryにデータを貯めることにしました。BigQueryは主にデータの入力とクエリ時のデータスキャンによって課金されますが、現状使ってみた限りだとコストは1週間で10円以下に済んでいるようです。
- Slackへデータをを送る: Slackは通知ではなく、気軽に補足したデータをプレビューできるUIとして利用しています。分析などはできませんが、普段使っているツールなので気軽に最近の傾向をチラ見することができます。気になったペイロードなどを見つけた場合は、BigQueryの方で検索・分析などをかけることができます。
Slackへの通知は以下のようにHexとHuman readableな形式の両方を掲載してメッセージされます。すべてのデータを見るのは難しいですが、気が向いた時にざっと眺めるには十分なUXになっています。
観測されたスキャン＆攻撃
せっかくなのでこの仕組によって収集されたスキャンや攻撃のデータをちょっとだけ晒してみたいと思います。
注意：ここで紹介するデータを実在する機器に送信すると不具合を起こす可能性があります。自分の管理下にある機器以外にデータを送信すると攻撃に該当し、刑事罰の対象になる可能性がある点に十分留意してください
古い脆弱性を狙った攻撃
既知の脆弱性を狙った攻撃コードはかなり頻繁に観測されます。おそらくアプリなどをインストールしたもののそのまま放置されているようなEC2インスタンスを狙っている、あるいはインストールしたばかりでまだ設定や脆弱性修正が終わっていない（にもかかわらずサービスが公開されてしまっている）ものを狙っいると考えられます。
例えば以下のデータはPHPUnitのCVE-2017-9841を狙った攻撃と見られます。
このような攻撃がIPアドレスをどこにも公開していない（ドメイン名との紐付けや、なんらかのサービスでの参照が無い状態）でも着弾していることを鑑みると、 原則として 設定やセキュリティ対策が不十分なインスタンスは、public IPアドレスから到達できるようにしてはいけない ということが分かるかと思います。
IoT機器を狙った攻撃
AWS上なので特殊なネットワーク構成などでない限り効果があるとは考えにくいのですが、なぜかいわゆるIoT機器の脆弱性を狙ったと見られる攻撃もよく観測されます。
上記の攻撃は D-Link DSL-2750B のコマンドインジェクション脆弱性を利用した攻撃と見られます。すべてを確認したわけではないですが、実行されることによってインストールされるであろうファイルは Mirai でした。paloaltoの記事 により詳しい説明があるので、興味ある方はこちらをご参照ください。
SSHのスキャン
もはや定番ネタなんですが、「攻撃者はSSHのデフォルトであるポート22を狙ってくるので、他のポート番号に変えておくと安全」という説があります。一週間ほどハニーポットで観測したsshの接続を試みたと思われる接続（データのprefixが SSH- のもの）を集計してみると、たしかに全体の67%相当である997件はポート22へ接続していますが、残りの33%あまりは全く異なるポートへ接続を試みています。
（ここに結果を貼ると大変なことになるので、gistに集計結果を置いておきます）
それぞれのポートへの接続数は22に比べると圧倒的に少ないためたしかにポートへ到達される確率は低くなりますが、逆にどのポートにしても到達される可能性が0ではない、ということがわかります。このことから、
- どのポートを使うとしても基本的な対策（鍵認証のみにするなど）は怠るべきではない
- ポートを変えておくことで、もし脆弱な設定のsshサーバが事故で露出してしまっても、多少時間を稼ぐことはできる
- ただしいずれ攻撃されると考えるべきで、安全とは言えない点に留意すべき
というのが実態であり、組織などの要件などに応じて対策の方針を決めるべきと考えます。
まとめ
基本的にはほとんど前回の焼き直しなのですが、構成がアップグレードしつつコストも抑えられるようになったのは良い進捗でした。また観測できる攻撃も昔ながらのものもあれば、新規に見えるようになったものもあり、傾向を把握しておくことは個人的に意義はあるなと感じました。仕事的に直接のメリットはなんにもないんですが、ほそぼそとしたハニーポット運用を引き続きやりたいと思っています。
Discussion