脆弱性検査を行うOSSツール「OpenSCAP」で何が分かるのか:OpenSCAPで脆弱性対策はどう変わる?(4)
本連載では、グローバルスタンダードになっている「SCAP」(セキュリティ設定共通化手順)、およびそれを基にシステム構成や脆弱性の検査を行うためのOSSツール「OpenSCAP」や、その周辺の技術、用語などを紹介する。今回は、OpenSCAPの環境を構築し、実際に試してみた。
まずはOpenSCAPを試してみよう
OSSセキュリティ技術の会の面和毅です。本連載「OpenSCAPで脆弱性対策はどう変わる?」では、実質的にグローバルスタンダードの「SCAP(Security Content Automation Protocol:セキュリティ設定共通化手順)」、およびそれを基にシステム構成や脆弱(ぜいじゃく)性検査を行うためのOSS(オープンソースソフトウェア)ツール「OpenSCAP」や、その周辺の技術、用語などを紹介しています。
今回は、前回まで紹介してきたSCAPの構成要素を踏まえて、OpenSCAPの代表的なツールを使って全体的な動きを見ます。
今回の検証環境としては、GUIツールを簡単に使用したいということもあるので、Fedora 29にGUIを入れたものを使用します(一部、CentOS 7.6での説明もあります)。
GUI(SCAP Workbench)を使って設定を検査する
OpenSCAPおよびその周辺ツールは、Red Hat、Fedora、CentOSではデフォルトのパッケージに含まれています。
まずは、「SCAP Workbench」というGUIツールを使ってローカル環境の設定値を検査してみます。
SCAP Workbenchをインストールする
SCAP Workbenchは、dnf(Red HatやCentOSではyum)、aptなどを用いてインストールすることができます。
[root@fedora29 ~]# dnf install scap-workbench
「scap-workbench」をインストールすると、依存関係が解決されて必要なファイル類がインストールされます。
SCAP Workbenchでローカルの状態をスキャンする
一般ユーザーで下記コマンドを実行すると、GUIが起動します。
[jsosug@fedora29 ~]$ scap-workbench
スキャン対象(OSやミドルウェア)が選択できるので、「Fedora」を選択します(図1)。
「Profile」でプロファイル(システムが従うセキュリティ要件)を選択します。「Standard System Security Profile」を選択して「Scan」を実行します(図2)。
スキャンが実行されます(図3)。
スキャン実行後にスキャン結果が表示されます。スキャン中にエラーがあった場合には、エラーが表示されます(図4)。
スキャン結果をダイアログから見ることができます(図5)。
また、スキャン結果からは「Fail」した(セキュリティ要件にそぐわなかった)箇所を修正するスクリプトを生成することができます。bashやAnsible、Puppet用のファイルも出力できます。デフォルトでは「remediation.XX」というファイル名で出力されます(図6)。
bashのスクリプト(remediation.sh)を確認してみます。remediation.shはセキュリティ要件にそぐわなかったところを修正するためのスクリプトなので、sudoコマンドなどを用いてroot権限で実行する必要があります。例えば、図7に挙げられている箇所では、Fedora 29のデフォルトでの「PASS_MIN_LEN」(パスワード最低長)は「5」でしたが、これが「7」に変更されます。
############################################################################### # BEGIN fix (8 / 38) for 'xccdf_org.ssgproject.content_rule_accounts_password_minlen_login_defs' ############################################################################### (>&2 echo "Remediating rule 8/38: 'xccdf_org.ssgproject.content_rule_accounts_password_minlen_login_defs'") declare var_accounts_password_minlen_login_defs var_accounts_password_minlen_login_defs="12" grep -q ^PASS_MIN_LEN /etc/login.defs && \ sed -i "s/PASS_MIN_LEN.*/PASS_MIN_LEN\t$var_accounts_password_minlen_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ] then echo -e "PASS_MIN_LEN\t$var_accounts_password_minlen_login_defs" >> /etc/login.defs fi # END fix for 'xccdf_org.ssgproject.content_rule_accounts_password_minlen_login_defs'
同様に、「PASS_MIN_DAYS」(パスワードを変更してから次に変更できるようになるまでの最短日数)は「0」から「7」に、PASS_MAX_DAYS(1つのパスワードを使える最長日数)は「9999」から「90」に変更されます(図8)。
# Password aging controls: # # PASS_MAX_DAYS 90 # PASS_MIN_DAYS 7 # PASS_MIN_LEN 12 # PASS_WARN_AGE Number of days # warning given before a password expires. # PASS_MAX_DAYS 9999 PASS_MIN_DAYS 0 PASS_MIN_LEN 5 PASS_WARN_AGE 7
# Password aging controls: # # PASS_MAX_DAYS 90 # PASS_MIN_DAYS 7 # PASS_MIN_LEN 12 # PASS_WARN_AGE Number of days # warning given before a password expires. # PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 12 PASS_WARN_AGE 7
スキャン結果をHTMLファイルやXCCDF、ARFファイルとして出力できます(図9)。
HTMLファイルでは、選択していたプロファイル(セキュリティ要件)にパスした設定、パスしなかった設定の総数と、項目を確認できます(図10、図11)。
インストール時にセキュリティ要件を適用する
これまでの操作を実行したほとんどの方が、Red Hat Enterprise Linux(RHEL)やCentOSのインストール時に「Security Policy」という選択画面を見たことがあると思います。これをインストール時に選択し、適用したいセキュリティ要件を選択することで、インストールされたOSの設定値を、選択したセキュリティ要件に従った値(例えば図6で見たようなログイン時間などの規程)に最初から設定することが可能です(図12、図13)。
CUIツールを使って、脆弱性対応を行って更新されているかどうかを確認する。
Red HatやSuSEなどでは、脆弱性情報とセキュリティアドバイザリーが出るごとに、「導入されているパッケージに対応したセキュリティフィックスがなされているか」がOVALで定義されたファイル(連載第3回を参照)を提供しています。
OpenSCAPのCUIツールである「oscap」コマンドと、この定義ファイルを用いることで、ローカルホストにインストールされているパッケージ類が、きちんと脆弱性対応を行って更新されているかどうかを確認できます。
ここではサンプルとして、Red Hatのセキュリティデータ提供サイトからダウンロードしたRHEL 7用のファイル(2018年12月17日分)をCentOS 7用に加工したものを使用し、ローカルPCのセキュリティフィックス状況をスキャンして、HTMLとしてレポートします。
※サンプルファイル「CentOS_7_Sample.xml.xz」を添付しておきますが、これはあくまでも「実験用」として使用し、本番環境では絶対に使用しないでください。本ファイルを本番環境で使用することによる責任は持てません。
コマンドは下記の書式で実行します。
# oscap oval eval --report "レポートを出力するHTMLファイル" "定義ファイル"
先ほどのサンプルのCentOS 7用にカスタマイズした定義ファイルを用いて下記コマンドを実行すると、oscapコマンドを実行したディレクトリにレポートファイルとして「centos-test.html」ファイルが出力されます。
[root@CentOS76 ~]# oscap oval eval --report centos-test.html CentOS_7_Sample.xml
このcentos-test.htmlファイルをWebブラウザで見てみると、ローカルにインストールされているパッケージ情報のうち、セキュリティフィックスが出ているにもかかわらずバージョンを上げていないパッケージに関しては赤(true)、バージョンが上がっているものに関しては緑(false)で表示されます(図14、図15)。
次回予告
今回は、ほとんどのLinuxディストリビューションに付属している、OSSツールのOpenSCAPを簡単に見ました。次回からは、OVALファイルやxccdfファイルについて、サンプルとともにより深く説明していきます。
筆者紹介
面和毅
略歴:OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍し、同社でSIOSセキュリティブログを連載中。
CISSP:#366942
近著:『Linuxセキュリティ標準教科書』(LPI-Japan)」
関連記事
- 2017年の脆弱性報告件数は過去最高の約1万4700件、まだ隠れた脆弱性がある可能性も:ESET
ESETによると、2017年は脆弱性の報告件数が前年比で2倍以上に増えて過去最高となり、中でも重大な脆弱性が近年の傾向に沿って急激に増加した。 - 外注したシステムの脆弱性は誰のせい? 連日の「深刻な脆弱性」にどう向き合い、どう対応するか?
連日のように公開される脆弱性情報の中から自分たちに関係するものを見つけ、適切な優先順位で対応するのは容易ではない。この状況に、企業はどう向き合えばよいのだろうか? @ITは、2017年8月30日にセミナー『連日の「深刻な脆弱性」どう向き合い、どう対応するか』を東京で開催した。多数の専門家やセキュリティベンダーが登壇した同セミナーの模様をお届けしよう。 - 「脆弱性情報」をどう扱うか――見つける人、流通させる人、対処する人、それぞれの視点
連日公表されるソフトウェアなどの脆弱(ぜいじゃく)性情報。2016年12月1日に行われた「Internet Week 2016」では、「脆弱性情報と賢く付き合う〜発見から対策までの最前線〜」と題したプログラムが開催された。
Copyright © ITmedia, Inc. All Rights Reserved.