株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

Kaspersky製品ナレッジ 第48回 ~疑似ランサムウェアを用いたKaspersky Endpoint Security for Linuxのアンチクリプター検証~

皆様、こんにちは。カスペルスキー製品担当SEの小池です。

前回、Windows Serverをファイルサーバーとして利用している場合におけるランサムウェア対策として、Kaspersky Security for Windows Serverのアンチクリプターを紹介いたしました。
blogs.networld.co.jp
今回は前回のLinux版とでもいうべき機能である、Kaspersky Endpoint Security for Linuxにおけるアンチクリプターを紹介・検証致します。
SMB もしくは NFSで共有領域を提供しているLinuxにおいて、その共有領域をアンチクリプターから保護するのに大変有効な機能です。

今回の内容は以下の通りです。

今回の記事は以下のバージョンにて検証し、画面ショットを取得しております。
●管理サーバー
 OS:Windows Server 2019
 DB:Microsof SQL Server 2017 Express (KSCと同居)
 Kaspersky Security Center:13.1.0.8324
 Kaspersky Security Center Web Console:13.1.918
●保護対象デバイス
 CentOS 8
●保護製品
 Kaspersky Endpint Security for Linux : 11.1.0.3013
●利用ライセンス
 Kaspersky Endpoint Security for Business - Advanced Japanese Edition.

1. KESLのアンチクリプター概要

KESLのアンチクリプターとは、LinuxおいてSMB / NFS プロトコルでネットワークアクセスされるローカルディレクトリのファイルを、悪意のあるリモートでの暗号化から保護する機能です。
オンラインヘルプはこちら

上の一行説明を超簡単な図にしました。(ほぼ前回の図の使いまわしですみません…。)
f:id:networld-blog-post:20210926145623p:plain

設定は以下の項目で構成されています。

  • アンチクリプターによる保護:アンチクリプターのON/OFF。デフォルトではOFF。
  • 保護範囲:アンチクリプターの保護範囲の設定。ローカルパスを直接指定する、NFSやSMBで共有している領域を明示的に指定する、そのサーバーで共有している領域すべてを対象とする、のいずれかから設定できます。
  • 信頼されていないホストのブロック:暗号化を仕掛けてきたデバイス (上の図でいうと②の端末) をブロックするかしないかの設定。また、そのブロックする期間 (分) を設定する。
  • 除外:アンチクリプター機能の保護範囲から除外する設定項目。ローカルパスを直接指定する、特定のマウント領域を指定する、全マウント領域を指定する、のいずれかから設定できます。
  • マスクによる除外:領域ではなくオブジェクト単位で除外する設定項目。アスタリスクなどのワイルドカードを使用できる。

f:id:networld-blog-post:20210926145756p:plain
注意事項として、本機能でサポートしているSambaとNFSが明確に決まっています
2021/9/25現在、KESL11.2.0のアンチクリプターは、SMB1、SMB2、SMB3、NFS3、TCP / UDP、および IP / IPv6 のプロトコルにおいて適切に動作するそうです。
逆にNFS2、NFS4はサポート外とのことです。個人的には、じゃあSMB4はどうなんだと言いたいところですが…。
サポートするプロトコルに関するオンラインヘルプはこちら

2. KESLのアンチクリプターを利用できるライセンス

2021/9/25現在、KESLのアンチクリプターを利用できるライセンスは以下の通りです。

  • Kaspersky Endpoint Security for Business Select
  • Kaspersky Endpoint Security for Business Advanced
  • Kaspersky Hybrid Cloud Security - サーバー
  • Kaspersky Hybrid Cloud Security - CPU
  • Kaspersky Hybrid Cloud Security Enterprise - サーバー
  • Kaspersky Hybrid Cloud Security Enterprise - CPU

3. KSCで統合管理している場合

この章では対象となるLinuxに導入しているKESLをKSCで統合管理している場合における、アンチクリプターの有効化と設定手順について記載します。
KSCで統合管理している場合と、KESLをスタンドアロンで利用している場合では手順が異なるので、スタンドアロンでKESLを利用している場合は次の第4章をご参照ください。

3.1. KESLのアンチクリプターの有効化(KSC利用時)

KSCで統合管理しているKESLでアンチクリプター機能をONにしたい場合は、KESLのポリシーから設定できます
Webコンソールの[デバイス]>[ポリシーとプロファイル]からKESLのポリシーをクリックします。
(下の画面にはKESL11.1.0とKESL11.2.0のポリシーがありますが、今回はKESL11.2.0のほうで手順を紹介します。)
f:id:networld-blog-post:20210926150133p:plain
[アプリケーション設定]タブ>[先進の脅威対策]>[アンチクリプター]をクリックします。
f:id:networld-blog-post:20210926150142p:plain
"アンチクリプターによる保護" を有効にし、併せて "強制適用" を有効にし、[OK]をクリックします。
f:id:networld-blog-post:20210926150152p:plain
[保存]をクリックします。
f:id:networld-blog-post:20210926150201p:plain
これでKSCで統合管理している場合における、アンチクリプターの有効化手順は完了です。
続けて設定を行います。

3.1. KESLのアンチクリプターの設定(KSC利用時)

アンチクリプターを有効化した時と同様に、KESLポリシーの[アプリケーション設定]タブ>[先進の脅威対策]>[アンチクリプター]を開きます。
f:id:networld-blog-post:20210926150250p:plain
保護範囲はデフォルトで "すべての共有ディレクトリ" となっています。
したがってアンチクリプター機能を有効にしただけだと、そのLinuxでSMBやNFS等で共有している領域全部がアンチクリプターの保護対象となります。
既定の設定は削除できますし、ほかに追加も可能です。
必要に応じて変更・追加・削除してください。
f:id:networld-blog-post:20210926150310p:plain
次に、信頼されていないホストのブロックについては、デフォルトで有効になっていて、ブロック時間は30分となっています。
なお、あらかじめ特定のホスト (運用端末等) を除外しておくことはできません
f:id:networld-blog-post:20210926150443p:plain
次に除外範囲です。
オブジェクト単位ではなく、ディレクトリやマウントポイントで除外したい場合はこの設定項目を使います。
f:id:networld-blog-post:20210926150515p:plain
最後にマスクによる除外です。
こちらは前の除外範囲と異なり、オブジェクト指定で除外したい場合に用います。
アスタリスクなどのワイルドカードが使用できるので、ファイル名に特定の文字列を含む等の条件も指定可能です。
f:id:networld-blog-post:20210926150527p:plain
以上がKSCで統合管理している場合における、アンチクリプターの設定でした。

4. スタンドアロンで利用している場合

この章では、KESLをスタンドアロンで運用している場合における、アンチクリプターの有効化と設定について記載します。KSCで統合管理している場合は手順が異なるので、KSCを利用している場合は前章の第3章をご参照ください。

4.1. KESLのアンチクリプターの有効化

KESLをスタンドアロンで運用している場合、アンチクリプターの有効化はkesl-controlコマンドで実施します
対象のLinuxに管理者権限でログインし、以下のコマンド実行してアンチクリプターの状態を確認します。

# kesl-control --get-task-state 13
f:id:networld-blog-post:20210926153025p:plain

続けて以下のコマンドを実行してアンチクリプターを開始します。
# kesl-control --start-task 13
f:id:networld-blog-post:20210926153101p:plain

再度アンチクリプターのステータスを確認します。
今度は開始されていることが確認できます。
# kesl-control --get-task-state 13
f:id:networld-blog-post:20210927091854p:plain
以上がスタンドアロンでKESLを使用している場合におけるアンチクリプターの有効化手順です。

4.2. KESLのアンチクリプターの設定

続けてアンチクリプターの設定コマンドについて記載します。
いつものことですが、ここでもkesl-controlコマンドの嵐です。
まず以下のコマンドを実行して現在の設定状況を確認します。

# kesl-control --get-settings 13
f:id:networld-blog-post:20210926153346p:plain
上の画面の出力について補足します。

  • UseHostBlocker:信頼されていないホスト (暗号化の攻撃を仕掛けてきたホスト) をブロックするかしないかの設定。
  • BlockTime:上のUseHostBlockerを有効にしている場合において、何分ブロックするかの設定。単位は分。
  • UseExcludeMasks:これはちょっとわかりにくいのですが、デフォルトでは存在しない "ExcludeMasks" (保護範囲から除外されるオブジェクトを定義するマスクのリスト) という項目が存在していて、これを利用するかしないかの設定です。
  • [ScanScope.item_0000]:アンチクリプターによる保護領域設定の1個目の意。保護対象領域の設定が増えると、末尾4桁が1ずつ増えていく。これより下の設定はすべて、この保護領域に関する設定。
    • AreaDesc:保護領域の名前。任意文字列を指定できる。
    • UseScanArea:1つ下にある項目 "Path" に設定された保護領域設定を使うか使わないかの設定。
    • Path:アンチクリプターによって保護したい領域の設定。AllSharedならSMB or NFSを使用してアクセスされるすべてのリソースが対象となる。
    • AreaMask.item_0000:こちらは、保護領域設定の中で、さらに保護対象を任意のオブジェクトのみに限定したい時に使用できるマスク設定です。デフォルトではすべてのオブジェクトが保護対象となっているので "*" が設定されています。

他、今回画面に出てこなかった各パラメーターはこちらのオンラインヘルプをご参照ください。

このデフォルト値から設定を変更したい場合は --set-settings オプションを使いますが、具体的な設定値をコマンドオプションで指定するか、あるいは設定ファイルを作ってそれを読み込むかの2通りがあります。
一応どちらも紹介いたします。

まず、具体的な設定値をコマンドオプションで指定する場合、以下のようなコマンドで設定します。

# kesl-control --set-settings 13 <key>=<value>
例として、ブロック時間を30分から120分に変更するには以下のようなコマンドになります。
# kesl-control --set-settings 13 BlockTime=120
f:id:networld-blog-post:20210926154845p:plain

もう1つの方法である、設定ファイルを作ってそれを読み込む場合。
まずは以下のコマンドで設定をエクスポートします。
# kesl-control --get-settings 13 --file <任意ファイルパス>
f:id:networld-blog-post:20210926155100p:plain
出力した設定ファイルをコピーして、オンラインヘルプを見つめながら頑張って編集します。
今回は以下の要件があると勝手に仮定して設定してみました。

  • デフォルトの設定はそのまま変更しない。
  • 全保護領域に共通で適用される除外設定を1個追加し、これを有効にする。
  • 除外設定は以下の要件に従う。
    • 除外設定名は "20210925add JOGAI" にする。
    • 除外パスは "/nfs/jogai1" にする。
    • 除外パスの中にある全オブジェクトを除外対象とする。

上の要件だとこんな設定ファイルになります。これを保存します。
f:id:networld-blog-post:20210926155204p:plain
先ほど頑張って作成した設定ファイルを以下のコマンドで反映させます。

# kesl-control --set-settings 13 --file <先ほど頑張って作成した設定ファイル>
f:id:networld-blog-post:20210926155237p:plain
続けて以下のコマンドで設定が反映されていることを確認します。
# kesl-control --get-settings 13
f:id:networld-blog-post:20210926155300p:plain
ちょっと長くなりましたが、以上がKESLをスタンドアロンで利用している場合におけるアンチクリプターの設定手順でした。

5. 疑似ランサムウェアを用いた検証

さて、ここからはGitHubから拝借した疑似ランサムウェアを用いて、KESLのアンチクリプターがちゃんと機能するのかを確認します
なお結果だけご覧になりたい方は、本記事の一番最後の章をご参照下さい
この検証は、アンチクリプターを有効にする以外はすべてデフォルトの設定 (下図参照) のまま実施しました。
f:id:networld-blog-post:20210926155518p:plain

検証したシナリオの図は以下の通りです。攻撃元のデバイスはWindowsで検証しました。
f:id:networld-blog-post:20210927092244p:plain

攻撃元のマシンで、攻撃対象のファイルサーバーのexport領域をマウントします。
f:id:networld-blog-post:20210926155626p:plainf:id:networld-blog-post:20210926155632p:plain

NFSで共有された領域にはテキスト20個を格納しました。今はテキストを正常に閲覧できます。
f:id:networld-blog-post:20210926155704p:plain

事前準備ができたら、マウントした領域に対して暗号化を試行します。
f:id:networld-blog-post:20210926155738p:plain

暗号化を試行して間を置かずに、攻撃側でZドライブとしてマウントしていた領域が使えなくなりました。これはKESL側で攻撃元デバイスをブロックしたためです。
f:id:networld-blog-post:20210926155907p:plain

Linux側からNFSで共有していた領域の暗号化状態を確認します。
どうやら20個あるファイルのうち10個だけ暗号化されたようです。
(被害程度が軽度であることをアピールするためにテストファイルもっと増やせばよかったです…。失敗しました…。)
f:id:networld-blog-post:20210926160031p:plain

信頼されていないホストの一覧を確認してみます。
kesl-controlの以下のコマンドを実行します。(KSCからはイベントで確認することができます。)

# kesl-control --get-blocked-hosts
f:id:networld-blog-post:20210926160107p:plain

後でイベントをまとめて確認したいので、この検証では先にブロック解除してみます。
ブロック解除が以下のコマンドです。(KSCからはブロックされているホストのブロック解除はできません。)
# kesl-control --allow-hosts <前のコマンドの出力のホスト行の値>
f:id:networld-blog-post:20210926160217p:plain

再度、以下のコマンドでブロックされているホストの一覧を確認すると、0件になったことがわかります。
f:id:networld-blog-post:20210926160235p:plain

ブロックの解除コマンドを実行後に、攻撃元デバイスからネットワークドライブの状態を確認すると、通常通り接続できていることがわかります。
f:id:networld-blog-post:20210926160322p:plain

ここまでで暗号化の検知KESLによるブロックブロック解除までを確認できました。
最後にどういったイベントが発生しているかを確認します。

KSCで統合管理している場合は、Webコンソールの[監視とレポート]>[イベントの抽出]>[最近のイベント]をクリックします。
f:id:networld-blog-post:20210926160505p:plain
f:id:networld-blog-post:20210926160605p:plain
上の図より、ホストブロックのイベント、ホストブロック解除のイベント、暗号化の検知イベントが発生していることが確認できます。
ただ…複数回検証したところ、なんと暗号化の検知イベントの発生数は、実際に暗号化されたファイル数とは数が合いませんでした。。。
具体的には3回検証して3回とも、実際に暗号化されたファイル数より暗号化の検知イベントの方が少ないという結果でした。
暗号化される側で、暗号化されたファイルを正確に検出するのは難しいのかな…。
なお、下の画面では暗号化の検知イベントがブロック解除の後に出ていますが、これは私が諸事情で複数回暗号化を試行したことが原因です。本来であればブロック解除より前に暗号化の検知イベントが発生します。見にくくなってしまい申し訳ありません。こういったイベントが発生するんだなという参考程度にご参照いただければと存じます。

それぞれのイベントの詳細の例は以下の通りです。
ブロックのイベント本文とブロック解除のイベント本文には、対象ホストの情報が含まれていることがわかります。
暗号化検知のイベント本文には、暗号化されたファイル名が含まれていることがわかります。
f:id:networld-blog-post:20210926160743p:plain

スタンドアロンで利用している場合はkesl-controlで確認できます。
発生しているイベントはKSCで統合管理している場合と同じ内容です。
イベントを確認するコマンドは -E オプションなのですが、これを実行すると大量のイベントが表示されるので、アンチクリプターのID13を指定して実行します。
# kesl-control -E --query "TaskId == '13'"
f:id:networld-blog-post:20210926160820p:plain

出力結果から、ホストブロックのイベント、暗号化の検知イベント、ブロック解除のイベントをピックアップして紹介します。
ホストブロックのイベントがこちら。
f:id:networld-blog-post:20210926160840p:plain

次に、暗号化の検知イベントがこちら。
なお、KSCで統合管理している場合と同様に、kesl-controlで確認できるイベントにおいても、暗号化の検知イベントは実際に暗号化されたファイルの数より少なかったです。
f:id:networld-blog-post:20210926160854p:plain

最後にブロック解除のイベントがこちら。
f:id:networld-blog-post:20210926160919p:plain

長くなりましたが、以上で疑似ランサムウェアを用いた検証を用いた検証は完了です。

5.1. 検証の結果

結果は以下の通りでした。

  • NFSでexportした領域に対して別のデバイスから暗号化を試行し、それを検知できた。(NFS3)
  • 暗号化の検知後、攻撃元デバイスをブロックする機能が正常に動作した。
  • ブロックされた攻撃元デバイスを、kesl-controlコマンドを用いてブロック解除することができた。
  • 攻撃元のデバイスをブロックしたイベント、暗号化を検知したイベント、攻撃元デバイスのブロックを解除したイベントを、KSCおよびkesl-controlで確認できた。
  • ただし、暗号化の検知イベント数は実際に暗号化されたファイルの数とは一致しなかった (暗号化の検知イベント数 < 実際に暗号化されたファイル数)。


今回はKaspersky Endpoint Security for Linuxのアンチクリプターの概要と検証を記載しました。
前回のKaspersky Security for Windows Serverのアンチクリプターに続く、ランサムウェア対策機能の紹介となりましたがいかがでしたでしょうか。
今回も検証によりランサムウェアによる被害を最小限にできることを証明できたと思います。(サンプルファイルを20個ではなく2000個くらい用意したほうがわかりやすかったですよね…本当にすみません…。)
1点だけ要注意なことは、サポートしているプロトコルを事前にご確認いただきたいという点です。
Linuxでexportで共有している領域があり、且つ、サポートしているプロトコルを使っているのであれば、本機能は大変有用かと存じます。
Linuxで共有領域があるサーバーにおけるランサムウェア対策の1つとしてご検討いただけますと幸いにございます。

この度は最後まで記事をご覧いただき誠にありがとうございました。
記載事項へのご指摘、ご不明点、ご質問等ございましたら、以下からご連絡いただければと存じます。
https://www.networld.co.jp/product/kaspersky/

それでは次回の記事でお会いしましょう!