Implementation and Monitoring of

Firewall Rules, Domain Restrictions, and

Privilege Changes Using Wazuh and
nftables
By
Daud Arsalan

1) Lab Overview & Roles

This lab uses two Linux systems. The Wazuh Manager receives logs, applies correlation rules, and displays events
in the dashboard. The Wazuh Agent machine is the endpoint where you enforce the firewall, block traffic, and
generate the logs that flow to the Manager.

 Wazuh Manager: Ubuntu server hosting the Wazuh dashboard and processing logs from agents.
 Wazuh Agent: Ubuntu machine where nftables firewall rules were applied and system activity was
monitored.

Throughout this document, whenever you see “Run on Agent”, that means the commands go on the Wazuh
Agent machine. When you see “Check on Manager”, that means you verify results in the Wazuh dashboard.
2) Install and Enable nftables (Agent)
Begin by installing and enabling nftables on the Agent.

sudo apt update

sudo apt install -y nftables

sudo systemctl enable --now nftables

apt update refreshes your package index, allowing you to fetch the newest nftables build and dependencies. apt
install -y nftables installs the firewall framework without prompting for confirmation (-y). systemctl enable --now
both start nftables immediately and ensure it starts at boot. You can confirm it’s active using:

sudo systemctl status nftables

If it shows “active (running)”, the service is live and ready to accept rules.

3) Create a Safe Baseline Ruleset (Agent)

Now define a minimal, safe default policy that allows loopback, preserves established connections, and drops all
other traffic until we add explicit allow rules.

Open the config:

sudo nano /etc/nftables.conf

Edit the custom rules:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {

chain input {

type filter hook input priority 0;

# allow local loopback and keep existing connections

iif lo accept

ct state established,related accept

# allow SSH from your LAN (adjust the subnet)

ip saddr 192.168.1.0/24 tcp dport 22 accept

# default: log and drop anything else

counter log prefix "NFT DROP: " drop

chain forward {

type filter hook forward priority 0;

policy drop;

chain output {

type filter hook output priority 0;

policy accept;

}
Save and apply:

sudo nft -f /etc/nftables.conf

sudo nft list ruleset

flush ruleset clears any pre-existing rules to avoid conflicts. The inet family applies to both IPv4 and IPv6. The
input chain governs traffic to the Agent; output governs traffic from the Agent; forward governs routed traffic (we
drop it by policy in a host scenario). ct state established, related accept ensures existing good connections are not
broken. The final log … drops both record packets and drops them; the prefix is important so we can search for
these events in Wazuh.

4) Ship Firewall Logs to Wazuh (Agent)

We want blocked packets to be logged so Wazuh can see them.

Edit /etc/nftables.conf and change the drop rule:

counter log prefix "NFT DROP: " drop

Reload:

sudo nft flush ruleset

sudo nft -f /etc/nftables.conf

nftables logs via the kernel logging path. On Ubuntu with syslog, they arrive in /var/log/kern.log (and often
/var/log/syslog). We’ll tell the Wazuh Agent to collect them.

This instructs the agent to read kernel/syslog lines and forward them to the Manager. You can sanity-check locally
by running:

sudo grep "NFT DROP:" /var/log/kern.log

If you see entries, they’ll appear in the Wazuh dashboard momentarily.

5) Blocking Specific Countries Using ipset and iptables
On the Wazuh Agent machine, we begin by preparing the system to handle large lists of IP ranges by creating a
dedicated set that will store all blocked networks. These ranges, such as those belonging to specific countries like
China, are downloaded from a public IP database. Once imported into the set, firewall rules are created to first log
any network traffic originating from these blocked IPs and then drop the traffic entirely, preventing
communication. The logging step ensures that all blocked connection attempts are recorded so they can be
monitored later in Wazuh. Finally, the firewall configuration is saved so that it persists after system reboots, and
the log entries generated by these blocks are stored in the system’s log files for centralized collection and analysis
in the Wazuh dashboard.

Run on the Wazuh Agent machine:

sudo apt install -y ipset iptables-persistent

sudo ipset create geoblock hash:net

Download country IP list (example for China):

wget -O cn.zone http://www.ipdeny.com/ipblocks/data/countries/cn.zone

Add to ipset:

for ip in $(cat cn.zone); do

sudo ipset add geoblock $ip

done

Create an iptables rule:

sudo iptables -I INPUT -m set --match-set geoblock src -j LOG --log-prefix "IPSET DROP: " --log-level 4

sudo iptables -I INPUT -m set --match-set geoblock src -j DROP

sudo netfilter-persistent save

Logs will now go to /var/log/kern.log and be picked up by Wazuh.

6) Domain / Website Blocking Using dnsmasq
For domain-based blocking, the approach uses dnsmasq as a lightweight DNS forwarder that can be configured to
return fake IP addresses (such as 0.0.0.0) for specific domains, effectively preventing users from accessing them.
This method works at the DNS resolution level—when a user tries to visit a blocked website like facebook.com,
their browser first attempts to resolve the domain to an IP address. dnsmasq intercepts this request and returns
the invalid IP, stopping the connection before it even starts. The blocking rules are placed in a configuration file
within /etc/dnsmasq.d/, where each line specifies a domain to redirect to 0.0.0.0. Once configured, dnsmasq is
restarted to apply the changes. Any attempts to access blocked domains will fail immediately, and the events
(including DNS queries) are logged in /var/log/syslog. These logs can then be collected by the Wazuh Agent and
forwarded to the Wazuh Manager, allowing administrators to view, analyze, and report on blocked domain
attempts directly from the Wazuh dashboard.

Run on the Wazuh Agent machine:

sudo apt install -y dnsmasq

Edit /etc/dnsmasq.d/blocklist.conf:

address=/facebook.com/0.0.0.0

address=/google.com/0.0.0.0

Restart:

sudo systemctl restart dnsmasq

Test:

nslookup facebook.com 127.0.0.1

Log file path: /var/log/syslog — add it to Wazuh Agent config just like we did with kern.log.

7) Admin Privilege Monitoring with auditd (Agent)

The Administrator privileges monitoring setup is designed to track and alert on any changes to critical system files
that control administrative permissions—mainly the /etc/sudoers file (which defines who can run commands as
the superuser) and the /etc/group file (which manages group memberships, including admin-related groups like
sudo). To achieve this, we use auditd, the Linux Audit Daemon, which is a kernel-level auditing framework capable
of logging detailed security events. Once auditd is installed on the Wazuh Agent machine, audit rules are
configured to “watch” these files for any write or attribute change actions. Whenever such an event occurs—like
granting a user sudo access or modifying group memberships—it is recorded in /var/log/audit/audit.log. This log
file is then monitored by the Wazuh Agent, which forwards any detected changes to the Wazuh Manager. From
there, administrators can review the events in the Wazuh dashboard under security alerts, providing clear
visibility into unauthorized or suspicious privilege modifications. This method ensures you can quickly detect and
investigate potential privilege escalation attempts.

Run on the Wazuh Agent machine:

sudo apt install -y auditd

Add rules:

sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes

sudo auditctl -w /etc/group -p wa -k group_changes

Check:

sudo auditctl -l

Audit logs are stored in /var/log/audit/audit.log — add it to Wazuh Agent config.

8) File Integrity Monitoring (FIM) for Key Configs (Agent)
Wazuh’s FIM catches unauthorized edits, providing before/after hashes and who changed what. Add nftables and
auth-critical files to FIM:

On the Wazuh Agent machine, edit /var/ossec/etc/ossec.conf:

<localfile>

<log_format>syslog</log_format>

<location>/var/log/kern.log</location>

</localfile>

<localfile>

<log_format>syslog</log_format>

<location>/var/log/syslog</location>

</localfile>

<localfile>

<log_format>syslog</log_format>

<location>/var/log/audit/audit.log</location>

</localfile>

<syscheck>

<directories check_all="yes">/etc/nftables.conf</directories>

<directories check_all="yes">/etc/dnsmasq.d</directories>

</syscheck>
Restart agent:

sudo systemctl restart wazuh-agent

Test Cases for Firewall and Monitoring Setup

1. Website Blocking (dnsmasq + nftables)

1. Precondition: dnsmasq is configured with blocked domains (address=/facebook.com/0.0.0.0) and the

system DNS points to a local server.

2. Action: Attempt to access blocked websites from the browser.

3. Expected Result: Websites fail to load; browser shows a connection error.

4. Verification: In Wazuh Dashboard → Security Events / Syslog → Check for dnsmasq query logs indicating
blocked domain requests.
2. Country Blocking (iptables + GeoIP)

1. Precondition: iptables rules are loaded to drop inbound/outbound traffic from specified country IP ranges
(e.g., China, Russia).

2. Action: Perform a ping or curl request to an IP address from a blocked country.

3. Expected Result: Request fails with timeout or unreachable error.

4. Verification: Wazuh Dashboard → Security Events / Firewall logs → Check for iptables DROP log entries
containing the blocked IP addresses.

3. Administrator Privilege Escalation Monitoring

1. Precondition: Wazuh is configured to monitor privilege escalation attempts (e.g., sudo command usage).

2. Action: Run a sudo command from a non-root account.

3. Expected Result: Command executes only if user has sudo rights; escalation attempt is logged.

4. Verification: Wazuh Dashboard → Security Events / Authentication → Locate log entry showing sudo
usage with timestamp and username.