すでに動いているシステム上でサービスを安全にする方法は 2 通りあります:
ある場所からのみアクセスできるようにサービスを制限するのはカーネルレベルで (すなわち、ファイアウォールで) アクセスを制限すること、あるインターフェイスに だけ応答するように設定すること (この機能を提供しないサービスもあります) またはその他の方法を使うことによって可能です。たとえば linux vserver パッチは プロセスがインターフェイスをひとつしか使わないように強制するのに使えます。
inetd
から起動されるサービス (telnet、ftp、finger、pop3...) に
ついて言えば、inetd はサービスがあるインターフェイスにだけ応答するように
設定することはできないことには言及する価値があります。しかし、その代用品で ある
xinetd
メタデーモンはちょうどこれに使える bind を
含んでいます。xinetd.conf(5)
をごらんください。
service nntp { socket_type = stream protocol = tcp wait = no user = news group = news server = /usr/bin/env server_args = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin +/usr/sbin/snntpd logger -p news.info bind = 127.0.0.1 }
以下の章は特定のサービスを意図されている用途にしたがってどのように適切に 設定できるかの詳細を論じます。
もし ssh のかわりにまだ telnet を動かしているなら、このマニュアルを読むのを やめてそれを変更するべきです。リモートログインにはすべて telnet のかわりに Ssh を用いるべきです。インターネットのトラフィックを盗聴して平文の パスワードを得ることが簡単にできる時代には、暗号を使うプロトコルだけを 使うべきです。よって、あなたのシステムでただちに apt-get install ssh を実行しましょう。
あなたのシステムのすべてのユーザに telnet のかわりに ssh を使うことを
すすめましょう。よりよいのは telnet や telnetd をアンインスールすることです。
さらに ssh を使って root
としてシステムにログインすることを避け、su や sudo
のような、root になるためのかわりの手段を使いましょう。
最後に、セキュリティを向上させるために /etc/ssh
中のファイル
sshd_config
を 変更するべきです:
ふたつ以上のインターフェイスがあるかもしれないので (そこで ssh を利用 可能にはしたくないなら)、または将来新しいネットワークカードを追加するのに そなえて (そしてそこからの ssh 接続を望まないなら)、ssh をある インターフェイスにだけ応答するようにしましょう。
可能なら Root のログインをいつでも禁止するべきです。ssh 経由で root に なりたいなら、こうすると 2 回のログインが必要になり、root のパスワードを SSH 経由で力まかせに推測することができなくなります。
要求を受けつけるポートを変更し、ssh デーモンが動いているのか侵入者には はっきりわからないようにしましょう。
空のパスワードはシステムのセキュリティをだいなしにします。
特定のユーザだけが ssh 経由でこのマシンにアクセスできるようにしましょう。
特定のグループのメンバーだけが ssh 経由でこのマシンにアクセスできるように しましょう。AllowGroups と AllowUsers にはアクセスを拒否するための同様の ディレクティブがあります。驚くべきことでもなく、それは「DenyUsers」や 「DenyGroups」と呼ばれています。
何をしたいかは完全にあなたが選べます。ssh の鍵をファイル ~/.ssh/authorized_keys に置いているユーザからのマシンへのアクセスだけを 許可するほうがより安全です。もしそうしたいなら、これを「no」に設定して ください。
最後に、これらのディレクティブは OpenSSH のものであることに注意してください。 現時点では、広く使われている SSH デーモンは 3 種類あります。ssh1、ssh2 そして OpenBSD の人たちによる OpenSSH です。Ssh1 は利用できる最初の ssh デーモンでした。そして依然として最も広く使われています (windows への 移植版さえあるといううわさです)。Ssh2 はソース非公開のライセンスで リリースされていることを除けば ssh1 より多くの長所があります。OpenSSH は 「ssh」が選択されたとき Debian にインストールされるバージョンです。
SSH を PAM サポートとともに設置する方法についてくわしくは security
mailing list archives
をごらんください。
Squid は最も有名なプロキシおよびキャッシュサーバです。そして考えるべき
セキュリティ問題がいくつかあります。Squid のデフォルトの設定はユーザからの
すべての要求を拒否します。/etc/squid.conf
の Access Control List
を定義して信用できるユーザ、ホストまたはネットワークからの
アクセスを許可するように Squid を設定するべきです。ACL 規則を定義することに
ついてくわしくは Squid User's
Guide
をごらんください。
さらに、適切に設定されていなければ、だれもがメールを Squid を通じてリレーする ことができます。なぜなら、HTTP プロトコルと SMTP プロトコルは同じように 設計されているからです。Squid のデフォルトの設定ファイルでは 25 番ポートへの アクセスは禁止されています。もし 25 番ポートへの接続を許可したいなら それを Safe_ports リストに追加するだけです。しかし、これは推奨されて 「いません」。
プロキシおよびキャッシュサーバを適切に設置して設定することはあなたのサイトを 安全に保つことの一部にすぎません。他に必要な仕事には何事もそうあるべきように 動いていることを確実にするため Squid のログを解析することがあります。 Debian GNU/Linux には管理者がこれを行うのを助けるパッケージがいくつかあります。 以下のパッケージが woody (Debian 3.0) で利用可能です:
calamaris
- Log analyzer for Squid or Oops proxy log files.
modlogan
- A modular logfile analyzer.
sarg
- Squid Analysis Report Generator.
FIXME: Squid Accelerator Mode のセキュリティについての情報をさらに追加する。
本当に FTP を (sslwrap でラップしたり、SSL や SSH のトンネルを通さずに)
使わなければいけないならば、
ユーザが自分のディレクトリ以外のどんなものも見ることができないように ftp を ftp
ユーザのホームディレクトリの内部へ chroot するべきです。そうしないと
ユーザはシェルを持っているかのようにあなたのルートファイルシステムをうろつく
ことができます。この chroot 機能を有効にするには proftpd.conf
のグローバル セクションに以下の行を追加することができます:
DefaultRoot ~
/etc/init.d/proftpd restart で proftpd を再起動して ホームディレクトリから逃げだせるか確かめてください。
../../.. を使った Proftp DoS 攻撃を防ぐには、以下の行を
/etc/proftpd.conf
に追加してください。
DenyFilter \*.*/
FTP はログインや認証のパスワードを平文で送っていること (これは匿名の公共
サービスを提供しているのなら問題ではありません) および Debian にはよりよい
代用品があることをいつもおぼえておいてください。たとえば、sftp
(ssh
パッケージによって提供されます)。他の
オペレーティングシステムのためのフリーな SSH 実装もあります: たとえば putty
や
cygwin
です。
しかし、ユーザに SSH 経由でアクセスさせようとしながら FTP サーバも維持するなら
典型的な問題にでくわすかもしれません。SSH で安全にされたシステムの内部にある
匿名 FTP サーバにアクセスするユーザはその FTP サーバにログイン
しようとするかもしれません。このアクセスは拒否されるでしょうが、それでも
パスワードが平文でネット上を流れることになります。これを避けるために、 ProFTPd
の開発者である TJ Saunders さんはユーザが匿名 FTP サーバに有効な SSH
アカウントを送ることを防ぐパッチを作りました。より多くの情報およびその
パッチがここで入手できます: ProFTPD Patches
今日では、X 端末はひとつのサーバが多くのワークステーションで必要とされる 多くの企業で使われています。これは危険かもしれません。なぜならファイルサーバに クライアント (X の観点からは X サーバです。X はクライアントとサーバの定義を 入れかえています) への接続を許可する必要があるからです。もし多くの文書に ある (非常に悪い) 提案にしたがうなら、あなたのマシンで xhost + と 入力することになります。これはすべての X クライアントにあなたのシステムへの 接続を許可します。すこしだけセキュリティをよくするには、特定のホストからの アクセスだけを許可するためにかわりに xhost +hostname コマンドを 使うことができます。
しかし、さらに安全な解決法は X をトンネル化してセッション全体を暗号化する
ために ssh を使うことです。これは他のマシンに ssh すると自動的に行われます。
これは /etc/ssh/ssh_config
で X11Forwarding を
yes に 設定することによって有効にしておく必要があります。SSH
の時代では xhost にもとづくアクセス制御を完全に廃止するべきです。
最高のセキュリティのためには、他のマシンからの X アクセスが必要ないなら、 こう入力して tcp の 6000 番ポートをバインドすることを停止することです: startx -- -nolisten tcp
注意: これは Xfree 4.0 (Debian 3.0 で提供される X サーバです) の
デフォルトのふるまいです。もし Xfree 3.3.6 を動かしているなら (すなわち、
Debian 2.2 をインストールしているなら)、/etc/X11/xinit/xserverrcc
を編集してこのような行を追加できます:
#!/bin/sh exec /usr/bin/X11/X -dpi 100 -nolisten tcp
XDM を使っているなら /etc/X11/xdm/Xservers
を次のように
してください: :0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp
X Window のセキュリティについてくわしくは XWindow-User-HOWTO
(/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz
)
をごらんください。
FIXME: これを行うために XFree 3.3.6 の設定ファイルをどう変更するべきかに ついての debian-security スレッドの情報を追加する。
もしローカルで使うためだけに (つまり、きれいなグラフィカルログインのために) ディスプレイマネージャをインストールしたいなら、XDMCP (X Display Manager Control Protocol) 関連を停止しましょう。XDM ではこれは /etc/X11/xdm/xdm-config のこういう行で行うことができます。
DisplayManager.requestPort: 0
ふつう、Debian ではすべてのディスプレイマネージャはデフォルトでは XDMCP サービスを開始しないよう設定されています。
職場に着いたとき、だれかがあなたのラインプリンタデーモンに DoS しているせいで プリンタが紙を際限なくはきだしているとしましょう。いやでしょう?
unix の印刷アーキテクチャでは、クライアントのデータをホストの印刷サーバに
送る方法がなければなりませんでした。伝統的な lpr
と
lp
では、クライアントコマンドはデータをスプールディレクトリに
コピーするか、データへの symlink を作ります (だからこれらのプログラムは ふつう
SUID または SGID になっているわけです)。
問題がなにもないようにするにはプリンタサーバを特に安全にするべきです。
これは信用されているサーバからの
接続のみを許可するようプリンタサービスを設定する必要があるということです。
これを行うには、印刷を許可したいサーバを /etc/hosts.lpd
に
追加してください。
しかし、これを行っても、lpr
デーモンは 515
番ポートへの外部からの接続をどの
インターフェイスからでも受けつけます。印刷を許可されていないネットワーク
(またはホスト) からの接続をファイアウォールで防ぐことを検討するべきです
(lpr
デーモンは特定の IP アドレスにのみ応答するようには
制限できません)。
lpr
より Lprng
を優先するべきです。 なぜなら IP
アクセス制御を行うように
設定できるからです。そしてどのインターフェイスをバインドするか (やや奇妙な
やり方ですが) 指定できます。
もしあなたのシステムでプリンタを使っているが、ローカルでのみ使っているなら、
そのサービスをネットワークで共有したくはないでしょう。/dev/lp0
デバイスのユーザパーミッションにもとづく cups
とか PDQ
によって提供されるような他の印刷 システムを使うことを検討することができます。
cups
では、印刷データは http プロトコルでサーバに
送られます。これはクライアントプログラムは特権を何も必要としないが、
サーバがどこかのポートで応答する必要があるということです。
しかし、cups
を使いたいが、ローカル専用にしたいなら、
/etc/cups/cupsd.conf
をこのように
変更することによってループバックインターフェイスをバインドするように
設定できます:
Listen 127.0.0.1:631
この設定ファイルにはネットワークやホストを受けつけたり拒否したりするなどの
多くの他のセキュリティオプションがあります。しかし、必要がないなら
応答するポートを制限するだけのほうがよいでしょう。Cups
は HTTP
ポートを通じて文書も提供します。外部の攻撃者に役に立つかもしれない
情報を明らかにしたくないなら (そしてポートをあけておきたいなら)、これ
追加しましょう:
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 </Locationi>
この設定ファイルは SSL/TLS 証明書や暗号を含むより多くの機能を追加するように 変更できます。http://localhost:631/ または cups.org にマニュアルがあります。
FIXME: 内容をさらに追加する (Amateur
Fortress Building
の記事は非常に興味深い意見を 提供している)。
FIXME: PDG が Debian で利用可能か調べて、もしそうなら、これをよりよい 印刷システムとして提案する。
FIXME: Farmer/Wietse がプリンタデーモンのかわりになるものを持っているか、 それが Debian で利用可能か調べる。
あなたのサーバがメールシステムでなければ、メールデーモンが外部からの接続に 応答する必要は本当はありませんが、たとえば設置している警告システムからの root ユーザへのメールを受けとるなどのために、ローカルのメールが配達される ようにしたいかもしれません。
Debian システムでこれを行うには、smtp デーモンを inetd から除かなければ ならないでしょう:
$ update-inetd --disable smtp
そして loopback インターフェイスにのみ応答するようにメーラデーモンを
設定します。exim (デフォルトの MTA) ではこれは /etc/exim.conf
ファイルを編集して以下の行を追加することによって行えます:
local_interfaces = "127.0.0.1"
両方のデーモン (inetd と exim) を再起動すると exim は 127.0.0.1:25 ソケットに のみ応答するようになります。注意してください、最初に inetd を停止しましょう。 そうしないと exim は起動しません。なぜなら inetd デーモンがすでに外部からの 接続を扱っているからです。
postfix については /etc/postfix/main.conf
をこう編集しましょう:
inet_interfaces = localhost
もしローカルのメールだけが望みなら、この方法はメーラデーモンに tcp wrapper を
使ったりファイアウォールの規則を追加してアクセスを制限したりするのより
よいです。しかし、他のインターフェイスにも応答させる必要があるなら、inetd から
起動して、外部からの接続を /etc/hosts.allow
と
/etc/hosts.deny
でチェックできるよう tcp wrapper を追加することを
検討してもいいです。そして、上で述べたような方法のどれかで記録するように
正しく設定していれば、許可されていないアクセスがメーラデーモンに対して
いつ行われようとしたかわかるでしょう。
メールを読んだり受けとったりするのは最も一般的な平文のプロトコルです。 メールを受けとるのに POP3 か IMAP を使っていれば、平文のパスワードを ネット経由で送っているので、今後ほとんどだれでもあなたのメールを読むことが できることになります。かわりに、メールを受けとるのに SSL (Secure Sockets Layer) を使いましょう。POP または IMAP サーバとして働いているマシンに シェルアカウントを持っていれば、ほかの選択肢は ssh です。これををやって みせる基本的な fetchmailrc がこれです:
poll my-imap-mailserver.org via "localhost" with proto IMAP port 1236 user "ref" there with password "hackme" is alex here warnings 3600 folders .Mail/debian preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref my-imap-mailserver.org sleep 15 </dev/null > /dev/null'
preconnect が重要な行です。これは ssh セッションを開始して必要なトンネルを 作ります。それが自動的に localhost の 1236 番ポートから IMAP メールサーバへの 接続を暗号化して転送します。ほかの可能性は ssl 機能つきの fetchmail を 使うことです。
POP や IMAP のような暗号化されたメールサービスを提供したいなら、 apt-get install stunnel してデーモンをこのように起動してください:
stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd
これは与えられたデーモン (-l) を指定されたポート (-d) へラップして、指定された ssl cert (-p) を使います。
Domain サーバデーモンを安全にするために取り組まなければならない問題がいくつか あります。これは他のどのサービスを安全にするときも検討されることです:
あなたの組織のもらしたくない貴重な情報を引きだすのに使えないように DNS
サーバから外部のクライアントへ提供される情報を制限するべきです。これには
以下のオプションを追加することが含まれます:
allow-transfer、allow-query、
allow-recursive、そして version です。これを (提供される
すべてのゾーンに適用されるように) グローバルセクションで制限することも
できますし、ゾーンごとに制限することもできます。この情報は
bind-doc
で文書化されています。このことについて
くわしくはそのパッケージをインストールしたあと
/usr/share/doc/bind/html/index.html
をごらんください。
あなたのサーバがインターネットと内部の (あなたの内部 IP は 192.168.1.2 だと
します) ネットワークに接続されていて (基本的なマルチホームのサーバです)、
インターネットにはサービスを何も提供したくはなく、内部のホストからだけ DNS
参照ができるようにしたいとしましょう。 /etc/bind/named.conf
にこれを追加することによって DNS 参照を 制限できます:
options { allow-query { 192.168.1/24; } ; allow-transfer { none; } ; allow-recursive { 192.168.1/24; } ; listen-on { 192.168.1.2; } ; forward { only; } ; forwarders { A.B.C.D; } ; };
listen-on オプションは DNS が内部アドレスを持つインターフェイスだけを バインドするようにしますが、このインターフェイスがインターネットに接続されて いるインターフェイスと同じでも (たとえば NAT を使っているときなど)、 問いあわせは内部のホストから来たときのみ受けいれられます。システムに インターフェイスが複数あって、listen-on がないときは、内部ユーザ だけが問いあわせることができますが、このポートは外部の攻撃者からもアクセス できるので、攻撃者は DNS サーバをクラッシュさせようと (またはバッファ オーバーフロー攻撃を行おうと) するかもしれません。自分自身以外のどの システムにも DNS サービスを提供しないなら 127.0.0.1 にだけ応答するように することさえできます。
chaos クラスの version.bind レコードは現在動いている bind プロセスの バージョンを含みます。この情報はしばしば自動スキャナや、bind が特定の攻撃に 対して脆弱であるか調べたい、悪意ある人に利用されます。version.bind レコードでうその情報を提供したり、情報を何も提供しないことによって、 公開されているバージョンにもとづいてサーバが攻撃される確率を制限することが できます。独自のバージョンを提供するには、version ディレクティブを 次のように使ってください:
options { ... various options here ... version "Not available."; };
version.bind レコードを変更することは攻撃に対する実際の保護にはなりませんが、 役に立つ防御策と考えられるべきです。
BIND の権限を制限することについては、もし root でないユーザが BIND を
動かしたら、BIND は新しいインターフェイスを自動的に検知できなくなるという
ことを知っておかなければなりません。たとえば、PCMCIA カードをラップトップに
さしこんだときです。このことについてくわしくは named 文書ディレクトリの
README.Debian (/usr/share/doc/bind/README.Debian
) を
ごらんください。BIND に関するセキュリティ問題が最近多くあります。よって
ユーザを切りかえることは可能ならば役に立ちます。
BIND を異なるユーザで動かすには、まずそのために別個のユーザおよびグループを 作ってください (root として動いていないサービスすべてに nobody または nogroup を使うのはよい考えではありません)。この例では、 named というユーザおよびグループが使われます。これはこう入力する ことによって可能です:
addgroup named adduser --system --ingroup named named
そこであなたのすきなエディタで /etc/init.d/bind を編集し、
start-stop-daemon --start
ではじまる行を
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
に変更してください。
あと必要なのは「/etc/init.d/bind restart」で bind を再起動し、こういう 2 行が syslog にないかさがすだけです。
Sep 4 15:11:08 nexus named[13439]: group = named Sep 4 15:11:08 nexus named[13439]: user = named
やった! named はもう root では動いていません。BIND について最高の
セキュリティを実現するには、デーモンのまわりに chroot の檻 (chroot を使う, 第 4.11 節 をごらんください)
を構築しましょう。 これを行う簡単な方法があります: -t
オプションです (named(8)
マニュアルページをごらんください)。
これは Bind が自分自身を指定されたディレクトリの中へ chroot するように
します。chroot の檻を設置したり動的なライブラリについて心配したりする
必要はありません。この chroot の檻の中に必要なファイルは以下のファイルのみです:
dev/null etc/bind/ - named.conf やすべてのサーバゾーンを含むべき sbin/named-xfer - name transfer を行うなら var/run/named/ - pid およびネームサーバキャッシュ (もしあれば) を保持します。 このディレクトリは named ユーザによって書きこみ可能で ある必要があります。 var/log/named - ファイルへのログを設定するなら、 named ユーザによって 書きこみ可能である必要があります dev/log - named が syslogd を通じてログを取るように設定されているなら syslogd がここで応答する必要があります
Bind デーモンが適切に動くためには named ファイルのパーミッションが必要です。 設定ファイルがいつも /etc/named/ にあるのでこれは容易な作業です。 セカンダリまたはキャッシュネームサーバでなければ、zone ファイルへは 読みとり専用のアクセスだけでいいことを考慮してください、セカンダリまたは キャッシュネームサーバの場合は、(プライマリサーバからの zone transfer が うまくいくように) 必要な zone への読み書き許可を与える必要があります。
BIND が Debian システムでなぜ root 以外のユーザとして動いていないのかに
ついて知りたければ、Bind に関するバグ追跡システム、特に Bug #50013: bind should not run as
root
をごらんください。
さらに、Bind を chroot することについては Chroot-Bind-HOWTO
(Bind 9 について) と Chroot-Bind8-HOWTO
(Bind 8 について) にくわしい情報があります。この文書は
doc-linux-text
(テキスト版) または doc-linux-html
(html 版) をインストールすることに よっても利用できます。
もし Debian (potato) の Bind 8.2.3 の完全な chroot の檻を設置しようと しているなら (すなわち、-t だけではないなら)、以下のファイルが その中に含まれるようにしてください:
dev/log - syslogd がここで応答するべき dev/null etc/bind/named.conf etc/localtime etc/group - 中身は 1 行だけ: "named:x:GID:" etc/ld.so.cache - ldconfig で生成される lib/ld-2.1.3.so lib/libc-2.1.3.so lib/ld-linux.so.2 - ld-2.1.3.so への symlink lib/libc.so.6 - libc-2.1.3.so への symlink sbin/ldconfig - chroot 設置後は削除可能 sbin/named-xfer - name transfers を行うなら var/run/
FIXME、 http://www.cryptio.net/~ferlatte/config/
(Debian 特有) および http://www.psionic.com/papers/whitep01.html
の情報を統合する。
FIXME。内容を追加する。
内部でのみ使用したいのであって、外部の人にアクセスしてもらいたくないならば
(試験用であるとか、doc-central
アーカイブにアクセス
したいためであるとか...)、 Apache
サーバへのアクセスを制限できます。これを行うには
/etc/apache/http.conf
で Listen または
BindAddress ディレクティブを使います。
Listen を使うなら:
Listen 127.0.0.1:80
BindAddress を使うなら:
BindAddress 127.0.0.1
そして /etc/init.d/apache restart で apache を再起動してください。 すると apache が loopback インターフェイスにしか応答しないことが わかるでしょう。
いずれの場合も、Apache によって提供される機能をすべて使っているのでなければ、
dhttpd
のような Debian で提供されている他のウェブサーバを
見てみたくなるかもしれません。
Apache
Documentation
は Apache
ウェブサーバについて行われるべきセキュリティ対策に関する情報を提供しています
(Debian では同じ情報が apache-doc
パッケージで提供されて います)。
もし finger サービスを動かしたいならまずそうするのが必要かどうか考えて
ください。もし必要なら、 Debian は多くの finger デーモンを提供しているのが
わかるでしょう (apt-cache search fingerd
の出力です):
公開のサービスに finger デーモンを使うなら ffingerd
が
推奨されています。いずれにせよ、inetd、xinetd または tcpserver を通じて finger
デーモンを設置するときにはこうすることをおすすめします:
同時に動くことができるプロセスの個数を制限し、(tcp wrapper を使って)
あるホストからの finger デーモンへのアクセスを制限し、必要なインターフェイス
だけに応答するようにしましょう。
BIND がここ数年多くの攻撃にさらされてきた理由はその複雑さだといってもたぶん 妥当でしょう (BIND を安全にする, 第 5.8 節 をごらんください)。
複雑な機能を持ちインストールしているユーザの基盤が大きな他の プログラムには Sendmail やいくつかの ftp デーモン (たとえば WUftpd) が あります。(もちろん、機能がなく満足しているユーザもいないプログラムも 役に立たないだけでなく同じくらい危険かもしれません)。
いずれにせよ、これらのどれかを動かすなら、同様の配置 — root 特権を破棄して、chroot された檻の中で動かす — にするか より安全な代替物に置きかえることを検討してください。
FTP、Telnet、NIS、RPC のような、ネット上でパスワードを平文で送ったり 受けとったりするネットワークサービスをすべて避けるべきです。この HOWTO の 著者は telnet や ftp のかわりに ssh を使うことを全員にすすめます。
telnet から ssh に移行しても、他の平文プロトコルを使うのではセキュリティは 「すこしも」向上しないことに気をつけてください。最善なのは ftp、telnet、 pop、imap、http を取りのぞいて対応する暗号化サービスで置きかえることでしょう。 これらのサービスから ftp-ssl、telnet-ssl、pop-ssl、https などのような SSL バージョンに移行することを検討するべきです。
上にあげたヒントの多くはすべての Unix システムにあてはまります (Linux や その他の Unixes についての強化関連の文書をほかに読んでいればそれに気が つくでしょう)。
もし可能なら、NIS、すなわち Network Information Service を使うべきでは ありません。なぜならそれはパスワードの共有を可能にするからです。設定が まちがっていたらこれはきわめて危険になります。
複数のマシン間でパスワードの共有が必要なら、他の選択肢を使うことを考えたく
なるかもしれません。たとえば、LDAP サーバを設置してユーザ認証用にその LDAP
サーバに接触するためにあなたのシステムの PAM を設定することができます。
設定の詳細は LDAP-HOWTO
(/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz
) をごらんください。
NIS のセキュリティについてくわしくは NIS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz
) を ごらんください。
FIXME (jfs): これを Debian で設定する方法についての情報を加える
可能なら RPC をいつでも停止するべきです。
このサービスには多くのセキュリティホールが知られていて、簡単に攻撃できます。
一方で NFS サービスはネットワークでとても重要です。よってあなたの
ネットワークでセキュリティと有用性のバランスを取らなければなりません。 多くの
DDoS (distributed denial of service) 攻撃はシステムに侵入して
いわゆるエージェントまたはハンドラーとしてふるまうのに rpc 攻撃を利用します。
NFS のセキュリティについてくわしくは NFS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz
) を ごらんください。
portmap を停止することは非常に簡単です。いくつかの方法があります。Debian 3.0
システムで最も簡単なのは portmap
パッケージを
アンイントールすることです。他のバージョンを使っているなら デーモンサービスを停止する, 第 3.6.1 節
にあるようにしてサービスを無効にする必要があるでしょう。 これは portmap が
net-base
パッケージ (システムを壊すこと
なくこれをアンインストールすることはできません) の一部であるためです。
これは実際には /etc/rc${runlevel}.d/ にある portmap 関連のすべての
symlink を削除します。これは手動でも行うことができます。ほかの可能性は
chmod 644 /etc/init.d/portmap ですが、これはブート時にエラー
メッセージを出します。シェルスクリプト /etc/init.d/portmap
の
start-stop-daemon の部分をはずすこともできます。
Debian GNU/Linux オペレーティングシステムには Linux カーネルによって
提供される内蔵されたファイアウォール機能があります。つまり potato (Debian 2.2
リリース) システム (デフォルトのカーネルは 2.2 です) をインストールしたら
ipchains
ファイアウォールがカーネルで利用できるということです。
ipchains
をインストールする必要がありますが、これは きっと
(その優先度ゆえに) すでにインストールされているでしょう。woody (Debian 3.0
リリース) システム (デフォルトのカーネルは 2.4 です) を
インストールしたら、netfilter
ファイアウォールが利用できます。
このスクリプトでファイアウォールの規則を設定したいユーザもいるでしょう。
しかし、自分がどのファイアウォールプログラムまたは機能を使っているのか
調べてください。なぜならこれらのプログラムや機能が他のファイルをいじったり
起動時に追加した定義を変更したりする可能性があるからです。たとえば、
firewalk
はファイアウォール設定に別の設定ファイルを 使います。
Debian 3.0 を使っているなら、iptables
パッケージが
インストールされているのに気がつくでしょう。これは 2.4.4 以降のカーネルの
netfilter 実装をサポートします。インストール直後にはシステムはファイアウォール
規則を知ることができないので (ファイアウォール規則はあまりにシステム
特有です)、あなたが iptables を有効にする必要があります。
そのためにはこのようにしなければなりません:
/etc/default/iptables
を編集して
enable_iptables_initd を true に設定します
iptables(8)
をごらんください)、 Debian
ファイアウォールパッケージによって提供される道具も使えます (ファイアウォールパッケージ, 第 5.15.4 節
をごらんください)。ファイアウォールが
有効なときに使われる規則と有効でないときに使われる 規則
(これは空の規則でもかまいません) を作る必要があります。
これが終わったらファイアウォールの設定は /var/lib/iptables/
ディレクトリに保存されシステム起動時 (または initd スクリプトを 引数
start および stop とともに実行するとき) に実行されます。
デフォルトの Debian の設定ではファイアウォールコードはマルチユーザランレベル (2
から 5) の極めてはやい段階 (10) に実行されることに注意してください。
また、このコードはシングルユーザランレベル (1) で停止されます。これがあなたの
ポリシーにあわないなら変更してください。
以下で概説されるパッケージはシステムが起動するときに実行される ファイアウォールスクリプトを導入するかもしれないことに注意してください。 これは一般的な設定とはまちがいなく対立し、望ましくない影響をもたらします。 パッケージの文書を読んでどちらか一方の設定を使ってください。
ファイアウォール規則をどうやって設定するべきかわからないなら Packet
Filtering HOWTO を読んでください。これは iptables
をインストールすると /usr/share/doc/iptables/html/
でオフラインで読めます。
ファイアウォール規則をローカルシステムへのアクセスを安全にし、さらにそこで 行われる外向きのやりとりを制限する方法として使うことができます。 ファイアウォール規則はサービスをあるネットワーク、IP アドレスなどにだけ 提供するように適切に設定できないプロセスを守るのにも使えます。
しかし、主にシステムを守るためにファイアウォール機能だけに頼らないほうが ずっとよいという理由により、この段階はこのマニュアルの最後に 書かれています。システムのセキュリティは層によって構成されています。 ファイアウォールは最後に、すべてのサービスが強化されたあとで取りいれる べきです。システムが組みこみのファイアウォールでしか守られていない設定なのに 管理者が喜んでファイアウォール規則を何らかの理由で (設定に問題があるとか、 気にくわないとか、まちがえてとか...) 削除してしまうことが容易に想像できます。 このようなシステムは攻撃にさらされることになるでしょう。
Debian のファイアウォールはフィルタリング規則でその背後にある システムへのアクセスを守り、インターネットへの接触を制限するのにも使えます。
Debian GNU/Linux マシンをブリッジファイアウォールとして、すなわち完全に ネットワーク透過的で IP アドレスを持たず、それゆえに直接攻撃できない フィルタリングファイアウォールとして設定することさえできます。
ファイアウォールについてよく知らないなら、doc-linux-text
パッケージの中にある Firewalling-HOWTO を読みましょう (他の文書形式も
利用できます)。くわしくは 一般的なセキュリティ問題について知る, 第 2.2
節 をごらんください。
Debian システムでファイアウォール規則を設定するのに使える ソフトウェアはいろいろあります:
fwbuilder
mason
、これはあなたのシステムが「見た」ネットワーク
トラフィックにもとづいてファイアウォール規則を提案できます。
bastille
(新バージョンの bastille に追加される
かもしれない強化過程には起動時に実行されるファイアウォール規則をシステムに
加える能力があります)
ferm
fwctl
easyfw
firewall-easy
ipac-ng
gfcc
knetfilter
firestarter
最後にあげたパッケージ、つまり gfcc、firestarter と knetfilter は GNOME (はじめの 2 個) または KDE (最後の 1 個) を使う管理用の GUI です。 これはリスト中の管理者向けの他のパッケージよりずっとユーザ向け (つまり、家庭ユーザ向け) です。
FIXME: これのパッケージについての情報をもっと加える
FIXME: Debian のファイアウォールについての情報と、それが他の ディストリビューションとどこがどうちがうのか調べる
FIXME: 自家製のファイアウォールコードはどこで有効にされるべきか (debian-firewall の一般的な FAQ か?)
Debian セキュリティマニュアル
v2.4 Tue, 30 Apr 2002 15:41:13 +0200 (翻訳: Thu, 6 Jun 2002)jfs@computer.org
oohara@libra.interq.or.jp