以下の改善を行った。
１． 中間証明書から、クロスルート証明書を削除
とりあえず、クロスルート証明書をつけておけばいい、と考えていたのだが、不特定多数のユーザから、PCブラウザを含む不特定のクライアント環境からのアクセスを想定している場合、クロスルート証明書の設定は推奨されません。ということになったらしい。
詳しい説明は大手に任せる。
２． ssl.conf を編集
春の修正では正常に受け付けてもらえなかった命令が動くようになっていた。
以下のとおり修正。
SSLProtocol ALL -SSLv3 -SSLv2 -TLSv1 -TLSv1.1
この修正により、ちょっと古いブラウザでは、このページは見れなくなった。セキュリティ維持のためである。
SSLサーバの信頼性をチェックできるページでチェックすると、
現時点で、当サイトのランクは「A＋」！めでたしめでたし。
細々とブログをやっていたが、Facebookとぐぐたすと連携させてみた。
これにより、自分のブログに書くだけで、自動的に、
Facebookとぐぐたすにも投稿されるのだ！
というわけで、テストを兼ねた投稿。
こっちは無償版もある。
古いPCに入れてセキュリティアプライアンスにしたり、仮想マシンにインストールして仮想アプライアンスにできる。
企業利用であれば、サポート付きの有償の製品版を利用するといい。
http://www.plum-systems.co.jp/endian-community/
新しいセキュリティ対策ソフトの話が無料で聴けるので、聴きに来てます。
既存のソフトのように、アホみたいに全ファイルのスキャンをするのではなく、WindowsOSの特性に着目して、挙動を監視、例えばマウスもキーボードも画面たっちもしてないのに、銀行振込の挙動をしだしたら止めるって感じです。
今までのソフトは、家捜ししたあげく、新型すぎる爆弾には気づけない、みたいな感じでしたが、これは金属の箱がカウントダウンしているのを発見したら、それが単なるタイマーなのか、爆弾なのかを見極めて、爆弾ならカウントダウンを止める感じです。
ハミングヘッズと言う国内ベンチャーが作ってます。
最近、驚くべき記事を見つけたので、ご紹介する
記事に書いてあるが、12文字以上の長いパスワードを使うことや、パスワードの使い回しをしない、二段階認証などセキュリティ的に強固な認証機構を利用する、といったことのほうが重要とのこと
システムの許す限り、数字･記号･大文字･小文字を盛り込んだ12文字以上のパスワードで、システム毎に違うパスワードを使用する、といった運用が安全のようだ。
だがしかし、システム毎というかサイト毎にパスワードを使い分けることは、なかなか難しいと思う。
大文字小文字を区別しなかったり、記号が使えなかったりするサイトがまだまだ存在するからだ。
そう考えると、パスワードという概念から離れた、新たな認証方式の概念が必要となってきているのかもしれない。
現時点では、それが二段階認証などなのか。。。
連携できるかのテスト
NICの設定を変更せざるを得なくなり、変更して再起動したところ、
名前解決が出来なくなる。
手動でネットワーク設定をすると解決するが、
service network restart とか reboot とかすると、設定が残らない。
答えは、今まで nameserver を記述していた、resolv.conf の
書き方が変わっていた。いつの間に!!
設定が消えてしまった直後、resolv.conf を見るとわかるのだが、
ifcfg-eth● に書け、的な英文が書かれている。
そう。ifcfg-eth● に、
DNS1=172.16.0.19
のような設定を追記するだけで解決できるのだ。
設定後は、service network restart とか reboot とかしましょう。
2014/9/24 20:13 ? 2014/9/28 21:00
サーバの電源が入らない障害が発生しました。
機器を交換し、現在は復旧しています。
投稿を編集しようとしたところ、タイトル欄だけが空白になってしまった。
本文を編集して更新したところ、タイトル無しになってしまった。
タイトルを再度書いて更新。
タイトル無しになってしまった原因は、php.ini の定義ミス。
この前、ネットで推奨設定が出ていたので、それを見習った結果の失敗。
そのとき、下記定義
mbstring.encoding_translation = Off
mbstring.detect_order = auto
mbstring.substitu_character = none
の編集のほか、
mbstring.internal_encoding = EUC-JP
としていたのだが、これが原因。
mbstring.internal_encoding = UTF-8
が正解。
修正後、HTTPサービスを再起動して対応完了。
ニュース報道でも取り上げられていますが、何かって言うと、
暗号化通信を導入しているサイト（https://?? のページ）が、
これの対策がされていない状態で 攻撃を受けると、
最悪の場合、そのサイトの秘密鍵が流出（※）します。
要するに、秘密鍵を手に入れた人は、そのサイトの
暗号通信を解読し放題、ってことです。
ID、パスワード、個人情報、クレジットカード番号 などなど・・・
※詳しく書くと、OpenSSLライブラリを利用しているプロセスの
メモリの内容が漏洩してしまいます。
さらに書くと、手に入れた秘密鍵を利用して、
精巧な偽サイトを作ることが出来ます。
この手法で作られると、警察などで公開されている
見破り方が通用しません。
ちなみに当サイトは本件脆弱性に該当しません。
本件を調べている中で、 続きを読む OpenSSLの脆弱性(Heartbleed)対策