Skip to main content

Fundamental Hardening

Local administrator accounts and passwords​

Initial User Account​

Factory-config contains publicly known username and password for the admin account. Publicly known passwords are prime targets for malicious automated scanners. By using default credentials, anyone with access can gain full privileges to the device.

tip

Consider using strong password with high entropy, consider setting up SSH passwordless authentication by leveraging SSH-keys.

It is possible to remove the initial administrator account, WeOS requires that at least one administrator exists on the device, therefore a new user with the role administrator must first be created. Note that an administrator cannot remove itself. It is recommended to create a new administrator user and remove the default admin account, this will make it harder to guess the username. As minimum, update the default admin account with a new password.

As minimum, replace the default admin password.

example:/config/aaa/user-admin#> password alg sha512 secret NewPassword

example:/config/aaa/user-admin#> show

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

As recommended, create a new user with role administrator and remove the default admin account.

example:/config/aaa/#> user MyNewAdminAccount
example:/config/aaa/user-MyNewAdminAccount#> password alg sha512 secret NewPassword

example:/config/aaa/user-MyNewAdminAccount#> show

Logout as admin and login with MyNewAdminAccount to remove the admin account since a user cannot remove itself

example:/config/aaa/#> no user admin

example:/config/aaa/#> show

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: AAA

Encrypt Secrets​

It is important to protect sensitive information in the configuration backup files. This can be achieved with the Encrypt secrets functionality. The device support different encryption sources, which should be selected depending on requirements and policies. In this example a password will be used in order to be able to decrypt all sensitive information in the configuration file, this method enables portability if the same password is used across multiple devices. Backup of the secret and configuration file should be stored separately.

example:/#> encrypt-password C0nF!Gp4sSw@RD382
example:/config/system/#> encrypt-secrets password
example:/config/system#> leave

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: Encrypted Secrets

Remote administration and network services​

Set an acceptable session timeout​

Setting a timeout for idle connections ensures that sessions automatically close after a defined period of inactivity. Without a timeout, or if it's set too long, idle connections may persist indefinitely, which can potentially lead to session hijacking, allowing unauthorized users to access the device. Timeout value depends on the environment (window-of-opportunity) and desired user-experience. It is recommended to set the session timeout for administrative connections to five minutes or less.

note

Factory-config does not contain a default session timeout for the console connection. Failing to set session timeout on the console may result in unauthorized users being able to access the device through an old user session.

Note timeout unit for each setting.

example:/config/management/web/#> session-timeout 5
example:/config/management/ssh/#> idle-timeout 300
example:/config/management/cli/#> timeout 300

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: Web Interface | Secure Shell (SSH) | Command Line Interface (CLI)

Limit authentication attempts​

Lockout users with successive failed login​

The lockout policy is a security feature that prevents unauthorized access to the system by locking out users who enter incorrect login credentials too many times. It is recommended to restrict failed remote administration attempts to a maximum of three or less. To mitigate locking out all users (resulting in Denial-Of-Service scenario), it is recommended to exclude the console port to always be able to login via console, however it depends on the installed environment.

example:/config/aaa/lockout-policy/#> enable
example:/config/aaa/lockout-policy/#> exclude console

example:/config/aaa/lockout-policy/#> show

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Fail Delays​

It is recommended to introduce a delay of at least one second between login attempts to significantly slow down brute force attempts.

example:/config/management/ssh/#> fail-delay 2

example:/config/management/ssh/#> show

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: AAA | Secure Shell (SSH)

Limit Remote Management Sessions​

Limit remote management sessions is available to mitigate exhausting system resources. The max-remote-sessions value depends on the environment and desired user-experience.

note

If a limit on remote management sessions is set, it is strongly recommended to set inactivity timeouts for all enabled remote login methods, to avoid locking out users.

example:/config/management/#> max-remote-sessions 3

example:/config/management/#> show

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: Limit Remote Sessions

Enforce Usage of Strong Passwords​

A password policy should be enforced to ensure users use more complex passwords, making it harder to guess or crack. Various parameters can be configured to increase the password entropy, however the policy should prioritise long passphrases (minimum 15 characters) over strict complexity rules. The longer and more complex password, the higher the entropy. Note that the password policy applies to user passwords. Unique and complex password/secret should also be used for routing authentication, VPN tunnels, DDNS, Simple Network Management Protocol (SNMP) auth, Radius/TACACS+ shared secret, and anywhere else passwords/secrets are stored in the configuration.

example:/config/aaa/password-policy/#> enable
example:/config/aaa/password-policy/#> min-length 15
example:/config/aaa/password-policy/#> reject-username

Depending on password policy, configure:
example:/config/aaa/password-policy/#> uppercases 4
example:/config/aaa/password-policy/#> lowercases 4
example:/config/aaa/password-policy/#> digits 5
example:/config/aaa/password-policy/#> specials 2

example:/config/aaa/password-policy/#> show

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: Password Compliance Policy

Replace Self-Signed Certificate for Web​

Using a default self-signed certificate leaves devices vulnerable to spoofing, MITM interception, and trust warnings that users may ignore. Replacing it with a certificate issued by a proper PKI enables chain-of-trust validation, centralized revocation, lifecycle management, and auditability. This improves security posture, reduces operational risk, and aligns with compliance expectations for encrypted management interfaces. For more information about retrieving certificates using SCEP and utilising CRL, see Public Key Infrastructure.

Prepare a PKCS12 bundle containing the end-entity certificate, matching key and necessary CA certificates. The bundle is protected by password.

$ openssl pkcs12 -export -out newcert.p12 -inkey newcert.pem -in dut1.pem -passout pass:westermo -certfile int-ca.pem -certfile root-ca.pem

Verify that device's web interface is not trusted when the web-default certificate is used:

$ curl --cacert root-ca.pem https://192.168.122.70/
curl: (60) SSL certificate problem: self-signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Import PKI artifacts using secure copy (SCP) from user alice, verify import and apply to the web:

example:/pki/#> import pkcs password westermo label newcert user alice proto scp 192.168.122.1 /certs/newcert.p12

example:/pki/#> show cert full

example:/config/management/web/https/#> certificate newcert

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Verify that device's web interface is now trusted:

$ curl --cacert root-ca.pem https://192.168.122.70/ | head
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2844    0  2844    0     0   110k      0 --:--:-- --:--:-- --:--:--  111k
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
  <title>newcert - </title>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Reference: PKI - Certificates

Notification & Consent Banners​

Login banners on network devices serve a critical role in both cybersecurity and legal compliance. Login banners are not only informational, they establish clear boundaries and expectations for anyone attempting to access the system. Informing that any unauthorized attempts may result in legal action can be a barrier to cross for some unauthorized users. However it also provides other important parts that could be required depending on organizational or regulatory requirements, such as informing about disclaimers and consent to logging and monitoring. For further read and examples, visit Guidance on Consent Banners at CISA.gov

example:/config/management/web/#> login-banner "This is a message."
example:/config/management/ssh/#> login-banner “This is a message."
example:/config/management/console/#> login-banner “This is a message."

example:/config/management/web/#> show
example:/config/management/ssh/#> show
example:/config/management/console/#> show

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: Web Interface | Secure Shell (SSH) | Console

Local Audit-Logging​

It is strongly recommended to use time-synch server for universal time across the system and remote syslog sinks for offloading auditable events to a separate device for data handling, see Enhanced Hardening. If a remote system can not be used, consider setting time manually and leverage persistent logging to external media, this approach should be considered as a last resort (not recommended) since local logging and lack of universal time-synch will make incident response handling difficult and time consuming.

Apply rules to packet flows​

When connecting a network to the Internet or any non-trusted network a router with Firewall functionality can be used to protect against undesired access and traffic to your local network and devices. Undesired traffic can include for example ICMP flooding and Ping-of-death types of attacks. A firewall should be considered where traffic is moving in, out or between different Security Zones (See Product Security Guide for further read). By doing so, strict control of the network traffic can be enforced. The firewall rules that is applicable is dependent on the logical environment, which can be defined with which traffic that is required to flow in, out or between different Security Zones. The following rules can be applied for enabling management traffic (SSH, HTTPS) on a specific VLAN, in this case VLAN 500.

warning

If you don’t allow any management access (ssh, https) on any interface you will not be able to reach the device after enabling the Firewall. Be careful and don’t lock yourself out!

example:/config/ip/firewall/#> policy input drop
example:/config/ip/firewall/#> policy forward drop
example:/config/ip/firewall/#> input accept in vlan500 dport https proto tcp
example:/config/ip/firewall/#> input accept in vlan500 dport ssh proto tcp
example:/config/ip/firewall#> enable

example:/config/ip/firewall/#> show

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: Firewall

Limit Broadcast, Multicast and Unknown Unicast Traffic​

The switch can be configured to limit the rate of a port’s incoming traffic, this is called ingress rate limiting. By default a port accepts packets at a rate up to the link speed, with ingress rate limiting activated the switch starts dropping packets when data arrives above the given rate threshold. This feature can be useful as a complement to layer-2 priority handling when congestion within the network is to be avoided. To minimise the risk of high levels of traffic with a broadcast behaviour entering the network, ingress rate limiting can be used to limit the amount of Broadcast, Multicast and Unknown Unicast that are allowed in on a port.

example:/config/#> port eth2
example:/config/port-eth2/#> ingress-rate-limit 1M match bc,mc,u-uni

example:/#> show port eth2

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: EthernetPorts

Recovery from unresponsive system​

The watchdog is a functionality that can help the system recover from various possible malfunctions that could cause the system to enter a state where it is not able to operate correctly. Anything from a hardware fault or program errors may cause the watchdog to trigger. By default, Watchdog is enabled. The system allows for disabling the watchdog. However, this is not something that is recommended. The current status of the watchdog can be observed with:

example:/#> show watchdog

Reference: Watchdog

Disable Unused Protocols and Services​

Upon initial startup, WeOS is loaded with a factory-default configuration. This setup is intentionally designed to prioritise ease of use, enabling users to quickly access and begin working with the device. While a large set of security policies is enabled by default, the configuration prioritises user accessibility and ease of setup, intentionally limiting strict security controls to streamline the initial experience.

warning

Each factory-enabled service and protocol should be carefully conceded if it should be enabled or disabled as part of the hardening.

Default Management Services​

All management services are enabled per interface, i.e., VLAN1, VLAN2, VLAN500 etc. Changing a management service on one interface, does not impact other interfaces. All implementations of management services must be configured individually per interface. The table below is a summary of management services with related default values.

ServicePortDefault ValueDescription
HTTP80EnabledDisable HTTP. HTTP does not encrypt data between the client and server, making it vulnerable to interception. If Web access is required, use HTTPS.
HTTPS443EnabledOnly leave HTTPS enabled if you use the web interface on the device, disable HTTPS on all interfaces that does not require access . HTTPS uses its own certificate for validation and default certificates should be replaced for additional security
SSH22EnabledOnly leave SSH enabled if you use the remote console services on the device. If not, disable SSH on all interfaces that does not require remote console access
Telnet23DisabledKeep disabled, only enable if there is a very specific requirement for Telnet. Use SSH as the preferred method.
SNMP (poll)161Enabled
poll community set to "public".		Disable SNMPv2. SNMPv2 is vulnerable to interception since it transmits authentication community strings and other network data in plaintext. The "public" poll community is publicly known information, anyone with basic knowlege can get operational information about the device. Instead use SNMPv3 which provides authentication and encryption
SNMP (traps)162DisabledLeave blank. Use SNMPv3 as the preferred option if SNMP is required. Disable SNMPv2 attributes via console.

Reference: HTTP | HTTPS | Secure Shell (SSH) | Telnet | SNMP

Default Protocols & Services​

It is possible to disable default enabled protocols and services, however it should be carefully considered if it should be enabled or disabled, since it depends on the environment and requirements of the network.

To disable SSDP and MDNS:

example:/config/discover/#> no mdns
example:/config/discover/#> no ssdp

example:/config/discover/#> show

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

LLDP can be useful for troubleshooting purposes, however it also provides network information which can be disclosed to users. Where it is possible, disable LLDP. If it is not possible, only enable LLDP on interfaces connected to trusted devices. Disable it on edge ports or guest networks to prevent exposure. In the following example, port eth9 is a edge port.

example:/config/lldp/#> no port eth9
example:/config/lldp/#> show port

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: LLDP

Default Settings​

The default settings described have effect on how the device behaves. Carefully consider each setting and it´s impact related to the installed environment.

To disable IGMP snooping per VLAN:

example:/#> config vlan 1
example:/config/vlan-1/#> no multicast-snooping

example:/config/vlan-1/#> show multicast-snooping

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: IGMP Snooping

IP Forwarding is enabled by default on devices with routing capability. Enabling IP Forwarding enables routing between VLANs without explicit firewall rules or access control lists, allowing lateral movement and increases the risk of compromise spreading across security zones. If routing is not required on the device, it should be disabled. However if routing is required, firewall rules should be applied.

example:/config/ip/#> no forwarding

Reference: IP Forwarding

Disable Unused Physical Ports​

Leaving unused ports enabled on a device could allow an adversary to connect a rogue device to the network and perform information gathering or compromise attempts. All unused ports should be disabled. Unused ethernet ports should always be disabled. For more complex and dynamic environments, such as a road-warrior scenario, consider PortNetwork AccessControl. The feature PortProvisioning can, in some cases, simplify the disable unused ports process.

example:/config/port-eth1/#> no enable

example:/#> show port

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

It is possible to disable the auxiliary ports, this will disable USB or SD card. By default, audit logs are not persistently stored and require the need for remote logging sinks. By remote logging sinks, this include multiple syslog servers or external media, such as USB or SD card. Depending on design and requirements, the auxiliary port may be used for persistently storing audit-records. If the auxiliary port is unused, it should be disabled.

example:/boot/#> no aux-port

example:/boot/#> show aux-port

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

It is possible to disable the console port, this will block all access to the device via the port except for factory-reset purposes. Disabling the console port is not recommended and is considered as a essential function. The port should always be available for mitigating security issues and solving functional issues, since remotely managing the device might be unavailable at that time.

example:/config/management/console/#> no login

example:/config/management/console/#> show

Remember "copy run start" to save to flash (NVRAM).
example:/#> copy run start

Reference: Ethernet Ports | Aux | Console

Avoid Untagged Native VLAN on Trunk Ports​

In WeOS, any VLAN where a port is configured as untagged can be considered the native VLAN for that port. Therefore, when configuring the VLANs on the device, consider how you combine the untagged and tagged ports, so that a trunk port is not configured as untagged for a VLAN that is not intended, especially because all ports are by default set as untagged in VLAN 1.

Generally it is recommended to avoid having untagged (native) VLANs on any trunk port(s):

  • Ensure that any incorrect untagged (native) VLANs are not configured on trunk ports.
    • If an untagged VLAN is required on a trunk port, ensure that it does not facilitate access on unintended access ports.
  • If a native VLAN is required on a trunk port, consider which VLAN is used, to avoid providing possible access on unintended access ports.
Frames tagged with VID 0 counts as untagged

Important to note, frames that are tagged with VID 0 (generally used for priority tagging), are treated as untagged when they ingress on a port.

Example of Untagged VLAN on Trunk Ports​

As an example where a potential misconfiguration can lead to unintended access, consider the following scenario:

                    Access port                  Trunk                   Access port
  .--.-.                        .--------.                    .--------.                      .--.-.
 ( (    )__                 U:1 |        |     U:1 T:100      |        | U:100               ( (    )__
(_,  \ ) ,_)--------------------+   S1   +--------------------+   S2   +--------------------(_,  \ ) ,_)
  '-'--`--'                     |        |                    |        |                      '-'--`--'
    LAN-1                       '--------'                    '--------'                        LAN-2

Send frame: [0,100] ----------->          [100] ------------->          [] ------------->
Send frame: [1,100] ----------->          [100] ------------->          [] ------------->

In the above scenario, an access port on S1 is configured as untagged in VLAN

  1. Similarly, an access port on S2 is configured as untagged in VLAN 100. Lastly, there is a trunk configured between S1 and S2 that is tagged with VLAN 100, however, the trunk ports on both S1 and S2 are still left configured as untagged in VLAN 1 by mistake (This could typically happen if configured from the device's factory default configuration).
Tags are stripped when egressing on an untagged port

Remember that when a VLAN tagged frame has ingressed on a port tagged in the same VLAN, the tag will be stripped when egressing on a port untagged in the same VLAN.

Because of this, if frames are sent from LAN-1 with nested VLAN tags, where the outer is tagged with VLAN 1 (or VID 0, counts as an untagged frame) and the inner tagged with VLAN 100, it can seemingly "hop" from LAN-1 to LAN-2, which was not the intention. The reason this happens is because the outer VLAN tag will be stripped from the frame, and it will egress in the untagged (Native) VLAN 1, that is also configured on the trunk port by mistake. What was the inner VLAN tag, VLAN 100, will now be the outer VLAN tag when we egress S1 towards S2. When the frame arrives on S2, tagged in VLAN 100, it will now be allowed to egress on the access port untagged in VLAN 100 towards LAN-2.

Reference: VLAN