運用
|
|
|
ここでは、方法2と3を組み合わせた中継の制限方法について解説しておく。SMTPの中継を制限するには、サーバの管理ツールでExchange Serverの管理画面を開き、[詳細管理]−[ドメイン名]の下にある[サーバー]−[サーバー名]−[プロトコル]−[SMTP]を開く。そしてデフォルトで存在する[既定のSMTP仮想サーバー]を右クリックし、ポップアップ・メニューから[プロパティ]を選択する。
SMTPの管理ツールの起動 | ||||||
SMTPプロトコルで中継を許可するかどうかなどの設定を行うには、SMTPの仮想サーバのプロパティを選択する。 | ||||||
|
すると次のような[既定のSMTP仮想サーバーのプロパティ]が表示されるで、[アクセス]タブを選択する。
SMTPの仮想サーバのプロパティ | |||||||||||||||
SMTPのサービスごとにこのような「SMTP 仮想サーバー」という仮想的なインターフェイスが作成される。 | |||||||||||||||
|
SMTP認証の設定
この画面ではSMTPの認証に関する設定を行う。インターネット側からメールを受け付けるためには認証なしで運用しなければならないが、内部ネットワークから利用する場合は認証をかけて不正な中継を防ぐのがよいだろう。OutlookやOutlook Expressをはじめ、最近のメール・ソフトウェアでは問題なく利用できるのが普通である。
SMTP認証の設定 | ||||||||||||
|
IPアドレス/ドメイン名によるアクセス制限の設定
[接続制御]の画面では、SMTPクライアントのIPアドレスや(逆引きした)ドメイン名に基づいて、SMTPサーバへのアクセスの可否を決める。ただしSMTP仮想サーバ・インターフェイスが1つの場合は(これはデフォルトの状態)、インターネットとイントラネットの両方からアクセスされるので、制限を付けてはいけない。2つ以上のSMTP仮想サーバ・インターフェイスを用意して、それぞれ個別にアクセス制御や中継制御を行う場合は、アクセス可能なクライアントを限定するために、この機能を活用するとよいだろう。
中継の制限
この画面は、SMTPの中継の制御を行うためのものである。LAN上のクライアントからのアクセスでは中継を許可し、インターネットからのアクセスでは確実に中継を禁止しなければならない。一般的には次のような制限を付けることになるだろう。
メールの中継の制限方法1 | ||||||||||||
一般的な中継の制限方法。インターネットからのアクセス時に、IPパケットの送信元IPアドレスが変換されないようなネットワーク環境では、このようにして中継を制限する(通常のNAT/IPマスカレードではこのようになっている)。アクセス元のIPアドレスがこの範囲以外の場合はインターネットからのアクセスであると判断し、中継を拒否する。 | ||||||||||||
|
ここでは、ローカルのLAN上で使われるプライベートIPアドレスの範囲を列挙し、これらのクライアントからのSMTPアクセスの場合には中継を許可している。一般的にはこれで正しく利用できることが多い。
しかしネットワークの構成によっては、これでは不十分な場合があるので注意してほしい。今回想定しているネットワークでは(最初に提示した図参照)、インターネットからのアクセスはすべて172.16.1.1というIPアドレスを持つルータからやってくることになる。ルータにおけるポート・フォワーディング(サーバ公開)機能の実装方法に依存するが、パケットの内部ネットワークへのフォワード時に、IPパケットのソース側IPアドレスがルータのIPアドレス(172.16.1.1)に変換される場合がある(単なるアドレス変換機能ではなく、より高機能なSMTPのProxyサービスを通るとこのようになる場合が多い)。するとSBS 2003マシンからすれば、172.16.1.1という「ローカルのIPアドレス」を持つクライアントからアクセスされたように見える。つまりSMTP通信のIPパケットにおいて、ソース側のIPアドレスがグローバルIPアドレスではなく、172.16.1.1というローカルIPアドレスになるのである。
このようなルータ(Proxy機能)を使っている場合は、以下のようにして、ルータからのアクセスの場合は中継を拒否するように設定すればよい。
メールの中継の制限方法2 | ||||||
インターネットからのアクセス時に、IPパケットの送信元IPアドレスも変換されてしまうようなネットワーク環境では、このようなルールを定義するとよい。ルータ(ここでは172.16.1.1)からのアクセス時にはインターネットからのアクセスであると想定し、この場合は中継を禁止する。 | ||||||
|
自社のネットワーク環境ではどちらの方式が使われているかは、SMTP接続時にnetstatコマンドを実行し、接続元のIPアドレスがいくつになっているかを調べてもよいし、後述するSMTPのログ機能でクライアント側IPアドレスを調べてもよい。スキルがあるなら、管理ツールの「ネットワーク モニタ」でパケットの内容をチェックするのもよい(Windowsのオプション・ネットワーク・コンポーネットで別途インストールする必要がある)。ネットワーク・モニタ・ツールの使い方やインストール方法については別稿の「Windowsネットワーク・プロトコルの理解と検証」を参照していただきたい。
オープン・リレーのチェック
メール・サーバの中継設定が完了したら、実際にインターネットやイントラネットなど、さまざまな場所からメール・サーバにSMTPプロトコルで接続して、オープン・リレーが有効になっていないかどうかをチェックする。この場合、実際にメーラ(メール・クライアント・ソフトウェア)を使って確認するという方法もあるが、これではSMTPのエラーの詳細をつかみにくいので、ここでは手動でtelnetコマンドを使ってテストする方法を紹介する。SMTPプロトコルの詳細についてはMaster of IP Networkフォーラムの「SMTPでメール送信の舞台裏をあやつる」や「インターネット・プロトコル詳説―SMTP」などを参照していただきたい。
オープン・リレーを調査する場合には、telnetでSMTPポートに接続して、以下のようなコマンドを送信すればよい(先頭の「番号:」は行番号なので入力してはいけない)。
1: helo sbsserver |
ここで1行目のheloコマンドにおける「sbsserver」というパラメータは、SBS 2003をインストールしたサーバの名称であるが、単なるプロトコル上のグリーティング・メッセージ(最初に送信するあいさつのようなもの)なので、ほかの文字列でもよい(正しくは、クライアント側のホスト名を指定する)。2行目と3行目にあるメール・アドレス(< > で囲むこと)は、それぞれメールの送信元と送信先のメール・アドレスである。<test@examples.com>は、このSBS 2003のドメインとはまったく関係のない別のドメインを使ったメール・アドレスであり、もしこれが許可されれば、オープン・リレーが許可されている状態であるといえる。だがこのコマンドの実行結果がエラーになるようならば、正しくオープン・リレーがブロックされているということになる。
実際に実行してみると次のようになるはずである。まずは内部LAN上の任意のクライアントもしくはSBS 2003上でコマンド・プロンプトを開き、次のようにしてSBS 2003に接続して正しく外部へ送信できることを確認する。
C:\>telnet 172.16.1.11 smtp …ローカルのLAN上からSBS 2003に接続 |
黄色い文字の部分は、サーバ側からの応答である。ここでは172.16.1.51のクライアント・マシンからSBS 2003(172.16.1.11)マシンに接続しているが、SBS 2003上から「telnet 172.16.1.11 smtp」と「telnet 127.0.0.1 smtp」も実行して、それぞれ同じ結果が得られることを確認していただきたい。これができないと、SBS 2003マシンそのものからメールを送信することができない。
結果で注目すべき場所は、最後の「250 2.1.5 test@example.com」という応答である。これは<test@example.com>というメール・アドレスへの送信が正しく行えるということを表している。
同様のテストをインターネット上の任意のホストから、ここで公開しているSBS 2003マシンのSMTPポートに向けても行ってみる。
C:\>telnet XX.XX.XX.XX smtp …インターネットからSBS 2003に接続 250 2.1.0 test@example.com....Sender O K
|
先頭にある「XX.XX.XX.XX」は、インターネット上からアクセスする場合の公開IPアドレスである。これはユーザーの環境に合わせて変更していただきたい。
この結果で注目すべき点は、rcptコマンドに対する最後の「550 5.7.1 Unable to relay for test@example.com(550 5.7.1 test@example.comへはリレーできない)」という応答である。一般的にSMTPプロトコルでは、応答の先頭にある200番台の数値は肯定応答、500番台の数値はエラー応答を表す。この例では、「test@example.comへはリレーできない」というメッセージが示すとおり、リレーが拒否されている。これが正しい動作であるが、もし「250 2.1.5 test@example.com」という応答が戻ってくるようならば、もう一度設定を確認していただきたい。
以上の例は、手動でオープン・リレーをチェックする方法であるが、これ以外にも自動でチェックしてくれるサービスを利用するという方法もある。詳しくはSecurity&TrustフォーラムのSecurity Tips「スパム中継防止のため、第三者中継をチェックする」などを参照していただきたい。
INDEX | ||
[運用]実例で学ぶSBS 2003ネットワーク構築と運用 | ||
第2回 SBS 2003のメール設定 | ||
1.POP3/IMAPサービスの設定 | ||
2.POP3コネクタによるメールの取得と再配布 | ||
3.メールのオープン・リレー対策(1) | ||
4.メールのオープン・リレー対策(2) | ||
5.メールのログ機能の設定 | ||
運用 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|