[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New Draft: draft-lewis-infrastructure-security-00.txt
I have added a few comments.
Look for djs> to mark my comments.
I will also snip as much of the text as possible leaving only the
related portions to provide context.
<SNIP>
1. Introduction
<SNIP>
This document presents
techniques that, together with network edge ingress filtering and RFC
2267 and RFC 3704, create a layered approach for infrastructure
protection.
djs> create defense in depth approach for infrastructure protection.
Denial of Service (DoS) attacks are common and the network
infrastructure itself is a target. Attacks targeting the network
infrastructure can take many forms, ranging from bandwidth saturation
to crafted packets destined to a router. These attacks might use
spoofed source address or they might use the true address of source
of the traffic. Regardless of the nature of the attack, the network
infrastructure must be protected from both accidental and intentional
attacks.
djs> infrastructure must be protected from accidental floods and
intentional attacks.
djs> Additionally this protection will assist in preventing the network
elements from
djs> being used as reflectors in attacks against others.
The techniques outlined in this document and described in section 2
below, provide a layered approach for infrastructure protection:
djs> provide a defense in depth approach for ...
Edge policy (filtering and precedence), per device traffic policy
enforcement for packets destined to a device and finally,
routing/address advertising best practices to limit core network --
that is P and PE infrastructure -- exposure.
This document is aimed at network operators who would like to
"harden" their infrastructure and make it more resilient to external
djs> This document is targeted at network operators who would like to
djs> limit their exposure to risks within their infrastructure and ...
attack. These techniques are designed to be used in addition to
specific protocol or application security features implemented in
network devices.
Infrastructure protection is a complex topic, improving protection is
always beneficial.
<SNIP>
2.1. Edge Infrastructure Access Control Lists
Edge infrastructure access control lists are ingress access control
lists that filter traffic destined to the network only. They should
permit all traffic through the network.
djs> They should permit all transit traffic.
Explicit filtering of
traffic destined to network devices creates a first level of
protection at the network edge: only traffic explicitly permitted
djs> traffic destined towards network devices creates a first layer of
djs> protection at the network edge. Only traffic explicity permitted
into the network can reach a device beyond the PE router with the
filter.
Although very effective, edge infrastructure access control lists are
not perfect and, like any filter lists, must be maintained and
djs> are seldom implemented completely or perfectly and, ...
updated. Furthermore, while widespread deployment on ingress
interface provides the most protection (which in some cases will not
be possible), some deployment is better than no deployment.
djs> (complete deployment in some cases will not be possible)
djs> partial deployment reduces the exposure of risks to some degree
djs> depending on how complete the deployment.
djs> The closer to the ingress point the better, however some edge
devices will not support filtering.
djs> In those cases a filter that is close to the edge can still limit
the exposure.
2.2. Edge Remarking
We define Edge Remarking as ensuring that ingress IP precedence or
DSCP values match expected values within the context of security.
This provides another layer of defense particularly for traffic
permitted through any of the Edge Infrastructure Access Control
Gill, Lewis, Quinn, Schoenmaker Section 2.2. [Page 5]
INTERNET-DRAFT Expires: October
2006
Lists. In this RFC we focus only on using Edge Remarking best
practices to enforce security policies.
djs> Remark packets that will traverse network elements that honor IP
precedence or DSCP valuses.
2.3. Device and Element Protection
Each device infrastructure device should enforce local rules for
traffic destined to the device itself. These rules can take the form
of filters (permit/deny) or rate limiting rules that allow ingress
traffic at specified rates. These should complement any existing
Edge Infrastructure Access Control Lists.
The deployment of these local device protection rules compliments the
edge techniques by protecting the device from traffic that: i) was
permitted but violates device policy, ii) could not be filtered at
the edge, iii) entered the network on an interface that did not have
ingress filtering enabled.
djs> iii is a subset/element of ii right?
2.4. Infrastructure Hiding
Hiding the infrastructure of the network provides an elegant
mechanism for protecting the network infrastructure. If the
destination of an attack is to an infrastructure address that is
unreachable, attacks become far more difficult.
djs> If the destination of an attack is towards an infrastructure
address
djs> that is not externally targetable or has limited targetablity,
attacks become far more difficult.
Infrastructure
hiding can be achieved in several ways:
- MPLS techniques
- IGP configuration
- Route advertisement control
3. Edge Infrastructure Access Control Lists
Edge Infrastructure Access Control Lists (EIACLs) are a specific
implementation of the more general Ingress Access List. As opposed
to generic ingress filtering which denies data (sometimes referred to
as user) plane traffic, edge infrastructure access control lists do
djs> (sometimes referred to
djs> as user plane) traffic, edge infrastructure access control lists
do
Gill, Lewis, Quinn, Schoenmaker Section 3. [Page 6]
INTERNET-DRAFT Expires: October
2006
not attempt to deny traffic going through the devices, rather this
form of access control limits traffic destined to infrastructure
djs>not attempt to deny transit traffic, rather this
djs>form of access control limits traffic destined towards
infrastructure
equipment while permitting -- if needed, explicitly -- traffic
through the network.
3.1. Constructing the Access List
Edge Infrastructure Access Control Lists permit only required traffic
to the network infrastructure,
djs>Edge Infrastructure Access Control Lists permits only required
traffic
djs>targeted towards the network infrastructure,
while allowing data plane traffic to
flow through unaffected.
djs>while allowing data plane traffic to
djs>flow through unfiltered.
The basic premise of EIACLs is that only a
relatively limited subset of traffic, sourced from outside your AS,
djs>AS vs. network? Many networks have multiple ASes.
needs to be destined for a core router and that by explicitly
djs> needs to be destined towards a infrastructor router and that by
explicitly
permitting only that known and understood traffic, the core devices
djs> the infrastructor devices
are not subjected to unnecessary traffic that might result in a
denial of service attack.
djs> denial of service. The word attack implies your only addressing
actual intentional attacks.
Since edge infrastructure access control lists protect only the
infrastructure, the development of the list differs somewhat from
"traditional" access filter lists:
1. Review addressing scheme, and identify address block(s)
that represent core devices.
djs> that represent infrastructor devices.
2. Determine what traffic must be destined to the core devices
from outside the AS.
djs> towards the infrastructor devices from outside the service
provider's network.
3. Create a filter that allow the required traffic, denies all
traffic destined to the core address block and then finally, permits
all other traffic to all.
As with other ingress filtering techniques, EIACLs are applied on
ingress into the network, and clearly comprehensive coverage (i.e. on
as many interface as possible) yields the most protection.
djs> EIACLs are applied as close to the ingress point as feasible
djs> and the more comprehensive the coverage the better the protection.
3.2. Other Traffic
In addition to the explicitly permitted traffic, EIACLs can be
combined with other common edge filters such as:
1. Source spoof prevention (as per RFC 3704) by denying
internal AS addresses as external sources.
Gill, Lewis, Quinn, Schoenmaker Section 3.2. [Page 7]
INTERNET-DRAFT Expires: October
2006
2. Filtering of reserved addresses (e.g. rfc1918 addresses) as
traffic should not be sourced from reserved address.
3. Other unneeded or unnecessary traffic
Filtering this traffic can be part of the list explicitly or
implicitly, however, explicit filters often provides log-able
information that can be of use during a security event.
3.3. Edge Infrastructure Conclusion
Edge Infrastructure Access Control Lists provide a very effective
first line of defense. To deploy them effectively, core address
space must be identifiable and widespread deployment is necessary.
4. Edge Rewrite/Remarking
RFC 1812 section 5.3 defines the use of IP Preference in IPv4 packets
for routing, management and control traffic. In addition it
recommends devices use a mechanism for providing preferential
forwarding for packets marked as routing, management or control
traffic using IP Preference bits 6 or 7 (110 or 111 in binary.)
RFC2474 defines DSCP and the compatibility of IP Preference bits when
using DSCP.
All packets received from the Customer edge (CE,) and the Peer Edge
by the Provider Edge (PE,) with IP Preference values of 6 or 7 or
DSCP bits of 11xxxx, as specified in RFC2474 Differentiated Services
Field Definition, should have the IP Preference bits rewritten.
Routing traffic received from the CE and the Peer Edge can safely
have the IP Preference bits rewritten, because only a limited number
of protocols are transmitted beyond the first PE router. The bits
may be rewritten to any value other than IP Preference values 6 or 7,
or any DSCP value other than 11xxxx. The new value can be based on
the network operators IP Preference or DSCP policy. If no policy
exists the bits should be rewritten to 0.
djs> EBGP could be multihop and you may want to leave the DSCP bits
alone?
Providers may not want to modify traffic that goes through their
network in an effort offer a fully transparent service. If the
provider relies on alternative means of classifying traffic for
prioritized forwarding rewriting the IP Preference bits is not
<SNIP>
4.1. Edge Rewriting/Remarking Discussion
By default router vendors do not differentiate an interface on a PE
router connected to a P router from an interface connected to a CE
router. As a result any packet with the proper IP Preference or DSCP
bits set may receive the same preferential forwarding behavior as
legitimate routing, management, and control traffic. A malicious
attack may be able to take advantage of the vulnerability to increase
the effectiveness of the attack or to attack the routing, management,
and/or control traffic directly.
This document is aimed at protecting network infrastructure from
traffic to the device rather than traffic through the device. Even
though the edge rewrite/remarking deals primarily with traffic
through a device it is included because the traffic has a direct
impact on traffic to a device. The forwarding prioritization given
to routing, management, and control traffic by default leaves devices
vulnerable to indirect attacks to the core infrastructure.
djs> vulnerable to indirect attacks to the infrastructure.
<SNIP>
5.1. Service Specific Access Control
Typically these mechanisms are not concerned with protecting the
system as a whole, but the service from exploitation. The goal is
not overall system availability, but maximizing the security of the
particular service.
djs> The systems availablity is dependant on the security of the
services running on the system.
<SNIP>
5.2.3. Access Control Implementation Guide
Implementing a complex set of access controls for all traffic going
to and from a router is non trivial. The following is a recommended
set of steps that has been used successfully by many carriers.
-Develop list of required protocols
-Develop source address requirements
-Determine destination interface on router
Does the protocol access a single interface?
Does the protocol access many interfaces?
Does the protocol access a virtual or physical interfaces?
-Deployment should be an iterative process
djs> -start with log instead of drop if possible and review the
logs.
-Start with relatively open lists then tighten as needed
5.3. Device Access Authorization and Accounting
Operators should use per command authorization and accounting
wherever possible. Aside from their utility in mitigating other
security threats, they provide an invaluable tool in the post event
forensics.
djs> AAA seems out of place here. I agree its important and that logs of
commands
djs> is a great after actions item to have.
<SNIP>
6. Infrastructure Hiding
Hiding the infrastructure of the network provides an elegant
mechanism for protecting the network infrastructure. If the
destination of an attack is to an infrastructure address that is
unreachable, attacks become far more difficult. Infrastructure
djs> untargetable or difficult to target.
djs> Its still really reachable via the transit traffic plane.
hiding can be achieved in several ways:
<SNIP>
6.4.2. Address core out of rfc1918 space
In addition to filtering the visibility of core addresses to the
wider Internet, it may be possible to use rfc1918 netblocks for
numbering infrastructure when IP addresses are required (eg,
loopbacks). This added level of obscurity takes prevention of wide
distribution of your infrastructure address space one step further.
Many networks filter out packets with rfc1918 address at
ingress/egress points as a matter of course. In this circumstance,
tools such as traceroute can work through your core, but reverse-
resolution of descriptive names should be restricted to queries from
internal/support groups.
djs> I think changing the default ports for services should be included
here.
djs> This is really service hiding but it can be used to limit your
exposure.
6.5 Change the ports services run on.
Many attack tools, worms, auto-rooters hardcode in the destination
port.
Changing that port to something that is not the well known port can
provide additional protection from such tools. This will not protect
you against
a determined attacker.
<SNIP>
Security through obscurity WORKS against some worms and other tools:)
Donald.Smith@qwest.com giac
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.