4.1 OSのセキュア化
前のページへ
次のページへ

4.1.2 セキュア化のための設定

システムをさまざまな脅威から保護するには、システムの設定をセキュアに変更したり、セキュリティ対策機能を追加したりするなどの作業が必要になる。このようなセキュア化を実施しないと、「3.2.3 セキュリティ脅威の洗い出しと評価」で解説したようなセキュリティ脅威にさらされることになる。

このような脅威からシステムを保護するために行う作業を、本モデルでは「セキュア化」と呼び、次のような作業を行いシステムのセキュア化を実施する。

なお、本モデルでは、セキュア化の作業を、「Solaris 8 10/01」を「core systemクラスタ」でインストールしたホストを対象とし解説を行う。

1) rootのホームディレクトリの変更

ホームディレクトリとは、ユーザ毎に割り当てられる作業用ディレクトリであり、ユーザは自身のホームディレクトリで、ファイルやディレクトリの作成、変更、削除が自由に行える。OSインストール後rootのホームディレクトリは「/(ルート)」(注1)に設定されており、この状態では、rootの作業ディレクトリが「/(ルート)」であるため、操作ミスなどにより「/(ルート)」配下にある重要なファイルを削除してしまう危険性がある。このようなリスクを最小限にするため、rootのホームディレクトリを「/」から「/root」に変更する。これにより、影響を及ぼす範囲を「/root」に限定することができる。

  (注1) 「/(ルート)」はUNIX系OSにおいて、全てのディレクトリ、ファイルがマウントされる重要な領域である。  

ア) ホームディレクトリ作成

# mkdir /root          #ディレクトリ作成
# chown root:root /root    #オーナー/グループの変更
# chmod 700 /root       #パーミッションの変更

イ) rootのホームディレクトリを変更

「/etc/passwd」ファイルを編集してrootのホームディレクトリを変更する。編集する際は、OSをSingle User Modeで起動して編集する。

---編集前---
root:x:0:1:Super-User:/:/sbin/sh

---編集後---
root:x:0:1:Super-User:/root:/sbin/sh

2) サービスのセキュア化

サービスとは、サーバーがクライアントまたはユーザに対して提供するさまざまな機能を指す。これらのサービスは内部、あるいは外部のネットワークに対してオープンなアクセスを提供していることが多い。オープンなアクセスとは、サービスがネットワークを介してあらゆるアクセスを受け入れている状態であり、常にセキュリティの脅威にさらされている。また、たとえアクセス時に認証システムを持っているサービスであったとしても、設定ミスによって認証が正常に実施されなかったり、認証時のユーザ名とパスワードが平文で送受信されるなどの脆弱性が存在する場合がある。よって、システムのサービス提供数が増加すると、システムが不正アクセスにより被害を受ける可能性はサービス提供数に比例するように飛躍的に高くなってしまう。

そこで、本モデルでは、次のような作業によって、サービスのセキュア化を行い、システムのセキュリティ強度を高める。

本モデルでは、以下のア)からウ)の手順でOSの正常な動作に影響のない不要なサービスを全て停止して、サービスの最小化を実現する。また、以下のエ)の手順で、設定によって選択的(許可/不許可)にネットワークアクセスを受け入れる方法としてOSにパケットフィルタリング機能を追加し、全てのネットワークアクセスを遮断し、必要なネットワークアクセスのみを許可する設定を行う。

Solaris 8において、OS起動時に提供されるサービスはinetd(Internet Daemon)と/etc/rc2.d、/etc/rc3.dディレクトリ下の起動スクリプトによって管理されている。inetdによるサービスの自動起動を停止するには、設定ファイルである/etc/inetd.confを編集する。また、/etc/rc2.dと/etc/rc3.dディレクトリ配下に存在する起動スクリプトで起動するサービスを停止するには、対象起動スクリプトファイルのファイル名を変更することで可能である。

ア) /etc/inetd.confの設定

All Denialの状態にするため、inetd経由で起動されるサービスをすべて無効にする。サービスを無効にするには、設定ファイルの各サービス起動設定行をコメントアウト(「#」を行頭に付加する)する。

---有効の場合---
telnet stream tcp nowait root /usr/sbin/in.telnetd

---無効の場合---
#telnet stream tcp nowait root /usr/sbin/in.telnetd

イ) /etc/rc2.dの設定

/etc/rc2.dディレクトリ下の各ファイルは、サービスあるいはアプリケーションの起動スクリプトである。これらのスクリプトファイルは先頭が「S」または「K」で始まるファイル名であり、それぞれ異なる意味を持っている。「S」はサービスの開始を意味し、「K」はサービスの停止または強制終了を意味している。必要でないサービスやアプリケーションは、起動スクリプトファイルのファイル名を変更することで自動起動を停止することが可能である。

本モデルでは、運用上不必要な起動スクリプトファイル名の先頭に「.(ドット)」を付けて、「S」から実行されないように設定し、サービスの無効化を実施する。以下に、「S20sysetup」を無効化する例を示す。

# mv S20sysetup .S20sysetup

/etc/rc2.dディレクトリでは、Table 4.5に示した起動スクリプト以外は上記のような方法ですべて無効化する。

Table 4.5 /etc/rc2.dディレクトリで起動を許可する起動スクリプト

使用するサービスの起動スクリプトファイル名
S01MOUNTFSYS
S05RMTMPFILES
S30sysid.net
S69inet
S71sysid.sys
S72inetsvc
S74syslog
S75cron
S80PRESERVE
S88utmpd
S99audit

ウ) /etc/rc3.dの設定

「イ) /etc/rc2.dの設定」と同様の方法で、Table 4.6に示した起動スクリプトをすべて無効化する。

Table 4.6 /etc/rc3.dディレクトリで無効化する起動スクリプト

無効化するサービスの起動スクリプトファイル名
S15nfs.server

sadmind/IISワーム

2001年5月に、sadmind/IISワームと呼ばれるワーム発見され、多くのインターネットサーバーに被害をもたらした。このワームはSolarisとWindows IISが稼動するシステムが感染対象となり、脆弱性を抱えるサービスを起動しているサーバーは、Webページの改ざんやバックドアの設置などの被害を受けてしまう。このワームは、不要なサービスの提供していたり、デフォルト設定のままでシステム運用をしていた多くのサーバーに被害を与えた1つの事例である。

ベンダーからリリースされているパッチを導入することで、このワームへの対策が可能である。各ベンダーのパッチ入手先と情報を下記に記す。

 Solaris
  Security Bulletin #00191
  「sadmind バッファオーバーフロー」:
   http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&doc=secbull/191&type=0&nav=sec.sba

 Windows
  Microsoft Security Bulletin MS00-078
  「Web サーバー フォルダへの侵入」の脆弱性に対する対策」:
   http://www.microsoft.com/japan/technet/security/prekb.asp?sec_cd=MS00-078

 CERT Advisory CA-2001-11
 「sadmind/IIS Worm」:
   http://www.cert.org/advisories/CA-2001-11.html


 情報処理振興事業協会 セキュリティセンター(IPA/ISEC)
 「ワームsadmind/IISによるWeb改ざんインシデントの対策について」:
   http://www.ipa.go.jp/security/ciadr/200105sadmindiis.html

 

エ) ip filterによるパケットフィルタリング

システムにアクセス制御機能を追加するには、いくつかの方法がある。そのひとつの方法が、パケットフィルタリングである。パケットフィルタリングとは、送信元ホストや送信先ホストのIPアドレス、ポート番号、パケットの方向などを組み合わせて、フィルタを設定し、ネットワークを出入りするパケットのアクセス制御(通過または遮断を判断)を行うことである。本モデルではip filterを使用してパケットフィルタリング機能を実現する。ip filterはカーネルのモジュールとして機能し、システムそのものが停止しない限りパケットフィルタリングが有効となるため、他のパケットフィルタリングツールに比べ安全性が高い。

ip filterの設定内容(フィルタリング設定)は、/opt/ipf/ipf.confファイルを作成して記述する。

本モデルでは、Table 4.7の方針に基づきパケットフィルタリングを設定する。これは、本モデルのWebサーバー(Apache/Solaris)を対象とした設定例で、Webサービス用にHTTP(80/TCP)とHTTPS(443/TCP)、コンテンツアップロード用にFTP(20、21/TCP)(注2) 、時刻問い合わせ用にNTP(123/UDP)通信、リモート管理用にSSH(22/TCP)通信を特定条件下で許可し、それ以外の通信を拒否する設定である。フィルタリングの内容はシステムの運用環境によって異なってくるので、他のサーバーでip filterを提供する場合には、フィルタリングの内容を変更する必要がある(注3)

また、フィルタリングを設定しない状態の場合、ip filterは全ての通信を許可する状態になるので、必ずデフォルトで全てのパケット送受信を禁止する設定を行なう。

  (注2) ここでは、Webコンテンツのアップロードを行うために、FTPを利用することを前提とする。Webコンテンツをアップロードするには、FTP以外にもいろいろな方法が存在しており、この詳細に関しては、「7. セキュアなWebコンテンツアップロード」を参照する。  
  (注3) ip filterでは、パラメータを使用して柔軟なフィルタリングが設定できる。例えば、外部ネットワークからのプライベートアドレス(IP Spoofing)やマルチキャストの遮断など。これらは、セキュリティ対策上、必須の設定とも考えられるが、本モデルではこれらのフィルタリングをファイアウォールで実施するものとし、ip filterでの設定は実施しない。  

Table 4.7 フィルタリングの設定方針

対象サービス 設定するフィルタの内容
デフォルト受信拒否 デフォルトですべてのパケット受信を拒否する
デフォルト送信拒否 デフォルトですべてのパケット送信を拒否する
WWW 不特定ホストからのWWWサービスへのアクセス(80、443/TCP)を許可する
NTP NTPサーバーとの時刻問い合わせアクセス(123/UDP)を許可する
FTP Webコンテンツアップロード用に特定のホストからのFTPアクセス(20、21/TCP)を許可する
SSH リモート管理用に特定ホストからのSSHアクセス(22/TCP)を許可する

フィルタリングの主なパラメータの内容はTable 4.8に示す。

Table 4.8 ip filterのパラメータ

パラメータ 内容
block 通信拒否
pass 通信許可
in 受信:フィルタに一致した通信のログを記録したい場合は in log
out 送信:フィルタに一致した通信のログを記録したい場合は out log
on x フィルタを適用するインターフェース名:xにインターフェース名を指定
proto x protocol typeの指定:xはtcp,udp,icmp,allのいずれかを指定
from x1 port=p1 to x2 port=p2 フィルタの対象ホスト、ポート番号を指定:x1,x2にはホストのIPアドレス、またはネットワークアドレスを記述する。全てのホストを対象とする場合はanyと記述する。p1,p2にはポート番号を記述する。特にポート番号を指定しない場合は記述しなくても良い
icmp-type proto icmpとした場合のicmpの種類を指定:echo,echorep,unreachなど
keep state 設定したフィルタに一致した通信に関係する通信全てにフィルタを適用
flags proto tcpの場合にtcp header flagの内容を指定。指定しなくても良い
head x xで指定した番号でフィルタリンググループを作成し、そのフィルタを作成したグループのデフォルトフィルタとする。headパラメータを指定しないフィルタはデフォルトグループ(グループ0)にグルーピングされる
group x xで指定した番号のフィルタグループにグルーピングする。groupパラメータを指定しないフィルタはデフォルトグループ(グループ0)にグルーピングされる
quick quickパラメータを指定したフィルタに一致した通信は、それ以降のフィルタを適用しない

上記の設定方針を基に設定した内容は、ipf.confのとおりである。また、この設定は以下のようなネットワーク環境に基づき実施する。

192.168.0.1:WebサーバーのIPアドレス
if0:Webサーバーのネットワークインターフェース名
192.168.0.10:Webコンテンツアップロードホスト(ステージングサーバー)のIPアドレス
192.168.0.20:リモート管理用ホストのIPアドレス
192.168.0.123:NTPサーバーのIPアドレス

ip filterのログ出力は、syslog.confファイルにip filter用のログ出力設定を追加することで可能である。ip filterはデフォルトの場合、syslogのfacility「local0」を使ってログを出力し、メッセージのレベルはsyslogに備わっているpriorityで設定することができる。本モデルでのip filterのログ出力設定は、以下のとおりである。

---ip filterのログ出力設定(抜粋)---
---/etc/syslog.confの一部---
#
#ip filterのログを/var/log/ipflogに出力
#
local0.debug    ifdef(`LOGHOST', /var/log/ipflog, @loghost)

また、出力先のログファイルは手動で作成しておく必要があるため、以下のようにしてログファイルを作成する。その後、設定を反映させるためにsyslogデーモンを再起動する。

---/var/log/ipflogの作成---
# touch /var/log/ipflog

---syslogdの再起動---
# sh /etc/rc2.d/S74syslog stop
syslogd going down on signal 15
# sh /etc/rc2.d/S74syslog start
syslog service starting.

上記の設定方針を基に設定した内容は、syslog.confのとおりである。なお、syslogの設定に関しては、「7) ログ出力の設定」を参照する。

3) PAM(Pluggable Authentication Module)の設定

Solaris2.6以降では、PAM(Plugable Authentication Module)と呼ばれる統合された認証モジュールを採用している。Solarisでは、PAMによって認証やアカウント管理、セッション管理、パスワード管理の機能をモジュール形式で一括管理することができる。

Solarisのデフォルトインストールの状態ではrshやrloginなどのPAM設定が、セキュリティ上好ましくないログイン方法に設定されているので、本モデルでは、PAMの設定を変更して、セキュリティ上好ましくないログイン方法を無効化する。なお、この作業で無効にするログイン方式の代わりに、より安全なログイン方法が必要な場合には、SSHを利用する。SSHの設定に関しては、「4.2.1 OpenSSHのインストールと設定」を参照する(注4)

  (注4)

PAMの設定を変更する場合は、以下のような状態で設定する。

  • 設定時には複数のコンソール接続を確保し、一方で設定した後、再接続を試みて接続できることを確認する。その間もう一方は設定に不備があった場合に備えて接続状態を保持しておく
  • 万一設定に不備があり、ログインできなくなった場合はシステムをSingle User Modeで起動してファイルシステムをマウントし、正しく設定し直す必要がある
 

ア) pam.confの設定

PAMの設定は/etc/pam.confの内容を編集して行う。この設定ファイルは、1行にPAMを用いるログイン方法と認証方式、認証モジュールの指定が記述されている。無効にするにはコメントアウト(「#」を行頭に付加することで設定無効とすること)を使用する。

---設定有効である場合---
login auth required /usr/lib/security/pam_unix.so.1

---設定無効とした場合---
#login auth required /usr/lib/security/pam_unix.so.1

本モデルでは、以下の設定を有効とする。

login auth required /usr/lib/security/pam_unix.so.1
other auth required /usr/lib/security/pam_unix.so.1
login account required /usr/lib/security/pam_unix.so.1
other account required /usr/lib/security/pam_unix.so.1
other session required /usr/lib/security/pam_unix.so.1
other password required /usr/lib/security/pam_unix.so.1

4) デフォルトumaskの変更

Solarisではデフォルトumaskという設定がある。システムが作成するファイルやフォルダのパーミッションは、デフォルトumaskが元になっている。これは、パーミッションの初期値「777」(ファイルの初期値は「666」)にumaskの値を適用して生成する。

例)umask 000に設定されている場合、新規ファイルに設定されるパーミッションは以下のようになる
666 - 000 = 666
つまり、パーミッションは rw-rw-rw- となる。

この状態では、一般ユーザに書き込み権限(w)が与えられてしまうので、システムファイルなどが一般ユーザによって書き換えられる危険性がある。そこで、デフォルトumaskを適切に設定し、適切なパーミッションでファイルが作成されるように変更する。本モデルでは適切なパーミッションを「644:rw-r--r--」とし、デフォルトumaskを「022」に設定する。

Solaris 8のデフォルトumaskは「022」に設定されている。これは、本モデルにおける適切な設定であるため、設定の変更は行なわない。Solaris 8のデフォルトumaskは「/etc/default/init」内に「CMASK」という変数で設定されている。以下に、/etc/default/initの一部を記す。

# @(#)init.dfl 1.5 99/05/26
#
TZ=Japan
CMASK=022
LANG=ja

5) Protocol Stackのセキュア化

TCP(Transmission Control Protocol)はネットワークの伝送制御を実現するもので、信頼性のある通信を行なう場合に使用される。ここでの信頼性とは、送信ホストが受信ホストに送ったデータに重複や欠落、間違いがなく、送った順序どおりに受信ホストに届くことを指す。これは、TCPのコネクション管理によって通信の信頼性を確保している。
  
TCP通信のコネクション管理方法の1つに「シーケンス番号による管理」があり、TCPがバイトストリームデータを正しく送受信するのに利用されている。バイトストリームデータでは、データを複数のセグメントに分割して送信する。この場合、各セグメントがデータストリーム全体の中のどの部分であるかが示す方法が必要となるが、TCPでは「初期シーケンス番号」と「確認応答番号」を使って実現する。

また、「初期シーケンス番号」と「確認応答番号」は、あるコネクションにおいて送受信されるデータが、そのコネクションの正当なデータであることを認識するためにも利用されているため、シーケンス番号を偽造された場合、不正なデータを正当なデータと認識してしまう危険性がある。

そのような問題を防止するため、シーケンス番号は推測し難い番号になるようにしなければならない。デフォルト状態のSolarisではTCPセッションのシーケンス番号が類推しやすい状態になっており、セキュリティ上問題がある。この問題を解決するため、シーケンス番号がランダムに生成されるように変更する。設定は設定ファイルである「/etc/default/inetinit」を編集して行う。/etc/default/inetinitの内容で、「TCP_STRONG_ISS=1」である場合、「TCP_STRONG_ISS=2」に変更する。ここでは、設定値「0」はシーケンス番号が予測可能な方式、「1」はランダムな増分値の方式、「2」はRFC1948で定義されている方式を設定できる。

# @(#)inetinit.dfl 1.2 97/05/08
#
# TCP_STRONG_ISS sets the TCP initial sequence number generation   
# Set TCP_STRONG_ISS to be:
# 0 = Old-fashioned sequential initial sequence numb
# 1 = Improved sequential generation, with random variance
# 2 = RFC 1948 sequence number generation, unique-per-
#
TCP_STRONG_ISS=2


/usr/sbin/ndd コマンド

nddコマンドは、ネットワークインターフェイスのカーネルパラメータを表示、変更するコマンドである。このコマンドを用いてTCP/IPドライバに特定の設定を行うことで、危険なパケットの通過を禁止したり、接続キューサイズの変更などができ、Solarisシステムのセキュリティを強化することが可能である。例えば、SYN Flood攻撃に対して、確立できる接続数や接続キューサイズを増加することで防御を強化することができる。nddコマンドでは、以下のTCP/IPドライバの設定が可能である。

  • ARP(Address Resolution Protocol)
  • IP(Internet Protocol)
  • TCP(Transmission Control Protocol)
  • UDP(User Datagram Protocol)

また、危険なパケットを通さないという点では、ip filterと似ているが、nddではカーネルのパラメータを直接変更することにより、より細かな設定を行うことができる(注5)

nddの概要と設定については、下記を参照する。

  Sun BluePrints
  「Operating Environment Network Settings for Security
   Updated for Solaris 8 Operating Environment」:
     http://www.sun.com/blueprints/1200/network-updt1.pdf

  Sun BluePrints (JP)
  「セキュリティに関する Solaris オペレーティング環境のネットワーク設定」:
    http://www.sun.co.jp/blueprints/1299/network.pdf

  (注5) これらのパラメータは、Solaris 2.5.1、2.6、7、8でほとんど変更なく使用されているが、SUN Microsystemsはnddパラメータのマニュアルを提供しておらず、今後パラメータ名が変更されることがありうる。  

 

6) Tcp Wrappersによるアクセス制御

システムにアクセス制御機能を追加する方法にはいくつかの方法がある。そのうちのひとつにTcp Wrappersというツールがある。このツールは、主にシステム上のネットワークサービスにアクセス制御機能を追加するもので、接続元のIPアドレスや接続するサービスの種類からアクセス制御が可能である(注6)

  (注6)

先に解説したip filterの機能でも同等のアクセス制御をすることができるが、本モデルでは、ip filterの使用目的はパケットフィルタリングとして、TCP Wrappersの使用目的はサーバーサービスのアクセス制御の実現とする。

 

ア) Tcp Wrappersのインストール

Tcp Wrappersのソースファイルをコンパイルしてインストールする。Tcp Wrappersは、最新版を以下のサイトから入手する。本モデルでは、Tcp Wrappersのバージョン7.6を用いて解説する。

  Tcp Wrappers入手先:
    ftp://sunsite.sut.ac.jp/pub/sun-info/Solaris/SOURCES/

以下の手順で、入手したアーカイブを展開し、コンパイルそしてインストールを行う。なお、インストール作業はroot権限で行う必要がある。

---アーカイブの展開---
% gzip -cd tcp_wrappers_7.6.tar.gz | tar -xvf -
---コンパイル---
% cd tcp_wrappers_7.6
% CC=gcc REAL_DAEMON_DIR=/usr/sbin make sunos5 (注7)
---インストール---
% su
# cp safe_finger tcpd tcpdchk tcpdmatch try-from /usr/local/sbin (注8)

  (注7)

cc=gcc:コンパイラとしてGNU CCを指定
REAL_DAEMON_DIR=/usr/sbin:アクセス制御を実施するサービスデーモンの格納場所を指定
make sunos5:インストールするOSを指定してコンパイル

 
  (注8)

Tcp Wrappersにはインストーラがないため、手動でコピーする。

 

イ) Tcp Wrappersの設定

Tcp Wrappersの設定は、以下の2種類の設定ファイルで行う。

Tcp Wrappersの設定内容は、以下の順番で適用される。

よって、方針としてhosts.denyに必ず"全て拒否"の設定を記述し、hosts.allowで許可する接続を記述する。

ここでは、ローカルホストからの全ての接続を許可し、それ以外は拒否する設定例を示す。

---/etc/hosts.deny---
ALL:ALL

---/etc/hosts.allow---
ALL:127.0.0.1

 

UNIXのアクセス制御(inetd、xinetd、tcpserver)

UNIX系OSで、サービスのアクセス制御を実現するにはいくつかの方法が存在する。本モデルでは、inetd + Tcp Wrappersを利用したアクセス制御の設定方法を解説している。このアクセス制御は、古典的なものなのでコネクション数を管理したり、ログ出力のカスタマイズなどの柔軟な設定を行うことができない。近年、このような柔軟な機能を持つアクセス制御ツールがいくつか提供されている。ここでは、以下の2つを紹介する。

  • xinetd

    「inetd + Tcp Wrappers」の拡張版ともいえるスーパーサーバーデーモンである。「inetd + Tcp Wrappers」と同様に、スーパーサーバーデーモン(xinetd)が他のサーバーデーモン(TELNETやFTPなど)を管理している。「inetd + Tcp Wrappers」と大きく異なるのが、サーバーサービスごとに設定ファイルが存在し、そのファイルにてログ出力やアクセス制御の詳細な設定を行うことができる点である。

      xinetdのホームページ:
       http://synack.net/xinetd/

  • tcpserver

    「inetd + Tcp Wrappers」と異なり、tcpserverはひとつのtcpserverデーモンで、ひとつのサーバーサービスのアクセス制御を行う。そのため、複数のサーバーサービスにアクセス制御機能を持たせる場合、サーバーサービス分のtcpserverデーモンを起動する必要がある。tcpserverは、アクセス制御ルールをハッシュ化したデータベースとするので、高速処理が可能である。接続数が多いサーバーサービス(SMTP、特にqmail)のアクセス制御を行うのに向いている。

      ucspi-tcpのホームページ:
        http://cr.yp.to/ucspi-tcp.html

 

7) ログ出力の設定

システムのログ出力(動作状況や問題発生時などの情報を記録すること)は、運用管理や問題発生時の情報として重要である。また、以下のような用途が考えられることから、セキュリティにおいてもログ出力は重要である(注9)。また、ログ運用の詳細に関しては「8.2.1 ログの運用」を参照する。

  (注9)

ただし侵入などの被害を被った場合には、侵入者によってログが消去、あるいは改ざんされている可能性があるため、記録していたログが必ずしも調査に役立つとは限らない。

 

ここでは、システムやデーモンなどからのメッセージを受け取って記録するsyslogデーモン「syslogd」によるログ出力の設定を行う。

ア) syslogdの動作

syslogdはシステム、またはさまざまなサービスからのメッセージを受け取り、設定にしたがってログ出力を行う。ログの出力先はファイルやコンソール、リモートホストのsyslogなどに設定することが可能である。

イ) syslogのセキュリティ

syslogにはリモートホストからログメッセージを受け取ることができる。しかし、これを攻撃者に悪用され、圧迫される危険性がある。このような脅威を回避するため、本モデルでは、リモートホストからのログメッセージを受け取らない設定にする。syslogの起動時に、このオプション(-t)を指定して起動することで設定が可能である。起動設定の変更は、syslogの起動スクリプトである「/etc/rc2.d/S74syslog」を編集する。

#!/sbin/sh
#
# Copyright (c) 1991-1999 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident "@(#)syslog 1.13 99/09/06 SMI"

case "$1" in
'start')
  if [ -f /etc/syslog.conf -a -f /usr/sbin/syslogd ]; then
    echo 'syslog service starting.'
    #
    # Before syslogd starts, save any messages from previous
    # crash dumps so that messages appear in chronological order.
    #
    /usr/bin/savecore -m
    if [ -r /etc/dumpadm.conf ]; then
      . /etc/dumpadm.conf
      [ "x$DUMPADM_DEVICE" != xswap ] && \
       /usr/bin/savecore -m -f $DUMPADM_DEVICE
    fi
    if [ ! -f /var/adm/messages ]; then
      /usr/bin/cp /dev/null /var/adm/messages
      /usr/bin/chmod 0644 /var/adm/messages
    fi
    /usr/sbin/syslogd -t >/dev/msglog 2>&1 &
  fi
  ;;

<以下省略>

ウ) syslogの設定

syslogの設定は/etc/syslog.confで行われ、記述方法は以下のとおりである。

    セレクタフィールド 
security.* 
アクションフィールド
/var/log/security

セレクタフィールドによって出力するログを指定し、アクションフィールドで出力先を指定する。セレクタフィールドは「.(ピリオド)」で区切られ、左をfacility(メッセージの属性)、右をpriority(メッセージの重要度)と呼ぶ。それぞれに指定できる項目名と内容をTable 4.9、4.10に示す。

Table 4.9 syslogのfacility

facility 内容
kern カーネルメッセージ
user ユーザプロセスメッセージ
mail メールシステム
daemon システムデーモン
auth 認証メッセージ
syslog syslogデーモンの内部メッセージ
lpr ラインプリンタスプーリング
news ネットニュースシステム
uucp UUCPシステム
cron cronシステム
authpriv プライベート認証メッセージ
ftp ftpデーモン
ntp ntpデーモン
security セキュリティシステム
console コンソールメッセージ
local0 - 7 ローカルでのカスタマイズ用
mark タイムスタンプ
* mark以外のすべて

Table 4.10 syslogのpriority

priority 内容
emerg(panic) システム使用不能などの緊急事態
alert アラートメッセージ
mail 重大なエラー
err(error) 通常のエラー
warning (warn) ワーニング
notie 注意
info インフォメーションメッセージ
debug プログラムデバック用メッセージ
none 特定のファイシリティを無効にする
* none以外のすべて

syslogのログ出力設定は「/etc/syslog.conf」で行う。ファシリティとレベルを組み合わせて、運用条件に適したログ出力設定を行う。

本モデルでは、できるだけ多くの情報を取得する方針(「8.2.1 ログの運用」参照)に基づき、以下の手順で、プログラムデバック用のメッセージを「/var/log/summary」に出力する設定を行う(変更後の「/etc/syslog.conf」)。

---/etc/syslog.confの一部---
*.debug       /var/log/summary

「/etc/syslog.conf」設定後、「/var/log/summary」を新規作成し、設定を反映させるためにsyslogデーモンを再起動する。

---/var/log/summaryの作成---
# touch /var/log/summary

---syslogdの再起動---
# sh /etc/rc2.d/S74syslog stop
syslogd going down on signal 15
# sh /etc/rc2.d/S74syslog start
syslog service starting.

 

前のページへ
目次へ
次のページへ
Solarisのインストール
第4章の目次
OpenSSHのインストールと設定


Copyright ©   2002 Information-technology Promotion Agency, Japan.  All rights  reserved.