Preface
”クラックされちゃったぁ。”と言うと笑い事ではない。俺自身経験があるが、あるサーバでどうもパフォーマンスが落ちたから調べてみよう。と思いリモートでサーバにアクセスしてlogを調べていたところ、侵入者と”ご対面～！”なんて言う間抜けな経験があった。びっくりである。何処から、どういう具合に進入してきたかは解らない。えてして、足跡を残さないのが侵入者である。そんなときは、直ぐさまネットワークケーブルを抜いて以下の事柄をチェックされたい。
１） 踏み台にされていないか？
２） ファイルを改ざんされていないか？
３） バックドアを仕掛けられてないか？
４） システムファイルが消されてないか？
５） アカウントを作成されていないか？
６） コマンドモジュール達が改竄されていないか？
そんでもって、一応現在のシステムを捨ててHDDをFormatし直して再インストールを実行。そして、脆弱性（ぜいじゃくせい）がありそうなサービスモジュールにパッチを当てた（BIND等）。それ以降、このようなことはなくなったが、こんな事が有ってからセキュリティには今まで以上に配慮するようになった。私的には、リモートサービスも、telnetはもちろんSSHも外部からアクセスできないようにしておいた方が効果的。さらに、TCP_Wapperを仕掛けるようにしよう。
セキュリティは、”ファイアウォールが有るから安心！”と言うことは決して無い。有るはずがない。クラッカー達は弱いところから攻めてくる。ポートスキャン（開いてるポートを調べる行為）を行い、狙いをつけたサーバのスキャンを試みる。それで、開いてるポートにアタック（攻撃）と言って弱そうなサービスを狙って攻撃を仕掛ける。ポートとはご存じのように、Unixのサービスが動いているかどうかの証拠になる番号である。ポートが開いていると言うことは、そのポートに対応するサービスが確実に動いていると言うことである。格闘技は、相手が弱っているところを突いて、相手を倒すのも卑怯ではあるが行われている。クラッカーも脆弱性を突く卑怯な方法を沢山使って、相手のサーバに攻撃および侵入を仕掛けるのだ。
昨今、クラッキングだけではなく、ウィルスというやっかいな代物も猛威をふるっている。怖いのは、自分の鯖が”踏み台”にされることである。NimdaやCodeRedなどは、サーバを寄生媒体として、他のサーバに攻撃を仕掛ける。最悪のウィルスである。こいつらに見る悪行は、今後のウィルスが如何にものすごい物かを物語っている。それらに対処するには、われわれが正しい知識で自分の身を守らなければならない。
１．日頃のサーバ管理
１）日頃のサーバ管理はもちろん大切である。これだけは俺の場合行っている。是非にあなたも参考にされたい。
① バックアップ
大切なファイルのバックアップ。
システムは、いつでも復旧できるが、個人のファイルは復旧できないので必須である。
例えば、DBのバックアップなどである。
注：
ただし、侵入の痕跡が解りバックドア及び改竄が確認されたモジュールが見つかったとき、そのバックアップデータも怪しいのでくれぐれも注意が必要である。
② logの監視
syslogの中の、messageはもちろんのこと、maillog、cron等も監視しておくと良い。
さらに、apacheのaccess_logも監視すべきであろう。logの見方は、 ここ を参考に。logの見方が解らなければまともな管理は出来ないと心得よ！
③ プロセスの確認
psコマンドで、見たことのないプロセスや見たことのないperlスクリプトが走ってないかを調べる。
# ps axw | more
PID TTY STAT TIME COMMAND
1 ? S 0:00 init [2]
2 ? SN 0:00 [ksoftirqd/0]
3 ? S< 0:00 [events/0]
4 ? S< 0:00 [khelper]
5 ? S< 0:00 [kblockd/0]
6 ? S 0:00 [khubd]
22 ? S 0:00 [pdflush]
23 ? S 0:00 [pdflush]
25 ? S< 0:00 [aio/0]
24 ? S 0:00 [kswapd0]
107 ? S 0:00 [kseriod]
416 ? Ss 0:00 /sbin/syslogd
419 ? Ss 0:00 /sbin/klogd
424 ? Ss 0:00 /usr/sbin/named -c /etc/bind/named.conf -u bind
448 ? S 0:00 /bin/sh /usr/bin/mysqld_safe
484 ? S 0:00 /usr/sbin/mysqld –basedir=/usr –datadir=/var/lib/mysql –user
=mysql –pid-file=/var/run/mysqld/mysqld.pid –skip-locking –port=3306 –socket=/var/run/
mysqld/mysqld.sock
485 ? S 0:00 logger -p daemon.err -t mysqld_safe -i -t mysqld
517 ? SLs 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid
613 ? Ss 0:00 /usr/lib/postfix/master
620 ? S 0:00 qmgr -l -t fifo -u
632 ? Ss 0:00 /usr/sbin/atd
635 ? Ss 0:00 /usr/sbin/cron
653 ? Ss 0:00 /usr/local/pgsql/bin/postmaster -S -i -D /usr/local/pgsql/data
662 ? S 0:00 postgres: stats buffer process
663 ? S 0:00 postgres: stats collector process
687 ? Ss 0:00 /usr/local/apache/bin/httpd
692 ? S 0:00 /usr/local/apache/bin/httpd
693 ? S 0:00 /usr/local/apache/bin/httpd
694 ? S 0:00 /usr/local/apache/bin/httpd
695 ? S 0:00 /usr/local/apache/bin/httpd
696 ? S 0:00 /usr/local/apache/bin/httpd
697 ? Ss 0:03 /usr/local/sbin/sshd
700 tty1 Ss+ 0:00 /sbin/getty 38400 tty1
702 tty2 Ss+ 0:00 /sbin/getty 38400 tty2
703 tty3 Ss+ 0:00 /sbin/getty 38400 tty3
2682 ? S 0:00 /usr/local/apache/bin/httpd
2683 ? S 0:00 /usr/local/apache/bin/httpd
2684 ? S 0:00 /usr/local/apache/bin/httpd
2685 ? S 0:00 /usr/local/apache/bin/httpd
2687 ? S 0:00 /usr/local/sbin/sshd
2689 pts/1 Ss 0:00 -bash
2692 pts/1 S 0:00 -su
2721 ? Ss 0:00 /usr/sbin/inetd
3475 ? S 0:00 pickup -l -t fifo -u
4148 pts/1 R+ 0:00 ps axw
4149 pts/1 S+ 0:00 more
④ ログイン状況の確認
logでも確認できるが、lastコマンドでログインユーザを調べる。
# last
hoge pts/1 192.168.255.121 Sun Feb 6 17:21 still logged in
hoge pts/0 192.168.255.152 Sun Feb 6 15:28 – 17:29 (02:00)
reboot system boot 2.6.8 Sun Feb 6 15:27 (04:36)
hoge pts/0 192.168.255.152 Sun Feb 6 09:22 – down (06:03)
hoge pts/0 192.168.255.121 Sat Feb 5 22:49 – 22:51 (00:01)
hoge pts/0 192.168.255.152 Sat Feb 5 22:37 – 22:47 (00:09)
hoge pts/0 192.168.255.161 Sat Feb 5 13:29 – 21:21 (07:52)
hoge pts/0 192.168.255.161 Sat Feb 5 13:24 – 13:26 (00:01)
hoge pts/0 192.168.255.161 Sat Feb 5 11:01 – 13:18 (02:16)
hoge pts/0 192.168.255.161 Wed Feb 2 22:00 – 00:17 (1+02:16)
root tty1 Wed Feb 2 21:59 – 22:32 (00:32)
reboot system boot 2.6.8 Wed Feb 2 21:58 (3+17:27)
hoge pts/1 192.168.255.161 Wed Feb 2 21:08 – down (00:47)
⑤ ネットワークセッションの確認
# netstat -n -l | less
0 127.0.0.1:10025 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:514 0.0.0.0:*
raw 0 0 0.0.0.0:1 0.0.0.0:* 7
raw 0 0 0.0.0.0:6 0.0.0.0:* 7
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
unix 0 [ ACC ] STREAM LISTENING 550 private/smtp-amavis
unix 0 [ ACC ] STREAM LISTENING 571 /tmp/.s.PGSQL.5432
unix 0 [ ACC ] STREAM LISTENING 599 /var/run/clamav/clamd.sock
unix 0 [ ACC ] STREAM LISTENING 611 /var/amavis/amavisd.sock
unix 0 [ ACC ] STREAM LISTENING 478 private/rewrite
unix 0 [ ACC ] STREAM LISTENING 482 private/bounce
unix 0 [ ACC ] STREAM LISTENING 486 private/defer
unix 0 [ ACC ] STREAM LISTENING 471 public/cleanup
でLISTENポートの確認を行う。しかし、lsofというコマンドを使って確認する方が解りやすいかもしれない。lsofは ここ を参照すれば細かい使い方が解る。以下のようにLISTENのみの状態がgrepを使うだけで出力できる。
# lsof -i | grep LISTEN
named 424 bind 21u IPv4 765 TCP sub2.kozupon.com:domain (LISTEN)
named 424 bind 23u IPv4 767 TCP localhost.localdomain:domain (LISTEN)
named 424 bind 25u IPv4 776 TCP localhost.localdomain:953 (LISTEN)
master 613 root 11u IPv4 1060 TCP *:smtp (LISTEN)
postmaste 653 postgres 3u IPv4 1244 TCP *:postgresql (LISTEN)
httpd 687 root 16u IPv4 1283 TCP *:www (LISTEN)
httpd 692 nobody 16u IPv4 1283 TCP *:www (LISTEN)
httpd 693 nobody 16u IPv4 1283 TCP *:www (LISTEN)
httpd 694 nobody 16u IPv4 1283 TCP *:www (LISTEN)
httpd 695 nobody 16u IPv4 1283 TCP *:www (LISTEN)
httpd 696 nobody 16u IPv4 1283 TCP *:www (LISTEN)
sshd 697 root 3u IPv4 1301 TCP *:ssh (LISTEN)
httpd 2682 nobody 16u IPv4 1283 TCP *:www (LISTEN)
httpd 2683 nobody 16u IPv4 1283 TCP *:www (LISTEN)
httpd 2684 nobody 16u IPv4 1283 TCP *:www (LISTEN)
httpd 2685 nobody 16u IPv4 1283 TCP *:www (LISTEN)
このようにいずれかのコマンドで、見たこと無いセッションが立ち上がっていないかを確認する。
さらに、プロミスキャスモード（ネットワーク上のパケットを自分宛以外のものも受け取ってしまうお構いなしモード）になっていないか確かめる。このモードになっていると、Sniffer等のネットワークモニタで通信の傍受をされている恐れがあるので気をつける。プロミスキャスモードは、tcpdumpコマンドするとプロミスキャスモードに移行する。したがって、tcpdumpコマンドを使った後はプロミスキャスモードの解除を忘れずに！
ちなみに、プロミスキャスモードへのセット・リセットは以下のようにする。
■ プロミスキャスモードセット
# ifconfig eth0 promisc
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:90:CC:A0:24:49
inet addr:192.168.255.103 Bcast:192.168.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:47264 errors:0 dropped:0 overruns:0 frame:0
TX packets:21126 errors:0 dropped:0 overruns:0 carrier:0
collisions:3254 txqueuelen:1000
RX bytes:32903744 (31.3 MiB) TX bytes:2549719 (2.4 MiB)
Interrupt:10 Base address:0xe000
以下省略
■ プロミスキャスモードリセット（解除）
# ifconfig eth0 -promisc
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:90:CC:A0:24:49
inet addr:192.168.255.103 Bcast:192.168.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:47289 errors:0 dropped:0 overruns:0 frame:0
TX packets:21137 errors:0 dropped:0 overruns:0 carrier:0
collisions:3254 txqueuelen:1000
RX bytes:32905812 (31.3 MiB) TX bytes:2551653 (2.4 MiB)
Interrupt:10 Base address:0xe000
以下省略
⑥ まるっきり処女のコマンドを初っぱなに用意しておく
初めて、OSをインストールするときに検査に必要なコマンド群のオリジナルをFDD等の記録メディアに作っておく。
クラックな方に侵入されて、改ざんされたコマンドは後でサーバ内をチェックしたときに正当性が無いからだ。
例えば、
w
last
ps
netstat
grep
find
strings
などで十分だろう。 これらを侵入された形跡があったときに活用すると良いだろう。
⑦ モジュールのアップデート
セキュリティアップデートおよびモジュールのアップデートを確実に行うこと。
ソースはもちろんのこと、バイナリもパッケージ管理システムを旨く利用して定期的にfetchすると良いだろう。さらに、セキュリティ勧告に気を配っておくこと。いち早く脆弱性の情報をつかむことが大切だと思う。
２）おかしいなぁ～。と思うとき
① psコマンドでサービスの状況を調べているとき、訳の解らないサービスが立ち上がってる。
② 最近、BINDが良く落ちる。もしくはOS、他のサービスが良く落ちる。特定サービスに影響が出てる場合。
③ 最近、サーバのアクセスが遅い。もしくは、重い感じがする。遅延やパケットロスが増加している。一時的なサーバのトラブルと思い見逃さないこと。
”ファイアウォールがクラッカーの侵入を防いでくれる”と言うのは過信した大きな間違いである。
さらに、telnetやrshだけ塞いでおけば、内部のマシンの遠隔操作はできないだろうと考えている方がいるならば、考えを変えた方が無難である。
例えば、②の場合などBINDの脆弱性を狙った攻撃の可能性がある。過去に発売された、RedHatLinux6.2(ZOOT)、カーネル2.2.14-5.0、BIND 8.2.2P5は、脆弱性のバグがあるバージョンでした。ゾーン転送を目的として53番ポートのみを開けているだけで、侵入され好き勝手にされてしまう。侵入に失敗したり、相手側でセッションを切ったりするとBINDは落ちる。このようなことから、最近”BINDが良く落ちるなぁ～。”と感じてる人は、クラッキングを疑った方が良い。
２．侵入されちゃったぁ～！
１）侵入を発見したら
① ネットワークケーブルをマシンから外す。おっと、その前に、 ここ を読もう。
侵入が確認されたら、あわてずネットワークケーブルをまずはサーバから外すことである。
自分が困るなら、まだしも踏み台にされて、他のサーバに被害を与えてる可能性もあるからである。このとき、間違ってもマシンをリセットしないこと。侵入時の足跡が残っているかもしれないのでそれを消してしまっては、もともこもない。
② 被害状況の確認（チェックチェック）
● 必要ファイルが改ざんされていないか？
● バックドアは仕込まれていないか？
● 余計なアカウントが作成されていないか？
③ ログ及び必要ファイルの確認
だいたい、間抜けなクラッカー以外は足跡なんか残さない物である。プロの泥棒が証拠を残さず立ち去るのと同じである。しかし、一応logファイルは確認したほうがよい。あとは、最終ログイン状況等の確認。ほとんどの場合は相手を特定することは出来ないと思って間違いはない。あと、どんな方法で侵入したかも調べておくべきである。痕跡を発見したら、ログのバックアップをとっておき、いつでも見れる状態にしておく。
２）具体的な被害を検査する
１項の１）の⑥で作った処女コマンドFDDを使ってチェックを始める。
① scriptコマンドを使ってこれから行う一連の操作をレコーダー（記録）する
# script /tmp/check.log
なんてファイルを適当なフォルダに作って記録を始める。終了時には、exitで終了する。
② lastコマンドを使ってログインした痕跡を調査
# last
③ wコマンドを使って今ログインしてる形跡を調査
# w
④ psコマンドで不審なプロセスの確認
特に怪しいスクリプトが立ち上がってないか？
# ps axw | more
⑤ 不審なLISTEN PORTの確認
# netstat -an
# lsof -i | grep LISTEN
⑥ ファイルのタイムスタンプの確認
ファイルのタイムスタンプの一覧をゲット出来るモジュール mac-robber と一覧中でタイムスタンプの範囲を絞り込む mactime のようなツールを使う。
例えば、以下のようにして / 領域の全てのファイルのタイムスタンプをゲットする。mac-robbitとmactimeの詳細は、 ここ を参照。
まずは、mac-robbitで/領域のバイナリ＆テキストファイルinfoを全てゲットする。
# mac-robber / > /tmp/mac_time.log
mac_time.logファイルの日付をmactimeで絞り込む。
# /usr/local/sleuthkit/bin/mactime -b /tmp/mac_time.log 01/30/2005 > timeline.01-30-2005-1
⑦ 不振なモジュールをチェック
setuidされてるファイルを出力する。以下のコマンドで ls -alで一覧を出したように出力されるので見やすいかも。
# find / -perm +4000 -uid 0 -exec ls -al ‘{}’ \;
もしくは、
# find / -type f \( -perm -u+s -o -perm -g+s \) -exec ls -al ‘{}’ \;
-rwsr-xr-x 1 root root 38188 Sep 13 2001 /usr/bin/chage
-rwsr-xr-x 1 root root 40356 Sep 13 2001 /usr/bin/gpasswd
-r-xr-sr-x 1 root tty 8112 Sep 12 2001 /usr/bin/wall
-rwsr-xr-x 1 root root 36164 Sep 12 2001 /usr/bin/at
-r-sr-x— 1 root news 30884 Sep 12 2001 /usr/bin/inndstart
-r-sr-x— 1 uucp news 80552 Sep 12 2001 /usr/bin/rnews
-r-sr-x— 1 root news 26412 Sep 12 2001 /usr/bin/startinnfeed
-rwsr-xr-x 1 root root 24080 Sep 13 2001 /usr/bin/crontab
-rwsr-xr-x 1 root root 14156 Sep 14 2001 /usr/bin/fld
-rwsr-xr-x 1 root root 48488 Sep 14 2001 /usr/bin/kon
-rwsr-xr-x 1 root root 238484 Sep 14 2001 /usr/bin/newvc
-rws–x–x 2 root root 555380 Sep 12 2001 /usr/bin/suidperl
-rws–x–x 2 root root 555380 Sep 12 2001 /usr/bin/sperl5.00503
-r-sr-sr-x 1 root lp 18552 Sep 12 2001 /usr/bin/lpq
-r-sr-sr-x 1 root lp 21336 Sep 12 2001 /usr/bin/lpr
-r-sr-sr-x 1 root lp 18992 Sep 12 2001 /usr/bin/lprm
-r-s–x–x 1 root root 14684 Sep 12 2001 /usr/bin/passwd
-rws–x–x 1 root root 16184 Sep 13 2001 /usr/bin/chfn
-rws–x–x 1 root root 15896 Sep 13 2001 /usr/bin/chsh
-rws–x–x 1 root root 5780 Sep 13 2001 /usr/bin/newgrp
-rwxr-sr-x 1 root tty 10696 Sep 13 2001 /usr/bin/write
-rwxr-sr-x 1 root mail 14660 Sep 12 2001 /usr/bin/lockfile
-rwxr-sr-x 1 root slocate 23536 Sep 13 2001 /usr/bin/slocate
—s–x–x 1 root root 84680 Sep 13 2001 /usr/bin/sudo
-rwsr-xr-x 1 pop root 29832 Jan 4 2004 /usr/local/sbin/popauth
-rwsr–r– 1 root bin 48961 Sep 12 2001 /usr/sbin/apcd
-rwsr-xr-x 1 root root 6052 Sep 12 2001 /usr/sbin/usernetctl
-rwxr-sr-x 1 root lp 28204 Sep 12 2001 /usr/sbin/lpc
-rwxr-sr-x 1 root maildrop 339544 Sep 13 2003 /usr/sbin/postdrop
-rwxr-sr-x 1 root maildrop 302993 Sep 13 2003 /usr/sbin/postqueue
-rwsr-xr-x 1 root root 142972 Sep 12 2001 /usr/sbin/ppxpd
-rwsr-xr-x 1 root root 19992 Sep 13 2001 /usr/sbin/traceroute
-rwsr-xr-x 1 root root 22492 Sep 13 2001 /usr/sbin/userhelper
-rwxr-sr-x 1 root utmp 8116 Sep 13 2001 /usr/sbin/utempter
-rwsr-xr-x 1 root root 34868 Aug 9 2001 /usr/libexec/pt_chown
-rws–x–x 1 root root 162212 Aug 19 2002 /usr/libexec/openssh/ssh-keysign
-rwsr-xr-x 1 root root 14644 Sep 13 2001 /bin/su
-rwsr-xr-x 1 root root 23728 Sep 12 2001 /bin/ping
-rwsr-xr-x 1 root root 66768 Sep 12 2001 /bin/mount
-rwsr-xr-x 1 root root 30224 Sep 12 2001 /bin/umount
-rwxr-sr-x 1 root root 5744 Sep 12 2001 /sbin/netreport
-r-sr-xr-x 1 root root 45414 Sep 12 2001 /sbin/pwdb_chkpwd
-r-sr-xr-x 1 root root 46442 Sep 12 2001 /sbin/unix_chkpwd
タイムスタンプが最近で、見たことのない（；￢＿￢） ぁ ゃι ぃファイルは、以下fileコマンドとstringsコマンドで大体のファイルの内容を調査することをお勧めする。
# file < あやしいファイル名 >
# strings < あやしいファイル名 >
⑧ 今度はrootkitを見つける
rootkitっていうクラックツールを仕掛けられてないか見つける。chkrootkitというモジュールを使う。詳しくは、 ここ を参照
# chkrootkit
このくらいやれば被害状況が解ると思う。ただ、これだけやれば確実だ！と言うことは無いので了解願いたい。
あくまでも、直ぐに検査できることを記述したまでのこと。
３）復旧と対策
① モジュールのパッチもしくはバージョンアップ
明らかに、脆弱性を突いて侵入したことが解る場合、そのターゲットになったサービスにパッチを当てて対処する。もしくは、新しいバージョンにバージョンアップする。
また、それが不要なサービスなら止めるかアンインストールする。
② システムの見直し
脆弱性モジュールがわかっても、この際システム全体の見直しをすべきである。
脆弱性の問題を含んだモジュールは一つではないかもしれない。
OSも含めて、最新バージョンへのアップデートを考えた方が良いと考える。
③ システムの再インストール（初心者にはこれしかないと思いまふ）
これは、あくまでも俺の主観だが、２）で被害状況が解ったら余計なことを考えずHDDのフォーマットから再インストールをお勧めする。間違ってもバックアップのリストアなんて考えないことだ、なぜなら過去のバックアップデータも侵入された後のデータかもしれないからだ！それを、リストアしたらまた侵入されてしまうではないか。
３．日頃からの準備
１項でのサーバの管理に加えて、日頃から万が一のために準備しておいた方が、いざというときの復旧が早くなる。特に、小生はバックアップサーバの準備が一番と考える。
① 現在、使っているメインサーバと同じサーバをもう一台あらかじめ用意しておく。
② ①のサーバはネットワークに参加させずに、保管しておく。
③ 現状のサーバが侵入された場合、原因を究明して、対策をバックアップサーバに反映することを忘れずに。
④ バックアップサーバを本サーバに変更して、ネットワークに参加させる。
⑤ 侵入されたサーバをバックアップサーバにするため、HDDフォーマットして再フルインストールする。
このようにしておけば、復旧も早いであろう。
いずれにしても、声を大にして言いたいのだが、初心者の方にはバックアップサーバを必ず用意していただきたい。たぶん、後で”良かった(^o^)！”と思うに違いない。多少費用はかかるが、お金には変えられない物があるのではないだろうか。
４．ウィルス、ワームに対しての対策
ウィルス、ワームに対しての対策としては、やはり、ウィルスソフトをサーバに仕掛けるべきである。 手前みそだが、当HPの” 技術の部屋 ”で紹介しているウィルスソフトなどいかがだろう？（ 掲載情報 参照）
特に、最近のウィルスはワーム型になっており、メールとして配信される。したがって、本来メールサーバのsmtpポートで監視して、ブロックするのが一番ベストである。上記の掲載情報の中の sophos社 では、smtp監視ウィルスソフトも発売している。その他に、ウィルスブロッカーでAmavisと言うモジュールも効果的である。やはりSophos社のAntiVirusを利用するのだが、Perlスクリプトで書かれている。詳しいことは、 ここ（AMaViSを使ってウィルスフィルタをかける！） で小生が書いている。一見してほしい。
sambaを使ってファイルサーバを構築している方は、クーロンで毎日、重要必要なフォルダをスキャンすることをお勧めする。定義ファイルの更新が少々面倒だが、備えあれば憂いなしである。
以上
コメント