認証ログは、ログイン試行、権限変更、session activity を説明する助けになります。セキュリティ上重要な証拠ですが、一行だけでユーザーの意図を確定したり、アカウント侵害を証明したりすることはほとんどできません。
ロギング · レッスン 5
認証ログ
Linux の認証レコードを見つけ、解釈し、安全に相関する方法を学びます。
認証レコードを見つける
Debian 系の syslog 設定は認証イベントを /var/log/auth.log へ、Red Hat 系は /var/log/secure へ route するのが一般的です。systemd journal が同じイベントを unit・process metadata とともに保持する場合や、集中ログが authoritative copy を持つ場合もあります。
ローカルの宛先を見つけ、関連サービスを問い合わせます。
$ sudo journalctl -u ssh.service --since '1 hour ago'
$ sudo less /var/log/auth.log
SSH unit は ssh.service または sshd.service の場合があります。アカウントとアクセスの詳細が含まれるため、通常レコードの権限は制限されています。
Linux の認証イベントは、必ずどこに保存されますか？
イベントを解釈する
従来形式のレコード例です。
Jan 31 10:37:50 icebox pkexec: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
時刻、host、発信 program、PAM module と service、要求された session user、発信元 UID を識別できます。これだけでは UID 1000 の背後にいる人物を特定できず、悪意ある操作とも証明できません。障害時点で有効な account record から UID を解決し、terminal、remote address、session、周辺イベントと相関させます。
このレコードの uid=1000 から何が分かりますか？
成功と失敗を調査する
限定した時間範囲で、accepted と rejected の試行をどちらも検索します。SSH では connection source、authentication method、target account、session open/close、service restart も調べます。失敗の繰り返しは、ユーザーの誤り、古い認証情報を持つ自動処理、scan、attack のいずれでも起こります。頻度だけで一つに決めることはできません。
last と lastb は、維持されていれば wtmp と btmp のレコードを要約できますが、これらの binary database にも retention と integrity の限界があります。journal、syslog、集中ログと照合してください。
失敗ログインの繰り返しは何と相関させるべきですか？
保存して対応する
incident が疑われる場合、host time と timezone を記録し、元ログと metadata を保持し、export copy を安全に保護します。証拠をその場で編集してはいけません。account lock、firewall change、session termination は正当なアクセスを中断したり、攻撃者へ気付かせたりする可能性があるため、incident-response process に従い、復旧経路を維持します。
調査中の認証証拠はどのように扱うべきですか？
レッスン完了
認証ログ を完了しました
これで、一つのレコードから分かることを過大評価せず、認証イベントを調べられます。
ローカルで設定された認証ログの宛先を見つける。
identity、service、method、session field を文脈の中で解釈する。
保存された複数情報源で、失敗・成功 activity を相関させる。
証拠を保持し、中断を伴う対応操作を調整する。