AWS上のWebサーバのアクセスログをawstatsで解析する

AWS(EC2)上のWebサーバのアクセスログをawstatsで解析するための手順に関して説明します。
但し、awstatsはEC2上ではなく、LAN内にあるLinux上にインストールするものとします。
はじめに
現状、Webサーバのアクセス解析にはGoogle Analyticsを利用されている方が多いと思います。
もちろん弊社でも利用しているのですが、Google Analytics はJavaScriptを利用して計測を行っているため、生のアクセスログを解析したものとは違った結果が現れます。
Google Analytics での解析でも十分な解析が行えますが、私は以下の点から awstats 等のアクセスログ解析ツールも併用する事が多いです。
- ボットやクローラー等のアクセスを知る
Google AnalyticsはJavaScriptを利用した計測であるため、この手のクライアントのアクセスを判別できない場合が多い - RSSリーダー等のアクセスを知る
RSSフィードへのアクセスもボット等と同様に計測できない場合が多い - セキュリティ上
HTTPサーバへのアクセスログを解析する事で、ソフトウェアの脆弱性を突いたアクセスを試みている形跡なども発見できます ( phpMyAdminの脆弱性を狙ったリクエストは弊社Webサイトにもたくさん飛んでくる )。
アクセスログの解析を行う事によって、これら問題に気づく→対処するという事もあります ( 実際これまでにあった )。
Google Analytics しか利用した事がないという場合、一度利用してみてはいかがでしょうか。
環境・構成
アクセスログを解析するために、今回利用するのは awstats です。
オープンソースのログ解析ツールの中でも最も有名なもののひとつです。
HTTPサーバのアクセスログ解析だけでなくメールサーバのログ解析等にも利用できます。
コンピュータの構成図は以下のようになります。
awstats を導入する場合、ログ解析を行う対象のサーバにインストールする形で説明がなされる事が多いような気がしますが、今回はその構成は取りません。
Webサイトが構築されているEC2インスタンスとは異なる (LAN上の) 別サーバにawstatsをインストールし、ApacheのアクセスログはEC2からこのサーバにrsyncで転送します。
この構成をとる理由は、以下になります。
- パフォーマンスを考慮
awstatsはログ解析や解析結果の表示を行うにあたって、それなりのパフォーマンスを要求します。Webサイトのパフォーマンスに影響を与える可能性もあるため、別サーバで動作させる方が望ましいという考えです。 - セキュリティリスクを上げない
サーバ上で動作するアプリケーションを増やす事はセキュリティリスクが増加する事に繋がります。
awstatsもこれまでにWebサーバのユーザ権限を奪取される可能性のある脆弱性が見つかった事があります。
今後も同様の事が発生する可能性も考えられるため、別サーバで運用する方が望ましいでしょう。
そもそも awstats の解析結果はサイト管理者、及び、関係者だけが見れればよいため、公開されたサーバ上に置く必要はない場合が殆どです。
利用OS、ソフトウェアは以下を想定しています。
OS (EC2) | Amazon Linux (64bit) |
---|---|
OS (LAN) | CentOS 6.5 (64bit) |
ログ解析ソフトウェア | awstats-7.1-1.el6 |
設定
上記構成における設定手順を以下に示します。
EC2上の apache の ログは /var/log/httpd に格納されています。
これを awstats を動作させるサーバの /var/log/aws ディレクトリに転送し、awstasで解析するものとします。
ディレクトリ構成等は利用している環境等で適宜変更して下さい。
awstats のインストール
awstats は yum を利用してインストールする事にします。
rpmforge リポジトリのインストール
awstats は CentOS のデフォルトの yum リポジトリには含まれていないので、rpmforge から取得/インストールを行います。
- http://pkgs.repoforge.org/rpmforge-release/ からプラットフォームに適合するrpm を取得します ( 弊社環境の場合 x86_64 版の最新の rpm を取得 )。
$ wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
- 取得した rpm ファイルを利用して rpmforge リポジトリをインストールします。
$ sudo rpm -ivh rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
awstats のインストール
yum でインストールします。
$ sudo yum install awstats
awstas の設定
apache 設定
awstats をインストールすると、apache用設定ファイルが /etc/httpd/conf.d/awstats.conf として作成されます。
このファイルを編集します。
-
$ sudo vi /etc/httpd/conf.d/awstats.conf
初期状態ではローカルホストからのアクセスしか許可されていないため、運用方式に併せて適宜、設定を変更します。
弊社の場合社内LANからはアクセス可能とさせるため、以下のように変更してあります。allow from 127.0.0.1 allow from 192.168.1.0/24 # 許可するサブネットを追加
- 設定を確認し問題なければ apache をリロードします。
$ httpd -t Syntax OK $ sudo /etc/rc.d/init.d/httpd reload
- Webブラウザから以下URLでアクセスしてawstats の動作を確認してみます。
http://awstatsをインストールしたホスト名/awstats/awstats.pl
この状態では awstats 自体の設定を行っていないため、以下エラーが表示されます。Error: Couldn't open config file "awstats.ホスト名.conf" nor "awstats.conf". Please read the documentation for directories where the configuration file should be located.エラーは表示されますが、これにより apache 用設定は機能している事が確認できます。
awstatsの設定
awstats の設定ファイルは /etc/awstats 以下に格納されます。
サンプルの設定ファイルがインストールされるので、これをコピー/編集して設定を行います。
- awstats.model.conf をコピーします。
$ cd /etc/awstats/ $ sudo cp awstats.model.conf awstats.conf
- 設定ファイルを編集します。
$ sudo vi awstats.conf
以下内容で設定します (抜粋)。#LogFile="/var/log/httpd/access_log" LogFile="/var/log/aws/access_log" # 解析対象のログファイルを指定します #SiteDomain="localhost.localdomain" SiteDomain="www.agilegroup.co.jp" # サイトのドメイン名を設定します #HostAliases="localhost 127.0.0.1" HostAliases="agilegroup.co.jp XXX.XXX.XXX.XXX" # 別のドメイン名でアクセス可能な場合に、その名前を指定します #DNSLookup=2 DNSLookup=1 # アクセス元の名前解決を行う場合1に #SkipHosts="127.0.0.1 SkipHosts="127.0.0.1 XXX.XXX.XXX.XXX" # 社内からのアクセスを除外したい場合等にはそのIP(XXX部分)を追記します。 # プラグインに関しては必要に応じて有効にします # GeoIPfree プラグインは利用される事が多いようです。 # 弊社ではGoogleのチャートAPIをグラフ表示に利用するためのプラグインも有効にしています。 LoadPlugin="geoipfree" LoadPlugin="graphgooglechartapi"
- GeoIPfreeを利用する場合、以下の追加インストールが必要になります。
$ sudo yum install perl-Geo-IPfree
上記LogFile設定の場合、最新のアクセスログのみが解析対象になります。
サイト構築と同時期にawstats を導入した場合はこれでOKですが、既に過去の(ローテートされた)アクセスログファイルが存在する場合、上記設定ではこれらファイルを解析してくれません。
こういう要件に対応する場合には 設定ファイルにもコメントがありますが、logresolvemerge.pl スクリプトを利用できます。
LogFile="/usr/bin/logresolvemerge.pl /var/log/aws/*access_log* |"
ログ取得スクリプトの作成
上記でawstats の設定に関しては完了しましたが、この状態では解析対象のログファイルが存在しません。
AWS(EC2)からログファイルを取得するためのスクリプトを記述し、cronで定期的にログを取得するようにします。
yum で awstats をインストールした場合、awstats のログ解析は /etc/cron.hourly 以下にインストールされる 00awstats スクリプトで実行されるようになります。
毎時ログ解析が実行される事になるので、EC2からのログ取得スクリプトも cron.hourly 以下に置くことにします。
( /etc/cron.hourly 以下に aws-httpdlog-backup.sh という名前で作成する )
rsync のインストール
ログの取得は構成図にも書いたように rsync を利用して行うものとします。
rsync がインストールされているか確認し、インストールされていなければ、インストールします。
$ sudo which rsync
which: no rsync in (/sbin:/bin:/usr/sbin:/usr/bin) <= インストールされていない
$ sudo yum install rsync
証明書ファイルの準備
Amazon Linux へ ssh 接続を行うためには証明書 ( pem ファイル ) が必要になります。ログ取得を行うサーバ上の適当なディレクトリにキーペアファイルを導入し、root以外が読めないように適宜パーミッションを設定しておいてください。
※以下スクリプトは /root/key/keypairfile.pem として保存した場合の例になります。
スクリプトの作成
-
ログ取得用スクリプトを作成します。
$ sudo vi /etc/cron.hourly/aws-httpdlog-backup.sh
以下内容で作成します。
※SSHのポートはデフォルトポートを想定しています。
EC2インスタンス(Amazon Linux)の初期設定 のようにSSHのポート番号を変更している場合、"-p ポート番号" オプションを ssh コマンドの後に追記します。#!/bin/bash EC2ADDRESS=取得先(EC2)のホスト名、または、IPアドレスを指定 HTTPDLOG_DIR=/var/log/httpd/ BKUP_DIR=/var/log/aws # rsync ec2 to local rsync -avrz --delete -e 'ssh -i /root/key/keypairfile.pem' ec2-user@$EC2ADDRESS:$HTTPDLOG_DIR $BKUP_DIR 1> /dev/null
- 実行権限を追加します。
$ sudo chmod +x /etc/cron.hourly/aws-httpdlog-backup.sh
- 実行してみます。
$ sudo /etc/cron.hourly/aws-httpdlog-backup.sh
初回実行時にはSSH接続するかどうか確認されるので yes を返答します。
Are you sure you want to continue connecting (yes/no)? yes
ただし、この状態で実行するとエラーになります。ec2-userに/var/log/httpdの読み取り権限がないためです。
EC2のパーミッション設定
上記 ec2-user が /var/log/httpd へのアクセス権がない問題を解消するために、パーミッションを変更します。
$ sudo chmod 0605 /var/log/httpd
上記設定前は、ec2-user で /var/log/httpd ディレクトリを参照するとエラーになっていたのが、ログを参照できるようになります。
ログ取得スクリプトの実行
awstats がインストールされたホストからスクリプトを再実行します。
$ sudo /etc/cron.hourly/aws-httpdlog-backup.sh
無事 /var/log/aws 上にログが取得されればOKです。
後は毎時 スクリプトが実行されます。
awstats によるログ解析
ログが取得できたら、awstats によるログ解析処理を行います。
ログ解析も毎時行われますが、すぐに解析をおこないたい場合、以下を実行します。
$ sudo /etc/cron.hourly/00awstats
ログの量にもよりますが、初回の解析にはある程度時間がかかります。
解析が完了しプロンプトに戻ってきたら、Webブラウザから awstats のURLにアクセスします。
http://awstatsをインストールしたホスト名/awstats/awstats.pl解析が無事行われていれば、結果が表示されます。

GraphGoogleChartAPI を有効にしている場合、デフォルトのawstatsのグラフ表示とは異なる表示がなされます。
国別アクセス表示部には地図が表示されたりします。

どのような種類のロボットやスパイダーが、どの程度アクセスしているかも確認できます。

HTTPエラーコード の 404 ページからは404 エラーになったURLの一覧を見る事ができます。
このページからはURL構成が変更になったために、実際にエラーになっているURLを確認できますが、これ以外に
- favicon.ico や robots.txt 等 WebブラウザやクローラーがアクセスするURLへのファイルの設置漏れ
下の実際の解析結果画像では、サイト移行当初に robots.txt を直ぐに設置しなかったために robots.txt で404エラーが多発した事が確認できます ( 現在は設置済み )。 - アプリケーションの脆弱性を狙ったアクセス
アクセスログを解析してみると、これがすごい多いことが確認できると思います。
下画像でも phpMyAdmin の脆弱性を狙ったアクセスがかなりある事が判ります。
他には少なくとも以下のアプリケーションへの攻撃が確認できました。
- Joomla ( 及び、Joomlaプラグイン )
- Wordpress
- ColdFusion
- SQLiteManager
- SQlite

まとめ
上述したように、アクセスログ解析ツールを導入、利用する事で、Google Analytics を利用した場合とは異なる切り口でアクセス解析をおこなう事が可能になります。
特にセキュリティ面では、不正アクセスが行われている事を確認する事で、なんらかの対策を行うきっかけになる場合もあるでしょう ( 企業サイトの場合、実際の不正アクセスの痕跡を見せる事で経営陣や、phpMyAdminの利用者 :-p への説明が行いやすいといった事もあるかもしれません )。
- Webサイト上に phpMyAdmin が導入されたままならば、アンインストールする
→ インストール時に使っただけじゃない?
必要なら、SSH接続してコマンド叩こう。 - WAF (Web Application irewall) を導入する ( あるいは導入を検討する )
→ ModSecurity っていうのがあるよ。
※WAFに関してはIPAが 読本を公開 してくれているので、セキュリティに関わる/興味がある方なら一読してみるのもいいかもしれません。
といった取り組みにつながり、よりセキュアなWebサイトを実現するきっかけになれば、ログ解析ツールを導入した価値もあると言えるのではないかと思います。
とりあえず、まだ利用した事がないというのであれば、一度使ってみては?