AmazonLinuxでfluentdを使ってApacheログをDynamoDBとmongoDBへ転送する

両者を比較する機会があり、ApacheのログをDynamoDBとMondgoDBに転送してみました。

 

DynamoDBへの転送

fluentdのインストール

転送手段はfluentdでと思ったら、http://docs.fluentd.org/articles/install-by-rpmに、

Currently, Amazon Linux is NOT supported.

とあり、使えないっぽいことがわかりました。。
でもRPMを自作するか、トレジャーデータのリポジトリからrpmを落としてくるかすればよいようです。自作なんてしたくないのでrpmを落としてきます。

https://shrub.appspot.com/packages.treasuredata.com/2/redhat/6/x86_64/

では、現時点での最新版はtd-agent-2.1.4-0.x86_64.rpmでした。

# rpm -ihv http://packages.treasuredata.com.s3.amazonaws.com/2/redhat/6/x86_64/td-agent-2.1.4-0.x86_64.rpm
http://packages.treasuredata.com.s3.amazonaws.com/2/redhat/6/x86_64/td-agent-2.1.4-0.x86_64.rpm を取得中
警告: /var/tmp/rpm-tmp.HadUid: ヘッダー V4 DSA/SHA1 Signature、鍵 ID a12e206f: NOKEY
準備しています... ################################# [100%]
更新中 / インストール中...
 1:td-agent-2.1.4-0 ################################# [100%]
adding 'td-agent' group...
adding 'td-agent' user...
Installing default conffile...
Configure td-agent to start, when booting up the OS...

という感じで何事も無くインストール出来ました。

 

DynamoDBのテーブル作成

続いてDynamoDBのテーブルを作ります。
Primary Key TypeはHash、Hash Attribute Nameはidにします。

CreateTable

あとはとりあえずSNS通知を外す以外はデフォルトで進めます。

 

 

fluent-plugin-dynamodbの設定

Apacheのログ転送にはfluent-plugin-dynamodbを使います。

# td-agent-gem install fluent-plugin-dynamodb
Fetching: fluent-plugin-dynamodb-0.1.11.gem (100%)
Successfully installed fluent-plugin-dynamodb-0.1.11
Parsing documentation for fluent-plugin-dynamodb-0.1.11
Installing ri documentation for fluent-plugin-dynamodb-0.1.11
Done installing documentation for fluent-plugin-dynamodb after 0 seconds
1 gem installed

/etc/td-agent/td-agent.confに以下のように設定を入れます。

<source>
type tail
format apache
path /var/log/httpd/access_log
tag httpd.dynamodb
pos_file /var/log/td-agent/httpd.pos
</source>

<match httpd.dynamodb.**>
type dynamodb
aws_key_id 【アクセスキー】
aws_sec_key 【シークレットキー】
dynamo_db_endpoint dynamodb.ap-northeast-1.amazonaws.com
dynamo_db_table apachelog
</match>

このままだと

# ls -la /var/log/ | grep httpd
drwx------ 2 root root 4096 2月 10 21:07 httpd

で、td-agentユーザがapacheのログを読めないので、

chmod 755 /var/log/httpd

しておきます。
これで適当にApacheにアクセスすると、

dynamoapachelog

 

のようにログが転送されることが確認できました。

 

 

MongoDBへの転送

MongoDBのインストール

とりあえずApacheと同じサーバにMongoDBを同居させてしまいます。
まず以下の内容で/etc/yum.repos.d/mongodb.repoを作成します。

[mongodb]
name=MongoDB repo
baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/
gpgcheck=0
enabled=1

MongoDBをインストールして起動します。

# yum install mongodb-org
# service mongod start

 

MongoDBへの転送設定

fluent-plugin-mongoは最初から入っていますので、/etc/td-agent/td-agent.confを以下のように設定変更します。

<source>
type tail
format apache
path /var/log/httpd/access_log
tag httpd.mongodb
pos_file /var/log/td-agent/httpd.pos
</source>

<match httpd.mongodb.**>
type mongo
host localhost
port 27017
database apachetomongo
collection apachelog
capped
capped_size 1024m
flush_interval 10s
</match>

td-agentをrestartします。

# service td-agent restart

これでMongoDBへのログ転送が始まります。

# mongo
MongoDB shell version: 2.6.7
connecting to: test
2015-02-22T02:22:57.448+0900 [initandlisten] connection accepted from 127.0.0.1:43711 #15 (3 connections now open)
> show dbs
admin (empty)
apachetomongo 2.077GB
local 0.078GB
test (empty)
> use apachetomongo
switched to db apachetomongo
> show collections
apachelog
system.indexes
> db.apachelog.count()
22
> db.apachelog.find().limit(10)
{ "_id" : ObjectId("54e8bef2beddad20c9000001"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "403", "size" : "3839", "referer" : "-", "agent" : "curl/7.40.0", "time" : ISODate("2015-02-21T17:22:47Z") }
{ "_id" : ObjectId("54e8bef2beddad20c9000002"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "403", "size" : "3839", "referer" : "-", "agent" : "curl/7.40.0", "time" : ISODate("2015-02-21T17:22:48Z") }
{ "_id" : ObjectId("54e8bef2beddad20c9000003"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "403", "size" : "3839", "referer" : "-", "agent" : "curl/7.40.0", "time" : ISODate("2015-02-21T17:22:48Z") }
{ "_id" : ObjectId("54e8bef2beddad20c9000004"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "403", "size" : "3839", "referer" : "-", "agent" : "curl/7.40.0", "time" : ISODate("2015-02-21T17:22:48Z") }
{ "_id" : ObjectId("54e8bef2beddad20c9000005"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "403", "size" : "3839", "referer" : "-", "agent" : "curl/7.40.0", "time" : ISODate("2015-02-21T17:22:49Z") }
{ "_id" : ObjectId("54e8bef2beddad20c9000006"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "403", "size" : "3839", "referer" : "-", "agent" : "curl/7.40.0", "time" : ISODate("2015-02-21T17:22:49Z") }
{ "_id" : ObjectId("54e8bef2beddad20c9000007"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "403", "size" : "3839", "referer" : "-", "agent" : "curl/7.40.0", "time" : ISODate("2015-02-21T17:22:50Z") }
{ "_id" : ObjectId("54e8bef2beddad20c9000008"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "403", "size" : "3839", "referer" : "-", "agent" : "curl/7.40.0", "time" : ISODate("2015-02-21T17:22:50Z") }
{ "_id" : ObjectId("54e8bef2beddad20c9000009"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "403", "size" : "3839", "referer" : "-", "agent" : "curl/7.40.0", "time" : ISODate("2015-02-21T17:22:51Z") }
{ "_id" : ObjectId("54e8bef2beddad20c900000a"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "403", "size" : "3839", "referer" : "-", "agent" : "curl/7.40.0", "time" : ISODate("2015-02-21T17:22:51Z") }

 

 

AmazonLinuxでclamavを使う

しらないうちにAmazonLinuxの標準リポジトリにclamavが追加されていたので使ってみました。

 

インストール

# yum install clamav clamav-update clamav-scanner-sysvinit

パッケージ名とかがrpmforgeのものと結構違います。。

clamav…スキャンを実行したりするフロントエンドです。
clamav-update…定義ファイルをアップデートするプログラムです(freshclam)。
clamav-scanner-sysvinit…clamdのinitスクリプトです。

 

 

ウィルス定義ファイルのアップデート設定

/etc/freshclam.confを以下のように編集します。

# Comment or remove the line below.
Example
↓コメントアウト
# Comment or remove the line below.
#Example


#DatabaseDirectory /var/lib/clamav
↓コメント解除
DatabaseDirectory /var/lib/clamav


#UpdateLogFile /var/log/freshclam.log
↓コメント解除
UpdateLogFile /var/log/freshclam.log

#DatabaseOwner clamupdate
↓コメント解除
DatabaseOwner clamupdate


#DatabaseMirror db.XY.clamav.net
DatabaseMirror db.jp.clamav.net
※db.jp.clamav.netの行を追記。

これで

# freshclam

で定義ファイルのアップデートが出来るようになりますので、cronなどで定期実行させます。

 

clamdデーモンの起動設定

/etc/clamd.d/scan.confを以下のように編集します。

# Comment or remove the line below.
Example
↓コメントアウト
# Comment or remove the line below.
#Example

#LocalSocket /var/run/clamd.scan/clamd.sock
↓コメント解除
LocalSocket /var/run/clamd.scan/clamd.sock

これでclamdのデーモンが起動できます。

# service clamd.scan start
# chkconfig clamd.scan on

…が、このままだと

# clamdscan ./
ERROR: Can't parse clamd configuration file /etc/clamd.conf

などと出てscanできませんでした。
clamdscanがclamdの設定ファイルが/etc/clamd.confにあることを期待しているみたいですので、以下のようにシンボリックリンクを張って回避します。

# ln -s /etc/clamd.d/scan.conf /etc/clamd.conf

これでいけるとおもいきや、

# clamdscan /root
/root: lstat() failed: Permission denied. ERROR

----------- SCAN SUMMARY -----------
Infected files: 0
Total errors: 1
Time: 0.000 sec (0 m 0 s)

のように、/rootの下は検索ができませんでした。。
clamdはclamscanというユーザで実行されるので、rootで実行させる必要があるみたいです。

/etc/clamd.d/scan.confで

#User clamscan
User root

してclamd.scanをrestartしました。これで/root配下でもどこでもスキャンできるようになります。
よくない感じもしますが。。

 

 

 

AmazonLinuxでcron実行時間が9時間ずれる

いつもuserdata

\cp -f /usr/share/zoneinfo/Japan /etc/localtime

sed -i -e "s/ZONE=.*$/ZONE=\"Asia\/Tokyo\"/" /etc/sysconfig/clock
sed -i -e "s/UTC=.*$/UTC=false/" /etc/sysconfig/clock
echo 'ARC=false' >> /etc/sysconfig/clock

みたいにしてタイムゾーンを直しているのですが、cronをAM2:00に仕掛けたところ、AM11:00に動く(9時間遅れる)という現象が発生しました。

タイムゾーンを変更した場合は、

service crond restart

してcrondを再起動しないとcrondは変更に気づかず時刻がずれたままcronを実行してしまいます。

crondはrsyslogと違って、logrotateのタイミングで再起動したりしないので、忘れると気づかないままになったりしますので注意が必要です。

 

 

 

AmazonLinuxで/var/log/messagesでホスト名が反映されない

AmazonLinux関係無いですが。。

hostnameを変更した後は、

service rsyslog restart

しないと、
/var/log/messagesで

Jan 15 12:07:01 ip-10-0-0-xx ******************
...

みたいな感じで、PrivateIPに紐づくデフォルトのホスト名のままになってしまいます。
logrotateのタイミングで自然に治るので気づかないままになりがちです。。

 

 

Windows Server 2012のIISでのSSL証明書の更新手順

普段Windowsを触る機会が無く年一のSSL証明書更新のたびにやり方を必ず忘れているのでメモ。

 

PFX形式の証明書の作成

IISにインストールするSSL証明書はPFX形式の証明書である必要があります。
事業者からSSL証明書を購入するとPEM形式で届いてしまうので、PFX形式に変換します。
変換コマンドは以下です。

openssl pkcs12 -export -in 【PEM形式の証明書】 -inkey 【秘密鍵】 -certfile 【CA証明書】 -out 【出力したいPFX形式の証明書】

Exportパスワードというものを求められます。これはIISにPFX証明書をインストールする際に必要です。任意のものを入れておきます。

 

IISマネージャからPFX形式の証明書をインストール

IISマネージャを起動します。

WindowsServer2012_IIS_SSL_update_01

 

左上のホーム?を選んで、「IIS」の下の「サーバ証明書」を選択します。

WindowsServer2012_IIS_SSL_update_02

 

インストール済みのSSL証明書の一覧が表示されます。
「インポート」をクリックします。

WindowsServer2012_IIS_SSL_update_03

 

証明書のインポートダイアログが表示されます。

WindowsServer2012_IIS_SSL_update_04

 

「参照」ボタンを押してPFX形式の証明書を指定し、最初のPFXへの変換時に入れたパスワードを入力します。
「証明書ストアの選択」は、「個人」のままで構いません。
エクスポートの許可はとりあえずチェックしたままにしておきます。
「OK」ボタンを押します。

WindowsServer2012_IIS_SSL_update_05

 

これでインストール済みのSSL証明書の一覧に追加されました。

WindowsServer2012_IIS_SSL_update_06

 

画面左の「サイト」の下の更新したいサイトを右クリックして「バインドの編集」を選択します。

WindowsServer2012_IIS_SSL_update_07

 

サイトバインド画面になるので、既存のエントリを選択し「編集」ボタンを押します。

WindowsServer2012_IIS_SSL_update_08

 

サイトバインドの編集画面が表示されます。
「SSL証明書」のプルダウンから、先ほど新たに追加した証明書を選択します。
古い証明書と名前が一緒で区別がつきにくいですが、プルダウンから選択後「表示」ボタンを押すと証明書の中身を見ることができるので、証明書の期限などで判別します。
「OK」ボタンを押します。

WindowsServer2012_IIS_SSL_update_09

 

これで完了です。
「OK」ボタンを押すと即反映されるようです。

 

 

 

 

 

 

AmazonLinuxでTripwireを使ってみる

Tripwireはファイル・ディレクトリの改ざんを検知するためのソフトウェアです。
改ざんを検知したいファイル・ディレクトリの情報をベースラインとして取得して、定期的にベースラインからの変更が無いかを確認することで、改ざんを検知します。

今回はAmazonLinuxでTripwireを使ってみました。

 

 

インストール

AmazonLinuxの標準リポジトリにはTripwireはありませんので、epelリポジトリからインストールします。

# yum install --enablerepo=epel tripwire

epel.repoファイルではenabled=0で無効にされているので、–enablerepo=epelで一時的に有効化します。

 

設定ファイル

Tripwireでは設定ファイルが2種類あります。

tw.cfg
…全体の設定ファイル
tw.pol
…どのファイル・ディレクトリを監視するかという設定を定義するファイル

Tripwireでは、これらの設定ファイルを暗号化して使用するため、viなどで開いても読めず編集することができません。
これは、Tripwireを仕込んだサーバが既に侵入されている場合、設定ファイル自体をいじられて、改ざん検知を無効にされてしまうおそれがあるためです。
そのため、設定ファイルを編集したい場合は、一旦平文で設定を記述したテンポラリ的な設定ファイルを作成し、これを暗号化してあげる必要があります。

設定用の平文設定ファイルのひな形は、Tripwireをインストールすると、twcfg.txt、twpol.txtというファイルとして、最初から用意されています。

 

tw.cfgの編集

平文のひながた設定ファイルを編集します。

# vi /etc/tripwire/twcfg.txt

ROOT =/usr/sbin
POLFILE =/etc/tripwire/tw.pol
DBFILE =/var/lib/tripwire/$(HOSTNAME).twd
REPORTFILE =/var/lib/tripwire/report/$(HOSTNAME)-$(DATE).twr
SITEKEYFILE =/etc/tripwire/site.key
LOCALKEYFILE =/etc/tripwire/$(HOSTNAME)-local.key
EDITOR =/bin/vi
LATEPROMPTING =true
LOOSEDIRECTORYCHECKING =true
MAILNOVIOLATIONS =true
EMAILREPORTLEVEL =3
REPORTLEVEL =3
MAILMETHOD =SENDMAIL
SYSLOGREPORTING =true
MAILPROGRAM =/usr/sbin/sendmail -oi -t

3箇所をデフォルトから変更しています。

LATEPROMPTING=true
…パスフレーズのプロンプト表示を遅く表示(パスフレーズがメモリ上に保持される時間を短くしてくれるそうです)。

LOOSEDIRECTORYCHECKING=true
…変更があった際、ファイルとファイルのあるディレクトリとで2重に検知してしまうのを防ぐ。

SYSLOGREPORTING=true
…動作のログをsyslogへ出力する。

※この辺を参考にしました。
http://www.atmarkit.co.jp/ait/articles/0203/19/news002_2.html

 

 

初期セットアップ

先ほど作成したtwcfg.txtと、twpol.txtを暗号化し、Tripwireが動作するようにしていきます。
なお、twpol.txtは一旦デフォルトのままで作業していきます。
(twpol.txtには、これはまあ改ざんされたらまずそうですね。。というファイルやディレクトリが最初から書いてあります。しかし、あくまで汎用的なものなので、今回だとAmazonLinuxには無いようなものも指定してあったりするのですが、これはあとで修正します)

設定ファイルの暗号化には、パスフレーズとキーファイルを生成する必要があります。
これにはインストールしたTripwireに含まれているtripwire-setup-keyfilesコマンドを使用します。
以下はコマンドの実行例です。対話型でパスフレーズの入力を求められます。

# tripwire-setup-keyfiles

----------------------------------------------
The Tripwire site and local passphrases are used to sign a variety of
files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain both
letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically have upper and lower case letters, digits and punctuation marks, and are at least 8 characters in length.)

Enter the site keyfile passphrase:【任意のパスフレーズを入力】
Verify the site keyfile passphrase:【もう一回任意のパスフレーズを入力】
Generating key (this may take several minutes)...Key generation complete.

(When selecting a passphrase, keep in mind that good passphrases typically have upper and lower case letters, digits and punctuation marks, and are at least 8 characters in length.)

Enter the local keyfile passphrase:【任意のパスフレーズを入力】
Verify the local keyfile passphrase:【もう一回任意のパスフレーズを入力】

Generating key (this may take several minutes)...Key generation complete.

----------------------------------------------
Signing configuration file...
Backing up /etc/tripwire/tw.cfg
to /etc/tripwire/tw.cfg.1228.bak
Please enter your site passphrase:【パスフレーズを入力】
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file: /etc/tripwire/twcfg.txt
has been preserved for your inspection. It is recommended that you move this file to a secure location and/or encrypt it in place (using a tool such as GPG, for example) after you have examined it.

----------------------------------------------
Signing policy file...
Please enter your site passphrase:【パスフレーズを入力】
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file:
/etc/tripwire/twpol.txt
has been preserved for your inspection. This implements a minimal policy, intended only to test essential Tripwire functionality. You should edit the policy file to describe your system, and then use twadmin to generate a new signed copy of the Tripwire policy.

Once you have a satisfactory Tripwire policy file, you should move the clear-text version to a secure location and/or encrypt it in place (using a tool such as GPG, for example).

Now run "tripwire --init" to enter Database Initialization Mode. This reads the policy file, generates a database based on its contents, and then cryptographically signs the resulting database. Options can be
entered on the command line to specify which policy, configuration, and key files are used to create the database. The filename for the database can be specified as well. If no options are specified, the default values from the current configuration file are used.

この時点で、twcfg.txtからtw.cfgが、twpol.txtからtw.polが、それぞれ暗号化されて作成されています。また、localキーファイルと、siteキーファイルが設定ファイルと同じディレクトリに生成されています。

# ls -l /etc/tripwire/
合計 84
-rw-r----- 1 root root 931 11月 6 14:48 【ホスト名】-local.key
-rw-r----- 1 root root 931 11月 6 14:48 site.key
-rw-r----- 1 root root 4586 11月 6 14:48 tw.cfg
-rw-r----- 1 root root 12415 11月 6 14:48 tw.pol
-rw-r--r-- 1 root root 600 11月 5 19:49 twcfg.txt
-rw-r--r-- 1 root root 46653 11月 5 18:52 twpol.txt

 

 

改ざんチェックのテスト試行とtw.polの修正

現在は存在しないファイルやディレクトリが指定されたままのtw.polが使われていますので、これを修正する必要があります。

一回改ざんをチェックすると、存在しないファイルやディレクトリがエラーとして出力されます。
この出力を基に、tw.pol(twpol.txt)を修正します。

 

まず最初にtripwireコマンドに–initオプションを付けて実行し、ベースラインデータベースを作成します。

# tripwire --init
Generating the database...
*** Processing Unix File System ***
### Warning: File system error.
### Filename: /dev/kmem
【略】
Please enter your local passphrase:【パスフレーズを入力】
Wrote database file: /var/lib/tripwire/【ホスト名】.twd
The database was successfully generated.

これにより、
/var/lib/tripwire/【ホスト名】.twd
という名前でベースラインのデータベースが出力されます。

 

続いて、改ざんチェックをしてみます。

# tripwire --check > err.txt 2>&1

存在しないファイル・ディレクトリが指定されているところがerr.txtに出力されます。
err.txtの中身は以下のようになっています。

# view err.txt

Parsing policy file: /etc/tripwire/tw.pol
*** Processing Unix File System ***
Performing integrity check...
### Warning: File system error.
### Filename: /dev/kmem
【略】

上記の「### Filename: 【ファイル名】」というところが、存在しないファイル・ディレクトリが書かれた部分となります。

以下のワンライナーで、twpol.txtから存在しないファイル・ディレクトリの指定をコメントアウトできます。

# for DELPATH in $(cat err.txt | grep '### Filename.*$' | sed -e s/'### Filename: '//g); do DELPATH=$(echo ${DELPATH} | sed -e "s/[\.\/]/\\\&/g"); sed -i "s/${DELPATH}/#&/g" twpol.txt; done

 

なお、Tripwireでは改ざんを検知した場合にメールで通知することができるのですが、tw.pol(twpol.txt)にアドレスを指定しなければならないので、これを追記します。

以下のコマンドで、twpol.txtにメールアドレスを追記できます。

# sed -i "s/^ *rulename =.*$/&\n emailto = 【メールアドレス】,/g" /etc/tripwire/twpol.txt

 

これでtwpol.txtを修正出来たので、再度暗号化してtw.polを最新化します。

# twadmin -m P -c /etc/tripwire/tw.cfg -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

 

修正済みのtw.polを元にベースラインデータベースを再作成します。

# tripwire --init

 

 

改めて改ざんチェックをしてみます。

# tripwire --check

今度は不要なファイルの指定が無くなったので、エラーが出なくなりました。
これでtripwireを使う準備が整いました。

 

 

定期的に改ざんをチェックするcronの設定

Tripwireをインストールすると、

/etc/cron.daily/tripwire-check

としてcron用のスクリプトが設置されており、日次で改ざんをチェックできる状態になっています。
しかし、デフォルトだと改ざんチェック時にレポートメールを送信するようになっていないため、以下のように修正します。

# vi /etc/cron.daily/tripwire-check

#!/bin/sh
HOST_NAME=`uname -n`
if [ ! -e /var/lib/tripwire/${HOST_NAME}.twd ] ; then
echo "**** Error: Tripwire database for ${HOST_NAME} not found. ****"
echo "**** Run "/etc/tripwire/twinstall.sh" and/or "tripwire --init". ****"
else
# test -f /etc/tripwire/tw.cfg && /usr/sbin/tripwire --check
test -f /etc/tripwire/tw.cfg && /usr/sbin/tripwire --check -M
fi

-Mが改ざん発見時にメールが送られるようにするオプションです。

 

 

平文設定ファイルの削除

/etc/tripwire/配下の設定ファイルの元ファイル(twpol.txt、twcfg.txt)は、残しておくとサーバへの侵入者に見られてしまいますので、削除しておきます。

設定変更時には、暗号化された設定ファイルから、平文の設定ファイルを生成することができます。平文設定ファイルを出力するコマンドは、以下となります。

# twadmin -m f -c /etc/tripwire/tw.cfg > /etc/tripwire/twcfg.txt
# twadmin -m p -p /etc/tripwire/tw.pol > /etc/tripwire/twpol.txt

 

なお、設定変更をする場合は、

  • 暗号化済みのtw.pol、tw.cfgを復号化して平文設定ファイルを出力
  • 平文設定ファイルを修正
  • 平文設定ファイルを暗号化
  • ベースラインデータベースを再作成
  • 平文設定ファイルを削除

という流れで作業をする必要があります。

 

 

tw.polにWebコンテンツの改ざん検知を追加

デフォルトのtwpol.txtではシステムに関するファイル・ディレクトリが指定されています。
ここに、ドキュメントルート配下を監視させるように設定を追加してみます。

まずtw.polを復号化して、twpol.txtを取り出します。

# twadmin -m p -p /etc/tripwire/tw.pol > /etc/tripwire/twpol.txt

出力されたtwpol.txtの末尾に、以下の内容を追記します。

# vi /etc/tripwire/twpol.txt

# Check web document root
(
rulename = "web document root",
emailto = 【メールアドレス】,
severity = $(SIG_HI)
)
{
/var/www/html -> $(SEC_BIN) ;
}

 

続いて、改めてtw.polを暗号化します。

# twadmin -m P -c /etc/tripwire/tw.cfg -p /etc/tripwire/tw.pol -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

Please enter your site passphrase:【パスフレーズを入力】
Wrote policy file: /etc/tripwire/tw.pol

続いて、改めてベースラインデータベースを再作成します。

# tripwire --init

Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Please enter your local passphrase:【パスフレーズを入力】
Wrote database file: /var/lib/tripwire/【ホスト名】.twd
The database was successfully generated.

 

これでドキュメントルート配下の監視ができるようになりました。
ドキュメントルート配下のファイルを変更し、レポートメールが飛ぶかを確認してみます。

# echo 'hogehoge' > /var/www/html/index.html
# tripwire --check -M

 

以下の様なレポートが送られてくればOKです。

Open Source Tripwire(R) 2.4.1 Integrity Check Report

Report generated by: root
Report created on: 2014年11月06日 19時05分58秒
Database last updated on: Never

===============================================================================
Report Summary:
===============================================================================

Host name: 【ホスト名】
Host IP address: 127.0.0.1
Host ID: None
Policy file used: /etc/tripwire/tw.pol
Configuration file used: /etc/tripwire/tw.cfg
Database file used: /var/lib/tripwire/【ホスト名】.twd
Command line used: tripwire --check -M

===============================================================================
Rule Summary:
===============================================================================

-------------------------------------------------------------------------------
Section: Unix File System
-------------------------------------------------------------------------------

Rule Name Severity Level Added Removed Modified
--------- -------------- ----- ------- --------
Invariant Directories 66 0 0 0
Temporary directories 33 0 0 0
Tripwire Data Files 100 0 0 0
Critical devices 100 0 0 0
User binaries 66 0 0 0
Tripwire Binaries 100 0 0 0
Libraries 66 0 0 0
Operating System Utilities 100 0 0 0
File System and Disk Administraton Programs
100 0 0 0
Kernel Administration Programs 100 0 0 0
Networking Programs 100 0 0 0
System Administration Programs 100 0 0 0
Hardware and Device Control Programs
100 0 0 0
System Information Programs 100 0 0 0
Application Information Programs
100 0 0 0
(/sbin/rtmon)
Shell Related Programs 100 0 0 0
(/sbin/getkey)
Critical Utility Sym-Links 100 0 0 0
Shell Binaries 100 0 0 0
Critical system boot files 100 0 0 0
System boot changes 100 0 0 0
* web document root 100 0 0 1
(/var/www/html)
OS executables and libraries 100 0 0 0
Critical configuration files 100 0 0 0
Security Control 100 0 0 0
Login Scripts 100 0 0 0
Root config files 100 0 0 0

Total objects scanned: 16267
Total violations found: 1

===============================================================================
Object Detail:
===============================================================================

-------------------------------------------------------------------------------
Section: Unix File System
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Rule Name: web document root (/var/www/html)
Severity Level: 100
-------------------------------------------------------------------------------
----------------------------------------
Modified Objects: 1
----------------------------------------

Modified object name: /var/www/html/index.html

Property: Expected Observed
------------- ----------- -----------
* Inode Number 266169 266213
* Size 10163 10165
* Modify Time 2014年11月05日 18時29分04秒
2014年11月06日 19時05分55秒
* CRC32 AhJSq0 AWZGwd
* MD5 AUyw/eGlPKCNcANoT1EOj6 BQRtOqdCYDspHjTXT6OSQB

===============================================================================
Error Report:
===============================================================================

No Errors

-------------------------------------------------------------------------------
*** End of report ***

Open Source Tripwire 2.4 Portions copyright 2000 Tripwire, Inc. Tripwire is a registered
trademark of Tripwire, Inc. This software comes with ABSOLUTELY NO WARRANTY;
for details use --version. This is free software which may be redistributed
or modified only under certain conditions; see COPYING for details.
All rights reserved.

ちなみに、このレポートは、複数箇所で改ざんがあっても一通しか来ません(改ざん箇所数分届いたりはしません)。

が、改ざんがあろうとなかろうと送られてきてしまいます。改ざん時だけ飛ばすようにしたいのですが、やり方がよくわかりませんでした。。

 

 

運用の仕方

tw.polで指定したファイル・ディレクトリを、運用上必要があり変更する場合、そのまま作業してしまうとcronでの改ざんチェックでアラートが上がってしまいます。

そのため、変更作業を行った後は、再度ベースラインデータベースを作り直す必要があります。

ウェブコンテンツの改ざんを検知したい場合などは、コンテンツを更新するたび、更新した人がコマンドラインでベースラインデータベースを作りなおさなければならなくなってしまうので、正直、運用負荷は高くなるなという印象です。

 

 

 

AmazonLinuxにnkfをインストールするchefレシピ

AmazonLinuxにはnkfが入っていません。リポジトリにも無いです。
nkfが無いとmailコマンドでメールを送るときとかに困るので、CentOS用のnkfのパッケージをインストールします。

パッケージ名(ファイル名)がベタ打ちなので、attributeに持たせた方がいいかも。。

aws-cliでスポットインスタンスをリクエストして起動するサンプル

userdataをbase64で渡さなければならないのがちょっと面倒でした。

aws-cliの他のコマンドだとfile://hoge.txtとかでいいのですが。。

リクエストのステータスがfulfilledになるまでにすごく時間がかかる場合とそうでもない時があるのでタイムアウトをどのくらいにするかが悩ましいところです。

AutoScalingを使ってEC2インスタンスを指定時刻に起動・停止させる

AutoScalingは、アクセス数の増減の傾向がわかっている時間に応じてWebサーバを自動的に増やしたり減らしたりするのに使われる場合がほとんどだと思いますが、単純に任意の時刻に自動的にサーバを起動させたり停止させたりするということもできます。

これを使うと夜中に1時間だけ起動してバッチを動かすというような使い方ができるので、そのサンプルスクリプトを作ってみました。

なお、userdata.txtは「AmazonLinuxでcloud-initを使う」のものを使っています。

 

 

注意点として「put-scheduled-update-group-action」で渡す時刻はGMTである必要があります。

あと気になったこととして、なぜかaws-cliでautoscalingを操作するコマンドを実行した際、成功しても失敗しても何も出力されません。ほかだとjsonが出力されるのですが。。

 

また、このサンプルスクリプトでは素のAmazonLinux AMIが起動するだけなので、起動しても中身が空っぽです。本来はバッチなどを仕込んだセットアップ済みの既存のEC2インスタンスを任意の時間にstartしたりstopしたりできるだけでもいいのですが、少なくともAutoScalingを使った場合はそういうことはできないようでした。
そのため、あらかじめバッチや必要なミドルウェアをインストールしておいたカスタムAMIを起動させるか、起動後にchef-soloなどで自分で自分をセットアップしてあげないと、バッチサーバとしては動作しません。

 

 

 

aws-cliでEC2インスタンスを起動する

aws-cliのコマンド群は、オプションへ値を渡すやり方がバラバラで普通に文字列でvalueを渡せばOKだったりKey=hoge,value=fugaで渡さなければならなかったりjsonで渡さなければならなかったりしていて、実際に動かそうとすると試行錯誤をするはめになるのでサンプルを参考として残しておきます。

公式ドキュメント(http://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html)

 

 

ec2 run-instances(EIPを付与する場合)

 

userdata.txtは「AmazonLinuxでcloud-initを使う」のものを使っています。

 

ec2 run-instances(自動でPublicIPを付与する場合)

 

aws-cliのバージョンが上がると変わっていくのが辛いです。。