Introduction to access security testing

Access security testing in Netrounds is intended for testing of end-user security in access networks according to the Secure End-user Connection Access Certification (SEC) and Source Address Validation Improvement (SAVI) Threat Scope (RFC 6959).

These tests are primarily designed for networks with shared broadcast domains, but all issues should be tested independently of what type of network design or topology is used (for example, one VLAN per customer). Our experience shows that the potential for configuration errors exists in any network and can give rise to security issues. Most of the access security issues tested in Netrounds cannot be mitigated by end-users; it is the broadband network that must provide protection.

The Netrounds access security tests (SEC specification) focus mainly on:

  • Man-in-the-middle (MITM) attacks: The ability to eavesdrop and possibly change traffic without the customer being aware of it.
  • Denial-of-service (DoS) attacks: The ability for one customer to affect the services of one or several other customers.
  • Abuse – Tracking of end-users (IP addresses): The ability to identify a customer if there has been some incorrect usage of the services.

Netrounds supports access security testing on the IPv4 protocol. 

To perform access security tests, at least three Netrounds Test Agents are needed. Two interfaces must be used on each Test Agent: one agent interface is used for testing, and the other ("eth0") is used to maintain the encrypted management connection to the Netrounds cloud servers.

Test Agents play one of three roles in access security tests:

  • Malicious Customer ("Malicious" for short): A customer attempting to perform an attack. Each Test Agent playing this role is connected as a standard customer to an access port.
  • Customer: A friendly customer who is affected by the attacks performed by Malicious Customer.
  • ISP: Internet Service Provider, placed in a trusted zone. Only one Test Agent plays this role.

The picture below shows an example of a test configuration.

It is most convenient to place the ISP Test Agent in the same Layer 2 network as customers, as this is required for some of the tests (though not for all of them; the requirement is noted for each test type to which it applies). This setup makes it possible to run all access security tests using the same network configuration.

It is also possible to place the ISP Test Agent in the Layer 3 network, as depicted below.

The description of each test has a reference to the corresponding identification in SEC and SAVI.

A few of the tests require a DHCP server and a multicast sender, neither of which is normally provided by the ISP Test Agent.

  • The DHCP server requirement can be met by setting up the ISP Test Agent as a DHCP server, or by using an external DHCP server connected to the network.
  • A multicast sender can either distribute real multicast traffic, or it can consist of a lab setup. A multicast source must be available in the network for tests involving multicast/IGMP.

See this page for an overview of all supported access security features.

Have more questions? Submit a request

Comments

Powered by Zendesk