exim4でTLS接続できない問題

以前、Linux上で「exim4」を使ってメールサーバを構築した時の問題として、同じような内容を「exim4のTLSエラー(エントロピー問題)」として載せました。その時に対処方法もいっしょに載せたのですが、方法がまずいようでサーバにかなりの負荷がかかるようです。今回は、その事にも考慮して新しい対処方法をまとめます。

前回の内容をまとめます。exim4で構築されたメールサーバにTLS接続すると、タイムオーバで接続できない時がある。その原因は、次のとおりです。

exim4は、TLS接続時にDiffie-Hellmanパラメータを使用します。このファイルは、生成から24時間たつと安全性の問題からいったん削除され、TLS接続が新たに発生した時に、再生成します。再生成する時にエントロピーが枯渇しているとファイルが作れずにTLS接続が確立できないからでした。

これに対し、前回の対処方法では、エントロピーを常時補間し、いつファイルの再生成が起こってもよいように備えるという方法でした。この方法だと、エントロピーの監視と生成を常時行うため、マシン負荷が大きくなってしまいました。今回の対応では、この高負荷の部分を解消するようにしました。

スポンサーリンク




Diffie-Hellmanパラメータファイルの削除のしくみ

問題のDiffie-Hellmanパラメータファイルは、どこにあってどのように削除されるのかを調べてみました。実際のファイル名は、「gnutls-params」で場所は、「/var/spool/exim4/」にありました。削除のしくみは、なんと「cron」にシェルを登録しておき、ある時間になるとそのシェルが起動され、単純にファイルを削除するだけでした。「/etc/cron.daily」ディレクトリに「exim4-base」というシェルが存在し、そのシェル内で「rm -f /var/spool/exim4/gnutls-params」が走っているだけでした。

対処方法その1

一番簡単な方法は、このファイルを削除しないようにするだけです。「exim4-base」から、この命令「rm -f /var/spool/exim4/gnutls-params」を削除するだけです。もっとも簡単でマシン負荷もほとんどない状態で運用可能です。

対処方法その2

上記方法だと、セキュリティー面に問題があるので、別の方法も考えてみました。その方法は、ファイル削除後、強制的にTLS接続を行い、再生成する方法です。もちろんTLS接続直前にエントロピーの追加を行い接続できる状態で実行します。実行するシェルは、次の通りです。

#!/bin/bash

entropy=`cat /proc/sys/kernel/random/entropy_avail`

while [ ${entropy} -lt 3000 ]
do
    find / /usr /var/ /home -xdev -type f -print0 2>&1 | rl -0 -c 1000 | xargs -0 cat > /dev/null 2>&1
    entropy=`cat /proc/sys/kernel/random/entropy_avail`
done

expect -c "
set timeout -1
spawn telnet localhost 25
expect \"220 kurobox\"
send \"ehlo locali\n\"
expect \"250 HELP\"
send \"starttls\n\"
expect \"220 TLS go ahead\"
send \"quit\n\"
"

まず、エントロピーの追加を行い、telnetで接続しTLSモードを起動します。このシェルをパラメータファイル削除のすぐ後に実行されるよう「cron」に登録しておきます。セキュリティー面と負荷の面からこの方法がベストかも知れません。

スポンサーリンク







シェアする

  • このエントリーをはてなブックマークに追加

フォローする