HrsTのあれこれ

TA-dmarc add-on for SplunkでExchange Onlineにアクセスしよう

TA-dmarc add-on for Splunk | Splunkbase でExchange Onlineにアクセスしよう

2022年11月時点ではExchange OnlineのIMAPは基本認証が使えないはずですので、モダン認証(OAuth2)を使う必要があります。WEBアプリ開発者でない方にとってはどうすれば？と途方に暮れているかもしれませんのでお役に立てればと思います。

ということで、最新のSplunkとTA-dmarcをセットアップしましょう。

TA-dmarcの[入力]の[Create New Input]に[DMARC imap(oauth2)]が表示されていることを確認します。 (TA-dmarc v4.1.1以降が必要です）

また、この作業を行う前に、DNSでDMARCレコードを公開または「rua=mailto:<EMAIL>」を追記し統計レポートを受け取ることを確認しましょう。
統計レポートはドメインごとに24時間に1度の頻度なので届くのは翌日だと思います。

設定の流れ

TA-dmarcで使用するアカウント情報を作成する
TA-dmarc Account登録
メールボックスの権限設定
TA-dmarc Inputの登録
動作確認

TA-dmarcで使用するアカウント情報を作成する

Azure ADポータルの[管理]>[アプリの登録]を開き、[新規登録]を選択します。

[名前] 管理しやすい名前を付けましょう。
[サポートされているアカウントの種類] 用法に合わせて選択ですが「この組織ディレクトリのみに含まれるアカウント」でよいと思います。
[リダイレクト URL] 「Web」を選び「https://localhost」に設定します。

[登録]を選択すると登録したアプリの[概要]に画面が変わります。

表示された"アプリケーション (クライアント) ID"の値は"Username"として後ほど利用します。

次に[管理]>[証明書とシークレット]を開き[新しいクライアントシークレット]を選択します。

[説明] 任意の名前
[有効期限] セキュリティ面を考慮すると短い方が良いですが運用とのバランスもありますのでお任せします。

[追加]を選択します。
追加されたシークレットの[値]を"Password"で使用します。このページから離れると二度と確認できませんので気を付けてください。

わからなくなったらシークレットを作成してください。使わなくなったシークレットは忘れず削除しましょう。

TA-dmarcでアカウントを登録する

先ほど作成したアプリの情報を使い設定します。

アカウント登録

Splunkの[TA-dmarc]>[設定]>[Account]の追加を行います。

Account name: わかりやすい名前を設定します。（有効期限を入れておく良いかも）
Username: Azure ADのアプリの"アプリケーション（クライアント）ID"です。
Password: "証明書とシークレット"で作成したシークレットの値になります。

パスワードには有効期限がありますので期限切れになる前に更新してください。

メールボックスの権限設定

メールボックスには作成したアプリを使用して接続しますので権限設定が必要です。

とりあえずPowerShellでExchange Onlineに接続しましょう。

Install-Module -Name ExchangeOnlineManagement
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -Organization <TENANTID>

<TENANTID> Azure ADの概要または、作成したアプリの概要で確認できます。

New-ServicePrincipal -AppId <CLIENTID> -ServiceId <OBJECTID>
Add-MailboxPermission -Identity "<EMAIL>" -User <OBJECTID> -AccessRights FullAccess

<CLIENTID> アプリ登録、アカウント登録で使用した "アプリケーション（クライアント）ID"です。
<OBJECTID> Azure ADの[エンタープライズアプリケーション]からアプリ登録で使用した名前を開くと[概要]の”オブジェクト ID”に表示されています。
<EMAIL> TA-dmarcから接続するメールアドレスです。
DNSのDMARCレコードに設定した「rua=mailto:<EMAIL>」

実行してエラーが出なければ権限設定は完了なのでExchange Onlineを切断しましょう。

Disconnect-ExchangeOnline

TA-dmarc Inputの登録

TA-dmarcの[入力]>[Create New Input]で[DMARC imap(oauth2)]を選択します。

基本的には初期値のままでよいです。

Name:任意の名前
Interval:受信チェックする間隔を秒で指定します。(例：3600)
Grobal Account: 事前に登録したアカウントを選択します。
IMAP server: 初期値の[outlook.office365.com]
IMAP username: 権限設定で使用したメールアドレスを入力 <EMAIL>
OAuth2 Authority: 「https://login.microsoftonline.com/<tenant_id>」
<tenant_id>は権限設定で使用した<TENANTID>です。

入力出来たら[追加]を選択します。

動作確認

正しく設定できていれば受信済みレポートの取り込みが始まります。

サーチで「| inputlookup ta_dmarc_checkpointer_lookup」を実行すれば取り込んだメッセージを確認できますし、「sourcetype="dmarc:json"」で内容を確認できます。

うまく取り込めない場合は、Splunkインストールフォルダの「var/log/splunk」にある「ta_dmarc_*」ファイルを確認するとエラーの原因が分かるかもしれません。

TA-dmarc add-on for Splunk でDMAR結果の表を作る

TA-dmarc add-on for Splunk | Splunkbase を使って表を作ります

DMARCレポートをどんなダッシュボードで表現するかを考えるときは、データを眺めるのが一番ですよね。というわけで一覧表示してみましょう。

sourcetype="dmarc:json"

| rename feedback{}.record.row.policy_evaluated.disposition as disposition

| rename feedback{}.record.row.source_ip as source_ip

| rename feedback{}.report_metadata.org_name as org_name

| rename feedback{}.record.row.count as count

| rename feedback{}.record.row.policy_evaluated.reason.comment as comment

| rename feedback{}.record.row.policy_evaluated.dkim as dkim

| rename feedback{}.record.row.policy_evaluated.spf as spf

| eval dmarc = if(IN(dkim,"pass") OR IN(spf,"pass"),"pass","fail")

| table disposition, source_ip, org_name,count, dmarc, comment, dkim, spf

TA-dmarcで取り込んだデータを読み込みます。

sourcetype="dmarc:json"

表の列名の為にフィールド名を変更します。
正直なところこの書き方がスマートなのかは疑問ですが、TA-dmarcのフィールド名が長いのでとりあえず省略しないとつらいんですよね。

| rename feedfeedback{}.record～略～

DMARC結果を表示します。

DKIMとSPFのどちらかがpassだったらDMARCはpassってのはこの記事を読んでる人にとっては当たり前だけど、その他の方にとっては明示的な方が分かりやすいですよね。

| eval dmarc = if(IN(dkim,"pass") OR IN(spf,"pass"),"pass","fail")

表を表示するのでtableを使います。

| table disposition, source_ip, org_name, count, dmarc, comment, dkim, spf

DMARCを勉強するならDKIM認証とSPF認証も一緒に表示することをお勧めします。

そうすることで、DMARCでいうDKIM, SPFと単体のDKIM, SPFが別物ということが分かると思う。

DKIMは署名を行ったサーバーから届いたメッセージが改ざんされていないことを確認する仕組みで、SPFはドメイン所有者（DNSサーバーの管理者）が送信メールサーバーを明示するだけで”なりすましメール”に対する対策ではないってことが分かると思う。

じゃDMARCでいうDKIMとSPFは？というと、メールソフトの送信者として表示されるメールアドレスのドメイン名とDKIMの署名やSPFのドメインが一致しているかを評価しています。　”メールソフトで自由に設定できる送信者”を制限する？間違っていたら迷惑メールフォルダやゴミ箱に届けてほしいという要望を公開する仕組みなんですよね。

TA-dmarc add-on for Splunk でDKIM認証結果を表示する

TA-dmarc add-on for Splunk | Splunkbase を使ってDKIM認証結果を表示する

DMARCレポートにはDKIM認証の結果は載っているけど、なぜかTA-dmarcではフィールドとして扱っていないんですよね。(なんでだろう？）
なので、ひと手間かけないと検索は出来るけど値としては使えないです。

sourcetype="dmarc:json"
| eval dkim = spath ( _raw, "feedback{}.record.auth_results.dkim.result")
| stats count by dkim

TA-dmarcで取り込んだデータを読み込みます。

sourcetype="dmarc:json"

dkim認証結果をjsonから抽出します。

spath(X,Y)でXのxmlまたはjsonからYで指定した値を取得できる

| eval dkim = spath ( _raw, "feedback{}.record.auth_results.dkim.result")

円グラフで表現したい場合は stats を使用すると良いです。

| stats count by dkim

折れ線グラフなら timechart を使います。

| timechart count by dkim

SPF認証についても"dkim"を"spf"に置き換えることで取得できます。

TA-dmarc add-on for Splunk でDMARC合否を表示する

TA-dmarc add-on for Splunk | Splunkbase を使ってDMARCレポートから合否を表示する。

DMARCレポートってSPFとDKIMの結果は載っているけどDMARCは載ってないんですよね。
なので、二つの結果のどちらかがPassすればPassという式が必要で次の検索コマンドを使うことで求めることが出来ます。

sourcetype="dmarc:json"
| rename "feedback{}.record.row.policy_evaluated.dkim" AS dkim
| rename "feedback{}.record.row.policy_evaluated.spf" AS spf
| eval dmarc = if(like(dkim, "pass") OR like(spf, "pass"), "pass", "fail")
| table dkim, spf, dmarc

TA-dmarcで取り込んだデータを読み込みます。

sourcetype="dmarc:json"

フィールド名が長いので短い名前に変更します。

| rename "feedback{}.record.row.policy_evaluated.dkim" AS dkim
| rename "feedback{}.record.row.policy_evaluated.spf" AS spf

dkimの値を求めます
dkim 又は spf もしくは両方が"pass"だったら"pass"を"dmarc"に代入します。
文字列比較なので like(TEXT, PATTERN) を使います。

| eval dmarc = if(like(dkim, "pass") OR like(spf, "pass"), "pass", "fail")

結果を表として表示します。

| table dkim, spf, dmarc

円グラフで表現したい場合は stats を使用すると良いです。

| stats count by dmarc

折れ線グラフなら timechart を使います。

| timechart count by dmarc

Outlook On the Webに挑戦してみた。

そういや、M365を使っている会社のExchangeメールって、アプリのOutlookを使ってるのが多いんでしょうかね。
前々職や前職はそうで、PCのインデックス作成に時間がかかるわ、ostファイルが肥大化したり不整合を起こして使えなくなるわで、いい印象がないんだけど…
— うさみこ@愛犬好き (@usamiko) 2022年11月14日

Microsoft365界隈ではWindows版Outlookを使わず、ブラウザ版のみを使っている人がいる。

私はというと、所属組織のメールシステムを去年Exchange Onlineに統一するまでは、Exchange Serverを社内向け、SMTP/POP3 Serverを社外送受信と使い分けていたため、Windows版Outlook＋Thunderbirdなどを使っていた関係で、いまだにWindows版を利用している。

Exchange Onlineの利便性をフルに活用する為にはブラウザ版が適しているのは知っているので上のツイートをきっかけにブラウザ版だけで過ごしてみようとチャレンジしてみた感想をお伝えしたい。

Microsoft EdgeサイドバーのOutlookが使いやすい

クリック一つでメールやスケジュールなどを利用できる点についてはWindows版が優れている。常に起動しておけばよいからだ。メモリーを消費するという声が聞こえるけど、TeamsやEdge、Chromeに比べればかわいいものだ。

ブラウザ版でも常に開いておけばよいという思うが、ウインドウを閉じてしまうと閉じてしまう。タブで切り替えながら使ってはいるけどやっぱり閉じてしまうのでクリック一つで開くことはできない。

その中で便利と感じたのが先月一般リリースされたサイドバーのOutlook。どのウィンドウでもクリック一つで受信トレイが表示できる。タブの切り替えなどにも影響しないのでとても便利だ。受信トレイを使った送受信ならこれで十分だし、ブラウザ版を開きたければその中にある”全画面で開く”をクリックすればすべての機能が使える点がとても良い。

通知が来ない

ブラウザ版にも通知という機能はあるが、ブラウザを開いていなければ通知が表示されない。私の環境が悪いのかブラウザ版を開いていなければ通知は受けられなかった。

Windows版を常に起動し通知を受けていた人間からすると通知が来ないというのは非常に不安な状態。まるで携帯電話を家に忘れてきたときの様だ。

一番困ったのは会議予定の事前通知がなくなった事。予定の15分前に通知が来るのでトイレに行ったり資料を確認したりしていたのが出来なくなった。時間になっても通知がないので微妙に遅刻。安定して通知を受けることは重要だ。

アドレス帳の組織階層がない

情シスという立場上、社員情報や組織図を確認する機会が多く、Windows版の組織は重宝していたのでちょっと困った。これに関してはブラウザ版のみは耐えられそうにない。

ウイジェットは役立たず

外が見えない部屋で外の天気が分かるというのは非常に良いことだ。

ここにOutlookのカレンダーが表示されているがあまり使った記憶がない。

表示されているんだから通知はここからしてくれよ！！って思ったりする

スマートフォンは優秀

着信通知に関してはiPhoneのOutlookアプリはパソコンより早く優秀。

常に持ち歩いているしアプリの起動とか意識不要な点も優秀

ただ、長文はつらいし、添付もつらい。何より他人の予定表を見るとかグループウェア利用としては機能不足、あくまで個人に特化している

共有メールはWindows版の圧勝

ブラウザ版は他のメールボックスを開く操作をしないと表示されないんだよね。

意識せずに使える点はとても重要

検索はブラウザ版

Windows版はキャッシュ期間の設定にもよるけど、６か月に設定した場合、７か月からオンラインアーカイブへ移動する２年までのメッセージが表示されなくなる。

検索しても一発では表示されないので探す手間が多い。

ブラウザ版はオンラインアーカイブも含めた検索結果が得られるのでとても便利。

こんな感じで一長一短あるな～という感じですね。近い将来UIが統一されると聞いているのでWindows版の機能不足や操作の慣れという問題は解決されると思うけど、グループウェアとしての使い方を重視するとWindows版がおすすめって感じがします。

それよりも今回気が付いたのがEdgeのサイドバーは優秀という事、おそらくEdgeの拡張機能のOutlookを統合したものだと思うのだけど、常に開けるという状態と、タブ切替の影響を受けない、並べて表示がふつうにできるなど、個人的に非常に使い勝手がハマってよかった。Webを見ながらメールを書いたりブラウザとの連携はよく使うシーンなので便利だ！！と感じました。

通知に関してはWindows標準のメールアプリを使えば受けることが出来るので登録すれば解決できるけど、なんか今設定すると負けな感じがしたので踏みとどまっている。以前は予定表のみ同期を設定していたのだけど、「情シス以外の普通の使い方」という体験の為に今は使っていないんですよね。

そろそろ企業向けにIPv6本格導入考える時期が来たんじゃない？

各企業において様々な働き方に対応できるインフラ構築も落ち着いた時期じゃないかと思いますが、IPv6だけは相変わらず導入できそうな気配を感じませんね。

やろうと思えばできるのですが、企業インターネット黎明期あった、グローバルアドレスを社内IPとして利用してしまう失敗が脳裏をよぎって躊躇してしまいますよね。「OCNエコノミーで安定高速インターネット接続環境を！！」みたいなことを言ってた時代に現地調査はいると「170.0.0.1/24」とかが設定されているネットワークに出会うことがたま～にありました。社内ネットワークで利用できるのは3種類のプライベートアドレスは今では当たり前ですが、Windows3.1時代にネットワークを構築した企業にとっては当たり前というとかわいそうですね。RFCの公開が1994年ですし。

インターネット接続環境はインフラ環境が単純な家庭用サービスが先行して普及するのは自然のことで、IPv6もその一つですね。フレッツ光プレミアム以降のサービスを契約すると気にすることなくIPv6対応ルーターが設置され利用できる準備が整いますので、利用者は意識してなくてもIPv6通信の普及は進むし、PPPoE遅い問題を目にした方はIPv6の積極的な導入に動いたのではないでしょうか？

そういう流れで会社のインターネット遅い！！IPv6対応して高速化しろよ！！って意見がちらほら聞こえているのです。企業ネットワークを変化させることって難しいのです。トップダウン型で取り組み始めても費用を提示するとNGってこともあるし、そもそも製品の選択肢が無かったり、性能不足、ノウハウ不足、パートナー不在と費用提示の前にとん挫することもあります。うまくいっても利用者側から変更を拒否されたり、利用システムが未対応だったりと課題もたくさんあり「今は変化できない」がず～っと続いてしまいます。

新規小規模拠点なら導入課題は少ないですが、既存小規模拠点の場合は予算的に不可というケースが多いのでは？一般家庭用機器ネットワーク拠点なら設定変更程度で済みますけど、VPN装置があったりすると対応機器に買換えが必要だったりしますが”壊れていない”　”今問題なく業務出来ている”という状況と”見えない効果”がブレーキを掛けます。だって「高速化した分、売り上げも上がるよね？」って現場が言われると無理、いらないって答えるよね。

そんな感じで変化はとても難しいのですが、インフラ担当としては何年も先を見据えて機器選定をしているので買換えタイミングでは高速化、もちろんIPv6対応も考慮しているわけです。機器に関しては予算が付けば解決できるし、利用システムも対応が徐々に増えているので何とかなるかな～という感じではあるのですけどね。

そんな中、絶対に無理だな～と感じているのが”定番設計が存在しない”という問題。

IPv4には”インターネット接続ゲートウェイでNATとLAN側はプライベートアドレスを使う”が最低限の定番設計で、拠点間で異なるサブネットを使っていれば統廃合に対して部分的な変更だけで対応できる。

この定番設計で構築されたネットワークをIPv4/IPv6デュアルスタック化しようとするといくつかの問題が解決できない。「あ、無理だ～」というのが私の感想。

何が無理って「プロバイダー変更のインパクト」「IPv4と同じセグメント分けが出来ない」って話だけでも、結構無理～って感じる。

プロバイダー変更のインパクト

IPv４はゲートウェイでグローバルアドレスに変換して、内部はプライベートアドレスを使用するので、プロバイダーを変更した際にグローバルアドレスが当然変わるけど、ゲートウェイの設定変更だけで利用者に影響でない。

これが、IPv６の場合、内部もグローバルアドレスを使うので、プロバイダー変更ですべてのIPアドレス設定に影響が発生する。自動設定だから問題ない？いや、端末への反映時間やDNSやサーバーの設定変更などを考慮すると「ISP障害だから別のISPに切り替えて対応しよう」ってのがIPv４のように気軽に出来ない。常に利用できる状態にするという設計になるのだろうか？

または、IPv4と同じようにユニークローカルアドレス使えばよいじゃないって話になるんだけど、NAT6対応のゲートウェイが必要になる。すべての機器が対応していれば話は簡単なんですけどね。

IPv4と同じセグメント分けが出来ない

IPv6はグローバルアドレスを使う前提なので、プロバイダーから割り当てられるIPアドレスを分割できる/56や/48だと良いのですが、/64だと無理ってなります。だって分割の最小が/64だから・・・これ以上分割できない。

PPPoEや専用線契約なら/48など潤沢なアドレス範囲を使えるので分割できるけど、IPoEだとひかり電話契約ありで/56、ひかり電話契約なしだと/64になるので必要セグメント数にもよるけど1:1に出来なければIPv4のセグメント統合が必要になる。

2022年現在はIPv6に変更する目的は「輻輳状態にあるPPPoEを迂回する」だと思うので、輻輳していないかもしれないIPv6のPPPoEは避けたいと考えるし、専用線費用なんて割に合わない。1Gbpsの専用線って月額いくらなんだ？100万位？

デュアルスタックへの準備は本格的に考えているけど、課題はたくさんありそうだし、何より定番設計が無さそう。ってのが一番痛いよね～。まだまだ企業内ネットワークのIPv6対応は先の話になりそう。

世の中のネットワーク技術者の皆さんお買い物どうやってる？

パソコンの購入はすでに落ち着き、円安による値上げが気になってる時期ですけど、ネットワーク機器って皆さん調達できているんですかね？

春ごろに注文した無線LANアクセスポイントはやっと届くとリセラーから連絡がありました。

24Port LANスイッチの納期照会したら”未定”という回答。

４月発表の新製品はいまだ商品登録されておらず見積もり出てこず。

L3スイッチは半年以上待ち

ファイアウォールは２ヶ月待ちと。

基本海外製品であるNW機器は納期１か月は標準ですけど、未定とか辛すぎ

もちろんメーカー、製品を選ばなければ調達できるけど計画的な設計は不可能。

壊れたらどうする？

追加購入が必要になったら・・・

拠点が増えたら・・・

コロナ騒ぎも落ち着きを見せ、出勤率も徐々に高くなっている段階で入手不可という状況はつらいですね。

登録: 投稿 (Atom)