Version: 2.0

Hardening & Configuration Guide WeOS 5

Introduction

Hardening a network is not one simple tick-box exercise. It takes time, effort and many considerations to understand what should be secured and why. Westermo have created hardening guidelines, in accordance with the ISO 62443-4-2 standard, providing a series of recommendations in to how to harden your WeOS device.

All recommendations are based on the WeOS version WeOS5 with supported hardware on the compatible Lynx, Redfox and Viper range.

The underlying message of the this document utilises the Defence in Depth (DiD) cybersecurity strategy. DiD is divided in to three subsections with the underlying philosophy of Identify > Protect > Detect > Respond > Recover. The three subsections that are to be considered are Environment (Identify), Systems & Application Security (Protect) and Monitoring & Recovery (Detect, Respond & Recovery).

We look at default values, which outline exactly how your device is configured when you receive it. Since every network and system is unique, you must take steps and understand what measures that should be introduced and deployed to ensure your network is safe, and remains safe. Not every parameter within in this document is valid for you and it is important to distinguish which ones are.

Cybersecurity in the broadest form is a risk assessment. Once you have assessed the risk, mitigating controls are strongly recommended to be deployed to help protect your assets.

Cybersecurity is also not only a digital effort. Understanding the logical network is critical in preventing attacks. though also you must acknowledge the underlying importance of physical networks. Designing a network with cybersecurity in mind helps in both the short and long term, with considerations taken on both the physical and logical network. Whilst this document focuses more on the logical network methodologies, awareness of physical networks is laced into each section for context. Decisions made on the logical network, have an impact on the physical network and vice-versa.

Reading this document will help you understand why and how measures help protect your network. There is no strict guide with the right and wrong measures to take, but one thing for sure is that ignorance of cybersecurity efforts will increase the risk of a breach. This document provides holistic overviews of different measures that have an impact on your network and provides recommendations to introduce them and in some cases to what level.

Each of the three sections, Environment, System & Application and Monitoring & Recovery, each are focused on measures that are be taken throughout those stages of your network design and deployment. Each section is detailed with various topics, which focus on both the logical and physical topology and each providing recommendations. Sections are summarised with recommendations of best practices being concluded.

The document is broken in to two sections, with two different orderings. The first part focuses on knowledge and recommendations for each section. The second part focuses on application and configurations processes. They are different orders for a reason, since practices must be observed in one order, and deployed in another. Take Firewalls for example, it is vital not to apply a Firewall as the first step since you may lose access to the device. It should always be implemented after you have done all the work. However it is important to consider the importance of once during design and a risk analysis phase, to help you understand what you should configure later.

It is important before reading this document to familiar with the OSI Model. We will use terminologies such as Layer 2 a Layer 3 to define solutions. For more information on how the OSI model works, check out the Westermo Industrial Blog at The OSI Model Explained.

Risks & Mitigating Controls

Understanding the risks of a network is the first step to control. Mitigation practices are recommended to be implemented to ensure your network becomes secure and remains secure.

Feature	Risk	Mitigating Controls
Firewall	Exposure to unwanted and authorised access can leave network vulnerable to attacks	Enable the firewall on all interfaces. Establish a set of rules that are either limited or restricted on specific ports, protocols, networks or IP addresses
NAT Rules	Traffic and data would not be masqueraded on external networks	Enable NAPT on all outgoing interfaces that require masquerading, especially those accessing untrusted networks such as the Internet.
VPN	Unencrypted traffic can lead to unauthorised viewership of data during transit.	Either locally or remotely, traffic should be encrypted via secure VPN practices to prevent unauthourised access.
AAA	No control or management or who has access to the device, with no method to managed or revoke access on large scale	Oversight of access to the network and devices provides the ability to ensure holistic management of who is access the network. Enabling different user accounts with appropriate permissions prevents the ability for intentional or unintentional cybersecurity attacks. Configuration in collaboration with 802.1x using services such as TACACS or RADIUS.
Session timeout	Users remain logged in all the time	Enable to prevent users remaining logged in if they are absent from end device or forget. Prevents extended sessions on Web and console without permissions and input
Password policy	Users are able to use passwords with no restriction	Enable to ensure users that create passwords must create passwords with high entropy
Lockout policy	Users are able to attempt to log in any number of times consecutively	Enable to restrict the number of consecutive attempts users can log in and establish a delay for when they can attempt again.
Alarms	Systems that do not have alarms enabled may not have the ability to inform if an error or an event has happened on the system.	Enabling alarms on relevant interfaces and services provides holistic oversight of incidents such as login attempts or local connections. Information should be logged to an external server
System Logging	Logs will always be saved on devices, however there is a maximum capacity of how much data will be stored. It is strongly recommended that an external log server is included in the system	Protecting and storing logs enables the ability to troubleshoot and understand the device in a deeper level
Persistent Logging	When a device is reset or experiences an unexpected shutdown, logs are not persistent and will be wiped. This could provide important information of an event, which is unable to be retrieved.	Configure persistent logging to protect value information and store on a remote logging server
Audit Event Logging	When this service is not enabled, details about what and who are not captured	Enabling this service provides a detailed oversight of who and what has been conducted. Information should to be stored on a remove logging server
Date & Time	Inaccurate time and date can invalidate certificates and can make logged information worthless	Set the time and date on all devices and sync up with external NTP servers for more accuracy
SNMP	Systems that do not have SNMP enabled may not have the ability to inform if an error or an event has happened on the system	Enable and configure SNMPv3 for authentication and authenticity of user access. Configure with external SNMP server to capture all information. Set up read and write permissions as per your system requirement. Do not enable write access if not required
Certificates & Keys	Lack of or no deployment of certificate and key management can remove the ability to manage and control the device with ease	Configuration allows for greater control of secure management access VPNs & tunnels.
DHCP Server	Unmanaged and poorly configured DHCP servers can supply devices with IP address thus giving them access to the network.	Disable DHCP if not required. If required, configure as per your system recommendations and limit to devices that only need it
DNS	DNS resolution could provide unwanted devices to access services on the Internet for example	Disable DNS is not required. If required, configure to devices that only need it and ensure that firewalls prevent unwanted devices from attempting to resolve IP addresses
VLAN	VLANs are required for management and routing. Ignoring and misconfiguring VLANS could potentially leave your device and network exposed to unwanted access	Disable all unwanted VLANs (i.e., VLAN1) and only configure VLANs that are required for routing, management services. Ensure that all management services are disabled that are not required
L2 Redundancy	Poorly or misconfigured Layer 2 redundancy protocols can cause your network to not operate as expected	Configure only required devices with L2 redundancy protocols
L3 Redundancy	Poorly or misconfigured Layer 3 redundancy protocols can cause your network to not operate as expected	Configure only required devices with L3 redundancy protocols

Management Services

Service	Port	Risk	Mitigating Controls
HTTP	80	HTTP is an insecure protocol and does not encrypt traffic during transit. If left enabled, bad actors would monitor and view traffic during transmission	Disable this service on all interfaces. If Web access is required, used HTTPS. It is only enabled for first time configuration
HTTPS	443	If there is no requirement for Web access to the device, regardless of additional features, it could potentially expose your device to unauthorised access (i.e., the ability for bad actors to attempt to gain access)	Only enable HTTPS if you use the Web services on the device. If not, disable HTTPS (and HTTP) on all interfaces that does not require web access. HTTPS uses its own certificate for validation and default certificates can be replaced for additional security
SSH	22	If there is no requirement for remote console access to the device, regardless of additional security features, it could potentially expose your device to authorised access (i.e., the ability for bad actors to attempt to gain access)	Only enable SSH if you use the remote console services on the device. If not, disable SSH on all interfaces that does not require remote console access
Telnet	23	Telnet enables unencrypted remote console access	Telnet is disabled by default. Only enable if there is a specific requirement for Telnet. Use SSH as the preferred method.
SNMP (poll)	161	By default, SNMPv2 is enabled with a poll community set to "public". If this interface is exposed, it provides an ability for bad actors to poll Westermo devices	Use SNMPv3 as the preferred option if SNMP is required. SNMPv2 is read only on default
SNMP (traps)	162	By default, SNMPv2 does not have write or poll communities configured. Inputting parameters in to this service is not recommended if not required.	Leave blank. Use SNMPv3 as the preferred option if SNMP is required. Disable SNMPv2 attributes via console.

All management services are enabled per interface, i.e., VLAN1, SSL253, etc. Changing a management service on one interface, does not impact other interfaces. All implementations of management services must be configured individually per interface.

WeOS, Westermo's Operating System

WeOS is a leading-edge industrial network operating system that is being continuously developed whilst being subjected to exhaustive quality testing. It powers the most reliable switches and routers on the market, designed for harsh industrial environments. WeOS has extensive support for network and security protocols that have been made simple to configure and maintain. WeOS along with Westermo’s robust hardware provides the world’s most reliable network solutions.

Continuous software validation ensures the highest quality
Resilient secure multimedia network solutions
Simple and flexible configuration
Legacy and industry specific solutions

For more information and to download the latest version of WeOS visit the website.

Defence in Depth

Protecting your network and system takes a considerable amount of time and money. The task of hardening your network should be acted upon as a must and not as an afterthought. The threat is real and is happening ever so more frequently. Cybersecurity threats on industrial networks are now not just a rare event. Today there are now targeted and organised threats continuously bubbling from societies underbelly.

Westermo are one part of the complex structure we as everyday users rely on. We are embedded at the core of industrial networks and our equipment is designed to last many years in the most harshest environments. We enable critical data communication with the network, though the system requires additional measures to ensure that it cyber secure.

When a solution is designed, tested, commissioned and deployed it can involve many complex pieces, which are all expected to operate together. Measures must be conducted at every step to ensure that the network is secure and most importantly is to remain secure. Westermo have developed a Defence in Depth strategy that assists with recommendations and supporting evidence in what you should do and why you should you do it. This document in no way means that if you take every step your network will be 100% secure, however, it rather displays facts in why decisions you make can help will secure your solution.

Defence in Depth (DiD) is divided in to three subsections with the underlying philosophy of Identify > Protect > Detect > Respond > Recover. The three subsections that are to be considered are Environment (Identify), Systems & Application Security (Protect) and Monitoring & Recovery (Detect, Respond & Recovery).

Environment (Identify) focuses on design, solution and device capabilities. It looks at why network segmentation, net-to-net protection and perimeter protection are critical to secure your networking. Further investment is required on both physical and logical network, where we will highlight the investment how logical measures compliment physical measures.

Systems & Applications security (Protect) focuses on the capabilities of devices and discusses how system integration should be conducted with device hardening. This means that measures such as disabling ports, limiting who and how user access the device, complimented by patch management helps maintain a healthy security posture for your system.

Monitoring & Recovery (Detect, Respond & Recover) focuses on how to monitor your network to detect threats, using services such as external logging help both capture what is going on the in the device, but also if a threat happened, you can understand where, when and how. These services are complimented with protocols such as NTP (to ensure your time and date is correct), along with audit trails and implementing practices with backup and restoring devices in the case of event.

Defence in Depth is a strategic structure for risk management, helping you to understand how to secure and harden your network.

Default Values

When you receive a device from Westermo, it will not be configured with many of the parameters that are recommended in the hardening guidelines. It is up to you to harden your device and system in line with the risks determined for your requirements and process. Here is a table of default values configured, with each supplied with a recommendation for how they should be configured. Included in the table is a link to the section within the hardening guideline and also understand how to adjust parameters to ensure your device is hardened.

Factory Default Values

It is strongly recommended to enable the firewall on all interfaces. Please note that this is only applicable on devices that support this function (Extended editions). Only enable services (i.e., NAPT, VPN, etc) if required.

Parameter	Default Value	Recommended Value	How to Harden?	Additional Comments
Firewall	no enable	enable	Firewall
NAT Rules	no enable	enable		Configured with firewall
VPN	no enable	enable
AAA	no enable	enable
Session timeout	no enable	enable		Configured in collaboration with Lockout Policy and Password Policy
Password policy	no enable	enable		Configured in collaboration with Session Timeout and Lockout Policy
Lockout policy	no enable	enable		Configured in collaboration with Session Timeout and Password Policy
802.1x	no enable	enable		Configured with AAA
Alarms	no enable	enable		Subject to your system requirements
System Logging	no enable	enable		Connect to external logging server
Persistent Logging	no enable	enable
Audit Event Logging	no enable	enable
Date & Time	enable	enable		Sync with two NTP servers
SNMP	enable	enable
Certificates & Keys	?	?
DHCP Server	no enable	no enable		Enable subject to requirement
DNS	no enable	no enable		Enable subject to requirement
VLAN	enable	enable		Enable on required interfaces. Disable all unused VLANs
L2 Redundancy	no enable	no enable		Enable subject to requirement
L3 Redundancy	no enable	no enable		Enable subject to requirement

Management Services

It is recommend to enable the following management services on specific and relevant interface. You need to consider if the service is required and if not, disable it. For example, SNMP should only be enabled if you have an SNMP server configured.

Parameter	Port	Protocol	Default Value	Recommended Value	Additional Comments
HTTP	80	TCP	enable	no enable
HTTPS	443	TCP	enable	enable
SSH	22	TCP	enable	enable
Telnet	23	TCP	no enable	no enable
SNMP (poll)	161	UDP	enable	enable	Available for SNMPv2 only. Strongly recommended to use SNMPv3
SNMP (traps)	162	UDP	enable	enable	Available for SNMPv2 only. Strongly recommended to use SNMPv3. Disable ability to write communities via console.

Environment (Identify)

Securing networks takes many steps, with the first one focusing on the environment. This sections looks at both the physical and logical network, with no emphasis on either.

Best practices of network security is about understanding how to segment a network, such as dividing and limiting the spread of threats. The mindset of "not if, but when" aids decisions being taken to protect assets. Establish firewalls and utilising protocols such as NAT and VPNs help establish security throughout your network and system. Firewalls and services, such as NAPT, are not just an enable state, by which you just turn them on an everything works. There are more efforts that take time and help protect your network. This means that you need to determine the level of how you want to secure your network based on the advice provided in this document. Furthermore, additional steps are recommended to be considered in to understanding of why products that support secure boot offer a level of security that helps protect your network for now and many years in the future.

When designing, testing and deploying a system, often management services are overlooked. This is where you access the device via the Web, console, or in some cases SNMP. Be default, WeOS devices have all ports enabled in VLAN1, with management services such as HTTP, HTTPS and SSH enabled. Now it is up to you which VLAN you use, though it is highly recommended to disable all unused ports and management services. This section covers why you should, and provides recommendations for actions to be taken.

Industrial networks are very commonly designed with redundancy in mind, especially those that are for critical services (which is very common). Industrial networks both can utilise switching and routing functionalities (subject to chosen devices), that support complex redundant network protocols. Networks that predominately use Switches can utilise protocols such as FRNT, whereas networks that predominately use Routers (or ones with routing functionality), can utilise protocols such as OSPF and VRRP. This section discusses recommendations and considerations to taken to establish both a robust and reliable physical and logical network.

Firewall

Industrial firewalls are one of those things that you may have heard of but might not sure exactly how they are important to a network. There are many different ways that one can configure a firewall, albeit it on system level or a device level.

A firewall, requires a Layer 3 compatible product and when configured correctly, is designed can protect the inside of your network (trusted), from external networks (untrusted). Firewall policies are based on trust of what is leaving the network and what is entering. It can protect against undesired access by applying rules ensuring packets reach the desired location. Firewalls can be configured with rules on traffic that is either pre-routed, input, forward or post-routed.

WeOS firewall include five different types of functionality; Input Filtering, Forward Filtering, Network Address Translation (NAT)/Network Address and Port Translation (NAPT), Port Forwarding and Application Layer Gateway (ALG) Helpers. If you would like to learn more about how to configure firewalls in depth, check out the Firewalls tab at WeOS5 Management Guide: Firewall & NAT. This document will focus on a few of these points.

Firewalls are rule based and will order the packets from the top down as the list goes. If a packet does not match the first rule, it will work its way through the list until it meets one that does. Then if not, it will be discarded. This is traditional how most industrial firewalls operate, though can have one minor drawback. If a rule is placed above another that supersedes one below, then a packet will acknowledge that first. This means that if you write a rule to accept all, then have a rule to block it, the packet will take the accept rule first and be processed. It is vital to understand the hierarchy of the rules ensuring that they are in the correct order and packets are accepted or dropped in or out of your network.

Within WeOS5 it is possible to create and configure Firewall rules before it is enabled. This is very helpful when building a firewall since it can be very easy to make the device inaccessible with the wrong rule.

Firewalls have the option to be either broadly configured or very specifically. An example of a broad configuration would be allowing a subnet, whereas a specific configuration could be drop to an IP address(s) and/or specific ports. Firewalls are very flexible and rely on understanding the requirements and desired flow of traffic.

A common industry practice is to enable a firewall with some specificity, with the mindset that the firewall is enabled. Whilst this may sound like a good idea, it does not offer a best practice. You should configure a firewall specifically for the network you are using and should not be afraid of being specific. Industrial networks, especially OT systems, regularly do not change. If they do, configuration is made at an agreed time, with settings being universally agreed before hand.

Here is a breakdown of how each type of firewall rule could be configured to harden your network. We have recommended practices for a general accept and deny input rule, a general limited accept and deny input rule and a general restricted accept and deny input rule. We will then discuss further examples for Forwarding Filtering.

An example of the three different types of input rules are as follows. Rules are not isolated to these parameters and are displayed as examples only.

General Rule: A rule that accept/deny packets with little regard to IP source, IP Destination, Source Ports or Destination ports.
Limited Rule: A rule that accept/deny packets with some regard to IP source, IP Destination, Source Ports or Destination ports.
Restricted Rule: A rule that accept/deny packets very specifically, concentrating on IP source, IP Destination, Source Ports or Destination ports, interface and packets.

Input Rule

An Input rule is for packets that are checked after a routing decision has been made and then applied to the packets. It is for packets that are directed to the local device, with the process running on the WeOS device itself.

WeOS devices implement a default drop policy on all interfaces. This will always be in position 1 and then lowered down the list when other rules are configured. This means that when the firewall is enabled with no other rules implemented, all incoming traffic (i.e input) will be dropped. This is an example of how access to a device can be removed accidentally.

General Rule

A general rule is the most broad. This is a rule that can deny everything, but if the user is only interested in accepting a specific protocol, or a specific interface. For example, an incoming interface could be set to accept all TCP traffic on an incoming interface VLAN1. If any other protocols are trying to enter, i.e. UDP, then it will be dropped.

This would be beneficial as a bare minimum when configuring the firewall, but is not recommended as a hardening parameter for inbound traffic. It will accept incoming packets from secure services such as HTTPS and SSH, both which are very useful management services. However, without additional configuration management services such as insecure services like HTTP would be accepted.

The purpose of a general rule is very useful when you want to start hardening your network, but is not a permanent solution for accepting incoming traffic. Enabling the firewall and working backwards is always the best approach when it comes to hardening your network. You should aim to use the general rule as a starting point and look to achieve more specific ruling such as either limited or restricted. The risk with the general rule is accepting too much through can leave your network open and vulnerable.

Limited Rule

A limited rule is a good middle ground and is fundamental when hardening your device and network. The mindset of a limited rule is for you to take consideration of IP source and Destination, as well as Port Source and Designation. This does not mean that you need to write hundreds of rules for every inbound and outbound packet, but it does mean that you can control which network packets are sourced and destined, along with which ports are sourced and destined.

Here are the three protocols as an example. We want to accept two, and deny one. Within this example network, there are two interfaces: VLAN1 & VLAN2

Service	Destination Port Number	Accept	Protocol
HTTP	80	No	TCP
HTTPS	443	Yes	TCP
SSH	22	Yes	TCP

VLAN1 is 192.168.2.0/24 and VLAN2 is 172.16.1.0/24. We want to accept incoming traffic from VLAN1 to VLAN2. Now a general rule, accepting all TCP traffic would implicitly accept all three, which is not sufficient in this case. This is why we recommended that a limited rule is applied to harden your network.

There are two rules to be configured, both are very similar. One will be identified for the HTTPS traffic and one for the SSH traffic. The rules will be configured to accept inbound VLAN1 to outbound VLAN2, using the protocol TCP. For HTTPS, this will be port 443 and for SSH it will be port 22.

A further consideration would be to add counters to the rules to identify how often this rule is hit. The rule for the ports is important to select either source or destination as well. For a HTTPS and SSH connection, most likely the source should be left blank, with the destination either set to 443 or 22.

There is no requirement to write a deny rule for HTTP, since it will automatically drop all packets that do not match the rule.

One additional measure that can be taken is to create a limited rule for specific port ranges.

Service	Destination Port Number	Accept	Protocol
A	600	Yes	TCP
B	620	Yes	UDP
C	500	NO	TCP

In this case, continuing with the same VLANS are before, you will need to write either one or two rules. One rule could be written to accept all VLAN1 to VLAN2 traffic and then create a rule either a Destination Start and End of 600 and 620. Since the requirement is to accept two different protocols (TCP and UDP), and a protocol should be stipulated to ANY. Whilst this is efficient, it does leave your network open to any protocols accepted between 600-620, on both TCP and UDP. This can limit the likelihood of an incident, but it should be noted.

The other method is to write two rules. Just as before stipulating the protocol (A = TCP, B = UDP), and then only writing the destination start and end for port 600 and port 620. This creates much more limited rule and is strongly recommended to harden your device.

Whilst it is efficient to write start and end source or destination ports, it does leave your network open to possibilities of attack. Take the first example with HTTP, HTTPS and SSH. If one rule was created was created to accept all traffic from VLAN1 to VLAN2, for TCP on destination ports 22-443, port 80 is then accepted through.

Think about how a packet will traverse through the rule listing. If a condition precedes another, or is too vague, then the device will only operate with the information that is configured.

Restricted Rule

A limited rule is not as simple to write as one rule and everything is fine, since it will be too specific. Furthermore, if you need one rule, it will then turn in to two, and with restricted rules, this naturally increases to too many. Note, WeOS devices support 1000 rules.

Expanding on the network from above, we have two devices with the interface VLAN1 on the 192.168.2.0/24 network. One has an End Device A set to 192.168.2.10/24 and End Device B set to 192.168.2.20/24. We want to accept and deny to same three services as before (HTTP, HTTPS and SSH), from interface VLAN1 and VLAN2. This is routed traffic.

In this case, we will need to write a rule for both the 192.168.2.10 and 192.168.2.20 devices, for both HTTPS and SSH. This is now four rules, rather than the original two (with limited). This will also reduce all accepted rules to only these two addresses, rather than the whole network range. This can be stipulated, just as with a limited rule, but this time in the network source and length you will locked as /32 address (limiting it to one IP address). Again, it is important to specify the designation ports and protocols. The destination/length can also be set to either a network address (172.16.1.0/24) or a specific address (172.16.1.10/24).

The restricted rule has its benefits ensuring that only a TCP packet, for HTTPS will be accepted from (source) 192.168.2.10/32 to 172.16.1.10/32 (destination). Whilst this means the list of firewall rules will expand, it provides full control over your network. It is recommended to setup logging as well as generating a comment for future reference. The counter is a very useful setting to include.

It is recommended for a restricted rule to not include a start and end for a source or destination ports along with specifying the exact protocol.

Firewalls take time to configure and require holistic oversight of exactly what is going in and out of your network. In most cases industrial systems do not change, and you should know exactly what is required to be incoming and outgoing on your network. Firewall logs can help identify exactly what is going on accepting you to create rules to either accept or implicitly deny traffic.

With either a general, limited or restricted rules. All packets that do not meet the rule list, will be dropped.

Forwarding Rule

A forwarding rule is much similar to an input rule, however rather than being for the local device itself, it is used to control what traffic is accepting to be routed to connected devices. The WeOS Management guide provides a detailed overview of the difference between an input and forward rule WeOS5 Management Guide: Firewall Guide.

Applying the similar philosophy as input rules, a user should write either a General Rule, Limited Rule or a Restricted Rule.

Packets will work their way through the list from top to bottom, and if they do not match, will then be dropped. Furthermore you do not need to write deny rules, unless specifically required.

Take considerations to harden your network with forwarding rules and input rules similarly. To limit access to the device itself (the WeOS device), use input. To limit access to devices connected to the WeOS device, use forwarding. It is recommended to configure both input and forwarding rules for your network. In most cases these rules would be different, with different protocols configured, servicing different devices on the network.

The main difference for forwarding rules is the inclusion of now both an incoming and outgoing interface (rather than just an incoming interface for input rules). This provides the much more thorough configuration for limited or restricted rules by defining exactly which incoming and outgoing interface to apply the rule too.

Deny Rule

Covered within the Firewall, we have mentioned the use of accept rules, with an implicit deny. This means that any packet that does not match a rule, then it will be denied. However, there is a function built in a firewall to create deny rules. The question is, why then would you need to create deny rules?

One of the purposes of deny rules is for efficiency. You may want to write a limited rule, but specifically deny certain services outbound. Take DNS for example. If an end device is configured with an IP address, subnet and default gateway, it could also have the option to configure DNS. This may not be a feature you want to serve your LAN network with.

DNS uses UDP, port 53. Lets say you have a created a limited rule that accepts all traffic from VLAN1 to VLAN2 outbound, but you do not want to write a specific rule for every device on your network. A deny rule could be created (just like an accept rule), but applying a much more general ruling mindset. A recommendation for the rule could be to deny all outbound traffic, on port 53 using protocol UDP, blocking DNS for example.

Where to place Firewalls on the network

There are many options in where you should place a firewall in the network, with either a centralised or a decentralised approach. A centralised approach is where your gateway to the untrusted network is the firewall for all traffic in and out of the network, where as a decentralised approach is where every device itself is in essence a firewall, and there is no single "centralised" firewall.

It is vital and recommended to have the firewall enabled. Whether or not you use a centralised or decentralised firewall is dependent on the network that you have in place. The benefits of a centralised firewall means that configuration is conducted all in one place, and in fact this could be on two (or more) devices using protocols such as Virtual Routing Redundancy Protocol (VRRP). This also means that you can log all traffic in and out of your network on those two devices. The limitation of a centralised system is that all firewall routing is conducted on those select devices, and also it means that one device has to catch everything. If a firewall rule is too vague, or open to exploitation, bad actors could access your network or outbound traffic that is not supposed to reach untrusted networks could leave.

A decentralised firewall has many benefits, with one being no single point to catch all inbound and outbound traffic. A packet could traverse the main firewall (to and from the untrusted network), and then be caught within the trusted network, which could have more specific rules. This also allows a much more effective and efficient system for Intrusion Detection and limit the spread of a threat if one happens.

Selecting the location to install your firewalls is an important step in the design phase. One could invest in devices that support Firewalls and not have this function enabled until required. Investment in your products is a good first step in to understanding how to design your network at a later date.

NAT Rules

WeOS devices can be configured with either stateful NAT (NAPT) or Stateless NAT (1-to-1 NAT). This guide will provide recommendations to harden your device for NAPT.

A NAT rule can be configured much like a firewall rule, following the philosophy of either a general, limited or restricted rule. Rules are not isolated to these parameters and are written as examples only.

General Rule: An outgoing interface is configured for all traffic, regardless of the source.
Limited Rule: An outgoing interface is configured for one network.
Restricted Rule: An outgoing interface is configured for only one source.

Network Address and Port Translation (NAPT)

Network Address and Port Translation, as known as NAPT, rules apply after the routing decision and are also known as IP masquerading. NAPT accepts a common (public) IP address to be shared by a set of hosts on a (private) network. For a more detailed example see the WeOS Management Guide: Stateless NAT Guide.

When a packet is destined to leave a network from a LAN to a WAN, especially to the Internet, it must use NAPT. NAPT accepts for multiple devices on the same LAN to use the same IP address when outside for the network. This is a fundamental rule for how the Internet works today, accepting for billions of devices to be interconnected, with each of them restricted to using very similar LAN networks. This is only applicable on IPv4 networks!

The example network to apply the rules has two VLANs, VLAN1 on 192.168.2.0/24 and VLAN2 which has a public IP address of 80.0.0.1/24. The Public IP address is provided by an Internet Service Provider (ISP) and is dynamic. There are two end devices on the network set to 192.168.2.10/24 and 192.168.2.20/24

A IP packet has a source and destination IP address. NAPT will masquerade an IP source address enabling a return of the packet when it is distributed outside of the LAN. A packet from an end device will masqueraded its source address from 192.168.2.10, to 80.0.0.1, when it is forwarded from the WAN interface (VLAN2 in this case). On return, the WeOS unit will lookup where this packet is sourced from (and not destined), and then change it back to the original IP address of 192.168.2.10. This can happen with simultaneous devices, on the same device by using random source ports.

NAPT must be used when accessing an outside network that is not trusted. It can help prevent inbound connections along with correctly configured filter rules.

General Rule

A general rule, much like an input or a forwarding rule, can cover a lot with very little configuration. NAPT rules are very simple to configure, with the option to define an outgoing interface, a source address along with a comment and logging.

For a general rule, an outgoing interface must be configured. No source address, comment or logging is enabled.

A general rule is not recommended as a permanent solution to harden your network.

Limited Rule

A limited rule is a preferred solution and recommended to harden your device. This provides much more control over your network, especially in cases there are other networks on the same WeOS device. Just as creating a general rule, the outgoing interface must be configured. This time, configure a source address of 192.168.2.0/24 and enable logging as optional.

Defining an outgoing interface and a source address provides much more control over exactly what traffic is accepted out of the trusted network.

A limited rule is recommended to harden your network.

Restricted Rule

To further establish control over your network, NAPT rules can be sourced to one specific address. Much similar to a limited rule, but this time specify exactly which address to use. For example, set the source address to 192.168.2.10/32. It is advised to enable logging.

For restricted rules, you must write one for each and every end device. This is one of the main benefits, since (with the example in mind), you may only trust 192.168.2.10/32 to be accepted out and not 192.168.2.20/32.

A restricted rule is recommended to harden your network.

Virtual Private Network (VPN)

A Virtual Private Network, known as a VPN, a service used to ensure that data is secure and private on untrusted networks. This would be between two (or more) sites, especially ones traversing networks such as the Internet.

WeOS supports different protocols for VPNs, one being IPSec and the other SSL. Both have there pro's and con's and within in these guidelines we will provide recommendations for which one to choose. This does not mean that you must change your whole system to use one, though the recommendations is based on why one offers more benefits than others.

VPNs provide the ability to protect how traffic communications logically. They can provide point to point communication along with redundancy for more complicated networks. There are some limits in what VPNs can achieve, and do offer an overhead when it comes to processing traffic.

The purpose of a VPN for industrial applications could be for remote access solutions, or localised connections (i.e., the same physical network), however the importance of it is to secure traffic between Point A and Point B (and even Point X). Potential threats from bad actors, who could potentially monitor and in the worst case, intersect and tinker with traffic during transmission is reduced with the introductions of VPNs.

An example of where VPNs and could reduce the potential threat from an attack is when a serious weakness was discovered with WPA2. This exposure was known as Key Reinstallation Attacks, KRACK. Broadly speaking, the vulnerability exploited that during transmission of traffic using Wi-Fi, a bad actor could intercept the communication by pretending to the be the Wi-Fi Access Point. Once they are "man-in-the-middle" between the end user and the access point, they would then strip secure protocols of forwarded data and monitoring communication to and from a server. The example used was stripping HTTPS traffic and forwarding it as HTTP traffic, and then intercepting the communication (that the end user thought was secure), easily viewing data information such as username and passwords. In 2017 it was very common for web servers to still use HTTP, as well as HTTPS, with no browser recommendation to prefer more secure services. If you would like to more about KRACK, check out krackattacks.com.

A VPN would immediately prevent this from happening since the end user would send encrypted traffic via the man-in-the-middle (MitM) to an end point. Even if it they used HTTP, the MitM would not be able to view the information. This does not mean that the WPA2 did not required to be resolved, but the potential of another exposure not yet being discovered is incredibly likely. Therefore, practices such as VPNs can eliminate even if your equipment and network is exposed.

We recommend implementing a VPN to harden your device and network in relevant locations.

SSL or IPSec?

There are two different protocols that can secure traffic on your network, IPsec or SSL. We recommend using a SSL to harden your device with.

Secure Socket Layer, known as SSL, is a VPN protocol and compatible with OpenVPN. It uses certificates to establish connections between point-to-point, point-to-multipoint or multipoint-to-multipoint networks. Thanks to the ability to use certificates, it is very efficient to communicate traffic securely and provides manageability of the network. If a certificate becomes compromised, it can be revoked (quickly) and updated to remove the potential damage to a minimum.

Furthermore, SSL has the ability to routed and firewall since it appears as an interface. IPSec does not appear as an interface and additional configuration of other protocols such as GRE must be in place for it to be. SSL also is more scalable and provides much more manageability also.

Within WeOS, there is the possibility to configure SSL VPNs using OpenVPN LAN Bridging (Layer 2) and OpenVPN Host to LAN (Layer 3). The latter is possible to configure over a Layer 2 network, but enable firewalls on the interface. See the WeOS Management Guide: OpenVPN Guide for detailed information on configuration with examples.

OpenVPN LAN Net-to-Net (Layer 2 VPN)

Layer 2 networks define traffic that is destined for the same network, rather than for an external network. With traditional VPN protocols such as IPSec, this is not possible. The LAN on Device A, must be different to the LAN on Device B. With OpenVPN, it is possible to have the LAN being the same on both Device A and Device B. Assuming the network is configured to support this functionality, SSL will appear as an interface within the firewall and will communicate traffic over the network.

Following the hardening recommendations for packet filtering on a Firewall, a restricted rule is recommended to harden your network with SSL. This setup is also includes that NAPT is configured with either a limited or restricted.

For packet filtering, rather than using VLANs for the incoming and/or outgoing interfaces, you will select the SSL instead. This will behave exactly the same as a if a VLAN interface was selected. A restricted rule is recommended to help ensure that only Device A LAN will communicate with Device B LAN. For example, if the SSL VPN used 192.168.2.1 for Device A and 192.168.2.2, a rule can be created to only accept these two addresses using the /32 netmask. Additionally this can be tightened by limiting to protocols such as ICMP (Ping) as an example. A further recommendation for TCP or UDP, is to the limit the source and designation ports is possible.

OpenVPN Host to LAN (Layer 3 VPN)

Much similar to how IPSec operates with two different LANs located at two different locations, SSL provides functionality and support. As discovered in the document, IPSec is not recommended to harden your device with, due to limited support with firewalls and routing capabilities. This is where SSL becomes a powerfully protocol.

The main difference between a Layer 2 VPN and a Layer 3 VPN is mostly how the traffic is routed. With a Layer 2 VPN, both sites will have the same LAN and may use DHCP to share that address. With Layer 3 VPNs, both sites are required to have different IP addresses. This extends the ability to route traffic securely between different networks, create a good security posture for your network.

Following harding recommendations for packeting filtering for the Firewall, a restricted rule is recommended. Make sure that you set both the source and destination address if possible and limit the traffic to specific devices. Not all traffic on from every device may need access through the SSL VPN.

Conduits and Segmentation

Networks and systems should be divided up and segmented to ensure traffic is correctly destined, rather than just having a flat network where everything can communicate with each other.

To ensure devices communicate only with the desired recipient, it is recommended to create conduits. A conduit in networking terms is much similar to one that is found in a building. It is the point between different pathways, between devices, in which data travels. This can include the media itself such as the copper ethernet, fibre, or any other medium that Westermo products support.

Create a physical infrastructure via conduits are vital to protect your network. For example, if a redundant network is created and all cables are connected through the same conduit (this is including the primary and redundant cables), and that conduit is damage, in most cases, you would lose access to many devices on the network. This would mean the physical redundancy is redundant (meaning that it is completely useless). Conduits, especially for redundancy are a vital backbone to ensure communication remains consistent. Cables should run in separate and independent physical conduits between devices. We recommend creating a reliable and well planned physical network incase of a local incident such as fire, or physical tampering.

Segmentation itself is complimented by conduits. When the network itself is physically and correctly installed, the network is recommended to be segmented as well. Segmentation divides the network in to smaller, more efficient, and appropriately sized chunks to ensure that traffic is correctly destined and received. This is not only important to manage the network and the system with, but it also makes it much harder for erroneous and malicious behaviour.

To segment a network, services such as Virtual LAN (VLAN) are vital. Whilst VLANs do not offer true security segmentation without correctly configured firewalls, they do offer a method to separate traffic from each other. Take an example network with three different requirements on the network: CCTV, Management and PLCs. There is no case where all three of these services should on one VLAN, which unfortunately, is very common in OT networks. Firewalls become very difficult to configure in these circumstance and networks are not protected from broadcast storms either. Additionally, if an intruder gets access to the PLC network, they then will have access to everything.

One of the best ways to segment the traffic is to use different VLANs. For example, VLAN10 for CCTV, VLAN20 for Management and VLAN30 for PLCs. This means that in the worst case that an intruder gains access to the PLC network, then with the correct firewall configuration, they will be isolated and segmented from the rest of the network. Other features can be removed such as management services can also be limited and restricted too with the use of VLANs.

With different VLANs and firewalls, network traffic can be isolated from each other. For example, if a packet on the PLC VLAN is required to be transmitted to the management network, then a limited or restricted rule can be created to only allow this to happen. This could be complimented both with decentralised firewalls (one on every device), ensuring that your network is safe and efficient.

We recommend using physical conduits and segmentation on your network. Conduits and installation recommendations can be found in the product guide example and segmentation configuration can be found in the WeOS Management guide for VLANs and Firewalls.

Confidentiality

The CIA triad is well recognised information security practice, specifically defining a risk management for digital information. The three equal parts are Confidentiality, Integrity and Availability. The hardening guidelines itself is loosely based from the three pillars.

When it comes to OT networks and systems, the integrity and availability of data are critical. Take Stuxnet for example. One of the main threats behind this attack of the Iranian nuclear program was the integrity of the data. Broadly speaking, due to the malicious software, the SCADA was receiving incorrect and different data that was distributed to the PLCs. The PLCs were being told to increase the speed of the centrifuges, where the engineers were being informed that the turbines were operating normally. Regardless of the data's confidentiality (whether or not it was secure), the integrity of the data was compromised.

Furthermore, the availability of data is just as important. Take a system supplying energy to a city and there is a power cut. As the provider attempts to bring the system back online and data is not received, then this would become an impossible task to conduct remotely and autonomously. This scenario could be equally vital for track side networks, water and wastewater, just to name a few.

The confidentially of data does however apply as a subsection of security. The question should be asked to what extent. Should you encrypt all data, some data or none at all? There is no one answer and this is entirely down to how your organisation will implement information security. We recommend that you implement some information security measures to ensure the confidentiality of your data. This could be via a VPN and especially and strongly recommended if your system operates over an untrusted network.

Why would you not encrypt data at all? One the main reasons behind this based on trust and full awareness of your network. If the system and network you operate is completely private and owned by your business, you may make the assumption that no one should ever gain access. This is of course with many other measures in place such as firewalls, VLANs, etc. Additionally, the information being transferred could not be vital, or of any actual value to a bad actor. If a PLC is transmitting a time based value, say when a stop sign is red, if the hacker is to obtain this information, they would only know that the stop sign is red at that moment or a moment in the past. The data that they obtain would also be amongst many other values and must be reference with prior knowledge of the system (for example, how does a hacker know that a 1 means a red stop light in a long line of data?). Though, we do not recommend that no confidential data measures are taken.

When you encrypt only some of the data, which in this case could be very important data that must always be kept private, and then leave some unencrypted, it provides a very good foundation for a system. If a hacker was to break the encrypted data, you would know immediately what has been compromised. This is one the benefits over encrypting everything. By only securing data that needs to be secure, you gain oversight and the ability to determine differences in the system rather than playing a guessing game to what has been exposed. We recommend implementing a measure in place to partially encrypt your network.

The advantage of encrypting all data traffic is simplicity. This is no need to separate traffic at source, and one could limit the amount of VPNs and segmentation in place. There is no need for an unencrypted data segmentation and encrypted data segmentation. This is especially important when you have a large complex network of many devices. We recommend implementing a measure in to place to encrypt all data.

The recommendation is based on the requirement of your network and organisation, however, as highlighted, it is better to implement some, rather than none.

Secure Boot

For Secure Boot there are more embedded and anchored steps in place. On the surface, secure boot is a step up from software signing, with extra layers to establish more security features.

When a WeOS package is generated, there are many complex steps in the procedure. The very first part of software signing via digital signatures is to establish two keys, one public and the other private. The private key here at Westermo is kept incredibly secure, with very few people who have permission to review it, let alone know where and how it is stored. The process of protecting the private key itself is complex by design, ensuring the integrity of the key itself is to remain intact.

The public key itself is available on request, and is considered public information. This is how public and private keys work and ensures there is integrity of services such as Internet as we know it today.

When a version of WeOS5 is generated today, it is digitally signed. The WeOS file itself is hashed, using a 256 bit hash, to create a digest. This Digest is then encrypted using the secure private key (that only few have access too), to create a digital signature. This is all an internal process and is simplified for the case of this guide.

When the firmware is downloaded and installed on supported device, there are several steps taken to ensure the file is trusted. Firstly, the WeOS .pkg file is verified against the public key and another digest is created. It is then compared against the original digest, with the digital signature, and decrypted with the public key to create a second digest. These two new digests are then compared together, within the WeOS unit itself, to ensure the integrity of the file. If there is integrity, then proceed with the update, if not, reject. Note that a rejection can in fact prevent the device from operating in the future.

Secure Boot helps establish the chain of trust and in place to ensure integrity of the file and the device hardware. With a series of public and private keys there is a process of validation. Here is example of the chain of trust. Imagine there are two keys, public and private 0 and public and private 1. The process of the chain of trust starts with the hardware, then the bootloader, then WeOS itself.

Firstly, the hardware, with public key 0, validates and signs the bootloader. The bootloader will validate against private key 0. It then uses public key 1 to validate and sign WeOS with the private key 1. This step is repeated, where WeOS can validate against further keys such as public and private keys from customers for container applications.

Secure boot itself coincides with the chain of trust to ensure that only validated, approved and verified WeOS versions can be installed on the device itself. If an update is required, a new private and public key is created and the process is repeated. If they do not match, then the device will reject the update. Secure boot will alleviate the need for validating the integrity of a WeOS package file. Even if a WeOS .pkg file is left for many months stored on a computer or sent to you from an untrusted source. Simply, if the file is not approved, it will not work.

Network Services

On a network, there are several services that provide multiple devices with IP addresses or access to the Internet. These are DHCP and DNS. Dynamic Host Configuration Protocol (DHCP) is a UDP protocol that provides the network with IP addresses. These can either randomly assigned on request, or assigned per MAC address or on a per port basis. Domain Name Server (DNS) provides devices on the network the ability to resolve IP addresses to words, and is common practice to use the Internet.

Both of these have pros and cons and without the correct configuration can potentially be a huge security risk. It is sometimes argued that DHCP should never be enabled, however with many customers in the rail industry, DHCP provides a critical service to enable systems to operate. DHCP, with option82 enabled provide the option to specifically provide an IP address on a per port basis. This means that any device that connects to a specific port will receive an IP address. This does highlight a potential risk, but in collaboration with a firewall can help reduce any threat to have no impact on the network.

DNS provides the ability for IP addresses to be translated to text (and vice-versa) is critical for devices to access the Internet. This could be a specific website, or a remote server. DNS provides the ability for devices on the internet to have no fixed IP address, though have a fixed URL for access. DNS should never be used by default, and strongly recommended to be used with a firewall, however if this service is needed measures must be taken.

Both have there benefits and risks, which we discuss in the following sections.

DHCP

Dynamic Host Configuration Protocol (DHCP) is enables end devices to receive IP address from a central server. More than one DHCP server can be configured on a network and a device, using VLANs or services such as DHCP-relay and Option82. DHCP is very common for on-board rail applications, though it does have uses for other industrial applications.

DHCP uses MAC addresses to receive and supply IP addresses to end devices. When a DHCP server is configured on the network, and a devices are set to request an IP address from a server (i.e, dynamic configuration and not static), there is a process in place. Firstly the end device (which does not have an IP address), will request from a DHCP server (which does have a IP address as well other options configured), that it would like an IP address. The Server will then respond to the end device with an IP address assuming it matches the criteria (i.e., is there IP addresses available). This can sound like a huge security risk since it enables any dynamic end device to request an address, and in fact it is. However, with some specific configuration and collaborative configuration, you can keep your network secure.

The reason for some industrial applications requiring DHCP is easily displayed for systems that are designed with replaceable end devices. For some on-board systems, for example, a DHCP server is established on the network. Devices, such as cameras, are usually very basic and have limited functionality. They may get damaged during their lifespan and need to be replaced with ease. If this end device was configured with an IP address, it would be mean that when one is replaced, that one must be configured with the same IP. Whereas, with DHCP, this is removed. This one helps reduce cost, but also enables the system to be much more fluid with further system configuration.

DHCP servers have many options that be configured and are supplied on request. These are known as, rather simply, as "options". Within a DHCP request packet, a client will ask for Option x, y, z, and the server will supply them. If they are not available, they will not. Options could be a subnet mask, default gateway, dns, lease time, etc. These are all configurable on the server and made available to the client.

With this in mind, the server can be configured with very limited options to ensure that only specific configuration is given to end devices. This could be a very specific lease time, default gateway, etc. Further options include using DHCP servers to provide static leases to specific MAC addresses. Therefore only approved devices can receive an IP address. The most common use for this application is maintenance laptops or limited use access (i.e., patching, troubleshooting, etc.).

One of the main risks with DHCP is configuring a pool. A pool is where the DHCP server will lease IP addresses within a specific range on any request. It is recommend to not use a pool option, rather to implement a static lease structure or DHCP Relay.

We do not recommend using DHCP unless there is a specific requirement for it. In the case that you do require DHCP, we recommend using Static Leasing or have measures in place to reduce the likelihood of an unknown device receiving addresses.

DHCP servers should be configured in collaboration with a firewall. Firewalls enable very specific rules to be placed on specific IP addresses to either limit or restrict access. If a device is only requiring HTTPS access, then a firewall, with DHCP, can allow only a specific IP address to use TCP port 443 for example. We strongly recommend any use of a DHCP server to be in collaboration with a firewall.

Ensuring that your end device has access to the network provides a foundation for availability. It means that you do have not have to configured every end device with a static IP address and allow the network itself to have some control over access on request. DHCP is a very powerful protocol when used correctly.

DNS

Domain Name System (DNS), known commonly as the phone book of the Internet, enables IP addresses to be translated to and from text. This enables anyone and anything to use the Internet today, and for a web page or server to be located in multiple locations at once.

The purpose of DNS is only for IP translation. If your network does not need to access the Internet, or if it has access to the Internet and only needs to connect to a specific server on a specific IP address, do not enable and configure DNS.

If your network requires access to non-specific servers (www.westermo.com) for example, then you must use DNS. This is especially important when it comes to using services such as WeConnect.

DNS is recommended to be used in limited cases specific to your network requirements. We recommend ensuring that DNS is not set by mistake and is not supplied by DHCP if unnecessary.

Redundancy

For redundancy, the physical network is as critical as the logical network. WeOS controls the logical network using very specific protocols that have been designed to ensure that if an incident would happen on the physical network, then the logical network will react.

There are two different types of redundancy that be configured in WeOS. Layer 2 redundancy, common practice for switched networks and Layer 3 redundancy, common practice for routed networks. The main difference between the two is topology arrangement and failover time (i.e., convergence). Layer 2 redundancy protools react in milliseconds (tens of), whereas Layer 3 redundancy protocols will react in seconds (likely tens of).

There are a few Layer 2 redundancy protocols that are configurable within WeOS devices such FRNTv0 and FRNTv2, RSTP and MRP. Additionally, LACP can be considered a Layer 2 redundancy protocol. For routing, which are not specifically designed as redundancy protocols but provide the feature, WeOS supports OSFPv2 and RIPv2, along with VRRP.

There is not a focus specifically on the protocol itself, where more can be found with the WeOS Management Guide, however this section looks at how they operate and provides recommendation for topologies and best practices.

Layer 2 Redundancy

Layer 2 redundancy specifically uses protocols that operate on the same network. This provides a foundation for networks that use VLANs, especially VLAN tagging. They provide very quick failover times, in the tens of milliseconds, enabling the most effective backbone for critical network availability. Protocols such as FRNT are proprietary to Westermo, meaning they are only compatible on our devices. We support other protocols such as Rapid Spanning Tree (RSTP) and Media Redundancy Protocol (MRP).

There is no recommendation in which protocol to use, however each offer benefits specific to the physical topology. For example, FRNT is a designed for ring topologies, RSTP supports both mesh and ring and MRP supports rings. RSTP and MRP are compatible with multiple vendors, with MRP being supported through licences. Link Aggregation, via LACP, is also non-proprietary, however we recommend using LACP on two Westermo devices rather than two different vendors.

In this section we will focus on ring topologies with FRNT and link Aggregation with LACP. RSTP can be used for a ring topology, but failover time is much less (slower) than FRNT.

Rings with FRNT

A physical topology of a ring, where there is a loop around the network is not only bad for networks, but has critical implications on network availability. A physical loop is a the forefront of a broadcast storm that can bring a network to its knees in a matter of minutes rendering it unusable, yet why is it so important to have a ring for redundancy? This is due to the collaboration with the logical topology and protocols such as FRNT.

WeOS are compatible with both FRNTv0 and FRNTv2. FRNTv2 is a leap forward in the terms of scope and flexibility from FRNTv0 and is the recommendation for and Layer 2 redundant network. FRNTv2, which we will refer to as just FRNT, enables loop free topology on a layer 2 ring network.

Devices are configured as either a member, which are part of a FRNT topology, or a focal point, which is the leader of the ring. Ports are either unblocked, meaning it will forward all traffic inbound and outbound, or a blocked, where no traffic is forward with the exception of any FRNT related packets. Every 100ms a hello packet is transmitted between every FRNT node along with the physical interface of each port being monitored as well. The Focal Point will block one port, designated by user configuration, to ensure that the network is physically a ring, actually operates as a bus.

In the case of an incident, say a cable is broken and or a device has an unexpected shut down (this could be either intentional or unintentional), the focal point will react within tens of milliseconds ensuring the network is up and running as quick as possible. It will achieve this by alert all of the devices of the change and unblocking its blocked port. This provides the network with availability enabling critical infrastructure to communicate, especially in the times of crisis.

The purpose of a ring is to ensure availability and with FRNT this is possible. An additional feature is the ability to self-heal the network and recover the network back to an operational state. A Network with a fault is not a healthy network. Something has gone wrong. This could be due to the possibility that this has been caused by an external threat, or an accidental one. If it was intentional, measures must be in place to ensure the damage is a minimal (many highlighted in this guide). However, if the cable was removed by mistake or a device unexpectedly shut down, then the network has the ability to recover and self heal.

The FRNT focal point will periodically send hello messages around the network, and once it receives the all clear, will alert the rest of the network that everything is ok. It will then place the unblocked port back to being blocked to prevent a broadcast storm and enable communication and network availability. There is a risk with slower redundancy protocols to accidentally create a loop causing a broadcast storm.

RSTP does support ring topologies, however there is one major factor that sets FRNT and RSTP apart. FRNT will send periodic hello messages around the network and will then ensure that all members, and the focal point, will clear their MAC tables to relearn the network and ensure traffic is not lost. Though, somewhat similar to RSTP, which sends heartbeats around the network, FRNT has one additional measure. It is aware of the port state.

The port state, which FRNT is only interested in the two configured ports, is the electrical state of the port. If a cable is connected, a port is qualified as UP and if it is removed, then it is qualified as DOWN. FRNT will monitor the port status and will react to the millisecond if it changes (i.e, a port goes from UP to DOWN). This enables FRNT to react incredibly quicker to unforeseen issues on the network, much more than RSTP that relies on heartbeats. RSTP was developed for IT networks and has slowly been introduced in to the OT sector, where FRNT has been designed from the ground up as an OT protocol.

A ring is important to availability because it provides the ability of failure. The larger the ring, the more risk of multiple failures (i.e., two cables removed or devices reset). To achieve maximum redundancy, rings should be as small as possible. If you have 10 devices, the ring could be broken down in to two rings with 5 devices, and then coupled together using Ring Coupling (RiCo).

Ring Coupling, along with FRNT, provides the ability to create redundant links between rings. The more links you have in place, the less likely of a single point of failure, ensuring availability of a network is designed from the core. There is no limit to the number of devices in the ring, and no limit to the number of coupled rings. The limitation of RiCo is how many connecting devices there are between the rings.

We strongly recommend designing networks with a ring topology using protocols such as FRNT and RiCo. These provide the maximum chance of network availability in the unlikely event of failure. With the ability to self heal and react in a instance, provides a foundation for your network to remain available and secure.

Aggregation with LACP

Link Aggregation is the ability to aggregate two or more physical ports within the same logical link. For example, Eth1 and Eth2 become lag1. This immediately provides a method of redundancy since you now have two cables instead of one. Since Eth1 and Eth2 both have a MAC address, connecting these cables between two devices will cause a broadcast storm. With link aggregation they now become lag1, which now enables Eth1 and Eth2 to use a new MAC address (only 1) and ensure a loop is not possible.

Link Aggregation uses a protocol called LACP, which between two devices, establish a partner and an actor. The actor will be in charge of the link ensuring that it is healthy, if not then block the link. Just the same as FRNT, LACP will block ports if there is a risk of a loop, but will unblock ports if everything is healthy. The main difference is that LACP will unblock all ports between devices which are part of the same aggregate (lag1 for example).

An additional feature is increased bandwidth between the two devices configured with LACP. If each physical link qualifies as 100Mb, then effectively with two ports you have 200Mb. This can help increase bandwidth over the whole network assuming further configuration and support for higher data rates.

LACP supports up to 8 Ethernet ports per each aggregate, which is unnecessary in almost application. It supports both Fibre and Copper Ethernet in the same aggregate, which is especially important for media diversity. When required, we recommend implementing link aggregation using LACP with at least two physical ports that are either Ethernet, Fibre or a mixture of both. It is strongly advised to not use different media with different speeds (i.e., 100Mb copper ethernet, and 1Gb fibre).

LACP itself has a built in mechanism to ensure the network remains available during an incident. A logical LACP link is considered UP if one or more of its member ports are UP. It is considered DOWN if ALL of its member ports are DOWN. For example, you have created an aggregate with Eth1, Eth2 and Eth3 and connected two devices both configured with LACP, lag1. Eth1, Eth2 and Eth3 are connected to the same ports on the other device. The devices both report lag1 is UP and communication is possible between end devices. Now let's say that Eth1 is disconnected, will Eth2 and Eth3 stop communication between devices? No, in fact LACP handles this very nicely ensuring your network remains available during the event of an incident. If Eth1 is removed, lag1 is in fact the logical method to communicate between devices, and Eth2 and Eth3 will handle the communication within that aggression.

One of the main reasons that aggregation provides availability for a network is by providing more than one connection between two devices. As with ring topologies, the more redundant paths you have, the less likely of impact in the case of an incident.

Link Aggregation and Rings

As we have discussed, introducing Layer 2 redundancy protocols such as FRNT and LACP are is highly recommended. However there is a further step to take and we recommend considering if you want to increase redundancy even further.

Link aggregation with LACP enables two or more physical ports to act as one logical port, lag1 for example. FRNT enables logical ports to be configured part of a ring, which means that they can use aggregation ports as those logical paths.

Take the example ring of four devices. Before with FRNT we used a port connecting from one device to another to make a ring, say Eth1 and Eth2. With LACP, you can aggregate those ports in to lag1. You will further need to create lag2 with two (or more) ethernet ports to create the ring. When configuring FRNT within a ring topology you select both lag1 and lag2 (rather than Eth1 and Eth2).

A ring is now established with at least two physical cables connected between each device. LACP is controlling the aggression, and FRNT is controlling the ring. If one port of the LACP link is disconnected, FRNT will not react, since the aggression is still consider as UP. Both cables must be removed for FRNT to react.

This naturally increases the availability of a network since there is now additional layers of a physical and logical topology. With true design and implementation of conduits (i.e, separation of cables), a network can handle multiple attacks at once and still remain available.

The implementation of either LACP or FRNT is strongly recommended. If you want to further harden your network, it is recommended to implement both together.

Layer 3 Redundancy

Layer 3 redundancy adds a layer of complexity of networks, however there is much more flexibility on offer when compared to Layer 2 networks. The reason is due to the ability for traffic to leave network and also have multiple paths to the same location. The function, just as with Layer 2 redundancy, uses VLANs to isolate networks from each other.

To route between different networks you need a device with routing capabilities. This is indicated by a feature within WeOS and is defined by which product you purchase. Take the Viper-3520-T20 for example. This product is a part of the Viper-3000 series and is available in two versions, Non-extended and Extended. The Non-extended is only Layer 2, and does not include services such as firewall or routing protocols such as OSPF. The Extended, which is identified with a -E within the name (Viper-E-3520-T20) offers Layer 3 functionality such as a Firewall, NAPT, OSPF and inter-VLAN routing.

Routing enables the ability to create complex networks that can span over a large geographical with the ability to have multiple paths to the same location. Additionally, the risk of the physical topology causing a broadcast storm can be reduced with efficient subnet management. To route traffic you must use a routing protocol such as RIP (Routing Information Protocol) or OSPF (Open Shortest Path First).

The two types of routing protocols available are Distance Vector and Link State. RIP is a distance vector protocol that bases decisions of where to route traffic based on information shared between their neighbours of their entire routing table. OSPF is a link state routing protocol that bases decisions on where to route traffic on information about networks that are directly connected too, which is broadcast to other OSPF nodes.

Link state protocols are much more efficient and scalable as the network grows, which is why OSPF is much more of an effective protocol to provide network availability. Additional, OSPF has measures to encrypt messages between nodes to reduce the likelihood of a man in the middle attack.

Multiple Paths with OSPF

Open Shortest Path First (OSPF) networks can be configured in a complex network topology. This topology can be setup to have multiple paths to same the destination, or multiple paths to multiple destinations. OSPF, the protocol itself, will decide which is the most "shortest" path based on a few metrics such as bandwidth and cost.

Broadly speaking, the cost is the sum of all device metrics between Network A and Network B. For example, if you have several devices between Network A and Network B, the path cost would add all these up together. If there is another path that is less than the (shorter) than this path will be the preferred route. And if it is greater, then the original path would be selected. This is what makes OSPF dynamic and for it be utilised in self-healing and redundant networks.

Cost is not the only metric that is important in OSPF, though it provides a vital tool to enable multiple paths.

OSPF, just as FRNT, is a protocol that provides the ability to manage, maintain and execute complex topologies to ensure network availability. This is especially important if your network is to be routed and with firewalls. Creating a complex network with routing protocols offers the same ability as Layer 2 redundancy protocols, but with much more options to dictate how network traffic traverse across the network.

Without diving too much into the detail about how OSPF is configured, imagine a system with several WeOS devices, each connected to each other, and each with local networks attached to them. Every local network is required to communicate with each other, with no preference with how they do. The only rule is that it must be the shortest path. This is where OSPF becomes very powerful.

OSPF is required to be configured on all devices that are part of that OSFP area.

Master and Backup with VRRP

Virtual Router Redundancy Protocol (VRRP), is a protocol that enables networks to have multiple redundant gateways, with one virtual gateway being shared amongst all end devices.

The main purpose is to ensure that all end devices that require traffic to leave the network (i.e., routed), can have a simple and single gateway configured, with the network owning the configuration in the background. Since most end devices cannot have multiple default gateways configured, VRRP provides a virtual IP address to set. This virtual IP address is then shared on compatible and configured WeOS devices to share ownership of who is the Master and who is the Backup.

VRRP nodes, as discussed, are either Master or Backup. You can have one Master on the network, with several backups ready to take stage in case the Master fails. The master unit is usually your primary method of communication to the outside world, with this link being considered the most reliable and stable. The backups follow the same philosophy, but may be on slower or more expensive services to only be used in the event of failure.

VRRP nodes will communicate with each other to determine who should be in charge (i.e., the master) and who is not (i.e., the backup). They use metrics to establish this, which is a numerical value determined by the administrator. Additional measures can be taken to drive this factor such as alarms, or digital inputs to increase or reduce the priority (and thus determining who the master and backup).

A network with VRRP is recommended in certain cases and relies on a solid and logical and physical infrastructure. Rather than having one gateway, you now have two (or more), which means that the physical network should not have a single point of failure. Nodes must be connected in the network and information that is important for each end device must be distributed. Albeit that the end device does not know about changes with VRRP (and is not to bothered about them), they must be able to communicate with the new master is more to the point.

VRRP in the context of security is much similar to FRNT and OSPF. A network that has a foundation of redundancy, i.e., multiple paths, virtual gateways, etc, provides the structure for security to be layered on top. If a bad actor targets the master, the backup unit (or several others) can take its place cause the least amount of damage to your network.

Since VRRP is just a networking protocols, it can be configured in collaboration with FRNT, OSPF, VLANS, Alarms etc. Building your network with multiple paths, conduits, segmentation and then utilising multiple devices with a virtual gateway via VRRP is strongly recommend.

VLANs

Virtual Local Area Network (VLAN) is an isolated broadcast domain that enables the ability for traffic to communicate within a single logical network infrastructure. The context of it being "virtual" means that is does not have to physically exist (i.e., cables). though it will do logically (i.e., on the device itself). As with a Local Area Network (LAN), a VLAN enables communication between end devices and networking equipment. This can be either on the same network (switching) or on different networks (routing).

Switches and Routers support many number of VLANs, where multiple different networks can exist, logically, on the same device. A VLAN itself carries a unique identifier (VID) to enables the ability to tag traffic for more oversight and expandability of your network.

Within a flat network, traffic within VLAN1 cannot communicate with VLAN2. When you introduce routing, then traffic can communicate between different VLANs. A Switch can have multiple VLANs on one device, but they cannot communicate with each other. A Router can also have multiple VLANs on one device, but they can communicate with each other (subject to configuration). WeOS products support both switches and routing. Devices with routing capabilities are defined by a -E (Enhanced) (i.e., Lynx-3510-E).

Designing a flat Layer 2 (L2) network with one VLAN and many devices is not recommended. Not only is there a risk of broadcast storms, but not all devices should be on the same network (i.e., PLCs, HMI's, SCADA). A flat L2 network removes the ability to firewall and can lead to the risk of a much large exposure. If an attacker gains access to a flat network, then they will have access to everything. This is where VLANs contribute to segmentation of a network.

Take the example of three different types of devices on the network; PLCs, HMIs and Management. You expect all PLCs to communicate with each other, all HMIs together and each device to have local management access. There are four PLCs, HMIs and WeOS devices, which are only switches. As highlighted, having all these devices on the same network (i.e., VLAN1) is strongly not recommended, so the preferred option is to separate each of these on three different VLANS. VLAN10, VLAN20 and VLAN30, one for HMIs, PLCs and Management respectively. These are now each logically separated from each other. If an attacker gains access to VLAN10, then they do not have access to VLAN20 or VLAN30.

Though this is where the physical infrastructure plays a role with the logical structure. We are going to assume there is some redundancy in place controlled by a protocol, but that is not important in this section. VLANs can be either tagged or untagged. Tagging enables VLANS to add a tag, the VLAN ID (VID), within the packet. It enables communication of multiple of logical networks over one physical network. The physical connection between device, A, B, C & D will each be configured with tagged VLANs to enable communication. All devices that are connecting to the devices themselves (i.e., the HMI, PLC, etc) will be untagged. To learn more about VLAN, tagging or untagged, check out the VLAN Support management guide section. Untagging and Tagging are identified as Access and Trunk respectively.

Despite separating the traffic on the VLANs does enable some additional security measures, it prevents traffic from communicating between different networks. Meaning that the PLCs and not communicate with HMIs. Granted, this may not be required, yet in networks that require this functionality, flat Layer 2 networks are not the option.

Using devices that support routing functionalities enables VLAN routing. PLCs and HMIs can seamlessly communicate with each other (assuming they are configured correctly). This option enables the ability to create a much more functional network in collaboration with a firewall. Traffic that is sent and received between two different VLANS should be limited. For example, if the PLC and HMI communicate on port 9000 UDP, then the firewall only needs to be set to allow port 9000 TCP through and deny everything else. This is especially important for a management VLAN that could be limited to only accessing Port 443 TCP (HTTPS), and removing any unwanted management services.

An additional measure that should be considered with VLANs is subnetting.

Subnetting

Subnetting is the process of dividing larger networks in to smaller, more efficient and manageable networks. The size of a subnet is decided by the subnet mask, that for an IPv4 network, can be anything between 0 and 32. A /0 network is the largest subnet, and a /32 is the smallest.

Take the network 192.168.2.0/24 as an example. With some basic calculations, we know that a /24 will provide 254 usable addresses (2 are reserved). This means that a device can be set between 192.168.2.1 and 192.168.2.254. Note, the two reserved are .0 and .255 for subnet ID and broadcast respectively. Now there is no recommendation of how you configure your devices with an IP address, but is important that you plan your network for expandability.

Networks can grow and shrink depending on the subnet is that is set. Let's say you want to make the network smaller, this means you use a larger number. For example, 192.168.2.0/28 means you have 14 address (two reserved) and can configure devices between 192.168.2.1 and 192.168.2.14. .0 is the subnet ID and .15 is the broadcast address. The next available network is 192.168.2.16, then 192.168.2.32, each increasing by 16.

A example of the network growing is use a lower number, say /16. 192.168.0.0/16 provides a range of 192.168.0.0 to 192.168.255.255. The next network is then 192.169.0.0, 192.170.0.0, etc.

Subnetting relates very much to security and availability. Firstly a small network, one that is designed with expandability in mind, should be considered. If you have four PLCs, why do you need a network that can have 254 addresses? For four devices it would be recommend to use a /29 network, which provides 6 usable addresses. This means that you can add two more devices, but no more. A further consideration is to use a /28 subnet, which is 14 usable addresses incase you may have more in the future. There is no requirement for a larger network.

Smaller networks are not only efficient for management, but they may reduce the extent of damage if someone gains access to a network. Limiting the network to a smaller range reduces the chance of bad actors guessing IP addresses that may be unused.

When it comes to VLANs and Subnetting, there is no general good practice advice on how to do it, however we strongly recommend for a good practice to be included in your network and system. By this we mean that time should be be invested in making a good network structure based on your requirements, rather than expecting direction. VLANs, especially ones that require routing, enable to ability to firewall the network, which is strongly recommended. If traffic does and even does not need to be routed, we recommend implementing an efficient and a well designed IP addressing scheme with subnetting.

For networks to remain available, and for their to be much larger availability, there is a requirement for proper planning of IP addressing and subnetting. The impact of poor management, design and implementation of IP address and subnets can lead to availability being reduced or severely hampered. The threat from attacks on large networks can have immediate and dramatic impact, which can be reduced (but not removed) with simple networking practices.

Static or Dynamic IP Addressing

When configuring a WeOS device an IP address may need to be set. This could be if you want to manage your device on the web or route traffic. The IP address can either be configured statically (manually) or dynamically (automatic), and it is up to you which method you choose based on your system requirements. There are benefits to both methods, but each carry a risk.

Static IP addressing enables detailed configuration, allowing for accurate management of your network and devices. Every IP you set on a device provides a record for communication, albeit for management of the device or for routing. One of the main drawbacks, which can be considered minor, is that if you need to replace the device then you need to be reconfigure the device with a backup file. It also limits the ability to conveniently expand your network over an extended period of time. For example, you have five devices, Device A, B, C, etc. each with a unique IP of 192.168.2.1, .2, .3, etc. If then you want to add another device as device C (.3), then original device C will become D (.4), and original D, would be E(.5), etc. Dynamic IP address does not solve this problem, though provides another option.

Dynamic IP address provides IP addresses to any device configured to request one, say a terminal PC or a laptop. This is configured via a DHCP server, which a WeOS device can be configured as one (in fact WeOS devices can be configured as both a Server and Client). The purpose of end devices to be set as clients to receive and request IP address may be required due to your network requirements. In many circumstances, DHCP is not recommended, but for systems such as on-board systems, DHCP provides a powerful tool. Since the end device will just receive an IP address, it means that configuration on that end device can be minimal. This is very helpful with end devices such as on-board CCTV or devices that may need to be replaced with ease.

Dynamic IP addresses can also have static IP attributes. DHCP Relays and Option 82 provide the ability for DHCP servers to "hand out" the same IP addresses using static leasing to the same device (every time). This could be to an end device or a maintenance laptop for example. There is no benefit to rolling this out if end devices are not to be replaced often, or if they have the ability to have IP addresses configured on them.

There is no preference in which method to select, however it should be considered which posses the biggest risk. Static IP address is very efficient and reduces the need for any server managing the network, however it has challenges if alternations are made to organise the network (albeit minor). It provides the ability to know exactly which device is configured and very important for routing (you do not want to use dynamic IP addressing for routing since routing often relies on fixed information). The only real challenge with static IP addresses is the quantity of effort. If your network is built of many hundreds of devices, this means that many hundreds of devices must be configured.

When it comes to dynamic IP addressing, this is not the solution to replace static IPs. Both are unique and offer benefits and challenges. It posses a risks that any device that requests an IP address will be served one, though this may be exactly what your system requires, especially one with very simply and non-configurable end devices. It also requires the need for a DHCP server (or multiple) on the system that need be configured, which could be extra equipment.

Setting your system and devices up with a solution that fits your requirement is a best practice. Consider the risks, but also use the benefits as strengths to ensure your system is safe.

Management Services

When you want to access a device you will use a management service. This could be via HTTPS via a web browser or SSH via the terminal, with both secure (HTTPS/SSH) and insecure (HTTP/TELNET) protocols being supported on WeOS devices. It is up to administrator of the network and system to dictate which service to use.

When configuring a VLAN, there is an option to have specific management services enabled. This would be either HTTP, HTTPS, SSH, mDNS, SSDP, SNMP and Telnet. Depending on your requirement, it is possible to enable or disable the services globally (i.e all VLANs) or enable or disable per VLAN. If they are disabled globally, it is not possible to enable a service on a VLAN.

Westermo recommend to have a minimum of management services enabled as possible. For example, if your company policy permits HTTPS access, then this could be enabled. This could include services such as SSH also.

We recommend to disable to the following globally: HTTP, mDNS, SSDP, and Telnet. HTTPS, SSH and SNMP should only be enabled on specific interfaces and not on all.

Best Practices: Environment (Identify)

When it comes to best practices, especially focusing on the environment, there are many recommendations. Some of these are independent of each other and some are in collaboration with each other. This is important to highlight since to help deploy a secure environment to help identify threats, there are several actions that required to be taken.

One of the first measures to take to secure your network is to configure the firewall, especially when traffic is leaving a trusted network to an untrusted one. Reducing access to either limited or restricted access via firewall rules helps control and manage what data is entering and leaving the network. In collaboration with a reduced set of management sercices and NAPT also provides an extra layer of security. Removing the use of unsecured protocols such as Telnet and HTTP, and utilising secure protocols such as HTTPS and SSH will reduce the likelihood of "man-in-the-middle" attacks. NAPT enables tracking of packets that leave a trusted network, especially when using services such as the Internet and can also reduce the likelihood of a bad actor trying to log in.

With a network that is segmented, with isolated and independent physical conduits provides a perfect environment to protect your assets. This is complemented with deployment of VPNs enabling traffic to be secure during transit of untrusted (and in some cases trusted) networks. Considerations in which VPN you use should be acknowledged, either SSL or IPsec, which is subject to your requirements. The recommendation to use certificates in both SSL or IPsec should not be ignored.

Building your network with redundancy is highly recommended, subject to your requirements. If it is not part of your original design it should be strongly considered otherwise. Networks that are built with multiple paths naturally offer layers of protection against bad actors, especially if one device is targeted specifically. If you are utilising a Switch network and building Ring Topologies, FRNT is recommended. If you are utilising a routed network and building more complex networks, OSPF is recommended. With routed networks, there is the option to include Firewalls and also virtual gateways with VRRP. There is no right or wrong answers, though considerations must not be ignored to ensure your network is correctly designed.

Switched or routed networks can utilise VLANs, which is strongly recommend. On a switched network, VLANS can be configured to isolate and segment the network. This helps reduce the impact of an attack if a bad actor accesses one VLAN, they may not be able to access the others. This is not only efficient network design, but also an efficient security practice. Removing unused VLANS, and disabled unused management services is highly recommended. For routed networks, VLANs can provide interfaces for the routing table to make decisions on. This is complemented with protocols such as OSPF and enables configuration of Firewalls with ease.

When it comes to creating your network, decisions with subnetting are strongly recommended. Networks that are "too large" can provide bad actors the ability to blend in and access other devices on the same LAN. Considerations with your network IP address scheme should always be introduced in the design phase. This helps both with Switched and Routed networks. Note that networks that are "too small" can cause more problems in the future as well. When it comes to subnetting, it's about getting it right. Think about how many devices could be on the network, not how many devices are on the network. It is important to leave room for expansion. Firewalls on routed networks can help reduce the spread of a threat by only allowing specific IP addresses through on specific ports, etc. The firewall is much easier to modify in the future than the size of the network.

When setting IP addresses, there is a choice to use either Static or Dynamic addressing. This is subject to your requirements and both have positive and negative attributes. Make the decision in how end devices and your network devices are configured early in the design phase and provide an efficient and effective network to allow for your decisions (i.e,, if you use dynamic addressing you need one (or more) DHCP servers).

System & Application Security (Protect)

To protect your network requires a proactive attitude and actions as well as continuous development. Actions and decisions you make during design, especially those considered in the environmental (identify) phase, have an impact and compliment the the Systems & Application security (Protect) phase.

One of the main areas of focus in this section is Authentication, Authorisation and Accounting, commonly known as AAA. AAA is an umbrella term referring to protocols and methods that can be used to handle and verify user access. WeOS devices have ability to both manage user access locally and remotely with either RADIUS or TACACS.

There are three main roles, each with recommend responsibilities. These are Admin, Guest and Operator. To secure your network you must determine who should be an admin, a guest and an operator and define what they should do allowed to do. Admins access should be very limited, with guest and operator being considered for much more "day-to-day" use.

To ensure that your network remains secure, establishing a zero trust philosophy naturally assists your decisions. It should not be able who to trust, but why and when? An admin should be trusted to conduct actions on the network, though why does that person have access and when can they conduct a task? If a bad actor gains admin access, they are able to do anything on the network that you allow them to do.

Further extending the ability to protect your network, implementing timeouts and limitations are to be considered. WeOS devices can be configured with session timeouts, limiting the amount of time sessions can remain active. Furthermore, limitations on passwords and lockout policies complement each other. Password policies can dictate how long, and what is allowed (and not) to be included with a password, with a lockout policy preventing multiple attempts (which could be intentional or an attack) to reduce the ability to for someone or something to gain access through brute force.

In this section, you will understand what password entropy is and why it really has an impact on a password. Passwords with low entropy are easy to crack and with a few small alterations and restrictions in place help extend entropy, making it almost impossible to guess.

For your network also to remain secure for many years patch management and asset management both help. Knowing where your device is in the field is a powerful tool along with understanding what version of firmware your device is using is critical. With this in mind, knowing how to download and safely store files is just as important.

AAA

Authentication, Authorization and Accounting (AAA) is an umbrella term referring to protocols and methods that can be used to handle and verify user access.

The three individual terms refer to who is allowed to access what device (Authentication), if access is granted what are the limitations of their available actions (authorization), and to recount what actions they performed (accounting).

A user should be granted the least possible privilege that allows performing that user’s task. This is realised by a light-weight Role Base Access Control (RBAC) that is available for built-in accounts.

Currently three roles are available:

administrator who has all privileges in the system. Default role for new users.
guest who only has access to a restricted CLI with limited read-only functionality.
operator who has access to a restricted CL with all of the guest functionality and some extra allowed commands.

Only built-in accounts can have roles. Each built-in account has only one role.

Role	Remote Server	Local Database	Built-in Accounts
Administrator	X	X	X
Guest			X
Operator			X

AAA is an important service to include in your network and is recommended to implement. Each of the three A's, Authentication, Authorisation and Accounting each play a vital role in protecting your equipment and network.

Authentication will verify who has and who should not have access to equipment to ensure that every connection made to the device itself is legitimate and approved (without manual invention). Authorisation will determine who can and who cannot complete a task such as change attributes of the device itself based on a predetermined permission. Accounting will determine when a user has taken an action on the device, with what change was and when.

AAA in combination provide a holistic overview as well as a detailed look trail on the network. This means that when an action is taken on the network, you will know about it, but more importantly, that if unauthorised actions are conducted, you will know where and when.

AAA includes a series of protocols of services to help provide the service recommended to harden your network. We recommend introducing services such as a Password Policy, Lockout Policy and 802.1x.

Responsibilities

Since there are many different interfaces on the device that users can connect to, both physically and logically, each of these need to be managed. An enabled Ethernet port for example, could be a way for a user or a bad actor to access the device. Just ignoring unused ports leaves your network and system open to vulnerabilities. A port can be easily disabled ensuring there is no entry in to the device. This could be the same for an interface that is facing the internet or an untrusted extent network.

To manage access, AAA can define who has access to what, based on the roles associated with the user. These also define who can action a task, for example to read the config, reset the device or apply a patch. To secure your network, it is important to manage responsibilities of users on all interfaces.

The three roles available are Administrator, Guest and Operator. Only Administrator can be managed with a Remote Server, Local Database and a Built-in accounts. A Guest and Operator can only be defined as a Built-in Account.

It is strongly recommended that you apply role based access to all user accounts. For example an Administrator account should only be able to apply patches, make configuration changes and a Guest account should only be able to read a few outputs from the device.

When you create an admin account within the Built-in Accounts context, this user will be able to log in via the web and console, as well as make changes via both. One way to restrict access for the admin is to remove web access via the firewall, or completely remove the local admin account and only manage it via a remote server. The latter being the preferred option. If you want to learn more on how to remove administrator access check out AAA - Login with Builtin User Accounts HowTo within the WeOS5 management guide.

With a guest account you can only access the console via SSH or via the Console Cable. This means that you either have to be locally connected to the device or you have setup restricted firewall rules for SSH (remote) access. When the a Guest Account accesses the console they are only able to execute a few commands that have been predefined within WeOS. These are to view certain services and status for example. It is not possible to factory reset the device or log in via the web with a guest account.

Setting up responsibilities enables users to be limited to which interface they are interact with any how. Mismanagement of this service leaves the network and system vulnerable to attacks. Every time a users logs in to a device, the log will record this. It will also record all unsuccessfully attempts as well.

802.1x

To further extend AAA rollout on your system, services such as 802.1x are recommended to be configured. 802.1x enables authentication for users who are approved to use the network when they connect. This could be via a media interface such as ethernet, fibre or Wi-Fi.

When users connect to a network, a device and a server will determine if this user has permission, and what permissions they have. This could be guest, administrator or something else. If this user does not have permission to, they will be rejected and no logical connection is made. One of benefits of this system is to protect the network from unauthorised access, but offer traceability of who, when, why and what a user conducted on the network.

802.1x is an IEEE standard for Port-Based Network Control (PNAC). Either using a TACACS+ or RADUIS server, depending on your requirement, a connection (For Example an ethernet connection from a PC) is first made physically to the device itself. Then from the device, a request is made to the server that will prompt the user to enter credentials. This could be an username and password, which is defined on the server itself. If these credentials are correct, the user will receive an "okey" to proceed to connect to the network. The server itself will also define the permissions. If, for example, this connection is not genuine (say a bad actor), the server will prevent the access to the device and network.

It is recommended to use either RADIUS or TACACS+ for 802.1x on your network. Much of the configuration for authentication is conducted on the server itself, with the WeOS device being configured to connect to the server. Once the connection is established, local access to the device is reduced and will rely on the server to authorise connections. If the connection to the server is severed, local access via an approved administrator account is still active. This user should comply both a recommended password and lockout policy.

Password Policy

A password policy is recommended be enforced to ensure users use more secure passwords. Various parameters can be configured to increase the password entropy, thus making it more difficult to crack. Additional and more stringent requirements are recommended for the minimum number of characters that should be included within a password such as uppercase, lower case, digits and special characters. It is also recommended to exclude and reject the username in the password (i.e admin)

We recommend the following as a minimum.

Value	Minimum value
Min length of password	14

One of the main reasons to use 14 characters as a minimum is due to password entropy. Password length is one of the most critical steps to take when creating secure passwords. Having a long password can help reduce the likelihood of simple guessing, brute force or social engineering attacks. The term used when more complicated and long passwords are created is known as password entropy.

More commonly, IT and OT managers are implementing rules following guidelines of password entropy. The general guidelines require length and blocklist of common phrases. To create a high entropy password, select a page in your favourite book.

call me ishmael

The entropy for this password is 70 points (with spaces). The entropy increases with added numbers, characters, and mixture of upper and lowercase lettering.

To increase your password entry, consider the following additional parameters. Note that length is still 14 characters.

Value	Minimum value
Min length of password	14
Min. Number of upper case characters	4
Min. Number of lower case characters	4
Min. number of digits	4
Min number of special case characters	2
Reject use name in password	Check

An example of the password could be as follows.

C@l10m30!SmAEl

The entropy for this password example is 91,76 points. If a machine would brute force by guessing different values, it would have over there 2 octillion different variables to chose from. Conventional supercomputers can guess roughly 100 billion different combinations per second ¹. Assuming this computer is left running, it would take over 625 million years to crack this password. For context, over 600 Million years ago, the first complex life was starting to grow on earth ². The likelihood of cracking this password is impossible, especially considering the amount of energy that it would take to actually perform this act also.

A bad example is to use less characters or default passwords. The default password for a WeOS5 device is admin. Implementing a password policy would reject this password straight away, but just for example the entropy for admin is 23.

Assuming that a dictionary attack was not conducted, which in this case would crack the password with ease if it was, it would take roughly 4,2 seconds to crack the password assuming a million guesses per second. This is considered bad practice for a password.

Session Timeout

When a user logs in and accesses a device, as long a they are conducting tasks within that device they should have the privilege of doing so. However if they stop this action the session will remain active. This is a huge risk and mitigations must be left in place. This person could leave their machine unattended, providing a bad actor to access their device and commit actions, possibly at a privilege level.

Introducing a session timeout on your devices is strongly recommended. WeOS devices have the ability to be configured with a parameter in minutes, meaning that if there is no activity for this set period, log this user out. This may seem like a basic configuration but it can easily protect your network in the case of someone being absent from the device.

There is the possibility of setting a session timeout on the CLI as also. This is measured within seconds. As with the web session timer, if there is no activity for a set period, the user will be logged out. The user will be informed that the session has expired.

We recommend setting a session timeout on all implemented interfaces.

Within the configuration of session timeout there is also an option to set a notification message for when a user is attempting to log in. This message is free text. When the user attempts to log in to the device, they must acknowledge that they have read the message before a login can be completed on the Web only. This is known as a "login banner".

A login banner can be set on HTTPS, SSH and Console interfaces. It is recommend that a login banner is set on all used interfaces. Note, making the message too specific could provide a bad actor with too much information. It is recommended to consider a message that is direct, but provides no "clues" in what the bad actor is accessing. For example, "WARNING! Unauthorised access is strictly prohibited!"

Lockout Policy

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. You can activate and configure the lockout policy with various parameters.

We recommend enabling lockout policy with the default values. These are if the number of consecutive failures (within 900 seconds) is greater than 3, then deny this user. Also, it is recommended to enable this feature on the admin account. The minimum default time to unlock access to the device again is set to 600 seconds (10 minutes).

Zero Trust

Zero Trust can sound a very extreme security policy, but it is integral philosophy to keep a network secure. The inverse, "full trust" is at the very least nonsensical. The middle approach of "some trust" is sometimes adopted, however, most commonly a spectrum of what or who to trust is blurred and subjective. This can lead to vulnerabilities and exposures.

A system with zero trust implemented offers a backbone for any physical connection, devices and users. A mindset that a user or device must earn trust to access the network is critical. And the inverse, which is if they are not trusted, there is immediate rejection. Implementing services such as AAA and firewalls provide a structure for a zero trust, providing an ability to determine who or what can log in, or being able to transmit or receive data.

Identification, least privilege access and continuous monitoring each create a pillar for a zero trust security model. Systems must be required to know who has access to and when, with the least amount of access given rather than a maximum. Additions such as microsegmentation, to divide the network up in to even smaller chunks can help alleviate and eliminate the potential threat.

We recommend considering the adoption of a zero touch security policy.

Patch Management and Asset Management

With new threats becoming a daily occurrence, keeping on top of this can be a daunting task. It is vital to keep on top of network security patches with regular, consistent and periodic patch management.

Patch management itself is not just installing the latest patch hoping it fixes the problem. It is about understanding what the patch is for, identifying relevant fixes to your system along with keep track of assets ensuring they are up to date.

When a patch is released from Westermo, we provide detailed release notes to ensure that you are up to date with the latest information. It is important to read the release notes to determine if the patch is relevant for your system and also what steps need to be taken to install it. We understand that it is no easy task to update multiple devices, especially on mission critical networks, which is why when we release patches we are clear and consistent in our methodology.

If a patch is not relevant for your system, or does not provide improvements of fixes vulnerabilities to your system, you need to consider whether or not you should take the time to install it. What is the true cost of taking a system offline for patch updates? Is there a suitable time of day that this task can be completed without interruption? These are just some the questions you should ask when considering an update.

If the patch is relevant to you and your system, then the above questions should be considered, but more importantly you should ask yourself, is my network exposed? What are the threats? What will it cost for the system to go offline? Challenges and risks such as time and cost can quickly be reduced, especially when there is a threat that requires fixing.

Keeping control of your assets and what they are configured and patched too is equally important. It is not a good security practice to have some devices updated and not the others. Therefore, when you decide to patch devices, consider patching them all.

We recommend updating your devices to the latest and most relevant version of WeOS. Always read the release notes to determine if the update is correct for you and ensure that patching is conducted first on a test network before rolling it out. WeOS is regularly updated with both major (5.xx) and minor (5.xx.y) releases periodically throughout the year. If you are not sure if the patch is relevant to your system, please speak with your local Westermo Technical Support for further clarification.

How to safely download and store software from Westermo

Downloading software from any website can be a risk. How do you know if the file is safe and is correct? Even more so, how is the integrity kept of a file that has ben stored for a long time? The latter is a very common practice within the industrial sector. A file is downloaded from our website, and then left on a drive for many months or even years. This file could be accessed by many different people and there may be no way for you to prove that this file has not been altered or replaced.

The efforts to protect the file requires an input from both sides (i.e., you as requester, and us, Westermo, as the supplier.). What this means is that when we make files available to download, such as patches, it is vital that you check you are downloading the file from the right place. This also includes confirming any communication (i.e. email) is from Westermo.

Downloading files from Westermo's website, or via an email link, provides integrity and establishes trust. Best practices are in place at Westermo to prevent malicious files to be uploaded to our website, however, fake websites pretending to be Westermo could make you believe that the file you are receiving is genuine.

To obtain the latest version of WeOS, you will input information on our webpage and receive an email with a download link. This is because the file is not located on our website directory itself, but a secure place. Measures are taken to ensure that the files are protected and only a limited amount of people have access to that directory. This helps reduce the likelihood of anyone replacing this file with either the wrong file, or a malicious one.

Downloading software from organisations such as Westermo can ensure that the file that we have uploaded and made available is safe. Measures and procedures in place to ensure that the file available on our website is accurate and has integrity. This is the same for many other companies, especially those who have App stores such as Microsoft and Apple.

Once you have the file, what other methods are in place for you to verify this information? How do you know that this file is correct? This is especially important if the file has been kept on a server for a really long time. The risk of a file being interrupted during transmission is very low. This would require either the file being replaced on the server itself, or a man-in-the-middle attack to replace the file. However, the chances of a file being replaced, adjusted or manipulated when it is stored on a server is much more likely. If the file has not been protected and just left in a downloads folder, how can you prove that this file has integrity?

To validate and verify a file, we can use Checksums. Checksums are a generation of numbers and letters in a specific sequence that are used to match and verify the integrity of a file. In the case of WeOS, we use a SHA-256 Checksum. This file is available on our website. There is not only one SHA-256 checksum for all WeOS. There is in fact one for each version, so it is important to ensure you have the correct one. Each time a new version of WeOS is generated, a new checksum is created and uploaded.

To use a checksum to verify a file, there are a few options. Software tools such as WeConfig provide a method and is recommended to consider. You will need to firstly download and install WeConfig, as well as the SHA-256 checksum file. Then within WeConfig itself you direct it to the appropriate directory and verify the file.

If WeConfig is not available, the alternative option is to use the terminal on either a Windows, Linux or macOS machine. There are many guides available online to verify checksums via the terminal.

Since you have downloaded both the SHA-256 checksum file as well as the WeOS 5.x package (.pkg) file, you will verify them against each other. The checksum file has a series of numbers and letters, which are also embedded in to the .pkg file. By using the terminal, you will output the checksum from the .pkg file and then compare them with the checksum file itself (viewable within a text editor). This will then confirm they are both the same.

These measures are to provides integrity to the WeOS .pkg file, ensuring you have the correct file, from a trusted source.

Note that is only applicable on devices that do not support Secure Boot.

Certificates and Keys

Devices are recommended to be configured with certificates to ensure they include the highest level of security and management. Certificates are way for devices to verify each other, or to verify humans also. This is extremely common on the Internet, especially with services such as HTTPS and SSH. If a certificate is out of date (i.e., expired), it may mean that the connection between client and server is insecure.

Certificate must be signed by an authority and require a system to protect, manage, deploy and revoke. SCEP, Simple Certificate Enrolment Protocol, is a protocol designed to help with such requirement.

Best Practices: System & Application Security (Protect)

Protecting your network is not just one task, but many. AAA provides the ability to authorise users and establish what permissions they have. It is strongly recommended to use AAA with either RADIUS or TACACS to ensure permissions are authorised with an external server. It not only removes the configuration per device, but also provides holistic oversight in to user access and user authorisation.

Establishing responsibilities of those users is also highly recommended. Admin users should be very limited and only have the ability to have full control such as configuration and patch management. There is also the option for local role based access for all user accounts, which should be implemented.

The guest account, with very little access provides a very powerful tool for diagnostics. Since it can only access the console with SSH (remotely) or the console cable (locally), users can log in and determine what is going on the device. They only have access to view certain attributes of the device allowing for limited access and control.

A Password policy is strongly recommended. Password policies can set the minimum length of the password, along with the minimum number of uppercase (ABCD), lower case (abcd), digits (1234) and special characters (!"#€). The length of the password helps lay the foundation for entropy, which essentially helps with the ability to guess the password. A password with high entropy briefly makes it almost impossible for anyone or anything to guess a password, mostly due to "available time" to conduct the task. Passwords with entropy in the 90s and above is theoretically impossible to guess with the allotted time available in the universe. This does not mean that you should have really long passwords, though it is strongly recommended to have a password of at least 14 characters.

Session timeouts and lockout policy, in combination with password policies, provide an excellent foundation for security and extended protection. It is recommended to use both session timeouts and lockout policies, and strongly recommended to use all three in combination (session timeout, lockout policy and password policy). When session timeouts are configured, a timer in the background monitors the session and determines if the user is active or not. If the user is inactive for a predetermined time (i.e., 5 mins), then the user will be logged out. This is very important if a user accidentally walks aways from a terminal, or a bad actor takes too long to establish an action. A lockout policy compliments more the password policy, and assists with how many attempts a user can make before another timeout is set. For example, if a bad actor attempts to log in incorrectly 3 times in a row, they will not be able to log in for another 10 minutes with that the account. This, in combination with a high entropy, extends the time it takes for something to guess your password.

Knowing where your asset is and how it is configured helps protect your network also. One of the main risks is not knowing what or where anything is on your network, which is why it is strongly recommended to have practices and procedures in place. It is especially important as well to know that when you download a patch to update your device, then there is integrity in that file. If this file is stored for many months, or many years (which is very common), there is a very high chance that file could be tampered with. Bad actors have the ability to trick users using sophisticated methods such as replacing firmware files. Using a checksum, available from Westermo, helps establish the integrity of the file, thus allowing you to be confident in your decision when updating your assets.

SUMMARY OF CERT, RATe, SESS, Port -etc

NEED MORE

Monitoring & Recovery (Detect, Respond & Recover)

With your system in place, deployed and operational, you now must consider Monitoring & Recovery (Detect, Respond & Recover). This section looks at that when an incident happens, how do you detect it, what do you do and how to recover back to normal operation. Albeit, this feels like your network is not secure, but since cybersecurity attacks are becoming much more sophisticated, it's a reality that must be faced.

WeOS devices have been designed with this in mind. Implemented alarms are critical, with many options to choose from. It is not about alarming your whole system, more alarming what is important. Then with this data, it must be logged. This can be either with local logging (which has some risks) or the more secure appropriate with external logging.

Ensuring that the data received is accurate and correct, the time and date must be set. WeOS devices can have the time set on them manually, however the introduction and deployment of NTP servers should be considered. There is no point in having many logs stored with no reference point. WeOS devices can themselves act as a NTP server and client, and your network should be designed with this in mind.

Further methods to configure, manage and monitor your network with SNMP should be considered. SNMP is a powerful protocol that is available in several versions. SNMPv1, SNMPv2c and SNMPv3. SNMPv3 should be your preferred choice, which is highlighted in this section.

Lastly, to recover your network, you must back it up. Knowing what to do with backup files and how to restore them is part of your respond and recovery program. What is the process in the place to ensure that your network is limited to the least downtime as possible and how do your bring it back online as quickly as possible.

Establishing multiple levels of monitoring help protect your network against threats, but also assist with immediate actions to detect, respond and recover your network.

Alarms

WeOS has the functionality to alert a user or software with an Alarm. There are four important terminologies for alarms; Sources, Triggers, Actions and Targets. For more information on the technical aspects check out the WeOS management guide section on Alarms.

Alarm sources drive Alarm triggers. This could be something such as Link Alarm. The Trigger drives Alarm Actions. This means the link alarm is to monitor if the port is either UP or DOWN (the trigger), and then take action if the state changes (from UP or DOWN). An Action then will take steps to inform an Alarm Target, to add this change to a Log. For example, an Ethernet Port with a link alarm. The ethernet port could be monitored, which has a trigger to establish if it is UP or DOWN. The port, in a healthy condition is UP, and unhealthy if it is DOWN. If the port then goes down (someone removes the cable), the an Action is taken to target this to a log.

Alarming a system is incredibly important and highly recommended. There are many different alarms that be configured such as monitoring the power input status, PoE usage, link alarms (ethernet ports), temperature sensors to name a few. These are configured per the device and WeOS itself controls the what alarms you have access to (i.e., an unsupported alarm is not available if you do not have the feature included in your device).

Every device on your system should be alarmed with sources such as ethernet ports, however it is important to establish which ports to monitor for example. There is no point monitoring a port that is never used and not enabled. On the other hand, there is no point monitoring everything. This means that alarming should be introduced at a later phase of implementation rather than the start, enabling you to establish the system in full operating first.

Once alarms are configured, it is important to establish where the information goes. What is the point of alarming and the data is just stored locally on your device? Since logs are wiped every time a device is reset, you need to take in consideration where information is stored. This is where external logging servers are vital. Furthermore, if too much information is being logged, then it could be overwhelming and unclear when trying to diagnose faults.

Alarms provide a foundation for a network and help keep the integrity of the network itself. A best practice is to firstly establish the network under normal behaviour, with alarms set in place to display changes or irregular behaviour. If you notice something different from the norm, then you can identify it quickly. This is especially prevalent for intrusion detection. An unauthorised user accessing a networking will display clear behaviour that is different from the day to day. Industrial networks should be the same everyday, with no erratic behaviour. This is what makes them behave differently to conventional IT networks.

We recommend implementing alarms in your system. It is recommended to use Link Alarms to monitor port status, determining if they are UP or DOWN (A cable is connected or not). This is the first line of defence against an attack or just understanding what condition your network is in. Further suggestions could be for input alarms of Power Sources. This is especially critical in systems that may have challenges with local power, or battery backups.

WeOS supports many different alarms, each unique to your system. For example, in cases of networks that use PoE, it is recommended to monitor PoE status. Some WeOS units support Digital IO, which is recommended to be monitored for compatible systems. When digital IO is configured, physical security measures such as door alarms can be implemented. When connected to Digital IO, WeOS can be configured to trigger actions such as logging and SNMP. One of the first steps of securing your digital network is establishing a solid physical security strategy and installing measures in place.

System Logging

System logging is a service that is enabled as default, but is often ignored or overlooked as important tool to secure your network. The main purpose of the log is to capture what is going on the network and the device on multiple levels. If something happens, there may be multiple recordings of the instance from different services (kernel, firewall, etc.). This can help you cross reference and identify faults. It can also be configured to report interactions with firewalls, NAPT and alarms.

By default, WeOS units will log many different services. These are all vital, however there is a finite amount of data that can be captured. Logs will fill up and once they do, will override existing data. This is very important to know and a system should be designed with a server to protect information. This is very important to understand if you are capturing too much information.

When a device is first powered up, there should be very little reported in the logs. If you notice the logs filling up with information it is worth investigating why. Examples could be physical port status being reported, unauthorised access, etc. This could be down to poor configuration or unobserved errors on your device. When information is logged on a device, a timestamp is attached to the notification. This timestamp will record the time, date, hours, minutes and seconds in the following format. MMM DD HH:MM:SS, for example, Dec 16 16:20:45. Please note that year is not recorded.

Services such as alarms or firewall functions can be configured to be reported to system logs. For alarms, an action is recommended to be configured to report to logs. For firewalls, it is recommended to configure rules to report to log. The firewall could report every rule, or just a select few to the log. Note that the firewall will report to log once if a packet matches a rule and allowed, and will report to the log every time if a packet matches a rule and is denied (for example a firewall hit). This means that if a firewall is being hit a lot with denied access (a hacker), the log will report every attempt.

It is important to note that there are two main challenges with system logs. One is that logging too much information can flood logs and establish an overwhelming fear of "too much data", and the other is that logs are not persistent. If a device is rebooted (either manually or unexpectedly), the logs will not remain. One of the most important steps and a strongly recommended measure is to setup a log server.

A log server is where devices on the network will transmit log entries to a remote and secure location. This log server cannot only protect the information, but it can organise the data too. Logs can be configured with severity levels in coordination with the protocol Syslog. Syslog (RFC 5245) is a protocol that defines how message notifications are conveyed. Syslog will report to systems logs and also syslog servers.

For alarms, the syslog protocol can report messages at different priorities from Emergency to Notice to debug. The purpose of the ranking provides a vital tool to troubleshoot and establish faults within a network. For example, if an alarm is reported at 00:00 with an alert of Emergency, it will be displayed at the top of a list on a server. Then another alarm is reported as Critical at 00:01. Since most alarm servers report traffic chronically, naturally the critical alarm should be on top. However, Syslog will organise information chronically, but also severity. Therefore, the alarm (which was reported first), we will remain on top because its severity is higher.

Therefore it is important to configure your network with the correct severity. If a port is being monitored with a link alarm, should this have the same severity if a digital alarm, monitoring a door, be equal? This is up to you, however we strongly recommended configuring a log server.

Logging can help protect a network in many ways. When correctly configured, the can report unauthorised access or the attempts made. Take a device or a network that is exposed on the internet, it is almost guaranteed that someone or something is going to try and log in. This is the main reason why it is important to change your default password, so let's say you have. The log will report all attempts and identify which user, and whether or not it was successful. The log will likely report a magnitude of different users, with consecutive (and hopefully) failed attempts. This could display a lot of information, but highlights that your device is exposed and potentially vulnerable.

One of the actions to take is to ensure that your firewall is configured and other security hardening measures in place such as password and a lockout policy is in place. Services such as using system logs to monitor the access to the firewall are strongly recommended.

System logs help maintain the integrity of the network and the device as it provides a method to report specific values. It is vital to know what is going on in your network and your device to ensure that no malicious behaviour is happening. The logs will help identify that if someone has gained access to your network, you are able to see when. For example, if an authorised user accesses your network, you could establish that the network and data on the network thereafter that moment cannot be trusted. This would be considered a huge problem, however it can help maintain or if not, restore integrity, and help resolve the reason of the exposure.

WeOS devices can also receive information from other devices. This could an attempt to flood a device, making it very difficult to see if someone has gained authorised access or just cause unwanted disturbances. System Logging is recommended to be configured with secure mode, which can prevent the device from receiving unwanted access to logs and not accept any remote messages sent to it. Furthermore, if you chose to disable web access on the device and only use the console, the log can be configured to report to the console too. This is recommended if you ?????

Persistent Logging

Persistent logging provides the ability to store logs if the device loses power or experiences an unexpected shutdown. Only available on specific models.

Audit Event Logging

Capturing information about a device is incredibly important, which is why the need to system logged and external logging services is strongly recommended to be implemented in to your system. With this in mind, capturing more detailed information on a device helps increase holistic oversight and makes troubleshooting much easier. Knowing what has happened and who has done something can not only help fix a problem, but can also help you understand if there is a threat or not.

Audit event logging is a service specifying specific log message that the WeOS device produces, where each of these messages have an associated ID that identify the specific event. This information is very similar what is currently logged in the device, though due to the specific ID, more insight is naturally obtained.

Here is an example of an Event ID Value, which identifies that a console login has been successful.

#	Value	Description
1	0x1000000000010010	Console login Success

Assuming the login was successful, the log will output the following:

Jan  8 18:29:11 viper wauditd[619]: type="audit"; eventid=0x1000000000010010; uid=0; gid=0; seqnum=66; eventidtext="Access Control - Console login Success"; msg="Authentication successful for user 'admin'";

The eventid 0x1000000000010010;, referencing the audit chart, displays that the login is successful. This is also identified with the eventidtext, along with a msg (message) from which user, admin.

Therefore we know that admin has successfully logged in via the console on Jan 8 at 18:29:11.

This information is available both in the console and the web. An extensive list is available at ....

Setting the time and date

Having accurate time and date may not seem the most important task, but in fact is one of the most important and easily overlooked actions when it comes to networking. Accurate time and date not only helps with troubleshooting a networking, but also providing an underlying value to logs. Knowing exactly when something happens provides an opportunity to truly discover a fault or if someone has attacked your system.

The time and date can be manually set on WeOS devices, which is recommended as a starting point. We strongly recommend using a least two NTP servers to ensure that the time and date does not drift. Network Time Protocol (NTP) is a UDP protocol that requests time and date data enabling the system to synchronise on a trusted clock.

NTP servers are commonly known as a stratum. Every hop, (Sever to Client, etc) increase the stratum by one. The first server is known as Stratum 1, which will be a server for a client. Stratum 1 is usually the most accurate of clocks, using either GPS or another source to reduce and time drift. That client can also become a server, which will then be Stratum 2, and so on. It is recommend to limit the amount of stratums (servers) on your network to a few to reduce time drifting or inaccurate synchronisation.

NTP Servers and Clients should be layered within a logical network. Stratum 1 could be an NTP server available on the Internet or a self-managed clock. This is likely to be available on an untrusted network. Therefore Stratum 2, which is the now a client of Stratum 1, is now the server for end devices. This device should be configured with the restricted firewall rules protecting the rest of the network from an untrusted network, ensuring the rest of the network is safe.

With a trusted NTP servers logs will be correctly marked with the accurate time. This information is vital. Inaccurate time and date makes analysis of logs almost impossible and can render them useless. The purpose of having two NTP servers is to ensure that the primary and secondary are referenced against each other, preventing any threat of one server drifting time. This also enables the ability to implement certificates for VPNs for the web server.

SNMP

Simple Network Management Protocol is a protocol that enables a network to monitor many multiple variables on a device. This information is reported to an SNMP server, located either locally or remotely,

The SNMP standards lays out a structure for the protocol to follow using a series of Object Identifies (OID) organised within a series of Management Information Base (MIB). A MIB contains many OID values. MIBs are defined and collect OID values with values that are related to each other. The OID will match a specific point on the device such as port status on every port. This means that there is a OID which will report every type of port status (UP, DOWN, etc) on every Port (Eth1, Eth2, etc). This means a lot of data that be captured at once.

SNMP can either poll or push data depending on the requirement. A poll is where a server will request information from a device itself, and a push, known as a Trap, is where information is sent to server on an incident. This means that if something happens, a trap will inform the server instantly. Whereas if a device is polled, it means that information is only as up to date as the latest value. A poll could be once every minute, hour, day, etc.

Within a MIB, the OID is referenced with a series of numerical values. Take port status for example. Port status, within the non-proprietary IF-MIB, is an object-type that can be monitored with ifOperStatus (Operating Status). There are several different integers that can be monitored, each mapped to a numerical value. UP (1), DOWN (2), Testing (3), etc. An SNMP service will use an OID from the IF-MIB of 1.3.6.1.2.1.2.2.1.8.x, where .x is the port. It will then report back to an SMMP server as either 1, 2 or 3. A message from a SNMP server will send a request with data points of the OID, to report back this information.

One should not poll every value, every second or minute. It is about getting it right and understand why and what you are polling. Values such as port status can be configured as traps that if the a cable is removed (the port charging from UP to DOWN) provides a sufficient response. Where a poll could mean that if poll window is too long, a cable could be removed during that period and connected with no idea that an incident has happened (granted, this could appear in the logs, but you are not alerted without prior configuration). This does not mean it should not be polled, but highlights why you should monitor regularly, but not too often.

Now with this data in mind, a poll or a trap provides a detailed value of the network. The data can be referenced easily since SNMP is a standardised protocol, meaning that if anyone captures this information they can either manipulate it, or extract a holistic view of the network. SNMP is available in serval versions, v1, v2 and v3. v1 and v2 are plain text, whereas V3 is encrypted. We strongly recommend using SNMPv3.

SNMP can be read and write values. For SNMP to be established, the server and the device must have matching values which are known as communities. It is important to not use communities for Read and Write, since they are not needed for SNMPv3.

SNMPv3 was developed in the late 90s to address security issues, however it only started to be adopted in recent years. SNMPv3 requires user configuration that matches a server providing a user either read-only (RO) or read-write (RW). There is an option to configure cryptography and authentication, which is strongly recommended. With this authorisation, it can establish secure transmission of data between end device and the server, reducing the threat of a man-in-the-middle attack.

For SNMPv3 traps, a server must be configured with the required parameter to select a predefined user to ensure the traffic is encrypted. Within WeOS, there is a possibility for a user to send a reboot or a factory-reset request via a write SNMP value. These parameters can be set to no-enable (disable) and is strongly recommended in doing so. These parameters must be set on the device itself. Multiple servers can also be configured to aid resilience in case of unexpected failure.

As with logging, SNMP provides an opportunity to understand the network. It offers a much more in-depth and defining data points such as port status, configured IP addresses, VLANs, alarm status, to name a few. Knowing more about your network is vital in keeping your network secure and for integrity to remain. SNMP provides an opportunity to capture if someone or something has accessed to the network, and broadly speaking, what they are doing (there is a possibility to capture if there is a spike in traffic on the network).

The challenge with SNMP is when too much is captured and losing access to remote devices. For example, if you are polling devices that are remotely connected via the a VPN over the Internet, if you lose access to that device (say the local internet access drops), SNMP polls will time out. SNMP traps will only send data on request also, meaning that once the network is established, it will not complete missing data points. This means for a network, especially one that is built to have integrity, must be configured and established with this in mind. Can you justify losing sight and information of a remote network? If not, what measures can be put in place? What do I need to monitor? How ofter should I monitor? These are all questions that require justifiable actions to ensure your network remains safe and secure.

How to work with Backup files?

There are three different types of configuration files within a WeOS device, each having an important role to play. These are startup, running and factory config. Startup and running configuration files are both Read and Write, where factory configuration is Read only. When a unit is powered up, it will read (and apply) all parameters set in the startup config. Any parameters written in the startup and factory configuration are persistent, meaning it does not change. Anything saved in the running configuration is persistent, unless rebooted, which then removes and restores back to running config (which could be factory, or what was previously configured). Note, this is not restoring the device back to factory, just the contents of the running configuration. Running configurations also have a checksum. This can be read via SNMP and tracked via an Alarm. This is exceptionally useful for change management or commissioning phases. If the Checksum changes, SNMP and alarms will highlight a difference, providing an opportunity for comparison.

When WeOS devices are configured with parameters, for example a firewall rule, data is saved to the configuration file. If any adjustments are made on the on web interface, they are immediately saved to the startup config. Any configurations that are made via the console or SNMP and saved to the running configuration. A further requirement to save parameters to the startup configuration is required.

Once a unit is configured, you will be able to take a backup of all three configuration files or view them via the CLI (subject to user access). WeOS devices provide a function known as "Technical Support", which will take a snapshot of the unit and save all logs and support files. If you just want to take a backup of the unit, use the "backup and restore" function, which captures the startup configuration only.

The backup file that you have captured from the device must be stored in a safe and secure place. As highlighted within How to Safely Download and Store Software from Westermo, protecting the integrity of files is critical for security. If files are tampered without your knowledge and restored on to a device, issues may arise on your device and network.

Configuration files are written in JSON, a language that can both be read and written by human or machine. Information is structured in a way that can be easily understood, enabling actions and tasks to be conducted on the device and system. Backup files can be read and written within any approved text editor. They must be saved as a .cfg.

Assuming a backup file has be correctly stored, they can be restored on the device. This could be because the device has been factory reset, or for other support reasons. The WeOS device will accept backup files which are formatted correctly, and will reject any unknown commands inputted within them file. If this is the case, the default value of these parameters will be set. It is important to check that parameters are configured correctly before uploading a configuration file.

Backup files can be checked via CRC (Need more information on this)

Best Practices: Monitoring & Recovery (Detect, Respond & Recover)

As we now have established, the when, not if approach is to be considered. This does not mean it will happen, however it means you are prepared for if it happens.

The first measure, which is strongly recommended, is to use alarms. Alarms are a powerful tool that allow you and your system to receive real time data on an incident, albeit a port status, someone opening the cabinet, or other values such as the temperate of the device. The alarms will log all information internally and can report information to an external logging server. Alarms can also be configured to trigger events such as VRRP, which is recommended if you utilise that protocol in your network.

Logs are always stored on the device itself, but by default are not persistent. This means if the device is reset or experiences an unexpected shutdown, then this information is deleted. With that in mind, the likelihood of that happening should be extremely low if the device is correctly installed with redundant power supplies, but it does happen. There are two methods to reduce the severity of that incident, which are recommended in parallel or independently. Devices, which support this functionality, can be configured with persistent logs, which means that if the device is reset, this information is saved. This is not common practice in most WeOS devices currently, but available in a select few.

The more appropriate and highly recommended approach is to use an external logging server. This server is to receive all information from all configured devices, and with protocols such as syslog, hierarchically organise them with the timestamp and least and most severe event. For example, if a link alarm is configured as well as temperate alarm, you may want to highlight the severity of one of those incidences. A port being removed may be someone actively infant of a device remove cables, either intentionally or unintentionally.

Audit event logging is highly recommended to be enabled to allow for full oversight of what is going on the device and by who. If you know an admin is logging in to the device, or an admin is trying to log in the device, the audit event logs will identify this action and record this information.

Logs, with the correct time and date set are incredibly valuable. It is highly recommended to have multiple NTP servers on your network, which also could be subject to firewalls and VLANs, to ensure that accurate information is always recorded. Knowing, where, when, how, and who conducted a task assists with the ability to detect, respond and recover.

SNMPv3 is strongly recommended, either in collaboration with alarms, or just independently. It is not advised to use SNMPv2c or less due to the security risks associated with legacy protocols. SNMPv3 provides both secure transmission of data through authorisation and also the ability to monitoring, manage and troubleshoot your network. SNMP can either receive traps (an alert from the device) or poll (request information from the device) many number of values. This could be from port status, to temperate, to IP addresses, to firewalls, to name a few. Note that too much information can sometimes be a bad thing, so it is important to limit SNMP to only what you need to monitor.

In the case of the rare incident of a breach, disaster recovery and a plan of action is highly recommended. Storing your backup files in a safe location and ensuring prompt recovery of those files to devices can help restore critical operation and prevent the impact of an attack.

What does Westermo protect? "Goal"

Secure Operations

"Always active"

Report vulnerabilities to us.

Certificates? How do we include this?s

Tie in with Michael

Configuration Hardening Guide WeOS 5

Abstract

This guide will show how to configure Westermo network devices using WeOS 5.23.0 with the purpose of being compliant with the Industrial Cybersecurity standard IEC 62443-4-2 SL2. The configuration is based on an example topology that will reflect a "lowest common denominator" security zone fulfilling all requirements from the standard. The security zone can be scaled with more switches and duplicated for larger networks if needed. The guide includes the topology map, IP-plan and the configuration files for reference.

Scope

The scope of this guide is WeOS 5 functionality, it is not intended to show how to setup all other services needed for compliance with the standard e.g., configuration of Radius servers, Network Management Systems etc. The flow of the guide is from a WeOS point of view, so the secured configuration is built in steps which are logical for WeOS which is not necessarily following the same order as the standard. References towards the fulfilment of the standard with each configuration step is clearly stated throughout the guide. The packet filter rules (firewall) are added only to enable the needed protocols and services to achieve the topology described and to fulfil the IEC 62443-4-2 standard. Other filter rules will be required for the processes running in this type of industrial network. These rules are not covered in this document but should be quite straight forward to achieve with the help of the filter rules described. The used functions are only briefly described throughout this document, but if deeper explanations are needed, the WeOS 5 User Guide provides more in-depth information. User Guide

Topology

The network consists of two redundant Layer 3 switches:

Lynx-3510-E-F2G-T8G - LxRouter01 and LxRouter02

And two Layer 2 switches:

Lynx-3510-E-F2G-P8G - ProcSW01 and ProcSW02

The two Layer 2 switches arre connecting end-nodes in a fictitious process network. The two Layer 3 switches in the topology provides the zone boundary with firewall filtering, redundant server services and VPN functionality. VRRP is used to provide a redundant Default Gateway for the network and its subnets. In this example it is used for router redundancy only so it will not monitor link-failures, but redundancy when the primary router needs to be upgraded or has a power loss.

The Process network uses a fiber optic Layer 2 ring topology to provide redundancy with fast fail-over for sensitive process data. There is one Local Control Room where local servers are located for Authentication, Network Management and Time Synchronization. Further away are the Remote Control Room located i.e., beyond the unsecured networks. From this control room the local NMS is accessed through HTTPS but it mainly provides VPN server functionality over the unsecured networks and Internet access. The Remote Control Room would typically have a Next Generation Firewall and more IT-types of equipment for securing the Internet access. This example network also provides a local management access port (eth3 of the LxRouters) for a field engineer/road warrior to be able to access the switches locally and perform management tasks if the NMS system is unavailable. The primary Road Warrior access is used as long as the primary router is available, if it is not then the backup access can be used.

IP Plan

This is the IP-plan for all Security Zones in this fictive application. Only Security Zone 5/Process Network 5 will be used in this example and are marked in bold for each subnet list below. The IP-plan follows the numbered logic of the Process Networks. So the first octet is common for all Security Zones i.e., 10.x.x.x the second octet represents the Process Network in this case number 5 i.e., 10.5.x.x. The third octet represents the different subnets used inside the zone e.g., 12 is the process as it uses ports eth1 and eth2 (10.5.12.x), 4 is the Radius server subnet which connects to port eth4 (10.5.4.x) etc. The connection towards the unsecured network uses port eth9 and are unique for all zones and each Layer 3 switch in it. These are just link subnets with only two host addresses which are using this address range, 172.16.9.x. The VPN tunnels over the unsecured network have addresses following the link subnets 10.169.5.x; 169 for VPN over unsecured 172.16.9.x and 5 for Process network number 5. The Remote Control Room has a single subnet 192.168.9.0/24 as it is the other side of the eth9 link subnets.

Process Subnets

10.1.12.0/24
10.2.12.0/24
10.3.12.0/24
10.4.12.0/24
10.5.12.0/24
10.6.12.0/24

Management Subnets

10.1.3.0/24
10.2.3.0/24
10.3.3.0/24
10.4.3.0/24
10.5.3.0/24
10.6.3.0/24

Authentication Server Subnets

10.1.4.0/24
10.2.4.0/24
10.3.4.0/24
10.4.4.0/24
10.5.4.0/24
10.6.4.0/24

Local Control NMS Server Subnets

10.1.6.0/24
10.2.6.0/24
10.3.6.0/24
10.4.6.0/24
10.5.6.0/24
10.6.6.0/24 \

Remote Control Room Subnet

192.168.9.0/24

NTP Server Subnets

10.1.8.0/24
10.2.8.0/24
10.3.8.0/24
10.4.8.0/24
10.5.8.0/24
10.6.8.0/24

Connection to Unsecured Network Subnets

172.16.9.0/30
172.16.9.4/30
172.16.9.8/30
172.16.9.12/30
172.16.9.16/30
172.16.9.20/30
172.16.9.24/30
172.16.9.28/30
172.16.9.32/30
172.16.9.36/30
172.16.9.40/30
172.16.9.44/30

VPN Subnets

10.169.1.0/29
10.169.2.0/29
10.169.3.0/29
10.169.4.0/29
10.169.5.0/29
10.169.6.0/29

Topology with IP-addresses Included

Configuration of LxRouter01

Getting Started/Basic Configuration

All configuration in this document is done via the WeOS 5 CLI using a console cable (USB-C). By connecting to the switch using a serial connection instead of an IP connection helps a lot when hardening the switch config. Start by logging into the switch through the console connection by using the COM-port assigned to the cable with a speed and data format of 115200 8N1. Default username is admin and default password is admin

lynx-79-69-a0 login: admin
Password:
.--.--.--.-----.-----.-------.-----.----.--------.-----.
|  |  |  |  -__|__ --|_     _|  -__|   _|        |  _  |
|________|_____|_____| |___| |_____|__| |__|__|__|_____|
                                       www.westermo.com

Westermo WeOS v5.23.0 5.23.0 -- Dec 10 13:25 CET 2024
Type: 'help' for help with commands, 'exit' to logout or leave a context.

Switch Identification Information

Start by setting up some basic information about the switch to make it easily identifiable in the network. From the config context go to the system context and set hostname, location and contact fields for the switch. In this case Lynx-3510 (Lx) Router 1 (Router01) which is located in Process Network 5 (PR05) and Cabinet 1 (-CAB01).

lynx-79-69-a0:/#> config system
lynx-79-69-a0:/config/system/#> hostname LxRouter01
lynx-79-69-a0:/config/system/#> location PR05-CAB01
lynx-79-69-a0:/config/system/#> contact support@companyname.com
lynx-79-69-a0:/config/system/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

VLANs and Layer 3 Interfaces

Setup all the VLANs which will serve as a base for the subnets used and assign Layer 3 interfaces to them. VLANs provides an important step in segmenting the network in order to limit unnecessary flow of data. By default all ports are allocated untagged to VLAN 1.

The process network will use VLAN 12 (ports eth1 and eth2) untagged and the 10.5.12.0/24 subnet.

Management in the network will only be allowed through VLAN 3 (port eth3) inside the zone using subnet 10.5.3.0/24. Except for the NMS server subnet which will use 10.5.6.0/24 addresses as the router switches will use its upstream interface i.e., the interface address closest to the destination as source address for traffic generated by the switch itself. This means that SNMP traps, Remote Syslog messages etc will have 10.5.6.1 and 10.5.6.2 as source addresses. This will make it easier in the NMS system by using the same addresses when initiating management traffic to the routers and also receiving traffic from the routers.

All servers for the network are located in a server VLAN, in this case several servers are used in separate VLANs 4, 6 and 8 with the subnets 10.5.4.0/24, 10.5.6.0/24 and 10.5.8.0/24. Most commonly all servers would run in a single hardware so just one VLAN and subnet could be sufficient depending on the redundancy demands for the network. The connection to the unsecured network is through a port interface i.e., no under-laying VLAN so traffic can only access this interface through Layer 3.

Create the port interface by removing the port from VLAN 1 and add a Layer 3 interface:
LxRouter01:/#> config vlan 1
LxRouter01:/config/vlan-1/#> no untagged eth9
LxRouter01:/config/vlan-1/#> end
LxRouter01:/config/#> iface eth9
LxRouter01:/config/iface-eth9/#> inet static 172.16.9.34/30
LxRouter01:/config/iface-eth9/inet-static-172.16.9.34/#> end
LxRouter01:/config/iface-eth9/#> end

Management VLAN:
LxRouter01:/config/#> vlan 3
Creating new VLAN vid:3 with name: vlan3
LxRouter01:/config/vlan-3/#> untagged eth3
Moving untagged port eth3 from vid 1 to vid 3.
LxRouter01:/config/vlan-3/#> tagged eth1..eth2
LxRouter01:/config/vlan-3/#> end
LxRouter01:/config/#> iface vlan3
LxRouter01:/config/iface-vlan3/#> inet static 10.5.3.1/24
LxRouter01:/config/iface-vlan3/inet-static-10.5.3.1/#> end
LxRouter01:/config/iface-vlan3/#> end

Authentication Server VLAN:
LxRouter01:/config/#> vlan 4
Creating new VLAN vid:4 with name: vlan4
LxRouter01:/config/vlan-4/#> untagged eth4
Moving untagged port eth4 from vid 1 to vid 4.
LxRouter01:/config/vlan-4/#> end
LxRouter01:/config/#> iface vlan4
LxRouter01:/config/iface-vlan4/#> inet static 10.5.4.1/24
LxRouter01:/config/iface-vlan4/inet-static-10.5.4.1/#> end
LxRouter01:/config/iface-vlan4/#> end

NMS Server VLAN:
LxRouter01:/config/#> vlan 6
Creating new VLAN vid:6 with name: vlan6
LxRouter01:/config/vlan-6/#> untagged eth6
Moving untagged port eth6 from vid 1 to vid 6.
LxRouter01:/config/vlan-6/#> end
LxRouter01:/config/#> iface vlan6
LxRouter01:/config/iface-vlan6/#> inet static 10.5.6.1/24
LxRouter01:/config/iface-vlan6/inet-static-10.5.6.1/#> end
LxRouter01:/config/iface-vlan6/#> end

NTP Server VLAN
LxRouter01:/config/#> vlan 8
Creating new VLAN vid:8 with name: vlan8
LxRouter01:/config/vlan-8/#> untagged eth8
Moving untagged port eth8 from vid 1 to vid 8.
LxRouter01:/config/vlan-8/#> end
LxRouter01:/config/#> iface vlan8
LxRouter01:/config/iface-vlan8/#> inet static 10.5.8.1/24
LxRouter01:/config/iface-vlan8/inet-static-10.5.8.1/#> end
LxRouter01:/config/iface-vlan8/#> end

Process VLAN:
LxRouter01:/config/#> vlan 12
Creating new VLAN vid:12 with name: vlan12
LxRouter01:/config/vlan-12/#> untagged eth1..eth2
Moving untagged port eth1 from vid 1 to vid 12.
Moving untagged port eth2 from vid 1 to vid 12.
LxRouter01:/config/vlan-12/#> end
LxRouter01:/config/#> iface vlan12
LxRouter01:/config/iface-vlan12/#> inet static 10.5.12.1/24
LxRouter01:/config/iface-vlan12/inet-static-10.5.12.1/#> end
LxRouter01:/config/iface-vlan12/#> end

VLAN 1 can not be removed but the interface can be disabled:
LxRouter01:/config/#> iface vlan1
LxRouter01:/config/iface-vlan1/#> no inet
LxRouter01:/config/iface-vlan1/#> no enable
LxRouter01:/config/iface-vlan1/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Verify the configuration with the show vlan and show iface commands:
LxRouter01:/#> show vlan
VID  NAME             OPER TAGGED/UNTAGGED/POLICY NEST
   1 vlan1            DOWN T:
                           U:eth5, eth7, eth10
                           N:
   3 vlan3            UP   T:eth1..eth2
                           U:eth3
                           N:
   4 vlan4            UP   T:
                           U:eth4
                           N:
   6 vlan6            UP   T:
                           U:eth6
                           N:
   8 vlan8            UP   T:
                           U:eth8
                           N:
  12 vlan12           UP   T:
                           U:eth1..eth2
                           N:
LxRouter01:/#>

LxRouter01:/#> show iface
INTERFACE         OPER  ADDRESS/LENGTH      SOURCE      MAC/PTP ADDRESS
lo                UP    127.0.0.1/8         static      00:00:00:00:00:00
eth9              UP    172.16.9.34/30      static      00:11:b4:79:69:a9
vlan1             DOWN  DISABLED                        00:11:b4:79:69:a0
vlan3             UP    10.5.3.1/24         static      00:11:b4:79:69:a0
vlan4             UP    10.5.4.1/24         static      00:11:b4:79:69:a0
vlan6             UP    10.5.6.1/24         static      00:11:b4:79:69:a0
vlan8             UP    10.5.8.1/24         static      00:11:b4:79:69:a0
vlan12            UP    10.5.12.1/24        static      00:11:b4:79:69:a0
LxRouter01:/#>

Disable Unsused Ports

There are three ports on the switch that are not used, eth5, eth7 and eth10, these will be disabled to minimize the attack vector of the network in accordance with FR 7 CR 7.7.

LxRouter01:/#> config port eth5, eth7, eth10
LxRouter01:/config/port-eth5,eth7,eth10/#> no enable
LxRouter01:/config/port-eth5,eth7,eth10/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Verify the configuration with the show port command.

LxRouter01:/#> show port
PORT             LINK     TYPE       SPEED  STATE           OWNER/VLAN
eth1             Up    1000-SX  1000M-Full  Forwarding      vlan U:12,T:3
eth2             Up    1000-SX  1000M-Full  Forwarding      vlan U:12,T:3
eth3             Down   1000-T  ----------  No-Link         vlan U:3
eth4             Up     1000-T   100M-Full  Forwarding      vlan U:4
eth5             Down   1000-T  ----------  Disabled        vlan U:1
eth6             Up     1000-T   100M-Full  Forwarding      vlan U:6
eth7             Down   1000-T  ----------  Disabled        vlan U:1
eth8             Up     1000-T   100M-Full  Forwarding      vlan U:8
eth9             Up     1000-T  1000M-Full  ----------
eth10            Down   1000-T  ----------  Disabled        vlan U:1
LxRouter01:/#>

Layer 2 Redundancy

The process network needs a fast redundancy protocol so it can fail-over traffic without disrupting the critical processes that runs over the subnet. So a Layer 2 ring protocol will be used, in this example FRNTv2 which is a Westermo ring protocol with a long track record in the industrial market. It is a fast, scalable and robust protocol well suited for critical industrial processes. One switch acts as the Focal Point in the ring i.e., it holds the blocked port, in this case it is ProcSW01 that has this role. All other switches in the ring are FRNT Members. For LXRouter01 it is not so important to configure the ring protocol early, but for the rest of the switches it will be needed for those switches to be able to reach services like NTP, Authentication servers etc. This is due to one of the reliability features of FRNT that a port will not go to forwarding unless FRNT is enbled on both ports connected to the same link. This makes it impossible to cause a storm by mistake if connecting the wrong ring ports together. The FRNT configuration is quite straight forward, go to the config and ring context. Use the FRNTv2 command and add a Ring ID, in this case 1. All switches in the same ring must have the same Ring ID. Define which ports that should be used for the ring, in this case the Fiber Optic ports eth1 and eth2. Disable the focal-point setting for all Member switches, but remember that it must be kept on for ProcSW01.

LxRouter01:/#> config ring
LxRouter01:/config/ring/#> frntv2 1
Activating FRNT with default settings, remember to change the ring ports!

Invalid settings: No ring ports defined
LxRouter01:/config/ring/frnt-1/#> port eth1
LxRouter01:/config/ring/frnt-1/port-eth1/#> end
LxRouter01:/config/ring/frnt-1/#> port eth2
LxRouter01:/config/ring/frnt-1/port-eth2/#> end
LxRouter01:/config/ring/frnt-1/#> no focal-point

Check the configuration with the show command:
LxRouter01:/config/ring/frnt-1/#> show
FRNT version     : 2
Ring ID          : 1
Mode             : Member
Port             : eth1
  hello-time     : 500 ms
Port             : eth2
  hello-time     : 500 ms
LxRouter01:/config/ring/frnt-1/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Default Gateway

LxRouter01 will have a default gateway in 10.169.5.1 which is the VPN end point of the Remote Control Router. This is used for resources needed outside of this security zone like NTP synchronisation, but it will not be reachable until the VPN to the Remote Control Room is up and running.

LxRouter01:/#> config ip
LxRouter01:/config/ip/#> route default 10.169.5.1

Verify with show route:
LxRouter01:/config/ip/#> show route
Network          Netmask          Gateway          Iface          Dist  TrigId
==============================================================================
0.0.0.0          0.0.0.0          10.169.5.1       *                1
LxRouter01:/config/ip/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

DNS Service

By setting up the local Routers (LxRouter01 and LxRouter02) as a DNS-server proxy it can provide DNS lookup for devices within the security zone e.g., the NTP server that will need to synchronize with external NTP servers for the correct time. Again the VPN tunnel end-point address is used for the switch's search path and DNS server proxy in this example will be available for VLAN3 (Management), VLAN4 (Auth Server), VLAN6 (NMS) and VLAN8 (NTP).

LxRouter01:/#> config dns
LxRouter01:/config/dns/#> name-server 10.169.5.1
LxRouter01:/config/dns/#> server
Activating DNS server.
LxRouter01:/config/dns/server/#> listen vlan3 vlan4 vlan6 vlan8
LxRouter01:/config/dns/server/#> end

Use the show command to verify settings:
LxRouter01:/config/dns/#> show
Domain Name Nameserver(s)  : 10.169.5.1
Search path(s)             : No search paths configured
Server                     : Enabled
Listen                     : vlan3 vlan4 vlan6 vlan8
Domain forward rules       : No domain forwarding entries configured
Reject-AAAA                : Disabled
Local host table           : No host entries configured
LxRouter01:/config/dns/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Time Synchronization using NTP

In order for the certificates used in the switch to be valid and the time stamps of the logs synchronised across the network, the switches must have a common time reference. To achieve this time synchronisation, NTP will be used. By not configuring a Timezone the switch will use UTC time in the logs which means that timezone and daylights savings time are not regarded in the switches. But can be adapted in the remote syslog servers or NMS's instead. Time synchronisation for the switches and end-devices in this security zone is achieved with a local NTP server located in VLAN 8 instead of using one over the unsecured network.

LxRouter01:/#> config ntp
LxRouter01:/config/ntp/#> peer 10.5.8.3
Activating NTP Peer with default settings.
LxRouter01:/config/ntp/peer-10.5.8.3/#> end

Check configuration with the show command:
LxRouter01:/config/ntp/#> show
Status            : Enabled
Server/Client     : Client
Step Adjust     : Enabled
    Threshold   : 10.0
    Limit       : 1

Peer                 Status    Poll-interval  Preferred
==============================================================================
10.5.8.3             Enabled             600
LxRouter01:/config/ntp/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Verify that the correct time has been set with the show date command:
LxRouter01:/#> show date
Wed Dec 18 13:55:51 UTC 2024
LxRouter01:/#>

Import Certificates

Certificates are used for a number of services in the routers and switches. In this example certificates will be used for HTTPS, TCP-SSL-Syslog and OpenVPN tunnels. The Certificates needs to be present on the units before the configuration of these services can be done. As the clock of the device is now set using NTP, the certificates will be valid and not outside of the time frame set in each certificate. So uploading all certificates used would look something like this when using TFTP to upload files. The CA-certificate has the CommonName Westermo-CA but the file name is just ca (ca.crt). From now on ca will be used in the configuration steps shown when the CA-certificate is referenced.

Start by importing the CA certificate:
LxRouter01:/#> cert import pem type ca tftp://10.5.4.3/hardening-cert/ca.crt
Downloading ca.crt from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/ca.cr 100% |********************************|  1224  0:00:00 ETA
Importing certificate ca...
OK

Then proceed with uploading the WEB certificate and key for https
LxRouter01:/#> cert import pem type public tftp://10.5.4.3/hardening-cert/10.5.3.1.crt
Downloading 10.5.3.1.crt from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/10.5. 100% |********************************|  4707  0:00:00 ETA
Importing certificate 10.5.3.1...
OK
LxRouter01:/#> cert import pem type private tftp://10.5.4.3/hardening-cert/10.5.3.1.key
Downloading 10.5.3.1.key from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/10.5. 100% |********************************|  1732  0:00:00 ETA
Importing certificate 10.5.3.1...
OK

Import certifcate and key used by TCP-SSL-Syslog:
LxRouter01:/#> cert import pem type public tftp://10.5.4.3/hardening-cert/SyslogClient05-01.crt
Downloading SyslogClient05-01.crt from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/Syslo 100% |********************************|  4606  0:00:00 ETA
Importing certificate SyslogClient05-01...
OK
LxRouter01:/#> cert import pem type private tftp://10.5.4.3/hardening-cert/SyslogClient05-01.key
Downloading SyslogClient05-01.key from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/Syslo 100% |********************************|  1732  0:00:00 ETA
Importing certificate SyslogClient05-01...
OK

Finally upload the certificate and keys for the OpenVPN tunnel:
LxRouter01:/#> cert import pem type public tftp://10.5.4.3/hardening-cert/VPNClient05-01.crt
Downloading VPNClient05-01.crt from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/VPNCl 100% |********************************|  4599  0:00:00 ETA
Importing certificate VPNClient05-01...
OK
LxRouter01:/#> cert import pem type private tftp://10.5.4.3/hardening-cert/VPNClient05-01.key
Downloading VPNClient05-01.key from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/VPNCl 100% |********************************|  1732  0:00:00 ETA
Importing certificate VPNClient05-01...
OK
LxRouter01:/#> cert import ovpn tftp://10.5.4.3/hardening-cert/VPNTLSKey-05.key
Downloading VPNTLSKey-05.key from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/VPNTL 100% |********************************|   657  0:00:00 ETA
Importing certificate VPNTLSKey-05...
OK

Verify that all files have been imported correctly with the show cert command:
LxRouter01:/#> show cert
TYPE     HASH      EXPIRES      NAME
CA-local dcf124c6  Jan 15 2035  Westermo-CA
Pub      82b3d1ca  Apr 22 2027  10.5.3.1
Pub      b3f73148  May  4 2027  SyslogClient05-01
Pub      8c0a6a26  May  4 2027  VPNClient05-01
Pub      ec380826  Jan 19 2038  lynx-79-69-a0.local
Key      N/A       N/A          10_5_3_1
Key      N/A       N/A          SyslogClient05-01
Key      N/A       N/A          VPNClient05-01
Key      N/A       N/A          web-default
OVPN Key N/A       N/A          VPNTLSKey-05
LxRouter01:/#>

Secure Management

Management services are enabled and disabled per interface of the switch. This is configured from the management section of the config context. The listen command controls which management services that are allowed and on which interface.

When using management over routed links, the switch will use its upstream interface (the interface closest to the destination) as source address for any locally generated traffic e.g., SNMP traps, remote syslog messages etc. This interface on the routers will most likely not be the interface of the management VLAN. In this example the Network Monitoring System is located in the Local Control Room (VLAN6) so to not complicate things for the NMS server it will use VLAN6 as its management interface for LxRouter01 and 02 and VLAN3 for the process switches ProcSW01 and 02. By using VLAN6 all management traffic will have the same source address from the routers, otherwise SNMP polls would be directed to VLAN3 but the SNMP traps would come from VLAN6, this greatly minimize confusion for the NMS server only using one address. Management for the process subnet, VLAN12, should only use VLAN12 for management, so keep it separated from the switch management (VLAN12 will be excluded from this how-to but it should be quite straightforward to setup firewall rules etc to get this working). The Road Warrior local access will only use VLAN3 for management. The Remote Control Room will use switch management by remote controlling the NMS server itself, in this example by using an HTTPS connection.

Unsecured configuration protocols should not be allowed in the network at all, meaning that HTTP, Telnet, SNMPv1/2c etc must be disabled. WeOS supports custom certificates for HTTPS, SSH with user-keys and SNMPv3 securing management data.

Restrict Access to Switch Management

WEB Interface

HTTPS custom certificates are generated with a Subject Alt Name that should match the Common Name of the certificate, being the IP-address of the management interface on the switch. If not the WEB browser will not accept the certificate even if it is from a trusted CA and will classify the WEB page as unsecure.

With the WEB certificate uploaded to the switch (10_5_3_1), disable HTTP and setup HTTPS to only listen to the management VLAN (VLAN3) and the NMS VLAN (VLAN6). In this case the WEB certificate will be valid when accessing the WEB interface on 10.5.3.1 (VLAN3), but not to NMS VLAN6 (10.5.6.1). Accessing the WEB on 10.5.6.1 the WEB certificate will not be valid and the WEB browser will complain that the connection isn't private. It is also important to have a session timeout so the management interface automatically becomes locked if a connection is idle. The default timeout is 10 minutes, but different values can be used depending on the use-case. Apply a login banner warning users not to attempt to access the switches without proper authorization.

LxRouter01:/#> config management
LxRouter01:/config/management/#> web
LxRouter01:/config/management/web/#> no http
Deactivating http service.
LxRouter01:/config/management/web/#> HTTPS
LxRouter01:/config/management/web/HTTPS/#> listen vlan3 vlan6
LxRouter01:/config/management/web/HTTPS/#> certificate 10_5_3_1
LxRouter01:/config/management/web/HTTPS/#> end
LxRouter01:/config/management/web/#> login-banner 'WARNING!\nThis is the property of CompanyName\nUnauthorized access is strictly prohibited!'

Use the show command to verify the settings:
LxRouter01:/config/management/web/#> show
Session Timeout    : 10 min

Login Banner
▏WARNING!                                                                    ▕
▏This is the property of CompanyName                                         ▕
▏Unauthorized access is strictly prohibited!                                 ▕
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

HTTP
HTTP               : Disabled

HTTPS
HTTPS               : Enabled
Custom certificate  : 10_5_3_1
HTTPS listen ifaces : vlan3 vlan6
HTTPS port          : 443
LxRouter01:/config/management/web/#> end

LxRouter01:/config/management/#>

SNMPv3

Make sure that only SNMPv3 is allowed on the switch. SNMPv3 will protect the integrity of the SNMP data and authenticate the user. The SNMP Trap community is not used when using SNMPv3 so it can keep the default settting. Disable the lower SNMP versions simply by removing the SNMP Communities. An SNMP trap host address is set to the NMS server address (10.5.6.3) of the Local Control Room and another host for the Remote Control Room (192.168.9.3). Both SNMPv3 traps and informs are available, the example will use SNMPv3 traps. The SNMP user is configured with an authentication username and password, an encryption key and which part of the OID tree the user is allowed to access, in this example the whole tree (1). Both VLAN3 and VLAN6 will be available for SNMP polling as explained above.

LxRouter01:/config/management/#> snmp
LxRouter01:/config/management/snmp/#> listen vlan3 vlan6
LxRouter01:/config/management/snmp/#> no rocommunity
LxRouter01:/config/management/snmp/#> no rwcommunity
LxRouter01:/config/management/snmp/#> rouser LxRouter01SNMP auth sha512 SnM9L*01P4S5w@rd crypto aes256 sNM9CrY970k3y01x 1
LxRouter01:/config/management/snmp/#> host 10.5.6.3 version 3 username LxRouter01SNMP type trap
LxRouter01:/config/management/snmp/#> host 192.168.9.3 version 3 username LxRouter01SNMP type trap

Run the show command to verify that the settings are correct:
LxRouter01:/config/management/snmp/#> show
Enabled             : Enabled
SNMP Versions       : v2c, v3
Read-Only Community : Disabled
Read-Write Community: Disabled
Trap Community      : trap
IfIndex-Persistence : Disabled
Engine-ID           : auto (80003f31030011b47969a0)
Listen interfaces   : vlan3 vlan6
Command(s) allowed  :
Remote trap host(s) :
ADDRESS                                  VERS  TYPE    RESEND  USERNAME
10.5.6.3                                 3     Trap            LxRouter01SNMP
192.168.9.3                              3     Trap            LxRouter01SNMP
SNMP v3 users       :
TYPE    USERNAME          AUTH    AUTHPW            CRYPTO  CRYPTOPW          OIDTREE
rouser  LxRouter01SNMP    SHA512  SnM9L*01P4S5w@rd  AES256  sNM9CrY970k3y01x  1
LxRouter01:/config/management/snmp/#> end
LxRouter01:/config/management/#>

SSH

SSH is used for secured IP-connections to the CLI of the switch. CLI access should only be allowed from the management VLAN (VLAN3) and the NMS VLAN (VLAN6). Again a login banner that warns the user of unauthorized access is configured. An idle-timeout will be set to 300 seconds and if the wrong password is issued a wait period of 2 seconds is used.

LxRouter01:/config/management/#> ssh
LxRouter01:/config/management/ssh/#> listen vlan3 vlan6
LxRouter01:/config/management/ssh/#> login-banner 'WARNING!\nThis is the property of CompanyName\nUnauthorized access is strictly prohibited!'
LxRouter01:/config/management/ssh/#> idle-timeout 300

Check the settings with the show command:
LxRouter01:/config/management/ssh/#> show
Enabled           : Enabled
Port              : 22 (default)
Keepalive         : 60 sec (default)
Idle timeout      : 300 sec
Fail delay        : 2 sec (default)
Listen interfaces : vlan3 vlan6

Login Banner
▏WARNING!                                                                    ▕
▏This is the property of CompanyName                                         ▕
▏Unauthorized access is strictly prohibited!                                 ▕
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
LxRouter01:/config/management/ssh/#> end
LxRouter01:/config/management/#>

Serial Console

A serial console connection directly to the CLI of the switch is considered good practices as a gateway of last resort for switch access if all else fail. However this way of accessing the switch must always be protected in the same way as the other management interfaces also using a login banner.

LxRouter01:/config/management/#> console
LxRouter01:/config/management/console/#> login-banner 'WARNING!\nThis is the property of CompanyName\nUnauthorized access is strictly prohibited!'

Verify using show:
LxRouter01:/config/management/console/#> show
Console login: Enabled

Login Banner
▏WARNING!                                                                    ▕
▏This is the property of CompanyName                                         ▕
▏Unauthorized access is strictly prohibited!                                 ▕
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
LxRouter01:/config/management/console/#> end
LxRouter01:/config/management/#>

Disabling the Serial Console (Use with Caution)

The serial console connection can be disabled, but it will probably do more damage than good. So do this with caution and not until all other configuration is in place!

LxRouter01:/#> config management
LxRouter01:/config/management/#> console
LxRouter01:/config/management/console/#> no login
LxRouter01:/config/management/console/#> leave
Applying configuration.
Configuration activated.  Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#> logout

CLI (SSH and Serial Console)

Set a timeout for both the serial console connection and the SSH connection to the CLI. This will cause idle connections to be terminated automatically after the timeout limit has been reached, in this example after 300 seconds.

LxRouter01:/config/management/#> cli
LxRouter01:/config/management/cli/#> timeout 300

Verify with show:
LxRouter01:/config/management/cli/#> show
Timeout: 300 sec
LxRouter01:/config/management/cli/#> end
LxRouter01:/config/management/#>

Max Amount of Remote Sessions

Finally set a maximum amount of allowed simultaneously remote connections to the switch management. The console connection is not included (can only be one), only remote sessions over the network like SSH, WEB etc. So in this case for example one WEB connection and one SSH connection is allowed if a third connection comes in on either VLAN3 or VLAN6 it will not be allowed. Finish the management configuration by saving all settings with copy run start.

LxRouter01:/config/management/#> max-remote-sessions 2

Verify setting with the show command:
LxRouter01:/config/management/#> show
Web: Enabled (HTTP: Disabled, https Enabled)
SSH: Enabled
Telnet: Disabled
SNMP: Enabled
CLI: Enabled (timeout: 300 sec)
Console login: Enabled
Max remote sessions: 2
LxRouter01:/config/management/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

User Authentication

User authentication can be setup in two ways, local (built-in accounts) or remote (remote server) authentication. The built-in account has an administrator role but also supports Guest and Operator roles (restricted CLI). Remote server accounts support administrator roles. Authentication services of WeOS will try to authenticate users against remote servers first (when configured) if servers are unreachable or server authentication fails the built-in accounts will be tried. An SNMPv3 user is already configured in the Restrict Access to Switch Management - SNMPv3 section and this is a local account which can not be authenticated through remote servers.

User Policies

The switch supports password policies which forces users for the built-in accounts to use passwords that complies to the polices of the rest of the company. But start by setting a lockout policy. So if a user fails to login 3 times within 900 seconds the account will be locked out for 600 seconds.

LxRouter01:/#> config aaa
LxRouter01:/config/aaa/#> lockout-policy

Check setttings with the show command:
LxRouter01:/config/aaa/lockout-policy/#> show
Enable      : Disabled
Deny        : 3
Deny admin  : Enabled
Unlock time : 600
LxRouter01:/config/aaa/lockout-policy/#> end
LxRouter01:/config/aaa/#> password-policy
Activating password policy with default settings, type 'abort' to cancel.
LxRouter01:/config/aaa/password-policy/#> min-length 15
LxRouter01:/config/aaa/password-policy/#> uppercases 4
LxRouter01:/config/aaa/password-policy/#> lowercases 4
LxRouter01:/config/aaa/password-policy/#> digits 5
LxRouter01:/config/aaa/password-policy/#> specials 2
LxRouter01:/config/aaa/password-policy/#> reject-username
Enabling reject username

Verify the configuration with the show command:
LxRouter01:/config/aaa/password-policy/#> show
enable                : Enabled
min-length            : 15
uppercases            : 4
lowercases            : 4
digits                : 5
specials              : 2
reject-username       : Enabled
LxRouter01:/config/aaa/password-policy/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Users and Passwords in this How-to

These users and passwords are used as examples throughout this guide:

Remote user only: username mll747 password E*4mp!3PaSSw0Rd99
Remote and local fallback user: username les839 password P4sSw0rDe*4mP!E48
Local user only with SSH-key authentication: username nhk354 password SSH-user key
Radius server password: h4Rde*4MP!Ep4ssW0rd72
SNMPv3 users:
rouser LxRouter01SNMP auth sha512 SnM9L*01P4S5w@rd crypto aes256 sNM9CrY970k3y01x 1
rouser LxRouter02SNMP auth sha512 SnM9L*02p4s5W@rD crypto aes256 sNm9cRY970K3y02x 1
rouser ProcSW01SNMP auth sha512 P45sw@r0sNM9pR0! crypto aes256 Cry970K3YSNm901p 1
rouser ProcSW02SNMP auth sha512 p4s5W@R0SnM9pr@2 crypto aes256 crY970k3YsNM902p 1
Encrypt secrets password: C0nF!Gp4sSw@RD382
Admin passwords:
LxRouter01: sKhAWg!@2QbflT85pRqggECKgIEoZiwe*TTyXp8zuZyGglWJOoQgkYauGh3N47ob
LxRouter02: d%fOuhmu1ijCyw0gb4pdZI%NXrzDpUcQ0m0Mk!NrP*D4DRmApRPmX!gXpZ6m^ZK8
ProcSW01: 4dlOhlcR8olGy%gAwsS0Z*2MYaIVnb!v%s6BL#P%Lb#LDta0S0Q^VtpdOB^k#bPg
ProcSW02: HqkW4jLa%LCquVlHxg3x8SE3qHXBm*F1m@g#V*uaqG%1Bj&1Qu*v7IwB&O^PTKMc

Remote User Authentication

Remote Authentication Radius Server

For the remote user authentication a Radius server will be used. The configuration and the authentication to the Radius server itself is setup according to the commands below. The login context tells the switch to use server 1 as primary authentication method, but it will still fallback to built-in accounts for users that are not present on the server.

Setup the connection to the Radius server:
LxRouter01:/#> config aaa
LxRouter01:/config/aaa/#> remote-server 1
Creating new remote server 1
Error: Missing remote server password.

LxRouter01:/config/aaa/remote-server-1/#> description "Usr & PNAC Auth"
Error: Missing remote server password.

LxRouter01:/config/aaa/remote-server-1/#> password h4Rde*4MP!Ep4ssW0rd72
Error: Missing remote server address.

LxRouter01:/config/aaa/remote-server-1/#> address 10.5.4.3
LxRouter01:/config/aaa/remote-server-1/#> type radius

Verify settings with the show command:
LxRouter01:/config/aaa/remote-server-1/#> show
Server 1           : radius
Description        : Usr & PNAC Auth
Server address     : 10.5.4.3
Auth port          : Auto (1812)
Password           : h4Rde*4MP!Ep4ssW0rd72
LxRouter01:/config/aaa/remote-server-1/#> end

Set the login procedure to use the Radius server for authentication:
LxRouter01:/config/aaa/#> login
LxRouter01:/config/aaa/login/#> method server 1
LxRouter01:/config/aaa/login/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Users with Remote Authentication Only

The user mll747 will not be added to a local account as this user should only be authenticated via the Radius server, therefore it will not be added to the switch configuration at all. All configuration of this user takes place in the Radius server.

Users with Remote Authentication and Built-in Account Fallback

User les839 which will be able to both authenticate via the Radius server and to a built-in account, should the Radius server be unavailable.

LxRouter01:/#> config aaa
LxRouter01:/config/aaa/#> user les839
LxRouter01:/config/aaa/user-les839/#> password alg sha512 secret P4sSw0rDe*4mP!E48

Verify correct configuration with the show command:
LxRouter01:/config/aaa/user-les839/#> show
Status             : Enabled
Name               : les839
Role               : administrator
Hash               : $6$MLNOLvDqyPoyVhTI$2qWtPfchs8D/nrIV7Zuwyv2/9tpF1vWQetY3UfTtKQNEmVvxajDk.Gs90/5b1E4Dd6LFcqHFZLgxy0f2UB5ZE1
SSH-keys           :

LxRouter01:/config/aaa/user-les839/#> end
LxRouter01:/config/aaa/#>

Users with SSH User Key Authentication Only

SSH-User-Key authentication requires built-in accounts as they are authenticated directly in the SSH-server. They can also be combined with 802.1X authentication for port network access control (PNAC). Users that do not have a built-in account password, will only be able to login to the switch through SSH with their private key, WEB or Console access is not possible. The key is uploaded by pasting it directly to the command line when prompted. The user nhk354 do not have a password configured, only the ssh user key.

LxRouter01:/config/aaa/#> user nhk354
LxRouter01:/config/aaa/user-nhk354/#> ssh-user-key import
Paste SSH user key(s) and hit enter twice:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC01aErOz1WaaFrlgpJzIVxfX0QoTFI8X65Klx4HHkMkfilD28O7E9pe6HPt/XgEQFQc4pecSAj41LbPJJgUQCVecDspufZb9Ba/WkFjaSdMY4IZHwZpVB95H6VwuI91ardluOUWluwK7cuxFsfivERstDCq9wbq6OTOb5KcFm/jXp/A3tWaf1NoQHMPcXbfFeLzhtZ/mthlKEg/G2LYgt5aRyg9AK6n92/jBjD3A84A1C45rfYMLU2MAl9q1ZhPKap4bb/FVCrHuM91C2nrnUznwSNCgJkUkN0fniJla2U02r0KB5nb7tdp0XofDd0LKTG1muy/0kT/OB00Xdrfd2BAtOQO85nschplDzrQR9ktJPo1xSfAsDq4nGM5ysXNFXCHqieGREVKrHVB3LHdY9FuGk/yfco8bu+Q84piCuFSsMQ/AJrjof6a0mifZbp6T6R3nS2wxwadaR9ezGWRxDE2HNbtMkEEGFL6y6VrXPFUP1pfb7A8kWffqKASivdjE38+jqF8zS9V1Ar6FizjmbUsaiaisLWoL3bBDz3BaKq7QmDZ3Uu+RfZje4nzyHYjjaMn3QeK6NJl5kqM78mmiU3oXEtMxZzNnrtJI+Jg0TBS+Wis7W67mG5SMdbsAY1CKupelFdbbLwdomN5+ZCrFvdjJRpLf4q98tLKO6GWiphkQ== rsa-key-20240311

Successfully imported SSH user key(s) for nhk354

Verify correct configuration with the show command:
LxRouter01:/config/aaa/user-nhk354/#> show
Status             : Enabled
Name               : nhk354
Role               : administrator
Hash               :
SSH-keys           :
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC01aErOz1WaaFrlgpJzIVxfX0QoTFI8X65Klx4HHkMkfilD28O7E9pe6HPt/XgEQFQc4pecSAj41LbPJJgUQCVecDspufZb9Ba/WkFjaSdMY4IZHwZpVB95H6VwuI91ardluOUWluwK7cuxFsfivERstDCq9wbq6OTOb5KcFm/jXp/A3tWaf1NoQHMPcXbfFeLzhtZ/mthlKEg/G2LYgt5aRyg9AK6n92/jBjD3A84A1C45rfYMLU2MAl9q1ZhPKap4bb/FVCrHuM91C2nrnUznwSNCgJkUkN0fniJla2U02r0KB5nb7tdp0XofDd0LKTG1muy/0kT/OB00Xdrfd2BAtOQO85nschplDzrQR9ktJPo1xSfAsDq4nGM5ysXNFXCHqieGREVKrHVB3LHdY9FuGk/yfco8bu+Q84piCuFSsMQ/AJrjof6a0mifZbp6T6R3nS2wxwadaR9ezGWRxDE2HNbtMkEEGFL6y6VrXPFUP1pfb7A8kWffqKASivdjE38+jqF8zS9V1Ar6FizjmbUsaiaisLWoL3bBDz3BaKq7QmDZ3Uu+RfZje4nzyHYjjaMn3QeK6NJl5kqM78mmiU3oXEtMxZzNnrtJI+Jg0TBS+Wis7W67mG5SMdbsAY1CKupelFdbbLwdomN5+ZCrFvdjJRpLf4q98tLKO6GWiphkQ== rsa-key-20240311

LxRouter01:/config/aaa/user-nhk354/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

The Admin User

The default admin user cannot be removed from the switch so when all the configuration best practices for passwords should be set for this user, see section at the end of the LxRouter01 configuration below. WeOS 5 support password lengths of up to 64 characters. A complex password can protect this user and prevent it from being used.

Road Warrior Access

DHCP-server with Option 82

If a "Road Warrior" access is needed for a local direct connection to the management VLAN. To make the connection process a bit easier a DHCP server with Option 82 can be configured for the management port only. This will always give out the same IP-address to the connected PC which in turn allows for firewall rules to be applied accordingly regardless of which PC/User that connects (if the user is authorized).

First setup the DHCP Relay Agent to provide port information to the server:
LxRouter01:/#> config dhcp-relay
Activating DHCP-relay with default settings, type 'abort' to cancel.
dhcp-relay: Invalid settings: No listening interface defined.

LxRouter01:/config/dhcp-relay/#> server 127.0.0.1:6767
dhcp-relay: Invalid settings: No listening interface defined.

LxRouter01:/config/dhcp-relay/#> iface vlan3
LxRouter01:/config/dhcp-relay/iface-vlan3/#> port eth3
LxRouter01:/config/dhcp-relay/iface-vlan3/port-eth3/#> end
LxRouter01:/config/dhcp-relay/iface-vlan3/#> end
LxRouter01:/config/dhcp-relay/#> option82
Activating Option 82.
LxRouter01:/config/dhcp-relay/option82/#> end
LxRouter01:/config/dhcp-relay/#> show
Status          : Enabled
Server          : 127.0.0.1:6767
Udp Listen Port : 67
Force Server ID : Disabled
Option 82       : Enabled
  Remote ID     : Mac

IFACE     GIADDR
vlan3     auto

LxRouter01:/config/dhcp-relay/#> end

Then setup the DHCP server to listen to port 6767 to only pickup the Option 82 request:
LxRouter01:/config/#> dhcp-server
LxRouter01:/config/dhcp-server/#> subnet 10.5.3.0/24
Created new DHCP server for subnet 10.5.3.0.
LxRouter01:/config/dhcp-server/subnet-10.5.3.0/#> no pool
Disabling dynamic IP allocation for this subnet, only static hosts allowed.
LxRouter01:/config/dhcp-server/subnet-10.5.3.0/#> gateway 10.5.3.254
LxRouter01:/config/dhcp-server/subnet-10.5.3.0/#> name-server 10.5.3.254
LxRouter01:/config/dhcp-server/subnet-10.5.3.0/#> domain Management
LxRouter01:/config/dhcp-server/subnet-10.5.3.0/#> end
LxRouter01:/config/dhcp-server/#> server-port 6767
LxRouter01:/config/dhcp-server/#> host 1
Warning, invalid setting: Invalid host entry.

LxRouter01:/config/dhcp-server/host-1/#> match option82 circuit-id string eth3
LxRouter01:/config/dhcp-server/host-1/#> address 10.5.3.251
LxRouter01:/config/dhcp-server/host-1/#> end

Use the show command to verify the correct configuration:
LxRouter01:/config/dhcp-server/#> show
Status           : Enabled
Gateway          : Auto
Name server      : Auto
Log server       : Disabled
Ping check       : Enabled
Listening port   : 6767
Client port      : 68 (DEFAULT)
Bootfile         : Disabled
TFTP server      : Disabled
Option Force     : Disabled
Static routes    :
        No classless static routes configured.


IDX   STATIC LEASE     TYPE        IDENTIFIER            REMOTE-ID
1     10.5.3.251       Circuit-ID  eth3                  N/A

SUBNET              POOL START       POOL END         COMMENT
10.5.3.0/24         10.5.3.0         10.5.3.255       Network, pool disabled.
LxRouter01:/config/dhcp-server/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

PNAC with IEEE 802.1X

To protect the Road Warrior access port IEEE 802.1X can be enabled. As soon as a user connects a PC to this port a correct username and password must be issued or access to the network will be blocked. In this example the user will be authenticated with the Radius server located in VLAN4 (Authentication Server Subnet). It is the same server used for user autentication i.e., authentication-server 1, see remote-server 1 setup in the above section Radius Server Configuration. The switch itself will not authenticate the user but will forward the authentication request to the Radius server.

LxRouter01:/#> config port-access
No ports set.
LxRouter01:/config/port-access/#> description "Road Warrior Authentication"
No ports set.
LxRouter01:/config/port-access/#> port eth3
LxRouter01:/config/port-access/#> dot1x
Authentication server does not exist.
LxRouter01:/config/port-access/dot1x/#> authentication-server 1
LxRouter01:/config/port-access/dot1x/#> re-authenticate
LxRouter01:/config/port-access/dot1x/#> end

Check settings with the show command:
LxRouter01:/config/port-access/#> show
PORT ACCESS
Status                  : Enabled
Description             : Road Warrior Authentication
Ports                   : eth3
802.1X
  Status                : Enabled
  Authentication server : 1
  Active authentication : 30
  Re-authenticate       : 3600
MAC AUTHENTICATION
Not configured.
LxRouter01:/config/port-access/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Minimize the Attack Surface

Disable Unused Protocols

Protocols not used in the network should be disabled to ensure that the switches doesn't give out information about themselves unnecessarily that could be targeted for an attack.

Disable SSDP and MDNS

These two protocols are only needed when the switches are factory defaulted and have not yet been assigned real IP-addresses to be used in the network. So these should be disabled.

LxRouter01:/#> config discover
LxRouter01:/config/discover/#> no mdns
Deactivating mDNS service.
LxRouter01:/config/discover/#> no ssdp
Deactivating SSDP service.

Verify settings with the show command:
LxRouter01:/config/discover/#> show
Multicast DNS (mDNS) Responder
   Enabled           : Disabled
Simple Service Discovery Protocol (SSDP) for Windows(TM)
   Enabled           : Disabled
LxRouter01:/config/discover/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Disable IGMP Snooping per VLAN

In this example network, Multicast isn't used so the IGMP Snooping protocol can be disabled. IGMP Snooping is best disabled per VLAN so for all VLANs configured on the switch disable the protocol.

LxRouter01:/#> config vlan 1
LxRouter01:/config/vlan-1/#> no multicast-snooping
LxRouter01:/config/vlan-1/#> end
LxRouter01:/config/#> vlan 3
LxRouter01:/config/vlan-3/#> no multicast-snooping
LxRouter01:/config/vlan-3/#> end
LxRouter01:/config/#> vlan 4
LxRouter01:/config/vlan-4/#> no multicast-snooping
LxRouter01:/config/vlan-4/#> end
LxRouter01:/config/#> vlan 6
LxRouter01:/config/vlan-6/#> no multicast-snooping
LxRouter01:/config/vlan-6/#> end
LxRouter01:/config/#> vlan 8
LxRouter01:/config/vlan-8/#> no multicast-snooping
LxRouter01:/config/vlan-8/#> end
LxRouter01:/config/#> vlan 12
LxRouter01:/config/vlan-12/#> no multicast-snooping
LxRouter01:/config/vlan-12/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Disable the SD-card/USB-port

Unless an external storage media is needed for example for local extended logging or configuration adaptations through different config files stored on the external media this port should be disabled. This is done in the boot context and requires a reboot of the switch to activate. This setting is automatically saved so there is no need to perform a copy run start.

LxRouter01:/#> boot
LxRouter01:/boot/#> no aux-port
Disabling all auxiliary ports (reboot required)

Verify settings with the show command:
LxRouter01:/boot/#> show aux-port
AUXILIARY PORT     ACTUAL STATE     CONFIGURED STATE
sd                 ENABLED          DISABLED (reboot required)
LxRouter01:/boot/#> leave
Saving bootloader configuration to FLASH
100% / [====================================================================]
LxRouter01:/#> reboot

After reboot the actual state is disabled:
ProcSW01:/#> boot
ProcSW01:/boot/#> show aux-port
AUXILIARY PORT     ACTUAL STATE     CONFIGURED STATE
sd                 DISABLED         DISABLED
ProcSW01:/boot/#> abort
ProcSW01:/#>

Adapt LLDP

LLDP is a protocol used for discovering neighboring switches in the network or other end-devices supporting this protocol. In this example it will be enabled on all ports except for port eth9 which leads to the unsecure network. The reason for this is to not disclose information about the security zone and the boundary switches. But as LLDP can give important information about how the network is connected and the attached end-devices (if supported) it can be used for verification that the network is setup as intended within the zone.

LxRouter01:/#> config lldp
LxRouter01:/config/lldp/#> no port eth9
Disabling LLDP for port(s) eth9

Verify configuration with the show port command:
LxRouter01:/config/lldp/#> show port
PORT     ENABLED   DIRECTION
eth1     Enabled   RX and TX
eth2     Enabled   RX and TX
eth3     Enabled   RX and TX
eth4     Enabled   RX and TX
eth5     Enabled   RX and TX
eth6     Enabled   RX and TX
eth7     Enabled   RX and TX
eth8     Enabled   RX and TX
eth9     Disabled  RX and TX
eth10    Enabled   RX and TX
LxRouter01:/config/lldp/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Unwanted Types of Broadcast Traffic

To minimize the risk of damaging levels of traffic with a broadcast behavior 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. For this example no Multicast traffic will be used and a reasonable level of broadcast is expected thus the lowest limit of 64 Kbps can be used. Higher levels can also be used if it is expected as normal for the network. The ring ports will be excluded as external traffic will not be able to enter these ports without passing any of the non-ring ports first.

LxRouter01:/#> config port eth3..eth10
LxRouter01:/config/port-eth3..eth10/#> ingress-rate-limit 64k match bc,mc,u-uni
LxRouter01:/config/port-eth3..eth10/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).

Verify correct settings with the show port command:
LxRouter01:/#> show port eth3
eth3
Link           : Up
Oper. status   : Enabled
Admin status   : Enabled
Description    : eth3
Type           : 1000-T
State          : Forwarding
Alarm          : N/A
VLAN           : U:3
MAC            : 00:11:b4:79:69:a3
Autoneg        : Enabled
Speed          : 1000M
Duplex         : Full
MDI/MDIX       : Auto
MDI/MDIX status: Invalid
Polarity status: UNKNOWN
Gbit-cu-master : auto
Fastlink       : Disabled
Flow Control   : Disabled
Prio mode      : tag
Prio           : 0
Ingress limit  : 64 match u-uni,bc,mc
Egress limit   : 0 kbps
Shielded mode  : Unshielded
PHY power mode : Low power (CLASS B)
Bridge group   : Disabled

LxRouter01:/#> copy run start
LxRouter01:/#>

Patch Management

In order to apply security updates to the switches without unneccesarily disrupting normal operation of the network, Layer 3 redundancy is needed. So if LxRouter01 is being updated and rebooted, LxRouter02 will take over the role as Default Gateway in the network. For this VRRP is used to provide router redundancy. In this example the redundancy is for the router itself not for the links connecting servers etc. In the Process subnet FRNTv2 provides Layer 2 redundancy.

Layer 3 Redundancy

VRRPv3 is used for the router redundancy in each VLAN/Subnet configured that needs to provide a Default Gateway out of those Subnets. In this example VLAN3, VLAN4, VLAN6, VLAN8 and VLAN12. LxRouter01 has the role of primary router for this network and will therefore have a higher priority (150) for all of its VRRP instances than LxRouter02 (100). The no vmac setting is needed for firewall compatibility with the VRRP interfaces, so the routers will not use a shared virtual MAC but instead will announce the owernship of the IP-address with gratuitous ARPs.

LxRouter01:/#> config router
LxRouter01:/config/router/#> vrrp 3
Creating new VRRP instance: 3
Invalid settings: Interface not set.
LxRouter01:/config/router/vrrp-3/#> iface vlan3
Invalid settings: Invalid IPv4 address.
LxRouter01:/config/router/vrrp-3/#> address 10.5.3.254
Invalid settings: VRID invalid. Valid values: 1 to 255.
LxRouter01:/config/router/vrrp-3/#> vrid 3
LxRouter01:/config/router/vrrp-3/#> version 3
LxRouter01:/config/router/vrrp-3/#> priority 150
LxRouter01:/config/router/vrrp-3/#> preempt
LxRouter01:/config/router/vrrp-3/#> no vmac
LxRouter01:/config/router/vrrp-3/#> end
LxRouter01:/config/router/#> vrrp 4
Creating new VRRP instance: 4
Invalid settings: Interface not set.
LxRouter01:/config/router/vrrp-4/#> iface vlan4
Invalid settings: Invalid IPv4 address.
LxRouter01:/config/router/vrrp-4/#> address 10.5.4.254
Invalid settings: VRID invalid. Valid values: 1 to 255.
LxRouter01:/config/router/vrrp-4/#> vrid 4
LxRouter01:/config/router/vrrp-4/#> version 3
LxRouter01:/config/router/vrrp-4/#> priority 150
LxRouter01:/config/router/vrrp-4/#> preempt
LxRouter01:/config/router/vrrp-4/#> no vmac
LxRouter01:/config/router/vrrp-4/#> end
LxRouter01:/config/router/#> vrrp 6
Creating new VRRP instance: 6
Invalid settings: Interface not set.
LxRouter01:/config/router/vrrp-6/#> iface vlan6
Invalid settings: Invalid IPv4 address.
LxRouter01:/config/router/vrrp-6/#> address 10.5.6.254
Invalid settings: VRID invalid. Valid values: 1 to 255.
LxRouter01:/config/router/vrrp-6/#> vrid 6
LxRouter01:/config/router/vrrp-6/#> version 3
LxRouter01:/config/router/vrrp-6/#> priority 150
LxRouter01:/config/router/vrrp-6/#> preempt
LxRouter01:/config/router/vrrp-6/#> no vmac
LxRouter01:/config/router/vrrp-6/#> end
LxRouter01:/config/router/#> vrrp 8
Creating new VRRP instance: 8
Invalid settings: Interface not set.
LxRouter01:/config/router/vrrp-8/#> iface vlan8
Invalid settings: Invalid IPv4 address.
LxRouter01:/config/router/vrrp-8/#> address 10.5.8.254
Invalid settings: VRID invalid. Valid values: 1 to 255.
LxRouter01:/config/router/vrrp-8/#> vrid 8
LxRouter01:/config/router/vrrp-8/#> version 3
LxRouter01:/config/router/vrrp-8/#> priority 150
LxRouter01:/config/router/vrrp-8/#> preempt
LxRouter01:/config/router/vrrp-8/#> no vmac
LxRouter01:/config/router/vrrp-8/#> end
LxRouter01:/config/router/#> vrrp 12
Creating new VRRP instance: 12
Invalid settings: Interface not set.
LxRouter01:/config/router/vrrp-12/#> iface vlan12
Invalid settings: Invalid IPv4 address.
LxRouter01:/config/router/vrrp-12/#> address 10.5.12.254
Invalid settings: VRID invalid. Valid values: 1 to 255.
LxRouter01:/config/router/vrrp-12/#> vrid 12
LxRouter01:/config/router/vrrp-12/#> version 3
LxRouter01:/config/router/vrrp-12/#> priority 150
LxRouter01:/config/router/vrrp-12/#> preempt
LxRouter01:/config/router/vrrp-12/#> no vmac
LxRouter01:/config/router/vrrp-12/#> end

Use the show vrrp command to verify the settings:
LxRouter01:/config/router/#> show vrrp

VRRP Instances
ID                    Interface   Router-ID   Priority   Address
3                         vlan3           3        150   10.5.3.254
4                         vlan4           4        150   10.5.4.254
6                         vlan6           6        150   10.5.6.254
8                         vlan8           8        150   10.5.8.254
12                       vlan12          12        150   10.5.12.254
LxRouter01:/config/router/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Firmware Upgrade

Currently a firmware upgrade should be performed from the WEB interface as the upgrade process will be encrypted over HTTPS. So go to Maintenance - F/W Upgrade and select File Upload Upgrade. Then browse for your firmware file and select which firmware that should be upgraded: All, Primary, Secondary or Bootloader.

VPN Tunnels

Data conduits\VPN tunnels are absolutely essential for protecting data over unsecure networks. It can protect protocols that do not have any built-in security. It is important to control which data that goes in and out of the tunnel through packet filtering as the vpn itself do not have this ability, it just encrypts and decrypts data destined to and received from the other side. In this example OpenVPN tunnels are used for data that needs to be forwarded over the unsecure network towards the Remote Control Room.

OpenVPN Tunnels

WeOS 5 OpenVPN tunnels supports PSK or Certificate authentication, this example will show the later. The certificates have already been uploaded to the switch, see the section Import Certificates above. Both LxRouters will act as OpenVPN clients and the OpenVPN server is located in the Remote Control Room.

There are of course several different ways to configure this tunnel, the server can push out the networks accessible etc but as this is a static net to net tunnel the settings will also be static. It gives a little bit more control of what is allowed over the tunnel or not by making packet filtering easier.

LxRouter01:/#> config tunnel ssl 1
Creating new SSL tunnel 1, check your settings before activating the tunnel!
ssl1: Invalid settings: No certificate selected.

LxRouter01:/config/tunnel/ssl-1/#> method certificates
ssl1: Invalid settings: No certificate selected.

LxRouter01:/config/tunnel/ssl-1/#> certificate VPNClient05-01
ssl1: Invalid settings: No CA certificate selected.

LxRouter01:/config/tunnel/ssl-1/#> ca-certificate ca
LxRouter01:/config/tunnel/ssl-1/#> no server
ssl1: Invalid settings: Invalid peer address.

LxRouter01:/config/tunnel/ssl-1/#> peer 172.16.9.33
LxRouter01:/config/tunnel/ssl-1/#> no compression
LxRouter01:/config/tunnel/ssl-1/#> data-ciphers aes-256-cbc
LxRouter01:/config/tunnel/ssl-1/#> tls-auth label VPNTLSKey-05 direction 1
LxRouter01:/config/tunnel/ssl-1/#> tls-version-min 1.3

Check settings with the show command:
LxRouter01:/config/tunnel/ssl-1/#> show
Tunnel #                      : 1
Description                   : ssl1
Status                        : Enabled
Server/Client                 : Client
Type                          : tap
Remote peer                   : 172.16.9.33
Pull settings                 : Enabled
Renegotiate                   : 3600 seconds
Keepalive                     : interval 10 restart 60
Port                          : 1194
Compression                   : no
Data Ciphers                  : aes-256-cbc
Data Ciphers Fallback         : None
Authentication hash           : sha256
Protocol                      : udp
Identity                      : None
TLS authentication            : label VPNTLSKey-05 direction 1
TLS minimum version           : 1.3

Method                        : certificates
Local certificate             : VPNClient05-01
CA certificate                : ca
LxRouter01:/config/tunnel/ssl-1/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

As the tunnel will use static configuration only, the tunnel interface ssl0 will need to have a tunnel IP-address configured manually. There are two OpenVPN tunnels coming from Process network 5 so a /29 subnet mask is used for the tunnel end-points. This gives six usable host IP-adresses, 10.169.5.1 for the server, .5.2 and .5.3 for the clients.

LxRouter01:/#> config iface ssl1
LxRouter01:/config/iface-ssl1/#> inet static 10.169.5.2/29
LxRouter01:/config/iface-ssl1/inet-static-10.169.5.2/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Network Monitoring

Alarms

Having the switches themselves signaling abnormal events in the network is crucial from a security point of view. Link-alarms, Power Source failure and Digital-In are used as examples here but a lot of other alarms are also available, like temperature alarm. Link-alarms can be used both for ports that are normally up and ports that are normally down. Normally up ports going down is important to be notified about so the link can be fixed as soon as possible. But also to make sure that it isn't a sign of a physical intrusion attempt. For example if a downed port quickly comes back up again, which could indicate that someone has added a device to the network. Normally down ports would have an abnormal state if it suddenly comes up, in this example the Road Warrior port eth3 will indicate link up status with an alarm, but also the disabled ports eth5, eth7 and eth10. Alarms can be signalled in different ways, this example network use SNMP-traps, Remote Syslog Messages and will indicate with the ON LED of the switch itself that an alarm is active by turning red.

Configure how to signal an active alarm, in this case via SNMP-traps, Syslog Messages and turn the ON LED red:
LxRouter01:/#> config alarm
LxRouter01:/config/alarm/#> action 1
LxRouter01:/config/alarm/action-1/#> no target
Action 1: No targets selected

LxRouter01:/config/alarm/action-1/#> target snmp log led

Check settings with the show command:
LxRouter01:/config/alarm/action-1/#> show
ID            : 1
Targets       : snmp log led
LxRouter01:/config/alarm/action-1/#> end

Configure a link-alarm with condition down for the normally up ports i.e., the alarm state is when the port goes down:
LxRouter01:/config/alarm/#> trigger link-alarm
LxRouter01:/config/alarm/trigger-1/#> action 1
LxRouter01:/config/alarm/trigger-1/#> condition down
LxRouter01:/config/alarm/trigger-1/#> port eth1..eth2, eth4, eth6, eth8..eth9

Verify configuration with the show command:
LxRouter01:/config/alarm/trigger-1/#> show
ID              : 1
Type            : Link-Alarm
Status          : Enabled
Port            : eth1..eth2, eth4, eth6, eth8..eth9
Severity        : active Warning, inactive Notice
Condition       : Low
Action          : 1
LxRouter01:/config/alarm/trigger-1/#> end

Configure a link-alarm for the normally down ports with condition up i.e., the alarm state is when the port goes up:
LxRouter01:/config/alarm/#> trigger link-alarm
LxRouter01:/config/alarm/trigger-2/#> action 1
LxRouter01:/config/alarm/trigger-2/#> condition up
LxRouter01:/config/alarm/trigger-2/#> port eth3, eth5, eth7, eth10

Verify configuration with the show command:
LxRouter01:/config/alarm/trigger-2/#> show
ID              : 2
Type            : Link-Alarm
Status          : Enabled
Port            : eth3, eth5, eth7, eth10
Severity        : active Warning, inactive Notice
Condition       : High
Action          : 1
LxRouter01:/config/alarm/trigger-2/#> end

The Digital-In connetor can be used for signalling physical events that occurs around the switch e.g., someone opens the cabinet door or some end-device that has an alarm relay that is triggered. The switch can then turn this physical event into a digital alarm through SNMP-traps and Syslog Messages:
LxRouter01:/config/alarm/#> trigger digin
LxRouter01:/config/alarm/trigger-3/#> action 1
LxRouter01:/config/alarm/trigger-3/#> condition down

Verify configuration using the show command:
LxRouter01:/config/alarm/trigger-3/#> show
ID              : 3
Type            : Digin
Status          : Enabled
Sensor          : 1
Severity        : active Warning, inactive Notice
Condition       : Low
Action          : 1
LxRouter01:/config/alarm/trigger-3/#> end

The switch has dual power input which means that it can have a primary power source and a battery backup as secondary power source. If the primary source would fail the secondary will seamlessly take over so it is important to receive a notification of this so the primary source can be fixed before the battery runs out:
LxRouter01:/config/alarm/#> trigger power
LxRouter01:/config/alarm/trigger-4/#> action 1
LxRouter01:/config/alarm/trigger-4/#> condition down

Check the settings with the show command:
LxRouter01:/config/alarm/trigger-4/#> show
ID              : 4
Type            : Power
Status          : Enabled
Sensor          : 1,2
Severity        : active Warning, inactive Notice
Condition       : Low
Action          : 1
LxRouter01:/config/alarm/trigger-4/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

SNMP Traps

SNMP trap configuration has already been completed in the Secure Management section where both the SNMPv3 user and SNMPv3-trap hosts have been set.

Remote Syslog

Remote Syslog messages will be able to provide more information about the switch than SNMP-traps can. As SNMP-traps are tied to the alarms that triggers the trap whereas the Remote Syslog will send all log messages or a selection based on filters configured. Destinations configured where to send messages and how. By using TCP-SSL-Syslog, authentication and encryption can be added to protect the integrity of the log messages sent over the network. In this example network, Remote Syslog messages will be sent both to the Local Control Room as well as to the Remote Control Room. The destinations will then be used by a sink to collect the logs and send them to the defined destinations. Filters can be added to control which messages to forward to the remote servers, no filter means that all messages will be sent. To make the filter configuration a bit easier you can use the invert command. So if all levels but debug i.e., notice and all above is to be sent to the server, debug is set as the level and invert sets all levels but debug.

LxRouter01:/#> config logging
LxRouter01:/config/logging/#> destination rsyslogLclCtrl

╒ Configuration Errors: 2 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No destination file name specified.                                     │
├────────────────────────────────────────────────────────────────────────────┤
│2   No destination media name specified.                                    │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/destination-rsyslogLclCtrl/#> type remote

╒ Configuration Errors: 2 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No remote host specified for the destination.                           │
├────────────────────────────────────────────────────────────────────────────┤
│2   No CA certificate label specified, necessary for validation of peer.    │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/destination-rsyslogLclCtrl/#> host address 10.5.6.3

╒ Configuration Errors: 1 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No CA certificate label specified, necessary for validation of peer.    │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/destination-rsyslogLclCtrl/#> ca-certificate ca

╒ Configuration Warnings: 1 ═════════════════════════════════════════════════╕
│#   Description                                                             │
│1   It is recommended that the configuration uses a certificate for secure  │
│    communication. Without a certificate, the other end of the connection   │
│    cannot verify the identity of this connecting device. However, this is  │
│    also dependant on how the other end of the connection is configured.    │
│    It may or may not require a certificate. If it does, the connection     │
│    will not be established without one.                                    │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/destination-rsyslogLclCtrl/#> certificate SyslogClient05-01
LxRouter01:/config/logging/destination-rsyslogLclCtrl/#> end
LxRouter01:/config/logging/#> destination rsyslogRemCtrl

╒ Configuration Errors: 2 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No destination file name specified.                                     │
├────────────────────────────────────────────────────────────────────────────┤
│2   No destination media name specified.                                    │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/destination-rsyslogRemCtrl/#> type remote

╒ Configuration Errors: 2 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No remote host specified for the destination.                           │
├────────────────────────────────────────────────────────────────────────────┤
│2   No CA certificate label specified, necessary for validation of peer.    │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/destination-rsyslogRemCtrl/#> host address 192.168.9.3

╒ Configuration Errors: 1 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No CA certificate label specified, necessary for validation of peer.    │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/destination-rsyslogRemCtrl/#> ca-certificate ca

╒ Configuration Warnings: 1 ═════════════════════════════════════════════════╕
│#   Description                                                             │
│1   It is recommended that the configuration uses a certificate for secure  │
│    communication. Without a certificate, the other end of the connection   │
│    cannot verify the identity of this connecting device. However, this is  │
│    also dependant on how the other end of the connection is configured.    │
│    It may or may not require a certificate. If it does, the connection     │
│    will not be established without one.                                    │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/destination-rsyslogRemCtrl/#> certificate SyslogClient05-01
LxRouter01:/config/logging/destination-rsyslogRemCtrl/#> end
LxRouter01:/config/logging/#> filter rsyslogFilter

╒ Configuration Errors: 1 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No filter type specified, need at least one.                            │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/filter-rsyslogFilter/#> level debug
LxRouter01:/config/logging/filter-rsyslogFilter/#> invert
LxRouter01:/config/logging/filter-rsyslogFilter/#> end
LxRouter01:/config/logging/#> sink rsyslogSink

╒ Configuration Errors: 2 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No sources specified, at least one is necessary.                        │
├────────────────────────────────────────────────────────────────────────────┤
│2   No destinations specified, at least one is necessary.                   │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/sink-rsyslogSink/#> source local

╒ Configuration Errors: 1 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No destinations specified, at least one is necessary.                   │
└────────────────────────────────────────────────────────────────────────────┘
LxRouter01:/config/logging/sink-rsyslogSink/#> destination rsyslogLclCtrl
LxRouter01:/config/logging/sink-rsyslogSink/#> destination rsyslogRemCtrl
LxRouter01:/config/logging/sink-rsyslogSink/#> filter rsyslogFilter
LxRouter01:/config/logging/sink-rsyslogSink/#> end

Verify settings with the show command:
LxRouter01:/config/logging/#> show
Console syslog   : Disabled
External logging : Disabled
Secure mode      : Enabled

╒ Sources ═══════════════════════════════════════════════════════════════════╕
│NAME                                                                        │
│Type: local      USERSPACE  KERNEL                                          │
│local            Yes        Yes                                             │
└────────────────────────────────────────────────────────────────────────────┘

╒ Destinations ══════════════════════════════════════════════════════════════╕
│NAME                                                                        │
│Type: remote     TRANSPORT  TO-HOST      PORT   FORMAT                      │
│rsyslogLclCtrl   tls        10.5.6.3     6514   rfc5424                     │
│rsyslogRemCtrl   tls        192.168.9.3  6514   rfc5424                     │
└────────────────────────────────────────────────────────────────────────────┘

╒ Filters ═══════════════════════════════════════════════════════════════════╕
│NAME             INVERT        TYPE  FILTER                                 │
│rsyslogFilter    Yes          Level  debug                                  │
└────────────────────────────────────────────────────────────────────────────┘

╒ Sinks ═════════════════════════════════════════════════════════════════════╕
│NAME             SOURCES       DESTINATIONS     OP FILTERS                  │
│rsyslogSink      local         rsyslogLclCtrl      rsyslogFilter            │
│                               rsyslogRemCtrl                               │
└────────────────────────────────────────────────────────────────────────────┘

LxRouter01:/config/logging/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Test and Verification

The main part of the configuration is completed so now is a good time to configure the rest of the switches in the network LxRouter02, ProcSW01 and 02. Connect everything and start testing that all aspects of the network are working properly before continuing with the Firewall/Packet Filter setup.

Packet Filter/Firewall

When configuring the firewall it is extremely important to know from where traffic is initiated as this is the starting point of the rules that needs to be setup. The firewall should always have the default policy as drop so only traffic with an allow rule can pass the filter, all other traffic will be dropped. Traffic generated by the switch itself is always allowed out so no rules allowing this is needed, this can be SNMP-traps, protocol synchronization traffic etc. But incoming traffic will be dropped unless allow rules are configured. The firewall has Input rules and Forwarding rules. Input rules are for traffic directed to the switch itself, SNMP polls, protocol synchronization traffic, SSH etc. Forwarding rules are for traffic that should be routed i.e., moved from one subnet to another.

Assymetric Routing

The firewall will effectively block traffic that it is unaware of i.e., not part of the registered active states. This becomes escpecially important when using redundant routers. So traffic that comes in over one router but the reply traffic goes back out over the other router, so called asymmetric routing won't be allowed by the firewall. Which means that both request and reply must traverse the same router and firewall.

This will become an issue when traffic generated from a subnet which both routers have as a directly connected network (can be seen with the command show ip route). The router will not reply back to the interface the request came in on but reply out on the directly connected interface and thus it will be blocked by the firewall.

The Management traffic in this network will be affected by assymetric routing when the NMS server (10.5.6.3) tries to connect to the Management subnet and LxRouter01 and 02 (10.5.3.1 and 10.5.3.2). The problem occurs when addressing LxRouter02 as the traffic will come in from VLAN3, over LxRouter01, to 10.5.3.2 but the source address is from VLAN6 (10.5.6.3). As VLAN6 is directly connected to LxRouter02 it will try to reply back out to VLAN6 rather than replying back to VLAN3 and back over LxRouter01. To mitigate this, the NMS server will use the VLAN6 addresses of LxRouter01 and 02 for management (10.5.6.1 and 10.5.6.2) which both routers have as a directly connected network. See also the Secure Management section.

LxRouter01:/#> config ip
LxRouter01:/config/ip/#> firewall
LxRouter01:/config/ip/firewall/#>


Input Rules:

Allow all VRRP synch traffic in on all interfaces running VRRP:
LxRouter01:/config/ip/firewall/#> input accept in vlan3 saddr 10.5.3.2/32 daddr 224.0.0.18/32 proto carp comment "Pass VRRP sync VLAN3"
LxRouter01:/config/ip/firewall/#> input accept in vlan4 saddr 10.5.4.2/32 daddr 224.0.0.18/32 proto carp comment "Pass VRRP sync VLAN4"
LxRouter01:/config/ip/firewall/#> input accept in vlan6 saddr 10.5.6.2/32 daddr 224.0.0.18/32 proto carp comment "Pass VRRP sync VLAN6"
LxRouter01:/config/ip/firewall/#> input accept in vlan8 saddr 10.5.8.2/32 daddr 224.0.0.18/32 proto carp comment "Pass VRRP sync VLAN8"
LxRouter01:/config/ip/firewall/#> input accept in vlan12 saddr 10.5.12.2/32 daddr 224.0.0.18/32 proto carp comment "Pass VRRP sync VLAN12"

Allow Management and Ping to the switch from the Primary Road Warrior PC directly connected to the Management VLAN of LxRouter01:
LxRouter01:/config/ip/firewall/#> input accept in vlan3 saddr 10.5.3.251/32 daddr 10.5.3.1/32 proto icmp comment "Pass in ICMP fr RdWarPC1"
LxRouter01:/config/ip/firewall/#> input accept in vlan3 saddr 10.5.3.251/32 daddr 10.5.3.1/32 dport 22 proto tcp comment "Pass in SSH fr RdWarPC1"
LxRouter01:/config/ip/firewall/#> input accept in vlan3 saddr 10.5.3.251/32 daddr 10.5.3.1/32 dport 443 proto tcp comment "Pass in HTTPS fr RdWarPC1"

Allow Management and Ping to the switch from the Backup Road Warrior PC directly connected to the Management VLAN of LxRouter02:
LxRouter01:/config/ip/firewall/#> input accept in vlan3 saddr 10.5.3.252/32 daddr 10.5.3.1/32 proto icmp comment "Pass in ICMP fr RdWarPC2"
LxRouter01:/config/ip/firewall/#> input accept in vlan3 saddr 10.5.3.252/32 daddr 10.5.3.1/32 dport 22 proto tcp comment "Pass in SSH fr RdWarPC2"
LxRouter01:/config/ip/firewall/#> input accept in vlan3 saddr 10.5.3.252/32 daddr 10.5.3.1/32 dport 443 proto tcp comment "Pass in HTTPS fr RdWarPC2"

Allow Management,Ping and SNMP to the switch from the Network Management System located in the VLAN6 subnet:
LxRouter01:/config/ip/firewall/#> input accept in vlan6 saddr 10.5.6.3/32 daddr 10.5.6.1/32 proto icmp comment "Pass in ICMP fr NMSSrv"
LxRouter01:/config/ip/firewall/#> input accept in vlan6 saddr 10.5.6.3/32 daddr 10.5.6.1/32 dport 22 proto tcp comment "Pass in SSH fr NMSSrv"
LxRouter01:/config/ip/firewall/#> input accept in vlan6 saddr 10.5.6.3/32 daddr 10.5.6.1/32 dport 443 proto tcp comment "Pass in HTTPS fr NMSSrv"
LxRouter01:/config/ip/firewall/#> input accept in vlan6 saddr 10.5.6.3/32 daddr 10.5.6.1/32 dport 161 proto udp comment "Pass in SNMP poll fr NMSSrv"

Allow incoming DNS requests for patch management, NTP synch etc:
LxRouter01:/config/ip/firewall/#> input accept in vlan3 saddr 10.5.3.251/32 daddr 10.5.3.254/32 dport 53 proto udp comment "Pass in DNS req fr RdWarPC1"
LxRouter01:/config/ip/firewall/#> input accept in vlan4 saddr 10.5.4.3/32 daddr 10.5.4.254/32 dport 53 proto udp comment "Pass in DNS req fr AuthSrv"
LxRouter01:/config/ip/firewall/#> input accept in vlan6 saddr 10.5.6.3/32 daddr 10.5.6.254/32 dport 53 proto udp comment "Pass in DNS req fr NMSSrv"
LxRouter01:/config/ip/firewall/#> input accept in vlan8 saddr 10.5.8.3/32 daddr 10.5.8.254/32 dport 53 proto udp comment "Pass in DNS req fr NTPSrv"

Allow icmp route probes over the OpenVPN tunnel from the Remote Control Room router:
LxRouter01:/config/ip/firewall/#> input accept in ssl1 saddr 10.169.5.1/32 daddr 10.169.5.2/32 proto icmp comment "Pass ICMP between SSL tun if"

Allow DHCP requests that comes in over the Loopback interface when using a DHCP Relay Agent and DHCP Server in the same router:
LxRouter01:/config/ip/firewall/#> input accept in lo dport 67 proto udp comment "Pass in DHCP req via RelayAgent"


Forwarding Rules:

Allow Time Synch (NTP) from Management and Server subnets to VLAN8 NTP-server subnet:
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan8 saddr 10.5.3.0/24 daddr 10.5.8.3/32 dport 123 proto udp comment "Pass NTP fr VLAN3 to VLAN8"
LxRouter01:/config/ip/firewall/#> forward accept in vlan4 out vlan8 saddr 10.5.4.3/32 daddr 10.5.8.3/32 dport 123 proto udp comment "Pass NTP fr AuthSrv to VLAN8"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan8 saddr 10.5.6.3/24 daddr 10.5.8.3/32 dport 123 proto udp comment "Pass NTP fr NMSSrv to VLAN8"

Allow the NTP server to access Internet via the OpenVPN tunnel for Time Synch (NTP) and Ping:
LxRouter01:/config/ip/firewall/#> forward accept in vlan8 out ssl1 saddr 10.5.8.3/32 dport 123 proto udp comment "Pass NTP fr VLAN8 to Internet"
LxRouter01:/config/ip/firewall/#> forward accept in vlan8 out ssl1 saddr 10.5.8.3/32 proto icmp comment "Pass ICMP fr NTPSrv to Internet"

Allow Management and Ping from the Primary Road Warrior PC to all servers:
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan4 saddr 10.5.3.251/32 daddr 10.5.4.3/32 proto icmp comment "Pass ICMP fr RdWPC1 to AuthSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan6 saddr 10.5.3.251/32 daddr 10.5.6.3/32 proto icmp comment "Pass ICMP fr RdWPC1 to NMSSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan8 saddr 10.5.3.251/32 daddr 10.5.8.3/32 proto icmp comment "Pass ICMP fr RdWPC1 to NTPSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan4 saddr 10.5.3.251/32 daddr 10.5.4.3/32 dport 22 proto tcp comment "Pass SSH fr RdWPC1 to AuthSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan6 saddr 10.5.3.251/32 daddr 10.5.6.3/32 dport 22 proto tcp comment "Pass SSH fr RdWPC1 to NMSSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan6 saddr 10.5.3.251/32 daddr 10.5.6.3/32 dport 443 proto tcp comment "Pass HTTPS fr RdWPC1 to NMSSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan8 saddr 10.5.3.251/32 daddr 10.5.8.3/32 dport 22 proto tcp comment "Pass SSH fr RdWPC1 to NTPSrv"

Allow Management, Ping and SNMP from the NMS server to the Management VLAN and the servers:
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan3 saddr 10.5.6.3/32 daddr 10.5.3.0/24 proto icmp comment "Pass ICMP fr NMSSrv to VLAN3"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan4 saddr 10.5.6.3/32 daddr 10.5.4.3/32 proto icmp comment "Pass ICMP fr NMSSrv to AuthSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan8 saddr 10.5.6.3/32 daddr 10.5.8.3/32 proto icmp comment "Pass ICMP fr NMSSrv to NTPSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan3 saddr 10.5.6.3/32 daddr 10.5.3.0/24 dport 22 proto tcp comment "Pass SSH fr NMSSrv to VLAN3"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan3 saddr 10.5.6.3/32 daddr 10.5.3.0/24 dport 443 proto tcp comment "Pass HTTPS fr NMSSrv to VLAN3"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan4 saddr 10.5.6.3/32 daddr 10.5.4.3/32 dport 22 proto tcp comment "Pass SSH fr NMSSrv to AuthSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan8 saddr 10.5.6.3/32 daddr 10.5.8.3/32 dport 22 proto tcp comment "Pass SSH fr NMSSrv to NTPSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan3 saddr 10.5.6.3/32 daddr 10.5.3.0/24 dport 161 proto udp comment "Pass SNMP fr NMSSrv to VLAN3"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan4 saddr 10.5.6.3/32 daddr 10.5.4.3/32 dport 161 proto udp comment "Pass SNMP fr NMSSrv to AuthSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out vlan8 saddr 10.5.6.3/32 daddr 10.5.8.3/32 dport 161 proto udp comment "Pass SNMP fr NMSSrv to NTPSrv"

Allow SNMP-traps, Remote Syslog messages from Management VLAN and the servers to the NMS server:
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan6 saddr 10.5.3.0/24 daddr 10.5.6.3/32 dport 162 proto udp comment "Pass SNMPtrp fr VLAN3 to NMSSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan6 saddr 10.5.3.0/24 daddr 10.5.6.3/32 dport 6514 proto tcp comment "Pass Syslog fr VLAN3 to NMSSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan4 out vlan6 saddr 10.5.4.3/32 daddr 10.5.6.3/32 dport 6514 proto tcp comment "Pass Syslog fr AutSrv to NMSSrv"
LxRouter01:/config/ip/firewall/#> forward accept in vlan8 out vlan6 saddr 10.5.8.3/32 daddr 10.5.6.3/32 dport 6514 proto tcp comment "Pass Syslog fr NTPSrv to NMSSrv"

Allow SNMP-traps and Remote Syslog messages from the Management VLAN to the Remote Control Room:
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out ssl1 saddr 10.5.3.0/24 daddr 192.168.9.3/32 dport 162 proto udp comment "Pass SNMPtrp fr VLAN3 to RmCtrl"
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out ssl1 saddr 10.5.3.0/24 daddr 192.168.9.3/32 dport 6514 proto tcp comment "Pass Syslog fr VLAN3 to RemCtrl"

Allow Management from the Remote Control Room to the Local Control Room NMS server:
LxRouter01:/config/ip/firewall/#> forward accept in ssl1 out vlan6 saddr 192.168.9.3/32 daddr 10.5.6.3/32 dport 443 proto tcp comment "Pass HTTPS fr RemCtrl t LclCtrl"
LxRouter01:/config/ip/firewall/#> forward accept in ssl1 out vlan6 saddr 192.168.9.3/32 daddr 10.5.6.3/32 dport 22 proto tcp comment "Pass SSH fr RemCtrl to LclCtrl"

Allow Radius Authentication from the Management VLAN to the Radius Server:
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out vlan4 saddr 10.5.3.0/24 daddr 10.5.4.3/32 dport 1812 proto udp comment "Pass RADIUS fr VLAN3 to AutSrv"

Allow HTTPS from the Primary Road Warrior PC and the NMS server to the Remote Control Room for patch management:
LxRouter01:/config/ip/firewall/#> forward accept in vlan3 out ssl1 saddr 10.5.3.251/32 dport 443 proto tcp comment "Pass HTTPS fr RdWPC1 to ReCtrl"
LxRouter01:/config/ip/firewall/#> forward accept in vlan6 out ssl1 saddr 10.5.6.3/32 dport 443 proto tcp comment "Pass HTTPS fr NMSSrv to RemCtrl"

Do not forget to enable the firewall filter:
LxRouter01:/config/ip/firewall/#> enable

Verify that the firewall is enabled and that the firewall rules are correct with the show command:
LxRouter01:/config/ip/firewall/#> show
Firewall is enabled.
Logging is Enabled, no rate limitation

Input Rules
Pos Rule
001 input accept in vlan3 saddr 10.5.3.2/32 daddr 224.0.0.18/32 proto carp
    "Pass VRRP sync VLAN3"
002 input accept in vlan4 saddr 10.5.4.2/32 daddr 224.0.0.18/32 proto carp
    "Pass VRRP sync VLAN4"
003 input accept in vlan6 saddr 10.5.6.2/32 daddr 224.0.0.18/32 proto carp
    "Pass VRRP sync VLAN6"
004 input accept in vlan8 saddr 10.5.8.2/32 daddr 224.0.0.18/32 proto carp
    "Pass VRRP sync VLAN8"
005 input accept in vlan12 saddr 10.5.12.2/32 daddr 224.0.0.18/32 proto carp
    "Pass VRRP sync VLAN12"
006 input accept in vlan3 saddr 10.5.3.251/32 daddr 10.5.3.1/32 proto icmp
    "Pass in ICMP fr RdWarPC1"
007 input accept in vlan3 saddr 10.5.3.251/32 daddr 10.5.3.1/32 dport 22 proto tcp
    "Pass in SSH fr RdWarPC1"
008 input accept in vlan3 saddr 10.5.3.251/32 daddr 10.5.3.1/32 dport 443 proto tcp
    "Pass in HTTPS fr RdWarPC1"
009 input accept in vlan3 saddr 10.5.3.252/32 daddr 10.5.3.1/32 proto icmp
    "Pass in ICMP fr RdWarPC2"
010 input accept in vlan3 saddr 10.5.3.252/32 daddr 10.5.3.1/32 dport 22 proto tcp
    "Pass in SSH fr RdWarPC2"
011 input accept in vlan3 saddr 10.5.3.252/32 daddr 10.5.3.1/32 dport 443 proto tcp
    "Pass in HTTPS fr RdWarPC2"
012 input accept in vlan6 saddr 10.5.6.3/32 daddr 10.5.6.1/32 proto icmp
    "Pass in ICMP fr NMSSrv"
013 input accept in vlan6 saddr 10.5.6.3/32 daddr 10.5.6.1/32 dport 22 proto tcp
    "Pass in SSH fr NMSSrv"
014 input accept in vlan6 saddr 10.5.6.3/32 daddr 10.5.6.1/32 dport 443 proto tcp
    "Pass in HTTPS fr NMSSrv"
015 input accept in vlan6 saddr 10.5.6.3/32 daddr 10.5.6.1/32 dport 161 proto udp
    "Pass in SNMP poll fr NMSSrv"
016 input accept in vlan3 saddr 10.5.3.251/32 daddr 10.5.3.254/32 dport 53 proto udp
    "Pass in DNS req fr RdWarPC1"
017 input accept in vlan4 saddr 10.5.4.3/32 daddr 10.5.4.254/32 dport 53 proto udp
    "Pass in DNS req fr AuthSrv"
018 input accept in vlan6 saddr 10.5.6.3/32 daddr 10.5.6.254/32 dport 53 proto udp
    "Pass in DNS req fr NMSSrv"
019 input accept in vlan8 saddr 10.5.8.3/32 daddr 10.5.8.254/32 dport 53 proto udp
    "Pass in DNS req fr NTPSrv"
020 input accept in ssl1 saddr 10.169.5.1/32 daddr 10.169.5.2/32 proto icmp
    "Pass ICMP between SSL tun if"
021 input accept in lo dport 67 proto udp
    "Pass in DHCP req via RelayAgent"
N/A drop


Forward Rules
Pos Rule
001 forward accept in vlan3 out vlan8 saddr 10.5.3.0/24 daddr 10.5.8.3/32 dport 123 proto udp
    "Pass NTP fr VLAN3 to VLAN8"
002 forward accept in vlan4 out vlan8 saddr 10.5.4.3/32 daddr 10.5.8.3/32 dport 123 proto udp
    "Pass NTP fr AuthSrv to VLAN8"
003 forward accept in vlan6 out vlan8 saddr 10.5.6.0/24 daddr 10.5.8.3/32 dport 123 proto udp
    "Pass NTP fr NMSSrv to VLAN8"
004 forward accept in vlan8 out ssl1 saddr 10.5.8.3/32 dport 123 proto udp
    "Pass NTP fr VLAN8 to Internet"
005 forward accept in vlan8 out ssl1 saddr 10.5.8.3/32 proto icmp
    "Pass ICMP fr NTPSrv to Internet"
006 forward accept in vlan3 out vlan4 saddr 10.5.3.251/32 daddr 10.5.4.3/32 proto icmp
    "Pass ICMP fr RdWPC1 to AuthSrv"
007 forward accept in vlan3 out vlan6 saddr 10.5.3.251/32 daddr 10.5.6.3/32 proto icmp
    "Pass ICMP fr RdWPC1 to NMSSrv"
008 forward accept in vlan3 out vlan8 saddr 10.5.3.251/32 daddr 10.5.8.3/32 proto icmp
    "Pass ICMP fr RdWPC1 to NTPSrv"
009 forward accept in vlan3 out vlan4 saddr 10.5.3.251/32 daddr 10.5.4.3/32 dport 22 proto tcp
    "Pass SSH fr RdWPC1 to AuthSrv"
010 forward accept in vlan3 out vlan6 saddr 10.5.3.251/32 daddr 10.5.6.3/32 dport 22 proto tcp
    "Pass SSH fr RdWPC1 to NMSSrv"
011 forward accept in vlan3 out vlan6 saddr 10.5.3.251/32 daddr 10.5.6.3/32 dport 443 proto tcp
    "Pass HTTPS fr RdWPC1 to NMSSrv"
012 forward accept in vlan3 out vlan8 saddr 10.5.3.251/32 daddr 10.5.8.3/32 dport 22 proto tcp
    "Pass SSH fr RdWPC1 to NTPSrv"
013 forward accept in vlan6 out vlan3 saddr 10.5.6.3/32 daddr 10.5.3.0/24 proto icmp
    "Pass ICMP fr NMSSrv to VLAN3"
014 forward accept in vlan6 out vlan4 saddr 10.5.6.3/32 daddr 10.5.4.3/32 proto icmp
    "Pass ICMP fr NMSSrv to AuthSrv"
015 forward accept in vlan6 out vlan8 saddr 10.5.6.3/32 daddr 10.5.8.3/32 proto icmp
    "Pass ICMP fr NMSSrv to NTPSrv"
016 forward accept in vlan6 out vlan3 saddr 10.5.6.3/32 daddr 10.5.3.0/24 dport 22 proto tcp
    "Pass SSH fr NMSSrv to VLAN3"
017 forward accept in vlan6 out vlan3 saddr 10.5.6.3/32 daddr 10.5.3.0/24 dport 443 proto tcp
    "Pass HTTPS fr NMSSrv to VLAN3"
018 forward accept in vlan6 out vlan4 saddr 10.5.6.3/32 daddr 10.5.4.3/32 dport 22 proto tcp
    "Pass SSH fr NMSSrv to AuthSrv"
019 forward accept in vlan6 out vlan8 saddr 10.5.6.3/32 daddr 10.5.8.3/32 dport 22 proto tcp
    "Pass SSH fr NMSSrv to NTPSrv"
020 forward accept in vlan6 out vlan3 saddr 10.5.6.3/32 daddr 10.5.3.0/24 dport 161 proto udp
    "Pass SNMP fr NMSSrv to VLAN3"
021 forward accept in vlan6 out vlan4 saddr 10.5.6.3/32 daddr 10.5.4.3/32 dport 161 proto udp
    "Pass SNMP fr NMSSrv to AuthSrv"
022 forward accept in vlan6 out vlan8 saddr 10.5.6.3/32 daddr 10.5.8.3/32 dport 161 proto udp
    "Pass SNMP fr NMSSrv to NTPSrv"
023 forward accept in vlan3 out vlan6 saddr 10.5.3.0/24 daddr 10.5.6.3/32 dport 162 proto udp
    "Pass SNMPtrp fr VLAN3 to NMSSrv"
024 forward accept in vlan3 out vlan6 saddr 10.5.3.0/24 daddr 10.5.6.3/32 dport 6514 proto tcp
    "Pass Syslog fr VLAN3 to NMSSrv"
025 forward accept in vlan4 out vlan6 saddr 10.5.4.3/32 daddr 10.5.6.3/32 dport 6514 proto tcp
    "Pass Syslog fr AutSrv to NMSSrv"
026 forward accept in vlan8 out vlan6 saddr 10.5.8.3/32 daddr 10.5.6.3/32 dport 6514 proto tcp
    "Pass Syslog fr NTPSrv to NMSSrv"
027 forward accept in vlan3 out ssl1 saddr 10.5.3.0/24 daddr 192.168.9.3/32 dport 162 proto udp
    "Pass SNMPtrp fr VLAN3 to RmCtrl"
028 forward accept in vlan3 out ssl1 saddr 10.5.3.0/24 daddr 192.168.9.3/32 dport 6514 proto tcp
    "Pass Syslog fr VLAN3 to RemCtrl"
029 forward accept in ssl1 out vlan6 saddr 192.168.9.3/32 daddr 10.5.6.3/32 dport 443 proto tcp
    "Pass HTTPS fr RemCtrl t LclCtrl"
030 forward accept in ssl1 out vlan6 saddr 192.168.9.3/32 daddr 10.5.6.3/32 dport 22 proto tcp
    "Pass SSH fr RemCtrl to LclCtrl"
031 forward accept in vlan3 out vlan4 saddr 10.5.3.0/24 daddr 10.5.4.3/32 dport 1812 proto udp
    "Pass RADIUS fr VLAN3 to AutSrv"
032 forward accept in vlan3 out ssl1 saddr 10.5.3.251/32 dport 443 proto tcp
    "Pass HTTPS fr RdWPC1 to ReCtrl"
033 forward accept in vlan6 out ssl1 saddr 10.5.6.3/32 dport 443 proto tcp
    "Pass HTTPS fr NMSSrv to RemCtrl"
N/A drop


NAT Rules (NAPT/masquerading)
Pos Rule


Port-Forward Rules
Pos Rule


Application Level Gateway
Alg Helpers

LxRouter01:/config/ip/firewall/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Final Steps and Clean Up

Protecting sensitive information

It is important to protect sensitive information in the configuration backup files from the switches. This can be achived with the Encrypt secrets functionality. In this example a password will be used in order to be able to decrypt all sensitive information in the configuration file. The idea is to share the password within this network.

LxRouter01:/#> encrypt-password C0nF!Gp4sSw@RD382
LxRouter01:/#> config system
LxRouter01:/config/system/#> encrypt-secrets password
LxRouter01:/config/system/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

Change the Admin Password

As mentioned earlier the admin user can't be removed so its password should be set to something really hard to crack, i.e., a really long password. The example below uses all 64 characters that is possible for a WeOS 5 password.

LxRouter01:/#> config aaa
LxRouter01:/config/aaa/#> user admin
LxRouter01:/config/aaa/user-admin/#> password alg sha512 secret sKhAWg!@2QbflT85pRqggECKgIEoZiwe*TTyXp8zuZyGglWJOoQgkYauGh3N47ob

Check settings with the show command:
LxRouter01:/config/aaa/user-admin/#> show
Status             : Enabled
Name               : admin
Role               : administrator
Hash               : $6$bccGEPwwqExbZSNN$LPYluxg8UJ.310sUu7qR7W6yXvX/UAys0g2WQPTwqxUD4S2CgiRWwVt7Eq4QkR7HAzvRrQuWXSz1O10jANOoN.
SSH-keys           :
LxRouter01:/config/aaa/user-admin/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
LxRouter01:/#> copy run start
LxRouter01:/#>

The LxRouter01 Config File

LxRouter01.cfg

Network Management and Maintenance

The network base is now up and ready for use, requirements for the process network also needs to be added. That is protocols needed, end-devices that must communicate over the firewall etc. But as mentioned earlier this is not part of the scope for this document as all networks are different and have different communication demands it would be impossible to also cover all of this.

From the Local NMS server the network is managed using SNMP to poll important OIDs to retrieve vital status from the switches, see available private OIDs, standard OIDs and conformance information in the WeOS firmware file under the mibs folder. WeOS 5 firmware files are available for download here: https://www.westermo.com/solutions/weos/download-weos/download-weos-5 The NMS server and the Remote Control Server will receive critical information from the switches using SNMP-traps and Remote Syslog messages. The Local NMS server will also be responsible for handing out new firmware files to keep the switches up to date with the latest bug and vulnerability fixes. In this example the upgrading of the switches will be performed using HTTPS from the WEB interface of the switches. The NMS server will also monitor the other servers, to make sure they are available. Patching of server software is downloaded from the Remote Control Site. Certificates are serviced from the Authtentication Server in VLAN 4, which also verifies the users and the PNAC functionality.

Configuration of LxRouter02

The configuration of LxRouter02 is more or less the same as for LxRouter01 but with different addresses etc. So only the config file is provided for reference: LxRouter02.cfg

Configuration of ProcSW01

The Process switches are Layer 2 switches so they have a lot less configuration than the Layer 3 switches (LxRouter01 and 02) as they won't have any firewall, VPN or routing settings. But still many of the security featurs configured on the Layer 3 switches are available in Layer 2 switches as well.

Getting Started/Basic Configuration

lynx-77-bf-a0 login: admin
Password:
.--.--.--.-----.-----.-------.-----.----.--------.-----.
|  |  |  |  -__|__ --|_     _|  -__|   _|        |  _  |
|________|_____|_____| |___| |_____|__| |__|__|__|_____|
                                       www.westermo.com

Westermo WeOS v5.23.0 5.23.0 -- Dec 10 13:25 CET 2024
Type: 'help' for help with commands, 'exit' to logout or leave a context.

Switch Identification Information

For the process switches the naming is as follows, Process (Proc) Switch (SW01) which is located in Process Network 5 (PR05) and Cabinet 3 (-CAB03).

lynx-77-bf-a0:/#> config system
lynx-77-bf-a0:/config/system/#> hostname ProcSW01
lynx-77-bf-a0:/config/system/#> location PR05-CAB03
lynx-77-bf-a0:/config/system/#> contact support@customername.com
lynx-77-bf-a0:/config/system/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

VLANs and Layer 3 Interfaces

The process switches will have the Management VLAN (VLAN 3) as tagged ports for the ring eth1 and eth2, no access ports so Management can only be reached over the ring using the 10.5.3.0/24 subnet. VLAN 12, the Process VLAN will have all ports as untagged with no Layer 3 interface as all process traffic is switched over these switches. As all ports will be used to connect process end-devices there will be no need to disable any ports. The VLAN 1 interface is disabled.

Management VLAN:
ProcSW01:/#> config vlan 3
Creating new VLAN vid:3 with name: vlan3
ProcSW01:/config/vlan-3/#> tagged eth1..eth2
ProcSW01:/config/vlan-3/#> end
ProcSW01:/config/#> iface vlan3
ProcSW01:/config/iface-vlan3/#> inet static 10.5.3.3/24
ProcSW01:/config/iface-vlan3/inet-static-10.5.3.3/#> end
ProcSW01:/config/iface-vlan3/#> end

Process VLAN:
ProcSW01:/config/#> vlan 12
Creating new VLAN vid:12 with name: vlan12
ProcSW01:/config/vlan-12/#> untagged eth1..eth10
Moving untagged port eth1 from vid 1 to vid 12.
Moving untagged port eth2 from vid 1 to vid 12.
Moving untagged port eth3 from vid 1 to vid 12.
Moving untagged port eth4 from vid 1 to vid 12.
Moving untagged port eth5 from vid 1 to vid 12.
Moving untagged port eth6 from vid 1 to vid 12.
Moving untagged port eth7 from vid 1 to vid 12.
Moving untagged port eth8 from vid 1 to vid 12.
Moving untagged port eth9 from vid 1 to vid 12.
Moving untagged port eth10 from vid 1 to vid 12.
ProcSW01:/config/vlan-12/#> end

VLAN 1 can not be removed but the interface can be disabled:
ProcSW01:/config/#> iface vlan1
ProcSW01:/config/iface-vlan1/#> no inet
ProcSW01:/config/iface-vlan1/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start

Verify the configuration with the show vlan and show iface commands.
ProcSW01:/#> show vlan
VID  NAME             OPER TAGGED/UNTAGGED/POLICY NEST
   1 vlan1            DOWN T:
                           U:
                           N:
   3 vlan3            UP   T:eth1..eth2
                           U:
                           N:
  12 vlan12           UP   T:
                           U:ALL
                           N:
ProcSW01:/#>

ProcSW01:/#> show iface
INTERFACE         OPER  ADDRESS/LENGTH      SOURCE      MAC/PTP ADDRESS
lo                UP    127.0.0.1/8         static      00:00:00:00:00:00
vlan1             DOWN  DISABLED                        00:11:b4:77:bf:a0
vlan3             UP    10.5.3.3/24         static      00:11:b4:77:bf:a0
vlan12            UP    DISABLED                        00:11:b4:77:bf:a0
ProcSW01:/#>

Layer 2 Redundancy

FRNTv2 will be used as ring protocol, same as for the LxRouters. But this switch ProcSW01 is the only switch configured as Focal Point for the ring. As the Focal Point functionality is the default setting there is no need to run the no focal-point command.

ProcSW01:/#> config ring
ProcSW01:/config/ring/#> frntv2 1
Activating FRNT with default settings, remember to change the ring ports!

Invalid settings: No ring ports defined
ProcSW01:/config/ring/frnt-1/#> port eth1
ProcSW01:/config/ring/frnt-1/port-eth1/#> end
ProcSW01:/config/ring/frnt-1/#> port eth2
ProcSW01:/config/ring/frnt-1/port-eth2/#> end

Check the configuration with the show command:
ProcSW01:/config/ring/frnt-1/#> show
FRNT version     : 2
Ring ID          : 1
Mode             : Focal Point
Guarded-recovery : Enabled
Ring-interval    : 500 ms
Blocking-port    : auto
Response-delay   : 1500 ms
Port             : eth1
  hello-time     : 500 ms
Port             : eth2
  hello-time     : 500 ms
ProcSW01:/config/ring/frnt-1/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

Default Gateway

The process switches will have the LxRouters as their Default Gateway for Management traffic so the NMS server will be able to access all management functionality in the switches. End-devices in the Process VLAN (VLAN 12) have the LxRouters as their Default Gateway (10.5.12.254) so this is not configured in these switches.

ProcSW01:/#> config ip
ProcSW01:/config/ip/#> route default 10.5.3.254

Verify with show route:
ProcSW01:/config/ip/#> show route
Network          Netmask          Gateway          Iface          Dist  TrigId
==============================================================================
0.0.0.0          0.0.0.0          10.5.3.254       *                1
ProcSW01:/config/ip/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

Time Synchronization using NTP

Just as the LxRouters, the ProcSWs must synchronize the time with the NTP server in VLAN 8 for the logs and the certificate validity.

ProcSW01:/#> config ntp
ProcSW01:/config/ntp/#> peer 10.5.8.3
Activating NTP Peer with default settings.
ProcSW01:/config/ntp/peer-10.5.8.3/#> end

Check configuration with the show command:
ProcSW01:/config/ntp/#> show
Status            : Enabled
Server/Client     : Client
Step Adjust     : Enabled
    Threshold   : 10.0
    Limit       : 1

Peer                 Status    Poll-interval  Preferred
==============================================================================
10.5.8.3             Enabled             600
ProcSW01:/config/ntp/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

Verify that the correct time has been set with the show date command:
ProcSW01:/#> show date
Mon Mar 24 14:04:25 UTC 2025
ProcSW01:/#>

Import Certificates

The ProcSWs must also have certificates for HTTPS and TCP-SSL-Syslog. VPN Tunnels are not used in these switches, so not certificates or VPNs are required.

Start by importing the CA certificate:
ProcSW01:/#> cert import pem type ca tftp://10.5.4.3/hardening-cert/ca.crt
Downloading ca.crt from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/ca.cr 100% |********************************|  1224  0:00:00 ETA
Importing certificate ca...
OK

Then proceed with uploading the WEB certificate and key for https
ProcSW01:/#> cert import pem type public tftp://10.5.4.3/hardening-cert/10.5.3.3.crt
Downloading 10.5.3.3.crt from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/10.5. 100% |********************************|  4707  0:00:00 ETA
Importing certificate 10.5.3.3...
OK
ProcSW01:/#> cert import pem type private tftp://10.5.4.3/hardening-cert/10.5.3.3.key
Downloading 10.5.3.3.key from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/10.5. 100% |********************************|  1732  0:00:00 ETA
Importing certificate 10.5.3.3...
OK

Finally upload the certifcate and key used by TCP-SSL-Syslog:
ProcSW01:/#> cert import pem type public tftp://10.5.4.3/hardening-cert/SyslogClient05-03.crt
Downloading SyslogClient05-03.crt from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/Syslo 100% |********************************|  4602  0:00:00 ETA
Importing certificate SyslogClient05-03...
OK
ProcSW01:/#> cert import pem type private tftp://10.5.4.3/hardening-cert/SyslogClient05-03.key
Downloading SyslogClient05-03.key from tftp://10.5.4.3...
Connecting to 10.5.4.3 (10.5.4.3:69)
hardening-cert/Syslo 100% |********************************|  1732  0:00:00 ETA
Importing certificate SyslogClient05-03...
OK

Verify that the certificates have been imported correctly with the show cert command:
ProcSW01:/#> show cert
TYPE     HASH      EXPIRES      NAME
CA-local dcf124c6  Jan 15 2035  Westermo-CA
Pub      ee3131b2  Apr 22 2027  10.5.3.3
Pub      c8e27824  May  4 2027  SyslogClient05-03
Pub      e50bb62e  Jan 19 2038  lynx-77-bf-a0.local
Key      N/A       N/A          10_5_3_3
Key      N/A       N/A          SyslogClient05-03
Key      N/A       N/A          web-default
ProcSW01:/#>

Secure Management

Restrict Access to Switch Management

Securing the Management is done in the same way as for the LxRouters so details can be found in the same section for LxRouter01 above. With the exception that the ProcSws will only listen to VLAN 3 for these Management services.

WEB Interface

ProcSW01:/#> config management
ProcSW01:/config/management/#> web
ProcSW01:/config/management/web/#> no http
Deactivating http service.
ProcSW01:/config/management/web/#> HTTPS
ProcSW01:/config/management/web/HTTPS/#> listen vlan3
ProcSW01:/config/management/web/HTTPS/#> certificate 10_5_3_3
ProcSW01:/config/management/web/HTTPS/#> end
ProcSW01:/config/management/web/#> login-banner 'WARNING!\nThis is the property of CompanyName\nUnauthorized access is strictly prohibited!'

Use the show command to verify the settings:
ProcSW01:/config/management/web/#> show
Session Timeout    : 10 min

Login Banner
▏WARNING!                                                                    ▕
▏This is the property of CompanyName                                         ▕
▏Unauthorized access is strictly prohibited!                                 ▕
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
HTTP
HTTP               : Disabled

HTTPS
HTTPS               : Enabled
Custom certificate  : 10_5_3_3
HTTPS listen ifaces : vlan3
HTTPS port          : 443
ProcSW01:/config/management/web/#> end
ProcSW01:/config/management/#>

SNMPv3

ProcSW01:/config/management/#> snmp
ProcSW01:/config/management/snmp/#> listen vlan3
ProcSW01:/config/management/snmp/#> no rocommunity
ProcSW01:/config/management/snmp/#> no rwcommunity
ProcSW01:/config/management/snmp/#> rouser ProcSW01SNMP auth sha512 P45sw@r0sNM9pR0! crypto aes256 Cry970K3YSNm901p 1
ProcSW01:/config/management/snmp/#> host 10.5.6.3 version 3 username ProcSW01SNMP type trap
ProcSW01:/config/management/snmp/#> host 192.168.9.3 version 3 username ProcSW01SNMP type trap

Run the show command to verify that the settings are correct:
ProcSW01:/config/management/snmp/#> show
Enabled             : Enabled
SNMP Versions       : v2c, v3
Read-Only Community : Disabled
Read-Write Community: Disabled
Trap Community      : trap
IfIndex-Persistence : Disabled
Engine-ID           : auto (80003f31030011b477bfa0)
Listen interfaces   : vlan3
Command(s) allowed  :
Remote trap host(s) :
ADDRESS                                  VERS  TYPE    RESEND  USERNAME
10.5.6.3                                 3     Trap            ProcSW01SNMP
192.168.9.3                              3     Trap            ProcSW01SNMP
SNMP v3 users       :
TYPE    USERNAME          AUTH    AUTHPW            CRYPTO  CRYPTOPW          OIDTREE
rouser  ProcSW01SNMP      SHA512  P45sw@r0sNM9pR0!  AES256  Cry970K3YSNm901p  1
ProcSW01:/config/management/snmp/#> end
ProcSW01:/config/management/#>

SSH

ProcSW01:/config/management/#> ssh
ProcSW01:/config/management/ssh/#> listen vlan3
ProcSW01:/config/management/ssh/#> login-banner 'WARNING!\nThis is the property of CompanyName\nUnauthorized access is strictly prohibited!'
ProcSW01:/config/management/ssh/#> idle-timeout 300

Check the settings with the show command:
ProcSW01:/config/management/ssh/#> show
Enabled           : Enabled
Port              : 22 (default)
Keepalive         : 60 sec (default)
Idle timeout      : 300 sec
Fail delay        : 2 sec (default)
Listen interfaces : vlan3

Login Banner
▏WARNING!                                                                    ▕
▏This is the property of CompanyName                                         ▕
▏Unauthorized access is strictly prohibited!                                 ▕
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
ProcSW01:/config/management/ssh/#> end
ProcSW01:/config/management/#>

Serial Console

ProcSW01:/config/management/#> console
ProcSW01:/config/management/console/#> login-banner 'WARNING!\nThis is the property of CompanyName\nUnauthorized access is strictly prohibited!'

Verify using show:
ProcSW01:/config/management/console/#> show
Console login: Enabled

Login Banner
▏WARNING!                                                                    ▕
▏This is the property of CompanyName                                         ▕
▏Unauthorized access is strictly prohibited!                                 ▕
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
ProcSW01:/config/management/console/#> end
ProcSW01:/config/management/#>

Disabling the Serial Console (Use with Caution)

ProcSW01:/#> config management
ProcSW01:/config/management/#> console
ProcSW01:/config/management/console/#> no login
ProcSW01:/config/management/console/#> leave
Applying configuration.
Configuration activated.  Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#> logout

CLI (SSH and Serial Console)

ProcSW01:/config/management/#> cli
ProcSW01:/config/management/cli/#> timeout 300

Verify with show:
ProcSW01:/config/management/cli/#> show
Timeout: 300 sec
ProcSW01:/config/management/cli/#> end
ProcSW01:/config/management/#>

Max Amount of Remote Sessions

ProcSW01:/config/management/#> max-remote-sessions 2

Verify settings with the show command:
ProcSW01:/config/management/#> show
Web: Enabled (HTTP: Disabled, https Enabled)
SSH: Enabled
Telnet: Disabled
SNMP: Enabled
CLI: Enabled (timeout: 300 sec)
Console login: Enabled
Max remote sessions: 2
ProcSW01:/config/management/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

User Authentication

User Policies

The sames policies are used for the ProcSWs as for the LxRouters.

ProcSW01:/#> config aaa
ProcSW01:/config/aaa/#> lockout-policy

Check setttings with the show command:
ProcSW01:/config/aaa/lockout-policy/#> show
Enable      : Disabled
Deny        : 3
Deny admin  : Enabled
Unlock time : 600
ProcSW01:/config/aaa/lockout-policy/#> end
ProcSW01:/config/aaa/#> password-policy
Activating password policy with default settings, type 'abort' to cancel.
ProcSW01:/config/aaa/password-policy/#> min-length 15
ProcSW01:/config/aaa/password-policy/#> uppercases 4
ProcSW01:/config/aaa/password-policy/#> lowercases 4
ProcSW01:/config/aaa/password-policy/#> digits 5
ProcSW01:/config/aaa/password-policy/#> specials 2
ProcSW01:/config/aaa/password-policy/#> reject-username
Enabling reject username

Verify the configuration with the show command:
ProcSW01:/config/aaa/password-policy/#> show
enable                : Enabled
min-length            : 15
uppercases            : 4
lowercases            : 4
digits                : 5
specials              : 2
reject-username       : Enabled
ProcSW01:/config/aaa/password-policy/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

Users and Passwords in this How-to

The same users are used as described for LxRouter01 above.

Remote User Authentication

Remote Authentication Radius Server

Setup the connection to the Radius server:
ProcSW01:/#> config aaa
ProcSW01:/config/aaa/#> remote-server 1
Creating new remote server 1
Error: Missing remote server password.

ProcSW01:/config/aaa/remote-server-1/#> description "User Auth Srv"
Error: Missing remote server password.

ProcSW01:/config/aaa/remote-server-1/#> password h4Rde*4MP!Ep4ssW0rd72
Error: Missing remote server address.

ProcSW01:/config/aaa/remote-server-1/#> address 10.5.4.3
ProcSW01:/config/aaa/remote-server-1/#> type radius

Verify settings with the show command:
ProcSW01:/config/aaa/remote-server-1/#> show
Server 1           : radius
Description        : User Auth Srv
Server address     : 10.5.4.3
Auth port          : Auto (1812)
Password           : h4Rde*4MP!Ep4ssW0rd72
ProcSW01:/config/aaa/remote-server-1/#> end

Set the login procedure to use the Radius server for authentication:
ProcSW01:/config/aaa/#> login
ProcSW01:/config/aaa/login/#> method server 1
ProcSW01:/config/aaa/login/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

Users with Remote Authentication Only

Mll747 will still only be a remotly authenticated user as for the LxRouters, so it will not be added to the switch configuration.

Users with Remote Authentication and Built-in Account Fallback

ProcSW01:/#> config aaa
ProcSW01:/config/aaa/#> user les839
ProcSW01:/config/aaa/user-les839/#> password alg sha512 secret P4sSw0rDe*4mP!E48

Verify correct configuration with the show command:
ProcSW01:/config/aaa/user-les839/#> show
Status             : Enabled
Name               : les839
Role               : administrator
Hash               : $6$lNzwgFufAjXfrnLR$9Qq9.o0QLG0gCAcB6kF1vm4zFeVrySRNkYMGgFnu7JHADiR7iEfvL/CVj9IY00FYF1OzT3bDmq2wSrDqw8OwB/
SSH-keys           :

ProcSW01:/config/aaa/user-les839/#> end
ProcSW01:/config/aaa/#>

Users with SSH User Key Authentication Only

ProcSW01:/config/aaa/#> user nhk354
ProcSW01:/config/aaa/user-nhk354/#> ssh-user-key import
Paste SSH user key(s) and hit enter twice:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC01aErOz1WaaFrlgpJzIVxfX0QoTFI8X65Klx4HHkMkfilD28O7E9pe6HPt/XgEQFQc4pecSAj41LbPJJgUQCVecDspufZb9Ba/WkFjaSdMY4IZHwZpVB95H6VwuI91ardluOUWluwK7cuxFsfivERstDCq9wbq6OTOb5KcFm/jXp/A3tWaf1NoQHMPcXbfFeLzhtZ/mthlKEg/G2LYgt5aRyg9AK6n92/jBjD3A84A1C45rfYMLU2MAl9q1ZhPKap4bb/FVCrHuM91C2nrnUznwSNCgJkUkN0fniJla2U02r0KB5nb7tdp0XofDd0LKTG1muy/0kT/OB00Xdrfd2BAtOQO85nschplDzrQR9ktJPo1xSfAsDq4nGM5ysXNFXCHqieGREVKrHVB3LHdY9FuGk/yfco8bu+Q84piCuFSsMQ/AJrjof6a0mifZbp6T6R3nS2wxwadaR9ezGWRxDE2HNbtMkEEGFL6y6VrXPFUP1pfb7A8kWffqKASivdjE38+jqF8zS9V1Ar6FizjmbUsaiaisLWoL3bBDz3BaKq7QmDZ3Uu+RfZje4nzyHYjjaMn3QeK6NJl5kqM78mmiU3oXEtMxZzNnrtJI+Jg0TBS+Wis7W67mG5SMdbsAY1CKupelFdbbLwdomN5+ZCrFvdjJRpLf4q98tLKO6GWiphkQ== rsa-key-20240311

Successfully imported SSH user key(s) for nhk354

Verify correct configuration with the show command:
ProcSW01:/config/aaa/user-nhk354/#> show
Status             : Enabled
Name               : nhk354
Role               : administrator
Hash               :
SSH-keys           :
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC01aErOz1WaaFrlgpJzIVxfX0QoTFI8X65Klx4HHkMkfilD28O7E9pe6HPt/XgEQFQc4pecSAj41LbPJJgUQCVecDspufZb9Ba/WkFjaSdMY4IZHwZpVB95H6VwuI91ardluOUWluwK7cuxFsfivERstDCq9wbq6OTOb5KcFm/jXp/A3tWaf1NoQHMPcXbfFeLzhtZ/mthlKEg/G2LYgt5aRyg9AK6n92/jBjD3A84A1C45rfYMLU2MAl9q1ZhPKap4bb/FVCrHuM91C2nrnUznwSNCgJkUkN0fniJla2U02r0KB5nb7tdp0XofDd0LKTG1muy/0kT/OB00Xdrfd2BAtOQO85nschplDzrQR9ktJPo1xSfAsDq4nGM5ysXNFXCHqieGREVKrHVB3LHdY9FuGk/yfco8bu+Q84piCuFSsMQ/AJrjof6a0mifZbp6T6R3nS2wxwadaR9ezGWRxDE2HNbtMkEEGFL6y6VrXPFUP1pfb7A8kWffqKASivdjE38+jqF8zS9V1Ar6FizjmbUsaiaisLWoL3bBDz3BaKq7QmDZ3Uu+RfZje4nzyHYjjaMn3QeK6NJl5kqM78mmiU3oXEtMxZzNnrtJI+Jg0TBS+Wis7W67mG5SMdbsAY1CKupelFdbbLwdomN5+ZCrFvdjJRpLf4q98tLKO6GWiphkQ== rsa-key-20240311

ProcSW01:/config/aaa/user-nhk354/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

The Admin User

The default admin user can not be removed from the switch so when all the configuration is completed a really long password should be set for this user, see section at the end of the ProcSw01 configuration below. WeOS 5 support password lenghts of up to 64 characters. A complex password can protect this user and prevent it from being used.

Minimize the Attack Surface

Disable Unused Protocols

The same procols as for the LxRouters should be disabled.

Disable SSDP and MDNS

ProcSW01:/#> config discover
ProcSW01:/config/discover/#> no mdns
Deactivating mDNS service.
ProcSW01:/config/discover/#> no ssdp
Deactivating SSDP service.

Verify settings with the show command:
ProcSW01:/config/discover/#> show
Multicast DNS (mDNS) Responder
   Enabled           : Disabled
Simple Service Discovery Protocol (SSDP) for Windows(TM)
   Enabled           : Disabled
ProcSW01:/config/discover/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

Disable IGMP Snooping per VLAN

ProcSW01:/#> config vlan 1
ProcSW01:/config/vlan-1/#> no multicast-snooping
ProcSW01:/config/vlan-1/#> end
ProcSW01:/config/#> vlan 3
ProcSW01:/config/vlan-3/#> no multicast-snooping
ProcSW01:/config/vlan-3/#> end
ProcSW01:/config/#> vlan 12
ProcSW01:/config/vlan-12/#> no multicast-snooping
ProcSW01:/config/vlan-12/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

Disable the SD-card/USB-port

ProcSW01:/#> boot
ProcSW01:/boot/#> no aux-port
Disabling all auxiliary ports (reboot required)

Verify settings with the show command:
ProcSW01:/boot/#> show aux-port
AUXILIARY PORT     ACTUAL STATE     CONFIGURED STATE
sd                 ENABLED          DISABLED (reboot required)
ProcSW01:/boot/#> leave
Saving bootloader configuration to FLASH
100% / [====================================================================]
ProcSW01:/#> reboot

After reboot the actual state is disabled:
ProcSW01:/#> boot
ProcSW01:/boot/#> show aux-port
AUXILIARY PORT     ACTUAL STATE     CONFIGURED STATE
sd                 DISABLED         DISABLED
ProcSW01:/boot/#> abort
ProcSW01:/#>

Unwanted Types of Broadcast Traffic

ProcSW01:/#> config port eth3..eth10
ProcSW01:/config/port-eth3..eth10/#> ingress-rate-limit 64k match bc,mc,u-uni
ProcSW01:/config/port-eth3..eth10/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start

Verify correct settings with the show port command:
ProcSW01:/#> show port eth3
eth3
Link           : Down
Oper. status   : Enabled
Admin status   : Enabled
Description    : eth3
Type           : 1000-T
State          : No-Link
Alarm          : N/A
VLAN           : U:12
MAC            : 00:11:b4:77:bf:a3
Autoneg        : Enabled
Speed          : -------------
Duplex         :
MDI/MDIX       :
MDI/MDIX status:
Polarity status:
Gbit-cu-master : auto
Fastlink       : Disabled
Flow Control   : Disabled
Prio mode      : tag
Prio           : 0
Ingress limit  : 64 match u-uni,bc,mc
Egress limit   : 0 kbps
Shielded mode  : Unshielded
PHY power mode : Low power (CLASS B)
Bridge group   : Disabled

ProcSW01:/#>

Network Monitoring

Alarms

The alarm settings are similar to the LxRouters except that there is no Road Warrior port on the ProcSws so only one type of Link-alarm is needed.

ProcSW01:/#> config alarm
ProcSW01:/config/alarm/#> action 1
ProcSW01:/config/alarm/action-1/#> no target
Action 1: No targets selected

ProcSW01:/config/alarm/action-1/#> target snmp log led

Check settings with the show command:
ProcSW01:/config/alarm/action-1/#> show
ID            : 1
Targets       : snmp log led
ProcSW01:/config/alarm/action-1/#> end
ProcSW01:/config/alarm/#> trigger link-alarm
ProcSW01:/config/alarm/trigger-1/#> action 1
ProcSW01:/config/alarm/trigger-1/#> condition down
ProcSW01:/config/alarm/trigger-1/#> port eth1..eth10

Verify configuration with the show command:
ProcSW01:/config/alarm/trigger-1/#> show
ID              : 1
Type            : Link-Alarm
Status          : Enabled
Port            : ALL
Severity        : active Warning, inactive Notice
Condition       : Low
Action          : 1
ProcSW01:/config/alarm/trigger-1/#> end
ProcSW01:/config/alarm/#> trigger digin
ProcSW01:/config/alarm/trigger-2/#> action 1
ProcSW01:/config/alarm/trigger-2/#> condition down

Verify configuraion using the show command:
ProcSW01:/config/alarm/trigger-2/#> show
ID              : 2
Type            : Digin
Status          : Enabled
Sensor          : 1
Severity        : active Warning, inactive Notice
Condition       : Low
Action          : 1
ProcSW01:/config/alarm/trigger-2/#> end
ProcSW01:/config/alarm/#> trigger power
ProcSW01:/config/alarm/trigger-3/#> action 1
ProcSW01:/config/alarm/trigger-3/#> condition down

Check the settings with the show command:
ProcSW01:/config/alarm/trigger-3/#> show
ID              : 3
Type            : Power
Status          : Enabled
Sensor          : 1,2
Severity        : active Warning, inactive Notice
Condition       : Low
Action          : 1
ProcSW01:/config/alarm/trigger-3/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

SNMPv3 Traps

SNMP trap configuration has already been completed in the Secure Management section where both the SNMPv3 user and SNMPv3-trap hosts have been set.

Remote Syslog

Remote Syslog is setup in the same way as the LxRouters.

ProcSW01:/#> config logging
ProcSW01:/config/logging/#> destination rsyslogLclCtrl

╒ Configuration Errors: 2 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No destination file name specified.                                     │
├────────────────────────────────────────────────────────────────────────────┤
│2   No destination media name specified.                                    │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/destination-rsyslogLclCtrl/#> type remote

╒ Configuration Errors: 2 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No remote host specified for the destination.                           │
├────────────────────────────────────────────────────────────────────────────┤
│2   No CA certificate label specified, necessary for validation of peer.    │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/destination-rsyslogLclCtrl/#> host address 10.5.6.3

╒ Configuration Errors: 1 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No CA certificate label specified, necessary for validation of peer.    │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/destination-rsyslogLclCtrl/#> ca-certificate ca

╒ Configuration Warnings: 1 ═════════════════════════════════════════════════╕
│#   Description                                                             │
│1   It is recommended that the configuration uses a certificate for secure  │
│    communication. Without a certificate, the other end of the connection   │
│    cannot verify the identity of this connecting device. However, this is  │
│    also dependant on how the other end of the connection is configured.    │
│    It may or may not require a certificate. If it does, the connection     │
│    will not be established without one.                                    │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/destination-rsyslogLclCtrl/#> certificate SyslogClient05-03
ProcSW01:/config/logging/destination-rsyslogLclCtrl/#> end
ProcSW01:/config/logging/#> destination rsyslogRemCtrl

╒ Configuration Errors: 2 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No destination file name specified.                                     │
├────────────────────────────────────────────────────────────────────────────┤
│2   No destination media name specified.                                    │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/destination-rsyslogRemCtrl/#> type remote

╒ Configuration Errors: 2 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No remote host specified for the destination.                           │
├────────────────────────────────────────────────────────────────────────────┤
│2   No CA certificate label specified, necessary for validation of peer.    │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/destination-rsyslogRemCtrl/#> host address 192.168.9.3

╒ Configuration Errors: 1 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No CA certificate label specified, necessary for validation of peer.    │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/destination-rsyslogRemCtrl/#> ca-certificate ca

╒ Configuration Warnings: 1 ═════════════════════════════════════════════════╕
│#   Description                                                             │
│1   It is recommended that the configuration uses a certificate for secure  │
│    communication. Without a certificate, the other end of the connection   │
│    cannot verify the identity of this connecting device. However, this is  │
│    also dependant on how the other end of the connection is configured.    │
│    It may or may not require a certificate. If it does, the connection     │
│    will not be established without one.                                    │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/destination-rsyslogRemCtrl/#> certificate SyslogClient05-03
ProcSW01:/config/logging/destination-rsyslogRemCtrl/#> end
ProcSW01:/config/logging/#> filter rsyslogFilter

╒ Configuration Errors: 1 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No filter type specified, need at least one.                            │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/filter-rsyslogFilter/#> level debug
ProcSW01:/config/logging/filter-rsyslogFilter/#> invert
ProcSW01:/config/logging/filter-rsyslogFilter/#> end
ProcSW01:/config/logging/#> sink rsyslogSink

╒ Configuration Errors: 2 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No sources specified, at least one is necessary.                        │
├────────────────────────────────────────────────────────────────────────────┤
│2   No destinations specified, at least one is necessary.                   │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/sink-rsyslogSink/#> source local

╒ Configuration Errors: 1 ═══════════════════════════════════════════════════╕
│#   Description                                                             │
│1   No destinations specified, at least one is necessary.                   │
└────────────────────────────────────────────────────────────────────────────┘
ProcSW01:/config/logging/sink-rsyslogSink/#> destination rsyslogLclCtrl
ProcSW01:/config/logging/sink-rsyslogSink/#> destination rsyslogRemCtrl
ProcSW01:/config/logging/sink-rsyslogSink/#> filter rsyslogFilter
ProcSW01:/config/logging/sink-rsyslogSink/#> end

Verify settings with the show command:
ProcSW01:/config/logging/#> show
Console syslog   : Disabled
External logging : Disabled
Secure mode      : Enabled

╒ Sources ═══════════════════════════════════════════════════════════════════╕
│NAME                                                                        │
│Type: local      USERSPACE  KERNEL                                          │
│local            Yes        Yes                                             │
└────────────────────────────────────────────────────────────────────────────┘

╒ Destinations ══════════════════════════════════════════════════════════════╕
│NAME                                                                        │
│Type: remote     TRANSPORT  TO-HOST      PORT   FORMAT                      │
│rsyslogLclCtrl   tls        10.5.6.3     6514   rfc5424                     │
│rsyslogRemCtrl   tls        192.168.9.3  6514   rfc5424                     │
└────────────────────────────────────────────────────────────────────────────┘

╒ Filters ═══════════════════════════════════════════════════════════════════╕
│NAME             INVERT        TYPE  FILTER                                 │
│rsyslogFilter    Yes          Level  debug                                  │
└────────────────────────────────────────────────────────────────────────────┘

╒ Sinks ═════════════════════════════════════════════════════════════════════╕
│NAME             SOURCES       DESTINATIONS     OP FILTERS                  │
│rsyslogSink      local         rsyslogLclCtrl      rsyslogFilter            │
│                               rsyslogRemCtrl                               │
└────────────────────────────────────────────────────────────────────────────┘

ProcSW01:/config/logging/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

Final Steps and Clean Up

Protecting sensitive information

Protect the configuration file in the same way as for the LxRouters.

ProcSW01:/#> encrypt-password C0nF!Gp4sSw@RD382
ProcSW01:/#> config system
ProcSW01:/config/system/#> encrypt-secrets password
ProcSW01:/config/system/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

Change the Admin Password

Finally, change the password for the admin user.

ProcSW01:/#> config aaa
ProcSW01:/config/aaa/#> user admin
ProcSW01:/config/aaa/user-admin/#> password alg sha512 secret 4dlOhlcR8olGy%gAwsS0Z*2MYaIVnb!v%s6BL#P%Lb#LDta0S0Q^VtpdOB^k#bPg

Check settings with the show command:
ProcSW01:/config/aaa/user-admin/#> show
Status             : Enabled
Name               : admin
Role               : administrator
Hash               : $6$hwPcuAEOXsZQtTXN$I12uGHGVDoLBZXNsEF08Qcm3KiPQBw9rRqsjyqpiNqckIpiK3cegbguxgEFDO3AYym7peQWwlubrEuighbMPd.
SSH-keys           :

ProcSW01:/config/aaa/user-admin/#> leave
Applying configuration.
Configuration activated.
Remember "copy run start" to save to flash (NVRAM).
ProcSW01:/#> copy run start
ProcSW01:/#>

The ProcSW01 Config File

ProcSW01.cfg

Configuration of ProcSW02

The configuration of ProcSW02 is more or less the same as for ProcSW01 but with different addresses etc. So only the config file is provided for reference: ProcSW02.cfg

Introduction​

Risks & Mitigating Controls​

Management Services​

WeOS, Westermo's Operating System​

Defence in Depth​

Default Values​

Factory Default Values​

Management Services​

Environment (Identify)​

Firewall​

Input Rule​

General Rule​

Limited Rule​

Restricted Rule​

Forwarding Rule​

Deny Rule​

Where to place Firewalls on the network​

NAT Rules​

Network Address and Port Translation (NAPT)​

General Rule​

Limited Rule​

Restricted Rule​

Virtual Private Network (VPN)​

SSL or IPSec?​

OpenVPN LAN Net-to-Net (Layer 2 VPN)​

OpenVPN Host to LAN (Layer 3 VPN)​

Conduits and Segmentation​

Confidentiality​

Secure Boot​

Network Services​

DHCP​

DNS​

Redundancy​

Layer 2 Redundancy​

Rings with FRNT​

Aggregation with LACP​

Link Aggregation and Rings​

Layer 3 Redundancy​

Multiple Paths with OSPF​

Master and Backup with VRRP​

VLANs​

Subnetting​

Static or Dynamic IP Addressing​

Management Services​

Best Practices: Environment (Identify)​

System & Application Security (Protect)​

AAA​

Responsibilities​

802.1x​

Password Policy​

Session Timeout​

Lockout Policy​

Zero Trust​

Patch Management and Asset Management​

How to safely download and store software from Westermo​

Certificates and Keys​

Best Practices: System & Application Security (Protect)​

Monitoring & Recovery (Detect, Respond & Recover)​

Alarms​

System Logging​

Persistent Logging​

Audit Event Logging​

Setting the time and date​

SNMP​

How to work with Backup files?​

Best Practices: Monitoring & Recovery (Detect, Respond & Recover)​

What does Westermo protect? "Goal"​

Configuration Hardening Guide WeOS 5​

Abstract​

Scope​

Topology​

IP Plan​

Process Subnets​

Management Subnets​

Authentication Server Subnets​

Local Control NMS Server Subnets​

Remote Control Room Subnet​

NTP Server Subnets​

Connection to Unsecured Network Subnets​

VPN Subnets​

Introduction

Risks & Mitigating Controls

Management Services

WeOS, Westermo's Operating System

Defence in Depth

Default Values

Factory Default Values

Management Services

Environment (Identify)

Firewall

Input Rule

General Rule

Limited Rule

Restricted Rule

Forwarding Rule

Deny Rule

Where to place Firewalls on the network

NAT Rules

Network Address and Port Translation (NAPT)

General Rule

Limited Rule

Restricted Rule

Virtual Private Network (VPN)

SSL or IPSec?

OpenVPN LAN Net-to-Net (Layer 2 VPN)

OpenVPN Host to LAN (Layer 3 VPN)

Conduits and Segmentation

Confidentiality

Secure Boot

Network Services

DHCP

DNS

Redundancy

Layer 2 Redundancy

Rings with FRNT

Aggregation with LACP

Link Aggregation and Rings

Layer 3 Redundancy

Multiple Paths with OSPF

Master and Backup with VRRP

VLANs

Subnetting

Static or Dynamic IP Addressing

Management Services

Best Practices: Environment (Identify)

System & Application Security (Protect)

AAA

Responsibilities

802.1x

Password Policy

Session Timeout

Lockout Policy

Zero Trust

Patch Management and Asset Management

How to safely download and store software from Westermo

Certificates and Keys

Best Practices: System & Application Security (Protect)

Monitoring & Recovery (Detect, Respond & Recover)

Alarms

System Logging

Persistent Logging

Audit Event Logging

Setting the time and date

SNMP

How to work with Backup files?

Best Practices: Monitoring & Recovery (Detect, Respond & Recover)

What does Westermo protect? "Goal"

Configuration Hardening Guide WeOS 5

Abstract

Scope

Topology

IP Plan

Process Subnets

Management Subnets

Authentication Server Subnets

Local Control NMS Server Subnets

Remote Control Room Subnet

NTP Server Subnets

Connection to Unsecured Network Subnets

VPN Subnets