IBM TechXchange Japan QRadar User Group

 View Only

QRadar SIEMで Linuxに導入されたSambaの認証ログを解析したいとき

By Katsuyuki Hirayama posted Thu November 17, 2022 01:39 AM

  
更新履歴
2022/11/24 ドメインがブランクの場合にユーザー名を取得できない問題を修正

はじめに

Samba は、Windowsネットワーク共有機能を実装したソフトウェアで、多くのLinuxディストリビューションで利用できます。Windowsとの相互運用性が必要な場合だけでなく、Linux間のファイル共有にも利用できますので、採用されているケースは多いのではないでしょうか。

今回は、Linux OS上で稼働するSambaが出力するログの一部を QRadar SIEMに転送し、他のマシンからSambaの共有フォルダーにアクセスした際に出力される認証ログを、QRadar SIEMの標準ルールで監視してみたいと思います。


トップに戻る

Sambaの認証ログをQRadar SIEMに転送する

Sambaの共有フォルダーにアクセスを試みると、どのようなログが出力されるのでしょうか。

それを確認するために、Ubuntu 20.04  環境にSambaを導入して試してみました。
# Sambaの導入方法については、インターネットを検索すると多数の情報が見つかると思います。

Sambaの設定

Sambaの設定ファイルは、/etc/samba/smb.conf にありますので、その中の [global] セクションに以下を定義します。

log level = 1 auth_audit:3

service smbd restart で反映させます。

デフォルトで logging = file が定義されており、「/var/log/samba」の下に「log.ホスト名またはIPアドレス」という名前でログが書き込まれます。確認したところ、以下の3パターンのログが出力されていました。

認証成功時 (ユーザー名「ibmuser」)
  Auth: [SMB2,(null)] user [ISS]\[ibmuser] at [Tue, 15 Nov 2022 11:56:15.758850 JST] with [NTLMv2] status [NT_STATUS_OK] workstation [ISSMGMT01] remote host [ipv4:172.30.34.17:61575] became [RED]\[ibmuser] [S-1-5-21-2556298376-1522818397-933809571-1000]. local host [ipv4:172.30.34.120:445]

認証失敗時 (存在しないユーザー「111」)
  Auth: [SMB2,(null)] user [ISS]\[111] at [Tue, 15 Nov 2022 11:49:54.640921 JST] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] workstation [ISSMGMT01] remote host [ipv4:172.30.34.17:61567] mapped to [ISS]\[111]. local host [ipv4:172.30.34.120:445]

認証失敗時 (ユーザー名「ibmuser」のパスワードが異なる)
  Auth: [SMB2,(null)] user [ISS]\[ibmuser] at [Tue, 15 Nov 2022 11:53:51.082043 JST] with [NTLMv2] status [NT_STATUS_WRONG_PASSWORD] workstation [ISSMGMT01] remote host [ipv4:172.30.34.17:61570] mapped to [ISS]\[ibmuser]. local host [ipv4:172.30.34.120:445]

どのようなアクセスを試みたのかを表すステータス (NT_STATUS_OK, NT_STATUS_NO_SUCH_USER, NT_STATUS_WRONG_PASSWORD) と、ユーザー名 や IPアドレスなどの情報が含まれているため、SIEMの相関分析に使用できそうです。

なお、「auth_audit:3」ではなく「auth_json_audit:3」を指定した場合は、JSON形式でログが記録されます。
多数のプロパティーを抽出したい場合は、こちらのほうが向いているかもしれません。

  {"timestamp": "2022-11-14T17:28:39.929314+0900", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4624, "logonId": "0", "logonType": 3, "status": "NT_STATUS_OK", "localAddress": "ipv4:172.30.34.120:445", "remoteAddress": "ipv4:172.30.34.17:61221", "serviceDescription": "SMB2", "authDescription": null, "clientDomain": "ISS", "clientAccount": "ibmuser", "workstation": "ISSMGMT01", "becameAccount": "ibmuser", "becameDomain": "RED", "becameSid": "S-1-5-21-2556298376-1522818397-933809571-1000", "mappedAccount": "ibmuser", "mappedDomain": "ISS", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv2", "duration": 25479}}

QRadar SIEMでログを確認するためには、ファイルに書き込むだけではなく、Syslogに転送する必要があります。
そこで、デフォルトの logging = file を、「logging = syslog@3 file」に変更します。(「3」は、「LOG_INFO」を意味します)

最終的な smb.conf への変更内容は、以下のとおりです。

logging = syslog@3 file
log level = 1 auth_audit:3

これにより、/var/log/samba への書き込みに加えて、Syslog にログが転送されます。

rsyslogの設定

SambaからSyslogに転送されたログは、rsyslogの構成ファイルに従って、ローカル ファイルに書き込んだり、リモートに転送したりできます。今回は、QRadar SIEMに転送します。

認証に関係するSambaログのみをQRadar SIEMに転送できるように、/etc/rsyslog.conf (または インクルード設定のある /etc/rsyslog.d/ 配下にある conf ファイル) に、以下を定義します。

:msg,contains,"Auth: [SMB2" @SIEMのIPアドレス
& stop

これにより、前述のSambaログの前に Syslog ヘッダーが付いたペイロードが、QRadar SIEMに転送されます。

Syslog経由でSIEMに届くペイロードの例 (「red」は Sambaマシンのホスト名)
<29>Nov 15 11:56:15 red smbd[7370]: Auth: [SMB2,(null)] user [ISS]\[ibmuser] at [Tue, 15 Nov 2022 11:56:15.758850 JST] with [NTLMv2] status [NT_STATUS_OK] workstation [ISSMGMT01] remote host [ipv4:172.30.34.17:61575] became [RED]\[ibmuser] [S-1-5-21-2556298376-1522818397-933809571-1000]. local host [ipv4:172.30.34.120:445]

トップに戻る

SambaのためのカスタムDSM(uDSM)

SambaのログをQRadar SIEMに転送すると、QRadar SIEMに定義されているログソースが、パーシングや正規化を行います。

Sambaのログを監視したいケースでは、Linux OS の他のログも監視しているかもしれません。
具体的には、authpriv のログと Auditd のログを、QRadar SIEMに転送するように設定しているケースが考えられます。

Sambaログを標準の Linux OS DSM で受信すると、以下のように「smbd Message」という一般的な情報イベントとして正規化されます。

情報イベントは 標準ルールによる脅威検知で使用することが難しいため、認証成功 や 認証失敗 のカテゴリーに再度マッピングしたいところです。
しかし、製品標準のLinux OS DSM は継続的な更新が行われているため、今後も新しいリリースが提供されるかもしれません。

そこで、標準DSMの影響を受けずに必要な定義を行う手段として、Samba専用のカスタムDSM (uDSM) を作成したいと思います。

カスタムDSM(uDSM)の作成には、DSMエディターを使用します。
使用方法については、既に「QRadar CE (Community Edition) 7.3.3 にカスタム・ログを取り込んで分析しましょう (カスタムDSM) 」で説明していますので、そちらをご覧ください。

今回は、Samba用カスタムDSMの内容に絞って説明します。

管理画面の「DSMエディター」をクリックし、「ログソースタイプの選択」で「新規作成」から新しいログソースタイプ名を入力します。
例えば「Linux Samba custom」など、任意の名前を付けます。(将来、ベンダーが新たに提供するかもしれないDSMと 競合しそうな名前は避けましょう)

DSMエディターを使用する際には、先ほどのSambaログのサンプルが非常に役に立ちます。
DSMエディターのワークスペースにテキスト形式のログをペーストすることで、パーシングした結果を確認しながら作業できるためです。

正規化マッピングに必須となる イベントIDフィールド と イベント・カテゴリーフィールド、さらに認証ログに不可欠なユーザー名などのフィールドを、正規表現で切り出していきます。

今回Samba用に切り出したフィールドは、以下のものです。
正規表現の多くは、DSMエディターの「正規表現の推奨」をクリックすることで自動的に生成できましたが、いくつかは自分で考える必要がありました。

名前 式のタイプ フォーマット 日付形式
イベントID 正規表現 status\s\[([^\]]+) $1
イベントカテゴリー 正規表現 \[\d+\]:\s+(\w+):\s $1
ユーザー名 正規表現 user\s\[\w*\]\\\[(\w*)\] $1
ログソースの時刻 正規表現 at\s\[([^\]]+) $1 EEE, dd MM yyyy HH:mm:ss.SSSSSS z
宛先IP 正規表現 ]\.\s\w+\s\w+\s\[\w+\d:(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}):\d+\] $1
宛先ポート 正規表現 ]\.\s\w+\s\w+\s\[\w+\d:\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}:(\d+)\] $1
送信元IP 正規表現 ] remote host \[\w+\d:(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}):\d+\] $1

これによって必要なプロパティーが抽出され、DSM定義の一部である ログソース拡張(LSX) を作ることができます。

次に、イベントID + イベントカテゴリー の組み合わせ ごとに、新しい QIDを作成してマッピングしていきます。今回は3種類だけです。

イベントID イベントカテゴリー 名前 上位カテゴリー 下位カテゴリー 重大度 説明
NT_STATUS_OK Auth Samba NT_STATUS_OK 認証 ユーザー・ログイン成功 1 Samba NT_STATUS_OK
NT_STATUS_NO_SUCH_USER Auth Samba NT_STATUS_NO_SUCH_USER 認証 ユーザー・ログイン失敗 3 Samba NT_STATUS_NO_SUCH_USER
NT_STATUS_WRONG_PASSWORD Auth Samba NT_STATUS_WRONG_PASSWORD 認証 ユーザー・ログイン失敗 3 Samba NT_STATUS_WRONG_PASSWORD

一連の作業が完了すると、DSMエディターのプレビュー欄が「解析してマップ済み」となり、最終的な情報が表示されます。

これを「保存」すると、ログソースタイプとして使用できるようになり、Log Source Management からログソースの定義を行うことができます。
また、「エクスポート」すると、他のQRadar SIEM環境にインポートして、ログソースタイプとして利用できるようになります。

インポートは、他の一般的なアプリやコンテンツ拡張と同じように、管理画面の「拡張の管理」から行います。

執筆者の環境で作成済みの Linux Samba custom カスタムDSM定義は、以下よりダウンロードできます。
(IBMによる正式サポートはありません。開発環境などで動作確認することをおすすめします)
(署名されていないため、インポート時に警告が出ます)

https://ibm.box.com/s/t3yuza38m7i463nvdpayg4pwyuhstir9

以下を入力:
useqradar+samba!

次に、管理画面の「Log Source Management」から、Samba用のログソースを定義します。
作成したばかりのログソースタイプ (この例では Linux Samba custom) を指定し、必要なパラメーターを入力します。

概要
名前 Samba @ red (任意の名前)
説明 (任意の説明)
有効 はい
ログ・ソース・タイプ Linux Samba custom (作成したカスタムDSMのログソースタイプ名)
プロトコル・タイプ Syslog
グループ (任意)
拡張機能 LinuxSambaCustomCustom_ext (作成したカスタムDSMに付随して作成されたLSX名)
言語 英語
ターゲット・イベント・コレクター 環境に合わせて設定
Disconnected Log Collector 環境に合わせて設定
信頼性 5 (環境に合わせて設定)
イベントの統合 はい (要件に合わせて設定)
イベント・ペイロードの保管 はい
プロトコル
ログ・ソース ID red (Sambaマシンのホスト名など)
受信ペイロードのエンコード UTF-8

ログソースの追加後は、デプロイが必要になります。

同一マシン (つまり同一ログソースID) で Sambaのログソース と  Linux OS ログソースが混在する場合 (一般的なケースだと思います) は、「ログソースの構文解析順序」において、Samba を Linux OSよりも上に定義する必要があります。

以下の例では、#3 の 「Samba @ red」ログソースが、#4の 「Linux OS @ red」よりも先に処理されます。

トップに戻る

おわりに

Samba用のカスタムDSMを作成することで、標準のLinux OS DSMの影響を受けることなく、認証成功 や 認証失敗 のカテゴリーで、正規化したメッセージを受け取ることができるようになりました。

これにより、認証カテゴリーのイベントを監視している標準ルールをトリガーできるようになり、Sambaの認証ログからもオフェンスを生成できます。

Linux OS の DSMは、同じOS上で動作する様々なサービスのログを受信する可能性があるため、Sambaのような特定サービスのログの正規化について、必ずしも最適ではない場合があります。
そのような場合でも、QRadar SIEMのDSMエディターを使用することで、個々の要件に合ったカスタムDSMを、比較的容易に作り出すことができます。

トップに戻る


参考文献
​​​

#QRadar
0 comments
13 views

Permalink