月別アーカイブ: 2月 2012

VPSの管理接続sshの認証にID&Passwordではなく、鍵ファイルとID&PassPhraseを使う。
sshサーバで
ssh-keygen -t rsa
とか打ち込むと、

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
ここはEnterで、

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
で、鍵に設定するパスフレーズを設定する。

ホームディレクトリの .ssh ディレクトリ下に、id_rsa, id_rsa.pubのファイルが出来る。
id_rsaが秘密鍵、id_rsa.pubが公開鍵。
sshでは、sshサーバのユーザホームディレクトリの .ssh/authorized_keys ファイルに公開鍵を入れて、クライアントに秘密鍵を入れる。
authorized_keys ファイルは複数の鍵を列記出来るので、
cat id_rsa.pub >> authorized_keys
みたいに、最後に追記する。

で、id_rsaをクライアントに入れる。
PuTTYの場合は、秘密鍵を一度PuTTYgenで処理して保存して、PuTTYの接続＞SSH＞認証＞認証のためのプライベートキーファイルに設定してやる。
さくらのVPSだと、ssh以外の管理接続が出来るけど、ServersMan@VPSを含む一般的なVPSではssh管理になるので、ID/Password認証より強度の強い鍵認証を導入したい。

(373)

　最近、うちの記事で良く登場するSSLボックスのRapidSSLの話。
　年額2100円と安いSSLサービスなので、それなりに面倒な点がある。
　それは、ルート証明機関が新しい物のため、ちょっとした追加設定を入れないと証明書が無効になることがある。

(事前メモ、証明機関＝CA、証明書＝CERT）
　一般的にSSL証明書はルート証明機関（最上位の認証機関）から直接証明書を発行されるわけではなく、ルート証明機関から証明書発行機関として認証された中間証明機関から証明書を発行されるのが一般的である（RapidSSLのルート証明機関はGeoTrust CAで、そこに認証されたRapidSSL CAが証明書を発行してくれる）
　また、ルート証明機関は元々PCやスマホなどのブラウザに証明書が内蔵されていて、その証明書によって証明機関が証明される。
　これは機種やバージョンによって無効なルート証明機関が存在する事を意味し、GeoTrust CAも古いAndroidやFirefox等では認証されない（証明書がインストールされていない）
　無効なルート証明機関から発行された証明書は無効な証明書として判断されて、セキュリティメッセージで「信頼されない証明機関から発行されています」「接続は推奨されません」等のメッセージが出て、せっかくセキュリティのためにSSLを導入しても、逆にとんでもない怪しさを出してしまう（もっとも、信頼されていない証明機関から発行されていても通信の暗号化が出来ることに代わりはないので、個人的に通信を暗号化するためだけの目的であれば続行してしまう手もある）
　では、RapidSSLは古い端末で正常に表示できないのかというと、対応策が存在する。
　それは、GeoTrust CAを更に別の証明機関から証明して貰うことで有効な証明機関として認証するという方法だ。
最新のブラウザでは
(ROOT)GeoTrust CA -> RapidSSL CA -> User CERT
となるところを
(ROOT)Equifax Secure CA -> GeoTrust CA -> RapidSSL CA -> User CERT
と言うように4層認証にする。
Equifax Secure CAはGeoTrust CAより歴史あるCAなので、WindowsXPや初期のAndroidにも登録されている。

実際には、各種プログラムのSSL証明書設定で証明機関証明書として4層認証用の設定を入れる。
↓（上のCERTが4層用GeoTrust CAの物で、下のCERTがEquifax Secure CAの物）

　これを各SSL関連記事で書いたように登録することで4層認証動作するように出来る。

　なお、RapidSSLで証明書を請求するとき、
www.hogepiyo.tld や web.hogepiyo.tld
　の証明書を取得すると、証明CN(コモンネーム＝DNS名)フィールドに、www.hogepiyo.tld or web.hogepiyo.tldとhogepiyo.tldの両方が併記されるので、両方のサーバで使うことも出来る（IPに制限はない）
　なので、hogepiyo.tldで運用するつもりでも、適当なホスト名を付けた証明書を取得しておいた方がオトクかもしれない（ただし、ブラウザの参考表示などでは第一CNが表示されるので、hogepiyo.tldでwww.hogepiyo.tldの証明書と表示されたりする）
　なお、このCNのルールは私が取得した時点での物なので、証明書を取得するときにはSSLボックスの説明を参照されたい。

(521)

　SSL証明書なんてあったって無くたって同じという人が居るけど、どうなのかという話。

　一般的な有線LANの話をすると、スイッチはMACアドレスが一致するポートにのみデータを流すのでデータが漏れることはないような気がする。
　しかし、ちょっと高価なスイッチ（インテリジェントスイッチ＝CISCO Catalyst等）を使うと、ポートミラーリングと言う設定が出来る。
　これは、あるポートの通信内容を別のポートに流す機能だが、これは別に特殊な機能でもなんでもない。

　典型的な接続形態でメールを使う場合だと
メールサーバ　＝　Internet　＝　アクセスルーター　＝　スイッチ　＝　クライアント
（Internet　＝　ルーターの集まりとも言える）
　みたいな感じになるけど、このスイッチをポートミラーリングできる機械にして、ルーターのポートをミラーリングしたポートにWireshark等のパケットキャプチャソフトを導入した端末を接続すると、LANから流れるデータは全部丸見えになる。

　POP3であれば、認証に使うID/Passwordもメール本文も丸見えなので、そのように仕組まれたネットワーク経由で一度でもメールチェックしたら最後、ID/Passwordを変更するまでメールボックスを覗き放題になる（ホットスポットのふりをして設置した無線APとルータ間にインテリジェントスイッチとロガーを仕込んだりしておくと、色々な情報が収集できることだろう）

　メール自体の暗号化（PGPなど）をすれば個別に暗号化したメール内容は保護できるけど、認証に使っているID/Passwordは上のように丸見えだし、暗号化していないメールはどうにもならない。
　Webでパスワードリセットのユニークコードをメールで送るようなシステムがあるけど、POP3が覗けるなら、この仕組みは簡単に破られてしまう（サイトでパスワードリセット処理をして、そのメールをいち早く受信してサーバから削除すれば、利用者の気づかない間にWebのアカウントを奪われる）

　POP3Sを使っていれば、セッションの開始から認証処理、データ転送、セッション終了までの通信が暗号化されるので、とりあえず通信内容が保護されるので、このような危険性を排除することが出来る。

　では、個別にメールを暗号化するのが不要かというと、そういうわけでもなく、SMTPS/POP3Sを使っていても、自分のメールサーバとクライアント間の通信が保護されるだけで、相手サーバとの通信は危険なインターネット内を経由することになるので、PGP暗号化は別のレベルで必要となる。

　と言うわけで、色々な場所から自分のVPSに接続して利用したい場合、SSL証明書を取得して色々な認証処理を暗号化してセキュアにした方が幸せだろう。

(359)

VPSでApacheサーバを使っていると、ネームバーチャルホストを使うことは多々あると思う（ServersMan@VPSのように無料でグローバルIPが複数取れるなら良いけど、普通のVPSはIP1個が普通）
また、cactiとかの監視ツールでApacheの状況を確認するのも良くあることで、通常は、Apacheのmod_statusを使って監視することになる。
通常、httpd.confのLocation /server-statusでハンドラーに接続するんだけど、バーチャルホストの第一候補ホストでmod_rewriteを使ってコントローラ制御をしたりしている場合、Locationに先行してmod_rewriteが走って、404 not foundになってしまう（こういう細工がない場合は、正常に繋がる）
ServerName localhostのバーチャルホストを作れば、localhost宛の監視を受け入れられるので、監視専用のバーチャルホストを作る。
また、監視機構がHostヘッダを使ってくれない可能性があるんで、localhostバーチャルホストは一番最初に定義する（ネームバーチャルで、一致するサーバネームがない場合、一番最初に定義されたバーチャルホストにマップされる）

<VirtualHost *:80>
ServerName localhost
DocumentRoot /var/www/html
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
</VirtualHost>

(1862)

　このサイトは日本語ドメイン使っているわけだけど、日本語ドメインの中身って
xn--日本語コード.tld
ってなってるんで、ヒナギク.com = xn--ockc3f5a.com ってなる。
検索エンジンなんかの登録の時には、この xn--ockc3f5a.com を使って登録するんだけど、日本語ドメインを意識していない相互リンクサイトとかだと、–がエンコードされて化けて登録できないことがあるようだ。
とりあえず、トップページだけ確認できればいいので、hinagiku.tld みたいなドメインを取得して、apacheのserveraliasディレクティブにセットしておけば、とりあえず使える。
WordPressの場合は、相対リンクではなく絶対リンクを作るので、hinagiku.tldのページはみんなヒナギク.comに向いてしまうのがイマイチ。

(212)