General

General FAQs about Zenarmor are outlined on this page.

Is Zenarmor® open source?

Zenarmor® consists of two modules:

• PHP Code & Python Scripts which provide the Web User Interface Functionality. This part is open source.

• The Packet Engine coded in C++. This part is closed source.

How Does Zenarmor TLS inspection feature work?

In terms of TLS inspection, there are two modes of inspection based on how deep the content inspection is and if decryption is in place:

1. Light-weight (or certificate-based) inspection: Zenarmor examines the initial phases of TLS sessions in this mode. These parts are still in clear text and contain useful data for identifying the type of remote application, remote hostname, and web category.

   The administration of certificates does not need any specific requirements, since this functionality is currently available across all membership levels. Zenarmor includes a basic Transport Layer Security (TLS) inspection capability for all edition including Free Edition, which involves extracting the Server Name Indication (SNI) from the certificate. The default setting enables the inspection of TLS traffic, which may be seen in the Reports section under TLS or in the Live Sessions section under TLS.

   This mode is already available for all subscription tiers and you don't need to do any certificate management. Light-weight TLS inspection is fully transparent.

2. Full TLS Inspection (or TLS decrypt/reencrypt): The Full TLS Inspection method involves Zenarmor terminating the SSL connection, decrypting the packet contents, doing a comprehensive packet inspection, and then re-encrypting the packet contents.

   The beta release of Full TLS Inspection with Zenarmor 1.17 was made accessible by the end of April 2024. In addition to the installation of CA certificates, no more requirements is necessary, ensuring a very transparent procedure.

   Zenarmor's Full Transport Layer Security (TLS) inspection capabilities improve the ability to monitor and control encrypted network traffic, hence offering a significant security benefit. Malicious actors often use encrypted communications to hide their nefarious actions, taking advantage of its widespread adoption. Zenarmor's Full TLS inspection functionality enables robust threat detection and prevention by decrypting and analyzing incoming and outgoing TLS packets. This approach enhances network security by establishing comprehensive monitoring, threat detection, and control systems for encrypted communications. It efficiently thwarts the penetration of hazardous information that could be hidden inside encrypted data streams, guaranteeing that security measures are not circumvented.

   Certificate-based (a.k.a. Light-weight) inspection is available on both the free version and the paid subscription tiers. On the other hand, the SSE/SASE/ZTNA memberships will provide users with the opportunity to use full TLS inspection.

SYN Flood Attack Detected! What should I Do?

As of v1.17, Zenarmor offers SYN flood attack detection capability. To be able to detect SYN flood attacks, Zenarmor monitors the SYN cache buffer. The SYN cache is a feature that helps mitigate SYN flood attacks by keeping track of recent SYN requests and responding to duplicates without involving the actual server. When the SYN cache buffer reaches a threshold value, predefined by Zenarmor, due to a large number of SYN packets and half-open TCP connections on your firewall, Zenarmor notifies you with a message indicating an SYN flood attack is detected on your network.

SYN flood attacks may occur in three ways:

1. Direct SYN flood attack: Direct SYN flood attack use a single source device with a legitimate IP address to send a large number of SYN requests to the server. When the server answers with SYN-ACK to acknowledge the connection, the attacker intentionally chooses not to react with the necessary ACK. Instead, they continuously send fresh SYN requests to the targeted server.

   While waiting for the ACK that never materializes, the server becomes overwhelmed by the inflow of SYN packets, which leads to the occupation of server resources and the establishment of several half-open connection sessions that last for a certain period of time. This monopolizes the server's resources, rendering it incapable of functioning effectively and denying requests from legitimate users.

   In direct SYN flood attack, the hacker manipulates the firewall settings or limits outbound traffic to solely SYN queries to guarantee that the SYN/ACK packets are disregarded. Given that hackers use their own IP addresses, they are very susceptible to identification. Since it becomes more convenient to track the origin of the assault and promptly terminate it, a Direct SYN flood attack is rarely used.

2. Spoofed SYN flood attack: In a spoofed attack, the malevolent client spoofs the IP address on every SYN packet delivered to the server. the attackers deliberately choose unused IP addresses to guarantee that the system does not react to the SYN-ACK response. Upon receiving the SYN request, the server promptly sends a SYN-ACK to the manipulated IP address and waits for a reply. Nevertheless, there is no reaction since the falsified origin did not transmit the packets.

   To evade detection, the malicious attacker employs SYN packets sent from IP addresses that have been falsified or manipulated. Spoofing complicates the process of tracking the packets and reducing the impact of the attack.

3. Distributed SYN flood attack: A Distributed Denial of Service (DDoS) SYN attack floods a target's system by flooding it with a deluge of SYN requests. In this assault, a multitude of infected machines, often organized into a botnet, collaborate to concurrently dispatch a large number of SYN packets to the intended target.

   The objective of distributed SYN flood attacks is to exhaust the target's resources, rendering it incapable of responding to valid requests and resulting in a denial of service. The attack's spread nature, using various sources, increases the difficulty of mitigating and defending against it. The sources appear authentic, but, the decentralized structure of the attack poses challenges in terms of mitigation. Every device inside the botnet has the ability to spoof its IP address, hence increasing the degree of obfuscation.

How to Detect and Track SYN Flood Attack Using Wireshark?

When Zenarmor sends you a SYN Flood Attack alert, you may want to detect and track the attack with a Wireshark packet analysis tool. To be able to track SYN flood attack, you may use the tcpdump tool to capture network packets on your firewall and save them as a .pcap file. Then, open this .pcap file on your local machine using Wireshark. This approach is advantageous for manually detecting direct SYN flood attacks and identifying the IP address of the attacker.

Wireshark can help detect SYN flood attacks by analyzing network traffic patterns. Look for a sudden increase in SYN packets from various IP addresses directed at a single server. You can filter for TCP flags and look for packets with the SYN flag set but the ACK flag cleared.

On Wireshark, you can apply a filter for SYN packets without an acknowledgment using the following filter: tcp.flags.syn == 1 and tcp.flags.ack == 0. You may see a high volume of SYN packets with very little variance in time. You may define a firewall rule to block the attacker's IP address if all SYN packets are originate from the same IP address.

The following pictures illustrate a significant influx of SYN packets originating from one specific source IP address and directed towards a single destination IP address.

Figure 1. Viewing TCP SYN Flood packets with Wireshark

Additionally, Wireshark allows you to analyze the timing and source of SYN packets to identify patterns associated with SYN flood attacks. You may look for a rapid increase in SYN packets within a short period. We have the option to see Wireshark's graphs, which provide a graphical depiction of the increase in network activity. The I/O graph may be seen by navigating to the Statistics > I/O Graph menu. The data reveals a significant surge in the total number of packets, increasing from almost nothing to a maximum of 2400 packets per second.

Figure 2. Viewing Statistics I/O Graph on Wireshark

By removing our filter and opening the protocol hierarchy statistics, we can see that there has been an unusually high volume of TCP packets:

Figure 3. Viewing Statistics on Wireshark

All of these data are signs of a SYN flood attack with little scope for interpretation. By using Wireshark, we can definitively identify the presence of a malevolent entity and implement appropriate measures to resolve the issue.

How to Mitigate SYN Flood Attacks?

There exist multiple strategies for mitigating SYN flood attacks. These may include increasing server resources, filtering SYN packets at the network level, or using specialized tools to detect and block the attack. Some methods for SYN flood attack mitigation are listed below:

1. Filtering: Filtering entails configuring network device rules to detect and obstruct malicious SYN requests in accordance with known malicious IP addresses or specific patterns. This feature effectively mitigates the risk of SYN Flood attacks by impeding the ingress of malicious traffic onto the server.
2. Rate limiting: Rate limiting incoming connection requests is an essential preventative measure against SYN deluge attacks. Implementing this methodology involves setting a predetermined limit on the utmost number of connection requests that a server is permitted to receive during a given period of time. Connection requests that exceed this threshold are delayed or rejected on purpose.
3. Increasing Backlog: By increasing the backlog queue, servers are capable of managing a greater volume of incoming SYN requests, thereby establishing a safeguard against overloading endeavors. In the event of a SYN Flood attack, the server can accommodate a greater number of concurrent connections by expanding the queue, thereby averting the depletion of resources.
4. SYN Cookies: In the case of SYN Cookies, the server returns a SYN-ACK without allocating resources for the connection promptly. Before allocating resources, a valid ACK response must be received. This lightweight methodology mitigates the risk of resource depletion by postponing the allocation of resources until the connection's legitimacy is verified.
5. SYN Cache: The server utilizes a cache to store less information about each incoming SYN request as opposed to allocating substantial resources for each request. By efficiently managing incoming traffic and processing only valid connection requests, this method reduces resource consumption.
6. SYN-RECEIVED Timer Reduction: By delaying the server's ACK response following the transmission of a SYN-ACK, resources that were previously allocated to half-open connections can be released more rapidly. A reduced timer enables the server to effectively administer resources in the event of a SYN Flood attack through the minimization of time spent on incomplete connections.
7. Recycling Old Half-Open Connections: Upon reaching capacity in the accumulation of connection requests, the earliest TCP connections that are half-open are recycled. As long as legitimate connections can be established more quickly than malicious half-connections are requested, this will function.
8. Proxies and Firewalls: An additional layer of security is provided by the implementation of firewalls and proxies, which filter malicious traffic prior to its arrival at the target server. Firewalls and proxies function as gateways by scrutinizing incoming traffic and permitting or prohibiting connections according to predetermined regulations. This strategy increases security by an additional tier, thereby diminishing the probability of SYN Flood attacks.
9. Load balancers: Load balancers play a critical role in preventing SYN flood attacks by managing the complete TCP SYN/SYN-ACK/ACK handshake. By distributing incoming network traffic across numerous servers, they effectively mitigate the impact of an attack on any one server. Although the repercussions of a SYN flood attack may persist, the implementation of load balancers serves to mitigate the risk of individual servers becoming saturated.
10. Hybrid Methodologies: A layered defense against TCP SYN Flood attacks is produced by combining multiple techniques; this ensures that other methods can continue to provide protection in the event that one method fails. A more robust defense strategy can be developed by organizations through the integration of SYN caching, SYN cookies, backlog adjustment, SYN-RECEIVED timer optimization, and filtering.

Each of these approaches possesses benefits and drawbacks. You can most effectively prevent a TCP SYN flood attack by ensuring that the configuration of your systems corresponds to your network security policy and infrastructure.

How can I deny all web traffic except for specific websites?

Zenarmor allows you to easily block all HTTP(s) traffic except for specific websites by following the next steps.

1. Navigate to the App Controls tab on the policy where you want to set the web restrictions.

2. Block Secure Web Browsing and Web Browsing categories. This action will restrict all HTTP and HTTPS connections.

3. Go to the Exclusions tab.

4. Add the domains or IP addresses you want to whitelist.

   warning

   For some websites, adding only the primary domain may not be sufficient for full functionality. You might also need to include their CDN domains. Use the Live Sessions feature to identify and verify these domains.

   tip

   You may need to add Zenarmor domains, zenarmor.net, zenarmor.com, sunnyvalley.io, sunnyvalley.cloud as a whitelist to prevent service interruptions

How often are Zenarmor Application & Web Database (threat signatures) updated?

The majority of our threat signatures are served through our real-time Cloud Infrastructure. This database is queried in real-time and signature updates to this system are almost continuous. We can push a new signature to the Cloud within minutes. ​

Zenarmor has a local database which caches the most popular domains and doesn’t query them. In addition, the queried domains not found in the local database are cached to increase the performance. The cache is updated hourly. ​

The local App database is used for the signatures that are more sophisticated. Since these signatures are complex, they require testing. Usually we ship 1-4 local signature updates per month. ​

The frequency of updates is independent of the OPNsense update cycle. Updates are handled directly by Zenarmor. ​

To ensure you receive the latest updates automatically, the toggle button must be enabled for the option Check for Zenarmor Application Database on the Settings → Privacy → Updates & Health pane. ​

Figure 4: Zenarmor Privacy Settings Updates & Health Pane

Can I also run DNS based filtering systems (Pi-hole, unbound) along with my Zenarmor?

Yes. You can run Pi-hole and other DNS filtering systems along with Zenarmor as an additional layer of defense.

The only thing you need to be aware of is that if you run these tools on a separate host other than the firewall itself (on which the Zenarmor is running), you'll need to disable DNS caching.

Reason is cached DNS traffic will NOT be traversing through the firewall; causing Zenarmor to miss DNS mappings.

For those scenarios, (like Pi-hole) we advise disabling caching on them and use firewall's dns cache as the forwarder.

How do I uninstall the Zenarmor plugin?

• Navigate to Zenarmor → Configuration

• Click on Uninstall tab

• Click on Uninstall Zenarmor packet engine button.

• Confirm that you want to proceed.

How do I get support for Zenarmor?

Please refer to Getting support section here

How do I send a bug report for Zenarmor?

Please refer to Reporting a Bug section here.