Product SiteDocumentation Site

Bölüm 14. Security

14.1. Defining a Security Policy
14.2. Firewall or Packet Filtering
14.2.1. Netfilter Behavior
14.2.2. Syntax of iptables and ip6tables
14.2.3. Creating Rules
14.2.4. Installing the Rules at Each Boot
14.3. Supervision: Prevention, Detection, Deterrence
14.3.1. Monitoring Logs with logcheck
14.3.2. Monitoring Activity
14.3.3. Detecting Changes
14.3.4. Detecting Intrusion (IDS/NIDS)
14.4. Introduction to AppArmor
14.4.1. Principles
14.4.2. Enabling AppArmor and managing AppArmor profiles
14.4.3. Creating a new profile
14.5. Introduction to SELinux
14.5.1. Principles
14.5.2. Setting Up SELinux
14.5.3. Managing an SELinux System
14.5.4. Adapting the Rules
14.6. Other Security-Related Considerations
14.6.1. Inherent Risks of Web Applications
14.6.2. Knowing What To Expect
14.6.3. Choosing the Software Wisely
14.6.4. Managing a Machine as a Whole
14.6.5. Users Are Players
14.6.6. Physical Security
14.6.7. Legal Liability
14.7. Dealing with a Compromised Machine
14.7.1. Detecting and Seeing the Cracker's Intrusion
14.7.2. Putting the Server Off-Line
14.7.3. Keeping Everything that Could Be Used as Evidence
14.7.4. Re-installing
14.7.5. Forensic Analysis
14.7.6. Reconstituting the Attack Scenario
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”.

14.1. Defining a Security Policy

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.
The very first thing to determine is therefore the goal. A good approach to help with that determination starts with the following questions:
  • What 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.
  • What are we trying to protect against? Is it leakage of confidential data? Accidental data loss? Revenue loss caused by disruption of service?
  • Also, who 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.
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.
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.
Once the risk has been modeled, one can start thinking about designing an actual security policy.
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.