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