RFC 3871
Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure
2.4. Configuration and Management Interface Requirements
This section lists requirements that support secure device configuration and management methods. In most cases, this currently involves some sort of command line interface (CLI) and configuration files. It may be possible to meet these requirements with other mechanisms, for instance SNMP or a script-able HTML interface that provides full access to management and configuration functions. In the future, there may be others (e.g., XML based configuration).2.4.1. 'CLI' Provides Access to All Configuration and Management Functions
Requirement. The Command Line Interface (CLI) or equivalent MUST allow complete access to all configuration and management functions. The CLI MUST be supported on the console (see Section 2.3.1) and SHOULD be supported on all other interfaces used for management. Justification. The CLI (or equivalent) is needed to provide the ability to do reliable, fast, direct, local management and monitoring of a device. It is particularly useful in situations where it is not possible to manage and monitor the device in-band via "normal" means (e.g., SSH or SNMP [RFC3410], [RFC3411]) that depend on functional networking. Such situations often occur during security incidents such as bandwidth-based denial of service attacks.
Examples.
Examples of configuration include setting interface addresses,
defining and applying filters, configuring logging and
authentication, etc. Examples of management functions include
displaying dynamic state information such as CPU load, memory
utilization, packet processing statistics, etc.
Warnings.
None.
2.4.2. 'CLI' Supports Scripting of Configuration
Requirement.
The CLI or equivalent MUST support external scripting of
configuration functions. This CLI SHOULD support the same command
set and syntax as that in Section 2.4.1.
Justification.
During the handling of security incidents, it is often necessary
to quickly make configuration changes on large numbers of devices.
Doing so manually is error prone and slow. Vendor supplied
management solutions do not always foresee or address the type or
scale of solutions that are required. The ability to script
provides a solution to these problems.
Examples.
Example uses of scripting include: tracking an attack across a
large network, updating authentication parameters, updating
logging parameters, updating filters, configuration fetching/
auditing, etc. Some languages that are currently used for
scripting include expect, Perl and TCL.
Warnings.
Some properties of the command language that enhance the ability
to script are: simplicity, regularity and consistency. Some
implementations that would make scripting difficult or impossible
include: "text menu" style interfaces (e.g., "curses" on UNIX) or
a hard-coded GUI interfaces (e.g., a native Windows or Macintosh
GUI application) that communicate using a proprietary or
undocumented protocol not based on a CLI.
2.4.3. 'CLI' Supports Management Over 'Slow' Links
Requirement. The device MUST support a command line interface (CLI) or equivalent mechanism that works over low bandwidth connections. Justification. There are situations where high bandwidth for management is not available, for example when in-band connections are overloaded during an attack or when low-bandwidth, out-of-band connections such as modems must be used. It is often under these conditions that it is most crucial to be able to perform management and configuration functions. Examples. The network is down. The network engineer just disabled routing by mistake on the sole gateway router in a remote unmanned data center. The only access to the device is over a modem connected to a console port. The data center customers are starting to call the support line. The GUI management interface is redrawing the screen multiple times...slowly... at 9600bps. One mechanism that supports operation over slow links is the ability to apply filters to the output of CLI commands which have potentially large output. This may be implemented with something similar to the UNIX pipe facility and "grep" command. For example, cat largefile.txt | grep interesting-string Another is the ability to "page" through large command output, e.g., the UNIX "more" command: For example, cat largefile.txt | more Warnings. One consequence of this requirement may be that requiring a GUI interface for management is unacceptable unless it can be shown to work acceptably over slow links.
2.4.4. 'CLI' Supports Idle Session Timeout
Requirement. The command line interface (CLI) or equivalent mechanism MUST support a configurable idle timeout value. Justification. Network administrators go to lunch. They leave themselves logged in with administrative privileges. They forget to use screen- savers with password protection. They do this while at conferences and in other public places. This behavior presents opportunity for unauthorized access. Idle timeouts reduce the window of exposure. Examples. The CLI may provide a configuration command that allows an idle timeout to be set. If the operator does not enter commands for that amount of time, the login session will be automatically terminated. Warnings. None.2.4.5. Support Software Installation
Requirement. The device MUST provide a means to install new software versions. It MUST be possible to install new software while the device is disconnected from all public IP networks. This MUST NOT rely on previous installation and/or configuration. While new software MAY be loaded from writable media (disk, flash, etc.), the capability to load new software MUST depend only on non-writable media (ROM, etc.). The installation procedures SHOULD support mechanisms to ensure reliability and integrity of data transfers. Justification. * Vulnerabilities are often discovered in the base software (operating systems, etc.) shipped by vendors. Often mitigation of the risk presented by these vulnerabilities can only be accomplished by updates to the vendor supplied software (e.g., bug
fixes, new versions of code, etc.). Without a mechanism to load
new vendor supplied code, it may not be possible to mitigate the
risk posed by these vulnerabilities.
* It is also conceivable that malicious behavior on the part of
hackers or unintentional behaviors on the part of operators could
cause software on devices to be corrupted or erased. In these
situations, it is necessary to have a means to (re)load software
onto the device to restore correct functioning.
* It is important to be able to load new software while disconnected
from all public IP networks because the device may be vulnerable
to old attacks before the update is complete.
* One has to assume that hackers, operators, etc. may erase or
corrupt all writable media (disks, flash, etc.). In such
situations, it is necessary to be able to recover starting with
only non-writable media (e.g., CD-ROM, a true ROM-based monitor).
* System images may be corrupted in transit (from vendor to
customer, or during the loading process) or in storage (bit rot,
defective media, etc.). Failure to reliably load a new image, for
example after a hacker deletes or corrupts the installed image,
could result in extended loss of availability.
Examples.
The device could support booting into a simple ROM-based monitor
that supported a set of commands sufficient to load new operating
system code and configuration data from other devices. The
operating system and configuration might be loaded from:
RS232. The device could support uploading new code via an RS232
console port.
CD-ROM. The device could support installing new code from a
locally attached CD-ROM drive.
NETWORK. The device could support installing new code via a
network interface, assuming that (a) it is disconnected from all
public networks and (b) the device can boot an OS and IP stack
from some read-only media with sufficient capabilities to load new
code from the network.
FLASH. The device could support booting from flash memory cards.
Simple mechanisms currently in use to protect the integrity of
system images and data transfer include image checksums and simple
serial file transfer protocols such as XMODEM and Kermit.
Warnings.
None.
2.4.6. Support Remote Configuration Backup
Requirement.
The device MUST provide a means to store the system configuration
to a remote server. The stored configuration MUST have sufficient
information to restore the device to its operational state at the
time the configuration is saved. Stored versions of the
configuration MAY be compressed using an algorithm which is
subject to open review, as long as the fact is clearly identified
and the compression can be disabled. Sensitive information such
as passwords that could be used to compromise the security of the
device MAY be excluded from the saved configuration.
Justification.
Archived configurations are essential to enable auditing and
recovery.
Examples.
Possible implementations include SCP, SFTP or FTP over a secure
channel. See Section 2.1.1 for requirements related to secure
communication channels for management protocols and data.
Warnings.
The security of the remote server is assumed, with appropriate
measures being outside the scope of this document.
2.4.7. Support Remote Configuration Restore
Requirement.
The device MUST provide a means to restore a configuration that
was saved as described in Section 2.4.6. The system MUST be
restored to its operational state at the time the configuration
was saved.
Justification.
Restoration of archived configurations allows quick restoration of
service following an outage (security related as well as from
other causes).
Examples.
Configurations may be restored using SCP, SFTP or FTP over a
secure channel. See Section 2.1.1 for requirements related to
secure communication channels for management protocols and data.
Warnings.
The security of the remote server is assumed, with appropriate
measures being outside the scope of this document.
Note that if passwords or other sensitive information are excluded
from the saved copy of the configuration, as allowed by Section
2.4.6, then the restore may not be complete. The operator may
have to set new passwords or supply other information that was not
saved.
2.4.8. Support Text Configuration Files
Requirement.
The device MUST support display, backup and restore of system
configuration in a simple well defined textual format. The
configuration MUST also be viewable as text on the device itself.
It MUST NOT be necessary to use a proprietary program to view the
configuration.
Justification.
Simple, well-defined textual configurations facilitate human
understanding of the operational state of the device, enable off-
line audits, and facilitate automation. Requiring the use of a
proprietary program to access the configuration inhibits these
goals.
Examples.
A 7-bit ASCII configuration file that shows the current settings
of the various configuration options would satisfy the
requirement, as would a Unicode configuration or any other
"textual" representation. A structured binary format intended
only for consumption by programs would not be acceptable.
Warnings.
Offline copies of configurations should be well protected as they
often contain sensitive information such as SNMP community
strings, passwords, network blocks, customer information, etc.
"Well defined" and "textual" are open to interpretation. Clearly
an ASCII configuration file with a regular, documented command
oriented-syntax would meet the definition. These are currently in
wide use. Future options, such as XML based configuration may
meet the requirement. Determining this will require evaluation
against the justifications listed above.
2.5. IP Stack Requirements
2.5.1. Ability to Identify All Listening Services
Requirement.
The vendor MUST:
* Provide a means to display all services that are listening for
network traffic directed at the device from any external
source.
* Display the addresses to which each service is bound.
* Display the addresses assigned to each interface.
* Display any and all port(s) on which the service is listing.
* Include both open standard and vendor proprietary services.
Justification.
This information is necessary to enable a thorough assessment of
the security risks associated with the operation of the device
(e.g., "does this protocol allow complete management of the device
without also requiring authentication, authorization, or
accounting?"). The information also assists in determining what
steps should be taken to mitigate risk (e.g., "should I turn this
service off ?")
Examples.
If the device is listening for SNMP traffic from any source
directed to the IP addresses of any of its local interfaces, then
this requirement could be met by the provision of a command which
displays that fact.
Warnings.
None.
2.5.2. Ability to Disable Any and All Services
Requirement.
The device MUST provide a means to turn off any "services" (see
Section 1.8).
Justification.
The ability to disable services for which there is no operational
need will allow administrators to reduce the overall risk posed to
the device.
Examples.
Processes that listen on TCP and UDP ports would be prime examples
of services that it must be possible to disable.
Warnings.
None.
2.5.3. Ability to Control Service Bindings for Listening Services
Requirement.
The device MUST provide a means for the user to specify the
bindings used for all listening services. It MUST support binding
to any address or net-block associated with any interface local to
the device. This must include addresses bound to physical or
non-physical (e.g., loopback) interfaces.
Justification.
It is a common practice among operators to configure "loopback"
pseudo-interfaces to use as the source and destination of
management traffic. These are preferred to physical interfaces
because they provide a stable, routable address. Services bound
to the addresses of physical interface addresses might become
unreachable if the associated hardware goes down, is removed, etc.
This requirement makes it possible to restrict access to
management services using routing. Management services may be
bound only to the addresses of loopback interfaces. The loopback
interfaces may be addressed out of net-blocks that are only routed
between the managed devices and the authorized management
networks/hosts. This has the effect of making it impossible for
anyone to connect to (or attempt to DoS) management services from
anywhere but the authorized management networks/hosts.
It also greatly reduces the need for complex filters. It reduces
the number of ports listening, and thus the number of potential
avenues of attack. It ensures that only traffic arriving from
legitimate addresses and/or on designated interfaces can access
services on the device.
Examples.
If the device listens for inbound SSH connections, this
requirement means that it should be possible to specify that the
device will only listen to connections destined to specific
addresses (e.g., the address of the loopback interface) or
received on certain interfaces (e.g., an Ethernet interface
designated as the "management" interface). It should be possible
in this example to configure the device such that the SSH is NOT
listening to every address configured on the device. Similar
effects may be achieved with the use of global filters, sometimes
called "receive" or "loopback" ACLs, that filter traffic destined
for the device itself on all interfaces.
Warnings.
None.
2.5.4. Ability to Control Service Source Addresses
Requirement.
The device MUST provide a means that allows the user to specify
the source addresses used for all outbound connections or
transmissions originating from the device. It SHOULD be possible
to specify source addresses independently for each type of
outbound connection or transmission. Source addresses MUST be
limited to addresses that are assigned to interfaces (including
loopbacks) local to the device.
Justification.
This allows remote devices receiving connections or transmissions
to use source filtering as one means of authentication. For
example, if SNMP traps were configured to use a known loopback
address as their source, the SNMP workstation receiving the traps
(or a firewall in front of it) could be configured to receive SNMP
packets only from that address.
Examples.
The operator may allocate a distinct block of addresses from which
all loopbacks are numbered. NTP and syslog can be configured to
use those loopback addresses as source, while SNMP and BGP may be
configured to use specific physical interface addresses. This
would facilitate filtering based on source address as one way of
rejecting unauthorized attempts to connect to peers/servers.
Warnings.
Care should be taken to assure that the addresses chosen are
routable between the sending and receiving devices, (e.g., setting
SSH to use a loopback address of 10.1.1.1 which is not routed
between a router and all intended destinations could cause
problems).
Note that some protocols, such as SCTP [RFC3309], can use more
than one IP address as the endpoint of a single connection.
Also note that [RFC3631] lists address-based authentication as an
"insecurity mechanism". Address based authentication should be
replaced or augmented by other mechanisms wherever possible.
2.5.5. Support Automatic Anti-spoofing for Single-Homed Networks
Requirement.
The device MUST provide a means to designate particular interfaces
as servicing "single-homed networks" (see Section 1.8) and MUST
provide an option to automatically drop "spoofed packets" (Section
1.8) received on such interfaces where application of the current
forwarding table would not route return traffic back through the
same interface. This option MUST work in the presence of dynamic
routing and dynamically assigned addresses.
Justification.
See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of
[RFC1812], and [RFC2827].
Examples.
This requirement could be satisfied in several ways. It could be
satisfied by the provision of a single command that automatically
generates and applies filters to an interface that implements
anti-spoofing. It could be satisfied by the provision of a
command that causes the return path for packets received to be
checked against the current forwarding tables and dropped if they
would not be forwarded back through the interface on which they
were received.
See [RFC3704].
Warnings.
This requirement only holds for single-homed networks. Note that
a simple forwarding table check is not sufficient in the more
complex scenarios of multi-homed or multi-attached networks, i.e.,
where the traffic may be asymmetric. In these cases, a more
extensive check such as Feasible Path RPF could be very useful.
2.5.6. Support Automatic Discarding Of Bogons and Martians
Requirement.
The device MUST provide a means to automatically drop all "bogons"
(Section 1.8) and "martians" (Section 1.8). This option MUST work
in the presence of dynamic routing and dynamically assigned
addresses.
Justification.
These sorts of packets have little (no?) legitimate use and are
used primarily to allow individuals and organization to avoid
identification (and thus accountability) and appear to be most
often used for DoS attacks, email abuse, hacking, etc. In
addition, transiting these packets needlessly consumes resources
and may lead to capacity and performance problems for customers.
See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of
[RFC1812], and [RFC2827].
Examples.
This requirement could be satisfied by the provision of a command
that causes the return path for packets received to be checked
against the current forwarding tables and dropped if no viable
return path exists. This assumes that steps are taken to assure
that no bogon entries are present in the forwarding tables (for
example filtering routing updates per Section 2.7.5 to reject
advertisements of unassigned addresses).
See [RFC3704].
Warnings.
This requirement only holds for single-homed networks. Note that
a simple forwarding table check is not sufficient in the more
complex scenarios of multi-homed or multi-attached networks, i.e.,
where the traffic may be asymmetric. In these cases, a more
extensive check such as Feasible Path RPF could be very useful.
2.5.7. Support Counters For Dropped Packets
Requirement.
The device MUST provide accurate, per-interface counts of spoofed
packets dropped in accordance with Section 2.5.5 and Section
2.5.6.
Justification.
Counters can help in identifying the source of spoofed traffic.
Examples.
An edge router may have several single-homed customers attached.
When an attack using spoofed packets is detected, a quick check of
counters may be able to identify which customer is attempting to
send spoofed traffic.
Warnings.
None.
2.6. Rate Limiting Requirements
2.6.1. Support Rate Limiting
Requirement. The device MUST provide the capability to limit the rate at which it will pass traffic based on protocol, source and destination IP address or CIDR block, source and destination port, and interface. Protocols MUST include at least IP, ICMP, UDP, and TCP and SHOULD include any protocol. Justification. This requirement provides a means of reducing or eliminating the impact of certain types of attacks. Also, rate limiting has the advantage that in some cases it can be turned on a priori, thereby offering some ability to mitigate the effect of future attacks prior to any explicit operator reaction to the attacks. Examples. Assume that a web hosting company provides space in its data- center to a company that becomes unpopular with a certain element of network users, who then decide to flood the web server with inbound ICMP traffic. It would be useful in such a situation to be able to rate-filter inbound ICMP traffic at the data-center's border routers. On the other side, assume that a new worm is released that infects vulnerable database servers such that they then start spewing traffic on TCP port 1433 aimed at random destination addresses as fast as the system and network interface of the infected server is capable. Further assume that a data 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
circular memory buffer or log file rotation), or logging stops.
2.11.5. Ability to Maintain Accurate System Time
Requirement.
The device MUST maintain accurate, "high resolution" (see
definition in Section 1.8) system time.
Justification.
Accurate time is important to the generation of reliable log data.
Accurate time is also important to the correct operation of some
authentication mechanisms.
Examples.
This requirement may be satisfied by supporting Network Time
Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct
connection to an accurate time source.
Warnings.
System clock chips are inaccurate to varying degrees. System time
should not be relied upon unless it is regularly checked and
synchronized with a known, accurate external time source (such as
an NTP stratum-1 server). Also note that if network time
synchronization is used, an attacker may be able to manipulate the
clock unless cryptographic authentication is used.
2.11.6. Display Timezone And UTC Offset
Requirement.
All displays and logs of system time MUST include a timezone or
offset from UTC.
Justification.
Knowing the timezone or UTC offset makes correlation of data and
coordination with data in other timezones possible.
Examples.
Bob is in Newfoundland, Canada which is UTC -3:30. Alice is
somewhere in Indiana, USA. Some parts of Indiana switch to
daylight savings time while others do not. A user on Bob's
network attacks a user on Alice's network. Both are using logs
with local timezones and no indication of UTC offset. Correlating
these logs will be difficult and error prone. Including timezone,
or better, UTC offset, eliminates these difficulties.
Warnings.
None.
2.11.7. Default Timezone Should Be UTC
Requirement. The default timezone for display and logging SHOULD be UTC. The device MAY support a mechanism to allow the operator to specify the display and logging of times in a timezone other than UTC. Justification. Knowing the timezone or UTC offset makes correlation of data and coordination with data in other timezones possible. Examples. Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or UTC -6 depending on the time of year and exact county in Indiana) are working an incident together using their logs. Both left the default settings, which was UTC, so there was no translation of time necessary to correlate the logs. Warnings. None.2.11.8. Logs Must Be Timestamped
Requirement. By default, the device MUST timestamp all log messages. The timestamp MUST be accurate to within a second or less. The timestamp MUST include a timezone. There MAY be a mechanism to disable the generation of timestamps. Justification. Accurate timestamps are necessary for correlating events, particularly across multiple devices or with other organizations. This applies when it is necessary to analyze logs. Examples. This requirement MAY be satisfied by writing timestamps into syslog messages.
Warnings.
It is difficult to correlate logs from different time zones.
Security events on the Internet often involve machines and logs
from a variety of physical locations. For that reason, UTC is
preferred, all other things being equal.
2.11.9. Logs Contain Untranslated IP Addresses
Requirement.
Log messages MUST NOT list translated addresses (DNS names)
associated with the address without listing the untranslated IP
address where the IP address is available to the device generating
the log message.
Justification.
Including IP address of access list violations authentication
attempts, address lease assignments and similar events in logs
enables a level of individual and organizational accountability
and is necessary to enable analysis of network events, incidents,
policy violations, etc.
DNS entries tend to change more quickly than IP block assignments.
This makes the address more reliable for data forensics.
DNS lookups can be slow and consume resources.
Examples.
A failed network login should generate a record with the source
address of the login attempt.
Warnings.
* Source addresses may be spoofed. Network-based attacks often
use spoofed source addresses. Source addresses should not be
completely trusted unless verified by other means.
* Addresses may be reassigned to different individual, for
example, in a desktop environment using DHCP. In such cases
the individual accountability afforded by this requirement is
weak. Having accurate time in the logs increases the chances
that the use of an address can be correlated to an individual.
* Network topologies may change. Even in the absence of dynamic
address assignment, network topologies and address block
assignments do change. Logs of an attack one month ago may not
give an accurate indication of which host, network or
organization owned the system(s) in question at the time.
2.11.10. Logs Contain Records Of Security Events
Requirement.
The device MUST be able to send a record of at least the following
events:
* authentication successes,
* authentication failures,
* session Termination,
* authorization changes,
* configuration changes,
* device status changes.
The device SHOULD be able to send a record of all other security
related events.
Justification.
This is important because it supports individual accountability.
See section 4.5.4.4 of [RFC2196].
Examples.
Examples of events for which there must be a record include: user
logins, bad login attempts, logouts, user privilege level changes,
individual configuration commands issued by users and system
startup/shutdown events.
Warnings.
This list is far from complete.
Note that there may be privacy or legal considerations when
logging/monitoring user activity.
2.11.11. Logs Do Not Contain Passwords
Requirement. Passwords SHOULD be excluded from all audit records, including records of successful or failed authentication attempts. Justification. Access control and authorization requirements differ for accounting records (logs) and authorization databases (passwords). Logging passwords may grant unauthorized access to individuals with access to the logs. Logging failed passwords may give hints about actual passwords. See section 4.5.4.4 of [RFC2196]. Examples. A user may make small mistakes in entering a password such as using incorrect capitalization ("my password" vs. "My Password"). Warnings. There may be situations where it is appropriate/required to log passwords.
(page 55 continued on part 3)
