皆様、こんにちは。カスペルスキー製品担当SEの小池です。
第39回のブログにて、Kaspersky Endpoint Security for Linux にDockerコンテナスキャン機能概要とオンアクセススキャン検証について記載しました。
今回はこの続きで、Kaspersky Endpoint Security for LinuxのDockerコンテナスキャンにおけるオンデマンドスキャン機能の検証をしました。
今回の内容は以下の通りです。
- KESLのDockerコンテナスキャン機能概要
- Dockerコンテナスキャンの設定 (オンデマンドスキャン)
- 検証 (オンデマンドスキャンで検知＋駆除または削除させる場合)
- 検証 (オンデマンドスキャンで検知＋コンテナ停止させる場合)
- 検証 (オンデマンドスキャンでイメージをスキャンする場合)
- 余談 : KESL11.1のコンテナオンデマンドスキャンタスクでエラー"不明なエラー" が出る場合
- 余談 : 除外設定
- 本機能の利用を検討なさっている方へ
今回の記事は以下のバージョンにて検証し、画面ショットを取得しております。
●管理サーバー
OS：Windows Server 2019
DB：Microsof SQL Server 2017 Express
Kaspersky Security Center：13.0.0.111247
Kaspersky Security Center Web Console：13.0.10285
Kaspersky Endpoint Security 11.1.0 for Linux のプラグイン：11.2.0.136
●保護製品
Kaspersky Endpoint Security for Linux 11.2.0.4528
●Docker環境
Red Hat Enterprise Linux 8.4 (Ootpa)
●利用ライセンス
Kaspersky Hybrid Cloud Security Enterprise, CPU Japanese Edition.
KESLのDockerコンテナスキャン機能概要
KESLをインストールしたDockerホストにおいて、コンテナ、イメージ、および名前空間を、ウイルスやその他のマルウェアがないかどうかスキャンできる機能です。
スキャン方法はオンアクセススキャン (リアルタイム) とオンデマンドスキャン (定期的) の２通りがあります。
- オンアクセススキャン (リアルタイム)：ポリシーで有効無効を設定する。起動中のDockerコンテナをスキャンすることが可能で、脅威発見時は削除や駆除だけでなく、コンテナの停止も可能。
- オンデマンドスキャン (定期的)：タスクで設定 及び 実行する。起動中のコンテナのスキャンだけでなく、イメージのスキャンも可能。脅威発見時は駆除、削除、コンテナの停止のほか、イメージの場合はイメージの自動削除も可能。専用のCLIがあるのでCICDとの連携も可能。スキャン対象のコンテナおよびイメージをマスク (*や?) で限定することが可能。
各スキャン方法の概要については第39回のブログにて記載しておりますので、そちらをご参照ください。
Dockerコンテナスキャンの設定 (オンデマンドスキャン)
KESLによるDockerコンテナのンデマンドスキャンを実施したい場合は、タスクを作成します。
KSCのWebコンソールから、[デバイス]>[タスク]を開き、[+追加]をクリックします。
アプリケーション欄で [Kaspersky Endpoint Security 11.2.0 for Linux] を選択し、タスク種別を [コンテナのスキャン] にします。
タスク名と、デバイスの選択は任意に設定してください。
ここでは以下の通り、タスク名を "コンテナのスキャン"、範囲を "管理グループにタスクを割り当てる" にします。
[次へ]をクリックします。
対象となるグループを選択し、[次へ]をクリックします。
"タスクの作成が完了したらタスクの詳細を表示する" にチェックを入れ、[終了]をクリックします。
詳細画面が表示されたら、[アプリケーション設定]>[スキャン設定]を開きます。
画面を下までスクロールすると、"コンテナのスキャン設定" と "イメージのスキャン設定” という項目があります。
ここでコンテナのスキャン設定やイメージのスキャン設定をします。
コンテナのスキャンについては、デフォルトで有効 且つ すべてのコンテナが対象となっています。
”コンテナのスキャン" のチェックボックスを有効/無効にすることで、コンテナのスキャンをする/しないを指定できます。
次に "名前のマスク" でスキャンの対象となるDockerコンテナ名を指定できます。*や?等のワイルドカードを使えるため、対象となるコンテナを絞り込むことができます。
最後に "驚異の検知時の処理" で、脅威検知時の処理を指定できます。デフォルトでは [駆除の失敗時にはコンテナを停止] となっています。
なお、この項目では "削除" について言及されていませんが、[駆除の失敗時にはコンテナを停止]を選択した場合であっても、削除の処理はされることを確認しています。(詳しくは次章の検証をご参照ください。)
おそらくですが [駆除の失敗時にはコンテナを停止] を選択した場合、 駆除または削除の失敗時にはコンテナを停止するという挙動になっているものと推測されます。(2021/8/19 KESL11.2で検証した時点。)
イメージのスキャンについては、デフォルトで有効 且つ すべてのイメージが対象となっています。
”イメージのスキャン" のチェックボックスを有効/無効にすることで、Dockerコンテナイメージのスキャンをする/しないを指定できます。
次に "名前のマスク" でスキャンの対象となるDockerコンテナイメージ名とタグを指定できます。*や?等のワイルドカードを使えるため、対象となるイメージを絞り込むことができます。
"驚異の検知時の処理" で、脅威検知時の処理を指定できます。デフォルトでは [イメージをスキップ] となっています。
最後に "全レイヤーのスキャン" の有効/無効を指定できます。デフォルトでは無効になっています。
検証 (オンデマンドスキャンで検知＋駆除または削除させる場合)
Dockerコンテナスキャン (オンデマンドセスキャン) の検証をしてみます。
この検証では下図の通り、コンテナ名のマスクを "wordpress-*"、脅威の検知時の処理を"駆除の失敗時にはコンテナを停止" に設定して検証します。
この設定だと、コンテナ名が "wordpress-" で始まるコンテナがスキャン対象となり、駆除/削除の処理ができなかった場合はコンテナを停止させます。
なお、本検証ではKESL11.2のポリシーでリアルタイム (オンアクセススキャン) による検知を無効にしております。
(オンアクセススキャンを有効にしてしまうと、オンデマンドスキャンによる検知より前にオンアクセススキャンでEicarテストファイルを検知してしまうので…。)
検証対象のDockerホストにはKESL11.2をインストール済です。
Dockerホストでは以下のコンテナが起動中です。
このうち、今回の検証のスキャン対象となるコンテナは "wordpress-sample" と "wordpress-prod" です。
それでは "wordpress-sample" にログインし、/tmp配下にEicarテストファイル "Eicar_OnDemandScanTest01.com" を作成します。
KSCのWebコンソールから、[デバイス]>[タスク]を開き、作成済のコンテナスキャンタスクにチェックを入れて[開始]をクリックします。
[リストの更新]をクリックして画面を更新します。
先ほど実行したコンテナスキャンタスクのステータスが "正常終了" になったことを確認します。
KSCでEicarテストフィルの検知と削除に関するイベントが発生しているかを確認します。
Webコンソールから[監視とレポート]>[イベントの抽出]>[最近のイベント]をクリックします。
右上の検索ボックスで、作成したEicarテストファイルのファイル名 "Eicar_OnDemandScanTest01.com" を入力してEnterキーを押下し、関連イベントをフィルターします。
今回の場合は検知メッセージ、駆除不可のメッセージ、削除のメッセージの3つが発生していました。
(Eicarテストファイルは駆除が不可能なので、このような挙動になります。)
発生していたイベントの詳細は以下の通りです。
ちゃんとコンテナ名とファイル名がイベント文言に含まれているので、わかりやすいかと存じます。
Eicarテストファイルが検知されたコンテナ "wordpress-sample" の状況を確認しましょう。
まず、起動状況ですが、docker psコマンドで確認するとコンテナ "wordpress-sample" は起動中のままです。
これは今回、検知した脅威 (Eicarテストファイル) を正常に削除できたので、コンテナ停止には至らなかったためです。
コンテナ "wordpress-sample" にログインし/tmp配下を確認すると、検証用に作成したEicarテストファイル (Eicar_OnDemandScanTest01.com) が削除されていることがわかります。
以上のことから、オンデマンドスキャンで対象コンテナを処理 "駆除の失敗時にはコンテナを停止" でタスクを実行した場合は以下の通りとなることが確認できました。
- 脅威を検知し削除/駆除することができる。 (想定通り)
- 脅威を正常に削除/駆除できた場合は、コンテナを停止させない。(想定通り)
なお、削除/駆除できなかった場合については今回は検証しておりません。
検証 (オンデマンドスキャンで検知＋駆除または削除させる場合) は以上です。
検証 (オンデマンドスキャンで検知＋コンテナ停止させる場合)
オンデマンドスキャンによるコンテナのスキャン検証の2つ目です。
コンテナスキャンタスクで下図の通り、コンテナ名のマスクを "wordpress-*"、脅威の検知時の処理を"コンテナを停止" に設定して検証します。
なお、前章の検証と同様、本検証でもKESL11.2のポリシーでリアルタイム (オンアクセススキャン) による検知を無効にしております。
(オンアクセススキャンを有効にしてしまうと、オンデマンドスキャンによる検知より前にオンアクセススキャンでEicarテストファイルを検知してしまうので…。)
検証対象のDockerホストにはKESL11.2をインストール済です。
Dockerホストでは以下のコンテナが起動中です。
このうち、今回の検証のスキャン対象となるコンテナは "wordpress-sample" と "wordpress-prod" です。
それでは "wordpress-prod" にログインし、/tmp配下にEicarテストファイル "Eicar_OnDemandScanTest02.com" を作成します。
KSCのWebコンソールから、[デバイス]>[タスク]を開き、作成済のコンテナスキャンタスクにチェックを入れて[開始]をクリックします。
[リストの更新]をクリックして画面を更新します。
先ほど実行したコンテナスキャンタスクのステータスが "正常終了" になったことを確認します。
KSCでEicarテストフィルの検知と削除に関するイベントが発生しているかを確認します。
Webコンソールから[監視とレポート]>[イベントの抽出]>[最近のイベント]をクリックします。
右上の検索ボックスで、作成したEicarテストファイルのファイル名 "Eicar_OnDemandScanTest02.com" を入力してEnterキーを押下し、関連イベントをフィルターします。
今回の場合は検知メッセージ、駆除不可のメッセージ、削除のメッセージの3つが発生していました。
(Eicarテストファイルは駆除が不可能なので、このような挙動になります。)
発生していたイベントの詳細は以下の通りです。
なお、今回の検証では脅威検知時にDockerコンテナを停止するという設定にしましたが、コンテナ停止のイベントが出ませんでした…。なんでじゃい。
オンデマンドスキャンではちゃんとコンテナ停止イベントが発生していたので、こちらでも発生するかなと思ったのですが。
実際にDockerコンテナは停止しているのかを確認してみます。
Dockerホストでdocker ps -aコマンドを実行すると、確かにEicarテストファイルを検知させたコンテナ "wordpress-prod" は停止していました。
オンデマンドスキャンで対象コンテナのスキャンさせ脅威発見時にコンテナ停止する場合、以下の結果になりました。
- 脅威を検知でき、脅威を検知したコンテナを停止できる。(想定通り)
- コンテナ停止イベントが出ない。
なお、コンテナ停止イベントが出ない件についてはKESL11.2特有の事象である可能性があるので、実際に本製品のオンデマンドスキャンの実装を検討なさっている場合は、評価用ライセンスで一度挙動をご確認いただければと存じます。
検証 (オンデマンドスキャンで検知＋コンテナ停止させる場合) は以上です。
検証 (オンデマンドスキャンでイメージをスキャンする場合)
最後にオンデマンドスキャンによるイメージのスキャンを検証します。
コンテナスキャンタスクで下図の通り名前のマスクを "jenkins/*:latest"、脅威の検知時の処理を "イメージをスキップ" に設定します。
この設定だと、イメージ名とタグが "jenkins/*:latest" にマッチするイメージがスキャン対象となります。
なお、本検証ではKESL11.2のポリシーで、ファイル脅威対策とコンテナのオンアクセススキャンの両方を無効にしております。
(これらを有効にしてしまうと、Eicarファイルを入れたイメージが作成できないので…。)
検証対象のDockerホストにはKESL11.2をインストール済です。
Dockerイメージは5個あり、このうち今回の検証のスキャン対象となるイメージは "jenkins/docker:latest" と "jenkins/jenkins:latest" です。
今回はスキャン対象となるイメージの1つである "jenkins/docker:latest" の/tmp配下にEicarテストファイル "Eicar_OnDemandScanTest03.com" を作成してイメージをビルドしなおします。
docker-compose.ymlは以下の通りです。(関係ないコンテナの部分は白塗りしております。)
肝心のEicarファイルはDockerFileの一番下にechoで作成するコマンドを追記しております。
この状態でBuildします。(関係のないコンテナのビルド結果については割愛しております。)
もう一度イメージ一覧を確認し、目的のイメージ "jenkins/docker:latest" が更新されたことを確認します。
一応コンテナが1つも存在しないことを確認します。
準備ができたので、コンテナスキャンタスクを実行します。
Webコンソールから[デバイス]>[タスク]を開き、イメージのスキャンを有効にしたコンテナスキャンタスクにチェックを入れ、[開始]をクリックします。
[リストの更新]をクリックして画面を更新します。
コンテナスキャンタスクのステータスが "正常終了" になることを確認します。
KSC側で発生しているイベントを確認します。
[監視とレポート]>[イベントの抽出]>[最近のイベント]をクリックします。
画面左上の検索ボックスでEicarテストファイル名 (Eicar_OnDemandScanTest03.com) で検索します。
今回の場合は検知のメッセージ、駆除できない旨のメッセージ、削除メッセージの3件がヒットしました。
各イベントの詳細は以下の通りです。
イメージ名、タグ、ファイル名がイベント本文に含まれているのがわかります。
ただ、、、タスクの設定では "イメージをスキップ" にしたので、駆除/削除は発生しない想定でした。
なお、駆除/削除に関するメッセージが出ているからと言って、イメージ内のEicarテストファイルは削除されていません。
実際に確認してみました。
まず、処理を"イメージをスキップ" に設定していたので、Eicarテストファイルを検知したイメージは削除されずに残っています。これは想定通りです。
イメージからコンテナを起動して、/tmp配下にあるEicarテストファイルがどうなったか確認すると、下の通り残っています。
これはDockerイメージの仕様として仕方ない気が致します。ですが、脅威が残るならわざわざ駆除/削除のメッセージは出さない方がよいのでは…と個人的に思います。
以上のことから、オンデマンドスキャンタスクでDockerのイメージを処理 "イメージをスキップ" にしてスキャンした場合、以下の通りであることが確認できました。
- 脅威は検知されるが、イメージは削除されない。(想定通り)
- 脅威が駆除/削除可能なものである場合、それらの処理メッセージが発生する。
- 駆除/削除に関する処理メッセージが発生しても、イメージの中に脅威ファイル自体は残っている。(想定通り)
検証 (オンデマンドスキャンでイメージをスキャンする場合) は以上です。
余談 : KESL11.1のコンテナオンデマンドスキャンタスクでエラー"不明なエラー" が出る場合
KESL11.1でオンデマンドスキャンタスクを実行した際に、"不明なエラー" というイベントが発生することがあります。(下図参照)
この場合はKESL11.2を利用することで事象を解消できる可能性があります。
(というか、このエラーが出た場合の対処法はKESL11.2以降にする以外無いっぽいです。)
余談 : 除外設定
コンテナのオンデマンドスキャンタスクで特定のファイルだけ除外したい場合は、タスクのプロパティの[アプリケーション設定]>[除外範囲]で設定します。
除外設定はマスクか脅威名で設定します。
絶対パスだけだと除外できないので、ワイルドカードを使ってマスクで表現して登録してください。
特にコンテナのオンデマンドスキャンでは多重アーカイブファイルでエラーが出ることがあるので、この除外設定を使ってうまく除外してください。
本機能の利用を検討なさっている方へ
コンテナスキャン機能の総括として、本機能の利用を検討なさっている方へ、お伝えしたほうが良いかなと思うことを記載します。
まず、第39回と今回でご紹介いたしました通り、KESLのコンテナスキャンにはオンアクセススキャンとオンデマンドスキャンがあります。
それぞれできることが異なりますので、第39回と今回の記事、およびメーカーの資料をお読みいただき、ご要望を満たすにはどちらの機能を使うのか、両方必要なのかをご確認ください。
次に、KHCS Enterpriseライセンスが必要なのか否かをご確認ください。
オンアクセススキャンのみ 且つ コンテナの特定が不要な場合はKHCS Enterpriseライセンスは不要ですが、これだと検知したときのメッセージからどのコンテナで脅威を検知したのかさっぱりわからないので、個人的にはコンテナスキャンをしたい場合はKHCS Enterpriseライセンスは必須くらいの認識でよいかと存じます。
そして、実際に評価版ライセンスを入手して期待する挙動であるかをご確認ください。
特にKSCのイベントから既存の監視ソフトウェアと連携させたい場合などは、必ず評価版ライセンスで検証いただくことをお勧めいたします。
また、評価の際はKESLは11.2以降を使いいただくことをお勧めいたします。
最後に。KESLのコンテナスキャン機能はメーカー側も開発に注力しているらしく、最近のKESLのバージョンアップには必ずと言っていいほどコンテナスキャンに関する改修や機能追加が含まれています。
本記事ではKESL11.2で検証しておりますが、今後も後続のバージョンで機能が改善・追加される可能性が高いので、改善の要求や機能の追加リクエストなどがある場合は一度メーカーに連絡してみると良いかと存じます。
今回は第39回の続きで、KESLにおけるDockerコンテナスキャン機能のオンデマンドスキャンの紹介と検証を致しました。
先述致しました通り、KESLにおけるDockerコンテナスキャン機能はKESLのバージョンを重ねるごとに良くなっています。
オンアクセススキャンとオンデマンドスキャンを使い分けることでより強固なセキュリティを確保できるかと存じますので、Docker環境の保護製品ご検討の際にはぜひKESLも候補に入れていただければと存じます。
この度は最後まで記事をご覧いただき誠にありがとうございました。
記載事項へのご指摘、ご不明点、ご質問等ございましたら、以下からご連絡いただければと存じます。
https://www.networld.co.jp/product/kaspersky/
それでは次回の記事でお会いしましょう！
