前書き
優れたサーバー管理者は、新しい脆弱性を探します。 ポートを一般公開しているサーバーを実行する場合、そのセキュリティを固執する必要があります。
残念ながら、アプリケーションやオペレーティングシステムの最新のセキュリティパッチをすべて入手しても、サーバーはゼロデイ攻撃(パッチのない未知の脆弱性を標的とする攻撃)に対して脆弱です。 * AppArmor *は、サーバーをこのような攻撃から保護するアクセス制御システムとして機能するLinuxカーネルモジュールです。 このモジュールは、Ubuntu 8.04がリリースされて以来、デフォルトでUbuntuで利用可能です。
AppArmorがアプリケーションに対してアクティブな場合、オペレーティングシステムは、アプリケーションがそのセキュリティプロファイルで言及されているファイルとフォルダのみにアクセスすることを許可します。 したがって、適切に計画されたセキュリティプロファイルを使用すると、攻撃中にアプリケーションが危険にさらされても、それほど害を及ぼすことはありません。
このチュートリアルの対象
このチュートリアルでは、単純なAppArmorセキュリティプロファイルを作成します。これは、人気のあるHTTPサーバーである* Nginx *の権限の詳細を含むテキストファイルです。
AppArmorがどのように機能するかを示すために、2つのディレクトリから静的ファイルを提供するようにNginxを構成します。
この設定により、AppArmorが非アクティブの場合、外部ユーザーは両方のディレクトリのファイルにアクセスできます。 AppArmorがアクティブな場合、ユーザーはのファイルのみにアクセスできます。
ステップ1-Nginxをインストールする
サーバーを更新してNginxをインストールするために使用します。
sudo apt-get update
sudo apt-get install nginx
これで、Nginxサーバーが動作可能になりました。 デフォルトのサーバーはポート80で実行されます。 ブラウザでテストするには、URLとしてDropletのIPアドレスにアクセスします。 デフォルトのNginxウェルカムページが表示されます。
image:https://assets.digitalocean.com/articles/AppArmor_Nginx/1.jpg [Nginxウェルカムページ]
ステップ2:Nginxを設定して静的ファイルを提供する
静的ファイルが提供されるディレクトリを作成します。
sudo mkdir -p /data/www/safe
sudo mkdir -p /data/www/unsafe
を使用してディレクトリにファイルを追加します。
sudo nano /data/www/safe/index.html
ファイルに次の内容を含めます。
<html>
<b>Hello! Accessing this file is allowed.</b>
</html>
同様に、namedに次の内容の別のファイルを作成します。
<html>
<b>Hello! Accessing this file is NOT allowed.</b>
</html>
Nginxの構成ファイルはにあります。 このファイルを編集して、ポートでリッスンし、からファイルを提供する新しいサーバーを作成します。 編集後のコメント行を無視すると、ファイルは次のようになります。 `+ include / etc / nginx / sites-enabled / ; +`行をコメントアウトするには、ハッシュマークを追加する必要があります。 また、下に赤で示されている server *ブロック全体を追加する必要があります。
user www-data;
worker_processes 4;
pid /run/nginx.pid;
events {
worker_connections 768;
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
gzip on;
gzip_disable "msie6";
include /etc/nginx/conf.d/*.conf;
}
変更を保存し、次のコマンドを実行して新しい構成をロードします。
sudo nginx -s reload
この時点では、NginxのAppArmorがまだオンになっていないため、との両方にアクセスできるはずです。 安全なページは次のようになります。
image:https://assets.digitalocean.com/articles/AppArmor_Nginx/2.jpg [セーフページ]
Nginxの設定が完了しました。
ステップ3-既存のAppArmorプロファイルを確認する
Ubuntu 14.04には、いくつかのAppArmorプロファイルがプリロードされています。 次のコマンドでそれらをさらにインストールします。
sudo apt-get install apparmor-profiles
次のコマンドを実行して、使用可能なすべてのプロファイルをリストします。
sudo apparmor_status
かなりの数のプロファイルが表示されるはずです。 いくつかは強制モードになり、いくつかは苦情モードになります。 アプリケーションのプロファイルが* complainモード*の場合、AppArmorはアプリケーションのアクティビティを何らかの方法で制限することなく記録します。
ログに記録するものがあると、ディレクトリにNginxサーバーのログファイルが見つかります。
AppArmorは、プロファイルが*強制モード*にある場合にのみ、アプリケーションが実行できることを制限します。
また、Nginxサーバー用のプロファイルが存在しないことにも気付くでしょう。 次のステップで作成します。
ステップ4-Nginxの新しいAppArmorプロファイルを作成する
インストールします。 これらは、AppArmorの管理に役立つユーティリティのコレクションです。
sudo apt-get install apparmor-utils
これで、Nginxのアクティビティのプロファイリングを開始する準備が整いました。 コマンドを使用して、新しい空のプロファイルを作成します。 プロファイルはで作成されます。
cd /etc/apparmor.d/
sudo aa-autodep nginx
プロファイルが作成されたら、を使用してプロファイルを苦情モードにします。
sudo aa-complain nginx
Nginxを再起動します。
sudo service nginx restart
ブラウザーを開き、にアクセスします。 これにより、安全なWebサイトにアクセスするための通常のエントリがトリガーされ、Nginxログに表示されます。
ターミナルに戻ります。 次に、AppArmorユーティリティを使用して、Nginxログを調べ、そこで見つかった各アクションを承認または不承認にします。
sudo aa-logprof
このコマンドはログファイルをスキャンし、AppArmor Nginxプロファイルを更新します。 機能を許可または拒否するように何度か求められます。 サーバーが現在攻撃を受けていない場合、要求されるすべての機能はNginxが正しく機能するために必要なので、毎回* A を押すことができます。 最後に、変更を保存するように求められたら、 S *を押します。
新しいアプリケーションでAppArmorを有効にする一般的なプロセスは次のとおりです。
-
アプリケーションの新しい空のプロファイルを作成する
-
文句モードにします
-
適切なエントリがログに追加されるように、アプリケーションで通常のアクションを実行します
-
AppArmorユーティリティを実行してログを調べ、さまざまなアプリケーションアクションを承認または不承認にします
ステップ5:AppArmor Nginxプロファイルを編集する
特にNginxの場合、自動生成されたファイルを適切に機能させるには、変更を加える必要があります。 編集のために `+ / etc / apparmor.d / usr.sbin.nginx +`ファイルを開きます。
sudo nano /etc/apparmor.d/usr.sbin.nginx
少なくとも次の変更を行う必要があります。
-
`+#include <abstractions / apache2-common> +`行を追加します-はい、ハッシュマークは意図的です
-
行を追加
-
行を追加
-
ディレクトリ全体にアスタリスク(*)を含めるように行を更新します
-
コンマを含む行を追加します
-
Nginxが* w *を設定してエラーログに書き込むことができることを確認します
インクルードにより、Nginxはさまざまなポートでリッスンできます。 新しい* capability *行により、Nginxは新しいプロセスを開始できます。 * deny *ルールにより、Nginxがディレクトリにアクセスするのをブロックできます。
1つの作業プロファイルは次のようになります。
#include <tunables/global>
/usr/sbin/nginx {
#include <abstractions/base>
#include <abstractions/nis>
capability dac_override,
capability dac_read_search,
capability net_bind_service,
/data/www/safe/ r,
/etc/group r,
/etc/nginx/conf.d/ r,
/etc/nginx/mime.types r,
/etc/nginx/nginx.conf r,
/etc/nsswitch.conf r,
/etc/passwd r,
/etc/ssl/openssl.cnf r,
/run/nginx.pid rw,
/usr/sbin/nginx mr,
/var/log/nginx/access.log w,
/var/log/nginx/error.log ,
}
ログファイルに基づいて生成されたため、プロファイルは少し異なるように見える場合があります。 個々のパラメータを調査して更新するか、このファイルを大量にコピーするかは、独自のサーバー環境を検討する際の通常の注意事項に従って、あなた次第です。 AppArmorの権限は正しく取得するのが難しい場合があるため、このサンプルファイルと自動生成されたファイルを開始点として使用できますが、トラブルシューティングを行う準備をしてください。
AppArmor Nginxプロファイルの準備ができました。 を使用して、プロファイルを強制モードにします。
sudo aa-enforce nginx
すべてのプロファイルをリロードしてNginxを再起動し、最新の変更が有効であることを確認することをお勧めします。 以下を入力してください。
sudo /etc/init.d/apparmor reload
sudo service nginx restart
これらの段階のいずれかでエラーが発生した場合は、エラーを読み、構成ファイルを再確認して、正しい方向を示すように確認してください。
AppArmorのステータスを確認します。
sudo apparmor_status
Nginxプロセスが実施モードで実行されているのが見えるはずです。
ブラウザに戻ってにアクセスします。 ページが表示されるはずです。 次にをご覧ください。 次のようなエラーページが表示されます。 これは、プロファイルが期待どおりに機能していることを証明しています。
image:https://assets.digitalocean.com/articles/AppArmor_Nginx/3.jpg [禁止されたエラー]
トラブルシューティング
プロファイルの実施後にNginxサーバーの起動に失敗した場合、プロファイルにNginxが必要とする権限が含まれていない可能性があります。 確認する必要があります。
-
エラーテキスト
-
{ブランク}
-
{ブランク}
その後、これらのエラーに基づいてプロファイルを変更する必要があります。
たとえば、プロファイルに含めるのを忘れた場合、次のようなエラーが表示されます。
[emerg] 3611#0: socket() 0.0.0.0:8080 failed (13: Permission denied)
現実のシナリオでは、新しいアプリケーションの便利なAppArmorプロファイルに到達するには、多くの試行錯誤が必要であり、非常に時間がかかります。
結論
このチュートリアルでは、AppArmorプロファイルをゼロから作成する方法を学びました。 実際のシナリオでは、大規模なアプリケーションでAppArmorを有効にする前に、より厳密なプロセスに従う必要があります。
最初に、コマンドで苦情モードを有効にします。 その後、システム管理者は通常、コマンドを実行する前に数日間待機して、システムにアプリケーションのより一般的なアクションを記録する時間を与えます。 実動システムで使用されるプロファイルを作成する場合は、同じことをお勧めします。