center has many vulnerable servers that are infected and
simultaneously sending large amounts of traffic with the result
that all outbound links are saturated. Implementation of this
requirement, would allow the network operator to rate limit
inbound and/or outbound TCP 1433 traffic (possibly to a rate of 0
packets/bytes per second) to respond to the attack and maintain
service levels for other legitimate customers/traffic.
Warnings.
None.
2.6.2. Support Directional Application Of Rate Limiting Per Interface
Requirement.
The device MUST provide support to rate-limit input and/or output
separately on each interface.
Justification.
This level of granular control allows appropriately targeted
controls that minimize the impact on third parties.
Examples.
If an ICMP flood is directed a single customer on an edge router,
it may be appropriate to rate-limit outbound ICMP only on that
customers interface.
Warnings.
None.
2.6.3. Support Rate Limiting Based on State
Requirement.
The device MUST be able to rate limit based on all TCP control
flag bits. The device SHOULD support rate limiting of other
stateful protocols where the normal processing of the protocol
gives the device access to protocol state.
Justification.
This allows appropriate response to certain classes of attack.
Examples.
For example, for TCP sessions, it should be possible to rate limit
based on the SYN, SYN-ACK, RST, or other bit state.
Warnings.
None.
2.7. Basic Filtering Capabilities
2.7.1. Ability to Filter Traffic
Requirement.
The device MUST provide a means to filter IP packets on any
interface implementing IP.
Justification.
Packet filtering is important because it provides a basic means of
implementing policies that specify which traffic is allowed and
which is not. It also provides a basic tool for responding to
malicious traffic.
Examples.
Access control lists that allow filtering based on protocol and/or
source/destination address and or source/destination port would be
one example.
Warnings.
None.
2.7.2. Ability to Filter Traffic TO the Device
Requirement.
It MUST be possible to apply the filtering mechanism to traffic
that is addressed directly to the device via any of its interfaces
- including loopback interfaces.
Justification.
This allows the operator to apply filters that protect the device
itself from attacks and unauthorized access.
Examples.
Examples of this might include filters that permit only BGP from
peers and SNMP and SSH from an authorized management segment and
directed to the device itself, while dropping all other traffic
addressed to the device.
Warnings.
None.
2.7.3. Ability to Filter Traffic THROUGH the Device
Requirement.
It MUST be possible to apply the filtering mechanism to traffic
that is being routed (switched) through the device.
Justification.
This permits implementation of basic policies on devices that
carry transit traffic (routers, switches, etc.).
Examples.
One simple and common way to meet this requirement is to provide
the ability to filter traffic inbound to each interface and/or
outbound from each interface. Ingress filtering as described in
[RFC2827] provides one example of the use of this capability.
Warnings.
None.
2.7.4. Ability to Filter Without Significant Performance Degradation
Requirement.
The device MUST provide a means to filter packets without
significant performance degradation. This specifically applies to
stateless packet filtering operating on layer 3 (IP) and layer 4
(TCP or UDP) headers, as well as normal packet forwarding
information such as incoming and outgoing interfaces.
The device MUST be able to apply stateless packet filters on ALL
interfaces (up to the maximum number possible) simultaneously and
with multiple filters per interface (e.g., inbound and outbound).
Justification.
This enables the implementation of filtering wherever and whenever
needed. To the extent that filtering causes degradation, it may
not be possible to apply filters that implement the appropriate
policies.
Examples.
Another way of stating the requirement is that filter performance
should not be the limiting factor in device throughput. If a
device is capable of forwarding 30Mb/sec without filtering, then
it should be able to forward the same amount with filtering in
place.
Warnings.
The definition of "significant" is subjective. At one end of the
spectrum it might mean "the application of filters may cause the
box to crash". At the other end would be a throughput loss of
less than one percent with tens of thousands of filters applied.
The level of performance degradation that is acceptable will have
to be determined by the operator.
Repeatable test data showing filter performance impact would be
very useful in evaluating conformance with this requirement.
Tests should include such information as packet size, packet rate,
number of interfaces tested (source/destination), types of
interfaces, routing table size, routing protocols in use,
frequency of routing updates, etc. See [bmwg-acc-bench].
This requirement does not address stateful filtering, filtering
above layer 4 headers or other more advanced types of filtering
that may be important in certain operational environments.
2.7.5. Support Route Filtering
Requirement.
The device MUST provide a means to filter routing updates for all
protocols used to exchange external routing information.
Justification.
See [RFC3013] and section 3.2 of [RFC2196].
Examples.
Operators may wish to ignore advertisements for routes to
addresses allocated for private internets. See eBGP.
Warnings.
None.
2.7.6. Ability to Specify Filter Actions
Requirement.
The device MUST provide a mechanism to allow the specification of
the action to be taken when a filter rule matches. Actions MUST
include "permit" (allow the traffic), "reject" (drop with
appropriate notification to sender), and "drop" (drop with no
notification to sender). Also see Section 2.7.7 and Section 2.9
Justification.
This capability is essential to the use of filters to enforce
policy.
Examples.
Assume that you have a small DMZ network connected to the
Internet. You want to allow management using SSH coming from your
corporate office. In this case, you might "permit" all traffic to
port 22 in the DMZ from your corporate network, "rejecting" all
others. Port 22 traffic from the corporate network is allowed
through. Port 22 traffic from all other addresses results in an
ICMP message to the sender. For those who are slightly more
paranoid, you might choose to "drop" instead of "reject" traffic
from unauthorized addresses, with the result being that *nothing*
is sent back to the source.
Warnings.
While silently dropping traffic without sending notification may
be the correct action in security terms, consideration should be
given to operational implications. See [RFC3360] for
consideration of potential problems caused by sending
inappropriate TCP Resets.
2.7.7. Ability to Log Filter Actions
Requirement.
It MUST be possible to log all filter actions. The logging
capability MUST be able to capture at least the following data:
* permit/deny/drop status,
* source and destination IP address,
* source and destination ports (if applicable to the protocol),
* which network element received the packet (interface, MAC
address or other layer 2 information that identifies the
previous hop source of the packet).
Logging of filter actions is subject to the requirements of
Section 2.11.
Justification.
Logging is essential for auditing, incident response, and
operations.
Examples.
A desktop network may not provide any services that should be
accessible from "outside." In such cases, all inbound connection
attempts should be logged as possible intrusion attempts.
Warnings.
None.
2.8. Packet Filtering Criteria
2.8.1. Ability to Filter on Protocols
Requirement.
The device MUST provide a means to filter traffic based on the
value of the protocol field in the IP header.
Justification.
Being able to filter on protocol is necessary to allow
implementation of policy, secure operations and for support of
incident response.
Examples.
Some denial of service attacks are based on the ability to flood
the victim with ICMP traffic. One quick way (admittedly with some
negative side effects) to mitigate the effects of such attacks is
to drop all ICMP traffic headed toward the victim.
Warnings.
None.
2.8.2. Ability to Filter on Addresses
Requirement.
The function MUST be able to control the flow of traffic based on
source and/or destination IP address or blocks of addresses such
as Classless Inter-Domain Routing (CIDR) blocks.
Justification.
The capability to filter on addresses and address blocks is a
fundamental tool for establishing boundaries between different
networks.
Examples.
One example of the use of address based filtering is to implement
ingress filtering per [RFC2827].
Warnings.
None.
2.8.3. Ability to Filter on Protocol Header Fields
Requirement.
The filtering mechanism MUST support filtering based on the
value(s) of any portion of the protocol headers for IP, ICMP, UDP
and TCP. It SHOULD support filtering of all other protocols
supported at layer 3 and 4. It MAY support filtering based on the
headers of higher level protocols. It SHOULD be possible to
specify fields by name (e.g., "protocol = ICMP") rather than bit-
offset/length/numeric value (e.g., 72:8 = 1).
Justification.
Being able to filter on portions of the header is necessary to
allow implementation of policy, secure operations, and support
incident response.
Examples.
This requirement implies that it is possible to filter based on
TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits,
and ICMP type and code fields. One common example is to reject
"inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear
or SYN bit set+ACK,FIN and RST bits clear). Another common
example is the ability to control what services are allowed in/out
of a network. It may be desirable to only allow inbound
connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting
web servers.
Warnings.
None.
2.8.4. Ability to Filter Inbound and Outbound
Requirement.
It MUST be possible to filter both incoming and outgoing traffic
on any interface.
Justification.
This requirement allows flexibility in applying filters at the
place that makes the most sense. It allows invalid or malicious
traffic to be dropped as close to the source as possible.
Examples.
It might be desirable on a border router, for example, to apply an
egress filter outbound on the interface that connects a site to
its external ISP to drop outbound traffic that does not have a
valid internal source address. Inbound, it might be desirable to
apply a filter that blocks all traffic from a site that is known
to forward or originate lots of junk mail.
Warnings.
None.
2.9. Packet Filtering Counter Requirements
2.9.1. Ability to Accurately Count Filter Hits
Requirement.
The device MUST supply a facility for accurately counting all
filter hits.
Justification.
Accurate counting of filter rule matches is important because it
shows the frequency of attempts to violate policy. This enables
resources to be focused on areas of greatest need.
Examples.
Assume, for example, that a ISP network implements anti-spoofing
egress filters (see [RFC2827]) on interfaces of its edge routers
that support single-homed stub networks. Counters could enable
the ISP to detect cases where large numbers of spoofed packets are
being sent. This may indicate that the customer is performing
potentially malicious actions (possibly in violation of the ISPs
Acceptable Use Policy), or that system(s) on the customers network
have been "owned" by hackers and are being (mis)used to launch
attacks.
Warnings.
None.
2.9.2. Ability to Display Filter Counters
Requirement.
The device MUST provide a mechanism to display filter counters.
Justification.
Information that is collected is not useful unless it can be
displayed in a useful manner.
Examples.
Assume there is a router with four interfaces. One is an up-link
to an ISP providing routes to the Internet. The other three
connect to separate internal networks. Assume that a host on one
of the internal networks has been compromised by a hacker and is
sending traffic with bogus source addresses. In such a situation,
it might be desirable to apply ingress filters to each of the
internal interfaces. Once the filters are in place, the counters
can be examined to determine the source (inbound interface) of the
bogus packets.
Warnings.
None.
2.9.3. Ability to Display Filter Counters per Rule
Requirement.
The device MUST provide a mechanism to display filter counters per
rule.
Justification.
This makes it possible to see which rules are matching and how
frequently.
Examples.
Assume that a filter has been defined that has two rules, one
permitting all SSH traffic (tcp/22) and the second dropping all
remaining traffic. If three packets are directed toward/through
the point at which the filter is applied, one to port 22, the
others to different ports, then the counter display should show 1
packet matching the permit tcp/22 rule and 2 packets matching the
deny all others rule.
Warnings.
None.
2.9.4. Ability to Display Filter Counters per Filter Application
Requirement.
If it is possible for a filter to be applied more than once at the
same time, then the device MUST provide a mechanism to display
filter counters per filter application.
Justification.
It may make sense to apply the same filter definition
simultaneously more than one time (to different interfaces, etc.).
If so, it would be much more useful to know which instance of a
filter is matching than to know that some instance was matching
somewhere.
Examples.
One way to implement this requirement would be to have the counter
display mechanism show the interface (or other entity) to which
the filter has been applied, along with the name (or other
designator) for the filter. For example if a filter named
"desktop_outbound" applied two different interfaces, say,
"ethernet0" and "ethernet1", the display should indicate something
like "matches of filter ’desktop_outbound’ on ethernet0 ..." and
"matches of filter ’desktop_outbound’ on ethernet1 ..."
Warnings.
None.
2.9.5. Ability to Reset Filter Counters
Requirement.
It MUST be possible to reset counters to zero on a per filter
basis.
For the purposes of this requirement it would be acceptable for
the system to maintain two counters: an "absolute counter",
C[now], and a "reset" counter, C[reset]. The absolute counter
would maintain counts that increase monotonically until they wrap
or overflow the counter. The reset counter would receive a copy
of the current value of the absolute counter when the reset
function was issued for that counter. Functions that display or
retrieve the counter could then display the delta (C[now] -
C[reset]).
Justification.
This allows operators to get a current picture of the traffic
matching particular rules/filters.
Examples.
Assume that filter counters are being used to detect internal
hosts that are infected with a new worm. Once it is believed that
all infected hosts have been cleaned up and the worm removed, the
next step would be to verify that. One way of doing so would be
to reset the filter counters to zero and see if traffic indicative
of the worm has ceased.
Warnings.
None.
2.9.6. Filter Counters Must Be Accurate
Requirement.
Filter counters MUST be accurate. They MUST reflect the actual
number of matching packets since the last counter reset. Filter
counters MUST be capable of holding up to 2^32 - 1 values without
overflowing and SHOULD be capable of holding up to 2^64 - 1
values.
Justification.
Inaccurate data can not be relied on as the basis for action.
Underreported data can conceal the magnitude of a problem.
Examples.
If N packets matching a filter are sent to/through a device, then
the counter should show N matches.
Warnings.
None.
2.10. Other Packet Filtering Requirements
2.10.1. Ability to Specify Filter Log Granularity
Requirement.
It MUST be possible to enable/disable logging on a per rule basis.
Justification.
The ability to tune the granularity of logging allows the operator
to log only the information that is desired. Without this
capability, it is possible that extra data (or none at all) would
be logged, making it more difficult to find relevant information.
Examples.
If a filter is defined that has several rules, and one of the
rules denies telnet (tcp/23) connections, then it should be
possible to specify that only matches on the rule that denies
telnet should generate a log message.
Warnings.
None.
2.11. Event Logging Requirements
2.11.1. Logging Facility Uses Protocols Subject To Open Review
Requirement.
The device MUST provide a logging facility that is based on
protocols subject to open review. See Section 1.8. Custom or
proprietary logging protocols MAY be implemented provided the same
information is made available.
Justification.
The use of logging based on protocols subject to open review
permits the operator to perform archival and analysis of logs
without relying on vendor-supplied software and servers.
Examples.
This requirement may be satisfied by the use of one or more of
syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+
[RFC1492] or RADIUS [RFC2865].
Warnings.
While [RFC3164] meets this requirement, it has many security
issues and by itself does not meet the requirements of Section
2.1.1. See the security considerations section of [RFC3164] for
a list of issues. [RFC3195] provides solutions to most/all of
these issues....however at the time of this writing there are few
implementations. Other possible solutions might be to tunnel
syslog over a secure transport...but this often raises difficult
key management and scalability issues.
The current best solution seems to be the following:
* Implement [RFC3164].
* Consider implementing [RFC3195].
2.11.2. Logs Sent To Remote Servers
Requirement.
The device MUST support transmission of records of security
related events to one or more remote devices. There MUST be
configuration settings on the device that allow selection of
servers.
Justification.
This is important because it supports individual accountability.
It is important to store them on a separate server to preserve
them in case of failure or compromise of the managed device.
Examples.
This requirement may be satisfied by the use of one or more of:
syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+
[RFC1492] or RADIUS [RFC2865].
Warnings.
Note that there may be privacy or legal considerations when
logging/monitoring user activity.
High volumes of logging may generate excessive network traffic
and/or compete for scarce memory and CPU resources on the device.
2.11.3. Ability to Select Reliable Delivery
Requirement.
It SHOULD be possible to select reliable delivery of log messages.
Justification.
Reliable delivery is important to the extent that log data is
depended upon to make operational decisions and forensic analysis.
Without reliable delivery, log data becomes a collection of hints.
Examples.
One example of reliable syslog delivery is defined in [RFC3195].
Syslog-ng provides another example, although the protocol has not
been standardized.
Warnings.
None.
2.11.4. Ability to Log Locally
Requirement.
It SHOULD be possible to log locally on the device itself. Local
logging SHOULD be written to non-volatile storage.
Justification.
Local logging of failed authentication attempts to non-volatile
storage is critical. It provides a means of detecting attacks
where the device is isolated from its authentication interfaces
and attacked at the console.
Local logging is important for viewing information when connected
to the device. It provides some backup of log data in case remote
logging fails. It provides a way to view logs relevant to one
device without having to sort through a possibly large set of logs
from other devices.
Examples.
One example of local logging would be a memory buffer that
receives copies of messages sent to the remote log server.
Another example might be a local syslog server (assuming the
device is capable of running syslog and has some local storage).
Warnings.
Storage on the device may be limited. High volumes of logging may
quickly fill available storage, in which case there are two
options: new logs overwrite old logs (possibly via the use of a