webサーバ」カテゴリーアーカイブ

apacheにexpiresモジュール追加

前のブログに書いた奴再投稿。
以前はこの方法でexpiresをインストールして一斉に書き換えた。

apacheにexpiresモジュール追加
http://mustache-in-g.blogspot.com/2008/06/apacheexpires.html

HTTPのレスポンスにexpire date(有効期限)が設定されて無いよ~、と報告受けたので、無い場合はapacheで勝手に発行してもらいたい。という事でmod_expiresを実装する事にした。

まず、DSOが有効になってればapacheをコンパイルし直す必要が無いのでラッチー。
調べてみる。

# /usr/local/apache/bin/httpd -l

Compiled in modules:
core.c
mod_authn_file.c
mod_authn_default.c



mod_userdir.c
mod_alias.c
mod_so.c

mod_so.cがあるので、DSO有効みたい。ヤッタネ

早速実装に入ります。

/usr/local/apache/bin/apxs -ic mod_expires.c

でまずは、エラー。怒られました。

# ./apxs -ic mod_expires.c
gcc -DLINUX=22 -I/usr/include/db1 -DUSE_HSREGEX -DUSE_EXPAT -I../lib/expat-lite
-fpic -DSHARED_MODULE -I/usr/local/apache/include -c mod_expires.c
gcc: mod_expires.c: No such file or directory
gcc: no input files
apxs:Break: Command failed with rc=1

これはmod_expires.cの場所が探せてないって事らしいです。

指定方法は調べるとみんないろんな方法でやってて、うまくいかず。
とりあえず、

/usr/local/apache/bin/apxs -ic /usr/local/src/apache_x.xx.xx/src/modules/standard/mod_expires.c

でうまくいった。

その後、httpd.confにLoadModuleで上で作られたmod_expires.soを追加。
と、Expiresの設定を追加。

LoadModule expires_module libexec/mod_expires.so
ExpiresActive On
ExpiresDefault “access plus 300 seconds”

※”access plus 300 seconds”の部分はデフォルトで設定される有効期限を記述。この場合アクセスから5分

後はapache再起動してOK。

ターミナルソフトか、コマンドプロンプトで80番ポートにアクセスしてGETしてみる。

C:\>telnet www.hoge.jp 80
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 27 Jun 2008 09:22:48 GMT
Server: Apache/1.3.17 (Unix) PHP/4.3.5
Cache-Control: max-age=60
Expires: Fri, 27 Jun 2008 09:27:48 GMT
Connection: close
Content-Type: text/html

確認OK、追加されてました。

ちなみにexpiresは何もサーバ側いじくる必要なくて、htmlやcgiなんかでも対応できるようです。
今回は面倒なのでデフォルトを設定してみました。

モジュールさえ実装されていればhtaccessでも可能でしょう。


カテゴリー: linux, server, webサーバ | タグ: , , , , , , , | apacheにexpiresモジュール追加 はコメントを受け付けていません。

HTTPS脆弱性問題とはどんな事?

HTTPS脆弱性のニュース。
http://journal.mycom.co.jp/news/2011/10/03/010/index.html
詳しく何が問題だったのかあまり書かれていないのでググッてみた。

発生条件など
http://blogs.technet.com/b/jpsecurity/archive/2011/09/27/3455728.aspx
どういった脆弱性か
http://jvn.jp/cert/JVNVU864643/index.html
CBCモードのイメージ(わかりやすい、これいいね!)
http://www.triplefalcon.com/Lexicon/Encryption-Block-Mode-1.htm
記事によるとCBCモードというので「初期化ベクトル (IV) の決定方法に問題がある」ということらしい。

最後のリンクのイメージを見た感じ、1つ前のブロックをくっつけて暗号化していく方法だが、その最初にくっつけるやつが問題、という事かな?

そしてそれをすべり込ませる条件が

  • 標的となるユーザーが HTTPS セッションを使用している必要があります。
  • 攻撃者が HTTPS トラフィックを解読するには、悪意のあるコードをユーザーのブラウザーセッションに挿入し実行する必要があります。かつ、
  • 既存の HTTPS 接続にピギーバック攻撃を仕掛けるには、攻撃者の悪意のあるコードは、HTTPS サーバーと同じ発信元である必要があります。

という事で、これを大量のセッションで仕掛けてくると、そういうことらしい。たぶん。

多分2つめの条件を使って目印を置いていくって感じなのかな?
常にハックのコードを抱き合わせで送って、一緒に暗号化させて挙動を解析してしまうと。

3つめの条件(ピギーバック攻撃)は正規のHTTPSに乗っかって送るのでこう言うのか、へーー。
トラックに車乗っけてるイメージ。

ま、とりあえず実際の攻撃は未確認ということで、早急に対応に走っているブラウザさん達にカンシャ


カテゴリー: server, webサーバ | タグ: , , , , | HTTPS脆弱性問題とはどんな事? はコメントを受け付けていません。