1 はじめに
メールサーバーをたててみると、毎日毎日不正アクセスの数が多いこと。
メールサーバーのmaillogを見てみると、SMTP-AUTHで失敗しているのがほとんどですが、
中には次のようなエラーも相当数あります。
1 2 |
RCPT Relay access denied |
中継しようとしてエラーとなっていることはわかりますが、
攻撃者がいったいどんなことをしていてエラーなったのか、
具体的なことはわかっていませんでした。
エラーとなった行いが分かれば、何か対策がたてられるかと思い、
SMTPのプロトコルについて調べてみた結果が本記事です。
この記事は、自分の備忘録として残しておくために記述しました。
2 SMTPのポート
2.1 SMTPのポートの目的
SMTPサーバーに接続する時、
SMTPサーバーのIPアドレスとポート番号の両方を指定します。
一般的なSMTPポートは複数存在していますが、
全てがどんな状況でも使用できるとは限りません。
それぞれのSMTPポートには、異なる目的が存在します。
SMTPのメール送信には、2つの過程があります。
SMTPのポートは、おおよそ
UA-MTA間ではサブミッション、MTA-MTA間ではリレーと使い分けられるようになっています。
2.2 STMPで使用されるポート
現代のインターネット上に存在するSMTPポートは1つではありません。
一般的なSMTPのポートは4つあります。
・ 25
・ 587
・ 465
・ 2525
2.2.1 25番ポート
25番ポートは1982年に作られたポートで、SMTPポートの中で一番古いものです。
25番ポートは今でも標準的なSMTPポートとして知られていて、
主にSMTPのリレーに使用されます。
現在では、多くのISPやクラウドホスティングプロバイダーが
25番ポートをブロックしていることから、
UAである末端のメールソフトから使うことはありません。
代わりに587番のポートが使われています。
2.2.2 587番ポート
587番ポートは、
現代のインターネット上ではSMTPサブミッションに用いるデフォルトのポートとなっています。
587番ポートはTLSもサポートしているため、安心してメールを送信できます。
2.2.3 465番ポート
465番ポートは、もともとSMTPS(SMTP over SSL)に割り当てられていました。
1998年にSTARTTLS over SMTP(Port 587)の登場によって、465番ポートは取り消されました。
しかし、多くのISPやクラウドホスティングプロバイダーは、
今でもSMTPサブミッションに465番ポートを割り当てています。
3 SMTPコマンドとメール送信シーケンス
3.1 メールの送信シーケンス
SMTP(Simple Mail Transfer Protocol)は、
送信者からのEメールメッセージを 受信者のメールサーバーまで
転送するためのインターネット標準です。
この転送は、メールサーバー上のメール転送エージェント(MTA)と、
ユーザーのローカルコンピュータ上のユーザーエージェント(UA)を
使用することで実現します。
MTAの役割は、他のMTAからのメールを送受信することです。
SMTPプロトコルは基本的に、メールサーバー間でのメッセージ転送手段を提供します。
こうした転送処理を受け取るサーバーは、最終的な宛先か、または単なるメッセージの中継点です。
Eメールの受信は、POPまたはIMAPプロトコルによって行われます。
これらのプロトコルについては、本記事のテーマから外れますので、本記事では示しません。
SMTP転送は、送信者の認証、メールの送信、接続の終了の3段階で行われます。
これらの手順は、「ロックステップ」型で実行されます。
つまり、送信者が1つのコマンドを送信するつど、受信者がこれを処理し応答を返します。
本節の以下の項では、
2つのSMTPメール転送エージェント間で行われるSMTPコマンドの実行例を示します。
これらの通信は、Wiresharkなどのスニファを利用するまでもなく、
図3.1-2に示すよう”telnet”で確認することができます。
3.1.1 送信者の認証
受信者は通常、25番ポートでTCP接続をリスン(受信待機)します。
接続が確立されると、
送信者は”HELO”コマンドを発行し、これに続けて送信者のドメイン名を提供します。
これに対し、受信者は送信者に対して自身の証明を行います。
この過程のやり取りは、以下のようになります。
1 2 3 4 |
受信者 < 25 番ポートの接続を待機 > 送信者: < TCP 接続を確立 > 送信者: HELO sender.com 受信者: 250 server.com |
もう1つの認証方法は、EHLOコマンドを使用する方法です。
このコマンドはHELOとほぼ同機能ですが、
送信者がサービス拡張の使用を要求する点が唯一異なります。
これはSMTPの機能を拡張する手段ですが、本記事での説明は省かせていただきたく思います。
EHLOコマンドを使用した認証は、次のようになります。
1 2 3 4 5 6 7 8 9 10 |
受信者 < 25 番ポートの接続を待機 > 送信者:< TCP 接続を確立 > 送信者: EHLO sender.invalid 受信者: 250 receiver.invalid 250-HELP 250-EXPN 250-XREMOTEQUEUE 250-ETRN 250-PIPELINING 250-SIZE |
この例では、サーバーからの応答はHELOコマンドとほぼ同じですが、
サーバーは自身がサポートするサービス拡張を通知しています。
この時点で認証段階は終了し、メール送信プロセスを続行できます。
3.1.2 メールの送信
送信者が認証されると、次の段階はメールメッセージの送信です。
これは、
MAIL FROM、
RCPT TO、
およびDATA
の3つのコマンドだけを使用する単純なプロセスです。
メールメッセージの送信プロセスは、MAIL FROMコマンドと、
後に続けた送信者アドレスの送信(メールの送信者を指定)によって開始されます。
受信者は、メールを受け取る場合は「250 OK」という肯定応答を返します。
次に、送信者は一連のRCPT TOコマンドを発行します。
個々のコマンドの後ろには、メール受信者のアドレスを指定します。
受信者は、個々のメール受信者の許可または拒否を選択します。
受信者が拒否されても、メール転送は続行します。
送信者は、次にDATAコマンドを使用して、実際のメッセージを送信します。
サーバーはこれに対して「354 ~」という応答を返し、
以降に続くすべての行をメッセージとみなします。
このメッセージには、Date、Subject、To、Cc、From などのヘッダフィールドと、
これに続いてメッセージ本文が含まれます。
すべてのデータの送信が完了すると、送信者は<CRLF>.<CRLF>を発行します。
これにより受信者は、全データが転送されたことを確認できます。
DATAコマンドは、メール処理が完了できなかった場合(受信者が存在しないなど)、
またはサーバーのリソース不足が生じた場合のみに失敗します。
メール送信の実際のプロセスは、次のようになります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
送信者: MAIL FROM: <hoge@sender.invalid> 受信者: 250 OK 送信者: RCPT TO: <some1@receiver1.invalid> 受信者: 250 OK 送信者: RCPT TO: <some2@receiver2.invalid> 受信者: 550 No such user here 送信者: RCPT TO: <some3@receiver3.invalid> 受信者: 250 OK 送信者: DATA 受信者: 354 Start mail input; end with <CRLF> . <CRLF> 送信者: Blah blah blah... 送信者: ...etc. etc. etc. 送信者: <CRLF>.<CRLF> 受信者: 250 OK |
この段階が完了すると、メールは送信され、接続が閉じられます。
3.1.3 接続の終了
メール送信が完了したので、最後に残された処理は接続の終了だけとなります。
これには、送信者がQUITコマンドを発行します。
受信者はこれに対し「221」という応答を返し、接続を閉じたことを確認します。
このやり取りは次のようになります。
1 2 3 |
送信者: QUIT 受信者: 221 closing channel < TCP 接続が終了 > |
いったんこのコマンドを発行すると、メール送信プロセスが完了します。
3.2 SMTPコマンド
SMTPコマンドを表3.2-1にまとめました。
全てのメールサーバーが、表3.2-1に示すコマンド全てを実装しているわけではありません。
各コマンドの書式については、下に示すページをご覧いただければと思います。
3.3 SMTP応答コード
メールサーバーからの返信メッセージには3桁の数字が含まれていて、
この数字(コード)によってOKやエラーの種類を判断します。
ちなみに、SMTPサーバーと接続が確立できなかった場合は、
ICMP(Internet Control Message Protocol)によって理由が通知されます。
4 SMTP-AUTH
SMTP-AUTHとは、
メール送信プロトコルであるSMTPにユーザー認証機能を追加した仕様です。
SMTPはもともと認証を持たない仕様だったため、
結果的に迷惑メールを許してしまっていました。
メール送信する前にSMTPサーバーとユーザーとの間で
ユーザーアカウントとパスワードの認証を行い、認証された場合のみメールの送信を許可します。
SMTP認証を利用するには、サーバーとクライアントの双方が対応していなければなりません。
図4.1-1に 認証方式「LOGIN」での、SMTP-AUTH通信の様子を示します。
以上
HTMLだと、
思うように編集することは難しく、やろうすればとっても時間が掛かります。
ですので、本記事の元となっているWordで作成したPDFを
ページ最後に貼り付けました。
役に立てていただければ、うれしく思います。
このPDFファイルは、自由に配布されてもかまいません。
ただし、再配布の際には、
入手元と著者名は明らかにしてください。
なお、上のPDFファイルの内容、また本文中の記述に、
誤字や脱字、誤った内容の記述など見つかりましたら、
下に示すフォームでご連絡いただければ幸いです。