FAQ17-49

メールの不正利用・なりすまし被害に遭った場合の一連の手順 new!

メールの不正利用・なりすまし被害に遭った場合の一連の手順を説明します。なおこの説明は「サポート2」に収録されている『E-Post Mail Server V システム運用ガイド』の44ページ以降に記述されている同じ内容です。

ここでは、サポートした案件から、実際になりすまし・不正中継された事例を紹介します。

不正利用・なりすましされたときに最初に気づく現象、その後の対処策

メールの配送（送信）に異常に時間がかかっている、なかなか相手に届かない

(a) 社内利用者のメールクライアントにできるだけ接続をさせないようにして、SMTP 受信サービス（epstrd）およびSMTP 配送サービス（epstdd）を停止。
(b) domains フォルダおよび holding フォルダの名前を別名にリネーム。incoming フォルダにも大量のファイルがあるときは、incoming フォルダも別名にリネーム。
例）old_domains、old_holding、old_incoming 等
(c) 不正利用やなりすましを受けている内部アカウントを、取得中のログなどから判定する。
たとえば、SMTP 受信ログ（inlog）を見て、外部への同報送信を異常な数を繰り返し試みているものを探し出したり、あるいはSMTP 配送失敗ログ（faillog）を見て、外部への配送が結果として大量に失敗している記録を探し出す。
(d) 原因となっている内部アカウントをリネームなどの方法で、いったん使用停止にする。アカウントをいきなり削除すると、該当アカウントのメールボックスも削除されてしまうため。
(e) SMTP 受信サービス（epstrd）およびSMTP 配送サービス（epstdd）を再開し、domains フォルダおよび holding フォルダの様子をしばらく見るようにする。通常メールのリトライ程度なら、数個のファイルか、多くても数十個程度。リトライ設定時間を経過すれば、やがてそれらのファイルはなくなる。
(f) 別名にリネームしていた incoming フォルダのデータファイルを確認する。拡張子が .RCP または .$CP ファイルのものをメモ帳で開くと、送信元エンベロープFROM が確認できるので、原因となっている内部アカウントのものでないか、宛先エンベロープTO が、大量に同報送信されているものでないか、などを確認する。
(g) 上記(f)で該当しない正常なメールデータを見つける。.RCP（または.$CP）ファイルと .MSG ファイルが同じファイル名で一組になっているので、それらのファイルを新しくできている正しい incoming フォルダにコピーする。コピー後、SMTP 配送サービス（epstdd）が自動的に外部への配送を試みることになる。
(h) domains フォルダおよび holding フォルダについても、膨大に残っているリトライデータの大多数は、なりすましや不正利用によるものと考えられるが、万が一にも該当しない正常メールが残っていないかを見つける。ただし、domains フォルダおよび holding フォルダに格納されるデータ及びその仕組みなどについては、同ガイドの「⑫リトライデータの処理と動きについて」を参照のこと。
(i) 万が一、該当しない正常なメールがリトライデータとして残っていることが判明した場合は、それらのフォルダ、ファイルを新しくできている正しい domains フォルダおよびholding フォルダにコピーする。コピー後、SMTP 配送サービス（epstdd）が自動的に再度のリトライを行い、外部への配送を試みることになる。
(j) 原因となった内部アカウントに対して、適切な対処を行う。
例１）SMTP 認証が未実施だった場合は、SMTP 認証を実施するようにする。
例２）SMTP 認証パスワードが類推された場合は、パスワードを変更する。
例３）アカウントそのものを削除して二度と使わないようにする
(k) 今後のことを考え、なりすましや不正利用にあった外部のIPアドレスを拒絶する。
具体的には、マシン接続ログ（acceptlog）やSMTP 受信ログ（inlog）で接続元のIPアドレスを特定し、「マシンごとの中継」【effect.dat】などでそうしたIPアドレスを拒絶・拒否したり（false）、場合によってはリレー禁止（norelay）の設定にする。
(l) 今後のことを考え、セキュリティをより高めるために用意されたSMTP／POP3／IMAP4各サービスにおける「接続ロックアウト」機能（認証接続ロックアウト機能およびIPロックアウト機能）の導入を検討し、設定を行う。

事例その１：A 社、B 社の例（複数あり）

事例その２：C 社、D 社の例（複数あり）

本来設定してはいけない内部ドメイン名をtrue指定して運用を続けて

事例その３：E 社の例（複数あり）

事例その４：F 社の例

事例その５：G 社の事例

使用してはいけない[tab]コードを使用して設定した

コードを無視し、その後をカットして処理する結果となった。実際の動きは不運にも下記と等価になってしまった。
'--------------------------------
[ローカルエリア内のIP]
*.*.*.*
'--------------------------------
結果的には、１行目でローカルエリア内のIP アドレスからの接続に対して無条件許可を意味する "true" 指定をしたのと同じ働きとなり、２行目でその他すべて（外部）のIPアドレスからの接続に対しても無条件許可を意味する "true" 指定をしたのと同じ働きとなってしまった。その結果、２行目に記述していた "*.*.*.*" が "true" 指定されているとみなされ、意図せずに外部から不正中継され、外部へ大量に配信される事態となった。
その後、【effect.dat】に入力する区切り文字を正しい半角スペースに訂正、以降は意図した通りの動きが得られることとなった。
'--------------------------------
[ローカルエリア内のIP] default
*.*.*.* norelay
'--------------------------------