というワケで、以下それぞれの手順をメモしておきます。

Basic認証

ブラウザのダイアログが出て「ユーザー名・パスワード」を要求されるアレですね。認証をかけたいディレクトリに.htaccessを置く必要があるので、.htaccessが利用可能である事が前提です。

まずは、照合用の.htpasswdファイルを作成。言わずもがなですが、公開ディレクトリより上層に配置します。シェルで以下のコマンドを実行します。

;; 公開ディレクトリが/var/www/htmlなので
# htpasswd -b -c /var/www/.htpasswd ユーザー名 パスワード

「-b」オプションで、端末から入力したパスワードを利用出来るようです。ただし、コマンド入力時にパスワードが丸見えなので気をつけなさい!!みたいな事がmanに書いてありました。

「-c」オプションは新規ファイル生成(create)なので、認証ユーザーを追加したい場合には不要のようです。取りあえず上記のコマンドで、「hoge」ユーザーのパスワード「hogehoge」を作成してみました。

で、次に認証をかけたいディレクトリ下に.htaccessファイルを配置します。取りあえずローカル環境でのテストなので、公開ディレクトリ以下全てを認証制にしてみます。.htaccessの内容はこんな感じです。

AuthUserFile /var/www/.htpasswd
AuthName "Input ID and password"
AuthType Basic
require valid-user

ポイントは「.htpasswdのパスは絶対パスで記述する」という点でしょうか。AuthNameに記述した内容がダイアログに表示されます。

Basic認証は、認証情報がリクエスト毎に送信され、尚かつその情報が暗号化ではなくbase64による「符号化」でしかない為、実質平文のID・パスワードがネットワーク上に流れるのであまりセキュアな方法とは言えないようです。

Firebugでリクエストヘッダを見てみると、以下の情報が送信されています。

Authorization  Basic aG9nZTpob2dlaG9nZQ==

この文字列をPHPのbase64_decode()関数などに与えてみると…

$ php -a
php > echo base64_decode("aG9nZTpob2dlaG9nZQ==");
php > hoge:hogehoge

と、ユーザー名/パスワードがあっさり分かってしまいました。

そこで、次のDigest認証が推奨されています。

Digest認証

こちらの認証方法はBasic認証とほとんど同様のようですので、まずは照合用の.htdigestファイルを作成します。

# htdigest -c /var/www/.htdigest レルム ユーザー名
Adding password for hoge in realm Secret Area.
New password: [パスワード応答]
Re-type new password: [パスワード応答]

「レルム」というのは、.htaccessファイルに記述する「AuthName」と同一である必要があります。ここがBasic認証とは違いますね。

で、.htaccessは以下のようになります。

AuthType Digest
AuthName "Secret Area"
AuthDigestDomain /
AuthUserFile /var/www/.htdigest
require valid-user

「AuthType」が「Digest」になる点と、前述のように「AuthName」の意味合いが変わる事ぐらいでしょうか。

続いてこの場合のリクエストヘッダを見てみると、以下のような情報が送信されていました。

Authorization  Digest
username="hoge",
realm="Secret Area",
nonce="QlGMVhl2BAA=d7dd8bd6c5659d1efd515d79ed699ab1d694e99d",
uri="/",
algorithm=MD5,
response="afc54b31313e200977dcc5c0721d39bb",
qop=auth,
nc=00000006,
cnonce="303473c2c65228c6"

「algorithm=MD5」とありますので、認証情報が暗号化されて送信されているようです。この辺りが、Basic認証の代わりに推奨される理由でしょうか。

今日はここまで。

実のところは、C言語にケチョンケチョンに返り討ちをくらう毎日に若干凹んでしまい、色々な解説サイトをフラフラ彷徨っていたところ「Cで書くCGI」について言及されているサイトをまたもや発見。

コッソリとPythonやRubyのチュートリアルなぞ読んでみたりしている事もあり、ローカルに入れてるApacheで色々遊べるようにCGIが実行出来るように設定をしておこうと、まぁこういうワケです。

しかし、いつか本職の皆さんにドツかれそうな適当具合ですね(= ‘艸’)ﾑﾌﾟﾌﾟ

Ubuntu9.04の場合

UbuntuというかDebian系の場合は、以前も書いたように設定ファイルを細かく分散して管理しているようですね。RedHat系の設定ファイル構成に慣れているので、なかなか細かい所まで覚えきれません。

それっぽいファイル「apache2.conf」や「htttpd.conf」にゴリゴリ設定を追記していくべきではなさそう(httpd.confに至っては何も記述されていませんし)なので、今回もGoogle先生にお世話になりまくりです。

で、ローカルだし面倒だし「cgi-bin」ディレクトリ以外でもCGIが実行されるようにしたいな～、と以下のように設定してみました。

;; 念のためバックアップしておくのが無難(常識?)ですね
$ sudo vi /etc/apache2/sites-enabled/000-default

このファイルを見てみると、DocumentRootが「/var/www」である事と「cgi-bin」ディレクトリが「/usr/lib/cgi-bin/」エイリアスになっており、かつ「ExecCGI」の指定もあるので、ここに.cgiファイルを置けば面倒な設定をせずともアッサリ動かせそうですね。しかし、今回の目的上華麗にスルー!!

;; どこに置いても動くようにしたいので
<Directory /var/www/>
  Options Indexes FollowSymLinks MultiViews ExecCGI <- 追記
  AllowOverride All
  Order allow,deny
  allow from all
</Directory>

これで、

$ sudo apache2ctl configtest
$ sudo apache2ctl graceful

とApacheを再起動すればCGIが動くはず!!アレ??configtestやgracefulの時点で「apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1」と言われます(ﾟ_｡)?

調べてみたところ、設定ファイルで「ServerName」が指定されていないとこのメッセージが出る模様。なので、以下追記です。

;; ここで良いのでしょうかね??
$ sudo vi /etc/apache2/apache2.conf

(～中略～)
ServerRoot "/etc/apache2"
ServerName localhost <- 追記

さて、これでミーハーよろしく「/var/www/」下に「sandbox」なんてディレクトリを作ってみて、そこにこれまたミーハー気分で、C言語で作成したバイナリファイル(getenv.cgi)を置いてみました。

で、「http://localhost/sandbox/getenv.cgi」にアクセスすると…。アレアレ??ブラウザがファイルをダウンロードしようとします(･_･?)

単純に.cgiファイルがCGIとして認識されていないようですので、今度は以下のように。

;; ここにありました
$ sudo vi /etc/apache2/mods-enabled/mime.conf

AddHandler cgi-script .cgi <- コメントアウト(#)を削除

これで、再度Apacheを再起動して先ほどのURLにアクセスすると…。無事表示されました～。中身はUser AgentとIPアドレスを表示するだけのものですが…(*´σｰ｀)

公開サーバなどであれば、もっとセキュリティ面に配慮して設定すべきなのでしょうが、ローカルで閉じた環境のオレオレサーバなのでこれでOKかと。さて、Ubuntuが設定出来たらFedoraもやりたくなるのが心情というもの!!

Fedora 11の場合

FedoraやCentOSだと「/etc/httpd/conf/httpd.conf」に設定が集約されていますので、とにかくまずはこれを見れば良いですね。Ubuntuとの違いはDocumentRootが「/var/www/html」になるという点ぐらいでしょうか??

それ以外は、上記を参考にすれば書き留めておく程の事もなく終了してしまいました。

これで、PythonやRuby/Perlで遊べるぞ～!!ってC言語をやらんかい!!という話です。しかし、C言語は手強いですね～。「文字列」を扱うとすぐに混乱してしまいます。でも、その分ちゃんとコンパイルが通って動いた時の感激もひとしおなので頑張りますですよ～。

文脈からも分かるように、最近Pythonが気になって気になって仕方がなかったりもしますが…。

今日はここまでヾ(*’-'*)ﾏﾀﾈｰ♪

ミーハーは当然、ガッチリとクリーンインストールです!!

さて、Fedoraといえばyum、yumといえばRPM、RPMといえばdeb、debといえばUbuntu。強引極まりない結びつけですが、Linuxの2大巨頭(?)ともいえるRPMとdeb。どちらのパッケージ管理を利用しているかで、配布されているアプリケーションや、設定ファイルの配置なんかも変わってきますよね。

そこで、今回はwebサーバの定番「Apache」の設定ファイルや設定方法の違いを書き留めておこう!!というエントリです。で、題材にmod_rewriteモジュールをチョイスした、とこういうワケですね。

…いや、まぁね、ただ単にハマッただけなのですけどね(/ω＼)

ではいってみましょ～!!

RPM系(Fedora 10)の場合

まず、Apacheをインストールしなきゃ始まりませんので、yumでサクッと入れちゃいます。

;; 未だにsudoする癖がつきません
# yum install httpd

httpdの設定に関するファイルは、/etc/httpd下に入るみたいですので、チラッとのぞいてみましょう(/▽ﾟ＼)ﾁﾗｯ

;; 表示内容は若干端折ってます
$ ls -l /etc/httpd
drwxr-xr-x 2 root root 4096 conf
drwxr-xr-x 2 root root 4096 conf.d
lrwxrwxrwx 1 root root   19 logs -> ../../var/log/httpd
lrwxrwxrwx 1 root root   27 modules -> ../../usr/lib/httpd/modules
lrwxrwxrwx 1 root root   13 run -> ../../var/run

フムフム。FedoraやCentOSの場合、ここにあるconfディレクトリ下に設定ファイル「httpd.conf」が入ってるワケですね。設定ファイルの細かい記述については触れません(=必殺・放置)が、ではmod_rewriteを有効にするにはどうするのか??

取りあえず設定ファイル内をgrepしてみました。

;; 発見!!
$ grep mod_rewrite /etc/httpd/conf/httpd.conf
LoadModule rewrite_module modules/mod_rewrite.so

FedoraやCentOSのApacheは最初からmod_rewriteが有効になってるようですので、モジュールを利用するには、シンボリックリンクの貼られている/usr/lib/httpd/modules内にバイナリファイルが存在し、尚且つ、httpd.conf内に上記の「LoadModule ～」の1行が記述されていればOKなのだろう、と推測する事が出来ますね。

この「最初から有効」というのがハマった原因だったりもするのですが、次行ってみましょ～!!

deb系(Ubuntu 9.04)の場合

ハイ、これもまずはapt-getでサクッとインストールしちゃいます。

;; httpdではないのですね
$ sudo apt-get install apache2

RPMとはパッケージ名が違いますね。となると、設定ファイルはどこに入るのでしょうか??単純に考えると、/etc/apache2下ですね。

;; 表示内容はまたもや端折ります
$ ls -l /etc/apache2
-rw-r--r-- 1 root root apache2.conf
drwxr-xr-x 2 root root conf.d
-rw-r--r-- 1 root root envvars
-rw-r--r-- 1 root root httpd.conf
drwxr-xr-x 2 root root mods-available
drwxr-xr-x 2 root root mods-enabled
-rw-r--r-- 1 root root ports.conf
drwxr-xr-x 2 root root sites-available
drwxr-xr-x 2 root root sites-enabled

パッケージ名だけでなく、設定関連のファイル構成もだいぶ違う事が分かります。取りあえず、UbuntuでのApache設定ファイルはapache2.confになるようです。さて、じゃあmod_rewriteを有効化するにはどうするか??というと、以下の2つの手順を踏むようです。

1. a2enmodコマンドを管理者権限で実行する
2. (.htaccessを使うなら)設定ファイルの内容を変更する

まずは、a2enmodコマンドを早速実行してみます。mod_rewriteのプリフィックス「mod_」を除いたモジュール名が引数になるようですね。

;; 一般ユーザでやると怒られました
# sudo a2enmod rewrite
Enabling module rewrite.
Run '/etc/init.d/apache2 restart' to activate new configuration!

このコマンドを実行すると、/etc/apache2/mods-enabled下にrewrite.loadというシンボリックリンクが作成されました。で、このリンクの実体は../mods-available/rewrite.loadとなっていますので、実体の中を覗いてみました。

;; 発見!!
$ cat /etc/apache2/mods-available/rewrite.load
LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

おぉ～。ここでやっとFedoraにもあったモジュールロードの記述にたどり着きました。という事は、Ubuntuのようなdeb系Apacheのモジュールは、「LoadModule ～」が記述された実体ファイルへのシンボリックリンクを作成したり削除したり、という形で管理されていると考えて良いのですかね??

後は、mod_rewriteというのは.htaccessで利用する事が多いでしょうから、.htaccessを利用出来るように/etc/apache2/sites-available/defaultの以下を変更しました。

;; ココでいいのかな??
<Directory /var/www/>
　　Options Indexes FollowSymLinks MultiViews
　　AllowOverride None # -> AllowOverride Allへ
　　Order allow,deny
　　allow from all
</Directory>

う～ん、同じLinuxなのにここまで方法が違うのが、ディストリビューションの個性だな～と思うのですが、小っこい脳みそでは覚えるのが大変であります。

最後に、それぞれのApacheの制御コマンドを載せておきます。

;; RPM系なら
# service httpd start -> 起動
# service httpd stop -> 停止
# service httpd restart -> 再起動
# service httpd reload -> php.iniなんかの再読み込み
# service httpd status -> 動いてる??

;; deb系なら
$ sudo apache2ctl start -> 起動
$ sudo apache2ctl stop -> 停止
$ sudo apache2ctl restart -> 再起動
$ sudo apache2ctl status -> 動いてる??
$ sudo apache2ctl configtest -> 設定ファイルの文法チェック
$ sudo apache2ctl graceful -> 現在進行中の接続が終了してから再起動

覚えるのは大変ですが、やっぱりこういう多様性もLinuxならではですよね!!

今日はここまでヾ(*’-'*)ﾏﾀﾈｰ♪

ヤ、ヤバイ…telnet楽しいです(= ‘艸’)ﾑﾌﾟﾌﾟ

webアプリといえば、「言語の文法覚えたら次はセキュリティ!!」と言われるほど、脆弱性に気を使わなくてはイケナイ分野なのですよね??書籍やネットで知識を仕入れる事は出来ますが、何だか頭デッカチになってるだけのような気もします。やっぱり実体験に勝るものはないでしょうから、ここはいっちょうtelnetでよりリアルな通信を体験してみよう!!(＞▽＜)b

とまぁ、今回の動機はそんなところです。

さて、サーバデーモンとしてのtelnetは確かに廃れて久しいようですが、クライアントとしてのtelnetはまだまだ現役(のハズ)!!何たって、LinuxディストリビューションにもWindowsにもMacにも最初から用意されてますものね!?ちょっとした実験やら検証には持ってこいだと思います。

なので早速、実験!!実験!!…の前にまずは、telnetの使い方備忘録です。

<HTTPでhogehoge.comにアクセス>

$ telnet
telnet> open hogehoge.com 80
GET /path/to/file HTTP/1.1
Host:hogehoge.com
[空Enter]

<SMTPでmail.hogehoge.comにアクセス>

$ telnet
telnet> open mail.hogehoge.com 25
HELO 自分のホスト名
MAIL FROM: 送信者のメールアドレス
RCPT TO: 送信相手のメールアドレス
DATA
From: 送信者のメールアドレス
To: 送信相手のメールアドレス
Subject: 件名
ここに本文
.
↑ピリオドのみの行で終了
QUIT

<POPでmail.hogehoge.comにアクセス>

$ telnet
tenet> open mail.hogehoge.com 110
user ユーザ名
pass パスワード
LIST 受信メール一覧
RETR メッセージ番号 → メールを読む
DELL メッセージ番号 → メールを削除
QUIT

実験にはこの程度あれば十分ではないでしょうか??以下のサイトを参考にさせていただきました。他にもFTPやHTTPのProxyでの接続等、さらに詳しく紹介されています(人-)謝謝

Telnetで遊ぶ

簡単な使い方が分かった所で、会社のサイトやらGoogleやらYAHOOやらにアクセスして喜んでいたのですが、ちゃんと勉強もしなくちゃイケマセン。

で、取り敢えずwebアプリという事でlocalhostで動いてるapacheに色々アクセスしてみると、リクエストは空Enterのみの行で初めて完結するようですね。また、レスポンスもヘッダとボディの間に空Enterのみの行がある事が分かりました。

$ telnet
telnet> open localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host:localhost
　←ここでリクエストが終了!!
HTTP/1.1 200 OK
Date: Thu, 12 Mar 2009 15:27:33 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8g PHP/5.2.8
Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT
ETag: "dc83f-2c-3e9564c23b600"
Accept-Ranges: bytes
Content-Length: 44
Content-Type: text/html
　←ここでレスポンスヘッダ終了!!
<html><body><h1>It works!</h1></body></html>

空Enterのみの行という事は、最後の文字のお尻に改行コードが2つ連続でくっついてるという事ですよね??これを利用して意図的にレスポンスヘッダを分割させるのが、いわゆる「レスポンスヘッダ分割攻撃」というやつですよね??対策としては(ヘッダだろうがボディだろうが)「ユーザの入力値をそのまま出力しない」のが鉄則ですよね。φ(・ω・ )

さらにもう1つ、単純にvar_dumpでスーパーグローバル変数$_SERVERをダンプするPHPファイルを作り、それにアクセスしてみました。

<telnet.php>

<?php
/* ワザワザ書くほどでもないですネ */
var_dump($_SERVER);
?>

ブラウザでアクセスしているワケではないですから、当然ユーザエージェントやリファラは変数に格納されていません。さて、そこでいわゆるUAやリファラの「偽装」を試してみるとどうなるのかな??と実験してみました。

$ telnet
telnet> open hogehoge.com 80
GET /path/to/file HTTP/1.1
Host:hogehoge.com
User-Agent: hogehoge
Referer: fugafuga

HTTP/1.1 200 OK
Date: Thu, 12 Mar 2009 15:49:20 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8g PHP/5.2.8
X-Powered-By: PHP/5.2.8
Content-Length: 1152
Content-Type: text/html

array(24) {
  ["HTTP_HOST"]=>
  string(9) "localhost"
  ["HTTP_USER_AGENT"]=>
  string(8) "hogehoge" ←アイヤ〜!!
  ["HTTP_REFERER"]=>
  string(8) "fugafura" ←偽装されちゃった!!

  〜以下略〜

}

おぉ、見事に本来期待する形式ではない値が入ってますね。故に、この値を信用して処理ロジックを組むのはよろしくない、という事なのでしょう。φ(・ω・ )

他にもPOSTとか試してみたのですが、長くなってしまったのでこの辺りで終了しておこうと思います。しかし、こうしてより「生」に近い処理を体験してみると、頭の中でボンヤリとしていた知識が実際に身についたような気がします。昨日より一歩前進出来たかな(・x・ ).o0○

GUI主流のご時世にtelnet叩いてワァワァ喜んでる時点で後退かもしれませんが…。

今日はここまでヾ(*’-'*)ﾏﾀﾈｰ♪

ダウンロードはコチラ

で、ダウンロードしたtarballを適当なディレクトリで展開いたしました。

$ tar zxvf httpd-2.2.11.tar.gz

次は./configure。色々なサイトを参考にさせていただいて、コンパイルオプションはこんな感じにしました。

$ ./configure \
> --enable-so \
> --enable-rewrite \
> --enable-ssl \

–enable-so

Apacheのモジュールを動的に組み込むのに必須のオプションだそうです。何はなくとも付けときましょう、という感じでしょうか??

–enable-rewrite

mod_rewriteの有効化ですね。CodeIgniterでは、URLからindex.phpを除去する為にrewrite機能を利用していますので必須としてみました。

–enable-ssl

SSLを有効にするオプションみたいですね。検証用ローカル環境には必要無さそうですが、取り敢えず付けてみました。ただし、SSLのパッケージがあらかじめ入ってないと「コンパイル出来るかボケェ!!」と怒られましたので、aptでopensslとlibssl-devを入れました。

これで後は、

$ make
$ sudo make install

でインストール完了!!apacheを起動するには

$ sudo /usr/local/apache2/bin/apachectl start

として、http://localhostにアクセスすると・・・

It works !!

やった!!取り敢えず動きました(≧∇≦)b

ubuntuのnautilusファイルブラウザは、FTP接続なんかも出来ちゃってチョ〜便利。なので、ちょっとしたファイルの書き換えをしたい時などによく利用しているのですが、何故かnautilusのメニューからFTP接続しているにも関わらず、Firefox君がその役目を華麗にインターセプトしてくれます。

何か設定イジったかな〜?などと考えつつGoogle先生にお伺いを立ててみると、同じ境遇の方がいらっしゃいました。

Nautilus FTP instead of Firefox/Swiftfox

単純に、デフォルトのFTPアプリケーションがFirefoxになってしまっているだけのようです。なので、Alt+F2でgconf-editorと入力したら、desktop→gnome→url-handlers→ftpを選択。我が家の環境では、command欄が「/usr/bin/firefox swiftfox “%s”」となっていましたので、これを「nautilus “%s”」に変更。その後再度FTP接続してみると・・・

nautilusが起動しましたヾ(＠＾▽＾＠)ﾉ ワーイ

今までの投稿では、ソースコードは全て「blockquote」でマークアップするという暴挙に出ていたｵﾗｧ(pﾟﾛﾟ)==p)`д)ｸﾞﾊｯので、いくら何でもこれはマズかろう、と…。

色々なブログを見ていると<pre></pre>などが利用されているようです。そこで、同じように<pre></pre>でマークアップしてみましたが、このテーマではCSSが指定されていないようなのでどうにも味気ない。

CSSあんまりよく分からないし面倒だし、WordPressならプラグインなどあるのではなかろうか?と探してみたら、やっぱりありました〜Ｏ(≧▽≦)ＯさすがWordPress。

利用させていただいたのは、「SyntaxHighlighter Plus」。使い方はとっても簡単で、ダウンロードしたプラグインを解凍したらフォルダごと/wp-content/plugins/にアップロード。管理画面からプラグインを有効化したら、それで準備はオッケーです。

でもって、ハイライトさせたい箇所を

[sourcecode language='言語名'] [/sourcecode]

で囲むだけ。実際にやってみるとこんな感じになりました。

<?php
class Hoge extends Controller
{
    public function __construct()
    {
        parent::Controller();
    }

    public function index()
    {
         echo 'CodeIgniter is cool framework!!';
    }
}
/**
* End of file hoge.php
*/

Javasvriptを利用しているので、無効にされていると綺麗にハイライト出来ないようですから、オフでご覧になっている方は一度オンにしてみて下さい。

このプラグイン、PHPは勿論多言語に対応しているみたいです。参考にさせていただいたこちらのブログで詳しく解説されています。

【WP】ソースコードをシンタックスハイライトする”SyntaxHighlighter Plus

さて、週末にちょこっと触ってみたCodeigniter1.7ですが、フォームのバリデーション周りがかなり便利になった印象です。詳しくは次回にでも…。

今日はここまで･△･)ﾉ ﾊﾞｲﾊﾞｲ

Apacheで設定するドキュメントルート。このディレクトリ以下に設置されたファイルやディレクトリは、基本的にwwwからアクセス出来てしまうので、セキュリティを高める意味でもアクセスされたくない(中身を覗かれたくない)ディレクトリは、ドキュメントルートより上の階層に設置するのが良いそうです。

Aliasというディレクティブを利用して実現できるそうです(Apacheのモジュールでmod_aliasが必要との事)。

Alias　[ドメイン以下のパス]　[実際にアクセスさせるパス]

という事は、例えばhttp:hoge.comなどというURLがありまして、そのドメイン以下にあるhttp://hoge.com/fugaというコンテンツをAliasさせたい場合、ドキュメントルートが/var/www/htmlだとすると、設定ファイルに記述する内容は

Alias　/fuga　/var/www/fuga

という感じですかね?

早速実験実験と、「されどLAMPな日々」をドキュメントルート外に設置してAliasしてみると…。

見事表示されましたＯ(≧▽≦)Ｏ

ディレクトリ・ファイルのパーミッションには注意しないとダメみたいです〜。あとは、同じ処理のAliasMatchというディレクティブもあるそうで、こちらはパス名に正規表現が使えるそうです。Apache便利だな〜。

最近CIが触れてないです。そろそろちゃんと1.7をチェックしたいです。

今日はここまで･△･)ﾉ ﾊﾞｲﾊﾞｲ