Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.117  Word version:  17.2.0

Top   Top   Up   Prev   Next
1…   4.2…   4.2.3…   4.2.3.4…   4.2.3.5…   4.2.4…   4.3…   4.3.4…   4.4… 
4.3 Security requirements and related test cases related to hardening  4.3.1 Introduction  4.3.2 Technical Baseline  4.3.3 Operating Systems  4.3.3.1.1 IP-Source address spoofing mitigation  4.3.3.1.2 Minimized kernel network functions  4.3.3.1.3 No automatic launch of removable media  4.3.3.1.4 SYN Flood Prevention  4.3.3.1.5 Protection from buffer overflows  4.3.3.1.6 External file system mount restrictions 
...

 

4.3  Security requirements and related test cases related to hardening  p. 64

4.3.1  Introduction  p. 64

The requirements proposed hereafter (with the relative test cases) aim to securing network products (including the network functions in service-based architecture) by reducing its surface of vulnerability. In particular the identified requirements aim to ensure that all the default network product configurations (including operating system software, firmware and applications) are appropriately set.

4.3.2  Technical Baseline  p. 64

4.3.2.1  No unnecessary or insecure services / protocols  p. 64

Requirement Name:
No unnecessary or insecure services / protocols
Requirement Description:
The network product shall only run protocol handlers and services which are needed for its operation, and which do not have any known security vulnerabilities. In particular, by default the following services shall be initially configured to be disabled on the network product by the vendor except if services are needed during deployment. In that case those services shall be disabled according to vendor's instructions after deployment is done. Disabled protocols may still need to be enabled for other reasons by the operators, e.g. remote diagnostics.
  • FTP
  • TFTP
  • Telnet
  • rlogin, RCP, RSH
  • HTTP
  • SNMPv1 and v2
  • SSHv1
  • TCP/UDP Small Servers (Echo, Chargen, Discard and Daytime)
  • Finger
  • BOOTP server
  • Discovery protocols (CDP, LLDP)
  • IP Identification Service (Identd)
  • PAD
  • MOP
Test Case:
TBA
Test Name:
TC_NO_UNNECESSARY_SERVICE
Purpose:
To ensure that on all network interfaces, there are no unsecure services or protocols that might be running.
Procedure and execution steps:
Pre-Conditions:
A list of all required network protocols and services containing at least the following information shall be included in the documentation accompanying the Network Product:
  • protocol handlers and services needed for the operation of network product;
  • their open ports and associated services;
  • and a description of their purposes.
The tool used shall be capable to detect and identify the protocol handlers and running services in the system.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. Verification of the compliance to the prerequisites:
    1. Verification that the list of available network services and protocol handlers is available in the documentation of the Network Product.
    2. Validation that all entries in the list are meaningful and reasonably necessary for the operation of the Network Product class.
  2. Identification of the network services and protocol handlers by means of capable tools or any other suitable testing means.
  3. Validation that there are no entries in the list of network services and handlers apart from the ones that have been mentioned and deemed necessary for the operation of the Network Product in the attached documentation.
  4. The tester shall reboot the network product and re-execute execution steps 2 and 3 without further configuration.
Expected Results:
The report will contain:
  • The names and version of the tool(s) used.
  • Information of all the protocol handlers and services running in the network product.
    Result will show:
  • There are no unnecessary services running in the network product except for the ones which are deemed necessary for its operation.
  • Any undocumented services running on the network product should be highlighted and brought out in the report.
  • The network product behaves the same after reboot as before.
Expected format of evidence:
A report provided by the testing agency which will consist of the following information:
  • The used tool(s) name and version information
  • Settings and configurations used
  • The output pertaining to the test case performed and
  • The test results i.e. services existing or not existing in the MME
Up

4.3.2.2  Restricted reachability of services  p. 66

Requirement Name:
The network product shall restrict the reachability of services
Requirement Description:
The network product shall restrict the reachability of services so that they can only be reached on interfaces where their usage is required. On interfaces were services are active, the reachability should be limited to legitimate communication peers. This limitation shall be realized on the network product itself (without measures (e.g. firewall) at network side) according to the requirement detailed in clause 4.2.6.2.1 Packet Filtering.
EXAMPLE:
Administrative services (e.g. SSH, HTTPS, RDP) shall be restricted to interfaces in the management network to support separation of management traffic from user traffic.
Test Case:
Test Name:
TC_RESTRICTED_REACHIBILITY_OF_SERVICES
Purpose:
To verify that it is possible to bind the services only to the interfaces from which they are expected to be reachable.
Procedure and execution steps:
Pre-Conditions:
  • The vendor shall declare, in the documentation accompanying the network product if the network product supports the capability to restrict services reachability to only the nodes authorized to access them. In this case, the vendor shall detail how this capability can be configured.
  • A list of all required network protocols and services containing at least the following information shall be included in the documentation accompanying the Network Product:
  • protocol handlers and services needed for the operation of network product;
  • their open ports and associated services;
  • the configuration options;
  • and a description of their purposes.
  • The network product is configured such that the required network protocols and services (as described in the network product documentation) are setup and each service is bound to an IP address of a specific network interface (e.g. IP1 which is the ip address of if1). Configuration may occur automatically during the initialization phase of the network product or manually as defined in the network product administration documentation.
  • The network product shall have at least two interfaces enabled, if1 and if2 respectively configured with IP Address IP1 and IP2.
  • The tester has administrative privileges.
  • A tester machine equipped with a network port scanner tool is available.
Execution Steps:
  1. The tester runs a network port scanner (e.g. nmap) towards if1 and verifies that the configured services are open/reachable.
  2. The tester runs a network port scanner (e.g. nmap) towards if2 and verifies that the configured services are not open/reachable.
Expected Results:
Services can be enabled on per-interface basis.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
  • The network product configuration
  • Pcap files
  • Screenshot
  • Network port scanner results (e.g. files containing this results)
  • Test result (Passed or not)
Up

4.3.2.3  No unused software  p. 68

Requirement Name:
Unused software shall not be installed or shall be uninstalled
Requirement Description:
Unused software components or parts of software which are not needed for operation or functionality of the network product shall not be installed or shall be deleted after installation. This includes also parts of a software, which will be installed as examples but typically not be used (e.g. default web pages, example databases, test data).
Test Case:
Test Name:
TC_NO_UNUSED_SOFTWARE
Purpose:
To ensure that there is no unused software or associated components that might be installed in the network product which are not required for its operation or functionality.
Procedure and execution steps:
Pre-Conditions:
A list of all available software and libraries and associated components containing at least the following information shall be included in the documentation accompanying the Network Product:
  • name of the software / library;
  • version of the software / library installed;
  • list of dependencies and versions;
  • any add-ons and functions;
  • any special hardware/debugging ports;
  • software support type;
  • licensing information;
  • brief description of their purpose.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. Verification of the compliance to the prerequisites:
    1. Verification that the list of software / libraries and components is available in the documentation of the Network Product.
    2. Validation that all entries in the list of software / libraries and components are meaningful and reasonably necessary for the operation of the Network Product class.
  2. Identification of the software / libraries or components which are installed in the system using any suitable command line tools or any other suitable means of determination.
  3. Validation that there are no entries in the list of software / libraries installed in the system apart from the ones that have been mentioned and deemed necessary for the operation of the network product in the attached documentation.
  4. Based on his/her experience, the tester will check for known default example files for software installed on the system.
Expected Results:
The report will contain the names and version of the tool(s) used for finding out what software /libraries is installed in the system. The detailed report will contain the name and version information of all the software / libraries installed in the system generated by the tool.
The list of all available software / libraries which has been deemed necessary for the operation of the network product by the vendor shall also be included as the test result. Any software / library not in the list of allowed software / libraries will be highlighted and brought out as a part of the report.
There should be no unnecessary software / library installed in the network product except for the ones which are deemed necessary for its operation.
There should be no more default example files for the installed software on the system.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
  • The used tool(s) name and version information,
  • Settings and configurations used
  • the output pertaining to the test case performed and,
  • the test results i.e. list of allowed and disallowed software
Up

4.3.2.4  No unused functions  p. 69

Requirement Name:
Unused functions of the network products' software and hardware shall be deactivated.
Requirement Description:
During installation of software and hardware often functions will be activated that are not required for operation or function of the system. If unused functions of software cannot be deleted or deinstalled individually as required in clause "5.3.2.3 No unused software" of the present document, such functions shall be deactivated in the configuration of the network product permanently.
Also hardware functions which are not required for operation or function of the system (e.g. unused interfaces) shall be permanently deactivated. Permanently means that they shall not be reactivated again after network product reboot.
EXAMPLE:
A debugging function in software which can be used for troubleshooting shall not be activated during normal operation of the network product.
Test Case:
Test Name:
TC_NO_UNUSED_FUNCTIONS
Purpose:
To ensure that there is no unused hardware or software functions that are not deactivated in the network product which are not required for its operation or functionality.
Procedure and execution steps:
Pre-Conditions:
A list of all available software and associated components containing at least the following information shall be included in the documentation accompanying the Network Product:
  • name of the software;
  • version of the software installed;
  • list of dependencies and versions;
  • any add-ons and functions;
  • any special hardware/debugging ports;
  • software support type;
  • licensing information;
  • requirement during functioning of system;
  • brief description of their purpose.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. Identification of the hardware and software functions which are installed in the system or might have been disabled using any suitable command line tools or any other suitable means of determination.
  2. Validate that there are no entries in the list of hardware and software functions installed in the system apart from the ones that have been mentioned and deemed necessary for the operation of the network product in the attached documentation.
Expected Results:
The report will contain the names and version of the tool(s) used for finding out what software and associated function is installed in the system. The detailed report will contain the name and version information of all the software and components installed in the system generated by the test tool.
The list of all available software which has been deemed necessary for the operation of the network product by the vendor shall also be included as the test result. Any software not in the list of allowed software will be highlighted and brought out as a part of the report.
There should be no unused function that is not deactivated in the network product except for the ones which are deemed necessary for its operation.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
  • The used tool(s) name and version information
  • Settings and configurations used
  • The list of software and associated functions
  • the test results i.e. allowed list of functions
Up

4.3.2.5  No unsupported components  p. 70

Requirement Name:
The network product shall not contain software and hardware components that are no longer supported by their vendor, producer or developer.
Requirement Description:
The network product shall not contain software and hardware components that are no longer supported by their vendor, producer or developer, such as components that have reached end-of-life or end-of-support. Excluded are components that have a special support contract. This contract shall guarantee the correction of vulnerabilities over components' lifetime.
Test Case:
Test Name:
TC_NO_UNSUPPORTED_COMPONENTS
Purpose:
To ensure that there is no unsupported software that is running in the network product which is not supported anymore and has reached its end-of-life or end-of-support.
Procedure and execution steps:
Pre-Conditions:
A list of all available software and associated components containing at least the following information shall be included in the documentation accompanying the Network Product:
  • name of the software;
  • version of the software installed;
  • list of dependencies and versions;
  • any add-ons and functions;
  • any special hardware/debugging ports;
  • software support type;
  • licensing information;
  • requirement during functioning of system;
  • brief description of their purpose.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. Identification of the hardware and software components, version information and the kind of support available for the software provided by the vendor, the producer, the developer or other contractual partner of the operator using any tool or any other suitable means of determination.
  2. Validate that there are no entries in the list of hardware and software installed in the system which are not supported as given by the vendor of network product in the attached documentation.
Expected Results:
The report will contain the names and versions of the tool(s) used for finding out what software and hardware components are installed in the system. The detailed report will contain the name and version of the software and hardware used in the system, and the period of support for each of these components.
The list of all available software and hardware components and their associated support information which has been deemed necessary for the operation of the network product by the vendor shall also be included as the test result. Any software or component which is not supported any longer by the vendor will be highlighted and brought out as a part of the report.
There should be no software installed in the network product which is unsupported as of the day of testing.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
  • The used tool(s) name and version information
  • Software and hardware components used in the network product
  • the test results i.e. support information of each listing
Up

4.3.2.6  Remote login restrictions for privileged users  p. 72

Requirement Name:
Remote login restrictions for privileged users
Requirement Description:
Direct login as root or equivalent highest privileged user shall be limited to the system console only. Root user will not be allowed to login to the system remotely.
Test Case:
Test Name:
TC_REMOTE_LOGIN_RESTRICTIONS_PRIVILEGED_USERS
Purpose:
Verify that root or equivalent highest privileged user will not be allowed to login to the system remotely.
Procedure and execution steps:
Pre-Condition:
A document that describes the interfaces to the network product and how the tester can login to them remotely.
Execution Steps:
Execute the following steps:
  1. The tester tries to remotely login to the network product using the credentials of the root or equivalent highest privileged user via the interfaces as described in the documentation.
  2. The tester tries to login to the network product using the credentials of the root or equivalent highest privileged user from the physical console of the system.
Expected Results:
The tester is not able to login to the system remotely using the root credentials.
The tester is able to login to the system from the physical console using the root credentials.
Expected format of evidence:
A Pass/Fail result.
Up

4.3.2.7  Filesystem Authorization privileges  p. 72

Requirement Name:
Filesystem Authorization privileges.
Requirement Description:
The system shall be designed to ensure that only users that are authorized to modify files, data, directories or file systems have the necessary privileges to do so.
EXAMPLE:
On unix® systems a 'sticky' bit may be set on all directories where all users have write permissions. This ensures that only the file's owner, the directory's owner, or root user can rename or delete the file. Without the sticky bit being set, any user that has write and execute permissions for the directory can rename or delete files within the directory, regardless of the file's owner.
Test Case:
Test Name:
TC_FILESYSTEM_AUTHORIZATION_PRIVILEGES
Purpose:
Verify that only users that are authorized to modify files, data, directories or file systems have the necessary privileges to do so.
Procedure and execution steps:
Pre-Condition:
A document describing how access control is configured for the filesystems in the network product shall be provided by the vendor.
Execution Steps:
Execute the following steps:
  1. The tester checks that OS-level permissions are configured correctly for users that are authorized to modify files, data, directories or file systems on the system.
  2. The tester tries to modify the files and directories for which the user has the necessary privileges.
  3. The tester tries to modify the files and directories for which the user doesn't have the necessary privileges.
Expected Results:
The OS-level access permissions are set correctly for the users.
The users can only modify files, data, directories or file systems for which he has the necessary privileges to do so.
Expected format of evidence:
Screenshot containing the configuration file showing the OS-level permissions are set correctly.
Up

4.3.3  Operating Systems  p. 73

4.3.3.1  General operating system requirements and test cases  p. 73

4.3.3.1.1  IP-Source address spoofing mitigation  p. 73
Requirement Name:
IP-Source address spoofing mitigation
Requirement Description:
Systems shall not process IP packets if their source address is not reachable via the incoming interface. Implementation example: Use of "Reverse Path Filter" (RPF) provides this function.
Test Case:
The test for this requirement can be carried out using a suitable tool or manually by performing the steps described below. If a tool is used then the tester needs to provide evidence, e.g. by referring to the documentation of the tool, that the tool actually provides functionality equivalent to the steps described below.
Test Name:
TC_IP_SPOOFING_MITIGATION
Purpose:
To verify that the network product provides anti-spoofing function that is, before a packet is processed, the network product checks whether the source IP of the received packet is reachable through the interface it comes in.
To verify that if the received packet source address is not routable through the interface on which it comes, then the network product drops this packet.
Procedure and execution steps:
Pre-Conditions:
  • A node N1 is available with:
    • Two interfaces named respectively if1-n1 connected to the network product and if2-n1 to which the tester connects a tester machine
    • routing capabilities
    • if2-n1 has a static IP address (e.g. 192.168.3.1 belonging to the subnet 192.168.3.0/24)
  • A node N2 is available with:
    • Two interfaces named respectively if1-n2 connected to the network product and if2-n2 to which the tester connects a tester machine
    • Routing capabilities. In particular N2 has a default route to if1-np subnet via if2-np (e.g. 192.168.2.1)
    • if2-n2 has a static IP address . This ip is the same as if2-n1 (e.g. 192.168.3.1 belonging to the subnet 192.168.3.0/24)
  • The network product has at least 2 enabled interfaces said if1-np and if2-np:
    • The interface if1-np is connected to interface if1-n1 of the node N1 on the subnet, e.g., 192.168.1.0/24.
    • The interface if2-np is connected to interface if1-n2 of the node N2 on the subnet, e.g., 192.168.2.0/24.
    • The network product is configured with a static route for the subnet where if2-n1 is connected to (e.g. 192.168.3.0/24), so this subnet can be reached via if1-n1 through if1-np.
Copy of original 3GPP image for 3GPP TS 33.117, Fig. 1: Configurations for the network product, N1 and N2
Figure 1: Configurations for the network product, N1 and N2
(⇒ copy of original 3GPP image)
Up
  • The vendor shall declare, in the documentation accompanying the network product, the supported anti-spoofing mechanism (e.g. RPF or similar function) and if it is enabled for all interfaces (e.g. net.ipv4.conf.all.rp_filter = 1 and net.ipv4.conf.default.rp_filter = 1 in the linux sysctl.conf file) or per interface bases.
  • The vendor shall declare if the dropped packets can be logged and how to enable this logging
  • The tester has administrator privileges
  • A tester machine is available and configured with:
    • A static IP address belonging to the subnet where if2-n1 and if2-n2 are connected to (e.g. 192.168.3.2/24)
    • A default gateway set to if2-n1 and if2-n2 IP Address (e.g. 192.168.3.1)
    • A network traffic analyser (e.g. tcpdump) on the network product is available
Execution Steps
  1. The tester starts to send ping messages to if1-np interface of the network product.
  2. The tester verifies, through the network traffic analyser, that the ping reaches correctly the if1-np interface and that responses are sent back.
  3. The tester disconnects the tester machine from if2-n1 interface of the node N1 and reconnects it to the interface if2-n2 of the node N2:
    • The testers uses the same network configuration of the tester machine.
    • The tester sends ping messages to if1-np interface of the network product.
    • The tester verifies, through the network traffic analyser, that the pings reach the if1-np interface of the network product, but they are dropped and no response is sent back since the source of the received packet is not reachable through the interface it came in.
    • The tester sends ping messages to if2-np interface of the network product.
    • The tester verifies, through the network traffic analyser, that the pings reach the if2-np interface of the network product, but they are dropped and no response is sent back since there is a default route via if2-np.
    • If the dropped packets are logged, the testers verifies that these packets are recorded.
Expected Results:
The network product supports an anti-spoofing mechanism (e.g. the RPF function) and it accepts a packet only if it reaches the network product on the expected interface (i.e. this packet has a source ip address belonging to the same network as the interface where it came in or if it is routable through the interface on which it came in), otherwise it discards the packet.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
  • The user settings and configurations
  • Pcap files
  • Log file if available
  • Test result (Passed or not)
Up
4.3.3.1.2  Minimized kernel network functions  p. 75
Requirement Name:
Minimized kernel network functions.
Requirement Description:
Kernel based network functions not needed for the operation of the network element shall be deactivated.
In particular the following ones shall be disabled by default:
  • Proxy ARP (to prevent resource exhaustion attack and man-in-the-middle attacks.
  • Directed broadcast (to prevent Smurf, Denial of Service attack and others like it.
  • IPv4 Multicast handling. In particular all packets with IP source or destination address belonging to the multicast IP ranges (224.0.0.0 through 239.255.255.255) shall be discarded by default and multicast route caching and forwarding shall be disabled to prevent smurf and fraggle attacks. A configuration option shall be available to enable the IPv4 multicast handling if required.
  • Gratuitous ARP messages (to prevent ARP Cache Poisoning attacks [ef]). A Gratuitous ARP request can be used mainly to inform the neighbours about the change in the MAC for the specified IP and consequently to update their ARP tables or to update the switches with the new MAC address or to defend link-local IP addresses in the Zeroconf protocol. By default, the network product shall not send Unsolicited ARP and any incoming Gratuitous ARP requests shall be discarded.
Answering routine for broadcast ICMP packets. In particular all ICMP ECHO and TIMESTAMP requests sent to network product via broadcast/multicast shall not be answered by default.
Test Case:
Test Name:
TC_PROXY_ARP_DISABLING
Purpose:
Verify that the Proxy ARP feature is disabled by default on the network product. In particular this test case verifies that the network product does not respond to ARP requests intended for another host.
Procedure and execution steps:
Pre-Conditions:
  • The network product shall have at least 2 different physical or logical Ethernet interface IF1 and IF2. E.g.
  • Host 1 is connected to IF1 on subnet A (for example 172.16.10.0/16).
  • Host 2 is connected to IF2 on subnet B (for example 172.16.20.0/24).
  • Network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available.
Execution Steps:
  1. If the feature is available in a configuration file, verify that it is disabled by default.
  2. Broadcast an ARP request from Host 1 on Subnet A to discover the MAC of Host 2 on subnet B. Since the ARP request is a broadcast, it reaches all nodes in the Subnet A, which include the IF1 interface of the network product, but it does not reach Host 2.
  3. Verify that the network product correctly receives this packet but that it does not send an ARP reply to Host 1 with its own MAC address.
Expected Results:
No Arp Reply is received by Host 1.
Expected format of evidence:
Pcap trace, snapshot of ARP Cache of Host 1
Test Name:
TC_DIRECTED_BROAD_DISABLING
Purpose:
Verify that the Directed broadcast is disabled by default on the network product. In particular this test case verifies that a packet received by a network product whose destination address is a valid broadcast address is dropped.
Procedure and execution steps:
Pre-Conditions:
  • The network product has at least 2 different physical or logical Ethernet interface IF1 and IF2.
  • Host 1 is connected to IF1 on Subnet A and Host 2 is connected to IF2 on Subnet B.
  • Network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available.
Execution Steps:
  1. If the feature is available in a configuration file, verify that it is disabled by default.
  2. Send an IP packet from Host 1 whose IP destination address is a valid broadcast address belonging to the subnet B.
  3. Verify that the Host 2 on Subnet B does not receive the packet because it will be dropped by the network product, rather than being broadcasted.
Expected Results:
The packet is not broadcasted by the network product and Host 2 cannot receive it.
Expected format of evidence:
Pcap trace showing that packet from host 1only incomes to the network product.
Test Name:
TC_IP_MULTICAST_HANDLING
Purpose:
Verify that IP Multicast is disabled by default on the network product. In particular this test case verifies that packets with IP source or destination address belonging to the multicast IP ranges (224.0.0.0 through 239.255.255.255) are not handled by the network product.
Procedure and execution steps:
Pre-Conditions:
  • Network traffic analyser on the network product or an external traffic analyser directly connected to the network product is available.
  • Network product
    Capability:
    NOT applicable in certain deployment scenarios where multicast needs to be enabled.
Execution Steps:
  1. If the feature is available in a configuration file, verify that it is disabled by default.
  2. Verify that none of the network product's interfaces is running Multicast (e.g. typing command ip maddr or ifconfig on any Unix® based platform)
Expected Results:
No interface is running multicast protocols
Expected format of evidence:
Screenshot containing command output.
Test Name:
TC_GRATUITOUS_ARP_DISABLING
Purpose:
Verify that the Gratuitous ARP feature is disabled by default on the network product. In particular this test case verifies that the network product cannot send gratuitous ARP requests and that the network product discards incoming Gratuitous ARP requests.
Procedure and execution steps:
Pre-Conditions:
  • Network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available.
  • Host 1 is connected to the network product
  • The network product ARP Cache already contains an entry for Host 1
  • The network product documentation does not state any reason why gratuitous ARP may be deliberately enabled in order to satisfy certain deployment scenarios. If the network product documentation does, however, state that the usage of gratuitous ARP is enabled in certain deployment scenarios, then this test case is not applicable (refer to the NOTE in the requirement).
Execution Steps:
  1. If the feature is available in a configuration file, verify that it is disabled by default.
  2. Send a Gratuitous ARP request from Host 1, i.e. an ARP request where the source and destination IP are both set to an IP address different from the one already cached in the network product ARP Cache for Host 1 and the destination MAC is the broadcast address ff:ff:ff:ff:ff:ff.
  3. Verify that the network product correctly receives this packet but discards it and that the ARP Cache is not updated.
  4. Send a Gratuitous ARP request i.e. an ARP reply where the source and destination IP are both set to an IP address different from the one already cached in the network product ARP Cache for Host 1 and the destination MAC is the broadcast address ff:ff:ff:ff:ff:ff.
  5. Verify that the network product correctly receives this packet but discards it and that the ARP Cache is not updated.
Expected Results:
The network product ARP Cache is not updated.
Expected format of evidence:
Snapshot of the network product ARP Cache
Test Name:
TC_BROADCAST_ICMP_HANDLING
Purpose:
Verify that responses to ICMP broadcast packets are disabled by default on the network product . In particular this test case verifies that all ICMP ECHO and TIMESTAMP requests sent to the network product via broadcast/multicast are not answered.
Procedure and execution steps:
Pre-Conditions:
  • The network product has at least one physical or logical Ethernet interface IF1 connected to a host, Host 1.
  • Network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available.
Execution Steps:
  1. If the feature is available in a configuration file, verify that it is disabled by default. .
  2. Send an ICMP ECHO message from Host 1 to ping a broadcast address (such as 255.255.255.255, or 192.168.1.255 on a 192.168.1.0/24 subnet)
  3. Verify that the network product doesn't respond to the ping.
  4. Send an ICMP timestamp request (ICMP type 13) from host 1 to a broadcast address (such as 255.255.255.255, or 192.168.1.255 on a 192.168.1.0/24 subnet).
  5. Verify that the network product doesn't respond to the timestamp request.
Expected Results:
The network product doesn't respond to any ICMP packet with a broadcast address.
Expected format of evidence:
Pcap trace showing that the ICMP ECHO/ ICMP timestamp packets are received by the network product but no responses are generated by the network product.
Up
4.3.3.1.3  No automatic launch of removable media  p. 80
Requirement Name:
No automatic launch of removable media
Requirement Description:
The network product shall not automatically launch any application when removable media device such as CD-, DVD-, USB-Sticks or USB-Storage drive is connected. If the operating system supports an automatic launch, it shall be deactivated unless it is required to support availability requirements.
Test Case:
Test Name:
TC_NO_AUTO_LAUNCH_OF_REMOVABLE_MEDIA
Purpose:
To verify that the network product does not launch any applications automatically when a removable media device is connected. Any such feature should be deactivated.
Procedure and execution steps:
Pre-Condition
If the network product is provisioned with the necessary physical ports/drives (CD/DVD drive, USB port, etc.) then the test case applies.
Execution Steps:
  1. The tester log in the network product.
  2. The tester inserts a removable media device (CD-, DVD-, USB-Sticks and/or USB-Storage drives) in the network product.
Expected Results:
The network product does not launch any applications to open the contents in the removable media device.
In Linux® machines, the removable media device is not automatically mounted in the filesystem.
Expected format of evidence:
Evidence can be presented in the form of screenshot/screen-capture on how the network product responds when any removable media device is attached to it.
Up
4.3.3.1.4  SYN Flood Prevention  p. 80
Requirement Name:
Syn Flood Prevention
Requirement Description:
The network product shall support a mechanism to prevent Syn Flood attacks (e.g. implement the TCP Syn Cookie technique in the TCP stack by setting net.ipv4.tcp_syncookies = 1 in the linux sysctl.conf file). This feature shall be enabled by default.
Test Case:
Test Name:
TC_SYN_FLOOD_PREVENTION
Purpose:
Verify that the Network Product supports a Syn Flood Prevention technique.
Procedure and execution steps:
Pre-Conditions:
  • The Network Product is listening on a TCP port one of its interfaces.
  • A network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available.
  • A host is connected to the Network Product interface and it is equipped with a tool able to reproduce a Syn Flood attack (e.g. nmap or hping)
Execution Steps:
  1. The tester configures the tool to send a huge amount of TCP Syn packets against the Network Product (e.g. hping3 -i <waiting time between each packet> -S -p <TCP port> -c <Number of packets> <MME IP>)
  2. The Network Product is still up and running normally, its services are still available and reachable, the memory is not exhausted, there is no crash.
Expected Results:
The Network Product does not become inoperative.
Expected format of evidence:
A Pass/Fail result provided by the tester.
Up
4.3.3.1.5  Protection from buffer overflows  p. 81
Requirement Name:
Protection mechanisms against buffer overflows
Requirement Description:
The system shall support mechanisms for buffer overflow protection. Documentation which describes these buffer overflow mechanisms and also how to check that they have been enabled and/or implemented shall be provided.
Test Case:
Test Name:
TC_PROTECTION_FROM_BUFFER_OVERFLOW
Purpose:
To ensure that the system supports mechanisms that protect against buffer overflow.
Procedure and execution steps:
Pre-Conditions:
  1. A document which provides a detailed technical description of the system's buffer overflow protection mechanisms.
    If a standard buffer overflow mechanism from a 3rd party vendor is used then a reference to the standard feature in the 3rd party vendors documentation should be provided.
  2. Test results from a test execution phase of buffer overflow protection mechanism testing.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. The tester verifies that there is:
    1. A technical description of the buffer overflow protection mechanisms that have been implemented on the system.
    2. Details of whether the buffer overflow protection mechanisms are implemented by default or if additional actions (e.g. scripts or commands manually executed) are required.
      c) If manually executed actions are required then detailed instructions should be included in the technical description.
  2. The tester verifies that the test results:
    1. Describe test procedures used to verify the buffer overflow protection mechanisms,
    2. Contain data which demonstrates/indicates that the buffer overflow protection mechanisms described in the technical description document have been implemented.
    3. Contains details of the test set-up for the testing of the buffer overflow protection mechanisms. Where simulators and/or scripts are used to artificially create the conditions to trigger the buffer overflow protection mechanism then details of these should also be included.
Expected Results:
  1. A technical description of the buffer overflow protection mechanisms that have been implemented on the system.
    • Details of whether the buffer overflow protection mechanisms are implemented by default or if additional actions (e.g. scripts or commands manually executed) are required.
    • If manually executed actions are required then detailed instructions should be included in the technical description.
  2. The test results should:
    • Describe test procedures used to verify the buffer overflow protection mechanisms,
    • Contain data which demonstrates/indicates that the buffer overflow protection mechanisms described in the technical description document have been implemented.
    • Contain details of the test set-up for the testing of the buffer overflow protection mechanisms. Where simulators and/or scripts are used to artificially create the conditions to trigger the buffer overflow protection mechanism then details of these should also be included.
Expected format of evidence:
Documentation showing each of the points in the results sections.
Up
4.3.3.1.6  External file system mount restrictions  p. 83
Requirement Name:
External file system mount restrictions
Requirement Description:
If normal users are allowed to mount external file systems (attached locally or via the network), OS-level restrictions shall be set properly in order to prevent privilege escalation or extended access permissions due to the contents of the mounted file systems.
Implementation example: In Linux® systems, administrators shall set the options nodev and nosuid in the /etc/fstab for all filesystems, which also have the "user" option.
Test Case:
Test Name:
TC_EXTERNAL_FILE_SYSTEM_MOUNT_RESTRICTIONS
Purpose:
Verify that OS-level restrictions are set properly for users that are allowed to mount external file systems (attached locally or via the network). This is to prevent privilege escalation or extended access permissions due to the contents of the mounted file systems.
Procedure and execution steps:
Pre-Condition:
Tester has admin access to check and configure the external filesystem mount permissions in the OS.
Tester has username and password of a user in the network product that has external filesystem mount privileges.
Execution Steps:
Execute the following steps:
  1. The tester shall verify that OS-level restrictions are set properly in order to prevent privilege escalation due to the contents of the mounted file systems (e.g. In Linux® systems, administrators shall set the options nodev and nosuid in the /etc/fstab for all filesystems, which also have the "user" option). The tester checks that OS-level parameters are configured correctly on the system.
  2. The tester mounts an external filesystem prepared by the tester with files exploiting privilege escalation methods (e.g. with writable SUID/GUID files).
  3. The tester tries to gain privileged access to system by using a suitable privilege escalation method using the contents of the mounted file system and then confirms that privilege escalation doesn't happen.
Expected Results:
The OS-level restrictions are set properly in order to prevent privilege escalation or extended access permissions due to the contents of the mounted file systems.
Any privilege escalation method used by the tester should be blocked.
Expected format of evidence:
Screenshot containing the configuration file showing that OS-level restrictions are set properly for users that are allowed to mount external file systems.
Up

Up   Top   ToC