Technical Documentation

infra_file.yml

The infra_file.yml defines the infrastructure of the test environment used for the automated evaluation of NFT scripts. It contains information about networks and machines used in the setup.

File Structure

The file consists of two main sections:

• Networks: Defines all available networks.
• Machines: Defines virtual machines (VMs) and their parameters.

Networks

This section describes the available networks, including both IPv4 and IPv6 configurations.

Fields:

• Netaddress: The base address of the network (IPv4 or IPv6).
• Netmask: The subnet mask in CIDR format (e.g., 24 for a /24 network).

Example:

Networks:
  HQLAN:
    Netmask: 24
    Netaddress: 172.16.0.0
  HQDMZv6:
    Netmask: 64
    Netaddress: "2001:db8:1::"

Machines

This section defines all machines involved in the test environment. Each machine entry contains IP addresses and login credentials.

Fields:

• IP: A list of one or more IP addresses.
• Management: IP address with which the tool can ssh to the machine.
• User: Username for access.
• Password: Password for access.
• NFTable (optional): Name of the NFT configuration file, that is to be installed on the machine.

Example:

Machines:
  hqfw:
    IP:
      - 172.16.1.1
      - 172.16.0.1
      - 192.0.2.1
    Management: 192.168.56.101
    User: your_vm_user
    Password: your_vm_pswd
    NFTable: name_of_your_nft_script

  hqfwv6:
    IP:
      - "2001:db8:1::1"
      - "2001:db8::1"
      - "2001:db8:ffff::1"
    Management: 192.168.56.101
    User: your_vm_user
    Password: your_vm_pswd
    NFTable: path/to/nft/configuration/file

Formatting Notes

• The file must be valid YAML (use spaces for indentation, no tabs).
• IPv4 and IPv6 addresses in the IP field must not be mixed. Define separate machines for IPv6.
• IPv6 addresses must be enclosed in quotation marks ("").
• At least one NFTable file must be defined.

tests.yml

The tests.yml file defines all tests to be executed for the automated evaluation of NFT scripts. Each entry describes a network connection that should be tested and specifies the protocol used for the test.

Structure of Entries

Each test entry is a YAML object with the following fields:

Fields:

• Name: Unique name of the test (e.g., Aufgabe_1.1).
• Source: Name of the source machine (e.g., hqclient).
• Destination: Target network or machine (e.g., INET or hqsrv, 192.168.0.1, 192.168.0.0/24).
• Proto: The test which is to be used (tcp, udp, icmp, ...).
• D_port: List of destination ports.
• S_port: List of source ports to use for the connection (for more specific tests).
• Points: Number of points this testcase is worth in the evaluation.
• Allow: Boolean indicating whether the connection should be allowed (true) or blocked (false).
• Secial: List of non default values, which may be required by some tests

D_port, S_port,Points,Allow and Special can be optional fields, depending on the data needed for a test.

Example:

- Name: Task_1.1
  Source: hqclient
  Destination: INET
  Proto: tcp
  D_port: 
   - 80
   - 443
  Points: 2

For ICMP tests, D_port is usually omitted or set to null:

- Name: Task_4.1
  Source: hqclient
  Destination: hqfw
  Proto: icmp

Formatting Guidelines

• The file consists of a list of test definitions in YAML format.
• Each test must include the fields listed above.
• IPv4 and IPv6 versions of a test are defined as separate tasks (e.g., Task_1.1 and Task_1.2).

template_mapping.yml

The template_mapping.yml file defines how protocol-specific test definitions should be mapped to the placeholders in test templates. It provides a flexible way to link input data (from tests.yml) to template variables.

Structure

The file is organized by protocol (e.g., tcp, udp, icmp). Each protocol key maps to a dictionary that specifies how to associate test fields with template variables.

Protocol Mapping

Example:

tcp:
  destination: destination
  dport: d_port
udp:
  destination: destination
  dport: d_port
icmp:
  destination: destination

In this example:

• For the tcp protocol:
  • The destination field in the test is mapped to the destination variable in the template.
  • The D_port field is mapped to d_port.
  • This also counts for udp.
• For icmp, only the destination is relevant and mapped accordingly.

Available fields for mapping

• destination: destination ips as a list
• d_port: destination ports as a list
• s_port: source port as a int
• special: contains any other values you might need for your test copied 1:1 from tests.yml

Notes

• All protocol names must be lowercase.
• The keys in each protocol mapping must correspond to fields in the test definitions (e.g., from tests.yml).
• The values must match placeholder names used in the associated templates.