TLS拡張（RFC4366）仕様の一つ Server Name Indication（SNI）によって名前ベースのバーチャルホストでもSSLが使えますが、そもそもなぜ、名前ベースのバーチャルホストでSSLが使えないのかその理由と、SNIの仕組みと設定方法について調べてみました。 以前、WEBディレクターの方から、SSLを使っているサイトのバーチャルホストの設定依頼を受けて「SSL使ってるとバーチャルホストは使えないっすよ」とドヤ顔で答えてしまい、少し恥ずかしい思いをしました。(^^;) 昔の上司の言葉「常にアンテナを張っておけ！」を思い出します。 SNIの仕組み SSLを使っていると当然ですがHTTPヘッダは暗号化されているので、クライアントがどのホスト名を指定しているのか判断できないため、先頭のバーチャルホスト（図の場合は lamp-sv）が表示されてしまいます。 SNIではSSL/TL
ご無沙汰しております。細羽です。 昨年、AndroidにおけるSNI対応状況という記事で、SSL/TLSの拡張仕様であるSNI(Server Name Indication)について触れました。 少しニッチなテーマだと思っていましたが、つい先日、さくらのレンタルサーバでSNI SSLを提供開始というプレスリリースが発表されました。広いサービスでSSL/TLS導入への需要が高まっている今、このような事例は今後増えていくものと考えられます。 そこで本記事では、重要度が高まっているSNIについて、その技術の概要を改めて理解し、実際の運用に役立てられるように整理をしたいと思います。 知識の整理を目的にした前編と、実践を目的にした後編の2部構成でお届けします。 以下が前編の内容です。 SNIで何が出来るようになるのか SNIで複数ドメインが運用可能になるまで SNIが重要になりつつある背景 SSL運
RC4 with TLS has been broken for quite some time now, but I did not yet manage to make the switch. Having a little time on my hands, I decided to future-proof my Apache configuration. Basically, what I want to do is: Disable ciphers for SSL that have known weaknesses. RC4, I am looking at you. DES, yes, you are meant as well. This includes ciphers that are marked EXPORT. Use TLS 1.2 instead of the
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
攻撃ツールキットの「Darkleech」はApacheを使ったWebサーバに感染し、Webサイトを見たユーザーをマルウェアに感染させるという。 広く普及しているWebサーバソフトのApacheを狙った攻撃が横行し、過去数週間だけで推定2万を超すWebサイトが被害に遭っているという。IT情報サイトのArs Technicaや米Cisco Systemsのブログが4月3日までに伝えた。 それによると、この攻撃ではApacheを使ったWebサーバが「Darkleech」という攻撃ツールキットに感染。被害は米国や英国を中心とする48カ国に及んでいる。これまでに感染が確認された中にはLos Angeles TimesやSeagateなどの大手企業が運営しているWebサイトも含まれるという。なお、この両社はArs Technicaに対し、感染が発覚した時点で対処済みだと説明している。 Darkleec
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 久々のApache HTTP Server 2.4.1という安定版がリリースされたので、早速ベンチマーク評価を行う。今回はevent_mpmのExperimentがとれて、晴れてデフォルトMPMになったのでそれを使ってみたい。 日本一（ひょっとすると世界一）早いApache 2.4.1 event_mpmのレビューを意識してみた。 はじめに 個人的にも、event_mpmが採用されたことに最も注目している。event_mpmは非同期型のIO処理をしていて、nginxに近いアーキテクチャをとっている。厳密には、nginxの非同期と比べた場合、nginxは徹底的にノンブロッキング（accept4を使う等）してworkerスレッドで次々と並列処理し
cles::blog 平常心是道 blogs: cles::blog NP_cles() « t2g で GPS ログを可視化する :: LUMIX G X VARIO PZ 14-42mm/F3.5-5.6 ASPH./ POWE... » 2011/08/26 Apache Killer が騒ぎになっている httpd PoC DoS cve 165 0へぇ Apache Killer という Apache HTTPD への DoS ツールが出現して大騒ぎになっている模様。 プロジェクトからも「Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x 」というセキュリティアドバイザリが出ています。 ApacheのDoSツールとしてはSlowloris が騒ぎになって以来でしょうか。 Advisory: Range
検証 Exploit Code は Apache Killer (killapache.pl) よりも apachepartial.pl のほうが Perl モジュール Parallel::ForkManager の追加が要らないので楽ちん。 Usage: ./apachepartial.pl <host> [path] [parallel reqs] [loops] [port] perl apachepartial.pl pooh.gr.jp /robots.txt 60 0 80 pooh.gr.jp は結構頑丈だったので 60 並列でやっと CPU idle 30% まで減らせた。 path で指定するコンテンツを 1300 バイト以上にすると効果的になる。robots.txt はちっさいので攻撃効果が低くなったみたい。 対策を実行したら、まずサービスに影響がないかを確認する。そ
Apacheの脆弱性(CVE-2011-3192)いわゆるApache killerが話題になっていますが、その脅威については一部誤解があるようです。 以下は、非常に脅威とする報告の例です。 一方今回のはプロセスの肥大化を伴うので、実メモリ消費して更にスワップも使い尽くしてOS毎激重になったあげくLinuxとかの場合はOOM Killer発動と、他のプロセスや場合によってはOSを巻き込んで逝ってしまいます。 CVE-2011-3192 Range header DoS vulnerability Apache HTTPD 1.3/2.xより引用 以下は、それほど脅威でなかったとする報告の例です。 pooh.gr.jp は結構頑丈だったので 60 並列でやっと CPU idle 30% まで減らせた。 Apache Killer (CVE-2011-3192) 対策 for CentOS 5
数日前からFull Disclosureで騒がれてたけどやっとCVE採番されたので。 以前のISC BINDの脆弱性(CVE-2011-1910)とかに比べるとzero-day状態に なったにも関わらずApache側の動きが遅い気もします。(表に見えてなかっただけ？) アドバイザリは以下 CVE-2011-3192 Range header DoS vulnerability Apache HTTPD 1.3/2.x http://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/raw/%3C20110824161640.122D387DD@minotaur.apache.org%3E/ DoSだけといってしまえばそれまでですが、Apache HTTPDでは久しぶりに 現時点で出ている全バージョンが対象 (2011/
Apache HTTPD 1.3/2.x の Range ヘッダーの DoS 脆弱性について Apache HTTPD の 1.3/2.x の Range ヘッダーの処理に DoS 攻撃の原因となる脆弱性が発見されました。パッチがリリースされるまでのとりあえずの対策が公開されいます。 8月20日に Full-Disclosure メーリングリストにおいて、Apache HTTPD 1.3/2.x の Range ヘッダー処理の問題を突いて、Apache HTTPD を処理不能にしてしまうスクリプトが公開されました。
Apache Web Serverに未解決の脆弱性が存在し、この脆弱性を突いた攻撃が横行しているとして、Apache Software Foundationが8月24日付（米国時間）のアドバイザリーで注意を促した。 アドバイザリーによると、ApacheでRangeリクエストを処理する方法にサービス妨害（DoS）の脆弱性が存在する。影響を受けるのはApache 1.3とApache 2の全バージョン。脆弱性を突いてリモートから攻撃を受けると、大量のメモリとCPUが消費されてしまう恐れがある。 脆弱性情報は先にセキュリティメーリングリストでも公開され、攻撃ツールが出回って広く使われているという。この問題を修正するパッチは4日以内に公開される見通し。アドバイザリーでは当面の対策として、攻撃を避けるための設定方法も紹介している。
先日、Web サーバ勉強会 #2 が開かれました。内容は、Apache のチューニングということで、参加したかったのですが、他の予定があって参加できませんでした。 そこで、僕が個人的に行っている Apache のチューニングを紹介したいと思います。最初、スライドで作成しようかと思ったのですが、ブログにまとめたほうがよさそうなのでブログにまとめていきます。 まず、大前提として Apache をチューニングするうえで、大事なことはその Apache が提供する Web サービスの種類のよって大きくチューニングする内容が異なるということです。例えば、動画・写真共有サービスと株価情報のサービスを比較すると、当然のことながら大きくサービスの内容が異なりますし、HTTP レベルでみるとクライアントからのリクエスト数、データサイズ、などがかなり違ってきます。 ですので、まずは自分が扱っているウェブサービ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
慎重に扱うべきコンテンツに関する警告
Apache httpd 2.4.1を試してみた