Linux × Security設定の適正化編 ~ソフトウェア管理~

はじめに

クラウドインテグレーション部の渡邊です。

本記事のシリーズでは、サーバの構築・運用に最低限必要なセキュリティの体系的知識習得を目的としています。

本シリーズの全体像と今回執筆の内容の位置づけは以下の通りです。

• 設定の適正化
  • ソフトウェア管理 ←今回はここについて説明
  • ユーザ管理
  • 運用管理
• パケットフィルタリング
• 権限の制御
• 暗号化
• 検知

本内容はLinuxセキュリティ標準教科書に準拠しており、設定の適正化の観点でセキュリティチェック項目表に沿って内容を紹介していきます。

 引用元：「Linuxセキュリティ標準教科書」 特定非営利活動法人エルピーアイジャパン p.13

環境

Amazon Linux 2

ソフトウェア管理

1.1 ソフトウェアのアップデート情報をチェックする

1つ目は、ソフトウェアのアップデート情報をチェックすることです。 脆弱性によるセキュリティの弱点を攻撃されることを防ぐために、定期的にアップデート情報をチェックする必要があります。

アップデート情報のあるサイトは以下3パターンに大別されます。 それぞれ脆弱性に関連するリンク集をいくつか示します。

①ディストリビューションのサイト(Debian・centOS・redhat…)

Red Hat CVE Database(英語)

CentOS-announce(メーリングリストの登録)

CentOS-announce(過去のアーカイブ)

Debian セキュリティ情報

②ソフトウェアの脆弱性サイト(JVN・jpcert・IPA…)

JPCERT コーディネーションセンター

JVN(JPCERT/CCと情報処理推進機構(IPA)が共同で管理している脆弱性情報データベース)

JVN iPedia

IPA緊急対策情報・注意喚起一覧

③開発コミュニティサイト(apache・mysql…)

Apache HTTP Server Security Reports(英語)

Apache Tomcat Security Reports(英語)

PostgreSQL Security Information(英語)

MySQL bugs

PHP report bugs(英語)

実務においてはこれらすべてを毎日チェックするのは大変なので、ある程度見るサイトを絞る必要があると思います。 例えば、以下のようなパターンで絞るのが良いかと思います。

• 網羅したい場合：CVEサイト

• 早く確認したい：開発コミュニティサイト

※CVEだと少々見づらいので日本語でまとまっているわかりやすいサイトとしてJPCERTなどのソフトウェアの脆弱性サイトを代わりに確認するのも良いと思います。

脆弱性公表のプロセスはざっくり以下の通りとなっているため、そちらを加味して自分なりに見やすいように選定してみるのが良いと思います。

[脆弱性公表のプロセス]

1. 脆弱性を発見
2. コミュニティやベンダーに連絡
3. (日本であれば)IPAに申請
4. mitre社がCVEの採番
5. そのプログラムを使用しているコミュニティやベンダーはその脆弱性に対して対応
6. コミュニティやベンダーが脆弱性対応後、一般公開

また、脆弱性は一般的にCVSSという評価手法を元に脆弱性の深刻度を定量的に評価します。 深刻度を評価するための基準およびそれによって判断される深刻度はそれぞれ以下の通りです。 各基準にある複数の項目に基づいて値を算出し、その数値によって深刻度を判断します。

深刻度レベル分け(重要度の高い順)

深刻度の評価基準

1.2 利用しているパッケージを定期的にアップデートする

2つ目は利用しているパッケージを定期的にアップデートすることです。

パッケージアップデートの目的は主に3つです

1. ソフトウェアの重大なバグの修正
2. 機能強化
3. 脆弱性の修正

仮に古いパッケージがあった場合、脆弱性の修正が行われていないものを含む可能性があるため、サーバを攻撃されてしまうおそれがあります。それを防ぐために、アップデートをする必要があります。

Linuxの場合だと代表的なものとして以下の2つパッケージ管理システムがあるので、パッケージのアップデートの運用の負荷軽減において役立ちます。

• yum・・・RedHat系パッケージ管理システム

• apt・・・Debian系パッケージ管理システム

※今回は詳しく紹介いたしませんが、現在ではyumの後継としてdnfコマンドがあります。

また、それぞれのパッケージ管理システムでコマンド体系が違うので注意が必要です。

例えば、yumの場合はパッケージをアップデートする際にupdateコマンドを指定すれば良いですが、 aptの場合だとupdateコマンドを指定してもパッケージの更新は行われないため、upgradeコマンドを指定する必要があります。

なお、apt updateコマンドはリポジトリ情報を管理するsources.listを更新した場合に、それを反映する際に使用します。

【パッケージアップデートのコマンドとオプション】

パッケージ管理ツールを触ってみる

大まかに以下のプロセスが行われています。

【yumによるパッケージアップデート-プロセス-】

1. リポジトリの依存関係の解決: パッケージマネージャーは、依存関係を解決するためにリポジトリを調べます。
2. アップデート対象のパッケージの特定: パッケージマネージャーは、現在インストールされているパッケージと比較して、新しいバージョンの利用可能なパッケージを見つけます。
3. パッケージのダウンロード: 新しいバージョンの利用可能なパッケージが見つかると、パッケージマネージャーはそれらをダウンロードします。
4. パッケージのアップデート: パッケージと依存関係の解決が完了すると、パッケージマネージャーはアップデートを実行します。
5. クリーンアップ: 古いバージョンのパッケージと関連するファイルがクリーンアップされます。
6. 検証: アップデートが正常に行われたかどうかを確認するため、パッケージマネージャーはインストールされたパッケージを検証します。

実機でupdateコマンドを実施したログを以下に示します。 おおむね先述のプロセスのとおりに動作していることが分かるかと思います。

【yumによるパッケージアップデート-実機ログ-】

$ yum list updates
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core | 3.7 kB 00:00:00
Updated Packages
cpio.x86_64 2.12-11.amzn2 amzn2-core
curl.x86_64 7.88.1-1.amzn2.0.1 amzn2-core
libcurl.x86_64 7.88.1-1.amzn2.0.1 amzn2-core
python2-setuptools.noarch 41.2.0-4.amzn2.0.3 amzn2-core

$ yum update
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core | 3.7 kB 00:00:00
Resolving Dependencies(リポジトリの依存関係の解決)
--> Running transaction check
---> Package cpio.x86_64 0:2.11-28.amzn2 will be updated
---> Package cpio.x86_64 0:2.12-11.amzn2 will be an update
---> Package curl.x86_64 0:7.87.0-2.amzn2.0.1 will be updated
---> Package curl.x86_64 0:7.88.1-1.amzn2.0.1 will be an update
---> Package libcurl.x86_64 0:7.87.0-2.amzn2.0.1 will be updated
---> Package libcurl.x86_64 0:7.88.1-1.amzn2.0.1 will be an update
---> Package python2-setuptools.noarch 0:41.2.0-4.amzn2.0.2 will be updated
---> Package python2-setuptools.noarch 0:41.2.0-4.amzn2.0.3 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
=============================================================================================================================================================================================================================================
Package Arch Version RepositorySize
=============================================================================================================================================================================================================================================
Updating:(アップデート対象のパッケージの特定)
cpio x86_64 2.12-11.amzn2 amzn2-core 256 k
curl x86_64 7.88.1-1.amzn2.0.1 amzn2-core 402 k
libcurl x86_64 7.88.1-1.amzn2.0.1 amzn2-core 344 k
python2-setuptools noarch 41.2.0-4.amzn2.0.3 amzn2-core 658 k

Transaction Summary
=============================================================================================================================================================================================================================================
Upgrade 4 Packages
Total download size: 1.6 M
Is this ok [y/d/N]: y
Downloading packages:(パッケージのダウンロード)
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
(1/4): curl-7.88.1-1.amzn2.0.1.x86_64.rpm | 402 kB 00:00:00
(2/4): cpio-2.12-11.amzn2.x86_64.rpm | 256 kB 00:00:00
(3/4): libcurl-7.88.1-1.amzn2.0.1.x86_64.rpm | 344 kB 00:00:00
(4/4): python2-setuptools-41.2.0-4.amzn2.0.3.noarch.rpm | 658 kB 00:00:00
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 8.4 MB/s | 1.6 MB 00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction(パッケージのアップデート・クリーンアップ・検証)
Updating : libcurl-7.88.1-1.amzn2.0.1.x86_64 [] 1/8
Updating : curl-7.88.1-1.amzn2.0.1.x86_64 [] 2/8
Updating : python2-setuptools-41.2.0-4.amzn2.0.3.noarch [] 3/8
Updating : cpio-2.12-11.amzn2.x86_64 [] 4/8
Cleanup : python2-setuptools-41.2.0-4.amzn2.0.2.noarch 5/8
Cleanup : curl-7.87.0-2.amzn2.0.1.x86_64 6/8
Cleanup : libcurl-7.87.0-2.amzn2.0.1.x86_64 7/8
Cleanup : cpio-2.11-28.amzn2.x86_64 8/8
Verifying : cpio-2.12-11.amzn2.x86_64 1/8
Verifying : python2-setuptools-41.2.0-4.amzn2.0.3.noarch 2/8
Verifying : curl-7.88.1-1.amzn2.0.1.x86_64 3/8
Verifying : libcurl-7.88.1-1.amzn2.0.1.x86_64 4/8
Verifying : python2-setuptools-41.2.0-4.amzn2.0.2.noarch 5/8
Verifying : libcurl-7.87.0-2.amzn2.0.1.x86_64 6/8
Verifying : curl-7.87.0-2.amzn2.0.1.x86_64 7/8
Verifying : cpio-2.11-28.amzn2.x86_64 8/8

Updated:
cpio.x86_64 0:2.12-11.amzn2
curl.x86_64 0:7.88.1-1.amzn2.0.1
libcurl.x86_64 0:7.88.1-1.amzn2.0.1
python2-setuptools.noarch 0:41.2.0-4.amzn2.0.3

Complete!

1.3 不要なソフトウェアをインストールしない

3つ目は、不要なソフトウェアをインストールしないことです。 不要なパッケージのインストール数を最小限にすることで、ソフトウェアの脆弱性を抱えるリスクを下げることができます。 このような構成を Minimal構成(最小構成) と呼びます。 AWSでは、コミュニティAMIで「minimal」と検索すると最小構成AMIがヒットします。

セキュリティの高いサーバを構築する際には、最小(Minimal)構成となるイメージを選び、その後で使うパッケージを個別にインストールする場合が多いようです。

実際に最小構成の中身を確認してみたところaws-cliやncなどもパッケージがなかったです(AMI名：amzn2-ami-minimal-hvm-2.0.20230307.0-x86_64-ebs で確認)。 こちらの記事で詳細に比較していたため、ぜひ参考にしてください。

まとめ

今回はソフトウェア管理の設定の適正化で以下観点を説明しました。

• ソフトウェアのアップデート情報をチェックする
• 利用しているパッケージを定期的にアップデートする
• 不要なソフトウェアをインストールしない

次回の記事ではユーザ管理・運用管理の設定の適正化について執筆予定です。ぜひそちらも御覧ください！

【参考】

脆弱性情報ハンドリングとは？

あなたが脆弱性を発見したとき：CVE 発行までの 4-Steps とは？

パッケージマネージャーとは？わかりやすい仕組みの解説

パッケージマネージャーとは？わかりやすい仕組みの解説～直接使っていないOSSとは～