IBM Log Analysis with LogDNA を使って IBM Cloud Flow Logs for VPC で取得したVPCのネットワークトラフィックを分析する

記事をシェアする:

この投稿は、2020年07月29日に、米国 IBM Cloud Blog に掲載されたブログ(英語)の抄訳です。

 

Flow logs for VPC を利用することでネットワークトラフィックの監視や、接続に関するトラブルシューティングが可能です。

IBM Cloud Flow Logs for VPC は、VPC内のVSIに対するネットワーク・インターフェースに対してアクセスログを取得し、IBM Cloud Object Storage (COS) に保管します。

Flow Logsを使うことで、以下のような疑問を解決できるようになります。

• VSIの予期しないTCPポートにアクセスされていないか？
• SSHは VPC に到達しているが、リジェクトされていないという問題が起きていないか？
• 悪意ある人が自分のネットワークにアクセスしようとしていないか？

COSに保管されたデータは、他のツールに取り込むことも可能です。本記事では、IBM Log Analysis with LogDNA にデータを取り込んで分析する方法をご紹介します。

 

 

VPC Flow Log をLogDNAに転送する

始める前にLogDNAインスタンスを作成し、プラットフォームログを有効化しておきます。これにより、このあとのセクションでデプロイした関数の呼び出しが、プラットフォームログに表示されるようになります。

 

サンプルコードのデプロイ

ブラウザで IBM Cloud にログインし、右上のシェルアイコンからIBM Cloud Shell を開きます。

ソースコードはGitHubで公開（IBM外のサイトへ）されています。ソースコードには、Cloud Object Storage をセットアップし、IBM Cloud Functions のトリガーとアクションを展開するためのスクリプトが含まれています。詳細な説明は README を参照してください。

Cloud Shell に以下のように入力します。


git clone https://github.com/IBM-Cloud/vpc-flowlogs-logdna
cd vpc-flowlogs-logdna


“local.env” ファイルを作成し、編集します。

cp template.local.env local.env
edit local.env
source local.env
# verify PREFIX and TF_VAR_ssh_key_name are in the environment by using the env command


このあとの操作には IBM Cloud CLI、Cloud Object Storage プラグイン、Cloud Functions プラグイン、Schematics プラグイン、および jq コマンドが必要ですが、Cloud Shell にはデフォルトでインストールされているので特にアクションは不要です。

“000-prereqs.sh”と”010-create-services.sh”の2つのファイルを実行します。

“000-prereqs.sh” は、ターゲット・リソース・グループ、ターゲット・リージョン、必要な IBM Cloud プラグイン、および外部ツールに関する基本的なチェックを実行します。

“010-create-services.sh” は、Cloud Object Storage サービス、バケット、および LogDNA サービスを作成します。また、サービスキーも設定します。サービスキーは、Cloud Functions アクションが COS および LogDNA サービスにアクセスするために使用されます。

 

成功すると以下のようにCOSのバケットとLogDNAインスタンスが作成されます。

COS：

 

LogDNA：

 

次に”020-create-functions.sh”を実行し、Cloud Functionsの設定をします。Cloud FunctionsとCloud Object Storageの間に認証を作成し、Cloud FunctionsがCOSから通知を受けられるようにします。次に、Flow LogsがCOSバケットに追加されたときにログアクションが開始されるようCloud Functions のトリガーとアクションを作成します。アクションはPythonで書かれており、action/__main__.pyというファイルで用意されています。スクリプトが終了したら、IBM Cloud コンソール から Cloud Function のトリガー を開き、上部のドロップダウンメニューから適切なネームスペースを選択します。また、左のナビゲーションから Actions パネルを確認してください。

以下のようなトリガーとアクションが作成されています。

 

“030-create-vpc.sh”を実行し、VPC、サブネット、インスタンス、Flow Logs コレクターを作成します。IBM Cloud Schematics サービスの Terraform を使用してVPCやサブネットを作成し、ibmcloud cli を使用してFlow Logs コレクターを作成します。スクリプトが完了したら、IBM Cloud コンソールでFlow Logsコレクターの設定を確認します。

 

Flow Logs：

数分待つと、COSバケットにFlow Logsが保管されるようになります。さらに数分後には、関数ログの呼び出しがLogDNAのプラットフォームログに表示されるようになり、Flow Logsが他のLogDNAインスタンスから参照できるようになります。

“030-create-vpc.sh”を実行したときに表示される最後の数行は以下のようになります。これらをコピーしておいてください。

 

LogDNAによる分析

はじめに

curl 52.116.136.250:3000/info を実行すると、vsi1 のプライベート IP アドレス、つまり 10.240.0.4 が出力されます。
curl 52.116.136.250:3000/remote を実行すると、パブリックインスタンス内からプライベートインスタンスをcurlし、vsi1のプライベートIPアドレスを表示します（プライベートです）。

悪意のあるレコードを探す

IBM Log Analysis with LogDNA ページを開き、インスタンスの横にある View LogDNA リンクをクリックしてダッシュボード画面を開きます。

Everything ビューで、target_ip:10.240.0.4 action:rejected となっているログを探してみましょう。

かなりの数のレコードがあるため、さらに検索をtarget_port:443に絞り込んでましょう。すると、 initiator_ipアドレスが92.63.197.61というレコードが見つかりました。

このIPアドレスは想定外のもので、悪意のある業者によるアクセスである可能性が高いことがわかりました。

 

期待しているトラフィックを探す

上記のcurlコマンドを実行してから数分経つと、いくつかのトラフィックが受け入れられているはずです。LogDNAダッシュボードでtarget_ip:10.240.0.4 action:accepted を検索します。target_port が 3000 であることに注目してください。

プライベート インスタンスではトラフィックが少なくなっています。target_ip:10.240.64.4 を試してみると、数パケットしか表示されないかもしれません。initiator_ip:10.240.64.4 を試すと、かなりの数のパケットが表示されます。これは何を意味しているのでしょうか？

レコードの一つを見てみると、target_port:67というのがあり、これはbootpプロトコルのためのものです。これは大丈夫そうなので、これをフィルタリングしてもっと見てみます。
initiator_ip:10.240.64.4 -target_port:67。さらにこの処理を続けてみると、次のようになっていることに気づきました。

• Port 67: Bootp
• Port 123: NTP
• Port 53: DNS
• Port 443: HTTPS
• Port 80: HTTP

443 と 80 ポートの target_ip アドレスを見て、それらが会社が承認したソフトウェアプロバイダであることを確認し、そうでない場合はアラームを設定してもよいでしょう。セキュリティグループやネットワークACLを変更して、より制約の多いものにすべきかもしれません。

 

SSHできない場合

私のPCでは、curl ifconfig.meを実行して自分のIPアドレスを取得しました。

$ curl ifconfig.me
24.22.68.94

LogDNAでは、次のように検索してください。 target_ip:10.240.0.4 target_port:22 initiator_ip:24.22.68.94。

action:rejectedというパケットが見つかりました。

私のPCからVSIへのネットワークは通っているようですが、なぜ拒否されているのでしょうか？

これは、セキュリティ・グループ・ルール、もしくはネットワークACLが原因である可能性が高いです。IBM Cloud ConsoleでVPCインスタンスに移動し、vsi1インスタンスをクリックして、ネットワーク・インターフェースに接続されているセキュリティ・グループを調べます。Security Groups をクリックすると、install-software グループはソフトウェアをインストールするためのもので、sg1 は外部アクセス用のものですが、ポート 3000 にのみ接続されていることがわかります。これはcurlコマンドで使われているポートです。ポート22へのアクセスはありませんので、これが拒否の原因になっている可能性が高いです。

x-sg1のセキュリティグループページのInbound rulesで、New ruleボタンをクリックして、新しいルールを追加します（プロトコル：TCP、ポートの範囲：22、22）。解決できたか確認するために、もう一度sshを試してみてください。フローログで action:accepted を探します。

 

More investigation

IBM Log Analysis with LogDNAを使ってFlow Logsを調べれば調べるほど、疑問が出てくるでしょう。自分のアプリケーションに必要な通信経路をしっかりと理解し、害を及ぼす可能性のあるパケット・フローを慎重に制約する必要があります。

LogDNAでは、ダッシュボードやアラームを作成することができます。例えば、VPC内のインスタンスへのsshアクセスが成功したときに、いつでもSlack経由で通知されるようにしたいと思うかもしれません。検索ボックスで検索条件を絞り込んで、興味のあるレコードを見つけます。右上隅で、Unsaved View のドロップダウンをクリックし、save as new view/alert を選択します。ポップアップで、Alert > View specific alert を選択し、Slack または他の通知方法のいずれかをクリックします。

 

まとめ

IBM Cloud Flow Logs for VPC は詳細なトラフィック・ログを提供し、IBM Log Analysis with LogDNA はネットワーク・トラフィックを検索できます。リアルタイムのアラート通知により、ネットワーク・アクセスを監査することも可能です。

VPC の詳細については、ソリューション・チュートリアルを参照してください。 LogDNA Slackアラートの詳細な説明については、こちら（英語）をご覧ください。

 

---

翻訳：IBM Cloud Blog Japan 編集部