Setting up protection against IT attacks in the enterprise using Zyxel equipment
Not so long ago, the company Human Security has identified an entire shadow network associated with infected devices and malicious applications. Infected were not only Android TV set-top boxes, but also tablet PCs, wearable devices and even cars. In this regard, it should be taken for granted that if at least one "smart" device is used in your company, whether it is an outlet, a light bulb, a robot vacuum cleaner or a TV with Internet control, it makes sense to limit access to everything except control servers on the Internet as much as possible.
A typical IoT attack looks like this: the device connects to a malicious Internet resource directly or through its own VPN, downloads and installs malicious code on itself, after which it begins to be either part of a large bot farm for attacks on third-party resources and use as a resident proxy, or simply spies on your network, trying to intercept some data, pull information from open resources, or harm in any other way. Therefore, the basis of IoT protection is to prevent them from accessing malicious management servers and your corporate network.
This is not as difficult as it seems, and the basics of such protection are discussed in our Bulletin of protection against IoT devices. In the same article, we will show how you can protect a corporate network at a separate facility where Zyxel network devices are used from threats related to IoT devices.
For testing, I have assembled the following stand:
- Security Gateway – Zyxel ATP500
- Access point – Zyxel NWA110AX
- Switchboard – Zyxel GS1915-8EP
Security settings are made along the "bottom-up" path, starting from the access point. For IoT devices, I am creating at NWA110AX a separate 2.4GHz wireless network profile. My main task is not to let smart sockets into other parts of the corporate network, first of all, into the control network, where the Web interface of the switch and gateway is open, as well as into the access network to which smartphones and laptops are connected. To do this, I am creating a separate VLAN with the number 32, but along the way there are some more features that I would like to mention.
Security settings are made along the "bottom-up" path, starting from the access point. For NWA110AX IoT devices, I am creating a separate 2.4GHz wireless network profile. My main task is not to let smart sockets into other parts of the corporate network, first of all, into the control network, where the Web interface of the switch and gateway is open, as well as into the access network to which smartphones and laptops are connected. To do this, I am creating a separate VLAN with the number 32, but along the way there are some more features that I would like to mention.
We rise to a higher level, and configure the VLAN for IoT with ID=32. The access point, when installing the VLAN on the SSID, sends tagged traffic, so on the switch we allow for VLAN 32 only those ports that go to the gateway and access point, not forgetting to mark TX Tagging, in my example this is the 1st port – to the gateway and the 7th to the access point.
We go one step higher – to the ATP500 gateway. This is a very sophisticated, functional model with support for virtual interfaces and security services, so from the very beginning we need to do everything right so that this functionality fully reveals itself. We start by creating a separate zone for IoT, roughly speaking, we logically describe a new group of networks for which we will apply the rules.
In Zyxel ATP500 there is a VLAN restriction – the virtual network is rigidly tied to the port, that is, if you do not have an aggregating switch under the gateway, but for example there are several PoE switches in different parts of the building, and they are connected to different gateway ports, then you will have to make several VLANs for IoT on the gateway, each – to its own physical port, each with its own IP and DHCP range, but in a common IoT zone. Here we can also set the speed limit for VLANs, for example, equal to 10% of your WAN connection.
Now any traffic from IoT devices will only pass through the gateway, and if an IoT device decides to wander through local network drives, try to pack printers or workstations, it will not work.
The next step is to allow IoT devices access only to HTTP(s) ports
IoT devices should not be allowed to use third-party DNS so that they can bypass our locks. Since Internet management for Internet of Things requires connecting to the server via HTTPs, we will leave them only this protocol, and HTTP just in case.
In Zyxel ATP500, we create two access policies, where we specify the IoT zone as the source, the WAN as the destination– and HTTP and HTTPs as services.
Restrict access to trusted addresses only (easy way)
If you already know the Web addresses that the IoT device is "knocking" on, consider yourself lucky. We will create an alias of the allowed domains using the content filtering service, apply it to the IoT zone, and ban everything else. The Zyxel ATP500 implements filtering by domain names at the DNS query level and through a transparent HTTPs proxy with SNI header filtering, that is, devices do not even need to slip a certificate and decrypt their traffic.
HTTPs filtering is set up simply: create a separate profile for IoT and specify trusted addresses in it, for example tuya.com . Select the check mark "allow access only to trusted sites" – and that's it, the profile is ready. In many countries with a "sovereign" Internet, encrypted HTTP headers are cut by the providers themselves, so all manufacturers of IoT devices use unencrypted SNI headers, since they have nothing to hide and will work everywhere, so this protection may be enough.
DNS filtering in the form in which it is implemented in the Zyxel ATP500 will not allow you to easily resolve only the necessary domains, and ban the rest. Zyxel has a policy of whitelisting and blacklisting, and you can, for example, add a mask *.* to the blacklist, and in the whitelist – tuya.com , but the white and black lists are the same for all DNS filtering profiles, so you can't, for example, limit everything at once for IoT, and close only for managers example.com . Well, since we started blocking, let's block everything.
We apply the created HTTPs filtering policy to the IoT to WAN policy, and create two policies for the DNS filter: HTTP/HTTPs from IoT to Any (excluding Zywall) and HTTP/HTTPs from IoT to Zywall.
That's the end of it – congratulations, you have chosen a good supplier of IoT devices, and you do not need all of the following.
If the addresses of the management servers are unknown or not static?
The manufacturer can use different management server addresses or change them with firmware updates, a process that you cannot influence. In this case, the option with white and black lists will not work, so we can use malicious address filtering, preventing the device from accessing compromised resources to download malicious code.
Here, a reputation filter comes to our aid, blocking IP addresses and server domains on the Internet based on constantly updated signature databases. This filter is configured centrally on the Zyxel ATP500 gateway and applies to all internal subnets, including LAN, IoT and any others. There are white and black lists that are filled in manually, as well as support for individual URLs, but this item is not very useful to us. Filtering by dangerous categories like exploits, phishing sites, etc. is already enabled from the factory in Zyxel ATP500, so there is nothing to do. But if it doesn't seem enough to you, you can connect an external blacklist tape.
IDP protection
IDP protection can play a role when your IoT network is already infected with malware and you need to minimize unwanted activity coming from your network so that you don't have to answer to law enforcement agencies for participating in hacking something there. In Zyxel ATP500, it is activated centrally for all interfaces, so in order not to disrupt the work of normal clients, you need to use it extremely carefully.
For example, if you want to enable protection against DoS traffic from your network, you will be offered a choice of 266 (currently) rules that need to be activated manually. By default, a "soft" action is set – logging, so that the administrator himself can filter out false positives of signatures during the test period, and only then apply the drop or reject rule.
Preventing of bypassing restrictions via VPN
If there is a software tab in the device from the factory that allows you to bypass blocking via VPN on port 443 or 80, we can limit any such activity on the Zyxel ATP500 gateway through the application patrol. Create a VPN_block profile and add to it all services by the VPN keyword, or the entire Tunneling category.
After that, we apply the created application patrol profile to the IoT-to-WAN policy created earlier.
At this stage, we have implemented protections to protect your infrastructure from both untrusted IoT devices with a weak level of security, and from initially infected with malware by the manufacturer or supplier.
Conclusions
In no case should you be negligent about the threat posed by alien devices integrated into your network, and certainly do not dismiss it by saying "well, what will they do to us – we have all resources closed." It doesn't matter if you have one smart socket or a thousand motion sensors, you'd better make all these settings to prevent a situation where illegal activity is carried out from your IP addresses.
When using modern Zyxel equipment, the setup will not take much time.
Michael Degtjarev (aka LIKE OFF)
04/12.2023
