セキュリティ監査状況を採点〜CISベンチマークを読んでみた(Amazon Linux編)

にしざわ

2016.04.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

西澤です。先日、CIS(Center for Internet Security) Benchmarkを読んでみたところ、とても勉強になったので、セキュリティに対する知見を深める為、少し古いものなのですが、Amazon Linux版もしっかり読んでみることにしました。

CISベンチマークの説明等、前回の記事はこちら
- あなたのAWSセキュリティ監査状況を採点〜CISベンチマークを読んでみた｜ Developers.IO

Amazon Linux版CISベンチマーク

Amazon Linuxの最新版は、先日リリースされたAmazon Linux AMI 2016.03ですが、CISベンチマークの対応は2015.03までのようです。少々古いバージョンにはなりますが、必ず参考になる点があるはずです。

Level1、Scoredを優先に読み進めて行くところは先日の記事と同様です。それでは、早速詳しく見ていきましょう。

CIS AMAZON LINUX 2014.09-2015.03 BENCHMARK V1.1.0

1. アップデート、パッチ適用

ファイルシステム設定

まずはマウントオプションの制限やパーティション分割の話。パーティションもディスクが少ない時代は細かく分けていましたが、最近ではあまり細かすぎるのも運用を複雑化するだけなので、分割しないケースが増えてきたように思います。セキュリティ的には、/tmpは分けた方が良さそうです。また、audit等のディスクが溢れてしまいかねないログ領域は分けることが推奨されているようです。

/tmpを別パーティションにする(Socred,Level1)
/tmpパーティションをnodevオプションでマウントする(Level1,NotScored)
/tmpパーティションをnosuidオプションでマウントする(Level1,Scored)
/tmpパーティションをnoexecオプションでマウントする(Level1,Scored)
/varを別パーティションにする(Level1,Scored)
/var/tmpを/tmpにbindマウントする(Level1,Scored)
/var/logを別パーティションにする(Level1,Scored)
/var/log/auditを別パーティションにする(Level1,Scored)
/homeを別パーティションにする(Level1,Scored)
/homeをnodevオプションでマウントする(Level1,Scored)
リムーバブルメディア用パーティションをnodevオプションでマウントする(Level1,NotScored)
リムーバブルメディア用パーティションをnoexecオプションでマウントする(Level1,NotScored)
リムーバブルメディア用パーティションをnosuidオプションでマウントする(Level1,NotScored)
/dev/shmをnodevオプションでマウントする(Level1,Scored)
/dev/shmをnosuidオプションでマウントする(Level1,Scored)
/dev/shmをnoexecオプションでマウントする(Level1,Scored)
誰でも書き込めるディレクトリにはSticky Bitを設定する(Level1,Scored)
cramfsファイルシステムによるマウントは無効にする(Level2,NotScored)
freevxfsファイルシステムによるマウントは無効にする(Level2,NotScored)
jffs2ファイルシステムによるマウントは無効にする(Level2,NotScored)
hfsファイルシステムによるマウントは無効にする(Level2,NotScored)
hfsplusファイルシステムによるマウントは無効にする(Level2,NotScored)
squashfsファイルシステムによるマウントは無効にする(Level2,NotScored)
udfファイルシステムによるマウントは無効にする(Level2,NotScored)

ソフトウェアアップデート設定

この辺りはそんなに細かく見なくても良さそうですね。特別な要件が無ければRPMパッケージを使うようにしましょう。

Amazon GPG Keyがインストールされていることを確認する(Level1,Scored)
gpgcheckが全て有効になっていることを確認する(Level1,Scored)
最新のソフトウェアアップデートを取得する(Level1,NotScored)
RPMパッケージの完全性を確認する(Level1,NotScored)

AIDE(ファイル改ざん検知)

改ざん検知ソフトウェアの導入(AIDE)が推奨されています。有償のソフトウェアを使っておけば、更に安心です。システムアップデートやアプリケーションのデプロイ時に抑止しておかないと通知が大量に飛んだりするやつですね。

AIDEをインストールする(Level2,Scored)
ファイル改ざん検知を定期的に実行する(Level2,Scored)

SELinux

なかなか敷居が高く、あまり本格的に運用したことが無いSELinux。不具合があった時に切り分けがすごく難しいのですが、SETroubeshoot等でしっかりデバッグしながらリリースまでにランニングしておかないと怖いですね。

/etc/grub.confでSELinuxを有効にする(Level2,Scored)
SELinuxを有効にする(Level2,Scored)
SELinuxをtargetedに設定する(Level2,Scored)
SETroubleshootをアンインストールする(Level2,Scored)
MCS Translation Serviceをアンインストールする(Level2,Scored)
Unconfined Daemons(SELinuxで制限されないプロセス)が存在しないか確認する(Level2,Scored)
SELinuxがインストールされている(Level2,Scored)

安全なBoot設定

ちょっとクラウドらしくない項目が出てきました。これはちょっとオンプレ運用に引きずられて残っているだけの項目のように感じてしまうのが正直なところ。Boot設定をいじって起動しなくなったらEC2環境ではどうにもなりません。

/etc/grub.confのownerはrootに設定する(Level1,Scored)
/etc/grub.confをrootでのみ読み書き可能にする(Level1,Scored)
Boot Loaderパスワードを設定する(Level1,Scored)

その他のプロセス強化

Core Dumpから機密情報を抜き出すスキルを持った悪意のあるユーザまで対策しないといけないそうです。この辺りは徹底してますね。

setuidによりCore Dumpが作成されないようにする(Level1,Scored)
仮想メモリ配置のランダム化(Level1,Scored)
最新のOSリリースを利用する(Level1,NotScored)

2. OSサービス

レガシーサービスの削除

本当にレガシーなサービスが並んでます。telnet clientを疎通確認に使うくらいですかね。普通に使っていれば問題無いと思います。

telnet-serverの削除(Level1,Scored)
telnet clientsの削除(Level1,Scored)
rsh-serverの削除(Level1,Scored)
rshの削除(Level1,Scored)
NIS Clientの削除(Level1,Scored)
NIS Serverの削除(Level1,Scored)
tftpの削除(Level1,Scored)
tftp-serverの削除(Level1,Scored)
talkの削除(Level1,Scored)
talk-serverの削除(Level1,Scored)
xinetdの削除(Level1,Scored)
chargen-dgramの無効化(Level1,Scored)
chargen-streamの無効化(Level1,Scored)
daytime-dgramの無効化(Level1,Scored)
daytime-streamの無効化(Level1,Scored)
echo-dgramの無効化(Level1,Scored)
echo-streamの無効化(Level1,Scored)
tcpmux-serverの無効化(Level1,Scored)

3. 特別な用途のサービス

必要無ければ下記のサービスも適切に設定または削除しておきましょう。起動するサービスは必要最低限にして、特に狙われやすい汎用的なサービスには十分気を付ける、といったところでしょうか。

daemon umaskの設定(Level1,Scored)
X Window Systemの削除(Level1,Scored)
Avahi Serverの無効化(Level1,Scored)
CUPSの無効化(Level1,NotScored)
DHCP Serverの削除(Level1,Scored)
NTPの設定(Leve1,Scored)
LDAPの削除(Level1,NotScored)
NFS、RPCの無効化(Level1,NotScored)
DNS Serverの削除(Level1,NotScored)
FTP Serverの削除(Level1,NotScored)
HTTP Serverの削除(Level1,NotScored)
Dovecotの削除(Level1,NotScored)
Sambaの削除(Level1,NotScored)
HTTP Proxy Serverの削除(Level1,NotScored)
SNMP Serverの削除(Level1,NotScored)
MTAをローカルのみに制限(Level1,Scored)

4. ネットワーク設定、Firewall

EC２のSource Destination Check機能やSecurity Group機能で代替できるものがほとんどかと思います。クラウドらしくAWSサービスに任せられる所は任せつつ、二重管理にしたくないところですね。ただ逆に、セキュリティの基本としては、鍵は1つよりも2つあった方が泥棒には入られにくいです。鍵１０個になると毎日の開け閉めが大変なので、運用要件との折り合いをつけて設定方針を決めないといけません。

ネットワークパラメータ設定(Host Only)

IP Forwardingの無効化(Level1,Scored)
Send Packet Redirectsの無効化(Level1,Scored)

ネットワークパラメータ設定(Host and Router)

Source Routed Packet Acceptanceの無効化(Level1,Scored)
ICMP Redirect Acceptanceの無効化(Level1,Scored)
Secure ICMP Redirect Acceptance(Level2,Scored)
疑わしいPacketのロギング(Level1,Scored)
ブロードキャストリクエストの無効化(Level1,Scored)
Bad Error Message Protectionの有効化(Level1,Scored)
RFC推奨のSource Route Validation(Level2,Scored)
TCP SYN Cookiesの有効化(Level1,Scored)

IPv6

IPv6 Router Advertisementsの無効化(Level1,NotScored)
IPv6 Redirect Acceptanceの無効化(Level1,NotScored)
IPv6の無効化(Level1,NotScored)

TCP Wrapperのインストール

TCP Wrapperのインストール(Level1,Scored)
/etc/hosts.allowの作成(Level1,NotScored)
/etc/hosts.allowのパーミッション確認(Level1,Scored)
/etc/hosts.denyの作成(Level1,NotScored)
/etc/hosts.denyのパーミッション確認(Level1,Scored)

特別な用途のプロトコル

DCCPの無効化(Level1,NotScored)
SCTPの無効化(Level1,NotScored)
RDSの無効化(Level1,NotScored)
TIPCの無効化(Level1,NotScored)
iptablesの有効化(Level1,Socred)

5. ログ、監査

rsyslog設定

AWSならrsyslogよりもCloudWatch Logsを活用しましょう。ただ、ログはきちんと出力した上でアクセスできる人は最小限にする、というところは参考になると思います。

rsyslogのインストール(Level1,Scored)
rsyslogサービスの有効化(Level1,Scored)
/etc/rsyslog.conf設定(Level1,NotScored)
rsyslogログファイルのパーミッション確認(Level1,Scored)
rsyslogによるログサーバへのログ転送設定(Level1,Scored)
許可された転送ログのみの許可設定(Level1,NotScored)

auditd設定

セキュリティ要件が厳しいシステムでは、auditdの設定が必須となると思います。ディスクフルになって監査ログが出力できなっても普通はサービス継続を優先すると思いますが、このような厳しい要件下では、監査ログ出力ができなくなったらシステム停止させるのですね。このような優先順位付けのシステムって余程ですよね。

監査ログストレージサイズの設定(Level2,NotScored)
監査ログフル時のシステム停止(Level2,NotScored)
全ての監査情報の保持(Level2,Scored)
auditdサービスの有効化(Level2,Scored)
auditdサービス起動前プロセスの監査有効化(Level2,Socred)
日時情報変更の記録(Level2,Socred)
ユーザ/グループ変更の記録(Level2,Scored)
ネットワーク設定変更の記録(Level2,Scored)
SELinuxの強制アクセス制御の記録(Level2,Scored)
ログイン/ログアウトの記録(Level2,Scored)
セッション起動情報の収集(Level2,Scored)
ディレクトリパーミッションイベントの収集(Level2,Scored)
許可されないファイルへのアクセス失敗記録の収集（Level2,Scored）
setuid/setgidコマンドの使用記録（Level2,Scored）
ファイルシステムマウントの成功記録(Level2,Scored)
ユーザによるファイル削除の記録(Level2,Scored)
sudoers設定変更の記録(Level2,Scored)
sudologの記録(Level2,Scored)
カーネルモジュールのロード、アンロードの記録(Level2,Scored)
監査設定変更の記録(Level2,Scored)
ログローテーション設定(Leve1,NotScored)

6. アクセス制御

cron、anacron設定

cron、anacronも適切なアクセス権が求められます。

anacronの有効化(Level1,Scored)
cronの有効化(Level1,Scored)
/etc/anacrontabのパーミッション設定(Level1,Scored)
/etc/crontabのパーミッション設定(Level1,Scored)
/etc/cron.hourlyのパーミッション設定(Level1,Scored)
/etc/cron.dailyのパーミッション設定(Level1,Scored)
/etc/cron.weeklyのパーミッション設定(Level1,Scored)
/etc/cron.monthlyのパーミッション設定(Level1,Scored)
/etc/cron.dのパーミッション設定(Level1,Scored)
atデーモンの制限(Level1,Scored)
at、cronを許可されたユーザのみに制限(Level1,Scored)

SSH設定

Linux運用では欠かせないSSH接続なので、チェック項目が多いです。確認しておくと良いでしょう。

SSH2設定(Level1,Scored)
ログレベルをINFOに設定(Level1,Scored)
/etc/ssh/sshd_configのパーミッション設定(Level1,Scored)
SSH X11 Forwardingの無効化(Level1,Scored)
MaxAuthTriesを4回以下に設定(Level1,Scored)
IgnoreRhostsをYesに設定(Level1,Scored)
HostbasedAuthenticationをNoに設定(Level1,Scored)
Root Loginの無効化(Level1,Scored)
PermitEmptyPasswordsの無効化(Level1,Scored)
PermitUserEnvironmentをnoに設定(Level1,Scored)
指定Cipherのみ許可(Level1,Scored)
Idle Timeout Intervalの指定(Level1,Scored)
許可されたユーザ、グループのみの許可(Level1,Scored)
SSH Bannerの設定(Level1,Scored)

PAM設定

この辺りは以前お世話になった現場でも対応したことがあります。PAMはOSやサービスに依存せず設定できる項目も多いので便利ですね。

Hashing AlgorithmをSHA-512に設定(Level1,Scored)
pam_cracklibによるパスワード要件の設定(Level1,Scored)
パスワード認証失敗によるロックアウト設定(Level1,Scored)
パスワード再利用の制限(Level1,Scored)
コンソールへのrootログイン制限(Level1,Scored)
suコマンドの制限(Level1,Scored)

7. ユーザ環境

Shadow Password(/etc/login.defs)設定

こちらもPAMと同様です。パスワード期限があまり短いと運用が辛くなることもあるので、その辺りは要件に合わせて対処しましょう。

パスワード有効期限の設定(Level1,Scored)
パスワード変更可能期間の設定(Level1,Scored)
パスワード有効期限の警告設定(Level1,Scored)
システムアカウントの無効化(Level1,Scored)
rootアカウントのデフォルトグループ指定(Level1,Scored)
デフォルトumask設定(Level1,Scored)
長期間利用されていないユーザのロックアウト(Level1,Scored)

8. バナー

バナーから余計な情報を削除したり、警告を出したりしましょう。悪意のあるユーザをびびらせるだけでも、抑止力になるということですかね。

ログイン時の警告バナー設定(Level1,Scored)
バナー内のOS情報削除(Level1,Socred)
GNOME警告バナー設定(Level1,NotScored)

9. システムメンテナンス

システムファイルのパーミッション

特にアカウント管理に関連するアクセス権限は厳しくチェックされます。

システムファイルのパーミッション設定(Level2,NotScored)
/etc/passwdのパーミッション設定(Level1,Scored)
/etc/shadowのパーミッション設定(Level1,Scored)
/etc/gshadowのパーミッション設定(Level1,Scored)
/etc/groupのパーミッション設定(Level1,Scored)
/etc/passwdの所有者設定(Level1,Scored)
/etc/shadowの所有者設定(Level1,Scored)
/etc/gshadowの所有者設定(Level1,Scored)
/etc/groupの所有者設定(Level1,Scored)
全ユーザが書き込み可能なファイルの確認(Level1,NotScored)
所有者の存在しないファイルやディレクトリの確認(Level1,Scored)
所有グループの存在しないファイルやディレクトリの確認(Level1,Scored)
SUID実行可能なプログラムの確認(Level1,NotScored)
SGID実行可能なプログラムの確認(Level1,NotScored)

ユーザ、グループ設定

以前、開発機でユーザがすぐにrootパスワード変更して忘れてしまうことが多発したので、UID=0の別ユーザ作ったことあります。こんな悪さの方法を知っているユーザも下記のようなチェックを定期的に行っていれば炙り出せますね。

パスワードフィールド空が存在しないこと(Level1,Scored)
/etc/passwdに"+"が存在しないこと(Level1,Scored)
/etc/shadowに"+"が存在しないこと(Level1,Scored)
/etc/groupに"+"が存在しないこと(Level1,Scored)
root以外にuid=0のユーザが存在しないこと(Level1,Scored)
rootユーザのPATH環境変数が適切に設定されていること(Level1,Scored)
ユーザのホームディレクトリのパーミッションが適切に設定されていること(Level1,Scored)
"."ファイルのパーミッションが適切に設定されていること(Level1,Scored)
.netrcファイルのパーミッションが適切に設定されていること(Level1,Scored)
.rhostsファイルのパーミッションが適切に設定されていること(Level1,Scored)
/etc/passwdのグループが正しく設定されていること(Level1,Scored)
ユーザのホームディレクトリが適切に設定されていること(Level1,Scored)
ユーザのホームディレクトリの所有者が適切に設定されていること(Level1,Scored)
重複するUIDが存在しないこと(Level1,Scored)
重複するGIDが存在しないこと(Level1,Scored)
予約されたUID(0-499)がシステムアカウントに設定されていること(Level1,Scored)
重複するユーザ名が存在しないこと(Level1,Scored)
重複するグループ名が存在しないこと(Level1,Scored)
.netrcファイルの存在有無を確認(Level1,Scored)
.forwardファイルの存在有無を確認(Level1,Scored)

CISが公開しいているAMIもあるんです

実は、CISがAWS Marketplaceに公開しているAMIもあります。EC2利用料に加えて、1時間あたり$0.02払えば、対策済みのOSが利用できますので、検討してみてはいかがでしょうか？

AWS Marketplace: Center for Internet Security products for sale on AWS Marketplace.

まとめ

前回の記事にも書きましたが、全てにおいてこのベンチマークの通りに設定していなければ、セキュリティ上問題がある、ということは決してありません。ちょっとクラウドらしくない項目もちらほらあるなあ、というのが正直なところでしたが、厳しいセキュリティ要件が求められるシステムでは、悪意のあるユーザによるアクセスをしっかりと防ぐまたは検知する仕組みが必須となります。ちょっと人を疑うような運用にはなりますが、外部および内部脅威対策の参考情報として、皆さんもぜひ目を通していただければと思います。

この記事が何かのお役に立てば嬉しいです。