#10 Kibana

第10週。

数週間前に構築したハニーポットのログがたまってきました。そろそろ見てみようかなと思い立った矢先、

サーバーが暴走しておりました。調べてみると、マルウェア捕捉用のハニーポット「Dionaea」がCPU100%で張り付いています。とりあえず、サービスを再起動しましたが、何が起きていたか調査してみようと思います。

目標

ElasticSearchでログ解析環境を構築し、サーバー暴走の原因を探る。

とりあえず、DockerでElasticSearch＆Kibana環境を作るところから始めます。

作業

1. Dockerの用意

Dockerはすでにありました。

$ docker -v
Docker version 20.10.8, build 3967b7d

2. docker-compose.ymlで環境の設定

Elasticの公式Dockerイメージが公開されているので、それを使います。公式ドキュメントを参考にdocker-compose.ymlを用意しました。

version: "3.8"
services:
   elasticsearch:
       image: docker.elastic.co/elasticsearch/elasticsearch:7.16.3
       hostname: doc-elastic101
       container_name: es01
       environment:
           - cluster.name=es-docker-cluster
           - network.host=0.0.0.0
           - node.name=es01
           - node.master=true
           - node.data=true
           - discovery.type=single-node
           - bootstrap.memory_lock=true
           - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
       ulimits:
           memlock:
               soft: -1
               hard: -1
       mem_limit: 1g
       ports:
           - "9200:9200/tcp"
       networks:
           esnet:
               ipv4_address: 172.30.10.1
       volumes:
           - elasticsearch1-data:/usr/share/elasticsearch/data
       extra_hosts:
           - "doc-kibana101:172.30.20.1"

   
   kibana:
       image: docker.elastic.co/kibana/kibana:7.16.3
       hostname: doc-kibana101
       container_name: kibana1
       environment:
           SERVER_NAME: "kibana"
           ELASTICSEARCH_HOSTS: "http://doc-elastic101:9200"
           ELASTICSEARCH_REQUESTTIMEOUT: "60000"
       ports:
           - "5601:5601/tcp"
       mem_limit: 1g
       networks:
           esnet:
               ipv4_address: 172.30.20.1
       extra_hosts:
           - "doc-elastic101:172.30.10.1"
       depends_on:
           - elasticsearch1

volumes:
   elasticsearch1-data:
       driver: local

networks:
   esnet:
       external: true

​3. ログ取り込み

Dockerを立ち上げると、以下URLからElasticSearchの管理画面に入れます。

http://localhost:5601

メニュー Analytis > Machine Learning > Upload File　からログファイルの取り込みができます。ここにハニーポットで集めたログを適当につっこみます。

4. 可視化

メニュー Analytics > Dashboardから先ほど取り込んだログをいい感じに可視化します。必要な情報をドラッグ＆ドロップでグラフ化できました。

アクセスログです。ロシアからありえないほどアクセスが来ていました。

ログの取り込みを自動化したり、グラフの見せ方を工夫したりこだわるところはいくらでもありそうですが、ひとまず環境ができました。

Dionaea調査

ログを見てみると、あるタイミングで、Dionaeaの初期化処理が止まらなくなっていました。これが原因のようです。

#/opt/dionaea/var/log/dionaea/dionaea.log

[28012022 21:36:02] connection /opt/dionaea/src/connection_tcp.c:206-debug: can recv 212 bytes
[28012022 21:36:02] connection /opt/dionaea/src/connection_tcp.c:211-debug: io_in: throttle can 212 want 212
[28012022 21:36:02] connection /opt/dionaea/src/connection.c:1850-debug: connection_throttle_update con 0x55feed2a4c00 thr 0x55feed2a5010 bytes 211
[28012022 21:36:02] connection /opt/dionaea/src/connection_tcp.c:255-debug: EAGAIN
[28012022 21:36:02] python /opt/dionaea/modules/python/module.c:853-debug: traceable_io_in_cb con 0x55feed2a4c00 ctx 0x7fb8da7797e0 data 0x55feee974cc0 size 211
[28012022 21:36:02] sip /dionaea/sip/__init__.py:45-warning: Cleanup
[28012022 21:36:02] sip /dionaea/sip/__init__.py:45-warning: Cleanup
[28012022 21:36:02] sip /dionaea/sip/__init__.py:45-warning: Cleanup
[28012022 21:36:02] sip /dionaea/sip/__init__.py:45-warning: Cleanup

直前に接続していたIPアドレスから、攻撃の内容を探ってみます。

Dionaeaは、通信の内容をバイナリデータとして捕捉しているため、攻撃の流れを確認することができます。

cd /opt/dionaea/var/lib/dionaea/bistreams/2022-01-28
ls -lat | grep xx.xx.xx.xx

MongoDBに対して攻撃を受けていました。保存されていた一連のバイナリデータを復元してみます。

HELP

SO?G×÷º,îê²`~óý{¹ÕÈwæÄÛ<=Ûoïn(
fedcba`	
*%àCookie: mstshash=beio

ieU§ärandom1random2random3random4/
9ÿ0
,*
qjn0k¡¢
¤^0\ P¢NM£0 ¡0krbtgtNM¥19700101000000Z§¹Ù¨0
¤ÿSMBr@@PC NETWORK PROGRAM 1.0MICROSOFT NETWORKS 1.03MICROSOFT NETWORKS 3.0LANMAN1.0LM1.2X002SambaNT LANMAN 1.0NT LM 0.12
l
GET /nice%20ports%2C/Tri%6Eity.txt%2ebak HTTP/1.0


default

0-c$

dobjectClass0
0`
OPTIONS sip:nm SIP/2.0
Via: SIP/2.0/TCP nm;branch=foo
From: <sip:nm@nm>;tag=root
To: <sip:nm2@nm2>
Call-ID: 50000
CSeq: 42 OPTIONS
Max-Forwards: 70
Content-Length: 0
Contact: <sip:nm@nm>
Accept: application/sdp


à
DmdTÿÿ
:/@=/@
JRMIK
ýÎú° MMSððððNSPlayer/9...98; {AA-A-a-AAA-AAAAA}àmß_
Z6,ÿ :æ(CONNECT_DATA=(COMMAND=version))
4(ÿUMSSQLServerH

GIOP$abcdefget
+<Mÿÿnonebeio

#ST

A:0ÿÿÿÿÔtest.$cmdÿÿÿÿserverStatusð?
nbeio


GET / HTTP/1.0


OPTIONS / HTTP/1.0


OPTIONS / RTSP/1.0


(rþ |
versionbind

文字コードが合ってないのか、あえてめちゃくちゃな文字を送ってきているのか、わかりませんが概要は掴めます。

"A:0ÿÿÿÿÔtest.$cmdÿÿÿÿserverStatusð? nbeio"の直後に出力の記録があり、

d:0@cursor+idnstestfirstBatchok

と返事をしています。MongoDBに明るくないのでいけませんが、ここで攻撃がささっている感じがします。

が、

...うーん、Dionaeaの不具合の可能性もあるのではっきりとはわかりません。もう少し調査が必要そうです。時間の都合もあるので、今回はこの辺りにしておきます。

まとめ

ログ解析の環境はできましたが、目標としていたハニーポットが暴走した原因を突き止めることはできませんでした。

調査の中で、ハニーポットが想定以上に細かくログを残してくれていることがわかり、解析欲を刺激されました。有益な情報を効率よく集めるには、大量のデータを捌く工夫が必要そうです。いままで身につけた技術を総動員して、さらに深掘りしていきます。

EOF