NICT 公開 NTP サービス

日本国内のNTPサーバといえば、ひと昔前は福岡大学のサーバ(clock.nc.fukuoka-u.ac.jp, stratum 1)が標準的に使われていましたが、徐々に負荷が上がり、福岡大学のサーバ管理者の方が2ちゃんねるで過負荷を訴えるという事態になりました。
当時の記事 - スラッシュドット ジャパン | 福岡大学NTPサーバの混雑解消にご協力を
それ以降は、インターネットマルチフィードのサーバ(ntp.jst.mfeed.ad.jp, strutum 2)が使われることが多くなってきました。個人ユーザはstratum 1のサーバには同期するべきではないというのが一般的になりました。
わりと最近、NICT 公開 NTP サービスというのが出てきましたが、これがなかなかすごいです。

[Q.2-1] stratum はいくつですか?
[A.2-1] stratum 1 です。なお、基準としている時計は「日本標準時」です。
[Q.1-6] 個人ユーザですが、stratum 1 にアクセスしても構いませんか?
[A.1-6] はい、どうぞ。

すごい。太っ腹。
上の/.Jの記事で、福岡大学のNTPサーバに対するアクセスは毎秒900リクエストに達していたそうですが、

[Q.2-3] 処理能力はどのくらいですか?
[A.2-3] 毎秒100万リクエスト以上 (1Gbps ワイヤレート) です。

何というスペック。福岡大学の1000倍以上です。
私の自宅サーバも ntp.nict.jp を見るようにしました。とはいえmfeedのほうがネットワーク的に近いらしくディレイは小さいようでした。なので一概にどちらがいいとは言い切れませんが、今後はNICTのNTPサーバが日本の標準になっていきそうな感じですね。

IISでApache互換のBASIC認証を使う

IISのユーザ認証機能には常々不満を感じていたのですが、「IISPassword」というソフトウェアを見つけました。
IISPassword
これを使うとIISApache.htaccess, .htpasswd互換のBASIC認証ができるようになります。 インストール、設定ともに簡単でサービスの停止も一度IISを再起動するだけです。また、非商用・商用ともに無償で使用することができます。
IISにも「基本認証」という機能がありそのまんまBASIC認証なのですが、こちらはWindowsのアカウントを使って認証を行います。なのでWindowsドメインアカウントかローカルアカウントを作っておく必要があります。
また、基本認証を行うとIISのプロセスの権限が認証を行ったユーザに変わります。Unixのseteuid(2)のような状態です。認証だけを行いたい場合はこれが邪魔になることも多いのではないでしょうか。
そして、まずいことになぜかAdministratorでの認証を無効にできません。他のユーザは無効にすることができます。つまり、基本認証を使う場合Administratorで認証を試行可能なプロンプトが必ず出てしまうことになります。もうアホかと。
IISPasswordを使うとWindowsのアカウントとは関係なく認証用のユーザを作ることができます。また、IISのプロセスの権限は匿名ユーザのままになります。おそらく多くの場合はこちらのほうが使い勝手がよいと思います。
ASP(Active Server Pages)を使いたがる方々がいるので仕方なくIISを使っているサイトがあるのですがやっぱり好きにはなれません。

DeleGateでクライアント認証付きSSLリバースプロキシサーバ

DeleGateでクライアント認証付きSSLリバースプロキシサーバ、いわゆるSSL-VPNの一種を構築しようとしています。
クライアント認証にはSSLクライアント証明書を使います。クライアント証明書をまともに運用しようとするとCRL(証明書失効リスト)を使わないといけません。
DeleGateはCRLを読み込めるのですがかなりハマりやすい手順なのでメモしておきます。
OpenSSLで以下のファイルを作成します。作り方は検索すればすぐに見つかるのでここで書くこともないでしょう。これらのファイルを /var/spool/delegate-nobody/lib に置きます。

server-key.pem: サーバの秘密鍵
server-cert.pem: サーバ証明書
cacert.pem: CAのルート証明書
crl.pem: CRL

ここからがハマりポイントです。サーバの秘密鍵サーバ証明書、CAのルート証明書はsslwayのオプションで指定できるのですがCRLのファイル名を指定する設定項目はありません。
CRLを読み込ませるには以下のようにハッシュ値をファイル名としたシンボリックリンクを作成しておきます。拡張子も忘れずに付けます。

ln -s cacert.pem `openssl x509 -in cacert.pem -hash -noout`.0
ln -s crl.pem `oepnssl crl -in crl.pem -hash -noout`.r0

DeleGateの設定例を書いておきます。DeleGateSSLリバースプロキシとして、webserverに素のHTTPで接続する構成を考えます。

delegeted -P443 \
 SERVER=https \
 FCL='sslway -key server-key.pem -cert server-cert.pem \
  -CApath /var/spool/delegate-nobody/lib -Vrfy -crl_check' \
 MOUNT='/* http://webserver/*' \
 PERMIT='http:{webserver:80}:*'

-Vrfyはクライアント証明書の提示・認証を強制するオプションで、-crl_checkはCRLを読み込むオプションです。-crl_checkはマニュアルのどこを見ても書いてありませんので注意。


以下愚痴
企業で自己署名証明書なんか使いたくないなあ。
ちょっとはセキュリティに金かけろよ。

L2TP over IPSec

会社でリモートアクセスVPNを構築することになりました。
クライアントはWindows PCなので、標準でサポートされているL2TP over IPSecを選択することにしました。
IPSecはユーザ認証機能を持っていませんが、L2TPと組み合わせることによってユーザ毎にアクセス制限を行うことができます。
IPSecにユーザ認証機能を追加するXAUTHというのもありますがWindows標準では対応してないので見送り。
Windows標準対応のVPNプロトコルにはPPTPもありますが、IPSecよりセキュリティ的に劣るのでこれも見送り。
VPNルータはL2TP over IPSecに対応していることと価格がそれなりに安いことでAlliedのAR450Sを選定しました。
わかりやすい日本語ドキュメントがあるのもポイント高いです。
IPsec NAT-Traversalを利用したリモートアクセス型L2TP + IPsec VPN(クライアントはWindows XP)
ドキュメントを参考に設定を行いVPNを構築することができましたが、NATとファイアウォールの設定で少しはまってしまいました。
IPSecファイアウォールとNATの設定が相互に絡み合うので接続できない原因を特定するのに苦労してしまいました。
IPSec自体も設定項目が多いので、相互接続事例がない場合のトラブルシューティングはさらに困難が予想されます。
私はまだそれほどVPNの構築をしたことはありませんがもうIPSecはめんどくさいのでSoftEtherに行ってしまいたい気分です。