IP自動更新スクリプト変更

今使ってるスクリプトでDDNSの自動更新がうまくいかないこともあり、たびたびアクセスできなくなることがあったので、自動更新のスクリプトを見直すことにした。この自宅サーバはddo.jpのDDNSを使ってるので、いろいろ調べて見たら、こちらのサイトで紹介されてるスクリプトが良さそうなので使わせてもらうことにした。
自動更新の動きとしては
(1)ddo.jpサイトで用意しているリモートIP確認サイトで現在のIPを確認。
(2)前回更新時のIPと変更時間をテンポラリーファイルから読み込む。
(3)前回更新時とIP同じで、かつ前回更新時から2週間以上経ってなかったら終了。
(4)そうでなかったら、DDNSを更新。変更内容をテンポラリーファイルとログに書き込む。
という感じで自動更新されるとのことなので、<2週間以上経ってなかったら終了>の所を1週間に変更して使うことにした。
あとこのスクリプトは、lynxが使えることが前提となってるようなので、まずlynxをインストールすることにする。

[root@server ~]# yum -y install lynx

今までと同じディレクトリに作成

[root@server ~]# cd /usr ← /usr ディレクトリへ移動
[root@server usr]# mkdir -p ddns ← ddns ディレクトリの作成
[root@server usr]# cd ddns ← ddns ディレクトリへ移動

■ 自動更新スクリプトの作成

[root@server ddns]# vi ddo.jpIP_upgrade.pl
#!/usr/bin/perl
#
# Check ip address, and update DDNS for "ddo.jp"
#
#
# parameters
# "ddo.jp" ID & PASSWD
local $ID     = 'ドメイン'; # Login ID(It serves as a domain name)
local $PASSWD = 'パスワード'; # Login password
# file names
local $CRT_IPF = '/tmp/CRT_IP2.dat';
local $LOG     = '/var/log/ddns.log';
# Check current ip address on the appointed URL web page.
local $CHK_URL="http://info.ddo.jp/remote_addr.php";
#
local $INTERVAL = 604800;       # 1 weeks
#
$ENV{'PATH'}="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin";
#---------------------------------------------------
# main
my ($NEW_IP,$CRT_IP,$CRT_TIME,$i);
# get current ip address which set as the domain.
$CRT_IP   = "";
$CRT_TIME = "0";
open(INPUT, $CRT_IPF);
foreach(<INPUT>){
chop;
/^IP:/   && do{ $CRT_IP   = $' };
/^TIME:/ && do{ $CRT_TIME = $' };
}
close(INPUT);
# check a assigned ip address
open(INPUT, "lynx -dump \"$CHK_URL\" | ");
foreach(<INPUT>){
/([0-9\.].*)/ && do{ $NEW_IP = $1};
}
close(INPUT);
# Lapsed time from the last update
$i = time() - $CRT_TIME;
# change DDNS, supposing the IP address is changed.
if ( ( ($NEW_IP ne "" )&&($CRT_IP ne $NEW_IP) ) || ( $i > $INTERVAL) ) {
# change DDNS
open(INPUT2,
"lynx -dump \"http://ddo.jp/dnsupdate.php?dn=$ID&ip=$NEW_IP&pw=$PASSWD\" |");
# check whether change of DDNS has been successful
foreach(<INPUT2>){
/SUCCESS: / && do{ $TEMP = 1;};
}
if( $TEMP == 1){
# save a new IP address.
$i = time();
open (OUTPUT ,">$CRT_IPF");
print OUTPUT "IP:$NEW_IP\nTIME:$i\n";
close OUTPUT;
# write a message on the log file
$time = conv_date(time());
open(LOG, ">> $LOG");
print(LOG $time . ":change \"" .
$ID . ".ddo.jp\" <= " . $NEW_IP . "\n");
close(LOG);
}
}
sub conv_date{
my ($times,$mode) = @_;
my ($sec,$min,$hour,$mday,$month,$year,$wday);
($sec,$min,$hour,$mday,$month,$year,$wday,undef,undef) = localtime($times);
$month++;
$year += 1900;
$times = sprintf("%d/%02d/%02d %02d:%02d", $year, $month, $mday,
$hour, $min);
return($times);
}

■ スクリプトに実行権限を与える

[root@server ddns]# chmod +x ddo.jpIP_upgrade.pl

■ このスクリプトをcronで1分おきに実行するように/etc/crontabに追加。

[root@server ddns]# cd
[root@server ~]# vi /etc/crontab
*/1 * * * * root /usr/ddns/ddo.jpIP_upgrade.pl

■ 停電などで再起動させたとき自動で実行するように設定

[root@server ~]# vi /etc/rc.local ← システム起動時実行コマンド定義ファイル編集
以下を最終行へ追加
chmod +x /usr/ddns/ddo.jpIP_upgrade.pl
/usr/ddns/ddo.jpIP_upgrade.pl

Fedora 9 ネットワークトラブル

メインサーバーにもFedora 9 をインストール。予備サーバーのときもそうだったが、今回もまったく同じトラブルがあった。途中でリモート接続が出来ないことに気づき、「ifconfig」で確認してみると、ネットワークの設定で指定したIPアドレスと違うIPアドレスになっている。IPアドレスを変更したら正常にリモート接続できたが、fedora1から毎回バージョンアップしてきてるのに、こんなトラブルははじめてだ。
■ネットワーク情報の確認

[root@server ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:E0:4C:E0:27:79
inet addr:yokensaka.com  Bcast:192.168.1.255  Mask:255.255.255.0
inet6 addr: 2001:c90:1c84:11e3:2e0:4cff:fee0:2779/64 Scope:Global
inet6 addr: fe80::2e0:4cff:fee0:2779/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:1144630 errors:0 dropped:0 overruns:0 frame:0
TX packets:671284 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1133307948 (1.0 GiB)  TX bytes:238603740 (227.5 MiB)
Interrupt:23 Base address:0x8000

ネットワーク設定では「192.168.1.10」にしてたが、確認すると「yokensaka.com」になってた。
vi /etc/sysconfig/network-scripts/ifcfg-eth0で見るとちゃんと「192.168.1.10」になってる。ifconfigで確認したIPアドレスに変更することでリモート接続できるようになった。
■IPアドレスの変更

[root@server ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0
# VIA Technologies, Inc. VT6102 [Rhine-II]
DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.1.255
HWADDR=00:e0:4c:e0:27:79
IPADDR=192.168.1.10
↓
IPADDR=yokensaka.com
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
DNS1=192.168.1.1
SEARCH="yokensaka.com"
NM_CONTROLLED=

Fedoraリリースノート「ネットワークマネージャー」を見るとどうもネットワークマネージャーは停止して古いネットワークサービスに切り替えたほうが良さそう。
※リモート操作でネットワークマネージャーを停止すると、その時点で繋がらなくなるので、リモート操作ではなくサーバー機で作業するようにする。
■ネットワークマネージャーの停止と自動起動の無効

[root@server ~]# /etc/rc.d/init.d/NetworkManager stop
[root@server ~]# chkconfig NetworkManager off

■ネットワークサービスの開始と自動起動設定

[root@server ~]# /etc/rc.d/init.d/network start
[root@server ~]# chkconfig network on

Fedora 9 にバージョンアップ

5月14日、 Fedora 9 がリリースされた。
自宅サーバーの予備機に Fedora 9 をインストールして、カテゴリーにある各種サーバー設定、セキュリティー設定等を行い、データのバックアップも無事終わった。今のところ問題なく動いている。すぐにでもメインサーバーとして切り替えられる状態だが、暫く様子見て安定してるようならメインサーバーも Fedora 9 にしよう。
Fedora 9 の新機能については、リリースノートを・・・。>>
20080517-f9launch.png

バックアップ(クライアントPCへ)

■ FC2~FC6 / Fedora7 / Fedora8 / Fedora9

A. クライアント側でのRsync によるバックアップ
(Linuxメインサーバー⇒Linux予備サーバー)

ここでは rsync を使用して、予備サーバーの起動時にメインサーバーのhtmlデータを予備サーバーに自動でバックアップする。rsync はアクセス権限や所有者情報もあわせてバックアップできる為、CGI等のパーミッションや所有者情報の設定をせずに即実行できる。また、rsync コマンドは、2回目以降は更新分のみバックアップしたり、バックアップ元から削除されたファイルをバックアップ先からも削除するなど同期を行うことも可能。データを同期させておけば、メインサーバーにトラブルが発生しても、すぐに予備のサーバーに切り替えることが出来る。
SSH を利用して予備サーバーからメインサーバーに対して rsync を自動実行するようにする。尚作業はメインサーバー、予備サーバーともrootで行う。
1.鍵の作成
先ずは、予備サーバーのほうで鍵の作成。Enterと書いてある部分は、何も入力せずにEnterキーを押せばOK。

[root@linux ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):   ←Enter
Enter passphrase (empty for no passphrase):   ←Enter
Enter same passphrase again:   ←Enter
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
16:68:99:ee:3a:4b:54:e3:29:e5:19:d2:9e:5c:06:7d root@linux.yokensaka.com

次にメインサーバーのほうのsshd_configを編集して、rootでのログインを許可。

[root@server ~]# vi /etc/ssh/sshd_config
PermitRootLogin no
↓
PermitRootLogin yes
この変更を終えたら、メインサーバーのSSHを再起動しておく。
[root@server ~]# service sshd restart

2.予備サーバーで作成した公開鍵の抜き取り

すでにsshでログインできる環境なら、scpコマンドで以下のようにコピーすることが出来る。

[root@linux ~]# scp /root/.ssh/id_rsa.pub 192.168.1.10:/root/.ssh/

メインサーバーの/rootにコピーしたid_rsa.pubをauthorized_keys2に登録。
続いて、authorized_keys2のパーミッションの変更。

[root@server ~]# mkdir .ssh
[root@server ~]# cat id_rsa.pub >> /root/.ssh/authorized_keys2    ←/rootで
[root@server ~]# chmod 600 /root/.ssh/authorized_keys2

以上で、予備サーバーからメインサーバーへのSSH接続は、パスワード等を入力することなく
接続できるようになっている。試しに予備サーバーから、メインサーバーにSSHで接続してみる。

[root@linux ~]# ssh 192.168.1.10
The authenticity of host '192.168.1.10 (192.168.1.10)' can't be established.
RSA key fingerprint is c5:df:b7:ec:8a:b4:68:dd:89:9d:ae:88:4b:33:4e:ae.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.10' (RSA) to the list of known hosts.
Last login: Sat Oct  7 11:53:15 2006 from linux.yokensaka.com
[root@server ~]#  ← SSHサーバーへパスワード応答なしでログインできた
[root@server ~]# exit ← SSHサーバーからログアウト
Connection to 192.168.1.10 closed.
[root@linux ~]# ← SSHサーバーからログアウトした

これでパスワードなどを入力することなく、メインサーバーに接続できる。
3.バックアップスクリプト作成(クライアント側)
すでに作成されてるサーバーのバックアップファイルと/var/www/html/にあるファイルを予備サーバーに rsync でダウンロードするスプリクト作成。

[root@linux ~]# vi backuprsync.sh
#!/bin/sh
RSYNC='rsync -avz -e ssh --delete'
$RSYNC 192.168.1.10:/var/www/html/ /var/www/html/ >> /var/log/backup.log
$RSYNC 192.168.1.10:/backup/backup.tar.bz2 /root/backup.tar.bz2 >> /var/log/backup.log
$RSYNC 192.168.1.10:/backup/fcdump.sql /root/fcdump.sql >> /var/log/backup.log
$RSYNC 192.168.1.10:/backup/ss1129dump.sql /root/ss1129dump.sql >> /var/log/backup.log
$RSYNC 192.168.1.10:/backup/nucleusdump.sql /root/nucleusdump.sql >> /var/log/backup.log
$RSYNC 192.168.1.10:/backup/takadump.sql /root/takadump.sql >> /var/log/backup.log
※サーバー側の/var/www/html/にあるファイルを、クライアント側の/var/www/html/へ上書きコピー
※サーバー側の/backup/の中にある個別のファイルをクライアント側の/root/にバックアップ
[root@linux ~]# chmod +x backuprsync.sh ← 作成したバックアップスクリプトへ実行権限付加

※mysqldump.sqlについてはメインサーバーの情報等が入っているのでクライアント側にリストアするとトラブルになる。mysqldump.sqlはクライアント側にはバックアップしない。あくまで個別のデータのみバックアップする。
4.バックアップスクリプト確認(クライアント側)

[root@linux ~]# /root/backuprsync.sh ← バックアップスクリプト実行
[root@linux ~]# ll /var/www/html/ ← バックアップ結果確認
※メインサーバーと同じ物がバックアップされてるはず
[root@linux ~]# ll /root/ ← バックアップ結果確認
合計 836080
drwxr-xr-x 2 root root      4096 10月 28 01:23 Desktop
-rw------- 1 root root      1183 10月 28 01:17 anaconda-ks.cfg
-rwx------ 1 root root      1983 10月 28 07:50 backup.sh
-rw-r--r-- 1 root root 843245840 10月 28 05:18 backup.tar.bz2 ← htmlバックアップファイル
-rw-r--r-- 1 root root        14 10月 28 07:50 backuplist
-rwxr-xr-x 1 root root       536 10月 28 08:02 backuprsync.sh
-rwx------ 1 root root       150 10月 28 06:33 chkrootkit.sh
-rwx------ 1 root root       253 10月 28 06:42 clamav.sh
-rwxr-xr-x 1 root root      2248 10月 28 06:23 conv_weblog_to_utf8.pl
-rw-r--r-- 1 root root     89327 10月 28 05:00 fcdump.sql ← fcバックアップファイル
-rw-r--r-- 1 root root     41402 10月 28 01:17 install.log
-rw-r--r-- 1 root root      3867 10月 27 06:58 install.log.syslog
-rw-r--r-- 1 root root    152446 10月 28 05:00 ss1129dump.sql ← ss1129バックアップファイル
-rwx------ 1 root root       337 10月 28 07:46 mysqldump.sh
-rw-r--r-- 1 root root  11451638 10月 28 05:00 nucleusdump.sql ← nucleusバックアップファイル
-rw-r--r-- 1 root root    239655 10月 28 05:00 takadump.sql ← takaバックアップファイル

※メインサーバーのバックアップファイルが/root/にバックアップされている
5.バックアップスクリプト自動実行設定

[root@linux ~]# vi /etc/rc.local ← システム起動時実行コマンド定義ファイル編集
/root/backuprsync.sh ← 最終行へ追加

これで、linuxクライアント起動時に自動でサーバーのhtmlファイルとデータベースファイルがバックアップされるようになる。
※ メインサーバーが再起動した時など、誤って予備サーバーのデーターをメインサーバーに上書きする可能性があるのでメインサーバーにはこの設定はしないこと!!
6.データベースを予備サーバーへ復元
htmlファイルは直に上書きしているが、データベースファイルは予備サーバー側で以下のコマンドを実行すれば各データベースが復元される

[root@linux ~]# mysql -uroot -pパスワード fc < /root/fcdump.sql
[root@linux ~]# mysql -uroot -pパスワード ss1129 < /root/ss1129dump.sql
[root@linux ~]# mysql -uroot -pパスワード nucleus < /root/nucleusdump.sql
[root@linux ~]# mysql -uroot -pパスワード taka < /root/takadump.sql

7.データベースを予備サーバーへ復元するスプリクトを作成

[root@linux ~]# vi restore.sh
#!/bin/bash
mysql -uroot -pパスワード fc < /root/fcdump.sql
mysql -uroot -pパスワード ss1129 < /root/ss1129dump.sql
mysql -uroot -pパスワード nucleus < /root/nucleusdump.sql
mysql -uroot -pパスワード taka < /root/takadump.sql
作成したリストアスクリプトへ実行権限付加
[root@linux ~]# chmod 700 restore.sh
リストアスクリプトを実行してみる
[root@linux ~]# ./restore.sh

※ 誤って古いデーターを上書きする可能性があるのでメインサーバーにはこの設定はしないこと!!

B. クライアント側でのFTP によるバックアップ設定
(Linuxメインサーバー⇒Linux予備サーバー)

基本的には(A)の Rsync によるバックアップを行なっているが Rsync によるバックアップがうまくいかない場合とか、自宅サーバーで自分しかアクセスしないような環境ならば FTP によるバックアップでも問題ないので FTP によるバックアップ設定も一応構築しておく。
1.FTP でダウンロードするスプリクト作成
すでに作成されてるサーバーのバックアップファイルと/var/www/html/にあるファイルを予備サーバーに FTP でダウンロードするスプリクト作成。

[root@linux ~]# vi backupftp.sh
#!/bin/sh
#cd /usr/bin
ftp -n 192.168.1.10 << "EOD"
user higo パスワード
binary
cd /backup
get backup.tar.bz2
get fcdump.sql
get ss1129dump.sql
get nucleusdump.sql
get takadump.sql
bye
EOD

※mysqldump.sqlについてはメインサーバーの情報等が入っているのでクライアント側にリストアするとトラブルになる。なので、mysqldump.sqlはクライアント側にはバックアップしない。あくまで個別のデータのみバックアップする。
2.作成したバックアップスクリプトへ実行権限付加

[root@linux ~]# chmod 700 backupftp.sh

3.クライアント(linux)でのFTPによるバックアップスクリプトを実行してみる

[root@linux ~]# ./backupftp.sh

4.バックアップ結果確認

[root@linux ~]# ll /root/
合計 483288
drwxr-xr-x 2 root root      4096  9月 28 07:06 Desktop
-rw------- 1 root root      1256  9月 28 07:01 anaconda-ks.cfg
-rwx------ 1 root root      1983 10月  1 19:10 backup.sh
-rw-r--r-- 1 root root 486301589 10月  7 08:05 backup.tar.bz2 ← htmlファイル
-rwx------ 1 root root       252 10月  1 07:17 backupget.sh
-rw-r--r-- 1 root root        14 10月  1 19:10 backuplist
-rwxr-xr-x 1 root root       118 10月  7 10:10 backuprsync.sh
-rwx------ 1 root root       151  9月 29 23:50 chkrootkit.sh
-rwxr-xr-x 1 root root      2248  9月 29 23:46 conv_weblog_to_utf8.pl
-rwx------ 1 root root        80 10月  1 22:50 ddo.jpIP_upgrade.sh
drwxr-xr-x 2 1341 1000     20480  9月 14 05:36 docs
-rw-r--r-- 1 root root     89327 10月  7 08:05 fcdump.sql ← fcデータベースファイル
-rw-r--r-- 1 root root     41604  9月 28 06:57 install.log
-rw-r--r-- 1 root root      3975  9月 28 06:50 install.log.syslog
-rw-r--r-- 1 root root    150847 10月  7 08:05 ss1129dump.sql ← ss1129データベースファイル
-rw-r--r-- 1 root root  10591330 10月  7 08:05 nucleusdump.sql ← nucleusデータベースファイル
-rwx------ 1 root root       306  9月 30 01:55 snortsnarf.sh
-rw-r--r-- 1 root root    238771 10月  7 08:05 takadump.sql ← takaデータベースファイル
-rwx------ 1 root root       618  9月 30 03:14 tripwire.sh

backuprsync.shを自動実行させているので/backupftp.shは自動実行させないで何かあったら手動で実行させるようにしている。

C. Winクライアント側でのFTP によるバックアップ設定
(Linuxメインサーバー⇒Winクライアント)

サイトのデータはクライアント(Win)のC:\Documents and Settings\ユーザー名\My Documents\www\yokensakaというフォルダにて管理しているのでサーバーのバックアップファイルも(Win)の同じところにバックアップしておく。
バックアップファイル格納フォルダをC:\Documents and Settings\ユーザー名\My Documents\www\yokensakaに作成しておく。
(C:\Documents and Settings\ユーザー名\My Documents\www\yokensaka\backup)
1.バックアップファイル取得コマンドの作成
以下の内容でC:\Documents and Settings\ユーザー名\My Documents\www\yokensaka\backup\backupget.txtを作成

open 192.168.1.10
ユーザー名 ← FTPでサーバーへ接続するためのユーザー名
******** ← FTPでサーバーへ接続するためのパスワード
binary
get /backup/backup.tar.bz2
get /backup/mysqldump.sql
get /backup/fcdump.sql
get /backup/ss1129dump.sql
get /backup/nucleusdump.sql
get /backup/takadump.sql
quit

2.バッチファイルの作成
以下の内容でC:\Documents and Settings\ユーザー名\My Documents\www\yokensaka\backup\backupget.batを作成

ftp -s:backupget.txt > backupget.log

FTP処理を行い、結果をbackupget.logに出力するbackupget.batというバッチファイル
3.バッチファイル(backupget.bat)を実行
C:\Documents and Settings\ユーザー名\My Documents\www\yokensaka\backup\backupget.batをダブルクリックで実行し、 C:\Documents and Settings\ユーザー名\My Documents\www\yokensaka\backupフォルダにbackup.tar.bz2及び各dump.sqlが転送されてきていることを確認。また、C:\Documents and Settings\ユーザー名\My Documents\www\yokensaka\backupフォルダにbackupget.logが作成されていることを確認。
4.バックアップファイル取得自動実行
backupget.batファイルをスタートアップに登録して、クライアント(Windows)を起動したときに自動でバックアップを行うようにする。

D. バックアップファイルをLinuxメインサーバーへ復元
(クライアントPC⇒Linuxメインサーバー⇒復元)

バックアップファイルをLinuxメインサーバーへ復元する必要が出てきた場合は、クライアントPCからLinuxメインサーバーへバックアップファイルを戻してからLinuxメインサーバー側で以下のコマンドを実行することで、パーミッション、所有者も含めて元のメインサーバーにリストア出来る。

[root@server ~]# tar jxvfP /backup/backup.tar.bz2
個別にパーミッション、所有者も含めて復元する場合
[root@server ~]# tar jxvfP /backup/backup.tar.bz2 /var/www/html/ファイル名

mysqldumpでバックアップしたファイルを使って元のメインサーバーにリストアするにはmysqlコマンドを使う。

全てをバックアップした場合のリストア
[root@server ~]# mysql -uroot -pパスワード < /backup/alldump.sql
個別のデータベースをバックアップした場合のリストア
[root@server ~]# mysql -uroot -pパスワード mysql < /backup/mysqldump.sql
[root@server ~]# mysql -uroot -pパスワード fc < /backup/fcdump.sql
[root@server ~]# mysql -uroot -pパスワード ss1129 < /backup/ss1129dump.sql
[root@server ~]# mysql -uroot -pパスワード nucleus < /backup/nucleusdump.sql
[root@server ~]# mysql -uroot -pパスワード taka < /backup/takadump.sql
mysqlをリストアした場合や全てをリストアした場合はmysqlの再起動が必要
[root@server ~]# /etc/init.d/mysql restart

バックアップ(サーバー内へ)

■ FC2~FC6 / Fedora7 / Fedora8 / Fedora9
サーバーのデータを tar コマンドを使い、同じサーバー内に圧縮バックアップが出来るようにする。
■ サーバー側でのバックアップ設定
1.バックアップスクリプト作成

[root@server ~]# vi backup.sh
#!/bin/bash
LANG=C
# バックアップ対象ファイルリスト名
BACKUPLIST=/root/backuplist
[ ! -s $BACKUPLIST ] && echo "$BACKUPLIST is not found" && exit 1
# バックアップ対象外ファイルリスト名
BACKUPNOLIST=/root/backupnolist
# バックアップ先ディレクトリ名
BACKUPDIR=/backup
mkdir -p $BACKUPDIR
# バックアップの保存世代数
BACKUPGEN=12
# バックアップのログファイル名
BACKUPLOG=/var/log/backup.log
# バックアップ先ディレクトリをバックアップ対象外ファイルリストに追加
TMPBACKUPNOLIST=`mktemp`
[ -s $BACKUPNOLIST ] && cat $BACKUPNOLIST > $TMPBACKUPNOLIST
echo $BACKUPDIR >> $TMPBACKUPNOLIST
# 前回バックアップしたファイル名変更
cd $BACKUPDIR
OLDBACKUPFILE=`ls backup.tar.bz2* 2>/dev/null`
if [ -f $OLDBACKUPFILE ]; then
TIMESTAMP=`ls --full-time $OLDBACKUPFILE|awk '{print $6}'|tr -d -`
mv $BACKUPDIR/$OLDBACKUPFILE $BACKUPDIR/${TIMESTAMP}$OLDBACKUPFILE > /dev/null 2>&1
fi
# バックアップのログファイル作成
rm -f $BACKUPLOG
touch $BACKUPLOG
chmod 400 $BACKUPLOG
# バックアップの実行
echo "`date` backup start" >> $BACKUPLOG
tar cjvfP $BACKUPDIR/backup.tar.bz2 -T $BACKUPLIST -X $TMPBACKUPNOLIST >> $BACKUPLOG 2>&1
[ $? -ne 0 ] && cat $BACKUPLOG | mail -s "BACKUP NG" root && exit 1
echo "`date` backup end" >> $BACKUPLOG
# バックアップの保存世代を超えた古いバックアップファイルを削除
if [ $(ls /backup/|wc -l) -gt $BACKUPGEN ]; then
OLDBACKUPCNT=`expr $(ls /backup/|wc -l) - $BACKUPGEN`
for file in `ls -t $BACKUPDIR|tail -n $OLDBACKUPCNT`
do
rm -f $BACKUPDIR/$file
done
fi
# バックアップ対象外ファイルを削除
rm -f $TMPBACKUPNOLIST

バックアップスクリプトへ実行権限付加

[root@server ~]# chmod 700 backup.sh

2.バックアップ対象ファイルリストの作成
バックアップ対象ファイルリストに/var/www/htmlディレクトリを追加

[root@server ~]# echo "/var/www/html" >> backuplist

3.バックアップ対象外ファイルリストの作成
例としてバックアップ対象外ファイルリストに/var/www/errorディレクトリを追加

[root@server ~]# echo "/var/www/error" >> backupnolist

4.バックアップスクリプトの確認

[root@server ~]# ./backup.sh ← バックアップスクリプトの実行
[root@server ~]# ls -lh /backup ← バックアップ先ディレクトリの照会
合計 754M
-rw-r--r-- 1 root root 753M 10月 27 20:15 backup.tar.bz2
↑ backup.tar.bz2というバックアップファイルが出来ている

5.バックアップディレクトリ、ファイルの確認

[root@server ~]# tar tjvf /backup/backup.tar.bz2
バックアップしたディレクトリ、ファイルが一覧表示される

6.バックアップ定期自動実行設定

[root@server ~]# crontab -e
00 05 * * * /root/backup.sh ← 追加(毎日05:00にバックアップを実行する)

■MySQLのデータベースのバックアップ
MySQLのバックアップにも色々な方法があるが、もっとも簡単な方法はmysqldumpを利用して自サーバー内の/backupディレクトリーにバックアップすることだと思う。
1.mysqldumpによるバックアップ
たとえば、全データベースを/backupディレクトリーにalldump.sqlという名前でバックアップするのなら次のようにする。linuxではこれをcronから起動させれば深夜に無人バックアップさせることが出来る。

[root@server ~]# mysqldump -A -uroot -pパスワード -Q --opt -r/backup/alldump.sql

個別のデータベースを/backupディレクトリーにデータベース名.sqlという名前でバックアップしたい場合は以下のようにする。

[root@server ~]# mysqldump mysql -uroot -pパスワード -Q --opt -r/backup/mysqldump.sql
[root@server ~]# mysqldump fc -uroot -pパスワード -Q --opt -r/backup/fcdump.sql
[root@server ~]# mysqldump ss1129 -uroot -pパスワード -Q --opt -r/backup/ss1129dump.sql
[root@server ~]# mysqldump nucleus -uroot -pパスワード -Q --opt -r/backup/nucleusdump.sql
[root@server ~]# mysqldump taka -uroot -pパスワード -Q --opt -r/backup/takadump.sql

2.MySQLのデータベースの自動バックアップ

MySQLの個別のデータベースを/backupにバックアップするスクリプトを作成。
[root@server ~]# vi mysqldump.sh
#! /bin/sh
mysqldump mysql -uroot -pパスワード -Q --opt -r/backup/mysqldump.sql
mysqldump fc -uroot -pパスワード -Q --opt -r/backup/fcdump.sql
mysqldump ss1129 -uroot -pパスワード -Q --opt -r/backup/ss1129dump.sql
mysqldump nucleus -uroot -pパスワード -Q --opt -r/backup/nucleusdump.sql
mysqldump taka -uroot -pパスワード -Q --opt -r/backup/takadump.sql
実行権限を与える
[root@server ~]# chmod 700 mysqldump.sh
バックアップスクリプトを実行
[root@server ~]# ./mysqldump.sh
バックアップされてるか確認
[root@linux ~]# ls -lh /backup
合計 1.2G
-rw-r--r-- 1 root root 753M 10月 28 05:16 backup.tar.bz2
-rw-r--r-- 1 root root 377K 10月 28 05:00 fcdump.sql
-rw-r--r-- 1 root root 150K 10月 28 05:00 ss1129dump.sql
-rw-r--r-- 1 root root 285K 10月 28 05:00 mysqldump.sql
-rw-r--r-- 1 root root  12M 10月 28 05:00 nucleusdump.sql
-rw-r--r-- 1 root root 234K 10月 28 05:00 takadump.sql

3.自動実行
すでに毎日5:00にデータベース以外のバックアップを自動実行させているのでデータベースも連携してバックアップする。
先にデータベースをバックアップして次に他のバックアップを実行するように/root/backup.shの前に/root/mysqldump.shを入れる。

[root@server ~]# crontab -e
00 05 * * * /root/mysqldump.sh ; /root/backup.sh

4.復元
バックアップファイルをサーバーへ復元する必要が出てきた場合は、以下のコマンドを実行することで、パーミッション、所有者も含めて元のメインサーバーにリストア出来る。

[root@server ~]# tar jxvfP /backup/backup.tar.bz2
個別にパーミッション、所有者も含めて復元する場合は
[root@server ~]# tar jxvfP /backup/backup.tar.bz2 /var/www/html/ファイル名

mysqldumpでバックアップしたファイルをリストアするにはmysqlコマンドを使う。

全てをバックアップした場合のリストア
[root@server ~]# mysql -uroot -pパスワード < /backup/alldump.sql
個別のデータベースをバックアップした場合のリストア
[root@server ~]# mysql -uroot -pパスワード mysql < /backup/mysqldump.sql
[root@server ~]# mysql -uroot -pパスワード fc < /backup/fcdump.sql
[root@server ~]# mysql -uroot -pパスワード ss1129 < /backup/ss1129dump.sql
[root@server ~]# mysql -uroot -pパスワード nucleus < /backup/nucleusdump.sql
[root@server ~]# mysql -uroot -pパスワード taka < /backup/takadump.sql
mysqlをリストアした場合や全てをリストアした場合はmysqlを再起動が必要
[root@server ~]# /etc/init.d/mysql restart

バッファ・オーパーフロー対策(Exec-Shield)

■ FC6 / Fedora7 / Fedora8 / Fedora9
Exec-Shieldを有効にして、バッファ・オーパーフロー攻撃をブロックする。
■ Exec-Shieldの設定

現状確認
[root@server ~]# cat /proc/sys/kernel/exec-shield
1
Exec-Shieldを有効にする。
[root@server ~]# echo 2 > /proc/sys/kernel/exec-shield
再確認
[root@server ~]# cat /proc/sys/kernel/exec-shield
2
起動時に、有効にする。
[root@server ~]# vi /etc/rc.d/rc.local
echo 2 > /proc/sys/kernel/exec-shield    ← 追加

■ Exec-Shieldの動作確認

[root@server ~]# wget http://pubs.research.avayalabs.com/src/libsafe-2.0-16.i386.rpm
--20:09:05--  http://pubs.research.avayalabs.com/src/libsafe-2.0-16.i386.rpm
=> `libsafe-2.0-16.i386.rpm'
pubs.research.avayalabs.com をDNSに問いあわせています... 198.152.240.29
pubs.research.avayalabs.com|198.152.240.29|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 374,371 (366K) [text/plain]
100%[====================================>] 374,371      120.19K/s    ETA 00:00
20:09:09 (119.99 KB/s) - `libsafe-2.0-16.i386.rpm' を保存しました [374371/374371]
[root@server ~]# rpm -ivh libsafe-2.0-16.i386.rpm  ← libsafeのインストール
準備中...                   ########################################### [100%]
1:libsafe                ########################################### [100%]
Adding libsafe to ld.so.preload for system wide protection
[root@server ~]# cp /usr/doc/libsafe-2.0/exploits/t1 ./  ← 攻撃ツールをコピー
[root@server ~]# rpm -e libsafe  ← libsafeのアンインストール
Removing libsafe from /etc/ld.so.preload (if exists)
[root@server ~]# ./t1  ← 攻撃ツールの実行
This program tries to use strcpy() to overflow the buffer.
If you get a /bin/sh prompt, then the exploit has worked.
Press any key to continue...abc;  ← 適当に入力
セグメンテーション違反です  ← バッファオーバーフローがブロックされた
[root@server ~]# rm ./t1  ← 攻撃ツールを削除
rm: remove 通常ファイル `./t1'? y

ClamAV version: 0.93にアップデート

■ Fedora8 / Fedora9
ClamAVがversion: 0.93にアップデートされたので、ソースから手動でインストール。
■ ソースからインストールした古いバージョンのclamavをアンインストール

アンインストール用にバックアップしてあったモジュールを展開。
[root@server ~]# tar zxvf clamav-0.92.1_self.tar.gz
clamav-0.92.1のディレクトリへ移動
[root@server ~]# cd clamav-0.92.1
clamav-0.92.1のアンインストール
[root@server clamav-0.92.1]# make uninstall
clamav-0.92.1のファイルとディレクトリーを削除
[root@server clamav-0.92.1]# cd
[root@server ~]# rm -f clamav-0.92.1_self.tar.gz
[root@server ~]# rm -rf clamav-0.92.1
古いバージョンのディレクトリーの削除
[root@server ~]# rm -rf /usr/local/clamav

clamavはインストールする前に
「clamav」という名前のユーザとグループを作成しておく必要がある。

[root@linux ~]# groupadd clamav
[root@linux ~]# useradd -g clamav -s /bin/false clamav

■ 最新版のClamAVをダウンロード 最新版は公式サイトで確認。

[root@server ~]# wget http://freshmeat.net/redir/clamav/29355/url_tgz/clamav-0.93.tar.gz
clamav-0.93を展開
[root@server ~]# tar zxvf clamav-0.93.tar.gz
ダウンロードしたファイルを削除
[root@server ~]# rm -f clamav-0.93.tar.gz
clamav-0.93ディレクトリーへ移動
[root@server ~]# cd clamav-0.93
Makefileを自動作成するためのツール「configure」を実行。
[root@server clamav-0.93]# ./configure --prefix=/usr/local/clamav
makeを実行し、clamavをインストール
[root@server clamav-0.93]# make
[root@server clamav-0.93]# make install

■ アンインストール用にバックアップしておく

[root@server clamav-0.93]# cd
[root@server ~]# tar cvf clamav-0.93_self.tar ./clamav-0.93
[root@server ~]# gzip clamav-0.93_self.tar

■ 設定ファイル変更
インストールが正常に完了したらまず、二つの設定ファイル
/usr/local/clamav/etc/freshclam.conf
/usr/local/clamav/etc/clamd.conf
をエディタで開きExampleと書かれた行をコメントアウトし、保存。

[root@server ~]# vi /usr/local/clamav/etc/freshclam.conf
# Comment or remove the line below.
Example
↓
#Example
[root@server ~]# vi /usr/local/clamav/etc/clamd.conf
# Comment or remove the line below.
Example
↓
#Example

■ 「freshclam」を使用してVirusDBをアップデート

[root@server ~]# /usr/local/clamav/bin/freshclam
ClamAV update process started at Sun Apr 27 08:59:28 2008
main.cvd is up to date (version: 46, sigs: 231834, f-level: 26, builder: sven)
WARNING: getfile: daily-6689.cdiff not found on remote server (IP: 219.117.246.122)
WARNING: getpatch: Can't download daily-6689.cdiff from database.clamav.net
WARNING: getfile: daily-6689.cdiff not found on remote server (IP: 219.117.246.122)
WARNING: getpatch: Can't download daily-6689.cdiff from database.clamav.net
nonblock_connect: connect timing out (30 secs)
Can't connect to port 80 of host database.clamav.net (IP: 211.10.155.48)
Trying host database.clamav.net (211.12.214.131)...
WARNING: getfile: daily-6689.cdiff not found on remote server (IP: 211.12.214.131)
WARNING: getpatch: Can't download daily-6689.cdiff from database.clamav.net
WARNING: Incremental update failed, trying to download daily.cvd
nonblock_connect: connect timing out (30 secs)
Can't connect to port 80 of host database.clamav.net (IP: 211.10.155.48)
Trying host database.clamav.net (211.12.214.131)...
Downloading daily.cvd [100%]
daily.cvd updated (version: 6957, sigs: 39725, f-level: 26, builder: arnaud)
Database updated (271559 signatures) from database.clamav.net (IP: 211.12.214.131)

■ ウィルススキャン確認(/etc/passwdをスキャンしてみる)

[root@server ~]# /usr/local/clamav/bin/clamscan --infected --remove --recursive /etc/passwd
----------- SCAN SUMMARY -----------
Known viruses: 270800
Engine version: 0.93
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.00 MB
Time: 4.017 sec (0 m 4 s)

version: 0.93でスキャンされてることを確認
■ Clam AntiVirusの定期自動実行設定
毎日自動的にウィルス定義ファイル最新化して、全てのファイルのウィルススキャンを行うスプリクトの作成

[root@linux ~]# vi clamav.sh
#!/bin/bash
PATH=/usr/bin:/bin
# excludelist
excludelist=/root/clamscan.exclude
if [ -s $excludelist ]; then
for i in `cat $excludelist`
do
if [ $(echo "$i"|grep \/$) ]; then
i=`echo $i|sed -e 's/^\([^ ]*\)\/$/\1/p' -e d`
excludeopt="${excludeopt} --exclude-dir=$i"
else
excludeopt="${excludeopt} --exclude=$i"
fi
done
fi
CLAMSCANTMP=`mktemp`
/usr/local/clamav/bin/freshclam > /dev/null
/usr/local/clamav/bin/clamscan --recursive --remove ${excludeopt} / > $CLAMSCANTMP 2>&1
[ ! -z "$(grep FOUND$ $CLAMSCANTMP)" ] && \
grep FOUND$ $CLAMSCANTMP | mail -s "Virus Found in `hostname`" root
rm -f $CLAMSCANTMP

■ Clam AntiVirus定期自動実行スクリプトに実行権限付加

[root@linux ~]# chmod 700 clamav.sh

■ cron編集

[root@linux ~]# crontab -e
00 03 * * * /root/clamav.sh ← 追加(毎日3:00にClam AntiVirusの定期自動実行)

■ スキャン除外設定
backupディレクトリをスキャン対象外にするように設定

[root@linux ~]# echo "/backup/" >> clamscan.exclude

rootkit検知ツール(chkrootkit)

■ FC2~FC6 / Fedora7 / Fedora8 / Fedora9
chkrootkit は、システムにrootkitが組み込まれていないかを検査してくれるツールで、 rootkit とは、不正アクセスの痕跡を消し去り、それを隠ぺいし、さらなる標的を攻撃することを可能とするツール群。 chkrootkit は、いくつかの rootkit を検出できるが、 検出しても駆除する機能はない。しかし、不正侵入検知に役立つ。
■chkrootkitのインストール

chkrootkitをインストール
[root@linux ~]# yum -y install chkrootkit

■chkrootkitの実行

chkrootkitを実行
[root@linux ~]# chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
・
・
・
Checking `scalper'... not infected
Checking `slapper'... not infected
Checking `z2'... user root deleted or never logged from lastlog!
Checking `chkutmp'... chkutmp: nothing deleted

実行結果中に”INFECTED”という行がなければ問題ない
■chkrootkitの実行(エラーのみ表示)

chkrootkitの実行(エラーのみ表示)
[root@linux ~]# chkrootkit -q
user root deleted or never logged from lastlog!

■chkrootkitの定期自動実行設定
rootkitを発見したときroot宛にメールが来るように設定

chkrootkitの実行スクリプトを作成
[root@linux ~]# vi /root/chkrootkit.sh
#!/bin/sh
/usr/bin/chkrootkit > /var/log/chkrootkit_log
grep "INFECTED" /var/log/chkrootkit_log
chmod 600 /var/log/chkrootkit_log
chkrootkitの実行スクリプトに実行権限を与える
[root@linux ~]# chmod 700 /root/chkrootkit.sh
cronを編集
[root@linux ~]# crontab -e
00 02 * * * /root/chkrootkit.sh
毎日2:00にchkrootkitの実行スクリプトを実行