AWSのセキュリティ評価サービス Amazon Inspector に触れる機会があったので記録しておこうと思います。
CVE(共通脆弱性識別子)ルールパッケージでの実行結果です。
何をどう検査しているのかという細かな情報は公開されていないようでしたので、パッケージ導入状態と実行時間により評価結果が変わるかを調べました。 (結果謎な部分は謎なままです)
評価テンプレートの時間が長いほど、Amazon Inspector は、より詳細かつ包括的なテレメトリーのセットを収集して分析します。 つまり、分析時間が長くなることで、Amazon Inspector は評価ターゲットの動作を細部にわたって確認し、より詳細な結果を提示できるようになります。
評価検証
- AmazonLinux に対して Common Vulnerabilities and Exposures-1.1 で評価を実行
- Duration 15min/1h/8h/12h/24h の結果を比較
結果
今回の検証結果は以下のとおりです。
- コンパイルした置き換えバイナリと同様に標準以外のリポジトリからの導入パッケージは検査されない
- パッケージの changelog のみで評価を行っているわけではない
- 今回の検証では実行時間による評価結果の変動は無かった
- サポートされるOSでも AWSエージェントのインストールは行えてしまう、コンソール上も特にエラー・警告は無い
- サポートされるOSは Amazon Inspector のセットアップ 参照
実行時間が長くなる事により外部パッケージでの導入状態も検査するようになってくれるかなという期待があったのですが、 変動はありませんでした。 せめて誤検知(ソースからの導入等)用に除外条件設定ができるようになると使い勝手が良くなるのではと思いました。
評価実施OS
CentOSも検証しようと思いましたが、AMI立ち上げ時点で検出結果0だったため、パターン検証からは除外しています。
(Findings としては Informational で No potential security issues found の出力となりました)
OS(Amazon Linux)状態パターン
- a) 初期状態
- AMIから起動しただけで他に何も手を入れていない状態
- b) yum upgrade 実施
- c) 外部リポジトリからパッケージ導入
- Nginx、MySQL5.7 を公式 rpm から導入
- d) 外部リポジトリからパッケージ導入 + changelog書き換え
Findings(検出結果)
Duration(実行時間)で選択可能な時間全てで実施しています。
- Duration別検出数
| Duration | a | b | c | d |
|---|---|---|---|---|
| 15min | 3 (2pkg) | 0 | 9 (1pkg) | 9 (1pkg) |
| 1h | 3 (2pkg) | 0 | 9 (1pkg) | 9 (1pkg) |
| 8h | 3 (2pkg) | 0 | 9 (1pkg) | 9 (1pkg) |
| 12h | 3 (2pkg) | 0 | 9 (1pkg) | 9 (1pkg) |
| 24h | 3 (2pkg) | 0 | 9 (1pkg) | 9 (1pkg) |
パターン a 検出結果
Severity が High で3つの CVE(2つのパッケージ) が検出されました。
opensslとkernelのバージョンを上げなさいという結果です。
パターン b 検出結果
yum でのパッケージ最新化を行った状態では検出結果 0 となりました。
導入しているパッケージが少なく、且つ、最新状態なので当然の結果です。
パターン c 検出結果
Severity = High で 8つ、 Medium が1つ検出されました。
パッケージは全て nginx です。
通常だと外部リポジトリのパッケージについては検査してくれないようです。
パターン d 検出結果
changelog の CVE No を見て判断しているのかもしれないと思い、試してみました。
Nginx 公式のパッケージの changelog に CVE No を追記しています。
結果、changelog 書き換えで検知結果が変わる事はありませんでした。(パターン c と同じ結果でした)
CVE No が含まれています。
[ec2-user@ip-172-30-0-95 ~]$ rpm -qa | grep nginx nginx-1.10.1-1.28.amzn1.x86_64 [ec2-user@ip-172-30-0-95 ~]$ rpm -q --changelog nginx | grep CVE - CVE-2016-0747: Insufficient limits of CNAME resolution in resolver - CVE-2016-0746: Use-after-free during CNAME response processing in resolver - CVE-2016-0742: Invalid pointer dereference in resolver - CVE-2014-3616 nginx: virtual host confusion (#1142573) - (#1126891) CVE-2014-3556: SMTP STARTTLS plaintext injection flaw - add patch for CVE-2013-4547 CVE-2013-2028 stack-based buffer overflow when handling certain chunked - Add security patch to fix CVE-2011-4315
- Nginx 公式から導入
CVE No が含まれていません。
[ec2-user@ip-172-30-0-7 ~]$ rpm -qa | grep nginx nginx-1.11.6-1.el6.ngx.x86_64 [ec2-user@ip-172-30-0-7 ~]$ rpm -q --changelog nginx | head * 火 11月 15 2016 Konstantin Pavlov <thresh@nginx.com> - 1.11.6 * 月 10月 10 2016 Andrei Belov <defan@nginx.com> - 1.11.5 * 火 9月 13 2016 Konstantin Pavlov <thresh@nginx.com> - 1.11.4. - njs updated to 0.1.2. [ec2-user@ip-172-30-0-7 ~]$ rpm -q --changelog nginx | grep -c CVE 0
- Nginx 公式からソースパッケージを取得し、changelogに CVE No を追加して rebuild
無理矢理 CVE No を追加してみました。この状態で Inspector での検査を行いました。
[ec2-user@ip-172-30-0-248 ~]$ rpm -qa | grep nginx nginx-1.11.6-1.amzn1.ngx.x86_64 [ec2-user@ip-172-30-0-248 ~]$ rpm -q --changelog nginx | head * 火 1月 26 2016 Jamie Nguyen <jamielinux@fedoraproject.org> - 1:1.8.1-1 - update to upstream release 1.8.1 - CVE-2016-0747: Insufficient limits of CNAME resolution in resolver - CVE-2016-0746: Use-after-free during CNAME response processing in resolver - CVE-2016-0742: Invalid pointer dereference in resolver * 水 9月 17 2014 Jamie Nguyen <jamielinux@fedoraproject.org> - 1:1.6.2-1 - update to upstream release 1.6.2 - CVE-2014-3616 nginx: virtual host confusion (#1142573)
