Franks: changed ssh case sensitivity

2006-02-15T03:57:32Z

changed ssh case sensitivity

← Older revision		Revision as of 20:57, 14 February 2006
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.

Hawson: Initial page

2005-10-27T00:16:34Z

Initial page

New page

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:
# Access control lists on the border [[router]].
# One or more rules on a network firewall.
# In large networks, perhaps additional router and firewall ACLs.
# A host-based firewall.
# [[TCP Wrappers]], also running on the destination host.
# 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 [[DefaultDeny|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.

DefenseInDepth - Revision history

Franks: changed ssh case sensitivity

Hawson: Initial page