text

システム管理基礎

スーパーサーバーとシステム管理のアレコレ

１．スーパーサーバとは

サーバのネットワークサービスは、クライアントからの要求を常に受けるために、特定のポートを監視していなければならない。
複数のサービスを提供するためには、常に複数のサービスを起動し監視する必要がある。しかし、これだと無駄なCPU・メモリの消費が発生してしまう。たとえば、POPがその代表だ。そこで、複数のサービス（ポート）を同時に監視して、普段は起動していない状態にしておく。クライアントから要求があった時だけ、そのデーモンを起動させて処理する仕組みが考案された。この仕組みが、スーパーサーバと呼ばれる。一般的なUNIX系OSではinetdやxinetdとして実装されている。いわば、デーモンのためのデーモンで、これがスーパーサーバといわれる所以。

スーパーサーバを利用すると、複数のサービスを起動しておく必要がなく、スーパーサーバひとつですべてのポートを監視することができますのでサーバのリソースの消費を防ぐことができる。また、スタンドアローン型のサービスは、一度サービスがダウンすると、手動で再起動するしかないが、スーパーサーバ型の場合はサービスが１度ダウンしたとしても、もう１度コネクションをすることでスーパーサーバが再度答えることができる。だだ、サービスを提供するデーモンに対して、コネクションが多発するものや、速度を重視するデーモンの場合は、スーパーサーバを１度経由になりますので、速度が遅くなる。そのようなデーモンの場合は、スタンドアロン型が適している。

２．実習の目的

POPサーバー、telnetサーバーなどは、DNS、Web、SMTPサーバーと異なり単独では動作しない。これらは、スーパーサーバであるxinetedを通じて起動する。アクセス頻度の少ないサーバーやセキュリティ面、メモリ節約上のどのようなサーバをスーパーサーバに管理させた方が良いかを理解する。

サーバーのアカウント管理をはじめとした各種サービスの管理の方法について学んでいく。

３．実習の手順

(1)　/etc/xinetd.dの各種設定ファイルの修正

(2)　xinetdの再起動

(3)　telnetの起動とリモートログインのテスト

(4)　デーモンをスーパーサーバーの監視下に置く

(5)　TCP Wrapperとの関係

(6)　ユーザー管理

(7)　Linuxのブートの仕組み

(8)　デーモン管理

(9)　プロセス管理

(10)　メモリ管理

(11)　ディスク管理

(12)　セキュリティ管理

(13)　システムログ管理

(14)　スケジュール管理

番外編　シェルスクリプト入門

４．スーパーサーバー

■xinetd

デーモンを監視するスーパーサーバと呼ばれるサーバがxinetdに該当する。すべてのデーモンではないが、幾種類かのデーモンはxinetdを通して起動される。

■/etc/xinetd.conf

スーパーサーバの設定ファイル(xinetd.conf)の中は下記のようになっている。

defaults{
instances =60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}

includedir /etc/xinetd.d

すべてのデーモンがスーパーサーバーで使えるわけではない、ということは上記で述べている。
では、どのようなデーモンが使えるかと言うと、/etc/xinetd.d以下のディレクトリに納められてるデーモンを起動するシェルスクリプトが該当する。自分でソースコードから独自にコンパイルしてインストールしたデーモンをスーパーサーバーでの制御下に加えたいときにはこのディレクトリ下にシェルスクリプトを書き加えればよい。

このときの注意点としては、下記にtelnetdのxinetd起動用スクリプトを例に説明する。
どのデーモン起動用スクリプトは同じ。デーモン名やパスの配置が異なることを意識しておこう。

# default: on
# description: The telnet server serves telnet sessions; it uses
# unencrypted username/password pairs for authentication.
service telnet
{
disable = yes
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
}

上記の”disable = yes”という記述に注目。
この記述は、/etc/xinetd.dに納められている、シェルスクリプトすべてに共通している。ここにシェルスクリプトが収められているデーモンは歴史的にxinetd.dが実装される前にスーパーサーバーとしてinetdが実装されていた時期があった。その当時のOSの標準設定としてスーパーサーバーの制御下に置かれていたデーモンである。だが、現在ではセキュリティの脆弱性が既知となっているため本来使われないデーモンである。実際に、telnet,rloginはsloginに、rshはssh、ftpはscp、・・・etcへと取って替わられた。そのため、いかにコネクションのあったときのみ起動して処理するとしても、脆弱性であることには変わらない。ローカル環境で限定的に使うことを考慮して残しているのだろう。そのため、スーパーデーモンの制御下でも稼働しないように起動設定がオフになっている。

実際に、スーパーサーバーの制御下で稼働させたい場合は、ここの部分を"disable = no"とする必要がある。

上記の例では、記述していないがスクリプトの末尾に以下のような記述をすることで、よりスーパーサーバーの制御を高めてよりセキュア・よりリソースを節約することができる。

■スーパーサーバーのアクセス制御

only_from = 172.18.0.0/16　<-　アクセスできるネットワークを限定
no_access = 172.16.0.0/16　<-　アクセス拒否をするネットワークを指定
access_time = 09:00-17:00　<-　アクセス可能時刻の設定

■スーパーサーバーの起動

#service xinetd start

■TCPWrapperとは

簡易的なアクセス制御の仕組みとしてTCPWrapperというモノがある。詳細な説明は省くが、特定のネットワークを指定してサーバーやサービスポートに対するアクセス制御を行うことができる。ファイアウォールでも同等のことはできる。ルール変更をしたあとファイアウォールの場合は再起動しないとルール変更が反映されないが、TCPWrapperはルール変更後再起動しないでもすぐに変更が反映される。ただし、アクセス制御をしているがTCPWrapperの場合ポートを塞いでいるわけではない。ルールで指定したネットワークからのアクセス制御をしているだけに過ぎない。そのため、手軽に使えるがTCPWrapperだけではファイアウォールの代替にはならない。変更した設定内容を保存すると、即座にルール変更が反映されるため、リモート接続をしてまちがった設定をしてしまった場合、大変なことになる。

TCPWrapperはすでに多くのUNIX系OSに標準で実装されている。
本実習で用いている環境(Fedra Core Linux 4.0)ではすでに搭載されていて、/etc/ディレクトリ下にhosts.allowとhosts.denyがあれば、TCPWrapperは実装されていると考えられる。

設定は至ってシンプル。
TCPWrapperによるアクセス制御の大原則は

アクセスはすべて拒否、限定的に一部のネットワークからのアクセスを許可。

先に、拒否リスト(hosts.deny)を設定し、あとから許可する通信だけを許可リスト(hosts.allow)に書き加えて設定は完了である。後は、いちいち、デーモン起動のコマンドをたたかなくともうよい。

かつて、inetdをスーパサーバとして実装していたときは『inetd + TCPWrapper』の組み合わせがスーパーサーバだった。現在では、xinetdだけでデーモンの制御及びアクセスもとネットワークごとのアクセス制御ができるので、Tcpwrapperはスーパーサーバーには使わなくなっている現状にある。

５．システム管理

■ユーザー管理

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊