Skip to main content

Security Guidelines

Document History

DateDescription
2024-01-21Added the Use Strong Ciphers.
(1.3.3)
2024-01-17Added WPA3 protocol to Enable Wi-Fi Security chapter.
(1.3.2)
2022-10-11Added recommendation to use the shred tool to Remove stored data when
decommissioning.
(1.3.1)
2021-10-01Added recommendation to Avoid using public IP addresses.
(1.3.0)
Suggested to use Secure Syslog Router App in Monitor system logs.
Added a list of default open ports to the "Open Ports" section.
Recommended RSA keys of at least 2048 bits in Use a proper HTTPS certificate.
Added reference to TLS 1.3 in Use secure HTTPS ciphers.
Added a list of subjects covered to the Introduction.
Changed ep.advantech-bb.cz to icr.advantech.com in all links.
2020-11-04Updated after a review by an external security advisor.
(1.2.0)
Modified section ordering and wording for better clarity and comprehension.
Added references to the Remote Monitoring Application Note and Zabbix Integration.
Emphasized the need for complex passwords through the document and clarified the password complexity policy in Use complex passwords.
Further explained whitelisting and blacklisting in Use restrictive firewall.
Discouraged private key replication in Use encrypted backups.
Added reminder to remove user owned information to Remove stored data.
2020-07-31Added links to Security inquiries and reports on the title page.
(1.1.0)
Introduced security zones and described security strengths of supported cryptographic algorithms in Security Features.
Added a suggestion to monitor DHCP client activities in Monitor System Logs.
Added the Verify Server Authenticity and Monitor Network Traffic recommendations.
Added a list of Related Documents and Document History.
2020-05-06Initial release.
(1.0.0)

Introduction

This document describes guidelines for securing an Advantech cellular router and keeping it secure during installation, configuration, operation, maintenance, and decommissioning. It includes best practices and tool recommendations.

The document, however, does not cover system-level security. It does not describe how to build and maintain secure networks. It focuses solely on securing the router.

Caution

When some router apps are installed, additional hardening may be required.

This document contains three parts:

  1. Description of Security Features provided by the cellular router in its default configuration;
  2. Recommendations for Secure Operation with a focus on monitoring, maintenance, and decommissioning;
  3. Hardening Guide with a focus on installation and configuration.

The following subjects are covered in this document:

Detailed description of features and all individual configuration options of a specific router can be found in the Configuration Manual of your router.

Security Features

Network segmentation

As introduced in the User Manual, Advantech cellular routers are designed to provide:

  • Access to the Internet from LAN;
  • Backed up access to the Internet;
  • Secure network interconnection using a Virtual Private Network (VPN);
  • Connection of a Programmable Logic Controller (PLC) via a Serial Gateway.

In any of these four situations a router interconnects two different security zones:

  1. Wide Area Network (WAN) zone outside our security perimeter, which includes:
    • Cellular (LTE) network(s), typically with the Internet access
    • Backup Ethernet connection to another WAN router
  2. Local Area Network (LAN) zone inside our security perimeter, which includes:
    • Devices connected to the wired or wireless Ethernet (WiFi)
    • Devices (PLC) connected via the serial link (RS232/RS485)
    • Peer LAN connected via the VPN

The essential function of a cellular router is to preserve the confidentiality and integrity of the LAN and its information assets. These functions must be preserved even under a DoS attackā€”when, for example, the availability of the router is degraded.

To meet these needs the Advantech cellular routers provide the following security features:

  • Firewall and NAT filter incoming and outgoing network traffic based on a set of rules. The stateful firewall can:
    • Allow/deny TCP connections and UDP or ICMP packets based on source and/or destination address and port.
    • Protect against common Denial of Service (DoS) attacks.
  • Cryptographic protection of WiFi and VPN communication (either OpenVPN or IPsec) prevents unauthorized nodes from connecting and protects the integrity and confidentiality of the network traffic.

Cryptographic algorithms

NIST SP 800-57 specifies security algorithms with similar strength and recommends the strength equivalent to 112-bit symmetric keys for years 2019ā€“2030 and the strength of 128 bits beyond 2030 (see the table below). The bold values are recommended by ANSSI for 2021ā€“2030 and by BSI for 2020ā€“2022.

| Strength | Symmetric Key Algorithms | Asymmetric Key Algorithms ||| Hash Functions |

Diffie-HellmanRSAElliptic Curves
<=80L=1024
N=160		k=1024f=160-223SHA-1
1123DESL=2048
N=224		k=2048f=224-255SHA-224
SHA-512/224
SHA3-224
128AES-128L=3072,
N=256		k=3072f=256-383SHA-256,
SHA-512/256,
SHA3-256
192AES-192L=7680,
N=384		k=7680f=384-511SHA-384,
SHA3-384
>=256AES-256L=15360,
N=512		k=15360f=512+SHA-512,
SHA3-512
[Strength of cryptographic algorithms per NIST SP 800-57]

| | | Diffie-Hellman (DH) Group || |

StrengthEncryption(Finite-Field) Diffie-HellmanElliptic Curve (ECDH)Hash
<=80Group 2 (1024-bit MODP)
Group 5 (1536-bit MODP)		MD5
SHA1
1123DESGroup 14 (2048-bit MODP)
128AES 128Group 15 (3072-bit MODP)Group 19 (256-bit ECP)SHA 256
152Group 16 (4096-bit MODP)
176Group 17 (6144-bit MODP)
192AES 192Group 20 (384-bit ECP)SHA 384
200Group 18 (8192-bit MODP)
256AES 256Group 21 (521-bit ECP)SHA 512
[Strength of available IPsec algorithms]

The Wi-Fi encryption (WPA2-PSK) uses AES-256. The security strength of various IPsec settings is compared in the table above.

The IPsec configuration is often a tradeoff between the security strength and the throughput since more complex algorithms require more CPU powerā€”hence the data throughput becomes lower. The bold values indicate the default values used when the auto mode is enabled.

Integration with external components

The router can operate as a standalone device. However, the following features require a central monitoring and management system for better security protection:

  • Remote monitoring by a network monitor such as PRTG or Zabbix (refer to the Zabbix Integration Guide Application Note) can detect anomalies through the collection and analysis of:

    • Router status information such as connection status, interface statistics, or voltage and temperature (refer to the SNMP Object Identifiers Application Note);
    • Significant events on the router such as reboots, user logins, or configuration changes (syslog);
    • Inbound and outbound network packet flows (see the NetFlow/IPFIX Router App).

    For more details, see the Remote Monitoring Application Note.

  • Automatic Update ensures the router is running the latest firmware with all available security patches.

Secure Operation

The following sections provide recommendations for secure monitoring, maintenance, and decommissioning of cellular routers manufactured by Advantech Czech.

Each section describes:

  • Risk related to router operation;
  • Recommendation to mitigate the risk. These recommendations assume firmware version 6.2.4 or above.

Use Latest Firmware

Risk

Due to shipping and storage time, even newly delivered routers may contain an older firmware version.

The firmware is built from a large number of software components, and we continuously fix discovered security vulnerabilities. Older firmware versions may be affected by publicly known vulnerabilities, which an attacker could exploit to disrupt router functions or steal sensitive information.

New firmware versions may also include additional configuration options to further enhance router security.

Recommendation

  1. Subscribe for firmware update notifications. You can either subscribe to our RSS channel or, when registered on our Portal, receive email notifications for specific router models.

  2. Upgrade your firmware as soon as possible.
    For a large number of routers, it is recommended to establish an HTTP/FTP server within your infrastructure, store the latest firmware packageā€™s .bin and .ver files in a directory, then enable the automatic update of firmware and set the Base URL to that directory.

  3. After upgrading, download the latest Security Guidelines and verify that the router configuration is properly hardened.

Use Complex Passwords

Risk

The default username is root. The default password is:

  • Unique auto-generated string, which is printed on the router's label.
  • root, if the unique password is not used for your router.

If the password is weak, an attacker may guess it, connect to the router, and perform malicious actions. This risk is even greater if the same password is reused for multiple routers.

Recommendation

  1. Always change the default password, even if it is complex.

  2. If multiple people need access to the router, create separate accounts for each person.

  3. Use passwords that are complex enough, either as a mix of letters, numbers, and special characters, orā€”better yetā€”a sentence composed of multiple words.

    Mike Halsey created a chart here that shows how long it would take a modern computer to crack passwords of varying complexities.

    According to NIST SP 800-63B, passwords shall be at least 8 characters in length, and no additional complexity requirements should be imposed. Research has shown that users tend to follow predictable patterns when subject to strict composition rules.

    The password complexity policy may be configured in /etc/settings.policy:

    POLICY_PWD_LENGTH=8  
POLICY_PWD_UPPERCASES=0  
POLICY_PWD_LOWERCASES=0  
POLICY_PWD_DIGITS=0

  4. Ensure that complex passwords are used for all user accounts and for all services on the device, such as Wi-Fi, SNMP, or RADIUS, including those provided by user modules.

  5. Never use the same or a similar password for other devices or systems.

    If you have too many routers to manage (and therefore too many passwords), consider using WebAccess/DMP or a password manager such as Bitwarden.

  6. Keep the password secret. Do not share it with anyone, and do not store it in close proximity to the device (for example, written on a sticker).

Use Encrypted Backups

Risk

Depending on the checkbox settings, one can:

  • Backup configuration, including the PIN for Mobile WAN, Pre-Shared Keys (PSK) for Wi-Fi, or private keys for OpenVPN/IPsec.
  • Backup users, including all password hashes in /etc/shadow.

By default, only the configuration is stored.
When the backup is not encrypted, an attacker could obtain the stored sensitive information and misuse the PIN, PSK, or attempt to crack the root password.

Recommendation

  1. Use a complex Encryption Password (see Use complex passwords) for any Configuration Backup. It must not be left blank or set to a trivial value that can be easily guessed.

  2. Do not replicate private keys to other devices. Each device should have its own.

Verify Server Authenticity

Risk

The first time you connect to a server via ssh or scp, the client will display a fingerprint of the server's public key:

The authenticity of host 'server.com (192.168.1.1)' can't be established.  
ECDSA key fingerprint is SHA256:NYo7IfkKOHUNScw3fEJxNKMRU+TZkvXe9UmW4w2dA2I.  
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This prompt is intended to verify the server's authenticity. If you always accept this message without checking, there is a risk that you may be connecting to a forged server operated by an attacker, who could then intercept your password or files.

Recommendation

Always verify the server fingerprint when connecting for the first time. Accept the verification request only when you are absolutely sure the server has not been forged. If you do not know the correct fingerprint, consult your system administrator.

If you are an administrator, maintain a list of SSH fingerprints for your machines, such as servers and routers. You can retrieve a fingerprint using the ssh-keygen tool:

user@server.com:/tmp$ ssh-keygen -l -f ssh_rsa_key  
256 SHA256:NYo7IfkKOHUNScw3fEJxNKMRU+TZkvXe9UmW4w2dA2I localhost (ECDSA)

Info

Due to size constraints, the ssh-keygen tool is not available on routers. You can temporarily copy the key to another server to retrieve its fingerprint.

Related to CVE-2020-14145.

Monitor System Logs

Risk

When routers are deployed in the field, attackers may attempt to log in or interact maliciously with the router. If these attempts go unnoticed, an attacker may have sufficient time to make multiple attempts, increasing the likelihood of a successful breach.

While you can view system messages on the System Log screen or save logs to a file, this method is impractical when managing a large number of routers.

Recommendation

  1. Set up a log collection and analysis server (e.g., Graylog or PRTG) to listen for Syslog UDP messages.

  2. In the Syslog service configuration, enter the Remote IP Address of the log collection server. We recommend entering 127.0.0.1 and installing the Secure Syslog Router App.

  3. Configure the server to automatically identify security-relevant events such as:

    • Router reboots
    • Both successful and failed login attempts
    • Changes to the router configuration
    • Clients connecting to (and disconnecting from) the WiFi AP
    • Clients requesting (and releasing) an IP address via DHCP

For more details on remote monitoring, please see the Remote Monitoring Application Note.

Monitor Network Traffic

Risk

In some deployments, the LAN is not under strict controlā€”for example, when portable devices such as laptops are temporarily connected for maintenance. These devices may carry malicious code that endangers the network from within the security perimeter. The likelihood of successful or damaging attacks increases if internal attacks go unnoticed.

Recommendation

  1. Set up a network monitoring system (e.g., PRTG).

  2. Deploy the NetFlow/IPFIX Router App:

    • Download the module and Add it to your routers in the User Modules configuration.
    • In the module configuration, check Enable Probe and enter the IP address of your monitoring system as the Remote Collector.

Caution

The NetFlow data should not be sent over WAN unless a VPN is used. The data are not inherently encrypted or obfuscated, so an unauthorized person may intercept and view the information.

Disable Lost Devices

Risk

Devices deployed in the field may be stolen or lost. An attacker who obtains a cellular router may:

  • Use the WAN connectivity paid for by the device owner;
  • Access the owner's network via the configured VPN;
  • Retrieve confidential data (e.g., certificates) stored on the device.

Recommendation

  1. Keep a record of active devices and associated digital assets, such as passwords, certificates, keys, or SIM cards.

  2. Detect the loss of a device as quickly as possible. When a device is lost, consider all associated assets as compromised:

    • Deactivate SIM cards used in the device;
    • Disable all accounts that use any of the passwords stored on the device;
    • Consider changing passwords that are similar to those stored on the device;
    • Revoke certificates for all private keys stored on the device.

Remove Stored Data When Decommissioning

Risk

The router configuration contains sensitive data, such as certificates, passwords, or PINs. It may also collect and store sensitive information from other machines. When the router is sent for maintenance or disposal, this stored information may leak to unauthorized persons.

Performing a Factory Reset using the RST button deletes the custom configuration, but it does not delete user certificates or any other user data stored on the router.

Recommendation

  1. Remove installed user modules. This will also remove user data related to these modules, except WA/VPN certificates.

  2. Use the shred tool (refer to the Command Line Interface Application Note) to securely remove sensitive files, for example:
    shred -u file1.txt

  3. Delete all remaining sensitive information in /var/data and ensure that all data possibly installed by custom user modules or owned by other users have been removed.

  4. If you uploaded your own HTTPS certificate, Generate a new certificate to overwrite it with a generic, self-signed one.

  5. Perform a Factory Reset by pushing/holding the RST button (see the User Manual). Then, wait until the PWR LED starts blinking again.

  6. Power off the device and remove all SIM cards.

  7. Remove all references to the device from network servers such as DHCP or DynDNS.

Hardening Guide

The following sections provide hardening guidelines for cellular routers manufactured by Advantech Czech.

Whereas the Configuration Manual of your router describes all capabilities and configuration options, this Hardening Guide provides a checklist to verify that the router installation and configuration are optimized for the highest security.

Each section describes:

  • Weakness which may arise from a misconfiguration;
  • Defaults factory settings; (This may differ if you are using a customized configuration module.)
  • Hardening guidelines to mitigate the weakness. These assume firmware version 6.2.4 or above.

The router configuration is initially set to the defaults of the factory firmware version. It can be reset to the defaults of the currently installed firmware version by pushing/holding the RST button.

Warning

The configuration is not modified during a firmware upgrade. For example, if you used 6.1.7 with its default settings, you will still use these settings after upgrading to 6.2.4.

No Physical Access

Weakness

Malicious persons with physical access to the device can easily disrupt its operation. An attacker may destroy or disconnect the device, extract credentials from its memory, modify the device, or replace it with a malicious device under their control.

Defaults

Cellular routers are protected against industrial environmental conditions (see the corresponding Data Sheet for more details).

Hardening

  1. Create a secure environment that can be accessed only by authorized personnel.
  2. Protect the power supply from unintentional disconnection. For critical systems, use Uninterruptible Power Supplies (UPSs).
  3. Protect input and output cabling.

Keep User Login Disabled

Weakness

The router security features protect against external threats, assuming there are no local non-root users who could log in and perform malicious actions. For example, since there are no user resource quotas, non-root users who can log in might execute CPU- or memory-intensive software, thereby disrupting router functions.

Defaults

The router supports two Roles:

  • Admin (root), who has full access rights to set up and configure the router, as well as remote shell access.
  • User, who can only view the router status through the web administration interface and access user data storage via (S)FTP. No other remote access is allowed.

Users created via the web interface have their login shell set to /bin/false, preventing them from logging in.

Hardening

Never make manual changes to the /etc/passwd file. Never allow regular (non-root) users command line access to the router.

Enable Wi-Fi Security

Weakness

Wi-Fi Authentication prevents unauthorized persons from connecting to the network. When disabled, anonymous attackers may spread viruses, perform Denial of Service (DoS) attacks on the network or connected clients, or simply steal bandwidth.

Wi-Fi Encryption protects the communication from eavesdropping by others. When disabled, attackers may intercept your login credentials or other sensitive data.

Defaults

The following Authenticationā€”Encryption combinations are allowed:

  • Openā€”None: Does not use any authentication or encryption. This is the default but least secure option.
  • Openā€”WEP: Uses the WEP key for encryption only. The WEP cipher is not secure as it can be broken in a few minutes.
  • Sharedā€”WEP: Uses the WEP key for both authentication and encryption. This is even less secure than Openā€”WEP, as the authentication phase makes data interception easier.
  • 802.1Xā€”WEP: Uses RADIUS for authentication and then derives the WEP key for encryption. As stated above, WEP encryption is not secure.
  • WPAā€”TKIP: Uses the original WPA protocol. It is not secure; use WPA2 instead.
  • WPAā€”AES: Uses WPA with a more secure AES instead of TKIP. This is intended for rare devices that support AES but not WPA2.
  • WPA2ā€”TKIP: Uses WPA2 with the older TKIP. Use only if you have older devices that cannot use WPA2ā€”AES or, preferably, WPA3.
  • WPA2ā€”AES: Uses the standard WPA2.
  • WPA3ā€”TKIP: Uses WPA3 with older TKIP. Use only if you have older devices that cannot use WPA3ā€”AES.
  • WPA3ā€”AES: Uses the standard WPA3. This is the most secure option.

All WPA, WPA2, and WPA3 protocols can use either a Pre-Shared Key (PSK) or RADIUS (Enterprise) for authentication. PSK is a simpler, user-friendly option for smaller networks, while RADIUS provides more robust security and management features for enterprise environments.

Hardening

  1. The most secure option is to enable WPA3ā€”AES to protect the security of user communication. If this protocol cannot be used for some reason, WPA2ā€”AES should be used as an alternative.

    • When a weaker authentication method needs to be used for compatibility reasons, consider using an Accept List to explicitly identify the clients that are allowed to connect.
    • When a weaker encryption method must be used, consider using a VPN (OpenVPN or IPsec) to protect the transmitted information.

  2. With WPA3-PSK or WPA2-PSK, use either a random 256-bit secret or a complex ASCII passphrase (as recommended in Use complex passwords).

  3. With WPA3-Enterprise or WPA2-Enterprise, use a complex RADIUS Auth/Acct Password.

Enable Wi-Fi Isolation

Weakness

In a public Wi-Fi network, the Pre-Shared Keys (PSK) are often well known, so the operator cannot effectively prevent malicious users from connecting to the wireless network. When connected users are not sufficiently isolated, these malicious users could use the network to attack other connected users.

Defaults

By default, both Bridged mode and Client Isolation are disabled.

Hardening

To further protect the security of connected devices:

  1. Ensure that Bridged mode is disabled.
  2. Enable Client Isolation.
  3. Configure the Firewall to prevent device-to-device communication by enabling filtering of forwarded packets, and then, for example (in this order):
    • allow all protocols with Source in the IP range of WiFi devices
    • deny all protocols with Destination in the IP range of WiFi devices

This configuration will prevent inter-user traffic on the WiFi network and also block external sources from initiating sessions with WiFi clients.

Disable Unused Services

Weakness

Enabled network services provide an additional attack surface for attackers to exploit. They can use flaws in the service implementation, communication protocols, or configuration to compromise the device or perform Denial of Service attacks.

Defaults

Most network services are disabled by default. Only the following services are listening (on their default ports) for inbound network communications:

  • DHCP server on primary LAN (eth0): udp/67
  • DNS: tcp/53 and udp/53
  • HTTPS: tcp/443
  • SSH: tcp/22
  • SNMP: udp/161

In addition, the following network services were enabled on v3 platforms until v6.1.0 and on v2 platforms until v6.2.0:

  • HTTP: tcp/80
  • FTP: tcp/21
  • Telnet: tcp/23

Hardening

  1. Remove user modules that are not necessary.

  2. Disable services, ports, and protocols that are not necessary, including services provided by user modules.
    Consider disabling services like SSH that are used only occasionally for manual maintenance. Such services can be enabled only when needed for maintenance and then disabled afterwards.

  3. Use the Save Report function and review the Sockets section to check UDP ports and all TCP ports in the LISTEN state. Only enabled services should listen on non-local addresses (other than ::1 and 127.0.0.1).

Caution

Always keep one service enabled for remote management, i.e. either HTTPS (for web administration) or the Hosted Management (HMP) Client (for WebAccess/DMP).

Avoid Using Public IP Addresses

Weakness

When the router is accessible via a public IP address, anyone in the world may try connecting, including cybercriminals. This greatly broadens the attack surface and increases the risk of an attack. For more details, see The dangers of public IPs from Kaspersky Daily.

Defaults

By default, the router obtains its IP address from the network operator or (on the eth0 interface) from the DNS server. Often, network operators use private networks and protect their customers from unwanted Internet traffic.

Hardening

Avoid using public IP addresses; do not make your router accessible from the public Internet. If you need to access your router remotely, you may:

  • Set up a VPN (Virtual Private Network), for example, using Advantech WebAccess/VPN.
  • Ask your network operator to set up a private APN for you.

Use Restrictive Firewall

Weakness

A firewall prevents unauthorized access to and from the LAN. A misconfigured firewall may impact the confidentiality, integrity, or availability of your network and devices.

Defaults

The router distinguishes between the outer (WAN) and inner (LAN) sides. Initially, the firewall drops traffic for well-known services (FTP, SSH, Telnet, DNS, HTTP(S), SNMP) coming from the WAN, while allowing all communication from the LAN.

Hardening

  1. The Firewall should allow only the minimal incoming traffic necessary.

  2. Enable filtering of incoming packets and define the IP addresses or IP ranges (e.g., 10.0.0.0/8) of systems in the WAN that need to send packets to the router, such as your central management server (if applicable).
    Note: These settings do not apply to LAN interfaces.
    Rules are processed sequentially, with the first matching rule taking effect:

    • First, define protocols or addresses that pose a threat to your network and must be denied (if any).
    • Then, define trusted protocols and addresses that need to be allowed.
    • Traffic not matching any of these rules will be denied by default.

  3. Enable filtering of forwarded packets and specify IP addresses or ranges from both the WAN and LAN that are allowed to send routed (forwarded) packets through the router. Other packets are dropped.

  4. Enable filtering of locally destined packets to drop all packets sent to the routerā€™s IP address, except those directed to the enabled services (e.g., Telnet, FTP, etc.).

  5. Enable protection against DoS attacks. This safeguards against common attacks such as:

    • TCP SYN flooding (allowing a maximum of 3 per second)
    • ICMP Echo flooding (allowing a maximum of 3 per second)
    • DoS attacks using small MSS (Maximum Segment Size), by enforcing a minimum of 250 bytes

  6. In the NAT Configuration, enable port forwarding and remote access only for the services that are in use. Disable any that are not needed.

Related to CVE-2010-4563, CVE-2019-11479, Nessus-50686.

Use Strong Ciphers

Weakness

Some ciphers use faulty algorithms or insufficient key lengths. These ciphers are vulnerable to attack, allowing attackers to eavesdrop on or counterfeit the communication.

Defaults

To achieve maximum compatibility, the OpenVPN Security Level is set to Weak by default.

Hardening

Set the OpenVPN Security Level to Medium or higher.

Disable FTP

Weakness

The File Transfer Protocol (FTP) provides basic, unencrypted file transfer capabilities with cleartext passwords for authentication. Attackers can easily eavesdrop on user passwords or use man-in-the-middle attacks to maliciously alter transferred data or inject malware.

Defaults

FTP has been configurable since v6.1.0. Starting with firmware v6.2.0, the FTP service is disabled by default.

Before v6.2.0, FTP was disabled on v3 routers. On v2 routers, it was enabled but accessible from the LAN only. Remote access from the WAN has always been denied.

Hardening

  1. The FTP service should be disabled. For secure file transfer, use SSH-based SFTP instead.
    FTP may only be used with extreme legacy systems in isolated networks that are periodically scanned for malicious software.

  2. When enabled, limit Maximum Sessions and Session Timeout.

  3. In the NAT configuration, remote FTP access must be disabled in all cases. Never use FTP over the public Internet.

Disable Telnet

Weakness

Telnet provides a simple terminal session to the router, but the Telnet protocol has no built-in security measures. Attackers can easily eavesdrop on the entire communication, including the root password.

Defaults

Telnet has been configurable since v6.1.0. Starting with firmware v6.2.0, the Telnet service is disabled by default.

Before v6.2.0, Telnet was disabled on v3 routers. On v2 routers, it was enabled but accessible from the LAN only. Remote access from the WAN has always been denied.

Hardening

  1. The Telnet service should be disabled. For a secure terminal session, use the SSH service instead.
    Telnet may only be used with extreme legacy systems in isolated networks that are periodically scanned for malicious software.

  2. When enabled, limit Maximum Sessions.

  3. In the NAT configuration, remote Telnet access must be disabled. Never use Telnet over the public Internet.

Related to Nessus-42263.

Disable (Unencrypted) HTTP

Weakness

Router administration via HTTP uses unencrypted communication. This means attackers can easily eavesdrop on user credentials.

Defaults

Since v6.1.0, the following configuration options are available:

Enable HTTPEnable HTTPSHTTP AccessHTTPS AccessRouter behaviour
OffOffOffOffWeb server completely down
OffOnRedirectOnForced redirect from HTTP to HTTPS
OnOffOnOffHTTP access only
OnOnOnOnIndependent HTTP or HTTPS access

The HTTPS service is available and always enabled on v2 and v3 router platforms. Starting with firmware v6.2.0, HTTP is disabled by default.

Before v6.2.0, HTTP was disabled on v3 routers. On v2 routers, it was enabled but accessible from the LAN only. Remote access from the WAN has always been denied.

Hardening

  1. Disable the HTTP service and enable HTTPS instead.

  2. In the NAT configuration, both remote HTTP access and remote HTTPS access must be disabled. The web administration interface should not be accessible from the Internet.

Caution

Always keep HTTPS enabled. If both HTTP and HTTPS are disabled, the web administration interface will not be accessible via any interface.

Related to Nessus-26194.

Use Secure HTTPS Ciphers

Weakness

The HTTPS protocol is built on a secure transport layer that exists in multiple versions. However, some versions are no longer considered secure and should not be used:

  • SSL 2.0 is prohibited by RFC 6176 since 2011.
  • SSL 3.0 is prohibited by RFC 7568 since 2015.
  • TLS 1.0 and TLS 1.1 will soon be deprecated by a future RFC.

Defaults

SSL 2.0 has never been enabled. SSL 3.0 has been permanently disabled since v5.0.0. TLS 1.0 and TLS 1.1 remain enabled for compatibility reasons, while the latest TLS 1.3 is supported starting with v6.2.8.

Hardening

Set TLS/SSL Min Protocol Version to TLS 1.2.

Use a Proper HTTPS Certificate

Weakness

A certificate verifies a router's identity to the web browser. If the certificate cannot be trusted, there is a risk that the browser is connected to a fake server. An attacker could trick the user into connecting to a fraudulent server and obtain the root password.

Defaults

During initialization, the router generates a self-signed certificate, which cannot be trusted.

Hardening

Obtain an HTTPS certificate from a public or corporate Certification Authority (CA), and then Upload a new certificate to your HTTP Configuration. The HTTPS certificate should:

  • Use RSA keys of at least 2048 bits;
  • Be within its validity period;
  • Be signed by a trusted certificate authority (i.e., not self-signed).

Caution

Checking the validity period requires the correct time to be set. To ensure the certificate remains valid even if the RTC battery or NTP server communication fails, the certificate validity period should start on 1.1.1980.

You can verify the validity of your certificate by clicking on the lock icon in your web browser.

Related to Nessus-15901, Nessus-51192, Nessus-57582, Nessus-69551.

Use Secure IPsec Ciphers

Weakness

The following algorithms are considered insecure:

  • Encryption: DES, 3DES, CAST, BLOWFISH
  • Hash: MD5, SHA-1
  • DH Group: Group 2 and lower (MODP512, MODP768, MODP1024)

Additionally, using a Pre-Shared Key (PSK) in Authentication Mode is less secure than using an X.509 certificate. A PSK is often cryptographically weaker, and if it is leaked, an attacker could perform a man-in-the-middle attack to impersonate either side and intercept the traffic passing through the tunnel.

Defaults

By default, the following settings are used:

  • IKE Protocol: IKEv1
  • IKE Mode: main
  • IKE Algorithm: auto, which selects aes128-sha256-modp3072 (complying with the NIST mandate that a minimum cryptographic strength of 128 bits is sufficient for security beyond 2030)
  • ESP Algorithm: auto, which defaults to aes128-sha256

Info

Once you set the auto mode, the default algorithms will be used. The individual algorithm configuration fields become greyed out, and any pre-filled values will be ignored.

Hardening

  1. Avoid Broken Algorithms:
    Do not use the insecure algorithms listed above. Preferably, stick to the default IKE and ESP settings.
    For manual configuration:

    • For IKE, use at a minimum:
      • IKE Encryption: AES128
      • IKE Hash: SHA256
      • IKE DH Group: 15 (MODP3072)
    • For systems not supporting SHA-256, SHA-1 may be used only as a HMAC for IKE, but not for any other purpose.
    • For ESP, use at a minimum:
      • ESP Encryption: AES128
      • ESP Hash: SHA256

  2. IKE Mode:
    The IKE Mode should be set to main. It is strongly advised to avoid aggressive mode, as it is inherently flawed.

  3. Authentication Mode:
    Use X.509 Certificate authentication. Certificates should be signed using at least SHA-256.
    To securely authenticate using a Pre-Shared Key, the key must be very long and random. For example, you can generate a secure key with:

   dd if=/dev/urandom count=1 bs=32 2>/dev/null | base64
  1. The PFS (Perfect Forward Secrecy) should be enabled for every tunnel. It protects the confidentiality of the traffic, if the IKE shared secret has leaked.

For more details, see the strongSwan documentation.

Use Complex SNMP Community

Weakness

The SNMP Community string functions like a password that allows access to router configuration and statistics.

An attacker who can guess the Read Community string can retrieve sensitive network information for further attacks, or overwhelm the router with massive traffic and cause a service interruption.

After activating Enable I/O extension, SNMP can be used to modify an I/O status. An attacker who can guess the Write Community string could maliciously control the connected system.

Defaults

By default, the SNMP agent and SNMPv1/v2 access are enabled and accessible via LAN only. The agent uses public as the Read Community and private as the Write Community stringā€”common defaults for many devices.

The I/O extension is disabled by default.

Hardening

  1. Disable the SNMP agent when it is not needed.

  2. Disable SNMPv1/v2 access and enable SNMPv3 access, which employs better encryption. The older SNMP versions should be avoided and used only in a private LAN.

  3. Disable SNMP extensions that are not needed.

  4. Configure the Firewall to restrict UDP traffic on port 161 (SNMP) to monitoring servers only.

  5. In the NAT configuration, disable remote SNMP access. Never use SNMPv1/v2 over the public Internet.

  6. Set the Read and Write Community strings to complex values that cannot be easily guessed (see Use complex passwords).

Related to CVE-1999-0524, Nessus-41028, and Nessus-76474.

Mitigate Sockstress Attack

Mitigate Sockstress attack

Weakness

A design flaw in the TCP protocol allows an attacker to create crafted TCP connections, which can eventually exhaust the router's resources and lead to a denial of service (DoS).

Defaults

No TCP service is accessible from the WAN, so the attack is possible from the LAN only. Attackers within the LAN may cause a DoS of any accessible TCP service, including SSH or HTTP(S) administration.

Hardening

The only way to completely prevent this attack is to whitelist access to TCP services in the Firewall configuration:

  • Allow TCP for selected services.
  • Deny all other TCP.

Note: The current firmware does not support rate limitation of TCP connections using iptables conntrack.

Related to CVE-2008-4609.