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. 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.
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. 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. 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.
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.
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. 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.
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.
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. 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. 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. 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.
Warnings. None. RFC2827] provides one example of the use of this capability. Warnings. None.
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. 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.
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.
* 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.
RFC2827]. Warnings. None.
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.
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.
"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.
Warnings. None. 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].
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. RFC3195]. Syslog-ng provides another example, although the protocol has not been standardized.
Warnings. None. 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.
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.
* 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. section 184.108.40.206 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.
section 220.127.116.11 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.