けんども日記: カテゴリ: server

カテゴリ: server のエントリを新しい順に 20 件まで表示します。 21 件以上ある場合、それらは省略されます。

2010-09-14

さくらのＶＰＳでＳＥＬｉｎｕｘを有効にする

話題のさくらのＶＰＳを借りた。すでにレビューや初期設定に関する情報は他にたくさんあるので、ここでは少々マニアック（？）な話題を。 ＫＶＭならディスクやＮＩＣは virtio だとおもったら、ここは完全仮想化（ゲストの汎用性を考えて？）。

さて、せっかくＣｅｎｔＯＳ５で完全仮想化なのに、ＳＥＬｉｎｕｘが無効化されているのはもったいない。 ＳＳＨのアクセス制限等の基本的な設定が終わってから、すぐにＳＥＬｉｎｕｘを有効にすることにした。

まず、初期状態でもラベルはある程度ついているが、怪しいのでこれは再ラベル必要か。

# ls -lZ /
drwxr-xr-x  root root system_u:object_r:bin_t:s0       bin
drwxr-xr-x  root root system_u:object_r:boot_t:s0      boot
drwxr-xr-x  root root                                  dev
drwxr-xr-x  root root system_u:object_r:etc_t:s0       etc
drwxr-xr-x  root root system_u:object_r:home_root_t:s0 home
drwxr-xr-x  root root system_u:object_r:lib_t:s0       lib
drwxr-xr-x  root root system_u:object_r:lib_t:s0       lib64
drwx------  root root                                  lost+found
drwxr-xr-x  root root system_u:object_r:mnt_t:s0       media
drwxr-xr-x  root root system_u:object_r:mnt_t:s0       misc
drwxr-xr-x  root root system_u:object_r:mnt_t:s0       mnt
drwxr-xr-x  root root system_u:object_r:usr_t:s0       opt
dr-xr-xr-x  root root                                  proc
drwxr-x---  root root root:object_r:user_home_dir_t:s0 root
drwxr-xr-x  root root system_u:object_r:sbin_t:s0      sbin
drwxr-xr-x  root root system_u:object_r:file_t:s0      selinux
drwxr-xr-x  root root system_u:object_r:var_t:s0       srv
drwxr-xr-x  root root                                  sys
drwxrwxrwt  root root system_u:object_r:tmp_t:s0       tmp
drwxr-xr-x  root root system_u:object_r:usr_t:s0       usr
drwxr-xr-x  root root system_u:object_r:var_t:s0       var

ということで、次回起動時にラベルの再付与できるように。

# touch /.autorelabel

その際はＰｅｒｍｉｓｓｉｖｅモードで起動できるように、/etc/selinux/config を書き換えておく。

#SELINUX=disabled
SELINUX=permissive

再起動すると起動中にラベルが再付与される。コントロールパネルのリモートコンソールで次のようなメッセージを確認。

*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.
/sbin/setfiles:  labeling files under /
******************************************** 

ログインしてＰｅｒｍｉｓｓｉｖｅモードになっていることを確認。

# getenforce 
Permissive

続いて、ＳＳＨのポートを変えてみよう。安全にＳＳＨを使うために、接続元の制限や公開鍵認証をするのは当然として、あわせてポートも変えておきたい。このようなサービスのポートを変更するのはＳＥＬｉｎｕｘのポリシに違反するので、対応が必要。例として 10022 番ポートにする（本当はもっとわかりにくいものを設定している）。これで /etc/ssh/sshd_config でポートを変更してもｓｓｈｄを立ち上げることができる。

# semanage port -a -t ssh_port_t -p tcp 10022

sermanage コマンドで ssh_port_t タイプのポートで 10022 が追加されていることを確認。

# semanage port -l|grep ssh
ssh_port_t                     tcp      10022, 22

さくらのＶＰＳでは標準では auditd が起動していないので、ＳＥＬｉｎｕｘに関するログは /var/log/messages や dmesg で確認ができる。ログを確認して問題がないようであれば、Ｅｎｆｏｒｃｉｎｇモードに切り替える。

# setenforce 1
# getenforce 
Enforcing

起動時にＥｎｆｏｒｃｉｎｇモードとなるように、 /etc/selinux/config も書き換える。

#SELINUX=disabled
#SELINUX=permissive
SELINUX=enforcing

これで再起動して動作に問題がなければＯＫ。さくらのＶＰＳの場合、リモートコンソールがあるので、万一ＳＥＬｉｎｕｘの設定をミスして起動できなくなっても安心（GRUB で enforcing=0 すればよい）。

ＳＥＬｉｎｕｘを有効にしたからセキュリティは万全というわけでもないし、運用も面倒だったりするのだけど、何もしないよりは安心できる気がする。

自分が設定したサーバを他人へ提供する場合、ＳＥＬｉｎｕｘの運用は難しい。例えば、初期状態ではＷｅｂアプリケーションがＤＢに接続したり、ネットワークを介して外部へ接続することすらできない。かといって、httpd_t に対して何でも許可してしまうと、ＳＥＬｉｎｕｘを有効にしている意味が薄れるので、ユーザが何をしたいのかをすべて把握する必要がある。それに対して、自分が使うサーバであれば、好きなように設定ができる。

わからずにＳＥＬｉｎｕｘを有効にしていると「ホームディレクトリから移動したファイルがＡｐａｃｈｅで表示できない」「ポートを変更したらサービスが起動しない」「DocumentRoot を変更したらＡｐａｃｈｅが起動しない」「ＦＴＰでファイルが転送できない」なんてことになるので、ＳＥＬｉｎｕｘが悪者扱いされることが多いのは残念。

2004-12-09

ネットワークを監視する信号灯

株式会社パトライトのニュースレターより、同社はネットワークやデバイスの監視をし、異常や障害を光と音とメールで通知できる信号灯を発売した。 SNMP プロトコルに対応し、 SNMP Trap を受けて異常を通知したり、 rsh コマンドによる制御、 Ping による監視もできるという。 詳細はパトライトのネットワーク対応製品を参照。

私は既に信号灯とリレーユニットを組み合わせた信号等による監視システムというものを作っている。私が構築した監視システムは、リレーユニットをシリアルポート経由で制御するもので、必ず Linux が稼働するコンピュータが 1 台必要となる。その上、制御する際のソフトウェアも自分で作る必要があった (簡単な Perl スクリプトで十分制御できるのだけど) 。これに対し、ネットワークに対応した新製品は単体で高度な機能を備えていることになる。もちろん、リレー制御の監視システムであればコンピュータ制御のため、ソフトウェア次第で新製品以上の機能を持たせることも可能だが、開発の手間を考えると、ネットワークの監視に特化するならば新製品の方がよいかもしれない。高さ 170mm と 262mm の 2 タイプがあり、価格はいずれも税込み 57,750 円。ちなみに、リレー制御でも 4 万円かかった。これらの製品はオンラインショップ、ぱっとクルで購入できる。

2004-08-12

squid を導入

常時接続の手段がこれしかないので仕方なしにフレッツ ISDN を使っている。少しでも快適な WWW 閲覧ができるように squid を入れることにした。 Debian なのでインストールは apt-get install squid だけで OK 。その他 /etc/squid/squid.conf で変更した箇所をメモしておく。

プロクシを導入したら、「診断くん」「確認くん」などを利用して漏れる情報を知っておくとよいだろう。

さて、導入後とても快適に WWW 閲覧ができるようになった。 WWW ブラウザのキャッシュサイズを増やしても画像などがうまくキャッシュされないことがあったため、頻繁に閲覧する WWW サイトなどは特に軽く感じられるようになった。

2004-05-03

mod_dir を外してみる

Apache の動作で個人的に少し気に入らないのは、ディレクトリ名のスラッシュを外して呼び出した場合に、スラッシュを補った URI へ飛ばすというものだ。

便利なのだが、おせっかいな感じがしてあまり好きではない。この機能は mod_dir に含まれているらしい。何も指定しなくても標準で組み込まれる。しかし、この mod_dir にはもっと重要な役割がある。ディレクトリ名もしくはサーバ名のみでリクエストした場合、 DirectoryIndex ディレクティブに指定されたファイルを表示するというものだ。普通、これは index.html や index.php などを指定する。このサイトも http://home.kendomo.net/ だけで呼び出したときは index.php の内容を返しているのだ。つまり、単純に mod_dir を外してしまえば、ディレクトリ名のスラッシュ省略時のリダイレクトはなくなるが、ディレクトリ名やサーバ名だけでリクエストしても表示されなくなってしまう。

それでも Apache の豊富な機能次第で何とかなるだろう。テスト用のマシンに Apache 2.0.49 を入れて試すことにした。とりあえず ./configure の際、 mod_dir をモジュール化し、後からそれを外してみた。すると、ディレクトリ名で呼び出すと、 Not Found になってしまった。それに対応すべく、まずは Alias ディレクティブを使ってみた。

これだと目的のページの index.shtml だけはディレクトリ名で呼び出せるのだが、そのディレクトリ内のファイルを呼び出そうとしても内部ではすべて index.shtml が含まれてしまうことになる。つまり、ディレクトリ内の他のファイルは読めなくなってしまう。続いて Rewrite を試した。こちらは柔軟性が高い。

これでうまくいった。しかし、ディレクトリ毎にこんなことをするのはとても効率が悪い。次のようにすればどのディレクトリにもマッチする。

ただし、全てのディレクトリに index.shtml が置いてあるわけではない。 index.php や index.html もあるのだ。やはり個別に対応するしかないのか。

公開用のサーバで使うにはもう少し調べた上で検討したい。

2004-03-20

Apache 2.0.49 リリース

Apache 2.0.49 がリリースされた。今回は深刻なセキュリティホールが発見されたわけではなく、バグの修正らしい。

さっそくアップグレード。 home.kendomo.net の Web サーバでは ServerTokens を Full にしてバージョン情報を隠していない。これはアップデートを怠っていないことを表すためでもある。

2004-02-21

MRTG で RTA55i のトラヒックを表示

ヤマハの RTA55i というルータを使ってフレッツ ISDN に接続している。負担をかけるとすぐに動作が不安定になる困ったルータでもある。何気なく MRTG 関係の調べものをしていると、このルータのトラヒックを MRTG で表示する方法を見つけた。

• MRTG with RTA55i (2nd)

トラヒックの取得は SNMP を使うイメージしかなかったのだが、民生用の RTA55i には SNMP など備わっていない。ステータスを表示するコマンドを使ってルータの管理ページから値を取得するなんて全く思いつかなかった。 Wget を次のように使う。

これはルータの管理画面で show status pp 1 というコマンドを入力したことに相当する。続いて、直前のコマンドの実行結果を取得。

Web ブラウザ向けに出力されるページ故、余計なコードがくっついてきてしまうが、この中に送受信されたパケットが含まれている。参考ページに従い、あらかじめ次のように出力結果をアスキーで出力しておくようにすると処理しやすいかもしれない。

あとは Perl で処理する。先ほどの Wget を system 関数で呼び出せば 1 つのスクリプトに収まる。

open(IN, "/tmp/rta55i");
flock(IN, 2);
my @lines = <IN>;
close(IN);
my ($line1, $line2);
for (my $i = 0; $lines[$i]; $i++) {
  my $packets = $lines[$i];
  if ($packets =~ /Received.*\[ *([0-9]+) *octet/) { $line1 = $1; }
  if ($packets =~ /Transmitted.*\[ *([0-9]+) *octet/) { $line2 = $1; }
}

print "$line1\n$line2\n\n\n";
exit;

mrtg.cfg に以下を追加。

Target[rta55i_pp01]: `スクリプトを絶対パスで指定`
MaxBytes[rta55i_pp01]: 1250000
Title[rta55i_pp01]: Traffic Analysis
PageTop[rta55i_pp01]: <h1>Traffic Analysis</h1>

しばらくファイルをダウンロードした後に生成されたグラフを確認したところ、フレッツ ISDN の帯域である 60kbps 付近をマークした。信用できそうな値が取得できているようだ。

• MRTG によるグラフ

2004-02-16

メールサーバのエラーログ

メールサーバに限らず、問題があったらログをメールで受け取れるようにしている。妙なログが何度もあったので調べてみると…。

1. スパムメールが foo@kendomo.net へ送りつけられる。
2. foo というユーザは存在しない。
3. MTA はスパムメールの From に Undelivered Mail を送る。
4. From のアドレスのサーバが見つからない。
5. spool に残り、何度か送ろうとする。何度もエラー。

2004-01-08

カーネルのアップデート

外部公開用サーバとクライアント兼ファイルサーバのカーネルをアップデートした。今回のセキュリティホールはローカルユーザがroot 権限を不正に取得可能な不具合らしいので急ぐことはなかったかもしれないが、気分的にアップデートしておきたかった。順調に伸ばしていた uptime が降り出しに戻ってしまうのはいつもながら悲しいけど。

2004-01-05

natcracker 来年でサービス休止

natcracker が 2005 年 1 月末でサービスを休止してしまうらしい。それはかなり困る。どうしよう。私が natcracker を使っていた理由は手軽な料金で固定 IP アドレスが使えることと、サーバとクライアントで異なる IP アドレスを使いたかったため。残念でならない。代わりのサービスを探さなければ。

• natcrackerサービス休止のお知らせ

2003-12-16

自宅サーバの監視

natcracker を使うようになってから、自宅サーバーWebRing のログ情報のページで私のサーバがダウンしているとみなされる回数が増えた。このウェブリングに登録すると、無料で Web サーバの監視をしてくれるのだ。同じくこの監視サービスの「無応答のため…」という内容のメールも来るようになった。フレッツ ISDN だけだとプロバイダとの接続が切れた時しかダウン扱いにならなかったので、原因は natcracker の可能性が高い。フレッツ ISDN だけでサーバを立ち上げていた頃は帯域をいっぱいに使ってもダウン扱いにはならなかった。しかし、今はダウンロードなどで帯域をいっぱいに使った際、 natcracker 経由で応答できない場合があることを確認している。フレッツ ISDN では少し厳しいのかもしれない。

こんな状態なので、できれば外部から更に詳細な監視がしたくなり、監視専用として安い共用のレンタルサーバを探してみるが、条件にあうサービスが見付からない。

1. 月 1000 円以内
2. サブドメインの持ち込み利用が可能
3. cron が自由に設定できる
4. Perl と PHP が使用可能
5. できれば PostgreSQL も使用可能

いくらなんでも 1000 円以内でこれは無理か。かといって監視専用にそれ以上使いたくない。 XREA の有料版が条件に近いが、 cron の実行が 1 日 3 回までなので監視には使えない。

カーネルログが記録されない?

natcracker を使うようになってから、 iptables を使っている。グローバル IP アドレスが割り当てられるため、使わないと恐い。しかし、 iptables のログはいつもコンソール上にでているだけで、ログファイルには記録されない。真っ先に iptables の設定を疑った。しかし、コンソールにでるのだから問題はないはず。

iptables はカーネルの機能なので、カーネルログ /var/log/kern.log を開いてみると、空だった。その前のログファイルである kern.log.0 は先日カーネルを再構築した日で止まってしまっている。もしかすると先日カーネルを再構築したのが問題かも知れない。原因を調べ、また再構築しなければならないのかと思った。念のため、さまざまなキーワードで更に Google 検索。

すると、 2ch の過去ログで同じようにログが記録されないという悩みの方が! その方は klogd を再起動して直ったとのこと。私も klogd を再起動してみる。すると、記録されるようになったではないか。私は /etc/syslog.conf を書き換えた後、 sysklogd しか再起動していなかった。それが原因らしい。これでようやく寝れる。

2003-12-13

再び natcracker で

やっと準備完了。何の準備かというと、 home.kendomo.net を再び natcracker を使って公開することだ。おとといから作業を進めていたのだが、途中でトラブルもあり、時間がかかってしまった。再び natcracker を使おうと思ったのは、やはり固定 IP アドレスが使えること。それに、せっかく契約しているのだから使わないのはもったいない (もっとも、年契約なので途中で解約できない) 。

PC にグローバル IP アドレスが割り当てられるので、気を使ったつもり。カーネルの再構築、 iptables の設定、もし切断されたときに再接続するスクリプトの作成、さらに接続状態を Web で確認したり、切断されたときにメールを送るスクリプトも作成。通常なら vtun は自動で再接続するようなので再接続スクリプトを今用意する必要はなかったかもしれないけど。

2003-11-11

Slot1 CPU で静音化

以前中古で購入した PC の CPU は Slot1 なのだが、ファンの音がとても静か。ヒートシンクが大きいので、ファンはそれほど強力なものでなくてもよいだろうか。普段使っている PC も Slot1 にすれば静かになるに違いない。

そんなわけで、先日ヤフオクで Asus の Slot1 対応マザーボード P3B-F を落札。それが届いた。チップセットは今まで使っていた CUBX と同じ 440BX だ。 CPU は中古の PC についていた Pentium 3 の 600EMHz を使うことにしたので、スペックも上がることになる 。交換後、電源を入れてみると、今まで耳障りだった音がしなくなり、聞こえるのはケースファンの音だけとなった。交換したのはマザーボードと CPU だけなので、 OS の再インストールの必要はなかった。

だがひとつ問題が発生した。今までの CUBX は IDE の接続口が 4 つあったため、 /dev/hdi と認識されていた HDD が /dev/hde になってしまった (ATA カードを使っている) 。 swap パーティションのマウントに失敗してしまったので、 /etc/fstab の該当部分を 編集することになった。

2003-11-08

Debian で公開開始

Debian で公開するあたり、 Snort、 Swatch、 Webalizer をインストールして設定。ルータの静的 NAT の設定を変更してついに公開開始。何かあったときにメールを送るようにしてあるのだが、それ以外にもビープ音でも知らせるようにしたい。しかし、 PC 本体にスピーカが付いていないのだ。

2003-11-07

メールサーバメモ

メールサーバの設定を行う。 MTA は Postfix 、POP3 は qpopper だが、 POP before SMTP を使うために qpopper-drac と drac をインストールした。この他に APOP の設定設定も行った。

## APOP 設定メモ
# touch /etc/pop.auth
# popauth -init
Really initialize POP authentication DB? yes
# popauth -user ユーザ
Adding only APOP password for ユーザ
New password:
Retype new password:

## root や postmaster に届いたメールを受け取る
/etc/aliases に
postmaster:    root  # これは最初からあるはず
root:   ユーザ # これを追加

# newaliases
Postfix を再起動