更新履歴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環境にインポートして、ログソースタイプとして利用できるようになります。
インポートは、他の一般的なアプリやコンテンツ拡張と同じように、管理画面の「拡張の管理」から行います。
次に、管理画面の「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