treedown’s Report

システム管理者に巻き起こる様々な事象を読者の貴方へ報告するブログです。会社でも家庭でも"システム"に携わるすべての方の共感を目指しています。

※https化しました。その影響でしばらくリンク切れなどがあるかもしれませんが徐々に修正していきます。 リンク切れなどのお気づきの点がございましたらコメントなどでご指摘いただけますと助かります。

sambaのaudit.logを確認してみた

以前の「(1/2)Debian Jessieのsambaでファイル監視」という記事からスタート、
この辺で仕掛けたaudit.log、そのまま収集をしていましたが、ログを見る機会があってログの読み方を自分用にメモ、ということでご報告いたします。

以前の記事

sambaサーバ監視オプション(使いそうなものだけ) - treedown’s Report

(1/2)Debian Jessieのsambaでファイル監視 - treedown’s Report

(2/2)Debian Jessieのsambaでファイル監視 - treedown’s Report

の続き。

監視オプションは

以前の記載にあるように「削除」について監視したいという需要なので
「full_audit:success = rmdir pwrite rename unlink」
としていました。
ということで削除履歴を収集していました。

で、ファイルサーバからデータが消えてしまった、ということで、どこから削除が実行されたかをログから確認することに。

ログを確認

さっそくFILESVRの削除ログ確認、消えたフォルダ名「TaisyoFolder」をgrepの条件としてFILESVRからの削除確認

# cat /var/log/samba/audit.log | grep TaisyoFolder | less

これを実行したら表示されたログの一部
---------------------------------------------------------------------------------
Jan 5 11:14:43 FILESVR smbd_audit: PCNAME-1|192.168.1.44|rename|ok|共有F-1/TaisyoFolder|共有F-1/新しいフォルダ/TaisyoFolder
Jan 5 11:14:49 FILESVR smbd_audit: PCNAME-1|192.168.1.44|unlink|ok|共有F-1/新しいフォルダ/TaisyoFolder/文書.docx
Jan 5 11:14:49 FILESVR smbd_audit: PCNAME-1|192.168.1.44|unlink|ok|共有F-1/新しいフォルダ/TaisyoFolder/通達文章.docx

 …以下略…

Jan 5 11:15:01 FILESVR smbd_audit: PCNAME-1|192.168.1.44|rmdir|ok|共有F-1/新しいフォルダ/TaisyoFolder

 …削除完了…

Jan 5 14:00:56 FILESVR smbd_audit: BakSVR|192.168.1.5|pwrite|ok|共有F-1/TaisyoFolder/文書.docx
---------------------------------------------------------------------------------
11:14:43にFILESVRに対してマシン名PCNAME-1(192.168.1.44)からrename命令が実行されています。これによって「共有F-1」配下にある「TaisyoFolder」が「共有F-1」「新しいフォルダ」の下に「TaisyoFolder」が作られるということになりました。(※たぶんこの時点で消えたように見えている)

11:14:49に実際に削除が実行されます。unlink命令がそれです。おそらくはフォルダごと削除しており、ファイルが個別に削除されていく履歴がログに残っています。リネームした(フォルダ移動した?)後にまとめて消してしまったってことですね。文書.docxや通達文章.docxといったファイルが消えました。
たくさんあったから割愛。

11:15:01に最終的に全部消えてしまいましたので、空になった上流のフォルダ(実際に削除命令を送り込んだフォルダ)である「共有F-1/新しいフォルダ/TaisyoFolder」に対してrmdir命令が実行されていることが記録されています。一番最後のrmdir命令が「共有F-1/新しいフォルダ/TaisyoFolder」に対して実行されているので、カレントディレクトリ「共有F-1」の中に存在していた「TaisyoFolder」は「新しいフォルダ」配下に移動されたあとで「新しいフォルダ」ごと(丸ごと)削除をされた、という動作が見て取れます。

14:00:56にBakSVRからリストアを実行しデータ復旧、新たにデータがpwrite命令によって対象の場所にデータ復旧されたことが記録されていました。

ログの見方

まずログに「unlink」とあるレコードがファイル/フォルダの削除を表しています。
続いて今回の対象フォルダ「<\\FILESVR\共有F-1\TaisyoFolde>」と表記されている箇所を探しました。

該当レコード(複数あると思います)に「smbd_audit: マシン名」が表示されます。
※一応「IPアドレス」も表示されますので特定可能な方を使います。
この箇所にある「smbd_audit: マシン名」で該当のフォルダの削除が実行された、ということになります。
※今回はPCNAME-1というコンピュータ名でIPアドレス192.168.1.44のPCから削除が実行された、ということに。
今回の設定ではログインユーザ名を取得していないため、該当のコンピュータ名を利用している人物を特定するにはPCのユーザを確認する必要があります。(サーバでは人の特定はできません)
このあたりはユーザ名を取得するようにすれば、ログにユーザ名も併せて併記されるようになります。
 ※理由があって取得していませんが。