-
タグ
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR
サーバのハードニング(要塞化)のガイドラインでは、サーバで使用するプログラムでOSやサーバアプリケーション名、バージョン等の情報(以下、バナー情報)を回答しないように設定することが推奨設定となっています。バージョン情報を攻撃者に収集され、脆弱性の存在を知られてしまうことを避けるのが目的です。
しかし、VPNやSSH通信等を提供するアプリケーションでは、アプリケーションやバージョン情報を識別している場合があり、バージョン情報が取得できない場合は弱い暗号プロトコルを使用するため、逆に危険ではないかという意見もあります。
また、Attack Surface Management(以下、ASM)製品を使用する場合、サーバのAsset情報やIssue情報を収集するソースがバナー情報となっているため、バージョン情報等を回答しない設定のサーバは正しくAssetやIssueの調査ができなくなります。
このようにバナー情報の設定はどうするべきか悩ましい問題と言えます。今回はこの問題について考察していきたいと思います。
バナー情報の推奨設定について
バナー情報は多くのサーバソフトウェアにおいて、初期状態ではバージョン情報などを回答するよう設定されています。初期設定で公開としている理由は不明ですが、サーバ構築の際にレスポンス情報から構成を再確認できるようにするためや、サーバと通信するアプリケーションを作成する際にアプリケーション名やバージョン情報から挙動を変更できるようにするためと考えられます。
では、セキュリティの観点ではどのように推奨されているかについて、アメリカ国立標準技術研究所(NIST)が公開している「NIST SP 800-123 Guide to General Server Security」※を参照すると5章の「Securing the Server Software」にて以下のような記載があります。
※ NIST SP 800-123, Guide to General Server Security
- For external-facing servers, reconfigure service banners not to report the server and OS type and version, if possible.
- Configure warning banners for all services that support such banners.
- 外部向けサーバの場合、可能であれば、サービス バナーがサーバとOSの種類およびバージョンを報告しないように再構成します。
- そのようなバナーをサポートするすべてのサービスに対して警告バナーを構成します。
この資料等が根拠となって、多くのハードニング手順ではバナー情報を表示しないよう設定する手順となっていると考えられますが、上記の記載の通り「if possible(できれば)」となっていることから、何が何でもそうすべきという設定ではなく「非表示にして他に影響がなければ、非表示設定にすべき」という程度の推奨事項であることがわかります。また、この項目には以下の注釈がついています。
This deters novice attackers and some forms of malware, but it will not deter more skilled attackers from identifying the server and OS type.
これは初心者の攻撃者や一部のマルウェアを阻止しますが、より熟練した攻撃者がサーバやOSの種類を特定するのを阻止することはできません。
当然ですが、脆弱性のあるバージョンのアプリケーションを使用している際にアプリケーション名やバージョン情報を非表示にしたからと言って、脆弱性そのものが解消するわけではありません。脆弱性によってはバナー情報に頼らずとも脆弱性の有無を確認する方法が存在することもあり、バナー情報の秘匿が絶対の対策ではありません。
推測になりますが、これらのバナー情報の秘匿が推奨された背景には、この推奨設定が作られた当時は現在よりPCやサーバのスペックが限られる、攻撃者がサーバを調達するハードルが高い、といった攻撃や調査のリソース調達が容易ではない状況がありました。そのため、複雑な手法での脆弱性調査の自動化や攻撃の自動化が困難だったことから、バナー情報による脆弱性調査が主流であったといった当時の状況があるのではないでしょうか。
現代ではレンタルサーバや仮想サーバの構築は極めて簡単で、攻撃の自動化のハードルが低くなっていることから、脆弱性調査を行わず片っ端から攻撃コードを送り付けるといった攻撃も見られます。このような状況を踏まえると、現在ではバナー情報の秘匿についても対策の優先度が下がったと言えるのかもしれません。
バナー情報を秘匿することのASM製品への影響
冒頭でも説明した通り、パケットのレスポンスヘッダに記載されたバージョン情報等をもとに、以降の挙動を決定するアプリケーションが存在するように、セキュリティ対策製品においてもバナー情報をもとに警告を出す場合があります。
ASM製品がその最たるもので、過去のLAC WATCHでも説明した通り多くのASM製品は攻撃的な通信を行わず通常のWebサイトへのリクエストと同等の通信内容で取得可能な情報から脆弱性の有無や設定不備等の調査を行います。そのため、ASM製品を使用して外部公開資産の問題を調査する場合にバナー情報が非公開となっている場合は正常に情報を収集できず、脆弱性の有無を判断できない可能性があります。ASM製品毎にバナー情報が非公開の場合の挙動は異なる可能性がありますが、ラックで確認できた範囲ではバナー情報を確認できないという警告は出ないようです。
ASM製品を利用する場合は組織内でバナー情報のポリシーを統一し、ASM製品の調査対象とする資産と除外する資産を明確にし、バナー情報の設定をした方がよいでしょう。
バナー情報を秘匿すべきか
バナー情報の取り扱いについては様々な意見がありますが、読者の方々にとっては秘匿すべきか秘匿すべきでないかという点が一番知りたい情報だと思います。
この問題についてラック社内で意見を集めましたが、秘匿することに賛成と反対で意見は分かれました。理由としては、秘匿することにも秘匿しないことにも一定の根拠があると言えるからです。その上で基本的な方針としては、「基本的には秘匿すべきだが、システム上の理由があれば公開する」というのが望ましいと考えております。
秘匿に賛成の意見
- バナー情報を公開している場合、それ自体が脆弱性ではありませんが、アクセス可能な第三者にサーバの構成情報を取得されてしまいます。このアプリケーション名やバージョン情報をもとに、攻撃者は脆弱性の有無を推測できます。攻撃者は平時からこの情報を収集することで、脆弱性が報告された際に攻撃可能なサーバを速やかに特定できます。
秘匿に反対の意見
- サーバのバナー情報をもとに使用する暗号プロトコルを決定するような場合は、バナー情報を秘匿した方が脆弱になることがあります。これはSSHやVPNといった通信を提供しているサーバ等で発生する可能性があります。通信を行うアプリケーションは一般的に使用可能な暗号方式の中で最も強度の高い方式を使用するように設計されていますが、ユーザアプリケーションとサーバ側の双方が対応しているプロトコルを使用することになります。バナー情報が得られないことで本来使用可能なプロトコルよりも強度の低いプロトコルをリクエストしてしまい、不必要に危険な暗号方式で通信をしてしまう危険性があります。
- ASM製品に代表される脆弱性調査を目的としたセキュリティ対策製品では、サーバのバナー情報をもとに脆弱性の存在を判断しているため、バナー情報を秘匿している場合は調査結果に反映されなくなります。また、ASM製品にはバナー情報が得られないことについての警告は出ない可能性があります。
- ASM製品を使用している状態に限らず、バナー情報を秘匿する場合はサーバ管理者以外の第三者がソフトウェアのアップデート漏れを指摘できないという問題があります。
上記の状況が考えられるため「バナー情報を基本的に非公開とする」という方針は時代遅れだとするものもありました。
ペネトレーションテストでの評価
- バナー情報を公開している点をリスクとして評価することはしていません。しかし、「不必要な情報を公開しているのであれば非公開とした方がよいのではないか」というコメントをすることはあります。
- バナー情報が公開されていたとしても、適切に脆弱性対策のパッチ適用やバージョンアップを行っていれば被害を受ける危険性は下がりますし、IPSやWAF等の対策製品を使用していれば攻撃を遮断できます。
このように、バナー情報を秘匿することと秘匿しないことにはそれぞれ一定の根拠が存在し、秘匿すべきか否かの結論はサーバの使用目的や組織の管理方針を踏まえて、組織として方針を決定すべきと言えます。
現在のインターネット環境においてバナーを公開し続けることのメリットはないと言えますが、先にも解説した通りバナー情報が得られないことでの不利益が生じるアプリケーションも存在するため、使用しているアプリケーション等を踏まえて慎重に判断することが必要です。
様々な意見を踏まえた上で基本的にはバナー情報を秘匿することが望ましいと言えますが、注意点として「バナー情報を秘匿する」ことと「アプリケーションの脆弱性を解消する」ことはイコールではないという点を忘れてはいけません。バナー情報を秘匿することはあくまで攻撃者に構成情報を収集させず、攻撃を受けるリスクを下げるものであって、脆弱性を狙った攻撃を防ぐことはできません。
昨今の攻撃傾向として、バージョンがわからないサーバに対してとりあえず攻撃コードを試すパターンも存在するため、脆弱性のあるアプリケーションを早急にアップデートすることや、パッチ適用をするといった対応は必要となります。こういった点を考えると、バナー情報を秘匿することよりもいかに速やかにバージョンアップやパッチ適用を実施するかに注力した方が効果的と言えるかもしれません。
そしてそのためにはあえてバナー情報を公開し、ASM製品を活用して外部公開資産の脆弱性管理を実施する方が効率的な脆弱性管理につながると考えられます。
最後に
本記事ではセキュリティ対策として賛否あるバナー情報(アプリケーション名やバージョン情報等)の秘匿化について、メリットやデメリットを含めたラックとしての見解を記載いたしました。
確かに以前はサーバのハードニング手順の一つとして取り上げられており、バナー情報を非公開にすることが基本とされていましたが、今日では必ずしもそれが正しいとは言えなくなっております。本記事で述べた見解も執筆時点での攻撃傾向やセキュリティ対策製品の動向を踏まえたものであり、いずれはまた見解が変わる可能性もあります。
サイバーセキュリティの対策手法は常に時代とともに変化しており、一度対策をしたからと言って永遠にそのままでよいものではありません。最新の技術や新たな脆弱性等によって最新の対策は常に変化し、定期的に見直しが必要です。ラックは最新の情報を収集し今後も発信していきます。もし、ご不明点やセキュリティ対策へのご不安等ございましたら、お気軽にご相談ください。
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- もっと見る +
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR