Monitoring pfSense with Wazuh

In this post, I demonstrate how I installed the Wazuh agent on a pfSense host and ingested some logs into my SIEM.
Monitoring pfSense with Wazuh
In: Defend, Home Lab, Computer Networking, Wazuh, SIEM

Change Log

Jan. 22, 2025: Added steps to demonstrate configuring rsyslog in Wazuh Manager and pfSense to enable logging without the need to install the Wazuh Agent package



Building out Our Capabilities

This is an extension of my original home lab guide here:

Adding a Comprehensive Wazuh SIEM and Network Intrusion Detection System (NIDS) to the Proxmox Lab
In this module, we will take a look at the process setting up a comprehensive Wazuh SIEM, including a NIDS and some HIDS agents, in our Proxmox home lab.

I hope to continue adding more SIEM, hunting, and detection content. I've really enjoyed learning more about Wazuh, emulating threats with different attack techniques, and seeing how they present in the SIEM.



Option 1: Wazuh Agent

Enabling FreeBSD Package Repositories

You can install the Wazuh agent on pfSense in two ways:

  1. Compile the port locally using the FreeBSD source code
  2. Or, install the Wazuh agent from the FreeBSD package repository

For the sake of time and convenience, I am opting for option 2, and installing the Wazuh agent using the FreeBSD package repository.

FreeBSD package repositories are disabled by default on pfSense installations, as Netgate views unofficial software as a security and compatibility concern. You can read more about their reasoning at the link below.

pfSense® software Configuration Recipes — Using Software from FreeBSD | pfSense Documentation

In order to allow pkg to pull from said repository, we need a couple files:

nano /usr/local/etc/pkg/repos/pfSense.conf

Edit this file

FreeBSD: { enabled: yes }

Set enabled to 'yes'

nano /usr/local/etc/pkg/repos/FreeBSD.conf

Edit this file next

FreeBSD: { enabled: yes }

Set enabled to 'yes' here as well





Installing the Wazuh Agent

Follow the steps to enable the FreeBSD package repositories. Then, open a shell on your pfSense box and run the following commands:

# Update the package cache
pkg update

# Search the package cache for the official agent
pkg search wazuh-agent

# Install the agent
# Replace x.xx.x with your version number
pkg install wazuh-agent-x.xx.x



Revert Package Repositories

When finished with the installation, please refer back to the Enabling FreeBSD Package Repositories section and revert your changes.

  • Change back to FreeBSD: { enabled: no }
  • Run pkg clean and pkg update



Enabling and Starting the Agent

Following installation of the agent, you'll see some output on configuring your agent.

cp /etc/localtime /var/ossec/etc/

Now, edit the /var/ossec/etc/ossec.conf file and point it to your Wazuh manager:

<server>
	<address>WAZUH-MANAGER-IP-ADDRESS</address>
</server>

Now, start the Wazuh agent and enable start at boot — using the shell script option per the official documentation:

sysrc wazuh_agent_enable="YES"

# We don't want to remove any original files
# So, we create a symbolic link
ln -s /usr/local/etc/rc.d/wazuh-agent /usr/local/etc/rc.d/wazuh-agent.sh

service wazuh-agent start

Trim your Wazuh agent logs to preserve disk space:

crontab -e
# Run every day at 4 AM and delete stale logs older than 30 days
0 4 * * * find /var/ossec/logs/ossec/ -d 1 -mtime +30 -type d -exec rm -rf {} \; > /dev/null



Monitoring Suricata Logs

Enable eve.json Output

Log into your pfSense box and go to Services > Suricata. You should see a list of your interface(s) where Suricata is running.

You'll need to click the Edit button on each interface to make these changes.

Ensure these two options are set. All of the other eve.json options are your choice on configuring them.

Once you have enabled eve.json output on each desired interface, restart Suricata for the changes to take effect.



Ingesting eve.json with the Wazuh Agent

Log into your Wazuh manager using KIbana and go to Wazuh > Management > Groups.

Click on Add new group and name it something like pfSense. Click on your new group and click Manage agents.

Add your pfSense agent to the group and save the changes. Now, with the group created, you can add some pfSense-specific configurations.

Click the Edit group configuration button.

Add the following lines to the group shared configuration. Once you save it, the Wazuh manager will push the changes to any member(s) of the group.

<localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/*/eve.json</location>
</localfile>



Test Your NIDS

Want to generate some safe alerts and make sure they show up in Wazuh?

GitHub - 3CORESec/testmynids.org: A website and framework for testing NIDS detection
A website and framework for testing NIDS detection - GitHub - 3CORESec/testmynids.org: A website and framework for testing NIDS detection

Run this on any host connected to a network monitored by Suricata on the pfSense box. This will generate some false positives and you can check them out in Wazuh.



What About Syslog and Firewall Logs?

Syslog

Fortunately, the Wazuh agent will automatically ingest /var/log/system.log, so no work to be done there.



Firewall Logs

To have the Wazuh agent monitor the pfSense firewall log, just add another <localfile></localfile> directive to the agent.conf file like we did with the eve.json logs before.

Go to Wazuh > Management > Groups and click on the pfSense group we created before. Click on Edit group configuration.

Add this declaration to the configuration file and click Save.

<localfile>
	<log_format>syslog</log_format>
	<location>/var/log/filter.log</location>
</localfile>



A Note on the Firewall Log

Wazuh Manager has the decoders and rules in place to monitor the output in /var/log/filter.log. You can view the decoders and rules in the source code.

Decoders tell the Wazuh manager how to process the lines of the log output.

wazuh/0455-pfsense_decoders.xml at master · wazuh/wazuh
Wazuh - The Open Source Security Platform. Contribute to wazuh/wazuh development by creating an account on GitHub.

Rules tell the Wazuh manager how to take the decoded fields and arrange them in the various rules that will generate logs and/or alerts in the SIEM.

wazuh/0540-pfsense_rules.xml at master · wazuh/wazuh
Wazuh - The Open Source Security Platform. Contribute to wazuh/wazuh development by creating an account on GitHub.

There are two pfSense rules:

  • pfSense firewall drop event
  • Multiple pfSense firewall blocks events from same source

The pfSense firewall drop event rule does not log by default as noted by the <options>no_log</options> line in the rule declaration.

⚠️
Logging this rule can become quite noisy!
<rule id="87701" level="5">
	<if_sid>87700</if_sid>
	<action>block</action>
	<options>no_log</options>
	<description>pfSense firewall drop event.</description>
	<group>firewall_block,pci_dss_1.4,gpg13_4.12,hipaa_164.312.a.1,nist_800_53_SC.7,tsc_CC6.7,tsc_CC6.8,</group>
</rule>

The Multiple pfSense firewall blocks events from same source rule does log by default.

If you would like the pfSense firewall drop event logged to Wazuh, you can override the rule and I will show you how to do that.



Create a Custom Rule File

Open the Wazuh menu and go to Management > Rules

In the search bar, enter the keyword pfsense

Click on the rules file hyperlink

Copy the entire group declaration from <group> to </group>

Click on the back arrow

Click Add new rules file

Name it something like pfSense-Overrides.xml

Paste the text you copied into the code editor and modify it such that it looks like this. Three observations here:

  • I have added this rule to the pfSense group, the same as the original
  • The only rule remaining here is the pfSense firewall drop event rule
  • I have removed the <option>no_log</option> line and added an overwrite="yes" option to the rule.
<group name="pfsense,">
  <rule id="87701" level="5" overwrite="yes">
    <if_sid>87700</if_sid>
    <action>block</action>
    <description>pfSense firewall drop event.</description>
    <group>firewall_block,pci_dss_1.4,gpg13_4.12,hipaa_164.312.a.1,nist_800_53_SC.7,tsc_CC6.7,tsc_CC6.8,</group>
  </rule>
</group>

Click Save. It will tell you that the rule will not apply until the Wazuh Manager is restarted. You can restart the manager from this screen.

Now, return to the alerts for your pfSense Wazuh agent and you should now see the firewall drop events.



Troubleshooting Agent Upgrades

I am adding this here as a follow up, to note some issues I had while upgrading from version 4.2 to 4.3. Unfortunately, it seems there were some breaking changes between these major versions.

When I tried to upgrade my Wazuh Agent with the pkg install wazuh-agent , the installation went fine. But upon reloading the agent service with service wazuh-agent restart , I received this error message:

Could not open file 'queue/sockets/.agent_info' ...

I had to do the following to remediate:

  1. SSH into Wazuh Manager
  2. Remove the agent from the Manager with /var/ossec/bin/manage_agents , due to hostname conflicts upon re-adding the agent
  3. Make a backup of your /var/ossec/etc/ossec.conf file
  4. Uninstal, re-install, and configure the Wazuh Agent on pfSense
  5. Kill any running processes not terminated by the uninstallation: kill -9 `pgrep wazuh`
  6. Run service enable wazuh-agent and service start wazuh-agent
  7. Re-add the agent to the pfSense group to receive the shared configuration file

Not an ideal situation, but also not a huge pain to remediate. Key notes to be aware of:

  • Historic logs for your pfSense agent will be registered to a different agent ID
  • Keep this in mind when browsing current/older logs by agent ID



Option 2: rsyslog

Enable Wazuh Syslog Collector

Configuring log collection for different operating systems
User manual, installation and configuration guides. Learn how to get the most out of the Wazuh platform.
Open the Wazuh menu and click "Configuration"
Click "Edit configuration"
💡
You can do these same steps by editing /var/ossec/etc/ossec.conf via ssh as well and then running sudo systemctl restart wazuh-manager
<remote>
  <connection>secure</connection>
  <port>1514</port>
  <protocol>tcp</protocol>
  <queue_size>131072</queue_size>
</remote>

<!-- SYSLOG CONFIGURATION(S) START HERE -->
<!-- REQUIRE PER-PROTOCOL CONFIGURATIONS -->
<!-- UDP Listener -->
<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>SYSLOG_SENDER_1</allowed-ips>
  <allowed-ips>SYSLOG_SENDER_2</allowed-ips>
  <local_ip>WAZUH_MANAGER_IP</local_ip>
</remote>

<!-- TCP Listener -->
<!-- Requires a different port -->
<remote>
  <connection>syslog</connection>
  <port>515</port>
  <protocol>tcp</protocol>
  <allowed-ips>SYSLOG_SENDER_1</allowed-ips>
  <allowed-ips>SYSLOG_SENDER_2</allowed-ips>
  <local_ip>WAZUH_MANAGER_IP</local_ip>
</remote>

Substitute WAZUH_MANAGER_IP AND SYSLOG_SENDER_x with the correct IPs. More detail about the configuration options can be found here. Configured to receive syslog over TCP and UDP.

Click "Save" and once the changes are confirmed, click "Restart Manager"



Configure pfSense to Send Syslog

Log into pfSense and navigate to Status > System Logs > Settings
Set the log message format to "syslog"
In the "Source Address" field, I've chosen the LAB_HOSTS interface, as it's on the 10.148.148.0/24 VLAN. Since pfSense is the default gateway for the VLAN, the traffic will come from 10.148.148.1, thus we configured the <allowed_ip>10.148.148.1</allowed_ip> before.
⚠️
pfSense sends Syslog over udp/514 -- which aligns with the port we used in the ossec.conf file above. If other hosts require Syslog over TCP, configure to send to tcp/515 per the configuration above.

Ensure you configure firewall rules to allow traffic to Wazuh Manager where needed.
You can choose what you wish to send to Wazuh. I chose "Everything" for the sake of this example. Click "Save" when finished.



Viewing Logs in Wazuh

⚠️
The syslog events sent to Wazuh Manager are NOT going to be logged in a default Wazuh Installation, as they're not going to match on any configured rules, nor have a minimum alert threshold of >= 3. In a default installation, you'll need to write a custom rule to set specific syslog events to match your rule threshold.

In my environment, I've configured logall_json, such that we log all incoming events that can be read by a valid decoder. In this case, the events are written in syslog format, so should have no problem decoding.

Be advised that enabling logall_json in Wazuh Manager, does add an incredible amount of detail pertaining to logs and events, but it also increases the storage requirements manyfold. So, if you go this route, ensure you have adequate storage for your Wazuh Manager.
Hunting with Wazuh: Adding Context
In this post, I elaborate on the Log All JSON option in the Wazuh Manager’s configuration and how that can add more context beyond just alerts.

More information on enabling the logll_json option in Wazuh

Open the side menu and go to "Discover"
Comments
More from 0xBEN
Building a Security Lab in VMware Workstation Pro
VMware

Building a Security Lab in VMware Workstation Pro

In this project, broken up into multiple modules, you will build a comprehensive cybersecurity home lab using VMware Workstation Pro. Upon completion, you will have an environment where you can safely practice penetration testing against a wide variety of targets, as well as detection in your SIEM.
Table of Contents
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to 0xBEN.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.