logwatch でログの収集

2009/05/20（水） 00:46 ― taki

いよいよサーバの管理っぽくなってきた。 今回は　logwatch　のインストール。

インストールはいつもの

# aptitude install logwatch

設定ファイルの編集

# vi /usr/share/logwatch/default.conf/logwatch.conf

編集する部分は

# The default detail level for the report.
# This can either be Low, Med, High or a number.
# Low = 0
# Med = 5
# High = 10
Detail = Low

こいつを

Detail = Med

に変更するのみ。

これは好みで設定するように。

これで毎日飽きもしないでログをメールで送ってくれる。

異常を調べるには役に立ってくれるはず。

と書いたのであるが、メールの宛先も指定しないとダメだったりするので追記します。

# Default person to mail reports to.  Can be a local account or a
# complete email address.  Variable Print should be set to No to
# enable mail feature.
MailTo = root

この部分を適当なメールアドレスに変更しないといけない。 root宛のメールが自分のアドレスに送られる設定（/etc/aliasesの設定）になっていれば問題ないのですが、そうでない場合はそれなりにメールアドレスを指定すること。

普通はサーバをたててから　logwatch　を入れたりする。それももっともなこと。 がしかし、ポートを開けた瞬間から攻撃の対象となることを忘れてはならない。

話は脱線するが、複数のユーザでサーバを使用する場合、パスワードの管理には特に注意を要する。たった一人が単純なパスワードを使うだけで悪意を持った侵入者を許してしまう事になる。現在ではかつてのような、サーバに侵入してセキュリティホールを修正してくれるハッカーはまずいないと考えたほうが良い。サーバを公開する以上は確実に運営したいものです。パスワードのクラックで一番多いアタックは、ショルダーアタックだという話もある。これは、パスワードを入力するのをその肩越しに見るものである。セキュリティが崩れることの原因は人的なものが多いものです。

１年ほど前だったと思う。debianの大きなセキュリティ問題が発生した。OpenSSHの問題だった。それを私は放置していた。そんなある日、ユーザの　.bash_history　の異常に気がつく。そのユーザはシェルの使い方は知らないのである。

「あっやられた！」気づいた時には遅かったのである。

すぐにネットワークケーブルを抜いた。 そして、ログをいろいろ調べていると、侵入されたのはまだ昨晩のことだった。しかも、OpenSSHの問題では無く、ブルートフォースのパスワード総当たりの攻撃でやられていたようだ。ユーザのパスワードがユーザ名と同じという単純明快。 しかも、シェルの使い方も知らないユーザにシェルを開放している。 まるで、１０年以上前のプロバイダみたいなものだった。 そんなわけで、セキュリティには念には念を入れるということを忘れないで欲しい。

ログの管理は基本中の基本です。