サイト/サーバーに関する作業

HTTPSの無効化

HTTPでのアクセスを推奨しつつHTTPSのアクセスを可能にしていたのだが、証明書エラーを気にする方が多いので、そもそもHTTPSアクセスを無効にした。

HTTP推奨、HTTPS対応、SSL証明書無効というのは、実はUFJ銀行と同じなのだが(amakai.netの証明書を使用している。ゆうちょ銀行も似た方法。ちなみに、三井住友とりそなはNot Foundを返すようになっている。みずほはHTTPSが稼働していない)、どうしても警戒するらしい。

問題は、現代的なブラウザはスキームなしだとHTTPSから試してしまう上に、無効な証明書に対してセキュリティソフトが警告を出すこともあるためだ。

私の個人サイトだけなら別にいいのだが、仕事のほうのサイトでは受注に響く可能性が高い。そのため、そもそもHTTPSを無効化するという措置をとった。HTTPSは技術要求的な意味合いが強く有効にしてきたが、証明書の問題はコストの問題となるため、かなり難しい。もちろん、その構築が複雑である、という問題もある。

MozillaとEFFが、無料で簡単にHTTPSを使えるようにするためのものを用意しているらしいので、それに期待するしかない、といったところか。SSL証明書に関する悪質な利権主義が私は大嫌いだ。一部の人たちが「私達が認証局です」と名乗り、その身内か大金を払ったところが認証局となり、認証してほしかったら金を払えという。SSLの認証の仕組み自体が、利権を生むために作ったものだとしか思えないひどいものだ。

だからSSL証明書をとることは、金銭的にだけでなく、心理的にもかなり嫌だ。

PCの基礎知識の講座up-to-date

彼女にPCに関する知識をつけてもらわないといけないので、全然な人が日々覚えていくことで私の実務に使える知識が身につく講座をスタート。

メールで送っているものを転載している。

http://reasonset.net/chienomi/essay/articles/steady-study.html

CSS

CSSを更新したのだが、気づいたことがある。pre-wrapに設定されている場合などで、「折り返した行をインデントする」ということができない。だからおそらくはJavaScriptで論理行に交互に色付けすることが一般的になっているのだろうと思うが、それはあまり好みではない。

wrapされた行を指定するセレクタ、あるいは要素中の論理行を表すセレクタが欲しい。

ケータイのメール、eメール、VPS

ケータイのメールに関する設計がおおよそ固まった。結構複雑な構成なので試行錯誤となったが、いい感じになった。なお、今回は一般ユーザーが真似するのは難しい話になるが、一般ユーザーでも応用可能な方法を最後に紹介する。

やり方

まず、ケータイはWILLCOMのフィーチャーフォン(A)とスマートフォン(B)の2台だ。主にAを使用しており、現在のところBの用途は定まっていない。これは、Bのほうが多様に使うため、バッテリー的な理由だ。

「ケータイアドレス」はA、B共にある。Aはもちろん、Bも届くと直ちに自動で受信される。着メロや振り分けにも対応する。

基本的にケータイのメールをPCで扱いたい。打つのもバックアップもそのほうがずっと楽だ。そのような理由でまずメールの転送を考えるのだが、Aは転送ができるが、WILLCOMのスマートフォンであるBは転送できない。Yahoo Mobile Mailに属するサービスなので、恐らくソフトバンクでもできない。これは困った。

まずVPSのaliasを使ってケータイのバックアップ用のアドレスを作る。単純に共有するには、Aから転送されるそのaliasでPCとBに送るようにすればいい。だがこの場合、Bに送られたメールは孤立する。Bは転送できないため、この問題をこのアプローチで解消できない。

そこで、メール機能の設定でReply-Toヘッダを入れるようにし、返信時に他のアドレスに届くようにする。その受信アドレスはAliasとし、PCとスマホに転送する。

ここまでを実現するには次のことをしなくてはいけない

  • スマホのアドレスを教える時は転送用のアドレスも一緒に教え、送る時はそちらのアドレスに送るように頼む
  • PCからのメールを受信できるようにしてもらう
  • なりすまし防止機能をoffにする。でないとPCからケータイのアドレスで送った時にはじかれる(ソフトバンク、WILLCOMでは必須の設定)

オープンに使うには相手に頼まなくてはいけないことが多く、ややハードルが高い。クローズドなアドレス向きだ。

だが、これではAに送られたメールはAliasによってBとPCに行く。だが、Bで返信してしまうとAにはいかない。もしこれでAに行くようにしてしまうとループする。AのメールをBで扱うことができない。BのメールをAで扱いたいことはさすがにないと思うが、Aの絶望的な入力効率を考えると、バッテリーを気にしなくていい状況ではBで打ちたいところだ。

そこで、Android端末であるBにK-9 Mailを入れた。これはIMAPマルチアカウント対応のMUAである。これがなかなかすぐれもので、アカウント設定に加えて送信メールアカウントを設定できる。Aliasを使っている場合、ひとつのIMAPメールボックスに配送されるが、アドレスはひとつでないという状況になるわけだが、IMAPメールボックスのみを設定し、その上でそのメールボックスに追加のメールアドレスを設定するだけで対応できるのだ。

送信アドレスごとの署名、SSL/STARTTLSの設定、ポート設定など結構細やかにできる。複数のIMAPアカウントにも対応し、扱いやすい。K-9 Mailのアドレス帳はスマホのものをそのまま使用する。

だが当然ながらこのメールボックスPCで扱っている時もあるし、同期してほしくない時がある。なぜか「同期しない」設定にしているとリアルタイムに同期されてしまう。これは結構困る。同期設定はアカウントごとに可能だ。

方法としては、同期して欲しい時はグローバル設定で同期設定を「常に」、してほしくない時は「しない」に切り替えることでそれをコントロールできる。これでかなりいい感じになる。

そしてIMAPアカウントとしてAから転送されるアカウントを設定し、送信アカウントとしてAのメールアドレスを設定すれば完了だ。標準でストアする送信済みメールは自動で消されてしまうので、フォルダの設定でIMAPフォルダを指定しておく(普通はsentだろう)。

BからAのメールを扱う時はK-9 Mailを起動する。この方法の欠点は、K-9 Mailができる通知は通知だけなので、誰からメールがきたかによって通知方法を変えることができない。ランプ色や着信音などだ。もちろん、Bに直接送られたメールについては問題ない。

VPSを用いない応用

柔軟かつ簡単に設定でき、管理もできるということでVPSのアドレスを使っているが、それが嫌なら方法はある。

転送ができるアドレスと、IMAPアクセスができるアドレスを用意する。転送ができるアドレスは複数アドレスへの転送ができなくてはいけない。転送用アドレスは1つでいい。BとPCに転送されるようにすれば、Aのほうは転送設定ができるので、転送設定でその転送アドレスを指定すれば両方に、PCだけを設定すればAとPCに届くようになる。Bは転送アドレスをそのまま使う。

あとはIMAPアクセスすれば良い。Yahooは猛烈にレスポンスが悪いのでオススメしない。IMAPメールボックスはかなり遅いところが多い。VPSのものとは雲泥の差だ。

早いのはGMailだが、GMailはあまり好きでない。GMailを使えばK-9 MailでなくGMailの純正クライアントを使うこともできる。

DeleGateでHTTPSリバースプロキシ

私のサイトはずっとhttpsで接続できなかったのだけれど、ようやく手を入れることにした。

HTTPSによる接続自体はできるのでサーバーは動いているし、ファイアウォールも阻害していない。証明書関連の問題だと判断できる。

DeleGate + SSLについての情報は大概が古く、SSLwayについてしか言及されていない。DeleGateの最新マニュアルを見ると、STLSというビルトインTLSフィルタを持ち、またビルトイン匿名証明書を持つため証明書も不要であるように思える。ではどう使うのか??

jfuruyaのブログに答があった。DelegateのパラメータとしてSTLS="fcl,fsv:https"を渡す必要があるのだ。しかしこれだとHTTPでアクセスするとはじかれる。ちなみに、SERVER=httpではhttpsで接続しろと言われる。マニュアルを確認、どうもSTLS="-fcl,-fsv:https"であるべきであるということが分かった。

しかしそのままでいくとスタイルシートが表示されない。どうやら、httpsでページを表示しているのにhttpでスタイルシートをロードしているのが問題らしい。つまり、リンクはhref="http://..."ではなく、一般には説明されない書式でスキームを維持するhref="//..."形式にしなくてはいけないようだ。

とりあえずこのような特殊な接続をする人はいないと思うので、全体は修正していないが、ビルド時にテンプレートを変更するので、サイト全体をビルドする時には直る、はずである。

Mail Virtual Alias @ CentOS 6

メールサーバーの本運用は通常virtualであるはずだ。メールアカウントの数だけユーザーアカウントがあるというのは考えられない。

ただし、私の場合はサブドメインをバーチャルエイリアスにするため、バーチャルドメインが必要になる。

新しいDovecotに関する情報がなく苦労したが、http://vogel.at.webry.info/201312/article_10.htmlの通りにやってみた。大体これでうまくいったのだが、私の場合はいくつかひっかかった点があった。

まず、hown -R mailuser ~mailuserをちゃんと実行しておかなくてはいけないこと。vmailboxファイルは最後に/をつけ忘れるとmbox形式になってしまうこと。

しかしこれではPOPの認証がfailedとなる。調べてみると、このサイトにはデフォルトでコメントアウトしているauth-passwdfile.conf.extのロードをしていない。

[root@server ~]# grep -R auth-passwd /etc/dovecot
/etc/dovecot/conf.d/10-auth.conf:#!include auth-passwdfile.conf.ext

さらに、パスワードファイル認証も無効化されている。

[root@server ~]# grep disable /etc/dovecot/conf.d/10-auth.conf
#disable_plaintext_auth = no
# Authentication cache size (e.g. 10M). 0 means it's disabled. Note that
# 0 disables caching them completely.
# NOTE: See also disable_plaintext_auth setting.

この2点を修正したが、それでもエラーになる。原因はパスワードファイルのファイル名(設定ではなくファイル自体)が間違っていたためのNo such file or directoryだった。

さらにPostfixからのDovecot認証の利用は情報が錯綜してよくわからない状態だったが、結局のところ/etc/dovecot/conf.d/10-master.confのPostfixから利用するコメントアウトをはずすだけでエラーは出なくなった。しかしながら、認証自体がうまくいかない。userとgroupの設定を追加したが、元々666なのだから、効果はなかった。明らかに問題はPostfixにあり、Dovecotはこれでいいだろう。

telnetを打ってみると25番ポートが反応しない。ここでOP25Bによるものだと気付いた。

submissionの設定を探してみると、master.cfにsubmissionの項目があり、このコメントアウトをはずせばsubmissionは機能する。しかしながら

submission inet n - n - - smtpd
# -o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING

TLSを強制するとTLSが機能しない。とりあえず、TLSは要求しないことにした(encryptでなくmayにしておく)。

しかし、それでも544 host access deniedという応答で送ることができない。調べてみると、さらに別のパラメータを設定する必要があるようだ。main.cfに記述する。

smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_relay_restricions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
broken_sasl_auth_clients = yes

さらにスペルミスにもひっかかってしまったが、これでうまく通った。TLSが上手く動かない以外は正常だ。

TLSについて調べてみると、どうも鍵にパスフレーズがかかっていると使えない、ということだ。そこで、次のようにして問題の解決を図る。

[root@sesrver]# openssl genrsa -aes128 1024 server.key
Generating RSA private key, 1024 bit long modulus
.++++++
.........................++++++
e is 65537 (0x10001)
Enter pass phrase: #ここでは普通にパスフレーズを入力する
Verifying - Enter pass phrase:
[root@dti-vps-srv71 certs]# openssl rsa -in server.key -out server.key #これによってパスフレーズを消滅させる
Enter pass phrase for server.key:
writing RSA key
[root@dti-vps-srv71 certs]# openssl req -new -x509 -key server.key -days 3650 -out server.crt # certファイルを作る
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:JP #カントリーコード
State or Province Name (full name) []:Kanagawa #神奈川
Locality Name (eg, city) [Default City]:Yokohama #横浜
p {[
"さらにスペルミスにもひっかかってしまったが、これでうまく通った。TLSが上手く動かない以外は正常だ。",
"TLSについて調べてみると、どうも鍵にパスフレーズがかかっていると使えない、ということだ。そこで、次のようにして問題の解決を図る。"
]}

sb { -END
[root@sesrver]# openssl genrsa -aes128 1024 server.key
Organization Name (eg, company) [Default Company Ltd]:HarukaSound #組織名
Organizational Unit Name (eg, section) []: #部署はない
Common Name (eg, your name or your server's hostname) []:reasonset.net #FQDN
Email Address []:master@reasonset.net #メールアドレス
[root@dti-vps-srv71 certs]# openssl x509 -in server.crt -outform der -out server.der # derファイルの生成

これで鍵の生成は完了。ファイル名が若干変わったので、main.cfを修正。さらに、DovecotのSSLが設定されていなかったので、/etc/dovecot/conf.d/10-ssl.confを修正(ssl = yesのコメントアウトをはずし、ファイル名を修正)。

そしてmaster.cfencryptに戻して完了。STARTTLSが正しく働くようになった。

ルーターをCentOS7に

CentOS6はUSB NICを認識できなかったため、慣れないUbuntuを使ってきたが、ついにCentOS 7への移行を実現した。

刷新されたAnacondaインストーラを使う。何もいじらずにインストールできるようになっているが、その一方でインストールしながらユーザーが作成できるなど効率的なデザインに変化している。シンプルながら機能性が失われておらず、なかなか驚きがある。

インストールが完了すると例によってmei_meが騒ぐ。とりあえずrootでログインし

# rmmod mei_me

さらに二度と起動しないように、/etc/modprobe.d/blacklist.conf に

blacklist mei
blacklist mei_me"

とどめに、/etc/modprobe.d/modprobe.conf.local

install mei /bin/true
install mei_me /bin/true

NICの設定はAnacondaから行える。そのためいきなりネットワークに接続できた。

ネットワークの設定はnmtuiまたはnmcliで行う。nmtuiは対話的に利用できる。これを用いて設定する。もちろん、USB NICも正しく認識されている。

ifconfigがないため、net-toolsをインストールしておくほうが良い。また、digコマンドもないため、dns-toolsをインストールしておく。このほか、zshとvimとdnsmasqをとりあえずインストールした。

IP forwardingが無効となっているため、これを恒久的に有効にする方法を探したが、良い記述がない。systemdに移行したための問題だ。そこでやや乱暴だが、/etc/sysctl.d/99-sysctl.confに

net.ipv4.ip_forward = 1

と書いておく。これでリブートしておおよそうまく動くのだが、DNSをフォワードしてくれない。ファイアウォールに起因するが、CentOS7はfirewalldを使用しており、設定方法が分からない。とりあえずfirewalldを無効化すれば動く。

だが、もちろんそれは困るので、とりあえずsubID 0x10のネットワークのコネクションは全部通過するようにする。通らないのはDNSなので、sshログインで設定可能だ。

firewalldは動いていなければいけない。そして、0x10インターフェイスをtrustedにする。

# firewall-cmd --zone=trusted --change-interface=enp0s25

さらに恒久化するため、/etc/sysconfig/network-scripts/ifcfg-enp0s25にZONE=trustedを追記する。これで0x10(enp0s25)から入ってくるトラフィックは全て通過するようになった。

dnsmasqを設定すると、Ubuntuのように訳の分からないことならず、正しくDHCP, DNSともに機能する。

全体的な印象としては、systemd, firewalldという新機構が案の定手強い状況だ。Fedoraと違いiptablesと共存しているわけではないため、firewalldの設定は必ず習得しなければいけないという厳しいものだ。GUI込みならばそれほど難しくないのかもしれないが。

困ったことに検索してみても、firewall-configを紹介しているだけで、firewalldのコマンドラインにおける設定方法は全く紹介されていないのだ。

PostfixでTLSをサポートさせる

relay testでTLSがサポートされていないことには気付いていたのだが、なかなか検証できずにいた。ようやく今日やった。

証明書を作った記憶はあったのだが、なぜサポートされていないのだろうか、と調べてみた。すると、TLSまわりがごっそりコメントアウトされている。なぜコメントアウトしたのだろう?

まず、main.cfに追加されていたのがこの部分。

#SSL setting
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/server.pem
smtpd_tls_key_file = /etc/pki/tls/certs/server.key
smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_schache

これがコメントアウトされていた。わざわざ書いたのに。さらに、master.cfのこのセクションもコメントアウトされていた。

smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes

これはもともと存在した部分で、単純にコメントアウトされていたのだろう。恐らくはSASL authを無効にしたままでTLSを有効にすると起動せず、それで無効にした、というところではないかとは思うのだが。

これでrelay testするとTLSサポートが確認された。

簡易的なOP25B対応

様々な仕事が滞っている中なので、先行してメールを送れるようにだけはしておいた。

OP25Bとは、SMTPサーバーポートである25をISPが中継しない、というものだ。スパム対策だというのだが、実際は自由にメールを使わせない、メールをISPで一元化するものとなっている。

メールアカウントが提供するサーバーをそのまま使っていれば特に不自由は感じないという人もいるだろうが、近年のSMTPサーバーサービスはかなり複雑に認証され、フィルタされることもあって使い勝手は著しくよくない。以前ならそれに対する対応としてローカルなメールサーバーを使えばよかったのだが、今度はそれがISPによって蓋をされた格好になる。

各家庭でMTAから出す、ということそのものが特殊な要求と見るのかもしれないが、今はそもそもSMTPサーバーを提供しないメールアカウントも珍しくないので、やはりの必要だし、自宅でのメールサーバー公開もできない。

とりあえずシンプルな方法として、セキュアで確実にリレーしてくれるMTAが欲しい、ということで工夫してみた。

まず、VPSにPostfixを導入する。そして、次のように設定する。

inet_interfaces = localhost
mynetworks_style = host

これ以外についても適切に設定するが、これで外部からメールを受けとらないためセキュアな設定となる。もちろん、外部からメールを受けとるように設定する場合には、より広く適切な設定が求められる。

この状態ではSMTPを用いてメールを送信することができるのはVPS自身だけだ。しかし、VPSのループバックインターフェイス経由ならば送信できるため、SSHのポートフォワーディングを用いることで他のホストからのメールを中継してもらうことができる。

これには次のコマンドを使用する。

$ ssh -x -L 2500:localhost:25 remorthost.example.com

「ローカルの1024以下のポートを転送する場合、ローカルのroot権限が必要」なのであり、ここでは2500番ポートをリモートの25番ポートに転送することでroot権限なしに実現している。なお、リモートホストの名前はlocalhostにしないと、loインターフェイス経由での接続にならないので注意が必要。インターフェイスを気にしなければFQDNで指定しても接続できてしまうことがあるから、理解していないことがある。

-Lオプションのまんなかのargは、後で指定するhostが名前解決をし、接続するための名前だ。つまり、localhostを解決するのは、リモートホストで、リモートホストにとっての::1/127.0.0.1に接続される。

-nオプションを使えばバックグラウンド接続が可能なはずだが、ServerMans@VPSではそれができなかった。接続そのものが切られてしまう。タイムアウトして接続は切られてしまうし、不要なターミナルセッションが生まれてしまうが、通常通りのログインとした。

あとはMUAのSMTPサーバーとしてlocalhost:2500を指定すれば、MUAはVPSのPostfixとやりとりをしてメールを送信することになる。通信はssh(通常は22番ポート)を経由するため、25番ポートをブロックするOP25Bにはひっかからない。

VPSの活用方法としては一般ユーザーでも意味のある方法になるのではなかろうか。もっとも、セキュリティ管理などを考えれば一般ユーザーに進められる方法ではないが。

VPS * DeleGate によるフロントエンドサーバーを用いたインターネットサーバー

概要

IPv6への移行がこれほどまでに叫ばれているのに、世の中は全くIPv6に移行する気配がない。IPv4の枯渇はであり、そうなるとグローバルアクセス可能なインターネットサーバーというのは極めて難しい。重大な問題は、グローバルIPアドレスの価値が高すぎること、そしてISPが自宅サーバーを阻む方向にあることだ。

そこでよい対応方法のひとつとして、グローバルアクセス可能なVPSをリバースプロキシとして、という方法があり、さらにいえばVPNを汲むことでVPSをフロントエンド(ルーター)とするサイトを構築することも可能だ。

今回はとりあえず、「VPSを使ってインターネットにサービスを公開する」ところまで事を進めた。

事前準備

少なくともVPSと独自ドメインが必要不可欠だ。別に無料サブドメインでも問題はない。ただし、VPSは将来的にはVPNを汲むことが可能な、つまりはpppあるいはtunデバイスが利用可能なrootサーバーである必要がある。

私は今回、サーバーとしてDTI ServerMan、ドメインはXDomainを利用した。契約書を熟読するのに、何より時間がかかった。契約そのものは簡単で、特にクレジットカード決済ができる人ならあっという間だが。

そして、VPSを安全な状態にセットアップするまでがまた一手間。基本的手順としては、

  • 一般ユーザーを作る
  • 一般ユーザーのパスワードを強固なものにする
  • SSHのポートを変える
  • rootパスワードを強固なものにする
  • usermodでwheelグループに追加
  • visudo
  • FirewallをConnected/ICMP/SSHのみ透過するように変更
  • アップデート
  • 不要なサービスを止める

といったところになる。CentOSでのこうした個々の作業は情報が豊富なので、私は繰り返さない。各自調べてほしい。

この状態では基本的に何もできないので、サーバーを停止しておいたほうが安全である。

レジストラの方でリゾルバの設定(DNSレコードの設定)を行えばVPSに名前でアクセスできるようになる。普通はここで、VPS自身でサービスを起動し、ファイアウォールを設定してサービスを提供する。

私はとりあえずXDomain側でサービスを開始した。XDomainで設定しても独自ドメインでのサービスは提供できるのだが、フルカスタマイズはできないし、将来的にフロントエンドの変更が生じる場合があるので、やめておいた。

DeleGate

DeleGateは汎用のプロキシデーモンだ。HTTP/FTP/NTP/NNTP/Socks/SSH/SMTP/POP3/IMAP4などのアプリケーションゲートウェイ(リバースプロキシを含む)として機能するばかりでなく、ネットワークレベルゲートウェイとしても機能する。つまり、TCP/UDPパケットを転送することも可能。単純にこれをリバースプロキシとして動作させるだけでもかなり多くのサービスが提供できる。

ただ、CentOSにはDeleGateのパッケージがない。かつてはプロキシサーバーといえば、というほど有名だったが、今はマイナーなようだ。そこで手動導入したのだが、思わぬ問題が立ちふさがった。テスト環境はx86_64で、本番環境はi586ということが判明し、同じパッケージが導入できないのだ。そこで、本番環境はRPMで導入、一方テスト環境は

yum install gcc gcc-c++ make openssl-devel
# wget URI
# tar xvf file
# cd delegate9.9.8
# make
# cp src/delegated /usr/local/sbin/

これで最低限動作はするようになる。セキュリティや細かな設定は別として。

さて、テスト環境では

delegated -P 80 MOUNT="/journal/* blogURI/*"

で動作してくれたのだが、本番はそうはいかず、checksum生成をした上で

delegated -P 80 MOUNT="/journal/* blogURI/*" PERMIT="http:*:*"

としてあげる必要があった。

おまけ

無事動作したので、一区切りついたということでお祝いに寿司を食べてきた。

さらっと書いているが、結構大変な作業でトラブル続きだったことを報告しておく。