Difference between revisions of "DefenseInDepth"

From Hackepedia
Jump to navigationJump to search
(Initial page)
 
m (changed ssh case sensitivity)
 
Line 1: Line 1:
 
A common security practice is known as "defense in depth."  This comes from a military term of the same name (See [[wikipedia:Defense_in_depth]] for historical details).
 
A common security practice is known as "defense in depth."  This comes from a military term of the same name (See [[wikipedia:Defense_in_depth]] for historical details).
  
The basic premise is to avoid a single point of failure when defending your systems and network against attackers.  This typically means that network traffic must be allowed to pass through multiple checks, in multiple locations within your network.  For example, an inbound [[SSH]] session must pass through many tests before the server process even starts the user authorization mechanism:
+
The basic premise is to avoid a single point of failure when defending your systems and network against attackers.  This typically means that network traffic must be allowed to pass through multiple checks, in multiple locations within your network.  For example, an inbound [[Ssh]] session must pass through many tests before the server process even starts the user authorization mechanism:
 
# Access control lists on the border [[router]].
 
# Access control lists on the border [[router]].
 
# One or more rules on a network firewall.
 
# One or more rules on a network firewall.

Latest revision as of 20:57, 14 February 2006

A common security practice is known as "defense in depth." This comes from a military term of the same name (See wikipedia:Defense_in_depth for historical details).

The basic premise is to avoid a single point of failure when defending your systems and network against attackers. This typically means that network traffic must be allowed to pass through multiple checks, in multiple locations within your network. For example, an inbound Ssh session must pass through many tests before the server process even starts the user authorization mechanism:

  1. Access control lists on the border router.
  2. One or more rules on a network firewall.
  3. In large networks, perhaps additional router and firewall ACLs.
  4. A host-based firewall.
  5. TCP Wrappers, also running on the destination host.
  6. Any additional application-level access controls (such as Allow/Deny rules in Apache).

Once the network traffic has run this gauntlet of tests, the SSH session is allowed to actually begin, and the user may attempt to authenticate.

The advantage to using defense in depth is that multiple failures or misconfigurations are required to cause problems. If, for example, the border router has few, if any, restrictions on traffic flow, the network firewall, or host firewall, or tcpwrappers, or an application restriction can stop non-permitted traffic.

The disadvantage, obviously, is that of complexity. Since the most common (and safest) policy is to deny everything not explicitly permitted, each and every place that can restrict traffic must be correctly configured. This can be very frustrating during initial configurations.