Catching up to 3.1-19990210-BETA. (again)

Reviewed by:	Japanese Online Manual Project <man-jp@jp.FreeBSD.ORG>
Submitted by:	Kazuo Horikawa <k-horik@yk.rim.or.jp>

1 files changed, 587 insertions, 400 deletions

diff --git a/ja_JP.eucJP/man/man7/security.7 b/ja_JP.eucJP/man/man7/security.7
index 32632118d6..534e92d12a 100644
--- a/ja_JP.eucJP/man/man7/security.7
+++ b/ja_JP.eucJP/man/man7/security.7
@@ -3,432 +3,615 @@
 .\" the source tree.
 .\"
 .\"	%Id: security.7,v 1.4 1998/12/26 05:19:42 dillon Exp %
-.\" jpman %Id: security.7,v 1.2 1999/01/31 11:05:10 horikawa Chk %
+.\" jpman %Id: security.7,v 1.3 1999/02/11 11:18:48 vanitas Stab %
 .\"
 .Dd December 20, 1998
 .Dt SECURITY 7
 .Os
-.Sh NAME
+.Sh 名称
 .Nm security
-.Nd introduction to security under FreeBSD
-.Sh DESCRIPTION
+.Nd FreeBSD におけるセキュリティ入門
+.Sh 解説
 .Pp
-Security is a function that begins and ends with the system administrator.
-While all
+セキュリティは、システム管理者とともに始まり、システム管理者と
+ともに終る機能です。すべての
 .Bx
-systems are inherently multi-user capable, the job of building and
-maintaining security mechanisms to keep those users 'honest' is probably
-one of the single largest undertakings of the sysadmin.  Machines are
-only as secure as you make them, and security concerns are ever competing
-with the human necessity for convenience.   UNIX systems,
-in general, are capable of running a huge number of simultaneous processes
-and many of these processes operate as servers - meaning that external entities
-can connect and talk to them.  As yesterday's mini-computers and mainframes 
-become today's desktops, and as computers become networked and internetworked,
-security becomes an ever bigger issue.
-.Pp
-Security concerns can be split up into several categories:
+システムは昔からマルチユーザに対応しています。セキュリティの仕組みを
+組み込んで維持することで、ユーザを
+.Sq 正直に
+し続ける仕事は、システム管理者の最も大きな責務の一つでしょう。マシンは、
+管理者が設定しただけのセキュリティしか示しません。セキュリティに関する
+問題は、むしろ、便利さを求める人間との競合問題です。一般に、
+.Ux
+システムは莫大な数のプロセスを同時に実行させることも、また、その多くを
+サーバとして動作させることもできます。これは、外部の何者かが
+接続してきて、サーバプロセスと会話することができるということを
+意味します。昨日までのミニコンピュータとメインフレームは、今日では
+デスクトップコンピュータとなり、かつ、それらはネットワークで結ばれて
+インターネットと接続されるようになりました。これにより、セキュリティは
+昔と比べてはるかに大きな問題となっています。
+.Pp
+セキュリティに関する問題は、いくつかのカテゴリに分類することができます。
 .Bl -enum -offset indent
 .It
-Denial of service attacks
+サービス不能攻撃
 .It
-User account compromises
+ユーザアカウントにかかる危険
 .It
-Root compromise through accessible servers
+アクセス可能なサーバを経由した root 権限にかかる危険
 .It
-Root compromise via user accounts
+ユーザアカウントを通した root 権限にかかる危険
 .El
 .Pp
-A denial of service attack is an action that deprives the machine of needed
-resources.  Typically, D.O.S. attacks are brute-force mechanisms that attempt
-to crash or otherwise make a machine unusable by overwhelming its servers or
-network stack.  Some D.O.S. attacks try to take advantages of bugs in the
-networking stack to crash a machine with a single packet.  The latter can
-only be fixed by applying a bug fix to the kernel.  Attacks on servers can
-often be fixed by properly specifying options to servers to limit the load
-they incur on the system under adverse conditions.  Brute-force network 
-attacks are harder to deal with.  A spoofed-packet attack, for example, is 
-nearly impossible to stop short of cutting your system off from the internet.
-.Pp
-A user account compromise is even more common then a D.O.S. attack.  Many
-sysadmins still run standard telnetd, rlogind, rshd, and ftpd servers on their
-machines.  These servers, by default, do not operate over encrypted
-connections.  The result is that if you have any moderate-sized user base,
-one or more of your users logging into your system from a remote location
-(which is the most common and convenient way to login to a system) will
-have his or her password sniffed.  The attentive system admin will analyze
-his remote access logs occasionally looking for suspicious source addresses
-even for successful logins.
-.Pp
-One must always assume that once an attacker has access to a user account,
-the attacker can break root.  However, the reality is that in a well secured
-and maintained system, access to a user account does not necessarily give the
-attacker access to root.  The distinction is important because without access
-to root the attacker cannot generally hide his tracks and may, at best, be
-able to remove that user's files and crash the machine, but not touch anyone
-else's files.
-.Pp
-System administrators must keep in mind that there are several ways to break
-root on a machine.  The attacker may know the root password, the attacker
-may find a bug in a root-run server and be able to break root over a network
-connection to that server, or the attacker may know of a bug in an suid-root
-program that allows the attacker to break root once he has broken into a 
-user's account.
-.Pp
-Security remedies are always implemented in a multi-layered 'onion peel' 
-approach and can be categorized as follows:
+サービス不能攻撃とは、マシンから必要な資源を奪う行為です。
+サービス不能攻撃は、普通は、そのマシンで実行されるサーバや
+ネットワークスタックを圧倒して、マシンを使えなくしたりクラッシュさせようと
+するような力任せの仕組みです。サービス不能攻撃のいくつかは、
+ネットワークスタックのバグを利用して、パケット一つでマシンを
+クラッシュさせようとします。後者は、
+カーネルにバグ修正を施すことによってのみ修正することができます。
+サーバプロセスに対する攻撃は、サーバのオプションを適切に指定して、
+逆境状況のシステムにおいて、サーバプロセスが引き起こす負荷に限界を設けることで
+修正することができます。これらに比べると、ネットワークへの力任せの攻撃への
+対応はずっと難しくなります。たとえば、偽造パケットによる攻撃
+.Pq spoof-packet attack
+は、インターネットからシステムを切り離す以外の方法では、抑止することは
+ほとんど不可能です。
+.Pp
+ユーザアカウントを危険に晒すことは、サービス不能攻撃よりは多少はありふれた
+ものです。このご時勢でも、システム管理者の多くは、自分たちのマシンで
+標準の telnetd, rlogind, rshd, ftpd サーバを実行させています。これらの
+サーバは、デフォルトでは、暗号化されたコネクション上で動作していません。
+その結果、抱えているユーザ数が標準的な大きさならば、リモート
+.Pq そのシステムにログインするのに最も普通で便利な場所
+からログインしているユーザのうち一人以上は、パスワードを覗き見られて
+しまうでしょう。
+システム管理者が注意深いならば、たとえログインが成功していたとしても、
+リモートアクセスログをときどき解析して、疑わしいソースアドレスを探すものです。
+.Pp
+ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると、攻撃者が
+root の権限を破る可能性があることを仮定するべきです。しかし、
+セキュリティを十分保ち、手入れの行き届いたシステムにおいては、
+あるユーザアカウントへのアクセスが可能となっても、攻撃者に必ずしも
+root へのアクセス権を与えるとは限らないのが現実です。この違いは重要です。
+というのは、root へのアクセス権がなければ、一般的に、攻撃者は自分の
+侵入の痕跡を隠蔽することができませんし、そのユーザのファイルを消して
+マシンをクラッシュさせることができるのがせいぜいで、他のユーザの
+ファイルには手出しできません。
+.Pp
+システム管理者は、あるマシン上で root の権限を破る方法がいくつかあることを
+心しておかねばなりません。攻撃者が root のパスワードを知ってしまうかも
+しれません。攻撃者が root の権限で実行されるサーバのバグを見つけ、
+ネットワークからそのサーバへ接続して root の権限を破ることができるかも
+しれません。ひとたびユーザアカウントを破ると、ユーザアカウントから
+root の権限を破ることが可能であるバグを持つ suid-root プログラムの
+存在を、攻撃者は知っているかもしれません。
+.Pp
+セキュリティを改善する方法は、常に、
+.Sq タマネギの皮剥き
+のように
+複数の層のアプローチで実装されます。これらは次のように分類できます。
 .Bl -enum -offset indent
 .It
-Securing root and staff accounts
+root とスタッフのアカウントの安全性を高める。
 .It
-Securing root - root-run servers and suid/sgid binaries
+root の安全性を高める - root 権限のサーバと suid/sgid バイナリ。
 .It
-Securing user accounts
+ユーザアカウントの安全性を高める。
 .It
-Securing the password file 
+パスワードファイルの安全性を高める。
 .It
-Securing the kernel core, raw devices, and filesystems
+カーネルのコア、raw デバイス、ファイルシステムの安全性を高める。
 .It
-Checking file integrity: binaries, configuration files, and so forth
+ファイルの完全性のチェック: バイナリ、設定ファイルなど。
 .It
-Paranoia
+偏執狂的方法。
 .El
-.Sh SECURING THE ROOT ACCOUNT AND SECURING STAFF ACCOUNTS
-.Pp
-Don't bother securing staff accounts if you haven't secured the root
-account.  Most systems have a password assigned to the root account.  The
-first thing you do is assume that the password is 'always' compromised.
-To secure the root account you make sure that it is not possible to login
-to the root account using the root password from a random user account or 
-over the network.  If you haven't already, configure telnetd, rlogind, and
-all other servers that handle login operations to refuse root logins, period,
-whether the right password is given or not.  Allow direct root logins only
-via the system console.  The '/etc/ttys' file comes in handy here and is
-secure by default on most systems, but a good sysadmin always checks to make
-sure.
-.Pp
-Of course, as a sysadmin you have to be able to get to root, so we open up
-a few holes.  But we make sure these holes require additional password
-verification to operate.  One way to make root accessible is to add appropriate
-staff accounts to the wheel group (in /etc/group).  The staff members placed
-in the wheel group are allowed to 'su' to root.  You should never give staff
-members native wheel access via their entry in the password file... put staff
-in a 'staff' group or something and only add those that really need root to
-the wheel group.  Unfortunately the wheel mechanism still allows an intruder to
-break root if the intruder has gotten hold of your password file - he need only
-break the root password and the password of one of the staff accounts that
-happens to be in the wheel group.  So while the wheel mechanism is usable,
-it isn't much safer then not having a wheel group at all.
-.Pp
-An indirect way to secure the root account is to secure your staff accounts
-by using an alternative login access method and *'ing out the crypted password
-for the staff accounts.  This way an intruder may be able to steal the password
-file but will not be able to break into any staff accounts (or, indirectly,
-root, even if root has a crypted password associated with it).  Staff members
-get into their staff accounts through a secure login mechanism such as 
-kerberos(1) or ssh(1) (see /usr/ports/security/ssh) using a private/public
-key pair.  When you use something like kerberos you generally must secure
-the machines which run the kerberos servers and your desktop workstation.
-When you use a public/private key pair with ssh, you must generally secure
-the machine you are logging in FROM (typically your workstation), but you can
-also add an additional layer of protection to the key pair by password 
-protecting the key pair when you create it with ssh-keygen(1).  Being able
-to *-out the passwords for staff accounts also guarantees that staff members
-can only login through secure access methods that you have setup.  You can
-thus force all staff members to use secure, encrypted connections for
-all their sessions which closes an important hole used by many intruders:  That
-of sniffing the network from an unrelated, less secure machine.
-.Pp
-The more indirect security mechanisms also assume that you are logging in
-from a more restrictive server to a less restrictive server.  For example, 
-if your main box is running all sorts of servers, your workstation shouldn't
- be running any.  In order for your workstation to be reasonably secure 
-you should run as few servers as possible, up to and including no servers 
-at all, and you should run a password-protected screen blanker. 
- Of course, given physical access to
-a workstation an attacker can break any sort of security you put on it.
-This is definitely a problem that you should consider but you should also
-consider the fact that the vast majority of break-ins occur remotely, over
-a network, from people who do not have physical access to your workstation or
-servers.
-.Pp
-Using something like kerberos also gives you the ability to disable or
-change the password for a staff account in one place and have it immediately
-effect all the machine the staff member may have an account on.  If a staff
-member's account gets compromised, the ability to instantly change his 
-password on all machines should not be underrated.  With discrete passwords,
-changing a password on N machines can be a mess.  You can also impose 
-re-passwording restrictions with kerberos:  not only can a kerberos ticket
-be made to timeout after a while, but the kerberos system can require that
-the user choose a new password after a certain period of time (say, once a 
-month). 
-.Sh SECURING ROOT - ROOT-RUN SERVERS AND SUID/SGID BINARIES
-.Pp
-The prudent sysadmin only runs the servers he needs to, no more, no less.  Be
-aware that third party servers are often the most bug-prone.  For example,
-running an old version of imapd or popper is like giving a universal root
-ticket out to the entire world.  Never run a server that you have not checked
-out carefully.  Many servers do not need to be run as root.  For example,
-the ntalk, comsat, and finger daemons can be run in special user 'sandboxes'.
-A sandbox isn't perfect unless you go to a large amount of trouble, but the
-onion approach to security still stands:  If someone is able to break in
-through a server running in a sandbox, they still have to break out of the
-sandbox.  The more layers the attacker must break through, the lower the
-likelihood of his success.  Root holes have historically been found in
-virtually every server ever run as root, including basic system servers.
-If you are running a machine through which people only login via sshd and
-never login via telnetd or rshd or rlogind, then turn off those services!
-.Pp
-FreeBSD now defaults to running ntalkd, comsat, and finger in a sandbox.
-Another program which may be a candidate for running in a sandbox is
-named(8).  The default rc.conf includes the arguments necessary to run
-named in a sandbox in a commented-out form.  Depending on whether you
-are installing a new system or upgrading an existing system, the special
-user accounts used by these sandboxes may not be installed.  The prudent
-sysadmin would research and implement sandboxes for servers whenever possible.
-.Pp
-There are a number of other servers that typically do not run in sandboxes:
-sendmail, popper, imapd, ftpd, and others.  There are alternatives to
-some of these, but installing them may require more work then you are willing
-to put (the convenience factor strikes again).  You may have to run these
-servers as root and rely on other mechanisms to detect break-ins that might
-occur through them.
-.Pp
-The other big potential root hole in a system are the suid-root and sgid
-binaries installed on the system.  Most of these binaries, such as rlogin,
-reside in /bin, /sbin, /usr/bin, or /usr/sbin.  While nothing is 100% safe,
-the system-default suid and sgid binaries can be considered reasonably safe.
-Still, root holes are occasionally found in these binaries.  A root hole
-was found in Xlib in 1998 that made xterm (which is typically suid) vulnerable.
-It is better to be safe then sorry and the prudent sysadmin will restrict suid
-binaries that only staff should run to a special group that only staff can
-access, and get rid of (chmod 000) any suid binaries that nobody uses.  A 
-server with no display generally does not need an xterm binary.  Sgid binaries
-can be almost as dangerous.  If an intruder can break an sgid-kmem binary the
-intruder might be able to read /dev/kmem and thus read the crypted password
-file, potentially compromising any passworded account.  An intruder that breaks
-the tty group can write to almost user's tty.  If a user is running a terminal
-program or emulator with a talk-back feature, the intruder can potentially 
-generate a data stream that causes the user's terminal to echo a command, which
-is then run as that user.
-.Sh SECURING USER ACCOUNTS
-.Pp
-User accounts are usually the most difficult to secure.  While you can impose
-Draconian access restrictions on your staff and *-out their passwords, you
-may not be able to do so with any general user accounts you might have.  If
-you do have sufficient control then you may win out and be able to secure the
-user accounts properly.  If not, you simply have to be more vigilant in your
-monitoring of those accounts.  Use of ssh and kerberos for user accounts is
-more problematic, but still a very good solution compared to a crypted
-password. 
-.Sh SECURING THE PASSWORD FILE
-.Pp
-The only sure fire way is to *-out as many passwords as you can and 
-use ssh or kerberos for access to those accounts.  Even though the 
-crypted password file (/etc/spwd.db) can only be read by root, it may
-be possible for a intruder to obtain read access to that file even if the 
-attacker cannot obtain root-write access.
-.Pp
-Your security scripts should always check for and report changes to 
-the password file (see 'Checking file integrity' below).
-.Sh SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS
-.Pp
-If an attacker breaks root he can do just about anything, but there
-are certain conveniences.  For example, most modern kernels have a
-packet sniffing device driver built in.  Under FreeBSD it is called
-the 'bpf' device.  A intruder will commonly attempt to run a packet sniffer
-on a compromised machine.  You do not need to give the intruder the 
-capability and most systems should not have the bpf device compiled in.
-Unfortunately, there is another kernel feature called the Loadable Kernel
-Module interface.  An enterprising intruder can use an LKM to install 
-his own bpf device or other sniffing device on a running kernel.  If you
-do not need to use the module loader, turn it off in the kernel configuration
-with the NO_LKM option.
-.Pp
-But even if you turn off the bpf device, and turn off the module loader,
-you still have /dev/mem and /dev/kmem to worry about.  For that matter,
-the intruder can still write raw devices.  To avoid this you have to run
-the kernel at a higher secure level... at least securelevel 1.  The securelevel
-can be set with a sysctl on the kern.securelevel variable.  Once you have
-set the securelevel to 1, write access to raw devices will be denied and
-special chflags flags, such as 'schg', will be enforced.  You must also ensure
-that the 'schg' flag is set on critical startup binaries, directories, and
-script files - everything that gets run up to the point where the securelevel
-is set.  This might be overdoing it, and upgrading the system is much more
-difficult when you operate at a higher secure level.  You may compromise and
-run the system at a higher secure level but not set the schg flag for every
-system file and directory under the sun.
-.Sh CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC
-.Pp
-When it comes right down to it, you can only protect your core system
-configuration and control files so much before the convenience factor
-rears its ugly head.  The last layer of your security onion is perhaps
-the most important - detection.
-.Pp
-The only correct way to check a system's file integrity is via another,
-more secure system.  It is fairly easy to setup a 'secure' system: you
-simply do not run any services on it.  With a secure system in place you
-can then give it access to other system's root spaces via ssh.  This may
-seem like a security breech, but you have to put your trust somewhere and
-as long as you don't do something stupid like run random servers it really
-is possible to build a secure machine.  When I say 'secure' here, I assuming
-physical access security as well, of course.  Given a secure machine with
-root access on all your other machines, you can then write security scripts
-ON the secure machine to check the other machines on the system.  The most
-common way of checking is to have the security script scp(1) over a find
-and md5 binary and then ssh a shell command to the remote machine to md5
-all the files in the system (or, at least, the /, /var, and /usr partitions!).
-The security machine copies the results to a file and diff's them against
-results from a previous run (or compares the results against its own 
-binaries), then emails each staff member a daily report of differences.
-.Pp
-Another way to do this sort of check is to NFS export the major filesystems
-from every other machine to the security machine.  This is somewhat more
-network intensive but also virtually impossible for an intruder to detect
-or spoof.
-.Pp
-A good security script will also check for changes to user and staff members
-access configuration files:  .rhosts, .shosts, .ssh/authorized_keys, and
-so forth... files that might fall outside the prevue of the MD5 check.
-.Pp
-A good security script will check for suid and sgid binaries on all 
-filesystems and report their absolute existence as well as a diff against
-the previous report or some baseline (say, make a baseline once a week).
-While you can turn off the ability to run suid and sgid binaries on certain
-filesystems through the 'nosuid' option in fstab/mount, you cannot turn this
-off on root and anyone who breaks root can just install their binary their.
-If you have a huge amount of user disk space, though, it may be useful to
-disallow suid binaries and devices ('nodev' option) on the user partitions
-so you do not have to scan them for such.  I would scan them anyway, though,
-at least once a week, since the object of this onion layer is detection of
-a break-in.
-.Pp
-Process accounting (see accton(1)) is a relatively low-overhead feature of
-the operating system which I recommend using as a post-break-in evaluation
-mechanism.  It is especially useful in tracking down how an intruder has 
-actually broken root on a system, assuming the file is still intact after
-the break-in occurs.
-.Pp
-Finally, security scripts should process the log files and the logs themselves
-should be generated in as secured a manner as possible - remote syslog can be
-very useful.  An intruder tries to cover his tracks, and log files are critical
-to the sysadmin trying to track down the time and method of the initial break-in.
-.Sh PARANOIA
-.Pp
-A little paranoia never hurts.  As a rule, a sysadmin can add any number
-of security features as long as they do not effect convenience, and 
-can add security features that do effect convenience with some added
-thought.
-.Sh SPECIAL SECTION ON D.O.S. ATTACKS
-.Pp
-This section covers Denial of Service attacks.  A DOS attack is typically
-a packet attack.  While there isn't much you can do about modern spoofed
-packet attacks that saturate your network, you can generally limit the damage
-by ensuring that the attacks cannot take down your servers.  
+.Sh root アカウントとスタッフアカウントの安全性を高める
+.Pp
+root のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性を
+うんぬんしてもしかたがありません。ほとんどのシステムでは、root アカウントに
+割り当てたパスワードがひとつあります。まず最初にすべきことは、
+このパスワードは
+.Sq いつでも
+危険に晒されていると仮定することです。root アカウントの安全性を確保する
+ためには、ネットワーク越しに、あるいはどれか一般ユーザのアカウントから、
+root のパスワードを使って root アカウントにログインすることが決して
+できないことを確実にすることです。正しいパスワードが与えられようが
+与えられまいが、telnetd, rlogind, その他ログイン処理を行なうサーバ
+すべてで root でのログインを拒絶するように設定していないとするなら、
+今すぐそういうふうに設定して下さい。直接 root でログインできるのは、
+システムコンソールからだけにして下さい。ここで役に立つのが
+.Sq /etc/ttys
+ファイルです。ほとんどのシステムでは、デフォルトで安全ですが、
+優れたシステム管理者は、設定がそうなっているか常にチェックを怠らない
+ものです。
+.Pp
+システム管理者として、自分は root になれるようにしておかねばならないの
+はもちろんですから、穴をいくつか空けておきます。しかし、それらの穴を
+動作させるには、さらに追加のパスワード認証が必要であるようにして
+おきます。root でアクセス可能とする方法の一つとして、
+適切なスタッフアカウントを
+.Pq /etc/group の
+wheel グループに加えることがあります。
+wheel グループに置かれたスタッフメンバには、
+.Sq su
+を使って root になることが許されます。スタッフメンバに、
+パスワードファイルのエントリでそのまま wheel のアクセス権を
+与えてはいけません。スタッフは、
+.Sq staff
+かその類のグループに置き、その中で本当に root になる必要がある人
+だけを wheel グループに加えるようにします。残念ながら、wheel の
+仕組みだけだと、侵入者がパスワードファイルを手に入れると、攻撃者が
+破る必要があるのは root のパスワードか、wheel グループにたまたま属す
+staff アカウントの一つのパスワードだけです。wheel の仕組みは有益
+ですが、wheel グループがまったく存在しない状況と比べてそれほど
+安全なわけではありません。
+.Pp
+root アカウントの安全性を高める間接的な方法として、別のログインアクセス
+の方法を用いて、スタッフのアカウントの暗号化パスワードを\ * にして
+おくことで、スタッフのアカウントの安全性を高めるものがあります。この方法
+だと、侵入者がパスワードファイルを盗むことができるかもしれませんが、
+スタッフアカウントを破ることはできないでしょう。また、たとえ root が暗号化
+パスワードをパスワードファイルに付けていたとしても、間接的には root
+アカウントも破ることができないでしょう。
+スタッフメンバがスタッフアカウントでログインする際には、
+.Xr kerberos 1
+や
+.Xr ssh 1
+.Po
+.Pa /usr/ports/security/ssh
+参照
+.Pc
+のような、公開鍵 / 秘密鍵の鍵の組を使う
+安全性の高いログインの仕組みを使います。kerberos のような仕掛けを使う場合、
+一般に、kerberos サーバを実行するマシンと自分のデスクトップ
+ワークステーションとの安全性を確保しなければなりません。ssh で
+公開鍵 / 秘密鍵の鍵の組を使う場合、一般に、ログイン元マシン
+.Pq 通常は自分のワークステーション
+の安全性を確保しなければなりません。ここで、
+.Xr ssh-keygen 1
+で鍵の組を生成する際、鍵の組をパスワードで防御することにより、
+鍵の組を防護するための層を追加することもできます。スタッフアカウントの
+パスワードを\ * で外すことができることにより、スタッフメンバが
+管理者自身が設定した安全性の高い方法でのみログインできることも保証
+できます。かくして、多くの侵入者が使う重大なセキュリティの穴
+.Pq 安全性の低い無関係なマシンからネットワークを覗き見る方法
+のないセッションを提供する、安全性の高い暗号化されたコネクションを
+使うことを、すべてのスタッフメンバに強制することができるのです。
+.Pp
+より間接的なセキュリティの仕組みは、より制限の強いサーバから制限の弱い
+サーバへログインすることを前提としています。例えば、主マシンで、
+すべての種類のサーバを実行させている場合、ワークステーションではそれらの
+サーバを実行させてはなりません。ワークステーションの安全性を比較的
+高めておくためには、実行するサーバの数を、果てはサーバなしまで、
+できるだけ減らしておくべきです。また、パスワード防護された
+スクリーンセーバを走らせておくべきです。
+ワークステーションへの物理的アクセスが与えられたとすると、攻撃者は
+管理者が設定したいかなる種類のセキュリティをもうち破ることができるのは
+もちろんのことです。これは、管理者として考えておかねばならない決定的な
+問題ですが、システム破りの大多数は、ネットワーク経由でリモートから、
+ワークステーションやサーバへの物理的アクセス手段を持たない人々によって
+行なわれるという事実も、また、念頭に置いておく必要があります。
+.Pp
+kerberos のような方法を使うことで、スタッフアカウントのパスワードの変更
+もしくは停止を一箇所で行なうことと、スタッフメンバがアカウントを持つ
+すべてのマシンに即時にその効果を及ぼすことが可能となります。スタッフメンバの
+アカウントが危険に晒されたときに、すべてのマシンでその人のパスワードを
+即座に変更する機能を甘く見てはいけません。パスワードが分散されていると、
+N 台のマシンでパスワードを変更することは、てんやわんやの事態を招く可能性が
+あります。kerberos による再パスワード制限
+.Pq re-passwording restriction
+を課することもできます。これを使うことにより可能となることは、
+ある kerberos チケットをしばらくしてからタイムアウトにすることだけでなく、
+kerberos システムがユーザに一定期間
+.Pq 例えば、1 ヶ月に 1 回
+の後に新しいパスワードを選ぶことを要求することもできます。
+.Sh root の安全性を高める - root 権限のサーバと suid/sgid バイナリ
+.Pp
+用心深いシステム管理者は、自分に必要なサーバプロセスだけを過不足なく
+実行させるものです。第三者製のサーバはしばしばバグの温床であることに
+注意して下さい。例えば、古いバージョンの imapd や popper を実行させ
+ておくということは、全世界に共通の root の切符を与えているようなものです。
+自分で注意深くチェックしていないサーバは、決して実行してはいけません。
+サーバの多くは root で実行させる必要はありません。例えば、ntalk, comsat,
+finger デーモンを、特別の「砂場
+.Pq sandbox
+」ユーザで実行させることができます。
+.\"kuma hellofalot of trouble って何や？
+.\" hell of a lot of trouble みたいですね。;-) (金ん田 '99.02.11)
+管理者が膨大な数の問題に直面しない限り、砂場は完璧では
+ありませんが、セキュリティに関するタマネギ的アプローチはここでも
+成り立ちます。砂場で実行されているサーバプロセスを経由して侵入を
+果たすことができたとしても、攻撃者はさらに砂場から外に脱出しなければ
+なりません。攻撃者が通過せねばならない層の数が増えれば増えるほど、
+それだけ攻撃者が侵入に成功する確率が減ります。root の抜け穴は
+歴史的に、基本システムサーバも含め、
+root 権限で実行されるほとんどすべてのサーバプロセスに発見されています。
+ユーザが sshd 経由でのみログインし、
+telnetd, rshd, rlogind 経由でログインすること
+が決してないマシンをお使いなら、それらのサービスを停止させて下さい。
+.Pp
+.Bx Free
+では、今では ntalkd, comsat, finger は砂場で実行させることが
+デフォルトになっています。次に砂場で実行させるべきプログラムの候補として、
+.Xr named 8
+があります。デフォルトの rc.conf ファイルには、named を砂場で実行する
+ために必要な引数がコメントアウトされた形式で含められています。新しい
+システムをインストールしているか、それとも既存のシステムを
+アップグレードして使っているかに依存しますが、砂場として使用する
+特別のユーザアカウントがインストールされていないかもしれません。用心深い
+システム管理者は研究を怠らず、可能なところではつねにサーバに砂場を仕込む
+ものです。
+.Pp
+通常、砂場で実行しないサーバが他にいくつかあります。sendmail, popper,
+imapd, ftpd などです。これらのうちいくつかには代わりがありますが、
+代わりのものをインストールするには、それだけ多くの仕事が必要になるので、
+結局これらを喜んで入れてしまいます
+.Pq 簡単度がまたも勝利を収めるわけです
+。
+これらのサーバは、root 権限で実行せねばならず、これら経由で生じる侵入の
+検出のためには、他の仕組みに依存せねばならないかもしれません。
+.Pp
+システムの root 権限の潜在的な穴で他に大きなものとして、システムに
+インストールされた suid-root/sgid バイナリがあります。rlogin など、
+これらのバイナリのほとんどは、/bin, /sbin, /usr/bin, /usr/sbin に
+存在します。100% 安全なものは存在しないとはいえ、システムデフォルトの
+siud/sgid バイナリは比較的安全といえます。それでもなお、root の穴が
+これらのバイナリにときおり発見されています。1998 年に Xlib で見つかった
+root の穴は、xterm
+.Pq 普通、suid 設定されています
+を攻撃可能にしていました。
+安全である方がよいので、用心深いシステム管理者は残念に思いながらも、
+スタッフのみが実行する必要がある suid バイナリは、スタッフのみが
+アクセス可能な特別なグループに含めるように制限を加え、
+誰も使わない suid バイナリは chmod 000 して片付けてしまうでしょう。
+ディスプレイを持たないサーバは、一般的に xterm のバイナリを必要としません。
+sgid バイナリもほとんど同様の危険な存在になり得ます。
+侵入者が sgid-kmem のバイナリを破ることができた場合、
+その侵入者は /dev/kmem を読み出すことができるようになります。
+つまり、暗号化されたパスワードファイルを読み出すことができる
+ようになるので、パスワードを持つどのアカウントをも、
+.Pq 潜在的な
+危険に晒すことになります。
+tty グループを破った侵入者は、ほとんどすべてのユーザの端末に書き込みが
+できます。talk-back 機能を持つ端末プログラムやエミュレータをユーザが実行
+していると、
+.Pq 結局、そのユーザとして実行される
+コマンドをユーザの端末にエコーさせるデータストリームを
+侵入者が生成できる可能性があります。
+.Sh ユーザアカウントの安全性を高める
+.Pp
+ユーザアカウントは、普通、安全性を高めることが最も困難です。
+スタッフに対して、アテナイのドラコのような厳格なアクセス制限を課し、
+スタッフのパスワードを\ * で外すことができるとはいえ、管理者が持ちうる
+一般ユーザすべてのアカウントに対して同じことはできないかも知れません。
+十分な管理を保つならば、管理者は勝利し、ユーザの
+アカウントを適切な状態で安全を確保できるかもしれません。それが
+保てないならば、一般ユーザのアカウントをモニタしていっそう気を配るように
+するしかありません。一般ユーザアカウントでの ssh や kerberos の利用は、
+いろいろ問題をはらんでいます。それでも、暗号化パスワードと比較すると、
+はるかに良い解です。
+.Sh パスワードファイルの安全性を高める
+.Pp
+できるだけ多くのパスワードを\ * で外し、それらのアカウントのアクセスには
+ssh や kerberos を使うようにすることが、唯一の確実な方法です。たとえ暗号化
+パスワードファイル 
+.Pq /etc/spwd.db
+が root でのみ読み出し可能だとしても、
+たとえ root の書き込み権限が得られないにしても、侵入者がそのファイルの
+読み出しアクセス権限を得ることは可能かも知れません。
+.Pp
+セキュリティスクリプトは常にパスワードファイルの変更をチェックし、報告
+するようにすべきです (後述の「ファイルの完全性のチェック」を参照して下さい)。
+.Sh カーネルのコア、raw デバイス、ファイルシステムの安全性を高める
+.Pp
+root の権限を破ると、攻撃者はほとんど何でもできますが、
+もっと簡便なこともいくつかあります。例えば、最近のカーネルのほとんどでは、
+組み込みのパケット覗き見デバイス
+.Pq packet sniffing device
+ドライバを備えています。
+.Bx Free
+では
+.Sq bpf
+デバイスと呼ばれています。侵入者は普通、危険に晒された
+マシンでパケット覗き見プログラムを実行させようと試みます。侵入者に
+わざわざそういう機能を提供する必要はないので、ほとんどのシステムで bpf
+デバイスを組み込むべきではありません。不幸なことに、ローダブルカーネル
+モジュール 
+.Pq Loadable Kernel Module:LKM
+インタフェースと呼ばれる
+カーネル機能があります。やる気まんまんの侵入者は、LKM を使って
+自分独自の bpf もしくはその他覗き見デバイスを動作中のカーネルに
+インストールすることが可能です。
+モジュールローダを使う必要がないのであれば、カーネル設定で
+NO_LKM オプションを設定してこの機能を無効にして下さい。
+.Pp
+bpf デバイスを外し、モジュールローダを無効にしても、/dev/mem と /dev/kmem
+という悩みの種がまだ残っています。この問題に関しては、侵入者は raw
+デバイスに書き込むこともできます。この問題を避けるため、システム管理者は
+カーネルをより高い安全レベル
+.Pq securelevel
+、少なくとも安全レベル 1 で実行させる必要があります。
+sysctl を使って kern.securelevel 変数に安全レベルを設定することが
+できます。ひとたび安全レベルに 1 を設定すると、
+raw デバイスに対する書き込みアクセスは拒否され、例えば
+.Sq schg
+のような
+特別な chflags フラグが効果を発揮します。これに加えて、
+起動において重要なバイナリ・ディレクトリ・スクリプトファイルなど、
+安全レベルが設定されるまでの間に実行されるものすべてに対しても
+.Sq schg
+フラグを確実に on にしておく必要があります。この設定をやり過ぎても
+構いませんが、より高い安全レベルで動作している場合、システムの
+アップグレードがはるかに困難になります。システムをより高い安全レベルで
+実行させるようにするが、お天道さまの下にあるすべてのシステムファイルと
+ディレクトリに schg フラグを設定しないという妥協をする方法もあります。
+.Sh ファイルの完全性のチェック: バイナリ、設定ファイルなど
+.Pp
+ことここに至るとシステム管理者にできることは、
+便利度がその醜い頭を上げない程度に、
+コアシステムの設定 / 制御ファイルを防御することだけです。
+セキュリティのタマネギの最後の層はおそらく最も重要なもの、すなわち探知です。
+.Pp
+システムファイルの完全性をチェックする唯一の正しい方法は、別の、より安全な
+システム経由で行なう方法だけです。
+.Sq 安全
+なシステムを準備することは比較的
+容易です。単に、サービスを一切実行しないようにするだけです。安全なシステム
+を用いて、ssh 経由で他のシステムの root 空間にアクセスします。これは
+セキュリティの末端のように見えるかもしれません。しかし、管理者には信頼を
+どこかに置く必要があります。いきあたりばったりでサーバプロセスを
+実行するような馬鹿げたことをしない限りは、安全度の高いマシンを構築する
+ことは本当に可能です。ここで
+.Sq 安全
+という場合、物理アクセスに対する
+セキュリティをも含めて仮定していることはもちろんです。安全なマシンで、
+他のすべてのマシンに root のアクセス権限を持つものが得られると、
+「安全なマシンの上で」システムの他のマシンをチェックする
+セキュリティスクリプトを書くことができるようになります。
+最も普通のチェック方法は、セキュリティスクリプトで、
+まず、find と md5 のバイナリファイルをリモートマシンに
+.Xr scp 1
+してから、
+リモートシステムのすべてのファイル
+.Pq もしくは、少なくとも /, /var, /usr パーティション!
+に対して md5 を適用するシェルコマンドを
+ssh を使ってリモートマシンで実行するものです。
+安全なマシンは、チェック結果をファイルにコピーし、前回のチェック結果と
+diff を取り
+.Pq または、安全なマシン自身のバイナリと比較する
+違いを
+毎日のレポートとしてスタッフメンバひとりひとりにメールを送ります。
+.Pp
+この種のチェックを行なうもう一つの方法として、安全なマシンに対して、
+他のマシンの主なファイルシステムを NFS export する方法があります。
+このやり方はいくらかネットワークに負荷を掛けることになりますが、
+侵入者がチェックを探知したり偽造したりすることは、
+事実上不可能になります。
+.Pp
+優れたセキュリティスクリプトは、一般ユーザやスタッフメンバのアクセス制御
+ファイル: .rhosts, .shosts, .ssh/authorized_keys など、MD5 での精細な
+チェックから洩れそうなファイルの変更をチェックします。
+.Pp
+優れたセキュリティスクリプトは、すべてのファイルシステム上で suid/sgid
+バイナリに対してチェックを行ない、前回のチェック結果もしくは何らかの
+基準
+.Pq "例えば、基準を週 1 回にする"
+からの差分だけでなく、
+それらの存在そのものを報告するものです。
+.Sq nosuid
+オプションを
+fstab/mount で指定することで、あるファイルシステム上の suid/sgid
+バイナリの実行機能をオフにすることができますが、root によるこれらの
+実行をオフにすることはできません。さらに、root 権限を破った者は誰でも
+自分自身で用意したバイナリをインストールすることだってできます。
+しかしながら、ユーザのディスク空間を大量に持つ場合、
+ユーザパーティションで suid バイナリとデバイス
+.Po
+.Sq nodev
+オプション
+.Pc
+を不許可にしておき、スキャンしないで済ませることも有益かもしれません。
+それでも、私ならば、少なくとも週に 1 回はスキャンする
+でしょう。というのは、タマネギのこの層の目的は侵入の検知だからです。
+.Pp
+プロセスアカウンティング
+.Po
+.Xr accton 1
+参照
+.Pc
+は、侵入後の評価の仕組みとして利用をお勧めする、
+比較的オーバヘッドの低いオペレーティングシステムの機能です。
+侵入を受けた後でも当該ファイルが無傷であるとするなら、
+侵入者が実際のところどのようにしてシステムの root を破ったかを
+追跡するのに際して特に有益です。
+.Pp
+最後に、セキュリティスクリプトはログファイルを処理するようにして、
+ログファイル自体はできるだけ安全性の高い方法で
+(リモート syslog は極めて有益になり得ます)
+生成するようにすべきです。侵入者は自分の侵入の痕跡を覆い隠そう
+としますし、ログファイルはシステム管理者が最初の侵入の時刻と方法を
+追跡してゆくために極めて重要です。
+.Sh 偏執狂的方法
+.Pp
+多少偏執狂的になっても決して悪いことにはなりません。原則的に、
+システム管理者は、便利さに影響を与えない範囲でいくつでもセキュリティ
+機能を追加することができます。また、いくらか考慮した結果、便利さに
+影響を与えるセキュリティ機能を追加することもできます。
+.Sh サービス不能攻撃 (D.O.S attack) についての特記事項
+.Pp
+このセクションではサービス不能攻撃を扱います。サービス不能攻撃は、普通は、
+パケット攻撃です。ネットワークを飽和させる最先端の偽造パケット
+.Pq spoofed packet
+攻撃に対してシステム管理者が打てる手はそれほど多く
+ありませんが、一般的に、その種の攻撃がサーバをダウンさせないことを
+確実にすることで、被害を制限することはできます。
 .Bl -enum -offset indent
 .It
-Limiting server forks
+サーバの fork の制限
 .It
-Limiting springboard attacks (ICMP response attacks, ping broadcast, etc...)
+踏み台攻撃の制限 
+.Pq ICMP 応答攻撃、ping broadcast など
 .It
-Kernel Route Cache
+カーネルの経路情報のキャッシュ
 .El
 .Pp
-A common DOS attack is against a forking server that attempts to cause the
-server to eat processes, file descriptors, and memory until the machine
-dies.  Inetd (see inetd(8)) has several options to limit this sort of attack.
-It should be noted that while it is possible to prevent a machine from going
-down it is not generally possible to prevent a service from being disrupted 
-by the attack.  Read the inetd manual page carefully and pay specific attention
-to the -c, -C, and -R options.  Note that spoofed-IP attacks will circumvent
-the -C option to inetd, so typically a combination of options must be used.
-Some standalone servers have self-fork-limitation parameters.  
-.Pp
-Sendmail has its -OMaxDaemonChildren option which tends to work much
-better then trying to use sendmail's load limiting options due to the
-load lag.  You should specify a MaxDaemonChildren parameter when you start
-sendmail high enough to handle your expected load but no so high that the
-computer cannot handle that number of sendmails without falling on its face. 
-It is also prudent to run sendmail in queued mode (-ODeliveryMode=queued)
-and to run the daemon (sendmail -bd) separate from the queue-runs
-(sendmail -q15m).   If you still want realtime delivery you can run the queue
-at a much lower interval, such as -q1m, but be sure to specify a reasonable
-MaxDaemonChildren option for that sendmail to prevent cascade failures.
-.Pp
-Syslogd can be attacked directly and it is strongly recommended that you use
-the -s option whenever possible, and the -a option otherwise.
-.Pp
-You should also be fairly careful
-with connect-back services such as tcpwrapper's reverse-identd, which can 
-be attacked directly.  You generally do not want to use the reverse-ident
-feature of tcpwrappers for this reason.
-.Pp
-It is a very good idea to protect internal services from external access
-by firewalling them off at your border routers.  The idea here is to prevent
-saturation attacks from outside your LAN, not so much to protect internal 
-services from root network-based root compromise.  Always configure an exclusive
-firewall, i.e. 'firewall everything *except* ports A, B, C, D, and M-Z'.   This
-way you can firewall off all of your low ports except for certain specific
-services such as named (if you are primary for a zone), ntalkd, sendmail,
-and other internet-accessible services.
-If you try to configure the firewall the other
-way - as an inclusive or permissive firewall, there is a good chance that you
-will forget to 'close' a couple of services or that you will add a new internal
-service and forget to update the firewall.  You can still open up the 
-high-numbered port range on the firewall to allow permissive-like operation
-without compromising your low ports.  Also take note that FreeBSD allows you to
-control the range of port numbers used for dynamic binding via the various
-net.inet.ip.portrange sysctl's (sysctl -a | fgrep portrange), which can also
-ease the complexity of your firewall's configuration.  I usually use a normal
-first/last range of 4000 to 5000, and a hiport range of 49152 to 65535, then
-block everything under 4000 off in my firewall ( except for certain specific
-internet-accessible ports, of course ).
-.Pp
-Another common DOS attack is called a springboard attack - to attack a server
-in a manner that causes the server to generate responses which then overload
-the server, the local network, or some other machine.  The most common attack
-of this nature is the ICMP PING BROADCAST attack.  The attacker spoofed ping
-packets sent to your LAN's broadcast address with the source IP address set
-to the actual machine they wish to attack.  If your border routers are not
-configured to stomp on ping's to broadcast addresses, your LAN winds up
-generating sufficient responses to the spoofed source address to saturate the
-victim, especially when the attacker uses the same trick on several dozen
-broadcast addresses over several dozen different networks at once.  Broadcast
-attacks of over a hundred and twenty megabits have been measured.  A second
-common springboard attack is against the ICMP error reporting system.  By
-constructing packets that generate ICMP error responses, an attacker can 
-saturate a server's incoming network and cause the server to saturate its 
-outgoing network with ICMP responses.  This type of attack can also crash the
-server by running it out of mbuf's, especially if the server cannot drain the
-ICMP responses it generates fast enough.  The FreeBSD kernel has a new kernel
-compile option called ICMP_BANDLIM which limits the effectiveness of these 
-sorts of attacks.  The last major class of springboard attacks is related to
-certain internal inetd services such as the udp echo service.  An attacker 
-simply spoofs a UDP packet with the source address being server A's echo port,
-and the destination address being server B's echo port, where server A and B
-are both on your LAN.  The two servers then bounce this one packet back and
-forth between each other.  The attacker can overload both servers and their
-LANs simply by injecting a few packets in this manner.  Similar problems
-exist with the internal chargen port.  A competent sysadmin will turn off all
-of these inetd-internal test services.
-.Pp
-Spoofed packet attacks may also be used to overload the kernel route cache.
-Refer to the net.inet.ip.rtexpire, rtminexpire, and rtmaxcache sysctl 
-parameters.  A spoofed packet attack that uses a random source IP will cause
-the kernel to generate a temporary cached route in the route table, viewable
-with 'netstat -rna | fgrep W3'.  These routes typically timeout in 1600
-seconds or so.  If the kernel detects that the cached route table has gotten
-too big it will dynamically reduce the rtexpire but will never decrease it to
-less then rtminexpire.  There are two problems:  (1) The kernel does not react
-quickly enough when a lightly loaded server is suddenly attacked, and (2) The
-rtminexpire is not low enough for the kernel to survive a sustained attack.
-If your servers are connected to the internet via a T3 or better it may be 
-prudent to manually override both rtexpire and rtminexpire via sysctl(8).
-Never set either parameter to zero (unless you want to crash the machine :-)).
-Setting both parameters to 2 seconds should be sufficient to protect the route
-table from attack.
+普通に見られるサービス不能攻撃に、fork するサーバプロセスに対する
+ものがあります。これは、サーバにプロセス・ファイル記述子・メモリを
+食い尽くさせて、マシンを殺そうとするものです。
+inetd
+.Po
+.Xr inetd 8
+参照
+.Pc
+には、この種の攻撃を制限するオプションがいくつかあります。マシンが
+ダウンすることを防止することは可能ですが、この種の攻撃によりサービスが
+崩壊することを防止することは一般的に可能とは限らないことに注意する必要が
+あります。inetd のマニュアルページを注意深く読んで下さい。とくに、
+.Fl c ,
+.Fl C ,
+.Fl R
+オプションに注意して下さい。IP 偽造攻撃
+.Pq spoofed-IP attack
+は inetd の 
+.Fl C
+オプションを出し抜くので、普通はオプションを
+組み合わせて使用するべきであることに注意して下さい。スタンドアロンサーバ
+のいくつかは、自己の fork 上限のパラメータを持っています。
+.Pp
+sendmail には、
+.Fl OMaxDaemonChildren
+オプションがあります。負荷には遅れがあるので、
+sendmail の負荷に限界を設けるオプションを使うよりも、
+このオプションを使う方がまともに動作する可能性ははるかに高いです。
+sendmail の実行を開始する際に、
+.Cm MaxDaemonChildren
+パラメータを設定するべきです。その値は、
+通常見込まれる負荷を扱える程度に十分高いが、
+それだけの数の sendmail を操作しようとすると
+マシンが卒倒してしまうほどには高くないような値に設定するべきです。
+sendmail をキュー処理モード 
+.Pq Fl ODeliveryMode=queued
+で実行することや、
+デーモン
+.Pq Cm sendmail -bd
+をキュー処理用
+.Pq Cm sendmail -q15m
+と別に実行することは用心深いことと言えます。それでもなおリアルタイムでの
+配送を望むのであれば、
+.Fl q1m
+のように、キュー処理をはるかに短い時間間隔で
+行なうことができます。いずれにしても、
+.Cm MaxDaemonChildren
+オプションに
+合理的な値を確実に指定して、sendmail がなだれをうって失敗することが
+ないようにして下さい。
+.Pp
+syslogd は直接攻撃される可能性があるので、可能ならば
+.Fl s
+オプションを用いることを強く推奨します。これができないなら、
+.Fl a
+オプションを使って下さい。
+.Pp
+tcpwrapper の逆 identd などの接続返し
+.Pq connect-back
+を行なうサービスに
+ついては十分注意を払うようにするべきです。これらは直接攻撃を食らう可能性が
+あります。こういう事情があるので、tcpwrapper の逆 ident 機能を使おうとは
+思わないのが一般的なところです。
+.Pp
+境界ルータのところでファイアウォールを設けて、外部からのアクセスに対して
+内部サービスを防御することは実によい考えです。この考え方は、LAN の外
+からの飽和攻撃を防ぐことにあり、root からのネットワークベースの root 
+権限への攻撃から内部サービスを防御することに、あまり考慮を払って
+いません。ファイアウォールは常に排他的に設定して下さい。つまり、
+「ポート A, B, C, D と M から Z まで
+.Eo *
+以外
+.Ec *
+のすべてに防火壁を設ける」というふうにです。
+このようにすることで、named
+.Pq そこがゾーンのプライマリである場合 ,
+ntalkd, sendmail など、インターネットにアクセスを提供するサービス
+として特に指定するもの以外の、すべての低めのポートをファイアウォールで
+停止することができます。ファイアウォールをこの他のやり方、つまり
+包含的もしくは受容的なファイアウォールとして設定しようとする場合、
+いくつかのサービスを
+.Sq close
+することを忘れたり、新しい内部サービスを
+追加してファイアウォールの更新を忘れたりすることはよくあります。
+ファイアウォールの高めの範囲のポートを開けておいて、低めのポートを
+危険に晒すことなく受容的な動作を許すことができます。
+.Bx Free
+では、net.inet.ip.portrange への sysctl
+.Pq sysctl -a \&| fgrep portrange ,
+をいろいろ使用することで、
+動的バインドに使用されるポート番号の範囲を制御できることを記憶にとどめて
+おいて下さい。これによりファイアウォールの設定の複雑性を緩和できます。
+私は、ファイアウォールに通常の範囲として、first/last が 4000 から 5000 を、
+高位ポートの範囲として、49152 から 65535 を使用しています。さらに、
+.Pq いくつかのインターネットアクセス可能なポートを除くのはもちろんですが
+4000 より下のすべてをブロックしています。
+.Pp
+また別のありふれたサービス不能攻撃として、踏み台攻撃
+.Pq springboard attack
+と呼ばれるものがあります。これは、サーバが自分自身、ローカルネットワーク、
+他のマシンを過負荷に追い込むような応答を生成させる方法でサーバを
+攻撃します。この種の攻撃の中で最もありふれたものは、ICMP PING BROADCAST
+攻撃があります。攻撃者は、実際に攻撃したいマシンのアドレスをソース
+アドレスに設定した ping パケットを偽造して、対象の LAN の
+ブロードキャストアドレスに対して送信します。境界にあるルータが
+ブロードキャストアドレスに対する ping を握り潰すように設定されていない
+場合、犠牲者を飽和させるのに十分な応答が、詐称されたソースアドレスに
+対して生成され、LAN に嵐がまき起こります。攻撃者が同じトリックを
+多くの異なるネットワークにまたがる多くのブロードキャスト
+アドレスに対して同時に使用した場合、とくにひどいことになります。
+これまでに、120 メガビット以上のブロードキャスト攻撃が観測されています。
+2 番目の踏み台攻撃は、ICMP エラー報告の仕掛けを狙うものです。ICMP エラー
+応答を生成するパケットを生成することにより、攻撃者はサーバの
+受信ネットワークを飽和させることができ、同時に、サーバが送信
+ネットワークを ICMP 応答で飽和させるようにすることができます。
+mbuf を消費し尽くさせることにより、この種の攻撃でサーバを
+クラッシュさせることも可能です。サーバの ICMP 応答生成が速過ぎて、
+ICMP 応答を送信し尽くすことができない場合、とくにひどいことになります。
+.Bx Free
+カーネルには、この種の攻撃の効果を抑制する ICMP_BANDLIM と
+呼ばれる新しいコンパイルオプションがあります。
+3つめの主要なクラスに属す踏み台攻撃は、udp echo サービスのように
+ある種の内部 inetd サービスに関連するものです。攻撃者は単に
+ソースアドレスがサーバ A の echo ポートであり、ディスティネーション
+アドレスがサーバ B の echo ポートであるかのように UDP パケットを
+偽造します。ここでサーバ A, B はともに自分の LAN に接続されています。
+この 2 つのサーバは、この一つのパケットを両者の間で互いに相手に対して
+打ち返しあいます。このようにしていくつかのパケットを注入することで、
+攻撃者は両方のサーバと LAN を過負荷状態にすることができます。
+同様の問題が内部 chargen ポートにも存在します。有能なシステム管理者は
+この手の inetd 内部テストサービスのすべてを無効にしておくものです。
+.Pp
+偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を生じさせるために
+用いられることもあります。net.inet.ip.rtexpire, rtminexpire, rtmaxcache
+の sysctl パラメータを参照して下さい。でたらめなソース IP を用いた
+この偽造パケット攻撃により、カーネルは、一時的なキャッシュ経路を
+経路情報テーブルに生成します。これは
+.Sq netstat -rna \&| fgrep W3
+で見ることができます。これらの経路は、普通は 1600 秒程度でタイムアウトに
+なります。カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを
+検知すると、カーネルは動的に rtexpire を減らしますが、rtminexpire より
+小さくなるようには決して減らしません。ここに問題が 2 つあります。
+(1) 負荷の軽いサーバが突然攻撃された場合、カーネルが十分素早く反応
+しないこと。(2) カーネルが攻撃に耐え生き延びられるほど十分
+rtminexpire が低くなっていないこと。自分のサーバが T3 もしくはそれより
+良質の回線でインターネットに接続されている場合、
+.Xr sysctl 8
+を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いこと
+といえます。
+.Pq 自分のマシンをクラッシュさせたくない限りは:-
+どちらかを 0 に
+するようなことは決してしないで下さい。両パラメータを 2 秒に設定すれば、
+攻撃から経路情報テーブルを守るには十分でしょう。
 
-.Sh SEE ALSO
+.Sh 関連項目
 .Pp
 .Xr accton 1 ,
 .Xr chflags 1 ,
@@ -440,8 +623,12 @@ table from attack.
 .Xr syslogd 1 ,
 .Xr xdm 1 ,
 .Xr sysctl 8
-.Sh HISTORY
-The
+.Sh 歴史
 .Nm
-manual page was originally written by Matthew Dillon and first appeared 
-in FreeBSD-3.0.1, December 1998.
+マニュアルページは、もともと
+.An Matthew Dillon
+によって書かれました。
+最初に現れたのは、
+.Bx Free -3.0.1
+で 1998 年 12 月のことです。
+.\" translated by Norihiro Kumagai, 98-12-29