aws-recipe-user 大柳です。
個人情報や企業の営業秘密など機密性の高い情報をシステムで扱う場合には、権限を持ったユーザのみファイルにアクセスできる設定を行うだけでなく、誰が、いつ、どのようにして、そのファイルにアクセスしたかの監査情報を求められることがあります。ファイル監査と呼ばれます。
Linuxではauditdを用いてファイル監査を行うことができます。今回はauditdを利用してAWSのマネージドサービスだけでファイル監査ログを取得し、不正アクセスがあった場合に即時に通知する仕組みを作ってみます。
今回のゴール
Amazon Linuxにauditdでファイル監査の設定を行い、CloudWatch Logsにログを連携して、監視できるようにします。
記事は２回に分けて、前半はauditdの設定までを説明します。
auditdとは
Linux上のカーネルレベルでシステムコールを監視することで、各種イベントを記録するコンポーネントです。
今回利用するファイルアクセスの監視だけでなく、ユーザが実行したコマンド、セキュリティイベント（ログイン失敗など）のように幅広くセキュリティ監視に利用できます。
なお、システムコールの都度、フィルター処理が動くので、パフォーマンスへ影響が出る可能性がありますので、利用にあたっては注意が必要です。
詳しい仕組みは以下の記事が分かりやすいです。
第5章 システム監査
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/chap-system_auditing.html#sec-audit_system_architecture
auditd設定手順
ではauditdの設定を行っていきます。
auditdのインストール確認
Amazon Linuxには標準でauditdがインストール済です。
念のため、インストールされていること、起動していることを確認しましょう。
インストールされているかの確認
|
1 2 3 |
$ yum list installed | grep audit audit.x86_64 2.4.1-5.27.amzn1 installed audit-libs.x86_64 2.4.1-5.27.amzn1 installed |
起動しているかの確認
|
1 2 3 4 5 |
$ chkconfig --list | grep audit auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off $ service auditd status auditd (pid 2173) is running... |
auditdの設定
auditdが動いていることが確認できたら、auditdの設定を行います。
ログの出力場所や出力形式に関する設定は /etc/audit/auditd.conf にあります。
今回はログの出力先がデフォルト値（/var/log/audit/audit.log）になっていることを確認して設定は変えません。
/etc/audit/auditd.confの設定内容
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
# # This file controls the configuration of the audit daemon # log_file = /var/log/audit/audit.log log_format = RAW log_group = root priority_boost = 4 flush = INCREMENTAL freq = 20 num_logs = 5 disp_qos = lossy dispatcher = /sbin/audispd name_format = NONE ##name = mydomain max_log_file = 6 max_log_file_action = ROTATE space_left = 75 space_left_action = SYSLOG action_mail_acct = root admin_space_left = 50 admin_space_left_action = SUSPEND disk_full_action = SUSPEND disk_error_action = SUSPEND ##tcp_listen_port = tcp_listen_queue = 5 tcp_max_per_addr = 1 ##tcp_client_ports = 1024-65535 tcp_client_max_idle = 0 enable_krb5 = no krb5_principal = auditd ##krb5_key_file = /etc/audit/audit.key |
監査のルールに関する設定は /etc/audit/audit.rules にあります。
今回は、以下の設定を行います。
①システムコール監査の有効化(Amazon Linuxではデフォルトで無効）
-a never,taskの行をコメントアウト（先頭に#を付ける）
②監視するファイルパスの指定
-w /home/ec2-user/audit_test/ConfidentialInfo.txt -p rwxa -k file_audit
各オプションの意味は以下の通りです。
-w /home/ec2-user/audit_test/ConfidentialInfo.txt ： 監視するファイルパスの指定。今回はファイルを指定していますが、ディレクトリ指定も可能です。
-p rw ： ログ記録するパーミッションの指定。今回はRead、Writeを指定しています。
-k file_audit ： ログに対するキー指定オプションが設定できます。後からログを検索しやすくするためにfile_audit というキーを指定しました。
audit.rulesは以下のように設定しました。
/etc/audit/audit.rulesの設定内容
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# This file contains the auditctl rules that are loaded # whenever the audit daemon is started via the initscripts. # The rules are simply the parameters that would be passed # to auditctl. # First rule - delete all -D # Increase the buffers to survive stress events. # Make this bigger for busy systems -b 320 # Disable system call auditing. # Remove the following line if you need the auditing. #-a never,task # Feel free to add below this line. See auditctl man page -w /home/ec2-user/audit_test/ConfidentialInfo.txt -p rw -k file_audit |
ファイル監査テスト用のファイルを作成
テスト用にrootユーザで
/home/ec2-user/audit_test/ConfidentialInfo.txtを作成し、所有者(root）のみアクセスできる権限(700)を付けました。
|
1 2 3 |
$ ls -ltr total 4 -rwx------ 1 root root 13 Feb 20 11:47 ConfidentialInfo.txt |
auditdのリスタート
service auditd restart でauditdをリスタートすると設定が反映されます。
|
1 2 3 |
$ sudo service auditd restart Stopping auditd: [ OK ] Starting auditd: [ OK ] |
/var/log/audit/audit.log を確認するとログが出力されていることが確認できます。
システムコールを拾うため、今回設定したファイルパスへのアクセス以外の情報(例えばrestart時のログ)も出力されています。
ログ出力の確認
ファイル監査が動き始めたので、実際にログが出る操作をやってみましょう。
rootユーザで書き込み操作
rootユーザ(アクセス権限あり)で echo ‘Bad Data’ >> ConfidentialInfo.txt を実行します。
grepで file_audit に絞ると以下のメッセージの出力を確認できます。
uid=0(root)での/bin/bashの実行が成功したこと（success=yes）が確認できます。
|
1 |
type=SYSCALL msg=audit(1487591927.003:135): arch=c000003e syscall=2 success=yes exit=3 a0=1543100 a1=441 a2=1b6 a3=fffffff0 items=2 ppid=2806 pid=2807 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="bash" exe="/bin/bash" key="file_audit" |
ec2-userで読み込み操作
次にec2-user（アクセス権限なし）で view ConfidentialInfo.txt を実行します。
uid=500(ec2-user)での/bin/viの実行が失敗したこと（success=no）が確認できます。
|
1 |
type=SYSCALL msg=audit(1487591778.124:122): arch=c000003e syscall=2 success=no exit=-13 a0=169c3b0 a1=0 a2=0 a3=7fff6128b190 items=1 ppid=2576 pid=2804 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="view" exe="/bin/vi" key="file_audit" |
なお、auditログのフォーマットの詳細は以下サイトに記載があります。
5.6. Audit ログファイルについて
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Understanding_Audit_Log_Files.html
uidしか出ないのでユーザ名が分からず、タイムスタンプもUnix時間（1487591778だと2017/02/20 20:56:18）で表示されるので、可読性は良くありません。
また、上記のログ確認時にはgrepで絞ってみましたが、ログには他のメッセージも多数出力されています。システムコールを幅広く拾ってしまうためです。
ログ監視運用時には、必要なログを漏れなく効率よく検知できるように、監視ルールの設計が重要です。
まとめ
今回はAmazon Linuxでのauditdの設定とログ確認までを行いました。ログの可読性はあまりよくありませんが、簡単にファイル監査の設定を行うことができました。次回はCloudWatch Logsを使ってauditdのログ監視を設定します。
次回もお楽しみに。
