備忘録 for myself in the future

ここで、mailmanを運用する場合の注意。

mailmanにはmmsitepassを使ってグローバル管理パスワードを設定すればウェブ上のインターフェースからメーリングリストの作成が可能だが、この方法で作成するとアーカイブディレクトリの所有者がwww-dataになってしまうので、mailmanが配信されたメールをアーカイブすることが出来なくなってしまう。

同様にコマンドラインからroot権限でnewlistでメーリングリストを作成した場合も、アーカイブディレクトリの所有者がrootになってしまって、これまた同じくmailmanがアーカイブできなくなってしまう。

これらはdebianのパッケージの設定に問題があると考えられるが、下手に修正してバイナリパッケージのアップデート時に整合性がとれなくなると嫌なので、ここは何も対処せず、su listしてからコマンドラインでnewlistを実行してメーリングリストを作成するようにする。すると作成されるファイルはすべてlistユーザー所有になるので、パーミッションの問題は起きない。バッドノウハウワークアラウンド。

 

メーリングリストサーバーとしてmailmanを使う。パッケージのインストール内容をできる限り尊重する設定にする。

とりあえずapt-get install mailman

FQDNは最終的なサーバーの名前で、言語はjaを選ぶがなぜか最初はenしかインストールされない。なので、インストール後にもう一度dpkg-reconfigure mailmanで再びjaを選ぶ。すると今度はjaもインストールされる。

次にpostfixとの連携をさせるため、/etc/mailman/mm_cfg.pyを編集。といってもMTA=”postfix”の行を有効にするだけ。ついでにDEFAULT_URL_PATTERN = ‘http://%s/mailman/’と変更して間の余計な/cgi-bin/を抜いておく。これはFreeBSDでmailmanをインストールした時のデフォルトに合わせるため。これを合わせておかないとFreeBSDで既に運用しているリストを移植するときにいろいろ不整合が出ることが予想される。

Webベースの管理ページを表示させるため、

ln -s /etc/mailman/apache.conf /etc/apache2/site-enabled/010-mailman

を実行してapacheの起動時にパッケージが用意したデフォルトのmailman用の設定を読み込む様に設定する。さらに、/etc/mailman/apache.confを編集し、ScriptAliasの行の/cgi-bin/mailman/を/mailman/に変更してmm_cfg.pyと合わせておく。

次の作業ではmailmanのスクリプトがEUCでメッセージを吐き出すので、あらかじめターミナルの文字コードをEUCに一時的に変更しておく。root権限でsu listしてmailmanの実行ユーザーlistの権限に移行し(シェルがbashからshに切り替わるので戸惑わないこと)

/var/lib/mailman/bin/newlist mailman

を実行する。mailmanメーリングリストの管理ユーザーのメールアドレスと設定パスワードを入力すると最初のメーリングリストが作成される。

ここで、/var/lib/mailman/dataにaliasesとaliases.dbがlistユーザーの所有で作成されていることを確認してから、postfixのaliasesとして認識させるために、/etc/postfix/main.cfのalias_mapsの項目にカンマで区切ってhash:/var/lib/mailman/data/aliasesを追加しておく。

後は再起動すればapache,postfix,mailmanが起動してメーリングリストが使える様になる。

一応、元からexim4がインストールされているのだが、後述するmailmanとの連携はpostfixの方がやりやすいので、postfixをインストールする。すると競合するexim4はアンインストールされる。

apt-get install postfix

まずは、サーバーの種類だが、このサーバーはメールをSMTP AUTHでISPのサーバーに全部丸投げするので、スマートホストを選ぶ。次にFQDNを尋ねられるので運用予定のサーバー名を入力。そして、丸投げする相手の入力を求められるので[xxx.xxx.or.jp]:587の様にFQDNを[と]で囲んだ上でコロンの後にSubmissionポートを追加したものを入力する。最終受け取り先にはなっても中継は受けたくないので、localhost以外からは中継を受け付けない様に、デフォルトの中継受け入れ設定127.0.0.1/8,::1/128のままにしておく。

次に、/etc/postfix/sasl/authinfoを作成し、以下の様に丸投げ相手のSMTP AUTHに必要な情報を記入する。

[xxx.xxx.or.jp]:587 userid:password

パーミッションを600に設定、postmap authinfoを実行してhash化したauthinfo.dbを作成する。

最後に/etc/postfix/main.cfにSMTP AUTHのための情報を追加する。

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/authinfo

以上が完了したら、postfix reloadか再起動でpostfixを新しい設定で立ち上げる。コマンドラインからmailコマンドでテストメールをlocalhostからpostfixに投げ、ちゃんとスマートホスト経由で宛先に届くことを確認しておこう。

次に、iptablesによる余計なアクセスの遮断とsshguardによるsshへのブルートフォースアタックの遮断を設定しておく。

Wheezyではiptablesの設定はiptables-persistentパッケージによって起動時に再設定されるが、この時点ではまだ設定しない。

以下のファイルを作成。とりあえず、ウェブサーバーとSSHサーバーとSMTPサーバーだけファイヤーウォールを開けておく。

iptables.rule

—

*filter

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn’t use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

# Accepts all established inbound connections
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

# Allows all outbound traffic
# You could modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp –dport 80 -j ACCEPT
-A INPUT -p tcp –dport 443 -j ACCEPT

# Allows SSH connections
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
-A INPUT -p tcp -m state –state NEW –dport 22 -j ACCEPT

# Allows SMTP connections
-A INPUT -p tcp –dport 25 -j ACCEPT

# Allow ping
-A INPUT -p icmp –icmp-type 8 -j ACCEPT

# Reject all other inbound – default deny unless explicitly allowed policy:
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT

—

せっかくなのでIPv6でもファイヤーウォールを設定しておきたいのでIPv6用には別ファイルを用意する。

ip6tables.rule

—

*filter

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn’t use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d ::1/128 -j REJECT

# Accepts all established inbound connections
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

# Allows all outbound traffic
# You could modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp –dport 80 -j ACCEPT
-A INPUT -p tcp –dport 443 -j ACCEPT

# Allows SSH connections
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
-A INPUT -p tcp -m state –state NEW –dport 22 -j ACCEPT

# Allows SMTP connections
-A INPUT -p tcp –dport 25 -j ACCEPT

# Allow ping
-A INPUT -p ipv6-icmp –icmpv6-type 128 -j ACCEPT

# Reject all other inbound – default deny unless explicitly allowed policy:
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT

—

そしたら、これらのルールをiptablesに食わせる。

iptables-restore < iptables.rule

ip6tables-restore < ip6tables.rule

ルールを食わせてからおもむろにiptables-persistentパッケージをインストールする。

apt-get install iptables-persistent

するとインストール時にその時点でのiptablesの設定内容をファイルに書き出すか？と尋ねられるのでyesと答えるとIPv4用のルールとIPv6用のルールがそれぞれ/etc/iptables/rules.v4,rules.v6に書き出される。これで、再起動したらルールが復活する。

次にapt-get install sshguardでsshguardをインストールする。これは起動すると自動的にsshguard用のiptablesルールをiptablesに追加してくれるので特になにかする必要はない。

これで再起動すれば余計なポートの遮断とブルートフォース攻撃の遮断が始まる。

もしiptablesの設定に失敗した時は、sysv-rc-confでiptables-persistentとsshguardを無効にした上で再起動し、再びiptablesに新しいルールを食わせた後、dpkg-reconfigure iptables-persistentで再びルールを書き出し、その後、sysv-rc-confでiptables-persistentとsshguardを再度有効化して再起動すればよい。

注意すべきは、sshguradが立ち上がった状態でdpkg-reconfigure iptables-persistentをするとsshguard用のiptablesルールが含まれた状態でルールを書き出してしまい、結果、次に起動したときにiptables-persistentとsshguardがどちらもsshguard用のルールを登録して二重に登録されてしまうこと。その場合は、/etc/iptables/rules.v4,v6を直接書き換えてsshguard用の行を削ってもいい。

 

起動したらまずは固定IPに設定しなおす。

/etc/network/interfacesにeth2の項目がある。DS47は内蔵の8111G二つがeth0,eth1で認識されるのでLUA3-U2-AGTはeth2になる。これがインストール時にはdhcpに設定されているので、このdhcpをstaticに書き換えた後、その下に固定IPの設定を記入する。

address xxx.xxx.xxx.xxx

netmask xxx.xxx.xxx.xxx

gateway xxx.xxx.xxx.xxx

この時点で一度shutdown -hP nowで電源を切り、ヘッドレス・手足レスにした上で再起動する。別の端末からsshでログイン出来ることを確認して、以後はsshでリモートで設定する。

次に、/etc/apt/sources.listを開き、それぞれのリポジトリにcontrib non-freeを追加して非GPLなパッケージもインストール対象にする。ついでにapt-get updateでリポジトリキャッシュを更新。

まずは余計なサービスを止めるためにapt-get install sysv-rc-confでsysv-rc-confをインストール。起動して、exim4,dovecot(POP3,IMAPサーバー),rpcbind,nfs-commonあたりをすべてチェックアウトしておく。これで余計なサービスは起動しなくなる。

 

さて、OSはどうしようかと思ったのだが、今回のサーバーはできる限りメンテナンスの手間を減らして長期にわたり運用したいということで、いつものFreeBSDで構築する代わりにバイナリアップデートでメンテナンスできるLinuxをインストールすることにする。

本来ならUbuntu Server 12.04 LTSにして2017年までサポートしてもらうというのが理想だが、なぜかUbuntu ServerのインストーラーはLUA3-U2-AGTを認識しなかったので、代わりにDebianのStable版の最新であるWheezy(7.1)をインストールすることにする。

Windows上でDebian 7.1のNetinstall Amd64 ISOイメージをダウンロードし、UNetbootinを使ってこのISOイメージからFAT32フォーマットしたUSBメモリにブート可能なシステムを書き込む。あとはUSBメモリをDS47に刺してUSBメモリから起動した後、Debianのインストーラーに従ってお任せでインストール。途中、ホスト名を聞かれるので、この時点でいずれ置き換えるべきこのサーバーの名前をFQDNで入力しておく。

最後にtaskselでインストールするパッケージの選択を要求されるので、Webサーバー、メールサーバー、SSHサーバーと標準ユーティリティーを選んでおく。インストール完了したらBIOSから内蔵mSATAをブート領域に選んで再起動。

中古PCに以前のサーバーのHDDをそのまま移植して無理やり立てた自宅サーバーもそろそろ１年半が過ぎて、いくら何でも正式に構築した信頼性の高いサーバーに更新した方がいいだろうということで、思い立ったが吉日、サーバーの再構築へ向けての準備作業に入る。

今回のサーバー構築にあたっての要件は、ファンレス・スピンドルレスで長期間ハードウェア的にメンテナンス不要であること。というわけで、そういう構成が可能なものを見繕って、ShuttleのDS47というベアボーンを選択。こいつの特徴は、Celeron 847搭載で64bit OSが使えること、内蔵mSATAスロットがあるのでmSATA SSDが使えること。心配点はEthernetインターフェースがRealtek 8111GでこれがまだどのPC-UNIXでもサポートされていないことぐらい。

というわけで購入時についでにTOSHIBAのmSATA SSD 60GBを購入し、MacBook Proのメモリ増設で余っていた2GB x 2のメモリを転用、ハードウェア的な準備はあっさり完了。

Ethernetインターフェースは予想通り認識されなかったので、USB2.0-Gigabit EthenetアダプターであるBuffalo LUA3-U2-AGTを購入して接続。幸いにもDebianとFreeBSDは素直に認識する模様。

ディスプレイはHDMI接続、キーボードはPS3につないでいたものをとりあえずUSB接続。どうせこれらはインストールが終了したら外してしまいヘッドレス、手足レスで運用するので、適当にごまかす。

sendmail-sasl2のportのバージョンが上がっていたのでportupgradeでバージョンアップしたら、いつの間にかメール中継が出来なくなっていた。

ログを確認するとメール送信時のSMTP AUTH認証が出来なくなっているらしい。このサーバーは送信メールをとあるISPのSMTPサーバーにすべて丸投げする設定になっているので、このSMTP AUTHが通らないとすべてのメールがロストするんだよね。困った。

で、原因を調べてみると、どうやらこれまで-sasl2や-tlsなどのサブportに分かれていたsendmailのportがすべてmail/sendmailに統合されてオプション指定で選択する様に変更されたらしい。ところがportupgrade時にsendmail-sasl2からsendmailにアップグレードしておきながらSASLのオプションはデフォルトで外れているというなんという盲点。SASLが追加されてないとSMTP AUTHに必要なライブラリがないので認証できていなかっただけというオチ。

で、make configでオプション画面を再び呼び出してSASLとSASLAUTHDをチェックしてmakeしようとしたら、エラーでストップ。どうやらデフォルトでTLSをチェックした状態でインストールされたものはsendmail+tlsのパッケージとして登録される様になっており、SASLがチェックされると別パッケージ名になるのでコンフリクトだとおっしゃる。しょうがないので、sendmail+tlsをデリートしてから、デフォルトにSASLとSASLAUTHDを追加(TLSもデフォルト通りついたまま)してmake install。どうやら無事にsendmail+sasl2+tlsとしてインストールされた様だ。その後、メール中継が無事に動いていることを確認。maillogを見ても中継出来てなかった間に特にメールは来てなかったみたいなのでとりあえず一安心。

ていうか、こんな大事な事、ちゃんと/usr/ports/UPDATINGに書いとけよ。

どうやらWordPressの管理者ユーザーとして一般的に最初に作成されるadminを決め打ちで狙った辞書攻撃が多発しているらしい。

このサイトのadminユーザーのパスワードはパスワードジェネレーターで生成したランダム文字列にしてあるので辞書攻撃に屈するとは思えないが、それでも普段使わないユーザーに攻撃を受ける可能性があるというのは気持ち悪いのでadminユーザーは削除することにする。

まずは自分のアカウントを特権管理者に昇格。次にadminユーザーの所有にしてあるトップサイトのユーザーに自分を追加。最後にadminユーザーを削除すればOKかと思いきや、adminユーザーはサイト管理者のメールアドレスを持っているので削除できないとかぬかしおる。

ちょっと調べてみると新しいユーザーを作成してから削除しろとか書いてあるんだが、サイト管理者のメールアドレスを持った別のユーザーを作成しようとすると、同じメールアドレスを持ったユーザーが既にいると言って登録拒否。なんじゃこれ。しょうがないので、adminユーザーのメールアドレスを適当に変更する。これはできるのね。

待てよ？adminユーザーのメールアドレスが変更できるのなら、これでサイト管理者のアドレスとは違う様になったのだから、先のサイト管理者のメールアドレスを持ったユーザーは削除できないという制限には引っかからないのではないか？と思い削除を試みたら、案の定、削除できるじゃないの。つまり、WordPressはサイト管理者として登録されたメールアドレスを持つユーザーを削除できない特別ユーザーとして扱うくせに、このアドレスを持つユーザーが存在しなくてもまったく気にしないということか。意味が分からんが、まあ結果的に攻撃を受けやすいユーザーがいなくなったので良しとしよう。

 

FreeBSDのportsから入れたja-wordpressがアップデートされた。(3.4.2->3.5.1)

既にWordPressはWordPress本体から直接アップデートする方式にして最新の3.5.1に更新してあるので、この状態で間違ってportupgradeをかけてしまうといろいろ上書きされるかもしれない。今後のことを考えると実際にはファイルを削除せずにja-wordpressをインストールしたという登録情報だけを削除しておきたい。

具体的には/var/db/pkgにインストールしたパッケージの情報がベタに書き込まれているので、この中のja-wordpressディレクトリを削除(安全のために実際は移動)する。

この状態でportversionを実行すると正しくportsのインストール情報が更新されて無事にアップデートが必要なインストール済みportsのリストからja-wordpressが消えた。