Dockerコンテナは不変であるため優れています。 Dockerにはコピーオンライトファイルシステムが付属しているため、適切なコミットを作成した場合にのみベースイメージを変更できます。
この機能は、たとえば、ハッカーの攻撃を調査するときに役立ちます。 コンテナファイルシステムとベースイメージの不一致を簡単に確認できるようにすることで、攻撃者による変更を確認できます。
デモアプリケーション
例として次のインフラストラクチャを取り上げます。
フロントエンドという名前のサーバーで実行されているPHPアプリケーションと、別のマシン上のMySQLデータベースがあります。 （ 編集者はサードパーティのリポジトリに対して責任を負わず、未検証のソースからソフトウェアをインストールすると望ましくない結果につながる可能性があることを想起します。 ）
➜ docker run -d --name db -e MYSQL_ROOT_PASSWORD=insecurepwd mariadb ➜ docker run -d -p 80:80 --link db:db diogomonica/phphack
使用可能なデータベースとクライアント側が自由に使えるようになったので、次のようなメッセージが表示されるはずです。
残念ながら、実世界の2つおきのPHPアプリケーションのように、攻撃者が任意のコードをリモートで実行できるようにするテスト例に穴があります。
if($links) { <h3>Links found</h3> ... eval($_GET['shell']); ?>
誰かが間違った場所でevalを使用しているようです！ したがって、潜在的な攻撃者は不注意を利用して、脆弱なサーバーで任意のコードを実行できます。
➜ curl -s http://localhost/\?shell\=system\("id"\)\; | grep "uid=" uid=33(www-data) gid=33(www-data) groups=33(www-data)
ハッキングされたマシンでは、ハッカーは通常、快適になろうとします。PHPシェルとさまざまなツールキットをダウンロードします。 一部のクラッカーは、サイトの外観とコンテンツを置き換える傾向があります。
攻撃後に回復する
コピーオンライトファイルシステムによって提供される素晴らしい機能の1つは、コンテナー内の変更を表示する機能です。 docker diffは、クラッカーがファイルに対して行ったことを表示します。
➜ docker diff pensive_meitner C /run C /run/apache2 A /run/apache2/apache2.pid C /run/lock C /run/lock/apache2 C /var C /var/www C /var/www/html C /var/www/html/index.html A /var/www/html/shell.php
とても面白い！ 攻撃者はindex.html変更しただけでなく、 shell.phpという名前のPHPシェルもロードしたことがshell.php 。 ただし、最初にサイトを復元する必要があります。
さらに調査するために、 docker commitされたシステムのイメージをdocker commit保存できます。 コンテナは安定していないため、 手首を軽く振ってdiogomonica / phphackをリロードし、通常の操作に戻ります。
➜ docker commit pensive_meitner sha256:ebc3cb7c3a312696e3fd492d0c384fe18550ef99af5244f0fa6d692b09fd0af3 ➜ docker kill pensive_meitner ➜ docker run -d -p 80:80 --link db:db diogomonica/phphack
保存された画像を取得して、クラッカーが行った変更を確認しましょう。
➜ docker run -it ebc3cb7c3a312696e3fd492d0c384fe18550ef99af5244f0fa6d692b09fd0af3 sh
SUPER ELITE GROUP OF HACKERSのメンバーがちょうど私たちをハッキングしたようです。
攻撃コストを増やします
もちろん、攻撃後のコンテナの変更を確認できると便利ですが、攻撃自体を回避する方法はありますか？
これを行うために、コンテナファイルシステムへの変更を禁止するようにDockerに指示する--read-onlyオプションがあります。 これをインストールすると、 index.htmlの変更が妨げられる可能性がありますが、攻撃者がシェルまたは必要な他のツールをロードできないことがはるかに重要です。
仕組みを見てみましょう。
➜ docker run -p 80:80 --link db:db -v /tmp/apache2:/var/run/apache2/ -v /tmp/apache:/var/lock/apache2/ --sig-proxy=false --read-only diogomonica/phphack ... 172.17.0.1 - - [04/Sep/2016:03:59:06 +0000] "GET / HTTP/1.1" 200 219518 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36 OPR/39.0.2256.48" sh: 1: cannot create index.html: Read-only file system
ファイルシステムが読み取り専用になったため、クラッカーによるindex.html変更index.html失敗しました。
これは100％の保証を提供しますか？
まさか。 既存のRCEの脆弱性を修正するまで、ハッカーはマシン上で任意のコードを自由に実行し、たとえば識別情報を盗んだり、データベースからデータを盗んだりすることができます。
それにもかかわらず、システムをクラックしようとするハッカーの生活を著しく複雑にする本当の機会があります。 これを行うには、Dockerセキュリティ機能と最小限のコンテナーイメージを使用します。
おわりに
アプリケーションのセキュリティが絶対的なものになることはありません。 ただし、不変のインフラストラクチャを使用すると、ハッカーの作業が大幅に複雑になる可能性があり、ハッキングが発生した場合、復旧手順がはるかに簡単になります。
したがって、安全性と安定性のために、いくつかのハンドルを締めて、コンテナの防御を強化することは非常に可能です！