Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3871

Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure

Pages: 81
Informational
Updated by:  8996
Part 2 of 3 – Pages 22 to 55
First   Prev   Next

Top   ToC   RFC3871 - Page 22   prevText

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.
Top   ToC   RFC3871 - Page 23
   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.
Top   ToC   RFC3871 - Page 24

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.
Top   ToC   RFC3871 - Page 25

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
Top   ToC   RFC3871 - Page 26
      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.
Top   ToC   RFC3871 - Page 27
   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.
Top   ToC   RFC3871 - Page 28
   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.
Top   ToC   RFC3871 - Page 29
   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 ?")
Top   ToC   RFC3871 - Page 30
   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
Top   ToC   RFC3871 - Page 31
      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.
Top   ToC   RFC3871 - Page 32
   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.
Top   ToC   RFC3871 - Page 33
   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].
Top   ToC   RFC3871 - Page 34
   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.
Top   ToC   RFC3871 - Page 35

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.
Top   ToC   RFC3871 - Page 36

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.
Top   ToC   RFC3871 - Page 37

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.
Top   ToC   RFC3871 - Page 38
   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.
Top   ToC   RFC3871 - Page 39
   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.
Top   ToC   RFC3871 - Page 40

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),
Top   ToC   RFC3871 - Page 41
      *  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.
Top   ToC   RFC3871 - Page 42

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
Top   ToC   RFC3871 - Page 43
      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.
Top   ToC   RFC3871 - Page 44
   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.
Top   ToC   RFC3871 - Page 45

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
Top   ToC   RFC3871 - Page 46
      "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.
Top   ToC   RFC3871 - Page 47

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.
Top   ToC   RFC3871 - Page 48
   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].
Top   ToC   RFC3871 - Page 49

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.
Top   ToC   RFC3871 - Page 50
   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.
Top   ToC   RFC3871 - Page 51
   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.
Top   ToC   RFC3871 - Page 52

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.
Top   ToC   RFC3871 - Page 53
   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.
Top   ToC   RFC3871 - Page 54
      *  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.
Top   ToC   RFC3871 - Page 55

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)

Next Section