Welcome Guest 
Login
Username:

Password:


Lost Password?

Register now!
サイト内検索
Main Menu
Site Info
Webmasters

m-naka
 


Who's Online
13 user(s) are online (4 user(s) are browsing MyWorks(記事))

Members: 0
Guests: 13

more...
Themes

(2 themes)
SmartSection is developed by The SmartFactory (http://www.smartfactory.ca), a division of INBOX Solutions (http://inboxinternational.com)
■200304ログ■
Published by M-naka on 2004/3/6 (1615 reads)
2003年4月のサーバ管理記録。

■サーバ管理日記過去ログ■

管理履歴:
 20030427:SMTP-Auth機能(CRAM-MD5方式)実装
 20030425:/etc/postfix/main.cfの修正
 20030413:Postfix試験運用開始
 20030412:SSHサーバ稼動開始・Postfix実装

 

2003年4月27日(日)

・PostfixへのSMTP-Auth機能(CRAM-MD5)実装

 SMTPは本来的に認証を要求しない。しかし、無制限にSMTPアクセスを許可するわけにもいかない。商用ISPの場合、自己ネットワーク内からのみSMTP送信を許可している場合が多いだろう(=アクセス制限)。外部ネットワークからのSMTP送信はSPAM等の不正中継を阻止するために許可しないのが通常である。そのため、外部からのSMTP中継を許可する場合、POP before SMTPやWebMail等、送信者をある程度追跡できる方法を用いて許可する他ない。

 POP before SMTPでは、POPでアクセスした者のホスト情報(もしくはIPアドレス)に対し、一定時間のみSMTP中継許可を与えるものである。POPでアクセスするにはIDとパスワードで認証を受ける必要があるので、POPアクセスをしてきたホストは一応信用できる。WebMailの場合はアカウントとパスワードで認証しなければそもそもWebMail機能が使えない。逆に言えばログインしていれば一応「本人確認」は取れていることになる。

 しかし、POP before SMTPはPOPでアクセスしてきたホストの情報を信用するため、NATやIPマスカレードを経由すると、必然的にセキュリティレベルは低下する。これは、例えば企業や大学等のネットワークから利用する場合、POPの使用者とSMTPの使用者が別になる可能性がある、ということである(注1)。一方WebMailはブラウザーさえ利用できればメール機能を利用できる手軽さはあるが、アカウントやパスワードが人目に付く可能性は格段に上がること、純粋なテキストデータのみをやり取りするのではなく、HTMLデータをやり取りするためにデータ量が必然的に多くなること、の2点が弱点であるといえる(注2)。

 通常のSMTPのやり取りをしながらもユーザID・パスワードで認証を行うSMTP-Authは、高いセキュリティレベルと利便性を両立できる。中でもCRAM-MD5方式は強度が高い認証機能であるため、信頼性はさらに高くなる。

 なお、SMTP-Authは現行のインターネットメールシステムの標準規格で盛り込まれている機能ではない。事実、Postfixでもデフォルトでは対応しておらず、ソースのコンパイル時にオプションを付け、別途必要なパッケージをインストールする必要がある(注3)。RPMパッケージでもソースRPMを使用することで実装は可能らしいが、今回はソースをコンパイルすることで実装することにした。

必要となるパッケージ:
 postfix-2.0.9.tar.gz
 cyrus-sasl-1.5.27-17vl1
 cyrus-sasl-devel-1.5.27-17vl1

1)インストール

#rpm -ivh cyrus-sasl-1.5.27-17vl1.i386.rpm

#rpm -ivh cyrus-sasl-devel-1.5.27-17vl1

#tar xzvf postfix-2.0.9.tar.gz

#cd postfix-2.0.9

#make makefiles CCARGS="-DUSE_SASL_AUTH -I/usr/include" AUXLIBS="-L/usr/lib -lsasl"

#make install

2)パスワード設定

 

3)「踏み台」チェック

 メールサーバの不正中継チェックを実行。テスト項目は19個。

#telnet mail-test.abuse.org

 全てクリア(中継拒否)。SMTPに認証を要求している以上、理論上はそのIDとパスワードが破られない限り、中継されないことになる。SPAMを送りつけてくるような輩がそこまで手を込んだコトをしてくるとは思えないが。SMTPがセキュアであることがこれである程度示されたので、まずは善しとしよう。

4)使用メーラー

 全てのメーラーがSMTP-Auth機能に対応しているわけではない。CRAM-MD5方式への対応というとさらに選択肢は狭まる。オススメは我が家で利用させて頂いているEdMax(フリー版)である。マルチアカウント対応、CRAM-MD5方式SMTP-Auth機能対応、その他フリーソフトとしては非常に多機能。学生時代のアルバイト先でも利用させて頂いた非常に優秀なソフトである。調べてみたところ、フリーソフトでは他にnPOPが対応している。ちなみにnPOPもお気に入りソフトの1つである。

 EdMaxなら送信設定でSMTP-Authに関する設定項目があるので、ここを設定するだけでよい。

 残るは受信時のAPOP認証機能の実装。そうすればメールシステムに関してはかなりの安全性が保たれることになるだろう。

 

注1:
 もっともNATやIPマスカレードを使用している中規模・大規模ネットワークでは、LANからWANに向けてSMTPポート(25番)を開けられている可能性も必要性も低い。

注2:
 WebMailよりPOPアクセスの方が受信データが格段に少なくて済み、アカウント・パスワードによる明示的な認証作業が不要であるため、AirH"などでアクセスする際の快適さはPOPアクセスの方が明らかに上である。この点、ブロードバンドアクセスであれば、POPアクセスであろうとWebMialであろうと何の問題もない。初心者にはむしろWebMailの方が使いやすいだろう。

注3:
 SASLというパッケージが必要。

 

2003年4月25日(金)

・「Postfixで一部ホストよりメールが届かない」という問題を解決

 結論から言えば、送信元のホストがDNSで正引き・逆引きが共にできない状態にあったことが原因であった。どうも相手のネットワーク内でしか有効でないホスト情報をそのまま外部向けに使えるようにしてあるらしく、こちらではそのホストを「Unknown Host」としてSMTPアクセスを拒否していた、というオチである。/var/log/maillogをチェックしたところREJECTログの山が……。

 問題となる「Unknown Host」は固定されており、必ず特定のIPアドレスから発信されている。仕方がないのでこのIPアドレスを信用し、/etc/postfix/main.cfでこのIPアドレスからの中継を受け入れるように設定した。

 ちなみに今のところこのような状態になっているホストは他にはない。商用ISPのメールサーバなのに、こうした状態のままでいいのだろうか……?

 

2003年4月13日(日)

 メールサーバ(Postfix)の試験運用開始。

 

2003年4月12日(土)

1)SSHサーバ機能の実装、運用開始

 通信内容が丸見えなTelnetは外部ネットワークから利用するには危険すぎる。最悪の場合、通信内容の盗聴からIDやパスワードが窃取され、root権限奪取→サーバ自体を乗っ取られる可能性すらある。とはいえ、外部ネットワークからのログインが可能になることで得られる恩恵は決して少なくは無い。両者を両立させるもの、それがSSHによるセキュア通信である。

【1】サーバ側の設定
 RSA1(SSH1)とRSA2(SSH2)の2方式があるが、とりあえずRSA1方式を使用することに。セキュリティ強度はRSA2方式の方が上だが、複数のIDを発行するわけではないし、プライベートで運用するサーバであるから、RSA1方式でも十分と判断した。

 #ssh-keygen [user]

 これによりidentity(秘密鍵)ファイルとidentity.pub(公開鍵)ファイルが作成される。identity.pubはauthorized_keysにリネームして~/.sshディレクトリに格納(SSHアクセス時に読みに行く)。identityはFDなどにコピーしてクライアント側に移す。秘密鍵なので取り扱いに注意。次に

 #vi /etc/hosts.allow

 でhosts.allowファイルに以下の記述を追加。

sshd:all

 SSHログインのホストに制限を加え、さらにセキュリティ強度を上げるのであれば、hosts.allowで許可を与えるホストを限定してもよい。しかし、今のところそこまでの必要は認められないので、allで全てのホストからのSSHアクセスを許可しておく。

 

【2】クライアント側の設定
 クライアントとなるWindowsマシンにTTSSH(Tera Term Pro用SSHプラグイン)をインストール。これにより、Tera Term Proを利用したRSA1方式によるSSHログインが可能となる。サーバ側で作成されたidentityファイルをTTSSHのインストールディレクトリにコピーし、通信ポートは22番(TCP)を指定。

 

【3】ルータの設定
 eAccessのレンタルモデムは幸いにしてルータタイプ。ポートマッピングとポートフォワーディングの設定をすれば、セキュリティを維持しつつリモートアクセスが可能。

TCPポート22番 …… 外部からのアクセスを許可、Casperにフォワード(SSH)

 

【4】リモートアクセス実行
 alice-net.ddo.jpに外部からSSHログインができることを確認した。これにより

 ・Telnetサーバの停止=セキュリティレベルの向上

 ・外部からのTV録画予約設定

が実現。外部から各種サーバの設定ももちろん可能である。AirH"アクセスだとエコーバックに時間が掛かるという問題があるが……。

 

2)メールサーバ(Postfix)の実装

 alice-net.ddo.jpドメインのメールサーバの運用を開始した。ルータの設定(ポートマッピング)で

 TCPポート110番 …… 通過を許可、Omoikaneにフォワード
 TCPポート25番    …… 通過を許可、Omoikaneにフォワード

を開け、外部からの送受信も可能にしてある。メールの不正中継は極力避ける設定にしてあるが、一部正常に送信できないSMTPサーバが存在するようだ。


←前のページに戻る


Navigate through the articles
Previous article ■200305ログ■
The comments are owned by the poster. We aren't responsible for their content.
XOOPS Cube PROJECT
Powered by Mythril Networks © 2003-2022 The Mythril Networks Project