AWSでHoneypot構築してみた
2021年12月17日時点での動作確認済み
・構成図
・EC2作成
1.リージョン選択
以下の場所からリージョンを変更してください。
今回は東京リージョンで進めます。
2.インスタンス作成
3.「Debian 10」を選択
4.「t2.xlarge」を選択して次のステップへ
xlarge以下で試しましたがまともに動かなかったので、xlarge以上推奨です。
5.ステップ3はそのままで次のステップへ
6.ステップ4でサイズを「30」GBにして次のステップへ
7.ステップ5はそのまま次のステップへ
8.ステップ6でセキュリティグループの設定をする
セキュリティグループの割り当て「新しいセキュリティグループを作成」
セキュリティグループ名「T-Pot」、説明「T-Pot」
ソースを「マイIP」、説明には「SSH」
これらを変更し「確認と作成」へ
9.ステップ7で設定を確認し問題なければ「起動」
10.キーペアの作成
「新しいキーペアの作成」を選択し、キーペアタイプは「RSA」を選択
キーペア名に適当な名前(今回は「T-Pot-key-pair」)をつけて「キーペアのダウンロード」をする
※キーペアは再ダウンロードできないため注意
11.インスタンス作成画面に戻り、インスタンスができていれば完了です。
12.設定を間違えて作成してしまった場合
「インスタンスの状態」から「インスタンスの停止」、「インスタンスの終了」を押し、2から作り直してください。
・T-Potのインストール
まずTera termを起動します。 (Tera termをインストールしてない方はこちらからhttps://ja.osdn.net/projects/ttssh2/ )
1.Tera termの接続
ホストに先ほど作成したインスタンスの「パブリックIPアドレス」を入力
※今回はElastic IP アドレスを使用していないので、インスタンスを開始するたびに「パブリックIPアドレス」は変わります。
TCPポートは「22」、「SSH」で接続します。
2.SSH認証
ユーザ名には「admin」、認証方式は「RSA/DSA/ECDSA/ED25519鍵を使う」を選択し秘密鍵をEC2作成の10でダウンロードした鍵を使用し接続。
3.セットアップしていきます。
パスワードを求められた場合は任意で、Y/nはすべてYで進めていきます。
USERNAME=honey # ユーザ名の設定します sudo apt update && sudo apt upgrade -y #パッケージの更新 sudo apt install git #Gitのインストール sudo adduser honey #ユーザの追加 sudo gpasswd -a honey sudo #sudoグループに追加 sudo su honey #ユーザ切り替え
4.SSHの設定
cd #ホームディレクトリへ移動 mkdir .ssh #ディレクトリの作成 chmod 777 .ssh #権限設定
今回はWin SCPを使い公開鍵を.shhディレクトリに入れます。
(Win SCPのインストールはこちらからhttps://winscp.net/eng/download.php)
WinSCPを起動します。
ホスト名にインスタンスの「パブリックIPアドレス」、ユーザ名に「admin」を入力し、設定を押す。
SSHの認証に移動し秘密鍵(EC2作成の10)を選択する。
ここで公開鍵を表示し「authorized_keys.」で保存をし、OKして接続する。
先ほど作成した「authorized_keys」を/home/honey/.shh/に入れる。
(.shhが表示されない場合はWinSCPの「オプション」→「環境設定」→「パネル」→「隠しファイルを表示する」にチェックを入れてください。)
Tera termに戻り、以下のコマンドを入力
chmod 700 .ssh
5.TPotインストール
git clone https://github.com/dtag-dev-sec/tpotce cd tpotce/iso/installer/ cp tpot.conf.dist tpot.conf vim tpot.conf # myCONF_WEB_USER と myCONF_WEB_PW に管理画面のユーザ名とパスワードを指定します。 sudo ./install.sh --type=auto --conf=tpot.conf sudo reboot
6.管理用ポートの開放
T-Pot をインストール後に再起動した時点で SSH のポートが変更され 22 番ポートで SSH 接続ができなるため管理用途で使うポートを開放します。
AWSのセキュリティグループの「インバウンドルールを編集」から設定します。
「ルールの追加」をし以下のポートを追加して「ルールの保存」をします。
・ 64295 (SSH 用)
・ 64297 (Web 管理画面用)
※「インバウンドルール」の「ソース」の値は管理画面にアクセスするIPアドレスになるので、「マイIP」での設定を推奨しますが、その場合、接続するPCのIPアドレスが変更される毎にセキュリティグループの設定を更新する必要があります。
7.管理画面のアクセス
webブラウザで https://(IPアドレス):64297/にアクセスします。
「この接続ではプライバシーが保護されません」と表示されたら、「詳細設定」→「<IPアドレス> にアクセスする（安全ではありません）」を選択してアクセスしてください。
以下のような画面が表示されればOKです。
8.攻撃を受けるためのポート開放
「セキュリティグループ」→「インバンドルールを編集」→「ルールの追加」から以下を追加し、「ルールを保存」。 ・タイプ「カスタムTCP」、ポート範囲「1-64000」、ソース「カスタム」「0.0.0.0/0」 ・タイプ「カスタムUDP」、ポート範囲「1-64000」、ソース「カスタム」「0.0.0.0/0」
設定し終わったら管理画面で実際に攻撃されていることを確認してください。
・まとめ
今回最初はubuntuで構築しようと試しましたが、バージョン16.04はPythonエラーで20.06はサポート対象外であったためDebianで構築しました。 この構築手順が参考になりましたら幸いです。
Honeypotを利用したユーザに対する攻撃手法の研究
背景
現在、コロナによるテレワークの増加により、一般ユーザが社内の安全なネットワークから外れ、自宅環境で業務を行うことが増えてきている。その為、セキュリティ管理がしっかり行われていない個人に対してサイバー攻撃を行われる可能性がある。
事例として、自宅から社内のサーバにアクセスする際にデータを盗聴、なりすまし、送信したデータの改ざんをされたり、SSH等でリモート接続し、業務を行う場合でもリモートデスクトッププロトコルの脆弱性をついた攻撃等を受けてしまうことがある為、テレワークをする際にはセキュリティ上の危険性を理解し、安全に業務を行うことが必要である。
そのためには、まず攻撃者の個人に対する攻撃手法、内容を知ることが重要だと考える。
目的
本研究では、Honeypot(仮想ネットワークを持つことで外部に危害を与えずに侵入者の行動やマルウェアの挙動を観察できるシステム)を構築し、個人に対するサイバー攻撃（ハッキング、クラッキング）の手法、内容を分析することで、テレワークにおけるセキュリティ上の問題を洗い出し、そこで得られる情報をユーザにわかりやすく提示することで、ユーザのセキュリティ管理の意識を高めることを目的とする。
研究の内容
複数の仮想的なホストを内部に持つ攻撃監視システム(Honeypot)を構築、運用し、その構築した複数の仮想ホストに攻撃をリダイレクトさせることでシステム外部のホストへ危害を与えることなく Honeypot 内での攻撃者の行動を観察、分析することである。
Honeypotについて
Honeypot とは不正なアクセスを受けやすいように設定したシステムやネットワークを公開し、攻撃者の特定、受けた攻撃手法を分析するためのものである。今回は後述する様々なHoneypotが含まれているT-potを使い、運用していく。
T-potは”ドイツテレコム”によって開発されたHoneypotでこれをDocker上で動作させ、ログを ElasticSearch に集約、Kibana で可視化するというものである。
今回運用では、下記の表に記されている16種類のHoneypotを動作させることが可能である。
|
adbhoney |
Android Debug Bridge（ADB）に使用するポート5555が公開されている無防備な被害者に、攻撃者によってプッシュされているマルウェアをキャッチするように設計された、相互作用の少ないHoneypotを提供する |
|
ciscoasa |
DoSおよびリモートコード実行の脆弱性であるCVE-2018-0101を検出できるCiscoASAコンポーネントの相互作用の少ないHoneypot |
|
conpot |
展開、変更、拡張が簡単にできるように設計された、インタラクティブ性の低いサーバー側の産業用制御システムのHoneypot |
|
cowrie |
ブルートフォース攻撃と攻撃者によって実行されたシェルの相互作用をログに記録するように設計された、中程度から高度の相互作用SSHおよびTelnet Honeypot |
|
dionaea |
|
|
elasticpot |
インターネットに公開されている脆弱なElasticsearchサーバーをシミュレートするHoneypot |
|
glastopf |
産業用制御システムを標的とする敵の動機と方法に関する情報を収集することを目的としたICSHoneypot |
|
glutton |
SSHとTCPプロキシとして稼働し、攻撃者とサーバ間のMITMとして機能し、すべてをプレーンテキストで記録するHoneypot |
|
heralding |
|
|
honeypy |
相互作用の少ないHoneypotで、相互作用が中程度のHoneypotになることが可能 |
|
honeytrap |
攻撃を監視するために作成されたネットワークセキュリティツール |
|
mailoney |
|
|
medpot |
ポート2575でリッスン、GOsdepを使用するHL7 / FHIR Honeypot |
|
rdpy |
RDPYは、イベント駆動型ネットワークエンジンTwisted上に構築されています。RDPYは、標準のRDPセキュリティレイヤー、RDP over SSL、およびNLA認証（ntlmv2認証プロトコルを介して）をサポートする。 |
|
snare |
Webアプリケーションハニーポットセンサ「SNARE」は、「Glastopf」の後継機種です。SNAREは、Glastopfと同等の機能を持ち、既存のWebページを攻撃対象に変えることができる |
AWS - EC2とは
AWSとは、Amazon.comより提供されているクラウドコンピューティングサービスのことである。
仕様変更に長時間の物理的な作業を必要とする自社運用のサーバと比較して、AWSは需要に応じた計算能力を、設定変更のみで速やかに提供できることが強みである。
必要な環境をすぐに利用できること、接続に公開鍵を使用し、SSH接続にて安全に内部サーバの構築ができること、また構築が失敗してもクラウド上のサーバを消去することで外部に影響がでないことから、初心者が自分のPC上でHoneypotを構築するよりも安全だと考え、今回のシステムではAWSのサービスの一種であるAmazon EC2(必要に応じてスペックを変更できる仮想サーバを作成することができるサービス)を利用し構築した。
Honeypotの構成と環境構築
本研究で使用するHoneypotの最小要件と構成は以下のようになっている。
- 4GB RAM
- 64GB Disk
- DHCPネットワーク
- ネットワーク接続
上記の内容を考慮し、下の画像のEC2インスタンスを作成した。また、本環境はAWSの東京リージョンに設置されており、AWSのパブリックIPアドレスを割り当て、パブリックDNSは割り当てていない。AWSのセキュリティグループはHoneypotにログインするポート番号(64925,64927)以外はすべてオープンとなっている為、 「AWSのセキュリティグループの設定を誤るとこんな攻撃を受ける」という視点で見てもらうと、セキュリティの重要性を理解する助けになると思う。
EC2を使用したHoneypotの環境構築手順を以下に示す。
https://aws.amazon.com/jp/register-flow/
取得した情報の整理、分析
今回、構築したT-potに対する攻撃を各Honeypot別に集計すると下記グラフのような結果になった。
最も多くの攻撃を受けたのは、Dionaea（SMB , HTTP , HTTPS , FTP ,TFTP , MSSQL , MySQL , SIP等に対応した低対話型Honeypot）であった。
2番目はHoneytrap(TCP/UDPに対する攻撃を検知するハニーポット)であり、期間中に7万9千回を超える攻撃を検知した。
3番目のCowrieは攻撃者がブルートフォース攻撃とシェルの対話を記録するように設計された、中規模の対話型SSHとTelnetハニーポットである。
利用を試みられたCVEは
- CVE-2001-0540 31,284件
- CVE-2006-2369 30,696件
- CVE-2012-0152 1,281件
- CVE-2021-44228 CVE-2021-44228 874件
- CAN-2001-0540 873件
- CVE-2019-11500 CVE-2019-11500 710件
- CVE-2002-0013 CVE-2002-0012 CVE-1999-0517 654件
- CVE-2002-0013 CVE-2002-0012 637件
- CVE-2019-12263 CVE-2019-12261 CVE-2019-12260 CVE-2019-12255 489件
- CVE-2001-0414 260件
上記のようになっており、最も多かったCVEはCVE-2001-0540。この脆弱性は「Windows NTおよびWindows 2000のターミナルサーバーのメモリリークにより、リモートの攻撃者は、多数の不正なリモートデスクトッププロトコル（RDP）要求を使用してポート3389にサービス拒否（メモリ枯渇）を引き起こす可能性がある脆弱性である。（http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-0540）
次のCVE-2006-2369はインターネット越しにWindowsを遠隔操作するRealVNCを使用した製品を利用すると、リモートの攻撃者はクライアントが「タイプ1-なし」など安全でないセキュリティタイプを指定する要求を介してバイパスできるものである。
3番目のCVE-2012-0152はリモートデスクトッププロトコル(RDP)サービスにより、リモートの攻撃者は一連の細工されたパケット(ターミナルサーバーのサービス拒否)を介してサービスの拒否を引き起こすことができるものである。
そして12月6日に確認されたCVEのCVE-2021-44228 CVE-2021-44228はApache Log4jに存在する RCE 脆弱性である。この脆弱性は2021年12月6日にApache Software Foundationにより修正されたLog4j に存在するリモートコード実行の脆弱性（CVE-2021-44228）についての検証を実施し、脆弱性の悪用が可能であることを確認されたものである。
https://www.intellilink.co.jp/column/vulner/2021/121500.aspx
国別による攻撃者の割合としては下記のようになっている。
最も多かった国はアメリカで5900番ポートに11,625件、2番目はチェコで1025番ポートに900件攻撃を確認できた。
以前からロシアやアメリカ、中東などの国々からは攻撃が観測されていたが、ヨーロッパからの攻撃が増えていることが新たにわかった。しかし、他の攻撃の踏み台として使われている可能性もある（踏み台攻撃の場合、首謀者のと特定ができない）ため、本当にこの数値が正しいか、また別に研究する必要があると考える。
結果・考察
本研究にて、最も多くの攻撃を受けたのは、Honeytrap(Windowsクライアントに類似させ、TCP/UDPに対する攻撃を検知するハニーポット)であることから、シェア率の高いWindowsユーザに対し、常に攻撃を行っていることがわかる。
また、資格情報（管理者や一般ユーザ等）を狙った攻撃（ユーザIDとパスワードの組み合わせによってユーザ又は管理者アカウントに不正ログインし、コマンド等を実行する）も複数確認された為、ユーザの権限の設定やシステムの管理者アカウント等（特権ID）に対して複雑なパスワードや二段階認証等を適用することが大切である。
既知の脆弱性（CVE）の利用を試みる攻撃確認され、その中にはリモートでのサービス等に使用されている “Windows 7” の “Remote Desktop Protocol” や “Terminal Server Service” 等の脆弱性をつく攻撃が多く確認できた為、使用する場合は該当システムの脆弱性に対してパッチ等が適用されたバージョンを使用することを推奨する。
また、企業などが長期休暇や祝日（クリスマスや年末年始）に入ると、攻撃への対応が遅れる為、攻撃が集中すると思われたが、分析した結果普段行われている攻撃数とあまり変わりはなかった。これに関しては、本環境が個人や小規模なシステムへの攻撃を監視するものだった為、差が見られなかったと思われる。
12月6日に確認されたApache log4jの脆弱性を狙った攻撃が第4位になっていることから、新たに発見され、まだ対応が追い付いていない脆弱性を対象にしている攻撃者も多くいると考えられる為、運用しているサービスに関するセキュリティ上の問題が報告された場合は速やかに情報を収集し、適切な対処をする必要がある。
