Skip to main content

Best Practices for Zenarmor Deployment

Published on:
.
10 min read

This guide outlines the fundamental best practices that administrators must follow in order to optimize and effectively implement the Zenarmor® configuration settings. These procedures encompass critical components, including ease of policy configuration, device examination, and security rule enforcement. Furthermore, the article provides additional information regarding the protection of IoT devices, virtual environment considerations, and efficient reporting strategies.

Before deployment, carefully plan your Zenarmor setup. Consider your network infrastructure, security requirements, and desired configurations to ensure a smooth deployment process. Follow the official installation guidelines provided by Zenarmor to ensure a correct and secure deployment.

By following the outlined best practices, you can ensure a secure, efficient, and reliable deployment of Zenarmor in your network.

Hardware​

Although Zenamor is a lightweight application that can efficiently run on low-end devices and requires at least 1 GB of memory, you should consider the following best practices for choosing hardware that runs Zenarmor:

  • Virtualization: If active devices are more than 500 and the sustained WAN bandwidth is higher than 500 Mbps, we do not recommend deploying Zenarmor as a virtual guest since resources in virtual environments are generally shared between guest systems.

  • Network Adapter: For better reliability and performance select netmap compatible network adapter. Intel-based adapters, particularly em(4) and igb(4), are observed to perform well in terms of stability and performance. If your network driver has netmap incompatibility issues, you may try Zenarmor with emulated netmap driver mode.

    Try to utilize emulated network driver mode with Zenarmor for Ethernet interfaces that are incompatible with Netmap. This should help you overcome the compatibility issues and ensure a smooth experience. The emulated mode has been enhanced to deliver superior performance.

  • CPU: A high single-core CPU score is more performant than multiple CPU cores.

  • RAM: It is advisable to have high RAM, at least 8 GB for a better reporting performance if you prefer an Elasticsearch database. To process large amounts of data, the amount of memory available in the system is crucial for the overall performance of Zenarmor. For more information please refer to Zenarmor hardware requirements page.

Platform​

Zenarmor is an all-software instant firewall that can be deployed virtually anywhere. Zenarmor supports a variety of open-source Linux platforms, such as RHEL, Ubuntu, Debian, CentOS, and FreeBSD-based firewall platforms like OPNsense and pfSense software CE. We advise you to install Zenarmor on the OPNsense firewall.

It should be noted that the principles of Zenarmor and a packet-filtering firewall operate independently of one another. Initially, incoming packets are processed by the Zenarmor engine. If the engine permits them to pass, they are then processed by the L4 firewall platform, such as pfSense or OPNsense, on which Zenarmor is operating. Outgoing packets, conversely, are initially processed by your L4 firewall. When the packet-filtering firewall grants access to the outgoing packets, the Zenarmor engine proceeds to analyze them. In order to be permitted through, a network communication must not violate any rule specified on either the L4 firewall or Zenarmor.

It is advisable to independently configure Zenarmor to enable L7 filtering and configure your firewall for L4 filtering.

Subscription​

Zenarmor offers several editions, such as Free, Home, SOHO, Business, and SSE. You should decide which subscription plan is right for you. The number of devices you want to protect on your network, security requirements, API access, policy count, high availability, support, and integration with other security tools, are some of the criteria that you should consider for the Zenarmor edition selection. You should consider the following points before purchasing a license.

  • All license activation keys are limited to a single node at a time. The license on the first node will be deactivated and the engine will begin to operate with the Free edition when the same key is reactivated on another node.
  • Beware that the Home edition offers a total 3 number of policies and the SOHO edition offers a total 5 number of policies, including the Default policy, while other premium editions have no policy limitation.
  • Some enterprise-level security options, like full TLS inspection, CASB, and URL blocking, are only available for SSE and higher subscriptions.
  • The pool licensing option is available for SSE Editions, providing flexibility with a single activation key for all firewalls in enterprise infrastructure.
  • Check Zenarmor plans page for comparing editions.

General Settings​

Some tips for general settings of Zenarmor are listed below:

  • CPU Pinning: Zenarmor has a setting to make CPU pinning optional, giving you more flexibility in how you configure your system for optimal performance. By default, Zenarmor is pinned to a dedicated core to prevent CPU context-switching overhead. If the process wanders between CPU processors, CPU cache misses occur, which has a negative impact on performance.

  • Hardware Offloading: Since hardware offloading is incompatible with netmap, you should deactivate interface hardware offloading at boot time on your Zenarmor next-generation firewall with netmap deployment. This avoids firewall delays and also saves at least one interface down/up event. For more information, please refer to our disabling hardware offloading guide.

  • Swap Rate: Zenarmor allows you to set swap utilization in order to run your next-generation firewall engine safely. If the swap usage percentage is more than the value specified by the user (default %60), the engine is stopped, and the user is warned by displaying an error message on the screen. Please note that this is not Zenarmor's SWAP usage; rather it is the overall system SWAP usage and may be the result of other memory-intensive applications that are running on the system. To see which processes are using the resident memory, you can use the following command:

    top -ao res

  • Bypass Mode: Bypass Mode feature is useful when investigating incompatible network driver(s), troubleshooting a problem with the packet engine, or resolving issues with other system components such as netmap. If the problem still exists in bypass mode, that means the problem is not related to the packet engine. Rather, it may be a netmap or OS problem.

  • Jumbo Frames: The maximum MTU value of a Zenarmor-protected interface can be 1500 bytes due to the incompatibility issue between netmap and jumbo frames. You may set the MTU option by navigating to Interfaces settings on your OPNsense/pfSense firewall web UI.

  • API Keys: Keep in mind that your API keys have a lot of power, so keep them safe! Do not post your private API keys on GitHub, in client-side code, or anywhere else that is publicly available.

Reporting Database​

Zenarmor provides several reporting database options, like local and remote Elasticsearch DB, MongoDB, and SQLite. Select the best reporting database option that meets your needs and consider your network size and the RAM your firewall has. Elasticsearch appears to be a superior backend database option for large enterprise networks with hundreds of devices. A minimum of 8GB of RAM is required to operate ES in conjunction with Zenarmor. Additionally, you may transfer your data to a remote Elasticsearch database.

If you're using MongoDB backend and experiencing problems, it might be wise to switch to the Elasticsearch backend

In the case of residential networks or tiny networks, SQLite can adequately facilitate efficient reporting.

SSD drives are suggested for optimal reporting performance.

Policy Configuration​

The following tips are beneficial for defining a Zenarmor policy.

  • Using minimal criteria: Define your policy configuration as simply as possible. When multiple criteria are specified for a policy, it is applied exclusively to network packets that satisfy each of the specified criteria.

    Please note that the 'AND' logical operator is used to evaluate all policy criteria in Policy Configuration, not the 'OR' logical operator. So, for a particular type of traffic to match a specific policy, all criteria must be met. For instance, if you've created a policy and specified VLAN ID, IP, and username criteria, a session must match all of those. The only exceptions to this rule are Devices and MAC addresses, where they can be used interchangeably.

    For example, in the case where a policy configuration specifies the "Mobiles" device category and the 10.0.0.0/24 network, these should all be identical. Upon observing a transmission originating from the "Mobiles" device with the IP address 10.11.11.11, this flow will fail to comply with the specified policy.

    As another example, adding a detected device, CEO_laptop, and a user, CEO, to the policy named CEO_Rules would ensure that the policy would only be triggered when a user whose login identity is CEO utilized the CEO_laptop to connect to the network. When another user account utilizes this device to connect to the network, the CEO_Rules policy is not implemented on its network traffic.

  • Policy Processing Order: Zenarmor policies are processed in order, beginning from top to bottom. The most frequently matching rule should be placed at the top of the rule list for better performance, reducing unnecessary processing.

  • Default Policy Configuration: Although the Default policy configuration is mostly static and you can configure a limited set of parameters depending on your subscription, it is advised to enable the Block Untrusted Devices option in this policy. This will prevent rogue devices from accessing your network for harmful activities.

  • Block Untrusted Devices: It is recommended to enable Block Untrusted Devices on policies whose criteria match a broad range of endpoints, such as networks and VLANs, to prevent unauthorized access to your network by unknown devices.

  • MAC Address Criteria in Policies: There is no requirement to include MAC address criteria for Device- or Device Category-based policies. Caution is advised, as this particular policy applies solely to devices whose MAC addresses are explicitly specified within the policy. Inaccurate policy configuration due to improperly designed policies results in unforeseen packet filtering and package mismatching.

  • Enable Essential and Advanced Security Rules: To safeguard your IT resources from potential malicious connections and prevent any suspicious network activities, it's recommended to enable all Essential and Advanced Security Rules by selecting the High Control option in the upper right corner of the Security Rules page. In case you encounter false positive issues, you can effectively resolve them by creating exclusions through Live Sessions Explorers.

  • Be Careful with Whitelisting: Beware that exclusions take precedence over all your Security, Application Control, and Web Control rules. Particularly when adding a whitelist to a security category, exercise caution, as an erroneous definition could compromise your network.

  • Network Segmentation for IoT Devices: By separating your IoT devices from valuable IT assets using separate VLANs/networks and subsequently activating the Exempted VLANs & Networks option, you can prevent your devices from exceeding the device limitations specified in your purchased license. Exempted VLANs and Network addresses are circumvented by Zenarmor processing. There will also be no activity reported for these devices in the reports.

  • Blocking DOH/DOT: In order to show the block notification page, it is necessary to ban clients on your network from utilizing DNS-over-HTTPS (DOH) or DNS-over-TLS (DOT), since the Block Notification Page feature relies on DNS-based filtering.

    Typically, users activate DNS over HTTPS or DNS over TLS settings on their web browsers. To prevent DOH and DOT traffic on your network, you may activate the DNS over HTTPS feature in the Essential Security rules. Additionally, you can enable the DNS over HTTPS and DNS over TLS choices in the Network Management settings under Application Controls.

  • Interface Selection: If you do not select any interfaces in the policy configuration, the policy will be checked for network packets on all interfaces.

  • App Controls vs Web Controls: The difference between Application Controls and Web Controls is that Web Controls provide a more specific and focused policy management for HTTP and HTTPS (Web) based connections. Application Controls, on the other hand, work for all protocols and connection types and a more generalized control mechanism.

    For instance, if you want to block a specific website or category that you know operates over HTTP protocol, you are advised to control access through Web Controls.

    If you want to create an access policy for Tor Browser which can operate in any TCP port, your best bet will be to do it via Application Controls.

  • TLS Inspection: Prior to implementing full TLS inspection on an organization, it is recommended to meticulously strategize the TLS inspection deployment and adhere to established TLS inspection best practices.

  • URL Blocking: In order for the URL Blocking feature to function, your policy must have Full TLS Inspection enabled (TLS decrypt/re-encrypt).

  • App Controls: You may need to block QUIC Protocol Applications for Streaming Applications like YouTube or Facebook. You may wish to block ads and ad trackers via App Controls settings.

  • No Internet: In the policy, there is a No Internet option. You can deny the network connection of kids for some hours by defining a schedule for the policy and activating the No Internet option.

Reporting Configuration​

Best practices for Zenarmor reporting configuration are given below:

  • Enable Community ID Flow Hashing: Enable Community ID flow hashing to easily correlate network security events generated by other security tools on your network, like Suricata and Snort. This correlation provides a more comprehensive view of network activities and aids in the identification and response to potential threats. Enabling Community ID flow hashing ensures a synchronized and unified approach to network security across different tools, contributing to a more robust defense against various cyber threats.
  • Stream Reporting Data to Syslog or SIEM: Enable stream reporting data to your Syslog server or SIEM tool, such as Wazuh, Splunk, or Datadog, for unified security and powerful monitoring. This capability ensures unified security across your network and empowers you with powerful monitoring capabilities. By seamlessly integrating reporting data into your chosen Syslog or SIEM solution, you gain valuable insights, enhance threat detection, and streamline the management of security events. This proactive approach contributes to a more resilient and responsive security infrastructure.
  • Configure Reporting Data Period: Configure the reporting data period in accordance with the hardware specifications and reporting database of your choice. Zenarmor includes the optimal reporting data period for your database type by default.
  • Anonymization: You may anonymize your local and remote IP addresses for security and privacy purposes. If these options are enabled, Zenarmor will mask actual local and remote IP addresses and instead display anonymized IP addresses in your Reports.
  • DNS Enrichment: It is advised to enable DNS enrichment. Zenarmor analyzes DNS traffic and maps IP addresses to their DNS names. This will increase your filtering success rates and is highly recommended.
  • Web & App Controls: It is important to note that web controls are given priority over application controls. As a result of blocking a connection based on web control rules, the corresponding sessions will not undergo application control processing, and related reports will not contain application control information.

Protected Interfaces​

You should consider the following key points when configuring Zenarmor-protected interfaces:

  • Protect LAN Interfaces: As a best practice, it is recommended to protect LAN interfaces. You may run Suricata on WAN interfaces to protect your network against intrusions.
  • Suricata Deployment: if you're running Suricata on IPS mode, make sure you run them on different interfaces since they both use the same packet I/O subsystem (netmap), which can only be used by single process at the same time.
  • Select Parent Interface instead of VLANs: As a best practice, it is advised to select physical parent interfaces, such as igb0, instead of VLAN interfaces for protection. This will enable Zenarmor to inspect all subinterfaces of the physical interface including the VLAN interfaces. Beware that if you select both VLAN interfaces and their parent interfaces, this will result in unnecessary duplications of effort in packet processing and reporting.
  • Set Security Zone Properly: Ensure that the security zone tags are properly specified for each protected interface. Misconfiguring the interface tag might lead to issues with filtering and reporting. For instance, if you designate the LAN tag to your WAN interface, public IP addresses on the Internet that your internal clients connect to will be seen as local devices. This might result in the device identification function producing results that lack significance.

VPN Protocol Selection​

To protect your VPN (Virtual Private Network) clients against cyber threats using Zenarmor, you should prefer WireGuard VPN which is compatible with netmap. OpenVPN tun interface has no support for netmap driver on OPNsense anymore.

Device Identification​

Once Zenarmor has been installed on your firewall, proceed to examine devices on your network by navigating to the Zenarmor Devices page, and then verify them as trusted. Zenarmor defines all newly detected devices as untrusted by default. Suspicious or unknown devices should be left untrusted.

When you enable Device Access Control, these devices cannot connect to the network until you manually verify and acknowledge them as Trusted.

To keep unknown devices from getting into your network without your permission, you should turn on Block Untrusted Devices on rules that match a lot of different endpoints, like networks and VLANs.

Give Zenarmor some time and a chance for more accurate device identification. It should be noted that this is the initial iteration of the Zenarmor Device Identification function. Although it demonstrates exceptional capability in identifying the majority of devices connected to your network, certain instances may arise where minor inconsistencies or inaccurate data are detected, necessitating manual user intervention for correction and input.

The more network packets inspected and the more information they provide, the more accurate device identification. Device identification is an ongoing process until you stop it intentionally. Zenarmor continuously examines network flow to find detailed information about devices and to catch updates on them. To ensure that all devices are accurately displayed on your Zenarmor interface, allow Zenarmor some time and opportunity to detect them.

You can manually update automatically detected device details, such as name and device category. User-defined settings have higher priority than the settings automatically detected by Zenarmor. For instance, when a user changes the detected name or category of a device, the Zenarmor device database is updated, and detected values are ignored. Values set by the user manually are displayed.

If you attempt to remove a device that has recently been seen, it will reappear on the next scan. Therefore, it is advised to hide online devices instead of deleting them.

Cloud Threat Intelligence​

Zenarmor provides AI-based threat intelligence safeguarding your network against more than 300 million websites and domains is a remarkable standard feature that provides sophisticated protection and is included in all Zenarmor subscriptions, from the Free Edition to the SSE Edition. Some consideration about Zenarmor cloud threat intelligence service are outlined below:

  • Communication between Zenarmor and Zenarmor Cloud Threat Intelligence servers uses an encrypted proprietary protocol flowing on UDP ports 5353, 5355 and 3478. Those who are strictly filtering outbound connections will need to allow communication to the Zenarmor CTI servers via these UDP ports. Also, if you see Cloud Nodes are Down on the Zenarmor dashboard, ensure that ICMP is allowed from your Zenarmor node to CTI servers.
  • It is not recommended to disable the cloud threat intelligence service for effective application and web filtering. This might negatively impact your filtering success rates and security posture if disabled.
  • You may set local domain settings to be excluded from cloud queries. This might be handy if you see that your local domain is being categorized as Firstly Seen Sites.
  • Optimum Cloud Reputation servers are automatically selected for fast cloud queries according to their network response times.
  • Zenarmor caches the query results for better performance and periodically checks for updates on the cached items. Clearing the cache might come in handy if you want some particular categorization change to get applied immediately.

Certificate Management​

It is advisable to implement an intermediate Certificate Authority (CA) for Zenarmor. So that, you would be deploying your own root certificate authority on the endpoint devices.

If the firewall is compromised/reinstalled and the private key of the intermediate CA used for Zenarmor is lost, you may sign a new Zenarmor intermediate CA key using your own ROOT CA. Since the endpoints already own the customer's own ROOT CA, no issues will arise.

For inspecting TLS traffic or viewing the Zenarmor block notification page for TLS traffic, you need to install the Zenarmor internal CA certificate on your client devices as a trusted certificate.

If you reinstall your OPNsense firewall or Zenarmor node, you will need to import this CA certificate to your Zenarmor.

To be able to import the CA certificate, you must have not only the certificate file in PEM or CRT format that you obtained from the Zenarmor Certificate Authority Settings page but also the private key for the CA certificate. These files, internal_ca.pem, and internal_ca.key, are located in the path /usr/local/zenarmor/etc/cert on your node.

It is highly advisable to duplicate and store these certificate files on a separate secure device that is not publicly accessible while enabling TLS inspection or blocking notice page functionalities. Automating this task may be achieved by using the backup and restore functionality of Zenarmor.

Cloud-Based Management​

Register your node to the Zenconsole and enable the cloud management portal to administer all of your firewalls from the cloud and through a single pane of glass. Sharing firewall administration and establishing centralized, location-independent policies is incredibly beneficial, particularly for MSSPs and enterprises with multiple Zenarmor deployments.

Managed Service Providers (MSPs) can manage their customer's subscriptions on Zenconsole. They can view, cancel or purchase a subscription for the customers.

Update​

Stay up to date with Zenarmor updates and patches to protect your deployment from vulnerabilities. Regularly check for updates and apply them promptly. Sometimes software upgrades can be challenging, but if you follow the advice below, the process can be relatively straightforward and have minimal impact on your business. Here are the best practices that you may follow to upgrade your Zenarmor safely:

  1. Create Snapshot: Before beginning the upgrade procedure, create a snapshot of your virtual machine if you are operating your firewall in a virtual environment, such as Proxmox VE. So that you can rapidly deploy and operate your firewall system by minimizing downtime in the event of a problem.
  2. Test in a Staging Environment: Whenever possible, test the upgrade in a staging or test environment that closely mimics your production setup. This allows you to identify and resolve any compatibility or performance issues before deploying the upgrade in the production environment.
  3. Ensure Your Connection is Reliable: Ensure that you have a secure and reliable network connection to download the firmware update.
  4. Schedule Appropriate Time: To reduce service interruption and cybersecurity risks, schedule an appropriate time for your business. Establish a maintenance window that does not interfere with prime operation hours or periods of heavy network traffic. Weekend or nighttime hours are typically optimal for significant system upgrade operations. Do not enhance your system during office hours; instead, conduct a thorough analysis to determine when an upgrade or prospective rollback will have the least impact on your business.
  5. Get Approval: It is essential to understand who has the authority to make upgrade decisions and who makes the final "Go" or "No-Go" determination. Share your plan for an upgrade with your manager or approval committee and obtain their approval. Maintain an open line of communication with your manager regarding why you're upgrading, what you're upgrading, and when. Open channels of communication contribute significantly to the success of an upgrade: between departments impacted by the upgrade, between front-line staff and decision-making management, and, if necessary, between your organization and external partners and visitors.
  6. Prefer Zenarmor UI: It may be better to use the Zenarmor > Status page to update your Zenarmor in a more controlled and safe way.
  7. Fresh Install and Restore Backup: If you are unable to upgrade Zenarmor NGFW and cannot resolve the issue, you can attempt a fresh installation and restore from your most recent backup.
  8. Document and Review: It is essential to document the entire process of the upgrade. You must document the update's specifics and procedures, including the date, time, source, version, and modifications made. You must also document any problems or errors that arose, as well as how they were resolved or avoided. You must assess the efficacy, efficiency, and customer contentment of the update or revision, as well as review the process and the outcomes. In addition to sharing your findings and lessons learned with your stakeholders, you must also provide feedback and recommendations for future updates or enhancements. This information should be recorded in a readily accessible location so that you can enhance your process next time.

Backup and Recovery​

To be prepared for the worst-case scenario, regularly back up your Zenarmor configuration and reporting data to ensure quick recovery in case of system failures or security incidents. If you do have to roll back with a fresh installation of Zenarmor, you may rapidly recover from the failure by restoring your next-generation firewall. Test your backup and recovery procedures periodically.

Monitoring​

Implement monitoring tools to track the performance and security of your Zenarmor deployment. Analyze logs and reports to identify any suspicious activities or potential security threats.

You must examine the firewall's functionality, efficacy, stability, and compatibility. Check the Zenarmor notification page. Notifications enable you to be notified of critical Zenarmor firewall events. If you encounter any problems or errors, you must promptly identify and correct them, or revert to the previous state if necessary.

Training and Documentation​

Provide training to your team on using Zenarmor effectively and securely. Document deployment procedures, configurations, and best practices for future reference.

Support​

Never forget that Zenarmor is always by your side. You can communicate with the Zenarmor support team at any time. If you are experiencing issues with your next-generation firewall, do not hesitate to contact the support team.

Watch Now​

Here is a video for Zenarmor Deployment Best Practices:

Last updated on by Zenarmor