Log4Shell(Log4j)脆弱性の初期対応
はじめに
みなさん、師走で忙しいでしょうか？log4jで大きめな脆弱性が発見されました。
詳細は省きますが、ある条件可で任意のコードが実行できるような脆弱性です。
今回初期対応したのですが、諸々対応が難しいこともあり
対応が間違っているなどあればご連絡いただけると助かります
概要図
対策について考慮しないといけない図ですがこの記事のこの図がわかりやすいです。
対応
根本的な対策は、ソフトウェアのアップデートですが、Javaのバージョンに依存する処理もあったり、そもそもソフトウェアベンダーさんからバージョンアップソフトが出てないというので、なかなか対応が難しい状況かもしれません。
しかし、外部公開しているサイトについてはソフトウェアベンダーさんからのバージョンを待っているのは、ここまでセキュリティー情報が出回っている以上危険です。
そのため、修正ファイルが出るまでは別の対応をせざる得ません。
具体的な対応方法
1.WAFで対策（リスクの軽減）
とりあえず対策する場合、AWSを利用しているのであれば、AWS WAFが便利です。
※AzureもGCPも似たような機能（Azure：Azure WAFでカスタムルールで対応、GCP：Cloud Armor の WAF ルールでフィルタリング）
※あくまでも一時しのぎであることに気をつけましょう
リセラーさんで、WafCharmというファイアーウォールに契約している場合の対策とかいてあるのですが、AWSのカスタマイズルールだけでもある程度はブロックできます。
AWS WAFに「AWS-AWSManagedRulesKnownBadInputsRuleSet」というルールあるので
今回はAWSを利用していて、AWS WAFだけでも一定の効果があるようです。
2.ソフトウェアのバージョンアップ
他社製品の根本対応はソフトウェアバージョンアップしかありません！！！！
どうしても旧バージョン使いたいのでバージョンアップしたくないっす
セキュリティリスクをビジネス側で負ってください！それが嫌なら提供しているソフトウェアベンダさんと交渉してください。
どうしてもバージョンアップできない場合は、以下のワークアラウンドを実施するのも有効の模様です。詳細は以下のページを参照してください
Log4j 2.10およびそれ以降のバージョン
Log4jを実行するJava仮想マシンを起動する際に log4j2.formatMsgNoLookups を true に設定する
例: -Dlog4j2.formatMsgNoLookups=true
環境変数 LOG4J_FORMAT_MSG_NO_LOOKUPS を true に設定する
Log4j 2.10 より前のバージョン
JndiLookupクラスをクラスパスから除外する
終わりに
最新バージョンにすると、下位互換性が無いのでバージョンアップしない！とビジネス側から言われることも多々あります。
ただ、公開サイトの場合はセキュリティリスクはどうしてもあるので、インフラ担当者は旧バージョンで動かすことのリスクはビジネス側に説得する必要性はあります。ただ、旧バージョンのまま動かすとなると、セキュリティリスクもですが、累積の変更リスクであったりで、どうしようもなくアップデートする際に、エンジニアがそんな作業やりたくないといって逃げたりするので、天秤にかけないと危険だなと思ったりします。
※前々職で15年間アップデート放置したアプリにバージョンアップの話があり、先輩が2名失踪したとか笑えない話があります。。。
参考文献リスト
詳しい記事
Log4Shell(Log4j)の対応状況がリスト化されているサイト（English）
Discussion