Apache Log4j問題をネットワーク観点で対策する(CVE-2021-44228)
本記事は下記URLに移動しました。
５秒後に自動的に移動します。
Javaのログ出力ライブラリ「Apache Log4j」の脆弱性問題(CVE-2021-44228)が話題になっています。
業務で対応をされている方もいらっしゃるのではないでしょうか。（お疲れ様です・・）
アプリケーション観点での対策については各所で情報があがってきているので、今回はネットワークインフラ観点でできる対策について書いていこうと思います。
＊動作検証は厳密に行っていなので参考程度に見ていただければと思います
＊設定イメージ解説にパロアルトネットワークス社の次世代ファイアウォール（以下PAと記載）を利用しています
Apache Log4j問題について
問題の詳細は下記サイト、ブログをご参照いただければと思います。
とても詳しく書かれています。
ここでは概要だけ記載します。
ApacheLog4j の脆弱性(CVE-2021-44228)に関する注意喚起
対象バージョン
対策
恒久的な対策
脆弱性が修正された以下のバージョンにアップデートする。
暫定的な対策
恒久対策が難しい場合は、以下の対策を行う。
Log4j バージョン 2.10 およびそれ以降
Log4j を実行する Java 仮想マシンを起動時に「log4j2.formatMsgNoLookups」という JVM フラグオプションを指定する
環境変数「LOG4J_FORMAT_MSG_NO_LOOKUPS」を「true」に設定するLog4j バージョン2.10 より前
JndiLookup クラスをクラスパスから削除する
ネットワークで対策する
前述のとおり、アプリケーションレベルで対策を行うことが推奨されていますが、すぐに対応できないケースもあると思います。
・対応が必要なシステムを整理できていない（どのシステムが対象かわからない）
・動作検証をしっかりしてからでないと対応できない
・メンテナンスが許容される年末まで待ってとか・・
このような場合は、超暫定対処でネットワークレベルで対策が必要です。
今回はネットワークの中でも主にファイアウォール（UTM）での対策について書いていきます。
UTM機能で対策する
多くのファイアウォールではUTM機能が実装されています。
＊ライセンスが追加で必要なものが多いです
ファイアウォール各ベンダーがLog4j問題（CVE-2021-44228）のシグネチャを配信しているので、UTM機能が利用できる場合は以下の対策が有効です。
下記方向の通信にUTM機能を有効（ON）にする。
【インターネット（Any）】→ 【サーバ】
【サーバ】→ 【インターネット（Any）】
PAでは”セキュリティポリシールール”の”プロファイル設定”から設定可能です。
上記方向のセキュリティポリシーの”脆弱性防御”にプロファイルを適用します。
シグネチャ（脅威ID）を確認したところ、重大度がHightかCritical、デフォルトアクションが”リセット”になっていたので、デフォルトのプロファイルを適応すれば問題なさそうです。
次世代ファイアウォール(PA-Series、VM-Series、 CN-Series)または脅威防御セキュリティサブスクリプションを持つPrisma Accessは、以下の脅威IDでこの脆弱性に関連するセッションを自動的にブロックできます。
91991, 91994, 91995, 92001 (Application and Threat content update 8502)
UTM機能を利用することにより、外部からの脆弱性を悪用した通信をブロックできます。
また、シグネチャの内容によりますが【サーバ】→ 【インターネット（Any）】方向にもUTM機能を適用することにより、攻撃者の初回アクセスがサーバに到達してしまった場合のその後通信をブロックできる可能性があります。
また、脆弱性防御以外にも、アンチスパイウェア、URLフィルタリングも併用して設定することで防御効果を高めることが可能です。（PAの場合）
※アンチスパイウェアでは攻撃に利用されているドメインの名前解決ブロック、URLフィルタリングでは同じく攻撃に利用されるURLへのアクセスをブロックすることが期待できます
注意点
この対策も完璧ではないため注意点もあります。
- シグネチャベースのため、シグネチャにマッチしない通信はブロックできない
攻撃に利用する文字列パターンを変えるなど、攻撃パターンも変化しているようです。
- 通信が暗号化（HTTPS）されている場合は検知できない
暗号化通信（HTTPS）の場合は、ファイアウォールで通信の内容を検査できないためブロックできません。
ファイアウォールの前段、またはファイアウォール自身で複合化が必要です。
セキュリティポリシーで対策する
ファイアウォールでUTM機能を利用できない場合の対策、またUTM機能と併用する目的でセキュリティポリシーでの通信制御も有効です。
ホワイトリスト方式
１.アクセス元を絞る
サーバーへのアクセス元を限定できる場合は絞ります。
一般公開サービスの場合は難しいですね。
２.サーバからの通信は必要なものだけに絞る
今回の脆弱性では、攻撃を受けるとサーバから攻撃者の用意したLDAP等のサーバへアクセスを行います。
そのため、【サーバ】→ 【インターネット（Any）】方向の通信は、以下のような必要なものだけに絞ります。
攻撃で利用されるのは以下のプロトコルが多いようです。
このプロトコルのインターネット宛通信をブロックすることで、攻撃を止めることが可能です。
お気づきの方もいると思いますが、攻撃に利用するプロトコルにDNSが含まれています。
攻撃対象のサーバ情報（各ソフトウェアのバージョン情報、ユーザー情報、パスワード等）をDNSプロトコルにのせて、外部DNSサーバにパラメータとして渡すことが可能なようです。
DNSも制限できれば問題ないですが、なかなか制限は難しいと思いますので、UTM機能との併用（＊）が必要かと思います。
３.サーバからの通信は必要なものだけに絞る with アプリケーション識別
「２.サーバからの通信は必要なものだけに絞る」の応用です。
一般的なファイアウォール（アプリケーションを識別できない）では、ポートベースでの通信制御になります。
＊例：HTTPを許可する場合はTCP 80を許可する
この方法だと、許可したポートを使って攻撃者が通信をした場合にブロックできません。
＊例：TCP 80を許可した場合、攻撃に利用するLDAP通信をTCP 80で行うことで通信可能になる
アプリケーション識別可能なファイアウォールでは、許可通信をアプリケーションで指定することで上記に対応可能です。
PAでは”セキュリティポリシールール”の”アプリケーション”から設定可能です。
ブラックリスト方式
ここまでは、許可するものを指定するホワイトリスト方式でしたが、ここからはブラックリスト方式での対策です。
また、ホワイトリスト方式と併用するのがオススメです。
１.攻撃に利用されるプロトコルをブロックする
前述の通り、下記プロトコルが攻撃でよく利用されます。
このプロトコルをセキュリティポリシーでブロックします。
＊RMI、IIOPのポート番号はまとまった情報がなく不明です（すみません）
２.攻撃に利用されるプロトコルをブロックする with アプリケーション識別
「１.攻撃に利用されるプロトコルをブロックする」の応用です。
こちらも前述の通り、ポート番号のみの制御では別ポートを利用された場合にブロックできません。
アプリケーション識別を利用することで通信の内容を検査してアプリケーション判別してブロックすることが可能です。
＊例：LDAPがTCP 80を使って通信していてもアプリケーション識別可能
以下をブロック対象のアプリケーションとして設定します。
注意点としては、”サービス”の設定を「any」にすること。
デフォルトでは「application-default」が設定されているため、PAで定義されているデフォルトのポート番号しか検査されません。
例えばLDAPの場合、以下がデフォルトポートのため、それ以外のポートは検査されません。
ブロックするアプリケーションを設定する場合は、「any」とすることで他ポートを利用して通信を行っている場合も検査・制御可能になります。
番外編（外部DNSサーバに頼る）
外部のDNSサーバ（サービス）で、マルウェアサイトの名前解決をブロックしてくれるものもあるので、このようなサービスに頼るのもありかもしれません。
完全におまけ程度の対策ですが。
サーバに設定するDNSサーバ設定を、セキュリティ対策されている外部DNSサーバにすることで、攻撃に利用されているドメインの名前解決ブロックしてくれ・・・るといいなぁ。
おわりに
ネットワーク観点で Log4j脆弱性問題（CVE-2021-44228）の対策について書きました。
何をすれば完璧ということはないので、利用できるリソースやリスクを考慮しながら、多層（ライブラリアップデート + ネットワークでも対策等）で対策するのが良いと思います。
