システム奮闘記:その38

デーモンの設定



(2008年5月5日に掲載)
はじめに

  スーパーデーモンと言えば、デーモン小暮が経営しているスーパーだ。
  もしくは、ドラゴンボールに出てくる悟空、ベジータが気合いを入れたら、
スーパーサイヤ人になるのと同様、デーモンが気合いを入れたら、
スーパーデーモンに変身する。

  「山田く〜ん、座蒲団、3枚、持っていきなさい」というレベルのギャグだ。


  さて、くだらん前置きは、これくらいにして、本題に入ります。

  xinetdという物が存在していたのは知っていたのだが、
そもそも何をする物なのか、それがスーパーデーモンと呼ばれる
知らなかった。

  机の上のお勉強が大の苦手な私。
  何かキッカケがないと、本当は重要な事だったとしても、
重要性に気がつかないまま、放置した状態になる。

   スーパーデーモン(xinetd)という物も、そのうちの1つだった。

  だが、キッカケというのは意外な所から出てくる物だ。
  さて、今回は、スーパーデーモンの話や、不要なデーモンの話などを
書く事にしました。

3月のある日の事、scpというコマンドの存在を知った。
scpコマンド
scpコマンドの働き

  暗号技術を使ったリモートコピーなのだ。

  リモートコピーといえば、rcpコマンドがある事は知っていた。
  暗号化されていないので、途中の経路でデータが盗み見される
危険性が指摘されるものだ。

  だが、実際には、私はrcpコマンドを使った事がない。
  「危険だから」という模範解答(?)を行いたい所なのだが、実は・・・

  だいぶ前に、試してみて、使えへんかった (TT)

  そうなのです。単に使えなかっただけなのです。
  さて、リモートコピーがどんな物か知りたくなった上、使ってみたくなった。
  そこで、実験サーバーを使って、LAN内の中の一応、安全地帯(?)で
rcpコマンドを使ってみる事にした。

  早速、コマンドの使い方を調べてみた。

rcpコマンド
rcpコマンドの働き

  そして、実行できる環境を整えた。

rcpコマンドを使えるようにする設定
rcpコマンドを有効にする設定方法

  早速、rcpコマンドを使ったリモートコピーの実験を行ってみたが・・・

  なんで、接続エラーが出るねん (TT)

  だった。
 
  そこで調べてみると、xinetdの設定を触るのが必要な事がわかった。
  この時、初めて、xinetdを知らないと困る事がわかった。

  RedHat7.3の場合、xinetdの設定に関するファイルで、/etc/xinetd.d/rshの
ファイルを書き換える必要がある。

/etc/xinetd.d/rshの中身(初期値:RedHat7.3の場合)
# default: on
# description: The rshd server is the server for the rcmd(3) routine and, \
# consequently, for the rsh(1) program.  The server provides \
# remote execution facilities with authentication based on \
# privileged port numbers from trusted hosts.
service shell
{
socket_type = stream
wait = no
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/sbin/in.rshd
disable = yes
}
/etc/xinetd.d/rshを書き換えた後
# default: on
# description: The rshd server is the server for the rcmd(3) routine and, \
# consequently, for the rsh(1) program.  The server provides \
# remote execution facilities with authentication based on \
# privileged port numbers from trusted hosts.
service shell
{
socket_type = stream
wait = no
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/sbin/in.rshd
disable = no
}

  そして、/etc/rc.d/init.d/xinetd restart を行った。
  すると・・・

  リモートコピーができた!! (^^)V

  ついに、rcpコマンドが使えるようになったのだ。

  調べてみると、chkconfig rsh onでも、設定ファイルが、
disable = noに書き換わる事がわかった。

  そういえば、telnetやftpを有効にするために、chkconfigが使われているのを
思い出す。
  /etc/xinetd.d/のフォルダーに、telnetやftpに関するファイルがある。

  そこで初めて、xinetdが重要な物である事を知ったのだった (^^;;

  RedHat7.3の場合、telnetやftpは初期状態では使用不可能になっているが
xinetdデーモンの話を知らないのに、なぜ、有効にできたのか
不思議に思った人がいるかと思います。その理由は

  実は、本の丸写しです (^^)

  xinetdデーモンの事を知らなくても、chkconfig telnet onを使えば、
良いという事を、本の丸写しで覚えました。
  そのため、頭の中では何もわかっていませんでした (^^)


  ところで、先ほどから、接続の説明で「mayumi」と「waka」が出ています。
  それは私の大好きな小野真弓と競合する井上和香の事を意味しています。

「アコム VS プロミス」の場外乱闘?
私が大好きな小野真弓といえば、アコムのお姉さんで、
井上和香といえば、アコムのライバルであるプロミスの
キャンペーンガールだ。

大学の時の友人と飲みに行く度に、どっちが良いかで平行線を辿る。
私は「真弓ちゃん、(o)」で、友人は「和香ちゃん (o)」で
どっちが良いか、真っ二つになる。
まさに宗教戦争に近い物があったりする (^^;;

お互い共通しているのは、アコムからもプロミスからも金は借りない。
「サラ金に手出したら、返せなくなる」だからだ (^^;;

スーパーデーモン xinetd

さて、xinetdが重要な物である事を知ったのだが・・・ だから、xinetdとは一体、何やねん? だった (^^;; そこで、調べてみる事にした。 まずは、サーバーの負担を軽くする物だという。一体、どういう事なのか。
もし、xinetdがなければ
もし、xinetdがなければ待機待ちのデーモンが増える
httpdやnamedのようにクライアント側から問い合わせが頻繁にあるのと違い、
telnetdやftpdなどは、クライアントから、あまり問い合わせがあるとは思えない。

しかし、いつクライアントから問い合わせがくるのか、わからない物に対して、
常に待ち受けのためにデーモンを動かすのは、CPUやメモリの無駄な消費に
なってしまう。
例え、小さなデーモンであっても、チリも積もれば山となるで、
小さなデーモンの集まりだからといって侮れないのだ!

  (注意!)
  この奮闘記を公開した翌日、Sambaの太田さんから以下のご指摘を受けました。

Sambaの太田さんから以下のご指摘
もし、xinetdがなければ

という図の説明の中に、

----引用----
しかし、いつクライアントから問い合わせがくるのか、わからない物に対して、
常に待ち受けのためにデーモンを動かすのは、CPUやメモリの無駄な消費に
なってしまう。
例え、小さなデーモンであっても、チリも積もれば山となるで、
小さなデーモンの集まりだからといって侮れないのだ!
------------

という文面があります。しかし、待機中のdaemonは、メッセージの受け待ちで
止まっているため、CPUは消費していないと思うのですが。

メモリはおっしゃるとおり無駄な消費になってしまう事にはなりますね。

  実は、私は「デーモンは常駐しているのだからCPUは消費しているはずだ」
と思い込んでいた。
  そこで、ps auxコマンドでプロセスのCPU消費の度合を見てみると、
太田さんのご指摘通り、CPUの消費はなかった。
  しっかり確かめないとダメだなぁと思う今日この頃 (^^;;

  話は元に戻します。
  さて、xinetdによるメモリの節約のために以下のようになっている。

xinetdの役目
xinetedの役目
利用頻度が低いとされるデーモンは常駐させるのではなく、
受付窓口を、xinetdデーモンに一本化しておく。
そして、クライアントから問い合わせがやってきた時に、
xinetdが何の問い合わせかを判断して、該当するデーモンに
立ち上がるように指示を出す仕組みになっている。

この方法だと常駐しているデーモンは、xinetdだけになり、
メモリの節約になっている。

  デーモンの起動を行うデーモン。まさにデーモンのデーモンなので、
「スーパーデーモン」と呼ばれる所以だ。
  xinetdの前身として、inetdというデーモンもありますが、
私は使わないので、ここでは省略しまーす (^^)


  さて、named、httpdの頻繁に問い合わせる物は、xinetdを使わない。
  その理由は、xinetdを使うと、遅くなるからだ。これがデメリットなのだ。
  そのため、利用頻度の応じて、遅くなっても影響がないデーモンは
普段は常駐させずに、必要な時に、立ち上げるようになっている。

  一応、Apacheの設定には、inetd経由にはできる。

Apacheでinetdデーモン経由にする設定(httpd.confファイル)
#
# ServerType is either inetd, or standalone.  Inetd mode is only supported on
# Unix platforms.
#
#ServerType standalone
ServerType inetd

  だが、inetdを使っていないので、実際に、どれくらレスポンスが悪くなるのか
全くわからない。
  こんな事を書くと「inetdをインストールしたらええやん」と言われるので
次のように答えます。

  だって、面倒だもーん (^^;;

  そうなのです。ただのズボラなのです。
  そして、とどめを刺す言葉として

  事務員だから知らなくて、とーぜん (^^)V

デーモンとは

先ほどから「デーモン」という言葉が出ているが、よく考えると デーモンって何やねん? となる。頭の中では、サーバーソフトという感じで捉えているのだが、 明確に知っていたわけではないので、調べてみた。 調べた結果「デーモンとは、サーバープログラムの事」だという。 私が思っていた事と同じなので、誤解していない事にホッとした。 ところで、デーモンと言われると、私は「悪魔」を連想していた。 だが、本には「デーモンは守護神」と書いていた!! デーモンは悪魔ではなく守護神だった!! 同じデーモンでも悪魔の方は「demon」で、守護神は「daemon」なのだ!! 「daemon」はギリシャ神話の「ダイモン」から来ているという。
ギリシャ神話について
実際に、デーモン(daemon:ダイモン)がギリシャ神話に出てくるのか
確かめるために、私が愛読する次の本から調べてみた。
  「マンガ ギリシャ神話」全8巻(里中満智子:中央公論社)
かなり詳しく神々の系譜が載っているのだが、見つけられなかった。

この本には、ギリシャ神話と古事記との比較が載っている。
興味深いのは、女が女にストリップをして喜ばせる共通点がある。

ギリシャ神話で出てくる農耕と豊饒の女神(デメテル)が、自分の娘が
冥府の神・ハデスに略奪婚された時、怒りのあまりに仕事を投げ出し
さすらいの旅に出た。その時、人間の女性がデメテルの心を和ませようと
なんと、ストリップを行ったのだ。

古事記にも、天照大神が弟の素盞鳴尊(すなのおのみこと)の傍若無人ぶりに
衝撃を受け、天の岩戸(現在の長野県・戸隠)に隠れて、
地上が真っ暗闇になった時、なんとか天照大神が天の岩戸から出てもらおうと
誘い出した手が、宇受女命(うずめのみこと)という女神による
ストリップだった。

男性が女性のストリップを見て喜ぶのなら理解できるが
なぜ、女性が女性のストリップを見て喜ぶのか理解しがたい (--;;

真面目な話を書くつもりが、ピンクネタに走ってしまう私なのだ (^^;;

  この時、「demon」と「daemon」が別物だと思った。
  ふと、FreeBSDのマスコットキャラのデーモン君を思い出した。
  もし、デーモン君は「悪魔」なのか「守護神」なのか興味津々で
FreeBSDのサイトを見てみると、意外な事がわかった。

  「demon」と「daemon」も同じ物だった!!

  「demon」の古代の綴りは「daemon」だったのだ。
  古代は善と悪の両方の側面を持っていると考えられていたようだ。

  面白そうなので、詳しく調べてみようと思った。

  「世界神話大事典」(大修館書店)で、ダイモンを調べてみると
ギリシャ神話では善い神として紹介されているのだが、キリスト教の影響で
異教徒の偽神を「デーモン」(ダイモン)と呼ぶようになったと書かれている。

  「岩波 キリスト教辞典」では、ギリシャ神話のダイモンは善悪中立の神だが
キリスト教では異教徒の偽神(悪霊など)として「デーモン」と呼んでいる。

デーモンが悪者になる過程
調べていくと「旧約聖書」にはデーモンを「敵対する物」という記述があるみたい。
もしかすると、キリスト教だけでなくユダヤ教、イスラム教でも、
デーモンは悪魔の意味で使われている可能性はあるのだが、
そこまで調べていませんので、詳しい事はわかりませんが (^^;;

ギリシャ語のデーモン(ダイモン)には「超自然的な物」という意味がある。
要するに「神の力」を意味する。
キリスト教をはじめとする一神教の場合、他の神の存在を嫌い、
邪悪な存在として扱う。

私の推測だが「異教徒の神の力」を「邪悪な力」と考えて、
デーモンに悪魔の印象がついたのではと思ったりする。

  「善」の存在が「悪」の存在に変質していく話。
  実は、似たような例が日本にもある。それは「鬼」の姿だ!

  なんと鬼は、元々は精霊だった!

神戸市の長田神社の「追儺式」(2002/2/3 撮影)
神戸市の長田神社の「追儺式」
鬼といえば、桃太郎伝説にありますように、悪を連想させますが
太古の昔は鬼は悪ではなく、むしろ、厄除けと恵みをもたらす精霊でした。

奈良時代から平安時代にかけて仏教の影響で、地獄にいる怪物や、
羅刹や夜叉と混同され、恐ろしい存在になってしまいましたが、
兵庫県南部では太古の鬼像が、現在もそのまま引き継がれ、
長田神社の「追儺式」の鬼は厄除けの鬼です。

東北のナマハゲも太古の鬼の姿が残っている1つです。

ただ、これも調べると、太古から悪を思わせるの鬼もあり、
必ずしも「太古の鬼は善」と断言できないのだ。

  色々、調べて行くと面白いのだが、どんどん深みにハマるので、
この辺で話を、システムに話に戻します (^^)

  さて、デーモンの種類を見ると、大抵、後ろに「d」がついている。

後ろに「d」がつく理由
後ろに「d」がつく理由
この話を書くと「なんだ、当り前やん」と思われてしまうが
今まで、この事を知らなかっただけに、私にとっては大きな発見です!

/etc/servicesファイルについて

スーパーデーモンがメモリの節約してくれるのは理解できた。 もうひとつ、スーパーデーモンにはセキュリティー対策としての役目が あるのだが、その話を書く前に、ちょっと横道をします。 /etc/servicesファイルの話を書きたいと思います。 「図解でわかる Linux環境設定のすべて」(日本実業社:西村めぐみ) の本を見た時、xinetdの章に、/etc/servicesファイルに触れられていた。 それを見た私は、自慢じゃないですが、次の事を胸を張って言えます。 /etc/servicesファイルって、よくわからん いつもなら「何?」と書いて、知らない事をアピールするのだが、 今回は、いつもと違う。 それは以前、/etc/servicesファイルを触った事がある。 サーバー構築して、しばらくたった頃、ハッキリ覚えていないのだが、 どこかで仕入れた情報で/etc/servicesファイルに記述されている不要なポートに 「#」を追加すれば接続ができなくなるという話だ。
当時、どこかで仕入れたセキュリティーの対策の方法で
/etc/servicesファイルを触って、telnetを受け付けないようにする方法
telnetを受け付けない設定
この時のサーバー側の/etc/servicesファイルの設定
ssh             22/tcp          # Secure Shell Login
ssh             22/udp          # Secure Shell Login
#telnet          23/tcp
#telnet          23/udp

  この時、telnetで相手先にログインできなかったので、
実験には成功したのだが、Webサーバーに同じ事を行ったが
うまくいかなかったのを覚えている。

当時、どこかで仕入れたセキュリティーの対策の方法で
/etc/servicesファイルを触って、Webの接続を受け付けないようにする方法
.etc.servicesファイルの設定
この時のサーバー側の/etc/servicesファイルの設定
rje             77/tcp          netrjs
finger          79/tcp
#www             80/tcp          http    # WorldWideWeb HTTP
#www             80/udp                  # HyperText Transfer Protocol

  だが、Webサーバーに上のような設定を行っても、問題なく公開できる。

  当時、/etc/servicesファイルは謎が多いなぁと思ったのだが
調べる力がないので放置していた (^^;;


  さて、当時の記憶が正しい事を再現するために、もう一度、以下の
実験を行う事にした。

当時、どこかで仕入れたセキュリティーの対策の方法で
/etc/servicesファイルを触って、telnetを受け付けないようにする方法
telnet拒否の実験の様子
この時のサーバー側の/etc/servicesファイルの設定
ssh             22/tcp          # Secure Shell Login
ssh             22/udp          # Secure Shell Login
#telnet          23/tcp
#telnet          23/udp

  過去の実験と同様に、クライアント側からのtelnet接続が拒否された。
  次に、Webサーバーに対して、下の実験を行った。

当時、どこかで仕入れたセキュリティーの対策の方法で
/etc/servicesファイルを触って、Webの接続を受け付けないようにする方法
httpプロトコルの拒否実験
この時のサーバー側の/etc/servicesファイルの設定
rje             77/tcp          netrjs
finger          79/tcp
#www             80/tcp          http    # WorldWideWeb HTTP
#www             80/udp                  # HyperText Transfer Protocol

  当時の記憶通り、telnetでの接続は拒否されたが、Web接続は可能だった。
  どうして、こんな奇妙な事が起こるのか謎に思えた。

  だが、今回は調べるだけの力はついている。
  そこで、/etc/servicesファイルは一体、何なのか調べてみる事にした。

  本を見てみると「/etc/servicesファイルは、サービス名とポート番号の
対応関係を記述した物」だと書いていた。

  サービス名はアプリケーション層が認識できる物で、ポート番号は
トランスポート層(第4層)が認識する物で、それの変換を行う物という
感じで書かれていたのだが・・・

  何を意味するのか、わかんなーい (^^;;

  そこで、/etc/servicesファイルを触ってみて
色々な実験を行ってみる事にした。

実験・その1
telnetの接続拒否実験
この時のサーバー側の/etc/servicesファイルの設定
telnet          9023/tcp
telnet          9023/udp

  「実験・その1」の結果は

実験・その1の結果
[suga@mayumi]$ telnet waka
Trying 192.168.1.10...
telnet: connect to address 192.168.1.20: Connection refused
[suga@mayumi]$ 

  接続拒否された!

  そこで「実験・その2」として、以下の事を行う事にした。

実験・その2
telnetの接続拒否実験

ただし、telnetでポート9023で接続
この時のサーバー側の/etc/servicesファイルの設定
telnet          9023/tcp
telnet          9023/udp

  さて「実験・その2」の結果は

実験・その2の結果
[suga@mayumi]$ telnet waka 9023
Trying 192.168.1.10...
Connected to waka.
Escape character is '^]'.
Red Hat Linux release 7.3 (Valhalla)
Kernel 2.4.X on an i686
login: suga
Password: 
Last login: Tue Mar 22 13:44:26 from mayumi
[suga@waka]$ 

  接続できた!

  さて、なぜ接続ができたのか、考えてみる必要がある。
  ふと思った。

  ポート9023が、telnetポートと認識するみたいだ。

  もしかして、/etc/servicesファイルには以下の役目があると考えた。

/etc/servicesファイルの働き
/etc/servicesファイルの役目
クライアントからのサーバーへの接続されたポートを
サーバーが判断して/etc/servicesファイルでチェックを行い、
ポート番号からサービス名に変換したのちに、xinetdデーモンに
その情報が伝わるのではと考えてみた。

  そこで次の実験を行って見る事にした。

/etc/servicesファイル
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnetk          23/tcp
telnetk          23/udp
/etc/xinetd.d/telnetファイル
# default: on
# description: The telnet server serves telnet sessions; it uses \
#       unencrypted username/password pairs for authentication.
service telnetk
{
        disable = no
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
}
ポート番号をサービス名に変換する名前解決の実験

  実験を行ってみた結果・・・

  見事、成功!  (^^)V

  この成功から言えるのは、どうやら/etc/servicesファイルを使って
ポート番号からサービス名に変換している事がわかる。


  ところで、xinetdデーモンを経由しないデーモンを使った次の実験を行った。

Webサーバーへの接続実験を行った
Webサーバーへの接続実験
/etc/servicesファイル
rje             77/tcp          netrjs
finger          79/tcp
web             80/tcp          http    # WorldWideWeb HTTP
web             80/udp                  # HyperText Transfer Protocol

  予想に反して、全く問題なく接続できた。

  xinetdデーモンを中継する場合は、/etc/servicesファイルの影響を受けて
そうでない場合は、影響を受けないようだ。

  サーバーそのものは、ポート番号をサービス名に変換しないだろうか?
  そんな疑問を持ちながら数日経ったある日の事、ふと頭に浮かんだ。

  こういう仕組みだろうという物が浮かんだのだ。

クライアント
ポート番号とサービス名の名前解決の実験
クライアントからの接続要求で、ポート番号を認識したxinetdデーモンが
/etc/servicesファイルの確認を行って、サービス名に変換を行い、
/etc/xinetd.d/の中のファイルから、該当するサービス名のデーモンを
探し出すのではないかと考えた。

  そう考えると、辻褄があう!

  他にも、/etc/servicesファイルをチェックするソフトがあるのではと思った。

  ふと、tcpdumpコマンドが思いついた。
  そこで、まずは、/etc/servicesを書き換えて実験を行ってみた。

/etc/servicesファイル
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnetk          23/tcp
telnetk          23/udp
tcpdumpコマンドを使ってみる
/usr/sbin/tcpdump -port telnetk をすると。

13:44:21.650965 192.168.1.xx.2201 > aaaa.bbbb.co.jp.telnetk: 
         P 2266136660:2266136661(1) ack 1894380686 win 62873 
         <nop,nop,timestamp 243649866 335363694> (DF) [tos 0x10] 

13:44:21.651323 aaaa.bbbb.co.jp.40427 > 192.168.1.xx.telnetk: 
         P 2536244778:2536244779(1) ack 2905738235 win 7504 
         <nop,nop,timestamp 335366361 243647200> (DF) [tos 0x10] 

13:44:21.651510 192.168.1.xx.telnetk > aaaa.bbbb.co.jp.40427: 
         P 1:2(1) ack 1 win 5792 <nop,nop,timestamp 243649867 
         335366361> (DF) [tos 0x10] 

13:44:21.651609 aaaa.bbbb.co.jp.40427 > 192.168.1.xx.telnetk: . ack 2 
         win 7504 <nop,nop,timestamp 335366361 243649867> (DF) [tos 0x10] 

  どうやら/etc/servicesファイルを確認している。
  ネットワークに関連したソフトを使う際に、ポート番号ではなく、
サービス名で指定する場合、チェックをしないと、ソフトの方が
サービス名だけでは、どのポートを使った物なのか認識できない事がわかる。

  さて/etc/servicesファイルは、セキュリティー強化のための設定には
何も関係なく、単なるポート番号とサービス名の変換に使われる表だった。

  セキュリティーに関して何があると期待していた事もあり、
何もないという結果は、予想外だったのだが

  長年の謎が解けたので、ご満悦の私だった (^^)V

不要なデーモンの停止方法

xinetdデーモンのもう一つの役目を考える前に、不要なデーモンについて 触れたいと思います。 私が愛着を感じて使っているRedHat7.3に限らず、その他のLinuxの ディストリビューターや、Windowsサーバーでは、初期状態の時に 不要なデーモンや、不要なサービスが立ち上がっていたりする。 それを放置していると、CPUやメモリの無駄使いだけでなく、 セキュリティーホールになると言われる。 以前、不要なデーモンを立ち上げるのは危険だと聞いていたのだが・・・ 下手に触ると恐いので触っていません 失敗談の大量生産を行っていると、変に行動が慎重になってしまい、 逆に、身動きがとれなくなる。 だが、不要だとわかっているデーモンでも 停止方法がわからない (TT) そうなのです。 デーモンを起動時に立ち上がらなくする方法を知らなかったのです。 だが、今回、RedHat7.3の場合chkconfig (デーモン名) offを使えば デーモンが起動時に立ち上がらなくなる事がわかった。 さて、不要なデーモンを眠らせる前に、どんな不要なデーモンが 動いているのか、ps auxコマンドを使って見てみる事にした。
ps auxコマンドでプロセスを見てみる
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.6  1308  428 ?        S    Feb12   0:06 init [5] 
root         2  0.0  0.0     0    0 ?        SW   Feb12   0:00 [keventd]
root         3  0.0  0.0     0    0 ?        SWN  Feb12   0:00 [ksoftirqd_CPU0]
root         4  0.0  0.0     0    0 ?        SW   Feb12   0:46 [kswapd]
root         5  0.0  0.0     0    0 ?        SW   Feb12   0:00 [bdflush]
root         6  0.0  0.0     0    0 ?        SW   Feb12   0:05 [kupdated]
root         7  0.0  0.0     0    0 ?        SW   Feb12   0:00 [mdrecoveryd]
root        11  0.0  0.0     0    0 ?        DW   Feb12   0:42 [kjournald]
root        82  0.0  0.0     0    0 ?        SW   Feb12   0:00 [khubd]
root       524  0.0  0.7  1364  492 ?        S    Feb12   0:02 syslogd -m 0
root       529  0.0  0.5  1300  364 ?        S    Feb12   0:00 klogd -x
rpc        543  0.0  0.6  1448  432 ?        S    Feb12   0:00 portmap
rpcuser    566  0.0  0.9  1488  564 ?        S    Feb12   0:00 rpc.statd

(以下、省略)


  さて、不要なデーモンのうち、まずは、portmapデーモンに注目してみた。
  portmapが何のデーモンかを調べてみる事にした。

  本にはNIS、NFSを有効にするデーモンだと書いてある。
  (SMTP認証の際に、dracを使う場合も、portmapデーモンは必要です)

  だが、もうちょっと踏み込んで見てみると

  RPCサービスを処理するためのデーモン

  だという。
  「RPCサービス」は、どこかで聞いた事がある。
  
  調べて行くと、Sun社がUNIX上動く物として開発したのが始まりだという。
  その技術は、Windowsでも使われているという。

  ここでRPCが何かを思い出した!

  Windowsで悪名高いポート135への攻撃の話につながる。

  2003年7月19日、NT-Committee2のセミナーが大阪で行われた。
  「UNIXな人たちが知るべきWindowsのセキュリティー対策」で
講師の伊原さんがポート135の問題点を話されていたのを覚えている。

  IISを使ってサーバーを立ち上げる場合、ソフトの依存性により
RPCサービスは立ち上げておく必要がある。

IISとRPCサービスとの依存性
IISとRPCサービスとの依存性


IISとRPCサービスとの依存性の問題を解決する方法
IISとRPCサービスとの依存性の問題を解決する方法
Windowsについているパケットフィルタリング機能を利用して
ポート135を閉じてしまえば、RPCポートを狙った攻撃を防ぐ事ができる。

  伊原さんの話を聞いた時、「IISには厄介な問題があるな」と思った。
  この講演から1ヶ月後に、RPCサービスを狙ったBlasterワームが出現した。

  だが、今回、LinuxにもRPCサービスがある事を知った。
  WindowsよりもUNIXの方が先にRPCサービスができた事も知った

  そこで、LinuxにおけるRPCの問題点を調べてみると、2001年に事件があった。

  Ramenワームの出現だった!!

  なんとなく覚えている。Linuxで初めてのワームだった話だ。
  RPCサービスへの攻撃を行う事を、出現から4年経って知ったのだった (^^;;

  もし、RPCサービスの脆弱性を狙った攻撃がWindowsだけのものだったら
反MSの私は、これをネタにして

  Windowsは危険だからLinuxに乗り換えましょう!

  と声を大にして叫ぶ所なのだが、Linuxにも同じような問題がある事を知り、
Linuxの安全性に説得力がないので、やめる事にした (^^;;


  さて、NFSに関連した不要なデーモンが他にもある。
  rpc.statデーモンだった。

  一体、何やねん?

  rpc.statデーモンは、RPCプロトコルを実装したサーバーソフトだという。

  だから、何やねん?

  NFSファイルロックサービスのrpc.lockdが利用するもので、
NFSサーバーがクラッシュから復帰した時に、ロック回復につとめるという。

  よくわからん・・・ (--;;

  だが、これだけはわかった。
  NFSを使わない場合は不要なデーモンだという事だ。

  そこで、rpc.statデーモンを眠らせるために

  chkconfig nfslock offを行い、起動時に動かなくした。


  その他の不要なデーモンも退治する事にした。

  プリンターデーモンを寝かせるためにchkconfig lpd offを行い
  ノートパソコン用の電力制御や検査を行うデーモンを寝かせるために
chkconfig apmd offを行った。

  これで不要なデーモンが立ち上がらなくなった。


  さて、RPCに関する物で、/etc/rpcファイルがある。
  RPCサービス名と、プログラム番号との対応表だという。

/etc/rpcファイルの中身(一部抜粋)
portmapper      100000  portmap sunrpc rpcbind
rstatd          100001  rstat rup perfmeter rstat_svc
rusersd         100002  rusers
nfs             100003  nfsprog
ypserv          100004  ypprog
mountd          100005  mount showmount

  全部、見て行くと、色々なプログラムがRPCを使っている事がわかる。
  RPCを使って何かを行う事が結構あるのだなぁと思ってしまう。

デーモンとプロセス

さきほど、不要なデーモンを見つけるため、何気なくps auxコマンドを使い、 プロセスを見てみたが、よく考えると、 デーモンとプロセスの違いって何? だった (^^;; プロセスなどのLinuxで普段出てくる用語で、何気なく使っているのだが、 いざ、人に説明する場合に、「これって何だったっけ?」がある。 つまり人に説明できるどころか、自分自身、全く理解していない事を 露呈しているのだ! そこで調べてみると、プロセスとは、次の意味だという。 カーネルの管理下で実行中のプログラムの事 デーモンがサーバープログラムの意味なので、実行中のデーモンは プロセスの中に含まれる事になる。 そのため、ps auxコマンドを使って実行中のデーモンを見る事ができる。 これで少し賢くなった (^^) プロセスの話が出てきた所で、特定のポートを開いているプロセスを 調べるために、lsofコマンドがある。 メールサーバーで、ポート25を開いているプロセスを調べてみる事にした。
lsofコマンドを実行
[root@server]# /usr/sbin/lsof -i:25
COMMAND   PID USER   FD   TYPE DEVICE SIZE NODE NAME
master  21788 root   11u  IPv4  83956       TCP *:smtp (LISTEN)
smtpd   25268 root    6u  IPv4  83956       TCP *:smtp (LISTEN)
[root@server]#
ポート25をオープンしているプロセスを見ると、postfixのデーモンが
表示された。メールデーモンがポート25を開いている事がわかる。

ちなみに、lsofコマンドの「-i」はポートを指定する
オプションです。

  他のポートでも見てみる事にした。

lsofコマンドを実行
[root@server]# /usr/sbin/lsof -i:23
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
telnet  2759 suga    3u  IPv4 127422       TCP 192.168.X.Y:2201->xxx.yyy.co.jp:telnet (ESTABLISHED)
xinetd  4568 root   10u  IPv4 137867       TCP *:telnet (LISTEN)
[root@server]# 
ポート23をオープンしているプロセスを見ると、telnetとxinetdが出てくる。
1行目のtelnetは、私が他のホストに接続している状態が表示されている。
2行目は、telnet接続を待ち受けている総合窓口のxinetdデーモンが表示されている。

  どのポートで、どんなプロセスが動いているのかが、わかるコマンドだ。

  少し突っ込んだ話として、プロセス名を指定して、指定したプロセスの状態を
調べる事もできる。
  そこで、実験サーバー(RedHat7.3の初期設定の状態)で見てみた。

lsofコマンドを実行
[root@server]# /usr/sbin/lsof -c xinet
COMMAND  PID USER   FD   TYPE     DEVICE    SIZE    NODE NAME
xinetd  4568 root  cwd    DIR        3,2    4096       2 /
xinetd  4568 root  rtd    DIR        3,2    4096       2 /
xinetd  4568 root  txt    REG        3,2  162092  389524 /usr/sbin/xinetd
xinetd  4568 root  mem    REG        3,2   89547  356945 /lib/ld-2.2.5.so
xinetd  4568 root  mem    REG        3,2   89424  356962 /lib/libnsl-2.2.5.so
xinetd  4568 root  mem    REG        3,2  173359 1200594 /lib/i686/libm-2.2.5.so
xinetd  4568 root  mem    REG        3,2   23575  356956 /lib/libcrypt-2.2.5.so
xinetd  4568 root  mem    REG        3,2   45415  356978 /lib/libnss_files-2.2.5.so
xinetd  4568 root  mem    REG        3,2   46117  356986 /lib/libnss_nisplus-2.2.5.so
xinetd  4568 root  mem    REG        3,2   16051  356975 /lib/libnss_dns-2.2.5.so
xinetd  4568 root  mem    REG        3,2   68925  356990 /lib/libresolv-2.2.5.so
xinetd  4568 root  mem    REG        3,2 1401027 1200592 /lib/i686/libc-2.2.5.so
xinetd  4568 root    0r   CHR        1,3           66385 /dev/null
xinetd  4568 root    1r   CHR        1,3           66385 /dev/null
xinetd  4568 root    2r   CHR        1,3           66385 /dev/null
xinetd  4568 root    3r  FIFO        0,5          137855 pipe
xinetd  4568 root    4w  FIFO        0,5          137855 pipe
xinetd  4568 root    5u  IPv4     137861             TCP *:login (LISTEN)
xinetd  4568 root    6u  IPv4     137862             TCP *:shell (LISTEN)
xinetd  4568 root    7u  IPv4     138023             TCP xxx.yyy.co.jp:2327 (LISTEN)
xinetd  4568 root    8u  unix 0xc7d80ae0          137857 socket
xinetd  4568 root    9u  IPv4     138026             TCP *:9098 (LISTEN)
xinetd  4568 root   10u  IPv4     137867             TCP *:telnet (LISTEN)
[root@server]# 
xinetdデーモンの起動状況がわかる。
上を見ると、どのデーモンの総合窓口になっているのか
起動している際に使っているライブラリーなどがわかる。

  lsofコマンドだが、ユーザーが使っているファイルも、わかるという。
  色々な事がわかるのだなぁと感心してしまった。

  ちょっと調べてみると、次の事もわかった。
  クラッカーがクラックに成功した後、裏口から侵入口(バックドア)を
仕掛ける事がある。
  バックドアを調べるのに、lsofコマンドが使われる事があるという。

  セキュリティーに関して勉強する上で、重要なコマンドだとわかった。

接続制限の設定 スーパーデーモン xinetd 利点・その2

さて、お待たせしました。xinetdデーモンを使う2つ目の利点の話を 書く事にします。 2つ目の利点には、セキュリティーが向上が挙げられます。 手軽でわかりやすい、telnetを使って実験を行う事にした。
実験の状況
セキィリティー向上の実験
waka側の/etc/xinetd.d/telnetファイルの設定
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
disable = no
flags = REUSE
socket_type = stream        
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
only_from = chiwawa
}
赤い部分はアクセスを許可するホスト名(IPアドレス)を記述します。
ここでは、chiwawa(チワワ)からのアクセスだけを許可してみた。

  すると、mayumiからの接続は拒否された。

  接続制限を行う場合、以下のような記述も可能だ。

接続許可の設定は、次の3種類の設定ができる
only_from = 192.168.1.0/24
only_from = 192.168.1.{1,34,120}
only_from = xxx.yyy.co.jp
1行目は、192.168.1.0/24のアドレスはの接続は許可
2行目は192.168.1.1、192.168.1.34、192.168.1.1.120の3つを許可
3行目は、xxx.yyy.co.jpからの接続は許可
192.168.1.0/24を許可したいが、192.168.1.253だけ拒否する場合
only_from = 192.168.1.0/24
no_access = 192.168.1.253
iptablesやファイヤウォールの設定みたいに、順番にはこだわらないようだ。

  xinetdの前身であるinetdだと、接続元の確認を行って
接続制限を行う事ができないので、セキュリティー向上につながる。


  次に、サーバープログラムの実行ユーザー名の指定変更を行ってみる。
  telnetは、root権限で動くのだが、ここでsugaでやってみる事にした。

実験の状況
telnetの接続実験の様子
waka側の/etc/xinetd.d/telnetファイルの設定
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
disable = no
flags = REUSE
socket_type = stream        
wait = no
user = suga
server = /usr/sbin/in.telnetd
log_on_failure += USERID
}

  結果は、接続できへんかった

エラーの内容
[suga@mayumi]# telnet waka
Trying 192.168.1.10...
Connected to 192.168.1.10.
Escape character is '^]'.
Red Hat Linux release 7.3 (Valhalla)
Kernel 2.4.X on an i686
login: -h for super-user only.
Connection closed by foreign host.
[mayumi@suga]# 

  telnetでは、実行ユーザーはrootでないとダメだという事だが、
他のデーモンは、rootである必要でない場合は、安全を確保するために
root以外のユーザーにする必要があるし、それがxinetdを使うと
可能だという事がわかった (^^)


  次に、時間帯による接続制限ができるという。

telnetの接続実験の様子
waka側の/etc/xinetd.d/telnetファイルの設定
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
disable = no
flags = REUSE
socket_type = stream        
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
access_times = 10:00-16:00
}
10時〜16時までの間だけ、接続を許可する設定だ。

  もちろん、その時間帯にアクセスすると許可されるし、
それ以外の時間帯だと拒否される。もちろん、確かめました (^^)

  もし、深夜11時〜4時までの間の場合、0時をまたぐため、次の設定となる。

  access_times = 0:00-4:00 23:00-23:59

  なんだか奇妙な設定のような気がするが・・・。
  だが、これは実験で確認する事はしなかった。

  夜中に確かめるなんて、しんどいもーん (^^)

  システムの障害で徹夜はやっても、単なる実験のためでは徹夜はしない!!
  そうなのです。30越えると徹夜はしんどいのです (^^;;


  次にサーバーへの接続数の制限について見てみる事にした。

telnetの接続実験の様子
waka側の/etc/xinetd.d/telnetファイルの設定
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
disable = no
flags = REUSE
socket_type = stream        
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
instances = 2
}
赤い部分は、同時接続を2台にする設定です

  さて、3ヶ所からtelnetで接続してみたら・・・

  3ヶ所目からの接続は拒否された!

  接続制限の機能は、色々、応用できる。
  ftpサーバーで、サーバーの負荷の軽減のため、接続制限する事が可能だし、
もちろん DoS攻撃防止にもなる。


  他にも設定できる。
  プロトコルの選別、ポート番号の指定、ソケットの指定がある。
  だが、今回は割愛しまーす。

  だって、そんな高度設定する事ないもーん (^^)V


  なぜ、xinetdがセキュリティー的に優れていると言われるのか。
  inetdを調べてみたら、アクセス制限や時間帯による制限、接続台数の制限は
全くないため、xinetdの方がセキュリティー面で優れていると言われている。

  「inetd + TCP Wrapperの組み合わせを使えば、ええやん」という意見も
あるかと思います。
  私は、それでも良いと思います。この辺りの話は使い勝手の問題で
個人の好みが反映されますので、使ってみたい方が良いと思います。


最後に rcpを使おうと思った事がキッカケで、xinetdの事を知りました。 /etc/servicesのファイルが何かを知る事もできました。 lsofコマンドの存在も知る事ができました。 この辺りの話はセキュリティーの面でも重要になってくるので、 是非、私ように放置するのではなく、勉強される事をお薦めします!

次章:「安全にログイン。暗号化通信・SSHの設定入門」を読む
前章:「ヤマハルーターRTX1000の設定入門」を読む
目次:Linux、オープンソースで「システム奮闘記」に戻る