連載

2004年1月21日

UNIXサーバの運用管理で欠かせないログ管理：止められないUNIXサーバのセキュリティ対策（7）（2/2 ページ）

[木村靖，三井物産GTI] PC用表示関連情報

LINE

Hatena

syslogの設定を見直す

　syslog.confの見直しといっても、それほど多いわけではない。むしろ最近のUNIXでは、デフォルトの設定でも問題ない場合がほとんどだ。しかし、それでもUNIXの種類によっては、セキュリティ監査などを行ううえで必要となる設定がされていないこともあるので、設定がない場合は追加することをお勧めする。

見直し1――auth（authpriv）のログをファイルに保存する

　システムによっては、認証に関するauth（authpriv）のログがファイルに保存されない。auth（authpriv）では、だれがいつログインを試みたなどの記録が保存されることから、syslog.confに設定がない場合は追加するようにしよう。

　例： facilityがauthおよびauthpriv、priorityがinfo以上のログを/var/log/authlogに保存する。

auth,authpriv.info /var/log/authlog

見直し2――514/udpによるログの受け取りを制限（syslogd）

　syslogでは、外部のサーバからネットワーク越しにログを受け取るために、syslogd起動時にデフォルトで514/udpをオープンする。しかし、その514/udpでは、特にアクセス制限が行われていないため、外部の攻撃者が514/udpに対して大量のパケットを送り込むことで、syslogサービスの異常停止（DoS）を狙った攻撃が可能となる。

　外部（インターネット）からの514/udpに対するアクセスをブロックしてあればひとまずは回避できるが、念には念をという意味で、サーバ自身で514/udpへのアクセスを制限することをお勧めする。特に、外部からのログを受け取らない場合は、514/udpをオープンする必要はない。

　最近のsyslogdには、514/udpを受け取る／受け取らないのオプションが指定可能となっているので指定するとよい。ただし、オプションを変更する場合は、syslogdの再起動が必要となるので、基幹サーバなどの場合は注意が必要となる。

FreeBSD、NetBSDの場合（-sを指定する）

　-sは、デフォルトで指定されているが、もし-sがない場合は指定する。指定する場合、syslogdをいったん停止し、以下を実行する。

# /usr/sbin/syslogd -s

　次回起動時も有効にする場合は、

/etc/rc.confに syslogd_flags="-s"

の1行を設定する必要がある。

Solarisの場合（-tを指定する）

　syslogdをいったん停止し、以下を実行する。

# /usr/sbin/syslogd -t

　次回起動時も有効にする場合は、/etc/rc2.d/S74syslog（実体は/etc/init.d/syslog）の以下の1行を変更する。

　変更前：

/usr/sbin/syslogd >/dev/msglog 2>&1 &

　変更後：

/usr/sbin/syslogd -t >/dev/msglog 2>&1 &

Red Hat Linuxの場合

　デフォルトでは514/udpをオープンしない。そのため特に変更の必要はないだろう。逆に-rオプションを指定すると、514/udpがオープンされる。

見直し3――Solarisのログイン認証とsuをsyslog経由にする

　Solarisでは、ログイン認証やsuのログをsyslog経由で出力する変数（SYSLOG）が用意されている。デフォルトではsyslog経由で出力されるが、念のために既存の環境において有効（YESが設定かつコメントアウトされていない）であることを確認しておく。

　また、loginでは、SYSLOG_FAILED_LOGINS変数を有効、suでは、SULOG変数も合わせて有効にしておくとよい。

/etc/default/login

SYSLOG=YES
SYSLOG_FAILED_LOGINS=3

/etc/default/su

SYSLOG=YES
SULOG=/var/adm/sulog

　両者ともFacilityがauth、Priorityがnotice、critのログが出力される。

　loginのSYSLOG_FAILED_LOGINS変数には、ログインの失敗回数の閾（しきい）値（上記の場合は3回）を設定することで、閾値を超えた場合にログに残すように設定できる。ただし、これをログに残す場合は、あらかじめ空の/var/adm/loginlogファイルを作成しておく必要がある＊5。

＊5
syslogの多くは、ログをファイルに格納する際、ファイルが存在しないと書き込まない。そのため、新たなログファイルへの設定を追加した場合は、kill -HUPする前に、今回のようにtouchコマンドで空のファイルを作っておく必要がある。

# touch /var/adm/loginlog
# chmod 600 /var/adm/loginlog

　/var/adm/sulogファイルも同様に作成しておく。

# touch /var/adm/sulog
# chmod 600 /var/adm/sulog

　telnetなどで、3回ログインに失敗すると、/var/adm/loginlogに以下のようなメッセージがたて続けに出力される。

kimu:/dev/pts/2:Thu Jan 13 20:52:24 2004
kimu:/dev/pts/2:Thu Jan 13 20:52:33 2004
kimu:/dev/pts/2:Thu Jan 13 20:52:39 2004

　また、/var/adm/sulogには、suを実行するたびに、以下のようなログが記録される。いつだれがsuを実行したのかが分かる。

SU 01/13 20:39 + pts/4 kimu-root
SU 01/13 20:44 + pts/1 yasushi-root

設定内容の確認（loggerコマンド）

　/etc/syslog.confの内容を実際に反映させたら、あとは本当に正しく反映されているかどうかを確認する必要がある。

　ログに出力されるのをじっと待つという手もあるが、そのために時間をつぶすのもばからしいので、そういった場合はloggerコマンドを利用するとよい。

　loggerコマンドは、多くのUNIXで標準インストールされており、任意のfacilityとpriorityを指定してログの出力を確認することができる。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　例：facilityがkern、priorityがinfoログレベルにメッセージ「koreha test desu」の文字列を出力する。

% logger -p kern.info "koreha test desu"

　kern.infoのデフォルトの出力先には、以下のようなログが記録される。

Jan 13 00:27:11 atmarkit kimu: koreha test desu

　今回は、syslogの基本と現状確認について説明した。次回は、ログサーバへの転送やセキュリティを考慮したsyslogソフトウェアの導入について説明する。

筆者紹介

三井物産GTI （現：三井物産セキュアディレクション株式会社）

木村靖

「次回」へ

「止められないUNIXサーバのセキュリティ対策」バックナンバー