How to Configure a Wazuh IP Whitelist

An IP whitelist is a network access-control mechanism that permits connections only from explicitly trusted IP addresses or network ranges. In a Wazuh deployment, this can be useful for limiting access to sensitive services such as the Wazuh server API, Dashboard, Indexer, agent enrollment service, and other management interfaces.

However, it is important to understand that Wazuh does not have one universal ip_whitelist setting that controls every component.

Wazuh is composed of several services with different communication paths, ports, and security mechanisms.

The appropriate way to implement IP allowlisting therefore depends on which Wazuh service you want to protect and where the access-control boundary should be enforced.

Wazuh’s architecture consists primarily of the Wazuh agent, Wazuh server, Wazuh indexer, and Wazuh dashboard.

Agents communicate with the Wazuh server, the server forwards data to the indexer, and the dashboard communicates with both the Wazuh server API and indexer. This distinction matters when configuring a Wazuh IP Whitelist.

Restricting access to port 55000, for example, protects the Wazuh server API but does not automatically restrict agent connections on port 1514 or web access to the Dashboard on port 443.

Why IP Whitelisting Is Important for Wazuh Deployments

Wazuh components frequently expose network services that should not be reachable from arbitrary systems.

Limiting those services to known networks reduces the number of systems capable of initiating connections to sensitive infrastructure.

For example, an organization might allow:

Wazuh agents to connect to the manager only from corporate endpoint networks.
SOC analyst workstations to access the Wazuh Dashboard.
Administrative jump hosts to access the Wazuh API.
Wazuh servers to communicate with the Wazuh Indexer.
A trusted automation server to communicate with management APIs.
A specific monitoring network to access Wazuh infrastructure.

Wazuh documents several default communication ports, including TCP 1514 for agent connections, TCP 1515 for agent enrollment, TCP 1516 for cluster communication, TCP 55000 for the Wazuh server API, TCP 9200 for the Indexer API, and TCP 443 for the Dashboard.

Restricting these ports at the network boundary can substantially reduce unnecessary exposure.

For example, if the Wazuh API is required only by an internal administration subnet, there is little reason for arbitrary Internet hosts to be able to establish TCP connections to port 55000.

Common Use Cases for Trusted IP Addresses

A Wazuh IP whitelist is particularly useful in environments where the source networks are predictable.

Common use cases include:

Restricting Wazuh Dashboard access to corporate networks or VPN ranges.
Restricting API access to administrator workstations and automation servers.
Restricting agent enrollment to approved endpoint networks.
Restricting Wazuh manager connections to known agent subnets.
Restricting Indexer access to Wazuh server and approved administrative systems.
Allowing cloud security infrastructure to communicate with an on-premises Wazuh deployment.
Limiting management access to a dedicated bastion or jump-host network.
Separating production and administrative networks in larger Wazuh environments.

CIDR ranges are particularly useful here.

Instead of maintaining hundreds of individual addresses, you can allow a trusted network such as 10.20.30.0/24.

For example:

10.20.30.0/24

could represent the organization’s SOC analyst network.

An allowlist could then permit connections from that subnet while denying connections from other networks.

Wazuh IP Whitelisting vs. Firewall-Based Access Control

The phrase “Wazuh IP whitelist” can be misleading because IP restrictions are not necessarily implemented inside Wazuh itself.

In many deployments, the most appropriate implementation is a host-based firewall, network firewall, security group, network ACL, reverse proxy, or load balancer positioned in front of the Wazuh service.

For example:

SOC Workstation
      |
      | TCP 443
      v
+----------------+
| Firewall       |
| Allow:         |
| 10.20.30.0/24  |
+----------------+
      |
      v
Wazuh Dashboard

The firewall determines whether the source IP is permitted to reach the service.

This is different from application-level authentication.

A firewall may determine:

“Can this IP address establish a connection?”

Authentication then determines:

“Is this user or service authorized to use the application?”

Those controls should generally be used together rather than treating an IP allowlist as a replacement for authentication.

This aligns with the guidance in NIST SP 800-207, which emphasizes that organizations should not implicitly trust a user, device, or resource simply because it originates from a particular network location.

NIST’s zero-trust architecture therefore treats network location as only one part of the security model rather than as proof of identity or authorization.

What You Will Configure in This Guide

This guide explains how to approach Wazuh IP whitelisting at the appropriate layer instead of looking for a single global Wazuh configuration parameter.

You will learn how to:

Identify which Wazuh service needs IP restrictions.
Determine the relevant source and destination IP addresses.
Identify the Wazuh port associated with the service.
Decide whether the restriction belongs in Wazuh, the operating-system firewall, or an upstream network firewall.
Use individual IP addresses and CIDR ranges for trusted networks.
Restrict access to the Wazuh API, Dashboard, Indexer, and agent-related services.
Verify that approved addresses remain accessible.
Confirm that unauthorized networks are blocked.
Combine network restrictions with Wazuh authentication and authorization controls.

For example, if your goal is specifically to restrict administrative access to the Wazuh API, the API’s host and port settings are relevant.

Wazuh documents the API configuration in /var/ossec/api/configuration/api.yaml, with port 55000 used by default.

Related Guide: How to Configure Wazuh RBAC

RBAC should complement IP restrictions because an IP address alone does not determine what an authenticated Wazuh user is authorized to do.

What Is a Wazuh IP Whitelist?

A Wazuh IP whitelist is a set of trusted IP addresses or network ranges that are explicitly permitted to communicate with a Wazuh service.

The term allowlist is increasingly preferred over whitelist, but both terms describe the same basic network-security concept.

For example, suppose a Wazuh Dashboard should be accessible only from:

168.10.50
168.10.51
168.10.52

Those addresses could be permitted by the firewall while connections from other source addresses are denied.

Alternatively, if all SOC workstations reside within:

192.168.10.0/24

the entire subnet can be allowed instead.

The important point is that the IP restriction applies to a specific network communication path. It does not automatically apply to every Wazuh component.

Definition of an IP Whitelist

An IP whitelist is an access-control list containing network addresses that are allowed to establish connections to a protected service.

A simple allowlist might look like:

10.10.25
10.10.26
10.20.0/24

This means:

10.10.10.25 is trusted.
10.10.10.26 is trusted.
Hosts in 10.10.20.0/24 are trusted.

Whether everything else is denied depends on the firewall or access-control policy surrounding the service.

A typical policy might therefore be:

Source: 10.10.10.0/24
Destination: Wazuh Server
Port: 55000/TCP
Action: ALLOW

followed by a broader deny rule:

Source: ANY
Destination: Wazuh Server
Port: 55000/TCP
Action: DENY

The exact syntax varies between ufw, firewalld, nftables, iptables-based configurations, cloud security groups, hardware firewalls, and other network-control platforms.

How IP Allowlisting Works

IP allowlisting evaluates the source address of a network connection against an access-control policy.

Consider a Wazuh API server at:

10.0.0.10

The API listens on:

10.0.0.10:55000

An administrator connects from:

10.0.10.25

The firewall evaluates the connection:

Source IP:      10.0.10.25
Destination IP: 10.0.0.10
Destination Port: 55000
Protocol:       TCP

If 10.0.10.25 is permitted, the connection is allowed to reach the API.

If the address is not permitted, the firewall can reject or drop the connection before the request reaches the Wazuh API.

This provides an important layer of defense because unwanted traffic can be stopped before the application has to process it.

Wazuh itself also provides application-level security controls.

For example, Wazuh’s API requires authentication for its endpoints, and the API supports JWT-based authentication.

Related Guide: How to Configure Wazuh Alerts

Wazuh Components That Can Benefit From IP Restrictions

Different Wazuh components have different network exposure requirements.

Wazuh component	Typical port	Potential IP restriction
Wazuh server / agent communication	`1514/TCP`	Allow only trusted agent networks
Agent enrollment	`1515/TCP`	Allow only approved enrollment networks
Wazuh cluster	`1516/TCP`	Allow only cluster nodes
Wazuh server API	`55000/TCP`	Allow administrators and trusted automation
Wazuh Indexer API	`9200/TCP`	Allow Wazuh servers and authorized administrators
Wazuh Dashboard	`443/TCP`	Allow corporate/VPN/SOC networks
Syslog collector	`514/UDP` or `514/TCP`	Allow only approved log sources

These are default ports and can be changed depending on the deployment.

Wazuh’s official architecture documentation provides the current list of component ports and their purposes.

For example, a production environment might use the following model:

Internet
   |
   X  Blocked
   |
Firewall
   |
   +---- 443 ----> Wazuh Dashboard
   |
   +---- 55000 --> Wazuh API
   |
   +---- 1514 ---> Wazuh Manager

Each service can have a different allowlist because each service serves a different purpose.

Source IP Addresses vs. Destination IP Addresses

Understanding source and destination addresses is essential when configuring a Wazuh IP whitelist.

The source IP identifies the system initiating the connection.

The destination IP identifies the Wazuh service receiving the connection.

For example:

Source:
192.168.50.25

Destination:
192.168.100.10

Destination port:
55000/TCP

Here, 192.168.50.25 is the administrator’s workstation, while 192.168.100.10 is the Wazuh server.

The allowlist would normally be concerned with the source address:

ALLOW 192.168.50.25 -> 192.168.100.10:55000/TCP

This distinction becomes particularly important when Wazuh is behind a reverse proxy, load balancer, NAT gateway, VPN, or other intermediary.

The Wazuh server might not see the original client IP in every architecture. Instead, it may see the address of the proxy or load balancer.

Consequently, IP restrictions should be designed around the actual network path rather than assumptions about where the connection originates.

IPv4 and IPv6 Considerations

A Wazuh IP allowlist should account for both IPv4 and IPv6 if IPv6 is enabled in the environment.

An IPv4 address might look like:

192.168.1.50

An IPv4 CIDR range might be:

192.168.1.0/24

An IPv6 address might look like:

2001:db8:1234::10

and an IPv6 network could be represented as:

2001:db8:1234::/64

This matters particularly for Wazuh API deployments. Wazuh documents the API’s default host configuration as:

host: ['0.0.0.0', '::']

which represents listening on IPv4 and IPv6 addresses respectively.

If your firewall restricts only IPv4 traffic while IPv6 remains reachable, an attacker could potentially bypass an IPv4-only allowlist through IPv6.

Therefore, when IPv6 is enabled, verify both:

IPv4 policy
+
IPv6 policy

Related Guide: How to Configure a Wazuh Proxy

IP Addresses, CIDR Ranges, and Subnets

A whitelist can contain individual addresses or entire network ranges.

An individual address:

192.168.10.25

allows one host.

A /24 CIDR range:

192.168.10.0/24

represents a larger network.

CIDR-based rules are useful when Wazuh clients are organized into predictable network segments.

For example:

SOC network:
10.20.10.0/24

Server network:
10.20.20.0/24

Endpoint network:
10.20.30.0/24

You could create separate policies for each:

Dashboard:
10.20.10.0/24

Wazuh API:
10.20.10.0/24

Agent communication:
10.20.30.0/24

This is generally easier to maintain than hundreds of individual IP addresses.

However, avoid using excessively broad ranges simply because they are convenient. An allowlist of:

10.0.0.0/8

may technically work, but it potentially trusts millions of addresses across an enterprise’s private network.

A smaller subnet or explicit host list usually provides a tighter security boundary.

How Wazuh Handles IP-Based Access Control

One of the most important concepts when configuring a Wazuh IP Whitelist is that Wazuh does not provide a single global IP allowlist that automatically governs every network connection.

Instead, Wazuh consists of multiple services, each with its own communication requirements and security controls.

The architecture documentation identifies separate communication paths between agents, Wazuh servers, the Indexer, and Dashboard.

This means IP restrictions should be applied to the specific service or network boundary that needs protection.

Wazuh Manager Network Access

The Wazuh manager, referred to as the Wazuh server in current Wazuh documentation, provides several network services.

Agent connections normally use TCP port 1514, while agent enrollment uses TCP port 1515. Wazuh cluster communication uses TCP port 1516.

A firewall can therefore restrict these services independently.

For example:

ALLOW 10.20.30.0/24 -> WAZUH_MANAGER:1514/TCP
ALLOW 10.20.30.0/24 -> WAZUH_MANAGER:1515/TCP
DENY  ANY           -> WAZUH_MANAGER:1514/TCP
DENY  ANY           -> WAZUH_MANAGER:1515/TCP

This ensures that only the expected endpoint network can communicate with the manager’s agent services.

For a cluster, the policy should instead allow communication between the specific Wazuh server nodes that participate in the cluster.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

Wazuh Agent-to-Manager Communication

Wazuh agents establish connections to the Wazuh server to transmit security events and other collected information.

By default, the Wazuh agent connection service listens on TCP 1514. Wazuh also supports UDP for agent connections, although it is disabled by default.

This creates a natural opportunity for network-level allowlisting.

For example, if production endpoints are located in:

10.50.0.0/16

the firewall can allow that network to communicate with the manager’s agent port:

ALLOW 10.50.0.0/16 -> WAZUH_MANAGER:1514/TCP

Other networks can be denied.

This is particularly useful when the Wazuh manager has multiple network interfaces or when the environment contains separate production, development, guest, and administrative networks.

Related Guides:

Wazuh API Access

The Wazuh server API is one of the most important services to protect with IP-based restrictions.

The API listens on TCP port 55000 by default. Wazuh’s API configuration is stored in:

/var/ossec/api/configuration/api.yaml

The API documentation also exposes a host parameter that determines which IP addresses or hostnames the API listens on.

A typical configuration includes:

host: ['0.0.0.0', '::']
port: 55000

This does not mean that every client is automatically authorized to use the API. It means the API is listening on those local interfaces.

Authentication and authorization are separate controls.

Wazuh’s API uses authentication tokens for API requests, with endpoints requiring a JWT token after authentication.

For stronger network protection, you can place a firewall rule in front of the API:

ALLOW 10.20.10.0/24 -> WAZUH_MANAGER:55000/TCP
DENY  ANY           -> WAZUH_MANAGER:55000/TCP

This creates two distinct security layers:

IP allowlist
     ↓
API authentication
     ↓
Wazuh authorization / RBAC
     ↓
API resource

Related Guide: How to Configure Wazuh RBAC

Wazuh also provides API-specific hardening controls such as rate limiting and login-attempt restrictions.

Its documentation describes limiting API login attempts from the same IP address and temporarily blocking an address after the configured threshold is exceeded.

Wazuh Dashboard Access

The Wazuh Dashboard provides the web interface used by analysts and administrators.

The standard Dashboard port is TCP 443.

If the Dashboard is intended only for internal users, exposing it directly to the public Internet is generally unnecessary.

A common design is:

Corporate Network
       |
       v
   Firewall
       |
       | TCP 443
       v
Wazuh Dashboard

The firewall can permit only:

10.20.10.0/24

or the organization’s VPN address pool.

For example:

ALLOW 10.20.10.0/24 -> WAZUH_DASHBOARD:443/TCP
ALLOW 10.99.0.0/24  -> WAZUH_DASHBOARD:443/TCP
DENY  ANY           -> WAZUH_DASHBOARD:443/TCP

This approach is particularly useful when remote SOC analysts access Wazuh through a corporate VPN.

Related Guides:

IP restrictions should still be considered an additional network-control layer rather than a replacement for SSO, MFA, authentication, or RBAC.

NIST specifically warns against treating network location as implicit trust.

Its zero-trust guidance recommends explicit authentication and authorization rather than assuming that a system is trusted because it resides on an internal network.

Wazuh Indexer Access

The Wazuh Indexer is responsible for storing and querying Wazuh security data.

The Wazuh architecture documentation lists TCP port 9200 as the default Wazuh Indexer REST API port and TCP ports 9300-9400 for Indexer cluster communication.

The Indexer should generally have a much narrower network exposure than the Dashboard.

For example:

Wazuh Server
     |
     | TCP 9200
     v
Wazuh Indexer

A firewall could permit:

ALLOW WAZUH_SERVER_IP -> INDEXER_IP:9200/TCP

while blocking arbitrary client networks.

In a multi-node Indexer deployment, the cluster communication ports also need appropriate rules between the participating Indexer nodes.

Related Guides:

Where Firewall Rules Fit Into the Wazuh Architecture

Firewall-based IP allowlisting normally sits outside the Wazuh application itself.

Conceptually:

                 Internet
                    |
                    X
               Firewall
                    |
          +---------+---------+
          |                   |
       Allowed              Denied
          |
          v
   Wazuh Infrastructure
          |
   +------+------+------+
   |      |      |      |
 Agent  API  Dashboard Indexer

This provides a network-layer security boundary around Wazuh services.

The advantage is that unwanted traffic can be blocked before it reaches the application.

CISA’s communications-infrastructure hardening guidance similarly recommends network segmentation using mechanisms such as router ACLs, stateful inspection, firewalls, and DMZs as part of a broader defense-in-depth strategy.

Why Wazuh Does Not Use a Single Universal “IP Whitelist” Setting

A common misconception is that Wazuh should contain a configuration such as:

<ip_whitelist>
    <ip>10.10.10.0/24</ip>
</ip_whitelist>

that automatically protects every Wazuh service.

That is not how the Wazuh architecture works.

Each service has a different purpose:

Agent
  |
  +--> Wazuh Server :1514
                 |
                 +--> API :55000
                 |
                 +--> Filebeat --> Indexer :9200
                                      |
                                      v
                               Dashboard :443

Consequently, the appropriate access-control policy depends on the specific connection.

For example:

Agent access should be restricted around the agent communication service.
Enrollment access should be restricted around the enrollment service.
API access should be restricted around port 55000.
Dashboard access should be restricted around port 443.
Indexer access should be restricted around port 9200.
Cluster communication should be restricted to trusted Wazuh or Indexer nodes.

This is also why simply changing the Wazuh API host setting should not be described as configuring a universal Wazuh IP whitelist.

The API host setting controls where the API listens, while firewall rules control which remote source addresses can reach it.

Wazuh explicitly documents the API host and port parameters separately from its authentication and other security controls.

The practical security model is therefore:

Network access control
        +
Service-level configuration
        +
Authentication
        +
Authorization
        +
Logging and monitoring

That layered approach is more defensible than relying on an IP address as the sole security control.

NIST’s zero-trust architecture makes the same fundamental distinction: network location can be used as a policy signal, but it should not create implicit trust by itself.

Related Guides:

Prerequisites for Configuring a Wazuh IP Whitelist

Before configuring a Wazuh IP Whitelist, identify exactly which Wazuh services need to be protected and which systems legitimately need access to them.

This planning stage is important because applying an overly restrictive firewall rule can disconnect Wazuh agents, block the Dashboard, or prevent the Wazuh server from communicating with the Indexer.

The Wazuh architecture contains several independent communication paths, so the allowlist should be designed around those paths rather than around Wazuh as a single network service.

Wazuh’s official documentation identifies separate ports for agent communication, enrollment, cluster communication, the API, Indexer, and Dashboard.

Wazuh Manager Administrative Access

You should have administrative access to the Wazuh server before modifying its network-access controls.

On a typical Linux deployment, you may need access to:

/var/ossec/
/var/ossec/etc/
/var/ossec/api/configuration/

You will also need access to the operating system’s firewall configuration.

For example, depending on the distribution, you may work with:

ufw
firewall-cmd
iptables
nft

Determine which firewall framework is actually managing the server before making changes.

Running commands against one firewall system while another system is controlling the active rules can produce confusing results.

You should also determine whether the Wazuh server is:

A standalone server
Part of a Wazuh cluster
Behind a reverse proxy
Behind a load balancer
Hosted in a cloud environment
Protected by an external network firewall

These architectural details affect where the IP restriction should be implemented.

Root or sudo Privileges

Firewall configuration normally requires elevated operating-system privileges.

For example:

sudo ufw status

or:

sudo firewall-cmd --list-all

You may also need elevated privileges to inspect Wazuh configuration and service status.

For example:

sudo systemctl status wazuh-manager

and:

sudo ss -lntp

The second command is particularly useful because it allows you to identify listening TCP services and verify which addresses and ports are actually exposed.

Do not assume that every Wazuh installation uses the default ports. Verify the configuration of the specific deployment before creating firewall rules.

Identifying Trusted IP Addresses

Create an inventory of systems and networks that legitimately require access.

For example:

System	Example IP/network	Required access
SOC workstation	`10.10.10.25`	Dashboard/API
SOC subnet	`10.10.10.0/24`	Dashboard
Windows endpoints	`10.20.0.0/16`	Agent communication
Linux servers	`10.30.10.0/24`	Agent communication
Automation server	`10.40.10.15`	API
Wazuh server	`10.50.10.10`	Indexer
Indexer node	`10.50.10.20`	Indexer/cluster

Do not simply whitelist the entire corporate network unless there is a legitimate requirement to do so.

A smaller allowlist reduces the number of systems capable of reaching sensitive Wazuh services.

Identifying Wazuh Services That Require Protection

Determine which services should actually be restricted.

Common targets include:

1514/TCP    Wazuh agent communication
1515/TCP    Agent enrollment
1516/TCP    Wazuh cluster communication
55000/TCP   Wazuh API
9200/TCP    Wazuh Indexer
443/TCP     Wazuh Dashboard

Wazuh documents these ports as part of its standard architecture, although individual deployments can use different configurations.

You may not need to whitelist every service.

For example, if your only objective is to prevent unauthorized users from accessing the Dashboard, you might restrict port 443 while leaving agent communication unchanged.

Likewise, if the objective is to protect the API, the relevant rule may be limited to TCP 55000.

Backing Up Configuration Files

Before modifying firewall or Wazuh configuration, create a backup.

For example:

sudo cp /var/ossec/api/configuration/api.yaml \
/var/ossec/api/configuration/api.yaml.backup

You should also record the current firewall configuration.

UFW:

sudo ufw status numbered

Firewalld:

sudo firewall-cmd --list-all

Iptables:

sudo iptables -L -n -v --line-numbers

Save the output somewhere accessible in case you need to reconstruct the previous configuration.

If the Wazuh server is part of a production environment, use your normal configuration-management or change-management process rather than making undocumented firewall modifications directly on the server.

Planning Firewall Changes

Plan the rules before implementing them.

A useful approach is to create a matrix:

Source	Destination	Port	Action
Agent network	Wazuh Manager	1514	Allow
Enrollment network	Wazuh Manager	1515	Allow
SOC network	Wazuh API	55000	Allow
SOC/VPN network	Dashboard	443	Allow
Wazuh Manager	Indexer	9200	Allow
Internet	Wazuh API	55000	Deny
Internet	Indexer	9200	Deny

This makes it easier to identify missing communication paths before applying a default-deny policy.

Remember that firewall rules are directional.

A rule permitting traffic from an agent subnet to the Wazuh manager does not necessarily mean that every other required Wazuh communication path is permitted.

Testing Access Before Enforcing Restrictions

Before implementing a restrictive policy, test connectivity from every network that should remain authorized.

For example, from an approved client:

nc -vz wazuh.example.com 55000

Dashboard:

nc -vz wazuh.example.com 443

Agent communication:

nc -vz wazuh.example.com 1514

You can also inspect listening services on the Wazuh server:

sudo ss -lntp

Record the results before changing the firewall.

This gives you a baseline for comparison after the allowlist is implemented.

A particularly important precaution is to maintain an existing administrative session while testing firewall changes.

If a new rule unexpectedly blocks access, you may still have an active session from which to correct the configuration.

Identify the IP Addresses to Whitelist

The next step is to identify the actual source addresses that should be permitted to communicate with each Wazuh service.

Do not assume that the IP address visible on an administrator’s workstation is necessarily the address Wazuh will see.

NAT, VPNs, reverse proxies, load balancers, and other network devices can change the apparent source address.

Find the Wazuh Manager IP Address

On the Wazuh server, use:

ip addr

or:

hostname -I

For a more complete view:

ip -br addr

You may see multiple interfaces:

eth0    10.10.10.10/24
eth1    192.168.50.10/24

In this example, the Wazuh server has two network interfaces.

You need to determine which interface receives traffic from:

Wazuh agents
Administrators
The Dashboard
The Indexer
Other Wazuh cluster nodes

This distinction becomes especially important on servers connected to multiple VLANs or security zones.

Identify Wazuh Agent Networks

Determine the networks from which your Wazuh agents connect.

For example:

Production servers:
10.20.0.0/16

Corporate endpoints:
10.30.0.0/16

DMZ:
172.16.10.0/24

If all these networks legitimately contain Wazuh agents, they may need access to the Wazuh manager’s agent communication port.

Instead of creating hundreds of individual rules:

20.1.10
20.1.11
20.1.12
...

you could potentially use an appropriate CIDR range:

10.20.0.0/16

provided that every host within that range is actually intended to have access.

Related Guides:

Identify Administrator Workstation IP Addresses

Identify the networks from which administrators access the Wazuh API and Dashboard.

For example:

SOC subnet:
10.100.10.0/24

Management subnet:
10.100.20.0/24

If only a small number of administrators require API access, individual addresses may be more appropriate:

10.100.10.25
10.100.10.26

This is preferable to allowing a large network if the API is used only from dedicated administrative systems.

Identify Wazuh Dashboard Users

Determine how Dashboard users connect to Wazuh.

For example, users might connect:

Laptop
   |
   v
Corporate VPN
   |
   v
Wazuh Dashboard

In this architecture, the Dashboard may see the VPN address rather than the laptop’s local address.

If the VPN assigns addresses from:

10.200.0.0/24

then that may be the network that needs to be allowed.

This is one reason you should identify the actual source IP observed by the protected service rather than simply looking at the client’s local network configuration.

Related Guide: How to Configure Wazuh SSO

Identify Monitoring and Management Networks

Some deployments have dedicated management networks used by:

Monitoring systems
Backup servers
Configuration-management platforms
Automation systems
Bastion hosts
Vulnerability scanners
Security orchestration platforms

If these systems communicate with Wazuh, determine their source IP addresses.

For example:

Monitoring:
10.40.10.0/24

Automation:
10.40.20.0/24

Bastion:
10.40.30.10

You can then create narrowly scoped rules for each required service.

Determine Whether to Whitelist Individual Addresses or CIDR Ranges

Individual IP addresses provide greater precision.

For example:

10.40.30.10

allows one host.

CIDR ranges are easier to maintain when systems are organized into stable networks:

10.40.30.0/24

allows the entire subnet.

As a general principle:

Use the smallest address range that satisfies the operational requirement.

For example, if only two automation servers need API access, use:

10.40.20.10
10.40.20.11

rather than:

10.40.0.0/16

unless the larger network is genuinely required.

Account for Dynamic IP Addresses

Dynamic addressing can make IP allowlists difficult to maintain.

For example, an administrator’s workstation might receive:

10.10.10.25

today and:

10.10.10.42

tomorrow.

An IP-specific firewall rule could therefore stop working unexpectedly.

Better approaches may include:

Using a stable VPN address pool.
Using a dedicated administrative subnet.
Assigning static DHCP leases.
Restricting access through a bastion host.
Using identity-aware access controls in addition to network restrictions.

Avoid continually expanding an IP allowlist simply because individual workstation addresses change.

Account for NAT and Reverse Proxies

NAT can make multiple clients appear to originate from the same address.

For example:

Administrator A ─┐
Administrator B ─┼──> NAT Gateway ──> Wazuh
Administrator C ─┘

The Wazuh server may see:

Source: 203.0.113.10

instead of the administrators’ private addresses.

Similarly, a reverse proxy can sit between the user and Wazuh:

User
  |
  v
Reverse Proxy
  |
  v
Wazuh Dashboard

The Dashboard may therefore see the proxy’s network connection rather than the original client’s TCP source address.

Before creating the whitelist, determine where the network boundary actually exists.

For troubleshooting, packet captures can help identify the source address reaching the server:

sudo tcpdump -ni any port 55000

or:

sudo tcpdump -ni any port 443

This can be particularly useful when NAT or proxy infrastructure makes the expected source address unclear.

Configure a Wazuh IP Whitelist with a Firewall

Why Firewall-Based Allowlisting Is Usually the Preferred Approach

For most Wazuh deployments, the firewall is the most appropriate place to implement IP-based access restrictions.

The primary reason is architectural separation.

Wazuh handles security monitoring, event collection, analysis, alerting, authentication, authorization, and other application functions.

The firewall is specifically designed to control network connectivity.

A firewall can therefore enforce:

Who can connect?
        ↓
Source IP
        ↓
Destination IP
        ↓
Destination port
        ↓
Allow / deny

before the connection reaches the Wazuh application.

This also allows different Wazuh services to have different policies.

For example:

Dashboard :443
    ↓
SOC network only

API :55000
    ↓
Administrators + automation

Agent :1514
    ↓
Agent networks

Indexer :9200
    ↓
Wazuh server only

This is generally more flexible than trying to create one broad application-level rule.

Configure an IP Whitelist with UFW

Ubuntu systems commonly use UFW as a simplified firewall-management interface.

First, inspect the existing configuration:

sudo ufw status numbered

Suppose the trusted agent network is:

10.20.0.0/16

You could allow that network to reach the Wazuh agent port:

sudo ufw allow from 10.20.0.0/16 to any port 1514 proto tcp

For a specific API administration network:

sudo ufw allow from 10.100.10.0/24 to any port 55000 proto tcp

Dashboard access:

sudo ufw allow from 10.100.10.0/24 to any port 443 proto tcp

For the Indexer, you could restrict access to the Wazuh server’s IP:

sudo ufw allow from 10.50.10.10 to any port 9200 proto tcp

Before enabling or changing a default-deny policy, ensure that your current SSH administration path is explicitly permitted.

For example:

sudo ufw allow ssh

Then inspect the resulting rules:

sudo ufw status numbered

UFW rule ordering and existing rules should be reviewed carefully before adding a broad deny rule.

Configure an IP Whitelist with firewalld

RHEL, Rocky Linux, AlmaLinux, Fedora, and other distributions may use firewalld.

Check its current state:

sudo firewall-cmd --state

List the current configuration:

sudo firewall-cmd --list-all

To permit a trusted subnet to access the Wazuh agent port:

sudo firewall-cmd --permanent \
  --add-rich-rule='rule family="ipv4" source address="10.20.0.0/16" port protocol="tcp" port="1514" accept'

For the Wazuh API:

sudo firewall-cmd --permanent \
  --add-rich-rule='rule family="ipv4" source address="10.100.10.0/24" port protocol="tcp" port="55000" accept'

For the Dashboard:

sudo firewall-cmd --permanent \
  --add-rich-rule='rule family="ipv4" source address="10.100.10.0/24" port protocol="tcp" port="443" accept'

Apply the persistent configuration:

sudo firewall-cmd --reload

Then verify:

sudo firewall-cmd --list-all

If your environment uses IPv6, create corresponding IPv6 rules rather than assuming the IPv4 rules will protect both protocols.

Configure an IP Whitelist with iptables

Legacy or manually managed Linux systems may use iptables directly.

View the current rules:

sudo iptables -L INPUT -n -v --line-numbers

To allow a trusted agent subnet to reach TCP 1514:

sudo iptables -A INPUT \
  -p tcp \
  -s 10.20.0.0/16 \
  --dport 1514 \
  -j ACCEPT

Wazuh API:

sudo iptables -A INPUT \
  -p tcp \
  -s 10.100.10.0/24 \
  --dport 55000 \
  -j ACCEPT

Dashboard access:

sudo iptables -A INPUT \
  -p tcp \
  -s 10.100.10.0/24 \
  --dport 443 \
  -j ACCEPT

Indexer access:

sudo iptables -A INPUT \
  -p tcp \
  -s 10.50.10.10 \
  --dport 9200 \
  -j ACCEPT

Then inspect the resulting configuration:

sudo iptables -L INPUT -n -v --line-numbers

Modern Linux distributions increasingly use nftables underneath higher-level firewall tools, so determine which firewall framework your operating system actually manages before implementing persistent iptables rules.

Allow Trusted Wazuh Agent Networks

Agent communication should be restricted to networks that legitimately contain Wazuh agents.

For example:

Production agents:
10.20.0.0/16

DMZ agents:
172.16.10.0/24

The resulting policy could conceptually be:

10.20.0.0/16  -> Wazuh Manager:1514/TCP  ALLOW
172.16.10.0/24 -> Wazuh Manager:1514/TCP ALLOW
ANY            -> Wazuh Manager:1514/TCP  DENY

If agent enrollment is also required, TCP 1515 may need a separate rule.

Be particularly careful when restricting enrollment.

A firewall rule that permits existing agent communication but blocks TCP 1515 can leave existing agents functioning while preventing new agents from enrolling.

Allow Administrative Access to the Wazuh API

The API should normally be accessible only to systems that actually need it.

For example:

SOC network:
10.100.10.0/24

Automation server:
10.100.20.15

A policy could be:

10.100.10.0/24 -> Wazuh:55000/TCP ALLOW
10.100.20.15   -> Wazuh:55000/TCP ALLOW
ANY            -> Wazuh:55000/TCP DENY

This is particularly useful when automated tools use the Wazuh API for tasks such as configuration management, security automation, or operational workflows.

However, an IP allowlist does not replace API authentication.

An approved IP should still need valid Wazuh credentials or an appropriate authentication token.

Restrict Wazuh Dashboard Access

Dashboard access can similarly be restricted to SOC, corporate, or VPN networks.

For example:

Corporate SOC:
10.100.10.0/24

VPN:
10.200.0.0/24

The policy becomes:

10.100.10.0/24 -> Wazuh Dashboard:443/TCP ALLOW
10.200.0.0/24  -> Wazuh Dashboard:443/TCP ALLOW
ANY            -> Wazuh Dashboard:443/TCP DENY

This is particularly valuable when the Dashboard would otherwise be exposed through a public interface.

If the Dashboard is behind Nginx or another reverse proxy, make sure the restriction is applied at the correct network boundary.

Restrict Wazuh Indexer Access

The Indexer should generally have a highly restricted network policy because it contains Wazuh security data.

A common architecture is:

Wazuh Server
     |
     | 9200/TCP
     v
Wazuh Indexer

The firewall can therefore restrict port 9200 to the Wazuh server network or specific Wazuh server addresses.

For example:

10.50.10.10 -> Indexer:9200/TCP ALLOW
ANY         -> Indexer:9200/TCP DENY

For multi-node Indexer deployments, you must also account for the communication required between Indexer nodes.

Do not apply a simple single-server rule to a clustered environment without first identifying the cluster communication requirements.

Related Guides:

Set Default-Deny Rules Carefully

A default-deny policy can provide strong network isolation:

ALLOW trusted traffic
DENY everything else

However, implementing it incorrectly can lock you out of the Wazuh server or interrupt critical Wazuh communications.

Before adding a deny rule, identify at minimum:

SSH administration
Wazuh agent communication
Agent enrollment
Wazuh cluster communication
API access
Dashboard access
Indexer communication
Monitoring access
Backup access
Any required management or automation systems

For example, an administrator might accidentally create:

sudo iptables -A INPUT -p tcp --dport 55000 -j DROP

before adding the required allow rule for the administrator’s network.

The API would then become inaccessible.

The safer conceptual ordering is:

Allow trusted source
Allow required service
Verify connectivity
Add restrictive rule
Verify again

Do not assume that a default-deny policy is automatically safe merely because it is more restrictive.

Verify Firewall Rule Ordering

Firewall rule ordering can determine whether an allowlist works as intended.

Consider:

1. DROP ANY -> 55000
2. ALLOW 10.100.10.0/24 -> 55000

If the firewall evaluates rules sequentially, the first rule may block the traffic before the allow rule is reached.

The intended structure is generally:

1. ALLOW 10.100.10.0/24 -> 55000
2. DROP ANY -> 55000

After applying rules, inspect them with the relevant firewall tool.

Iptables:

sudo iptables -L INPUT -n -v --line-numbers

UFW:

sudo ufw status numbered

Firewalld:

sudo firewall-cmd --list-all

Then test from both sides of the allowlist:

Trusted IP
   |
   +----> Should connect

Untrusted IP
   |
   +----> Should be blocked

Finally, test the actual Wazuh functionality rather than merely testing whether the TCP port is open.

An agent should remain connected, the Dashboard should load for authorized users, and the API should accept authenticated requests from approved sources.

Related Guides:

Configure a Wazuh IP Whitelist for Wazuh Agent Communication

Wazuh agent communication is one of the most important network paths to protect because every enrolled endpoint must be able to communicate with the Wazuh server.

At the same time, exposing the agent communication service to unnecessary networks increases the number of systems that can attempt to connect to the manager.

The goal is therefore not simply to “block unknown IPs.”

Instead, configure the network boundary so that only networks containing legitimate Wazuh agents can reach the required Wazuh server ports.

Wazuh documents TCP 1514 as the default port for agent communication and TCP 1515 as the default port for agent enrollment.

Wazuh also supports UDP 1514 for agent communication when explicitly configured.

Understand Wazuh Agent Communication Ports

The first step is to determine which communication mechanisms your deployment actually uses.

The common ports are:

Port	Protocol	Purpose
`1514`	TCP	Wazuh agent communication
`1514`	UDP	Optional agent communication
`1515`	TCP	Agent enrollment
`1516`	TCP	Wazuh cluster communication

The standard agent communication path looks like:

Wazuh Agent
     |
     | TCP 1514
     v
Wazuh Manager

During automatic enrollment, the path may additionally be:

Wazuh Agent
     |
     | TCP 1515
     v
Wazuh Manager

These ports serve different purposes.

A firewall rule that permits 1514 but blocks 1515, for example, can allow existing agents to communicate while preventing new agents from enrolling.

Identify the Required Manager Ports

Before creating firewall rules, determine which ports your Wazuh manager actually uses.

You can inspect listening sockets with:

sudo ss -lntup

For example:

tcp   LISTEN   0   128   0.0.0.0:1514
tcp   LISTEN   0   128   0.0.0.0:1515
tcp   LISTEN   0   128   0.0.0.0:55000

The Wazuh API on 55000 is separate from agent communication and should therefore have its own access-control policy.

For agent traffic, focus primarily on 1514 and, if enrollment is being used, 1515.

You should also determine whether your environment uses:

TCP agent communication
UDP agent communication
Automatic enrollment
A Wazuh cluster
A load balancer
NAT
A reverse proxy

Do not create rules for services that your architecture does not require.

Allow Trusted Agent Networks

Suppose your production endpoints occupy:

10.20.0.0/16

and your DMZ servers occupy:

172.16.10.0/24

The firewall could permit both networks to communicate with the Wazuh manager on TCP 1514.

With UFW:

sudo ufw allow from 10.20.0.0/16 to any port 1514 proto tcp
sudo ufw allow from 172.16.10.0/24 to any port 1514 proto tcp

If automatic enrollment is required:

sudo ufw allow from 10.20.0.0/16 to any port 1515 proto tcp
sudo ufw allow from 172.16.10.0/24 to any port 1515 proto tcp

The resulting policy is conceptually:

20.0.0/16     -> Wazuh:1514 TCP   ALLOW
16.10.0/24   -> Wazuh:1514 TCP   ALLOW

20.0.0/16     -> Wazuh:1515 TCP   ALLOW
16.10.0/24   -> Wazuh:1515 TCP   ALLOW

Use the actual networks from your environment rather than these example ranges.

Related Guides:

Restrict Unauthorized Source Addresses

Once trusted networks are explicitly allowed, restrict other sources.

For example, with iptables:

sudo iptables -A INPUT \
  -p tcp \
  --dport 1514 \
  -j DROP

This should only be implemented after the required allow rules are already in place.

The intended policy is:

Trusted agent networks
        |
        +---- TCP 1514 ----> ALLOW
        |
        +---- TCP 1515 ----> ALLOW, if required

All other networks
        |
        +---- TCP 1514 ----> DENY
        |
        +---- TCP 1515 ----> DENY, if restricted

The restriction should be based on source address, not merely on the destination port.

For example, allowing TCP 1514 from every source would defeat the purpose of an IP allowlist:

ANY -> Wazuh:1514 -> ALLOW

Instead, the policy should be:

10.20.0.0/16 -> Wazuh:1514 -> ALLOW
ANY           -> Wazuh:1514 -> DENY

Be careful with NAT. If agents connect through a NAT gateway, the Wazuh manager may see the NAT address instead of each endpoint’s private address.

Configure TCP and UDP Rules Where Applicable

Wazuh supports agent communication over UDP 1514 when configured, but TCP is the standard choice in many deployments.

If your deployment explicitly uses UDP, create a corresponding UDP rule.

For UFW:

sudo ufw allow from 10.20.0.0/16 to any port 1514 proto udp

For iptables:

sudo iptables -A INPUT \
  -p udp \
  -s 10.20.0.0/16 \
  --dport 1514 \
  -j ACCEPT

Do not allow UDP merely because TCP 1514 is already permitted.

TCP and UDP are separate protocols and require separate firewall rules.

If your Wazuh agents use TCP only, leaving UDP 1514 closed reduces unnecessary network exposure.

Test Agent Connectivity After Applying Restrictions

After implementing the firewall policy, test from an authorized endpoint.

From a Linux system, you can test TCP connectivity with:

nc -vz WAZUH_MANAGER_IP 1514

For enrollment:

nc -vz WAZUH_MANAGER_IP 1515

A successful test should indicate that the TCP connection can be established.

However, an open TCP port does not necessarily mean that the Wazuh agent is functioning correctly. You should also inspect the agent service.

On Linux:

sudo systemctl status wazuh-agent

On Windows, verify that the Wazuh Agent service is running.

You can also examine the agent log for connection problems.

Linux agents commonly store logs under:

/var/ossec/logs/

For example:

sudo tail -f /var/ossec/logs/ossec.log

Look for successful connection activity as well as errors involving:

Connection refused
Connection timeout
Network unreachable
Authentication
Enrollment
Manager address
TLS or certificate problems

Verify Agent Status in the Wazuh Dashboard

Once network connectivity has been restored, verify that the agent appears correctly in the Wazuh Dashboard.

Check:

Agent name
Agent ID
IP address
Operating system
Last keepalive
Connection status
Last-seen timestamp

If an agent becomes disconnected immediately after the firewall change, compare the firewall rules against the agent’s actual source address.

A common mistake is allowing the endpoint’s expected private IP when the Wazuh manager actually sees a NAT gateway address.

You can also inspect the manager’s logs to determine whether traffic from the agent is reaching the Wazuh server.

Related Guides:

Configure IP Restrictions for the Wazuh API

The Wazuh API provides programmatic access to Wazuh management and operational functionality.

Because API access can expose sensitive information and administrative capabilities, it should not normally be reachable from arbitrary networks.

Wazuh’s API documentation provides specific configuration and security mechanisms, including authentication and controls for limiting login attempts.

Why the Wazuh API Should Be Restricted

The API is different from agent communication.

Agents need to communicate with the manager to send security data, while administrative applications and users may use the API to perform management operations.

A typical architecture might look like:

SOC Workstation
      |
      | 55000/TCP
      v
Wazuh API
      |
      v
Wazuh Manager

There is usually little reason for arbitrary Internet hosts to have direct access to port 55000.

Restricting the API to known management networks reduces the number of systems that can even attempt to authenticate against it.

This can also reduce exposure to:

Credential attacks
Automated scanning
API enumeration
Authentication abuse
Accidental exposure
Untrusted automation

However, IP filtering should remain a defense-in-depth control, not the sole API security mechanism.

Identify the API Listening Address and Port

Wazuh’s API configuration is stored at:

/var/ossec/api/configuration/api.yaml

The API configuration includes the listening host and port parameters. The default API port is 55000.

You can inspect the configuration with:

sudo grep -E 'host:|port:' /var/ossec/api/configuration/api.yaml

You can also determine which addresses are actually listening:

sudo ss -lntp | grep 55000

For example:

LISTEN 0 128 0.0.0.0:55000
LISTEN 0 128    [::]:55000

This indicates that the API is listening on IPv4 and IPv6 addresses.

If the API is listening on all interfaces, network-level firewall restrictions become particularly important.

Allow Only Trusted Management Networks

Suppose your administrators use:

10.100.10.0/24

and an automation server uses:

10.100.20.15

You could permit those sources to reach port 55000.

With UFW:

sudo ufw allow from 10.100.10.0/24 to any port 55000 proto tcp
sudo ufw allow from 10.100.20.15 to any port 55000 proto tcp

The resulting access policy is:

SOC network       -> 55000/TCP -> ALLOW
Automation server -> 55000/TCP -> ALLOW
Other networks    -> 55000/TCP -> DENY

If only one administrative host needs direct API access, an individual host rule is preferable to allowing an entire subnet.

Combine IP Restrictions With Authentication

An IP whitelist should not be treated as authentication.

For example, this:

Source IP = 10.100.10.25

does not prove that the person operating that workstation is authorized to administer Wazuh.

The stronger model is:

Trusted IP
    ↓
Firewall
    ↓
API authentication
    ↓
Authorization / RBAC
    ↓
Requested operation

Wazuh’s API supports authentication tokens for API requests.

This means that an attacker would need to overcome multiple controls rather than simply obtaining access to an approved network.

Related Guides:

Protect API Access Behind a Firewall or Reverse Proxy

A firewall is usually the simplest way to restrict direct API access.

However, some environments place the API behind a reverse proxy:

Client
  |
  v
Reverse Proxy
  |
  v
Wazuh API

This can provide an additional access-control layer.

A reverse proxy may be useful when you need features such as:

TLS termination
IP filtering
Rate limiting
Centralized access logging
Authentication integration
Request filtering

However, placing an API behind a reverse proxy introduces another networking consideration: the Wazuh API may see the reverse proxy as its direct client.

Therefore, determine whether the IP restriction should be applied:

Client IP

or:

Reverse proxy IP

and configure the network controls accordingly.

Test API Connectivity From an Allowed IP

From an approved management workstation, test the TCP connection:

nc -vz WAZUH_MANAGER_IP 55000

You can also send an HTTPS request to verify that the API responds:

curl -k https://WAZUH_MANAGER_IP:55000/

A response indicates that the service is reachable, although authentication may still be required.

For an authenticated API request, use the appropriate Wazuh API authentication mechanism rather than embedding credentials directly into shell history.

The important distinction is:

TCP connection succeeds
        ≠
API authentication succeeds
        ≠
User is authorized for every API operation

Each represents a different security layer.

Verify That Unauthorized IP Addresses Are Blocked

Perform the same connectivity test from a system that is not in the allowlist:

nc -vz WAZUH_MANAGER_IP 55000

The connection should fail or time out according to your firewall’s behavior.

If an unauthorized host can still connect, investigate:

Firewall rule ordering
NAT
Reverse proxies
Load balancers
IPv6
Cloud security groups
Another firewall allowing the connection
An overly broad CIDR rule

Also inspect the firewall counters where available.

For iptables:

sudo iptables -L INPUT -n -v --line-numbers

This can help confirm whether traffic is actually reaching the expected rule.

Configure a Wazuh Dashboard IP Whitelist

The Wazuh Dashboard is usually the most visible Wazuh service because it provides the browser-based interface used by security analysts and administrators.

If the Dashboard is intended for internal users, restricting its network exposure to trusted corporate networks, VPN ranges, or administrative networks can substantially reduce unnecessary exposure.

The standard Wazuh architecture uses HTTPS on TCP 443 for Dashboard access.

Identify the Wazuh Dashboard Listening Port

First determine which port the Dashboard is actually using.

On the Dashboard server:

sudo ss -lntp

You can search specifically for HTTPS:

sudo ss -lntp | grep ':443'

If the Dashboard uses a different port, use that port when creating the firewall rule.

The standard architecture is:

Browser
   |
   | HTTPS 443
   v
Wazuh Dashboard

If Nginx, Apache, HAProxy, or another reverse proxy is in front of the Dashboard, the externally exposed port may differ from the internal Dashboard port.

Restrict Dashboard Access to Trusted Networks

Suppose the SOC uses:

10.100.10.0/24

and remote analysts connect through:

10.200.0.0/24

You can allow both networks to access TCP 443.

With UFW:

sudo ufw allow from 10.100.10.0/24 to any port 443 proto tcp
sudo ufw allow from 10.200.0.0/24 to any port 443 proto tcp

The policy becomes:

SOC network -> Dashboard:443 -> ALLOW
VPN network -> Dashboard:443 -> ALLOW
Other       -> Dashboard:443 -> DENY

This prevents systems outside the approved networks from establishing a direct HTTPS connection to the Dashboard.

Configure Firewall Rules for the Dashboard

For firewalld, you can create a source-restricted rule:

sudo firewall-cmd --permanent \
  --add-rich-rule='rule family="ipv4" source address="10.100.10.0/24" port protocol="tcp" port="443" accept'

For a VPN network:

sudo firewall-cmd --permanent \
  --add-rich-rule='rule family="ipv4" source address="10.200.0.0/24" port protocol="tcp" port="443" accept'

Then reload:

sudo firewall-cmd --reload

With iptables:

sudo iptables -A INPUT \
  -p tcp \
  -s 10.100.10.0/24 \
  --dport 443 \
  -j ACCEPT

Then inspect the rule ordering:

sudo iptables -L INPUT -n -v --line-numbers

If using UFW, verify the resulting policy with:

sudo ufw status numbered

The exact firewall implementation is less important than ensuring the resulting policy expresses the intended access model.

Use a Reverse Proxy for Additional Access Control

A reverse proxy can provide another control layer between users and the Wazuh Dashboard.

For example:

Internet / VPN
      |
      v
+----------------+
| Reverse Proxy  |
| IP filtering   |
| TLS            |
| Rate limiting  |
+----------------+
      |
      v
Wazuh Dashboard

This architecture can be useful when the Dashboard needs to be exposed through a controlled ingress point rather than directly exposing the Dashboard server.

A reverse proxy can also provide centralized logging and additional request controls.

However, be careful when determining the source IP.

For example:

User: 10.200.0.25
        |
        v
Proxy: 10.200.0.10
        |
        v
Dashboard

The Dashboard server may see 10.200.0.10 as the immediate network peer.

Consequently, placing the IP allowlist only on the Dashboard host could accidentally allow every client that can reach the reverse proxy.

The strongest architecture typically places network restrictions at the appropriate ingress boundary while separately securing the backend Dashboard server.

Combine IP Restrictions With Authentication and RBAC

An IP whitelist does not determine what a user can do after accessing the Dashboard.

For example:

User from approved IP
        ↓
Dashboard authentication
        ↓
User identity
        ↓
RBAC permissions
        ↓
Allowed Wazuh functionality

This is particularly important in environments with multiple security teams.

An analyst might need access to alerts but not administrative configuration.

An administrator might need access to configuration and management functions.

An IP address cannot make that distinction.

Related Guides:

If your organization uses centralized identity, combining network restrictions with SSO, SAML, or OIDC can provide a stronger security architecture.

Related Guides:

Verify Access From Allowed and Blocked Networks

Finally, test the Dashboard from both sides of the access-control boundary.

From an approved network:

curl -kI https://WAZUH_DASHBOARD/

You should receive an HTTP response.

Then perform the same test from an unauthorized network:

curl -kI https://WAZUH_DASHBOARD/

The unauthorized connection should be blocked by the network control.

Also test the actual browser experience from an approved workstation:

Open the Wazuh Dashboard.
Confirm the login page loads.
Authenticate successfully.
Confirm alerts and Dashboard data are accessible.
Navigate through the areas required by the user’s role.

Then test from an unauthorized network.

The expected result should be that the connection is stopped before the user reaches the Wazuh login page.

If the unauthorized user can still see the login page, investigate whether:

The firewall rule is being applied to the wrong host.
A reverse proxy is handling the connection.
A load balancer is providing an alternate route.
IPv6 bypasses the IPv4 restriction.
The source IP is being changed by NAT.
A broader firewall rule appears before the deny rule.
Another public interface exposes the Dashboard.

A successful Wazuh IP Whitelist implementation should therefore be validated at both the network and application levels: authorized networks should retain the required Wazuh functionality, while unauthorized networks should be unable to establish the protected connection in the first place.

Configure a Wazuh Indexer IP Whitelist

The Wazuh Indexer stores and provides access to the security data generated by your Wazuh deployment.

Because the Indexer can contain alerts, events, vulnerability information, inventory data, and other security telemetry, it should generally have a much narrower network exposure than the Wazuh Dashboard.

A typical Wazuh architecture places the Indexer behind the Wazuh server and Dashboard rather than exposing it directly to users on the Internet.

Wazuh documents TCP 9200 as the default Indexer REST API port, while Indexer cluster communication uses ports in the 9300-9400 range.

Understand Wazuh Indexer Network Exposure

The Indexer should normally be treated as an internal infrastructure component.

A simplified deployment looks like this:

                    Users
                      |
                      | HTTPS
                      v
              Wazuh Dashboard
                      |
                      |
                      v
                 Wazuh Server
                      |
                      | 9200/TCP
                      v
                Wazuh Indexer

In this architecture, users generally do not need direct access to the Indexer’s REST API.

Instead, the Dashboard and Wazuh server communicate with the Indexer on behalf of users and Wazuh components.

This creates an opportunity to implement a highly restrictive network policy:

Wazuh Server -> Indexer:9200  ALLOW
Dashboard    -> Indexer:9200  ALLOW, if required
Other hosts  -> Indexer:9200  DENY
Internet     -> Indexer:9200  DENY

The exact communication requirements depend on your Wazuh version and architecture, so verify the current deployment before implementing restrictions.

Restrict Indexer Ports to Trusted Wazuh Components

The first step is identifying which systems legitimately require Indexer access.

In a simple deployment, the Wazuh server may be the primary system communicating with the Indexer.

For example:

Wazuh Server:
10.50.10.10

Wazuh Indexer:
10.50.10.20

You could restrict TCP 9200 so that only the Wazuh server can connect:

sudo ufw allow from 10.50.10.10 to any port 9200 proto tcp

Then prevent other sources from reaching the service.

Conceptually:

10.50.10.10 -> 10.50.10.20:9200 -> ALLOW
ANY          -> 10.50.10.20:9200 -> DENY

If multiple Wazuh servers or other trusted components require access, create explicit rules for those systems rather than allowing an entire corporate network.

Allow Wazuh Manager and Dashboard Communication

Your specific architecture determines which components need access to the Indexer.

A multi-node environment could look like:

Wazuh Server 1 ──┐
                 |
Wazuh Server 2 ──┼──> Wazuh Indexer
                 |
Dashboard ───────┘

The relevant source addresses should be explicitly permitted.

For example:

50.10.10 -> Indexer:9200 -> ALLOW
50.10.11 -> Indexer:9200 -> ALLOW
50.10.30 -> Indexer:9200 -> ALLOW

where:

50.10.10 = Wazuh Server 1
50.10.11 = Wazuh Server 2
50.10.30 = Dashboard

Do not assume that the Dashboard requires the same access as the Wazuh server in every deployment. Verify the actual network flow before implementing the rules.

Related Guides:

Prevent Direct Public Access to the Indexer

The Wazuh Indexer should generally not be directly accessible from the public Internet.

A dangerous configuration would look like:

Internet
    |
    | TCP 9200
    v
Wazuh Indexer

A better architecture is:

Internet
    |
    X
Firewall
    |
    +----> Wazuh Dashboard
    |
    +----> Wazuh API

Wazuh Server
    |
    | Internal network
    v
Wazuh Indexer

If your Indexer is currently accessible from an external network, determine why that access exists before removing it.

Some organizations may have legitimate administrative or monitoring requirements.

Where possible, expose administrative access through:

A VPN
A bastion host
A dedicated management network
A restricted reverse proxy
A private cloud network

rather than exposing TCP 9200 publicly.

Use Firewall Rules to Enforce Network Boundaries

For example, with firewalld:

sudo firewall-cmd --permanent \
  --add-rich-rule='rule family="ipv4" source address="10.50.10.10" port protocol="tcp" port="9200" accept'

Add additional trusted Wazuh components as necessary.

Then reload:

sudo firewall-cmd --reload

With iptables:

sudo iptables -A INPUT \
  -p tcp \
  -s 10.50.10.10 \
  --dport 9200 \
  -j ACCEPT

If a default-deny policy is being used, make sure the allow rules are evaluated before the corresponding deny rule.

You should also account for Indexer cluster communication in a multi-node deployment.

Do not restrict 9300-9400 without first identifying the nodes that need to communicate.

Verify Indexer Connectivity

From an authorized Wazuh server, test TCP connectivity:

nc -vz INDEXER_IP 9200

You can also test the HTTPS endpoint:

curl -k https://INDEXER_IP:9200/

The Indexer may return an authentication-related response rather than unrestricted data.

That is expected if network connectivity is working but application authentication is required.

Then test from an unauthorized host:

nc -vz INDEXER_IP 9200

The unauthorized connection should fail.

Also inspect the Indexer service and Wazuh components after applying the rule.

A successful TCP test alone does not prove that the entire Wazuh data pipeline is functioning.

Check for:

Wazuh server errors
Filebeat errors
Indexer connectivity failures
Dashboard data-loading errors
Authentication failures
TLS errors

Related Guides:

Whitelist an IP Address vs. an IP Range

One of the most important design decisions when configuring a Wazuh IP Whitelist is deciding whether to permit individual hosts or an entire network.

The principle should be simple:

Allow the smallest network scope that satisfies the legitimate communication requirement.

If a single automation server needs access to the Wazuh API, whitelist that server.

If several hundred Wazuh agents occupy a dedicated subnet, whitelist the appropriate subnet rather than maintaining hundreds of individual addresses.

When to Whitelist a Single IP

A single IP address is appropriate when one specific host needs access.

For example:

10.100.20.15

might represent a dedicated automation server.

You could allow only that address to reach the Wazuh API:

10.100.20.15 -> Wazuh:55000/TCP -> ALLOW

Individual IP rules are particularly useful for:

Bastion hosts
Automation servers
Monitoring servers
Backup systems
Dedicated administrator workstations
Specific Wazuh cluster nodes
Specific Indexer nodes

The primary advantage is precision.

If another system on the same subnet is compromised, it does not automatically inherit access simply because it shares the network.

When to Whitelist a Subnet

A subnet is appropriate when many legitimate clients share a stable network segment.

For example:

10.20.30.0/24

contains addresses from:

10.20.30.1

through:

10.20.30.254

If this is the dedicated Wazuh agent network, allowing the subnet can be much easier to maintain than creating individual rules for every endpoint.

For example:

sudo ufw allow from 10.20.30.0/24 to any port 1514 proto tcp

This permits the entire agent subnet to communicate with the manager.

A subnet-based rule works particularly well when IP addresses are dynamically assigned but remain within a controlled VLAN or address pool.

CIDR Notation Examples

CIDR notation allows you to represent IP networks compactly.

Some common examples include:

10.10.10.25/32

1. represents one IPv4 address.

10.10.10.0/24

2. represents a 256-address IPv4 block.

10.10.0.0/16

3. represents a much larger network.

For IPv6:

2001:db8:1234::/64

represents an IPv6 subnet.

The /32 example is particularly useful when a firewall expects CIDR notation but you want to describe a single host.

For example:

10.100.20.15/32

means only 10.100.20.15.

Risks of Allowing Large Address Ranges

A larger CIDR range increases the number of systems that can potentially reach the protected Wazuh service.

Consider:

10.10.10.15/32

versus:

10.10.0.0/16

The first permits one address.

The second permits a substantially larger portion of the private network.

If you allow a large corporate subnet to access the Wazuh API, every compromised workstation in that subnet may gain network-level access to the API.

The API may still require authentication, but the firewall has no longer reduced the attack surface to the intended administrative hosts.

Avoiding Overly Broad Rules

Avoid rules such as:

0.0.0.0/0

for IPv4 or:

::/0

for IPv6 when the objective is to create an IP allowlist.

These effectively represent all addresses.

Similarly, broad private-network ranges such as:

10.0.0.0/8

should not be used merely because they are convenient.

If only the SOC network requires Dashboard access, use:

10.20.30.0/24

rather than the entire private 10.0.0.0/8 address space.

The same principle applies to API and Indexer access.

Designing Least-Privilege Network Access

The principle of least privilege should apply to network connectivity just as it applies to Wazuh user permissions.

Instead of:

Corporate Network
        |
        v
Every Wazuh service

design service-specific access:

Agent Network
   |
   +----> Manager:1514

Enrollment Network
   |
   +----> Manager:1515

SOC Network
   |
   +----> Dashboard:443
   |
   +----> API:55000

Wazuh Server
   |
   +----> Indexer:9200

This provides much better segmentation.

For example, an analyst’s workstation may need:

443/TCP -> Dashboard

but not:

9200/TCP -> Indexer

Similarly, an agent may need:

1514/TCP -> Wazuh Manager

but not:

55000/TCP -> Wazuh API

This service-specific approach minimizes unnecessary network reachability.

Related Guide:

Configure a Wazuh IP Whitelist with a Reverse Proxy

A reverse proxy can provide another layer of network access control when the Wazuh Dashboard or API needs to be exposed through a controlled ingress point.

Instead of allowing clients to connect directly to Wazuh:

Client
  |
  v
Wazuh

the architecture becomes:

Client
  |
  v
Reverse Proxy
  |
  v
Wazuh

The proxy can perform IP filtering before forwarding requests to the Wazuh service.

When to Use a Reverse Proxy

A reverse proxy can be useful when you need:

Centralized TLS termination
Client IP restrictions
Rate limiting
Request logging
Multiple backend services
A single public entry point
Additional authentication controls
Network segmentation

For example:

Internet
   |
   v
Nginx
   |
   +---- IP allowlist
   |
   +---- TLS
   |
   v
Wazuh Dashboard

This can be particularly useful for organizations that already operate Nginx or Apache as an application gateway.

However, a reverse proxy should not be considered a replacement for the host firewall.

A stronger architecture is:

Client
   |
   v
Network Firewall
   |
   v
Reverse Proxy
   |
   v
Host Firewall
   |
   v
Wazuh Service

Each layer can enforce an appropriate security policy.

Restricting Access by Client IP

The reverse proxy can permit only known source addresses.

For example:

10.100.10.0/24

could represent the SOC network.

The proxy then allows requests from that range and rejects requests from other sources.

Conceptually:

10.100.10.0/24
       |
       +----> Reverse Proxy ----> Wazuh Dashboard

Other IPs
       |
       +----> REJECT

This is useful when the reverse proxy is the actual Internet-facing access point.

However, the proxy must correctly identify the client IP.

If another proxy or load balancer is in front of it, the TCP source address may be that intermediary rather than the original client.

Nginx IP Allowlisting

Nginx provides the allow and deny directives for source-address filtering.

For example:

location / {
    allow 10.100.10.0/24;
    allow 10.200.0.0/24;
    deny all;

    proxy_pass https://wazuh_dashboard;
}

This permits clients from the two specified networks while denying other source addresses.

For a single trusted administrator:

location / {
    allow 10.100.20.15;
    deny all;

    proxy_pass https://wazuh_api;
}

After changing the Nginx configuration, test the syntax:

sudo nginx -t

If the test succeeds, reload Nginx:

sudo systemctl reload nginx

The exact proxy_pass, TLS, upstream, and location configuration depends on how your Wazuh service is deployed.

Apache IP Allowlisting

Apache HTTP Server can also restrict access based on client IP.

For modern Apache configurations, the Require ip directive can be used.

For example:

<Location "/">
    Require ip 10.100.10.0/24
</Location>

You can permit multiple trusted networks:

<Location "/">
    Require ip 10.100.10.0/24
    Require ip 10.200.0.0/24
</Location>

Apache can then proxy approved requests to the Wazuh backend.

After modifying the configuration, validate it before reloading Apache:

sudo apachectl configtest

Then reload:

sudo systemctl reload apache2

On RHEL-based systems, the service name may instead be httpd.

Handling Trusted Proxy Headers

One of the most important reverse-proxy considerations is determining the real client IP.

Suppose the architecture is:

Client
10.100.10.25
    |
    v
Load Balancer
10.100.10.5
    |
    v
Nginx
10.100.20.5
    |
    v
Wazuh

The Wazuh server may see the Nginx address:

10.100.20.5

rather than:

10.100.10.25

A proxy can communicate the original address through headers such as:

X-Forwarded-For

or:

X-Real-IP

But these headers must be treated carefully.

You should configure trusted proxy behavior so that only known intermediary systems can supply or modify these headers.

Do not blindly trust an arbitrary client-supplied X-Forwarded-For value.

Preventing IP Spoofing

A malicious client may attempt to send a forged header:

X-Forwarded-For: 10.100.10.25

in an attempt to appear to originate from an approved network.

If the reverse proxy accepts that header directly from untrusted clients, an IP-based allowlist could potentially be bypassed.

The secure model is:

Untrusted client
       |
       X
       | Cannot define trusted client IP
       |
Reverse Proxy
       |
       | Determines actual source
       v
Trusted backend

If a load balancer sits in front of Nginx, configure Nginx to trust forwarding headers only from the load balancer’s known addresses.

The same principle applies to any proxy chain:

Client
   ↓
Trusted Load Balancer
   ↓
Trusted Reverse Proxy
   ↓
Wazuh

Each intermediary should have an explicit trust relationship.

Combining Reverse-Proxy Rules With Host Firewalls

The strongest implementation combines the reverse proxy with a host-level firewall.

For example:

                 Internet
                     |
                     v
              Network Firewall
                     |
                     v
               Nginx Proxy
              /           \
        IP allowlist     TLS
              |
              v
          Host Firewall
              |
              v
       Wazuh Dashboard

The network firewall can restrict who reaches Nginx.

Nginx can enforce client-level access rules.

The host firewall can restrict which systems can reach the Wazuh backend.

For example:

Firewall:
Allow -> 10.100.10.0/24 -> TCP 443

Nginx:
Allow -> 10.100.10.0/24
Deny  -> everything else

Host firewall:
Allow -> Nginx IP -> Dashboard port
Deny  -> other sources

This layered design is considerably stronger than relying on a reverse proxy alone.

It also means that if the reverse proxy is misconfigured, the host firewall can still provide a second access-control boundary.

Related Guides:

For an Internet-facing deployment, also monitor the reverse proxy and firewall logs for rejected connections.

Repeated attempts from unexpected addresses can provide useful indicators of scanning or unauthorized access.

The resulting security model should be:

Network allowlisting
        +
Reverse-proxy filtering
        +
Host firewall
        +
Wazuh authentication
        +
Wazuh RBAC

An IP whitelist is therefore one layer of the Wazuh security architecture, not a substitute for authentication, authorization, TLS, or proper network segmentation.

How to Verify a Wazuh IP Whitelist

Configuring a Wazuh IP Whitelist is only the first step.

You also need to verify that the allowlist produces the intended behavior.

A proper validation process should test both sides of the policy:

Authorized systems can connect.
Unauthorized systems cannot connect.
Required Wazuh services remain operational.
Firewall rules are being evaluated as expected.
NAT, proxies, and load balancers are not changing the source address unexpectedly.

Ideally, perform these tests from multiple network locations rather than relying exclusively on the Wazuh server itself.

Test Connectivity From an Allowed IP

Start from a system that should be permitted by the whitelist.

For example, if the Wazuh API is restricted to 10.100.10.0/24, test from a workstation in that network:

nc -vz WAZUH_SERVER_IP 55000

Wazuh Dashboard:

nc -vz WAZUH_DASHBOARD_IP 443

Agent communication:

nc -vz WAZUH_MANAGER_IP 1514

A successful TCP connection confirms that the network path and firewall policy permit the connection.

For HTTPS services, you can also test the application layer:

curl -kI https://WAZUH_DASHBOARD/

and:

curl -k https://WAZUH_MANAGER_IP:55000/

Remember that successful TCP connectivity does not necessarily mean that authentication or authorization will succeed.

The expected sequence is:

Network connectivity
        ↓
TLS connection
        ↓
Authentication
        ↓
Authorization
        ↓
Application access

Each layer should be tested independently.

Test Connectivity From a Blocked IP

Next, repeat the tests from a system that should not be allowed.

For example:

nc -vz WAZUH_SERVER_IP 55000

The connection should fail according to your firewall configuration.

You can also test the Dashboard:

curl -kI https://WAZUH_DASHBOARD/

The important result is that the unauthorized system cannot establish the protected connection.

If the unauthorized host can reach the service, investigate the entire network path rather than immediately modifying the Wazuh configuration.

Potential causes include:

An overly broad firewall rule
Incorrect CIDR notation
NAT
A reverse proxy
A load balancer
IPv6 connectivity
A cloud security group
Multiple network interfaces
An alternate exposed port

Check Firewall Status

Verify that the firewall is actually enabled and that your rules are present.

For UFW:

sudo ufw status numbered

For firewalld:

sudo firewall-cmd --list-all

You can inspect rich rules with:

sudo firewall-cmd --list-rich-rules

For iptables:

sudo iptables -L -n -v --line-numbers

If your system uses nftables:

sudo nft list ruleset

Do not assume that modifying one firewall automatically modifies every filtering layer.

A Wazuh server could be protected by:

Cloud security group
        ↓
Network firewall
        ↓
Host firewall
        ↓
Reverse proxy
        ↓
Wazuh service

A connection may therefore be blocked or permitted somewhere other than the rule you just configured.

Test Wazuh Agent Connectivity

For an authorized Wazuh agent, verify that it remains connected after implementing the whitelist.

On Linux:

sudo systemctl status wazuh-agent

You can inspect the agent log:

sudo tail -f /var/ossec/logs/ossec.log

Then verify the agent in the Wazuh Dashboard.

Check:

Agent status
Last keepalive
Last-seen time
Agent IP address
Agent group
Connection state

If the agent suddenly becomes disconnected after the firewall change, verify that the manager is allowing the source address actually seen by the server.

Test Wazuh API Access

From an approved administrative workstation, test TCP 55000:

nc -vz WAZUH_MANAGER_IP 55000

Then test the API over HTTPS:

curl -k https://WAZUH_MANAGER_IP:55000/

If the API requires authentication, perform an authenticated API request using the appropriate credentials or token.

The test should establish three separate facts:

The workstation can reach port 55000.
TLS negotiation works.
The authenticated user has the expected permissions.

Then repeat the test from a blocked network.

Test Dashboard Access

From an allowed workstation, open the Wazuh Dashboard URL in a browser.

Confirm that:

The login page loads.
Authentication works.
Alerts are displayed.
Dashboard data loads correctly.
The user’s normal permissions remain available.

Then test from a blocked network.

The blocked client should not be able to reach the Dashboard if your IP whitelist is designed to prevent network-level access.

If the login page appears from the unauthorized network, determine whether the request is reaching the Wazuh Dashboard directly or through a reverse proxy.

Review Wazuh Logs

Wazuh logs can help distinguish network problems from application problems.

On Wazuh servers, inspect the relevant logs under:

/var/ossec/logs/

For example:

sudo tail -f /var/ossec/logs/ossec.log

Depending on the issue, investigate:

Agent connection errors
API errors
Authentication failures
Configuration errors
TLS failures
Manager communication problems

Logs are particularly useful when the firewall allows a connection but the Wazuh application subsequently rejects it.

Review System Firewall Logs

If the firewall is blocking traffic, inspect its logs.

1. For systems using UFW, firewall-related events may be available through:

sudo journalctl -k

2. For firewalld:

sudo journalctl -u firewalld

3. For nftables or iptables, inspect the relevant kernel or logging configuration.

Firewall logs can reveal information that application logs cannot, including:

Source IP
Destination IP
Destination port
Protocol
Interface
Timestamp
Accepted or dropped traffic

This makes them particularly useful when troubleshooting a suspected whitelist mismatch.

Confirm That Legitimate Services Remain Operational

Finally, verify the entire Wazuh deployment rather than testing only one port.

Check:

Agent
  ↓
Manager
  ↓
Indexer
  ↓
Dashboard
  ↓
API

Also verify any integrations that depend on network connectivity.

For example:

Syslog ingestion
Filebeat
Cloud integrations
Alert integrations
Monitoring systems
Automation systems

A whitelist is successful only if it blocks unauthorized access without disrupting required Wazuh functionality.

Troubleshooting Wazuh IP Whitelist Issues

Most Wazuh IP whitelist problems are caused by network assumptions rather than Wazuh itself.

The most common mistake is assuming that the IP address you expect to see is the IP address that the Wazuh server actually receives.

NAT, VPNs, reverse proxies, load balancers, and cloud networking can all change the apparent source address.

Wazuh Agent Cannot Connect After Whitelisting

If an agent stops communicating after you implement the whitelist, first determine the source address seen by the Wazuh manager.

The agent might have:

Agent IP:
10.20.30.50

but the manager might receive traffic from:

10.20.30.1

because of NAT.

The whitelist must account for the address that reaches the manager’s network boundary.

Verify the Agent Source IP

On the Wazuh manager, inspect network connections or firewall logs.

For example:

sudo ss -ntp

You can also inspect firewall logs to identify the source address of rejected packets.

Compare the observed source IP with the whitelist.

If you configured:

10.20.30.50/32

but the manager sees:

10.20.30.1

the rule will not match.

Check Firewall Rules

Review the active rules:

sudo ufw status numbered

or:

sudo iptables -L INPUT -n -v --line-numbers

Check for:

Missing allow rules
Incorrect source addresses
Incorrect destination ports
Incorrect protocols
Earlier deny rules
Duplicate rules
Rules attached to the wrong interface

Related Guide: How to Test Wazuh Rules

Verify Required Wazuh Ports

Verify that the required agent ports remain available.

Typical configurations use:

1514/TCP = Agent communication
1515/TCP = Enrollment

If your deployment uses UDP communication, verify UDP 1514 as well.

You can test from the agent:

nc -vz WAZUH_MANAGER_IP 1514

For enrollment:

nc -vz WAZUH_MANAGER_IP 1515

Do not assume that allowing one port automatically permits the entire Wazuh communication path.

Check NAT and Routing

Inspect the route from the agent to the Wazuh manager:

ip route

Then identify whether traffic crosses:

A NAT gateway
A firewall
A VPN
A router
A load balancer
A cloud network boundary

The source IP used by the whitelist must correspond to the address visible at the point where filtering occurs.

Review Manager Logs

If the firewall permits the connection but the agent remains disconnected, inspect the manager logs:

sudo tail -f /var/ossec/logs/ossec.log

Look for:

Connection failures
Enrollment failures
Authentication errors
Invalid agent credentials
TLS errors
Rejected connections

This helps distinguish an IP filtering problem from a Wazuh agent configuration problem.

Wazuh API Access Is Blocked

If administrators can no longer access the API after implementing the whitelist, verify the network path before changing Wazuh authentication settings.

Verify the Administrator’s Source IP

Determine the actual IP address seen by the Wazuh server.

If administrators connect through a VPN, the source address may be from the VPN address pool.

For example:

Administrator workstation
        |
        v
VPN
10.250.0.25
        |
        v
Wazuh API

In this case, whitelist the VPN address or VPN subnet rather than the workstation’s local Wi-Fi address.

Check Firewall Configuration

Verify that TCP 55000 is allowed from the appropriate network:

sudo ufw status numbered

or:

sudo iptables -L INPUT -n -v --line-numbers

Make sure a broad deny rule is not being evaluated before the API allow rule.

Check Reverse-Proxy Rules

If API traffic passes through Nginx or Apache, inspect the proxy’s allowlist.

The host firewall may allow the request while the reverse proxy blocks it.

Conversely, the reverse proxy may allow it while the backend firewall blocks the proxy.

Check both layers.

Verify the API Listening Address

Inspect:

sudo ss -lntp | grep 55000

If the API is bound only to a particular interface, a firewall rule alone will not make it reachable through another interface.

Also verify the API configuration in:

/var/ossec/api/configuration/api.yaml

Wazuh Dashboard Is Inaccessible

Dashboard failures after IP filtering are often caused by a mismatch between the user’s actual source IP and the address permitted by the firewall.

Check Dashboard Firewall Rules

Verify the rules for the Dashboard port:

sudo ufw status numbered

or:

sudo firewall-cmd --list-all

Confirm that the appropriate administrator or user networks are explicitly allowed.

Verify the Dashboard Port

Check which port is listening:

sudo ss -lntp | grep -E ':443|:5601'

The exact port depends on your Wazuh deployment and any reverse proxy in front of it.

Check Reverse-Proxy Configuration

If Nginx or Apache is involved, verify:

allow rules
deny rules
Upstream configuration
Proxy headers
TLS configuration
Listening ports

For Nginx:

sudo nginx -t

Then inspect the relevant configuration files.

Verify the Client IP Seen by the Server

This is particularly important when a proxy or load balancer exists.

The user may believe their address is:

192.168.1.25

while the Wazuh server sees:

10.10.10.5

because the request passes through a proxy.

Always base the network allowlist on the address visible at the enforcement point.

Whitelisted IP Is Still Being Blocked

If an IP appears in your whitelist but traffic is still denied, work through the policy from the packet’s perspective.

Check CIDR Notation

A common mistake is specifying the wrong subnet.

For example:

10.20.30.15/24

is not the clearest way to represent the /24 network.

Prefer:

10.20.30.0/24

For one host:

10.20.30.15/32

Verify your CIDR calculations before deploying the rule.

Check Firewall Rule Order

With iptables, inspect rule numbers:

sudo iptables -L INPUT -n -v --line-numbers

An earlier rule may drop the packet before the allow rule is reached.

For example:

1  DROP   all
2  ACCEPT tcp -- 10.20.30.15  tcp dpt:1514

The second rule may never be reached.

Check Multiple Firewall Layers

Your host firewall may permit the traffic while another firewall blocks it.

Check:

Cloud security group
        ↓
Cloud network ACL
        ↓
Network firewall
        ↓
Host firewall
        ↓
Reverse proxy
        ↓
Wazuh

Identify exactly where the packet is being dropped.

Check Cloud Security Groups

If Wazuh runs in AWS, Azure, Google Cloud, or another cloud environment, inspect the applicable network controls.

A Linux firewall rule cannot override a cloud security group that blocks the connection before the packet reaches the server.

Check NAT or Proxy Behavior

The source IP may have changed before reaching the Wazuh host.

Inspect firewall logs and connection tables to determine the actual source address.

Unauthorized IP Can Still Access Wazuh

If an IP outside the whitelist can reach a Wazuh service, treat this as a configuration issue that should be investigated promptly.

Check for Overly Broad Allow Rules

Look for rules such as:

0.0.0.0/0

or excessively broad private-network ranges.

For example:

10.0.0.0/8

may permit considerably more systems than intended.

Review Exposed Ports

Scan the Wazuh host from an authorized testing environment to determine which services are reachable.

For example:

nmap WAZUH_SERVER_IP

For a production environment, perform external scanning only when you have authorization to do so.

Check specifically for unnecessary exposure of:

1514
1515
443
55000
9200
Other management ports

Check Reverse-Proxy Configuration

A reverse proxy may expose the Dashboard or API through a different port or hostname.

Make sure there are no alternate routes around the intended whitelist.

Review Cloud Firewall Rules

Inspect:

Security groups
Network ACLs
Load balancer listeners
Firewall policies
Public IP assignments

An overlooked load balancer listener can expose a service even when the backend server’s firewall is correctly configured.

Scan Externally Exposed Services

After making changes, perform an authorized external port scan to verify the intended attack surface.

The goal is not simply to confirm that a firewall rule exists.

The goal is to verify what an unauthorized system can actually reach.

Wazuh IP Whitelist Security Best Practices

A good Wazuh IP allowlisting strategy should reduce network exposure without becoming so broad or complex that it creates operational problems.

Follow the Principle of Least Privilege

Allow only the source networks that genuinely require access.

For example:

Agent network
    -> 1514/TCP

Enrollment network
    -> 1515/TCP

SOC network
    -> 443/TCP

Management network
    -> 55000/TCP

Wazuh components
    -> 9200/TCP

Do not give every workstation access to every Wazuh service.

Avoid Exposing Wazuh Services Directly to the Internet

Where possible, Wazuh management services should remain on private networks.

Avoid exposing:

to the entire Internet unless there is a specific architectural requirement.

If remote access is required, consider using:

VPN
Zero-trust network access
Private connectivity
Bastion hosts
Restricted reverse proxies

Prefer Private Networks and VPNs

A VPN can provide a controlled network path for remote administrators.

Instead of:

Remote workstation
       |
       v
Internet
       |
       v
Wazuh API

use:

Remote workstation
       |
       v
VPN
       |
       v
Management network
       |
       v
Wazuh API

The whitelist can then restrict API access to the VPN’s address pool.

Restrict Administrative Services to Management Networks

Services such as the Wazuh API and Indexer should generally have narrower access policies than agent communication.

For example:

Agents       -> Manager:1514
Administrators -> API:55000
Dashboard users -> Dashboard:443
Wazuh components -> Indexer:9200

This separation reduces lateral movement opportunities if one endpoint becomes compromised.

Use CIDR Ranges Carefully

CIDR makes firewall management easier, but convenience should not replace precision.

Prefer:

10.20.30.0/24

when that is genuinely the trusted agent network.

Avoid:

10.0.0.0/8

when only a small subnet needs access.

For individual hosts, use:

10.20.30.15/32

where appropriate.

Combine IP Filtering With Authentication

IP filtering answers:

“Where is this connection coming from?”

Authentication answers:

“Who is connecting?”

Neither control should be expected to replace the other.

A strong Wazuh deployment combines:

IP filtering
+
TLS
+
Authentication
+
Authorization

Use Wazuh RBAC for Authorization

Network allowlisting does not determine what an authenticated user can do.

Use Wazuh RBAC to control access to functionality and resources after authentication.

For example:

SOC Analyst
    -> Alerts
    -> Investigation

Incident Responder
    -> Alerts
    -> Response operations

Wazuh Administrator
    -> Configuration
    -> Management

Related Guide: How to Configure Wazuh RBAC

Monitor Firewall Changes

Firewall modifications should be treated as security-sensitive administrative changes.

Monitor:

Firewall configuration changes
New allow rules
Removed deny rules
Changes to trusted CIDRs
New exposed ports
Reverse-proxy configuration changes

For organizations using centralized security monitoring, firewall configuration changes can also be incorporated into broader audit and detection workflows.

Related Guide: How to Configure Wazuh Audit Logs

Regularly Review and Remove Obsolete IP Addresses

IP allowlists tend to grow over time.

An administrator might temporarily add:

10.100.20.25

for troubleshooting and forget to remove it.

A network range might remain trusted even after the associated VLAN is decommissioned.

Review whitelist entries periodically and remove:

Former administrators
Decommissioned servers
Old VPN ranges
Retired networks
Temporary testing addresses
Duplicate rules
Broad ranges that are no longer required

This keeps the Wazuh network attack surface under control.

Document Whitelist Rules

Every whitelist rule should have a clear purpose.

For example:

Source: 10.20.30.0/24
Destination: Wazuh Manager
Port: 1514/TCP
Purpose: Production Wazuh agents
Owner: Security Operations
Review: Quarterly

This is considerably easier to audit than an unexplained firewall rule such as:

ALLOW 10.20.30.0/24

Documentation also helps prevent accidental removal of rules that support critical services.

Test Firewall Changes Before Production Deployment

Do not make restrictive firewall changes directly on a production Wazuh server without a recovery plan.

Before applying a default-deny policy:

Confirm existing connections.
Add the required allow rules.
Verify rule ordering.
Test from an authorized host.
Test from an unauthorized host.
Confirm Wazuh services remain operational.
Keep an administrative session available.
Have console or out-of-band access available.
Document the rollback procedure.

This is particularly important when modifying firewall rules remotely.

A poorly ordered rule can lock you out of the Wazuh server entirely.

Maintain Emergency Administrative Access

Always maintain a controlled recovery path.

For example:

Primary access
     |
     v
VPN -> Management network -> SSH

Emergency access
     |
     v
Bastion / Console / Out-of-band management

Do not create a permanent unrestricted administrative backdoor merely to avoid lockouts.

Instead, maintain a documented emergency access mechanism that is itself secured, monitored, and limited to authorized administrators.

The overall objective of a Wazuh IP whitelist is to reduce unnecessary network exposure while preserving legitimate operations.

The most effective implementation combines source-IP filtering, least-privilege firewall rules, private networking, authentication, RBAC, logging, and regular access reviews rather than relying on IP allowlisting as a standalone security control.

Real-World Wazuh IP Whitelist Example

Consider an enterprise Security Operations Center (SOC) with several hundred servers and workstations sending security telemetry to a centralized Wazuh deployment.

Rather than placing every Wazuh service on the same network, the organization separates its infrastructure into dedicated network segments.

The resulting architecture looks like this:

                         Enterprise Network
                                |
              +-----------------+-----------------+
              |                 |                 |
              v                 v                 v
       Agent Network      SOC User Network   Management Network
       10.20.10.0/24       10.20.20.0/24      10.20.30.0/24
              |                 |                 |
              |                 |                 |
              v                 v                 v
        Wazuh Agents       SOC Analysts       Administrators
              |                 |                 |
              +-----------------+-----------------+
                                |
                                v
                         Wazuh Infrastructure

The organization then applies different network policies to each Wazuh service.

Separate Management, Agent, and User Networks

The enterprise creates three primary networks:

Network	CIDR	Purpose
Agent network	`10.20.10.0/24`	Wazuh-managed endpoints
SOC network	`10.20.20.0/24`	Security analysts
Management network	`10.20.30.0/24`	Wazuh administrators

The Wazuh infrastructure is placed on a protected server network:

Wazuh Manager:   10.20.40.10
Wazuh Indexer:   10.20.40.20
Wazuh Dashboard: 10.20.40.30

This segmentation allows the organization to create service-specific firewall policies rather than allowing every network to communicate with every Wazuh component.

Whitelist the Wazuh Manager From Trusted Agent Subnets

Wazuh agents require access to the manager for normal communication.

The firewall therefore permits:

10.20.10.0/24 -> Wazuh Manager:1514/TCP -> ALLOW

If automatic enrollment is used:

10.20.10.0/24 -> Wazuh Manager:1515/TCP -> ALLOW

Other networks are not permitted to reach these ports.

The resulting policy is:

Agent Network
     |
     +---- TCP 1514 ----> Wazuh Manager
     |
     +---- TCP 1515 ----> Wazuh Manager

An analyst workstation on 10.20.20.0/24, for example, does not need direct access to port 1514.

Restrict Dashboard Access to the SOC Network

Security analysts access the Wazuh Dashboard from:

10.20.20.0/24

The firewall therefore permits:

10.20.20.0/24 -> Wazuh Dashboard:443/TCP -> ALLOW

The agent network does not need Dashboard access merely because its systems are monitored by Wazuh.

Likewise, arbitrary corporate workstations should not automatically have network access to the Dashboard.

The policy becomes:

SOC Network
    |
    +---- HTTPS 443 ----> Dashboard -> ALLOW

Agent Network
    |
    +---- HTTPS 443 ----> Dashboard -> DENY

This is a practical example of applying least privilege at the network layer.

Restrict API Access to Administrators

The Wazuh API requires even tighter restrictions.

Only the management network is authorized to access TCP 55000:

10.20.30.0/24 -> Wazuh API:55000/TCP -> ALLOW

SOC analysts can access the Dashboard but cannot directly access the API unless their workstation is explicitly authorized.

The organization could make this even more restrictive by permitting only specific administrator systems:

10.20.30.15/32 -> Wazuh API:55000/TCP -> ALLOW
10.20.30.16/32 -> Wazuh API:55000/TCP -> ALLOW

This is preferable when only a small number of systems need administrative API access.

Related Guide: How to Configure Wazuh RBAC

Restrict Indexer Access to Wazuh Components

The Indexer contains security telemetry and should not be directly accessible by ordinary users.

The firewall allows only the Wazuh components that require Indexer communication.

For example:

Wazuh Manager    -> Indexer:9200 -> ALLOW
Wazuh Dashboard  -> Indexer:9200 -> ALLOW
SOC workstation  -> Indexer:9200 -> DENY
Agent network    -> Indexer:9200 -> DENY
Internet         -> Indexer:9200 -> DENY

The Indexer’s cluster communication ports are similarly restricted to the appropriate Wazuh Indexer nodes in a multi-node deployment.

Related Guide: How to Build a Wazuh Indexer Cluster

Use a Reverse Proxy for External Administrative Access

Suppose the organization needs remote administrative access to the Dashboard.

Instead of exposing the Dashboard server directly to the Internet, administrators connect through a hardened reverse proxy.

Remote Administrator
        |
        | HTTPS
        v
   VPN / Internet
        |
        v
+-------------------+
| Reverse Proxy     |
| IP allowlisting   |
| TLS               |
| Access logging    |
+-------------------+
        |
        v
 Wazuh Dashboard

The reverse proxy allows only approved administrative networks or VPN ranges.

For example:

VPN: 10.50.0.0/24 -> Reverse Proxy:443 -> ALLOW
Internet           -> Reverse Proxy:443 -> DENY

The Dashboard itself is also protected by a host firewall.

This creates multiple security layers instead of relying solely on the reverse proxy.

Related Guide: How to Configure a Wazuh Proxy

Validate the Configuration With Allowed and Blocked Clients

The SOC validates the implementation using several test systems.

An agent-network client tests:

nc -vz 10.20.40.10 1514

Expected result:

SUCCESS

An administrator tests API access:

nc -vz 10.20.40.10 55000

Expected result:

SUCCESS

An SOC analyst tests Dashboard access:

nc -vz 10.20.40.30 443

Expected result:

SUCCESS

The organization then tests from an unauthorized workstation.

For example, the unauthorized workstation attempts:

nc -vz 10.20.40.20 9200

Expected result:

FAILED / TIMEOUT

The same client attempts to reach the API:

nc -vz 10.20.40.10 55000

Expected result:

FAILED / TIMEOUT

The SOC also verifies that legitimate agents remain connected and that Dashboard data continues to update.

This produces a clear access matrix:

Source	Manager `1514`	API `55000`	Dashboard `443`	Indexer `9200`
Agent network	Allow	Deny	Deny	Deny
SOC network	Deny	Deny	Allow	Deny
Management network	As required	Allow	Allow	As required
Internet	Deny	Deny	Via controlled proxy only	Deny

This approach demonstrates why a Wazuh IP Whitelist should be designed around specific communication requirements rather than treated as one global list of trusted addresses.

Frequently Asked Questions

Question: What Is a Wazuh IP Whitelist?

A Wazuh IP whitelist is a network access-control policy that permits specified IP addresses or IP ranges to communicate with selected Wazuh services while blocking unauthorized sources.

In practice, the whitelist is usually implemented with a firewall, network security group, reverse proxy, or another network-control mechanism rather than a single global Wazuh setting.

Question: Does Wazuh Have a Built-In IP Whitelist?

Wazuh does not provide one universal “IP whitelist” setting that automatically restricts every Wazuh component.

Different services have different network requirements, including the Wazuh Manager, API, Dashboard, and Indexer.

For this reason, IP allowlisting is generally implemented at the appropriate network-control layer.

Question: How Do I Whitelist an IP Address in Wazuh?

Use a firewall or other network access-control mechanism to allow the required source IP to the specific Wazuh service and port.

For example:

sudo ufw allow from 10.20.30.15 to any port 55000 proto tcp

This allows 10.20.30.15 to reach the Wazuh API on TCP 55000.

The exact rule depends on which Wazuh service you are protecting.

Question: How Do I Whitelist an IP Range in Wazuh?

Specify the trusted network using CIDR notation.

For example:

sudo ufw allow from 10.20.30.0/24 to any port 1514 proto tcp

This allows systems in 10.20.30.0/24 to communicate with the Wazuh manager on TCP 1514.

Only use a subnet when every address in that subnet should legitimately have access.

Question: Which Wazuh Ports Should I Whitelist?

The ports depend on your architecture.

Common Wazuh ports include:

Port	Purpose
`1514/TCP`	Agent communication
`1514/UDP`	Optional agent communication
`1515/TCP`	Agent enrollment
`55000/TCP`	Wazuh API
`443/TCP`	Wazuh Dashboard in standard deployments
`9200/TCP`	Wazuh Indexer REST/API communication

Wazuh cluster and other integration ports may also be required.

Do not automatically whitelist every Wazuh port for every network.

Determine which systems actually require each service.

Question: How Do I Whitelist Wazuh Agents?

Allow the agent network or individual agent addresses to reach the Wazuh manager’s agent communication port.

For example:

10.20.10.0/24 -> Manager:1514/TCP -> ALLOW

If automatic enrollment is used:

10.20.10.0/24 -> Manager:1515/TCP -> ALLOW

Then deny unnecessary access from other networks.

Question: How Do I Restrict Wazuh Dashboard Access by IP?

Use a firewall or reverse proxy to permit only approved networks to reach the Dashboard.

For example:

10.20.20.0/24 -> Dashboard:443/TCP -> ALLOW
Other networks -> Dashboard:443/TCP -> DENY

If a reverse proxy is used, configure its client-IP restrictions as well as the host firewall.

Question: How Do I Restrict Wazuh API Access by IP?

Restrict TCP 55000 to the management networks or administrator hosts that require API access.

For example:

sudo ufw allow from 10.20.30.0/24 to any port 55000 proto tcp

Then combine the network restriction with API authentication and appropriate authorization.

Question: Can I Whitelist Multiple IP Addresses in Wazuh?

Yes. You can create multiple firewall or reverse-proxy rules for individual addresses or combine addresses into appropriate CIDR ranges.

For example:

20.30.15/32
20.30.16/32
20.30.17/32

could represent three authorized administrator systems.

If those systems belong to a controlled subnet, a CIDR range may be easier to manage.

Question: Can I Use CIDR Notation With a Wazuh IP Whitelist?

Yes. CIDR notation is commonly used when implementing network-level IP allowlisting.

Examples include:

20.30.15/32
20.30.0/24
20.0.0/16
db8:1234::/64

Use the smallest practical range that includes all legitimate systems.

Question: Should I Use Wazuh Rules or a Firewall for IP Whitelisting?

Use a firewall or equivalent network-control mechanism for network access restrictions.

Wazuh rules are primarily intended for analyzing events and generating security alerts.

They should not be treated as a replacement for a network firewall when the goal is to prevent an unauthorized system from establishing a connection.

The distinction is:

Firewall
    ↓
Controls whether traffic can reach the service

Wazuh rules
    ↓
Analyze security events and generate detections

These mechanisms can complement each other, but they serve different purposes.

Question: How Do I Troubleshoot a Wazuh IP Whitelist?

Start by identifying the actual source IP seen by the Wazuh server.

Then check:

CIDR notation.
Firewall rule ordering.
Destination port.
TCP versus UDP.
NAT.
Reverse proxies.
Load balancers.
Cloud security groups.
Wazuh service configuration.
Wazuh and firewall logs.

Test from both an authorized and unauthorized network.

Question: Is It Safe to Expose Wazuh to the Internet?

Directly exposing Wazuh management services to the public Internet increases the attack surface and should generally be avoided when private connectivity is possible.

Services such as the Wazuh API and Indexer should receive particularly restrictive network access.

If remote access is required, consider using:

VPNs
Private networks
Bastion hosts
Reverse proxies
Network firewalls
Strong authentication
RBAC
TLS

Do not rely on an IP whitelist as the only security control.

Question: Can I Combine IP Whitelisting With Wazuh RBAC?

Yes, and doing so provides stronger defense in depth.

IP filtering controls where a connection originates.

Authentication identifies who is connecting.

RBAC determines what that authenticated user can do.

A strong architecture therefore looks like:

Source IP
    ↓
Firewall
    ↓
TLS
    ↓
Authentication
    ↓
Wazuh RBAC
    ↓
Authorized functionality

Conclusion

A Wazuh IP Whitelist can significantly reduce unnecessary network exposure by ensuring that Wazuh services are reachable only from trusted systems and networks.

The most effective approach is to implement IP allowlisting at the firewall or network-control layer and apply different restrictions to each Wazuh component.

For example:

Agent networks
    -> Wazuh Manager

SOC networks
    -> Wazuh Dashboard

Management networks
    -> Wazuh API

Wazuh components
    -> Wazuh Indexer

Avoid creating one broad rule that allows an entire corporate network to access every Wazuh service.

Instead, apply the principle of least privilege.

Permit only the source addresses, networks, ports, and protocols that are genuinely required.

IP filtering should also be combined with other security controls.

Authentication verifies the identity of users and applications, while Wazuh RBAC determines what authenticated users are authorized to access.

The resulting security model is much stronger:

Least-privilege network access
             +
        IP allowlisting
             +
        Private networking
             +
      Authentication/TLS
             +
         Wazuh RBAC
             +
      Continuous monitoring

Finally, regularly review your whitelist rules.

Remove obsolete addresses, document the purpose of each rule, monitor firewall changes, and test both allowed and blocked connections after significant network changes.

A Wazuh IP whitelist should not be considered a one-time configuration.

It should be treated as an ongoing part of your Wazuh network-security and access-control strategy.