tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3871

 
 
 

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

Part 2 of 3, p. 22 to 55
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 22 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part