Network Defenses

Configuring a static IP on the domain controller in the 192.168.15.0/24 range and pointing its default gateway at 192.168.15.2. The successful ping to 192.168.15.2 confirms the DC is now routed through the corp-fw firewall on the LAN segment.

pfSense is configured to hand out a small dynamic range (192.168.15.5–192.168.15.10) on the LAN, and the leases page shows project-zero-sec-work, linux-client, and project-zero-win-client all receiving addresses from that pool. This verifies that my client and security agent machines are using pfSense as their DHCP server and are correctly attached to the protected LAN.

project-zero-sec-box set to a static address of 192.168.15.50/24 with 192.168.15.2 as the default gateway in the network settings. This pins the sec-box to a fixed IP on the protected LAN so it can reliably act as a security monitoring node behind corp-fw.

project-zero-corp-svr1 configured with a static address of 10.0.5.10/24 and 10.0.5.2 as its default gateway in the network settings. This pins the web/server VM to a fixed IP in the DMZ so pfSense can consistently route and filter traffic to it.

Navigating to the Wazuh dashboard’s Agents/Endpoint section and selecting a Linux agent deployment option. Here I set the server address, agent name, and group so the dashboard can generate a tailored install command for my project-zero-sec-work host.

Server Address: 192.168.15.50

Assign an agent name: project-zero-sec-work

Groups: linux

Here, I run the curl command from the wizard to download wazuh-agent-4.9.2-1.x86_64.rpm and install it on project-zero-sec-work. The terminal output confirms the package is verified and installed, placing the agent binaries on my sec-box.

Running systemctl daemon-reload, systemctl enable wazuh-agent, and systemctl start wazuh-agent to register and start the service. The final systemctl status wazuh-agent output confirms the agent is loaded and actively running on the host.

The Wazuh dashboard lists both my sec-box and DMZ server agents as connected and reporting telemetry. This verifies that the agents successfully registered with the manager and are now contributing logs and alerts to my security monitoring stack.

Editing /var/ossec/etc/ossec.conf on project-zero-linux-client to set the <address> field to 192.168.15.50 and keep port 1514/tcp. This change ensures the Linux workstation’s Wazuh agent forwards events directly to the sec-box manager on the LAN.

The Wazuh Agents table lists the Linux client with its updated IP and group, confirming it is enrolled under the correct manager and configuration profile. This verifies that the ossec.conf change on the Linux workstation was applied successfully.

Windows domain controller’s Wazuh agent configuration file opened from the OSSEC agent install directory. I’m preparing to update the <address> element so the DC’s agent reports to the same sec-box manager as the Linux hosts.

Here I run NET STOP WAZUH followed by NET START WAZUH from an elevated command prompt, and both commands complete successfully. Restarting the service reloads the updated ossec.conf so the DC agent reconnects to the new manager IP without requiring a reboot.

I updated the Wazuh agent’s ossec.conf so it points to the project-zero-sec-box manager at 192.168.15.50 and verified in the Wazuh dashboard that the project-zero-win-client agent shows as active with the correct IP.

The DMZ tab of the pfSense DHCP server with DHCP enabled on the DMZ interface and an address pool range of 10.0.5.3–10.0.5.4 inside the 10.0.5.0/24 subnet. This configuration allows DMZ hosts like project-zero-kali to automatically receive an IP address when they join the CORP‑DMZ network.

System → Package Manager in the pfSense web GUI. From here I can search for and install the Suricata IDS/IPS package on project-zero-corp-fw

Searched for “suricata” under Available Packages and click Install on the Suricata entry, which pulls in version 7.x as a pfSense package. This step adds the Suricata engine and its management UI under the Services menu.

Disabling problematic offloads helps ensure Suricata receives accurate packet data and avoids offload-related packet loss on pfSense.

Suricata enabled on the LAN (em1) interface, with “Send alerts to system log” checked so pfSense receives Suricata alerts alongside firewall logs. This ensures LAN traffic is inspected by Suricata and that detections are centrally visible in pfSense logging.

Here, under Alert and Block Settings, I enable “Block Offenders” and select “Inline Mode” for IPS mode, which allows Suricata to drop packets from hosts that trigger rules instead of only generating alerts. This turns Suricata on the LAN into an active IPS capable of blocking malicious traffic in real time.

These options subscribe my pfSense Suricata instance to two free, community‑maintained rule feeds, giving it broad coverage of common malware, exploits, and network attacks without requiring paid subscriptions.

The Suricata LAN Rules tab with a custom rule drop icmp any any -> any any (msg:"ICMP Request Blocked"; sid:2; rev:1;) added under custom.rules. Defining this rule instructs Suricata to immediately drop ICMP echo traffic on the LAN and tag it with the “ICMP Request Blocked” message.

The Suricata alerts view on the LAN instance shows multiple entries with action “DROP” and description “ICMP Request Blocked” for ICMP traffic from the Linux client. These alerts confirm that the custom rule is firing and that Suricata is successfully blocking the ICMP pings in inline IPS mode.

Navigate to "System" ➔ "Package Manager". Look up "arpwatch" ➔ Install

The ip a output on the Kali VM shows eth0 configured in the DMZ with IP 10.0.5.3/24 and its MAC address. This confirms that Kali is correctly attached to CORP‑DMZ and ready to act as the attacker in an ARP poisoning scenario against the DMZ server.

The Ettercap command sudo ettercap -T -M arp:remote /10.0.5.10// /10.0.5.2// running on Kali, which positions the attacker between the DMZ server (10.0.5.10) and the gateway (10.0.5.2). Ettercap reports both victims and begins marking them as ARP poisoning targets, simulating a man‑in‑the‑middle attack.

Shows the Arpwatch Database tab listing interface OPT1 with IP 10.0.5.2 and MAC 08:00:27:63:b0:05, along with a timestamp. This baseline entry lets me detect any later changes or flip‑flop events that would indicate ARP spoofing against the DMZ gateway.

The arp -a output on project-zero-corp-svr shows the gateway 10.0.5.2 mapped to MAC 08:00:27:f6:91:d9 on enp0s3. Comparing this with Arpwatch’s records helps confirm whether the ARP poisoning attempt has altered the server’s view of the gateway, supporting ARP cache poisoning detection.

After installing the pfSense Suricata package, I add a custom rule that tracks how many TCP packets a single source sends to 10.0.5.10 in a one‑second window, dropping traffic when the count goes over 100. This turns Suricata into a simple rate‑limiting control that can identify an hping3‑style flood and block it once the threshold is crossed

On project-zero-attacker, I run sudo hping3 -c 250000 -d 120 -S -p 80 -V 10.0.5.10 to bombard the web server with SYN packets on port 80. The hping3 statistics show that all 250,000 packets are transmitted but only a tiny fraction are received, indicating heavy packet loss once Suricata starts dropping the flood.

In the Suricata Alerts view, multiple entries appear with action “DROP” and description “DoS – Too many packets from attacker,” all for TCP traffic from 192.168.15.10 to 10.0.5.10:80. These alerts confirm that the threshold‑based rule is firing and that pfSuricata is actively blocking the hping3 flood aimed at the web server.suricata+2

I add a custom rule drop tcp ![192.168.15.5] any -> 10.0.5.10 21 (msg:"DROP: Unauthorized FTP access attempt"; sid:1000007; rev:1;), which uses the ! operator to match any source IP except 192.168.15.5. This turns Suricata into a simple application aware firewall control. Every FTP connection to 10.0.5.10:21 is dropped unless it originates from my trusted Linux client.

On project-zero-corp-svr, I run sudo docker start ftp-svr to bring up the FTP container exposed on port 21 of 10.0.5.10. This gives Suricata a real service endpoint to protect, enforcing my “single trusted client” rule on live FTP traffic.

From the Kali attacker VM, an ftp 10.0.5.10 attempt fails with “Connection refused,” and the Suricata alert view records TCP drops from 192.168.15.8 to 10.0.5.10:21 with the description “DROP: Unauthorized FTP access attempt.” Together, these outputs confirm that the layer 7 rule is matching non‑trusted FTP clients and actively blocking them at the firewall.

The syslog-ng General settings where I enable the service, select the LAN interface, choose UDP as the default protocol, and set the default port to 1514 while including the standard SCL config library. With these options saved, syslog-ng is ready to receive log traffic from pfSense on LAN:1514.

I enable remote logging, set the remote log server to 192.168.15.50:1514, and select log categories like system and firewall events to be forwarded. This ensures pfSense streams its key security logs into syslog-ng on project-zero-sec-work, where Wazuh can ingest and correlate them with host and Suricata alerts.

To allow pfSense to forward logs to the Wazuh server, I first verified that the required firewall rules were present on both the LAN and DMZ interfaces. These rules permit UDP traffic on port 5514 from the firewall to the security server while maintaining the existing segmentation between network zones. Without these rules, the syslog messages generated by pfSense would never reach the Wazuh manager for processing.

On the sec-box, I updated the ossec.conf configuration file to enable remote syslog ingestion from pfSense. The new <remote> block instructs Wazuh to listen on UDP port 5514, accept log messages only from the trusted pfSense firewall (192.168.15.2), and bind the listener to the security server's interface. Restricting log sources helps prevent unauthorized systems from injecting events into the SIEM.

After restarting the Wazuh manager, I monitored the archives.log file using tail -f to verify that log messages were being received successfully. The live output confirms that DHCP and system events generated by pfSense are arriving on the Wazuh server in real time, validating that the remote syslog configuration is functioning correctly before moving on to detection and analysis.

I intentionally generated a failed login attempt on the pfSense web interface. Wazuh successfully ingested the authentication event and displayed it within the SIEM, proving that firewall logs are being collected, parsed, and indexed for security monitoring. This provides centralized visibility into administrative activity and failed authentication attempts occurring on the firewall.

On project-zero-sec-work, I updated the ossec.conf configuration file by adding two <localfile> blocks. These instruct the Wazuh agent to continuously monitor Suricata's eve.json file for structured JSON events and fast.log for traditional syslog-style alerts. Collecting both log formats provides Wazuh with detailed intrusion data while maintaining compatibility with standard Suricata alert logs.

After restarting the Wazuh agent, I generated network traffic to verify the integration. The screenshot shows a Suricata detection successfully ingested into Wazuh, including the alert signature, severity, source and destination information, and packet metadata. This confirms that Suricata events are being collected, parsed, and indexed correctly.

Within the wizard, I unchecked the DHCP Server role to remove it from the Domain Controller. This ensures pfSense remains the only DHCP server on the network, preventing IP address conflicts while allowing the Domain Controller to focus on Active Directory services.

I created a new Organizational Unit named ProjectZero Workstations. This OU will serve as the central location for workstation computer accounts and users that will later receive targeted Group Policy configurations.

After creating the OU, I moved the domain-joined workstation computer accounts into ProjectZero Workstations. Placing these systems inside the OU ensures that any GPOs linked to it will automatically apply to the appropriate workstations.

I then moved the user accounts into the same Organizational Unit. Organizing both users and workstations within a dedicated OU allows security policies to be managed centrally and applied consistently throughout the environment.

On project-zero-win-client, I updated the network adapter settings to use the Domain Controller (192.168.15.25) as the preferred DNS server. Active Directory relies on DNS for locating domain services, so directing DNS queries to the Domain Controller is required before the workstation can successfully join the domain.

I created a Transcripts folder on the workstation's C: drive. This directory will later be used by Group Policy to store PowerShell transcription logs, providing a centralized location for recording PowerShell activity for auditing and security monitoring.

Within the ProjectZero Workstations OU, I selected Create a GPO in this domain, and Link it here. Linking the policy directly to the OU ensures it will automatically apply to all objects contained within it.

Using the Group Policy Management Editor, I navigated to the Account Lockout Policy settings and configured the desired security controls. These settings determine how Windows responds to repeated failed logon attempts, helping protect domain accounts against password guessing and brute-force attacks.

Finally, I verified that the PZ: Account Lockout Policy was successfully linked to the ProjectZero Workstations OU with Enforced enabled. This confirms the policy will take precedence and be applied consistently to all users and computers within the Organizational Unit.

Within the Group Policy Management Editor, I navigated to the Windows PowerShell administrative template, where the available PowerShell logging policies can be centrally configured for all domain-joined workstations.

I enabled Module Logging and configured it to monitor all PowerShell modules by specifying the wildcard (*). This ensures that execution details are captured regardless of which module is used, providing comprehensive visibility into PowerShell activity.

Finally, I enabled PowerShell Transcription and configured the output directory as C:\Transcripts. Every interactive PowerShell session is automatically recorded and saved to this location, creating an audit trail that can be reviewed during incident response or security investigations.

Create/Edit a GPO ➔ Name it: px:Limit RDP

GPO Location: Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security

Navigate to:

Inbound Rules > New Rule > Type: Predefined > Remote Desktop

Click Next, leave all checked.

Choose "Allow the connection if it is secure".

Click Next. Check "Authorized users" Add.. johnd@corp.project-zero-dc.com

Click Next.

Check "Authorized users" Add..  PROJECT-ZERO-WIN-CLIENT.

Finish.

After refreshing Group Policy on the workstation, Windows prompted the user to change their password in accordance with the configured domain policy. This confirms that the Group Policy Objects created throughout the project were successfully applied to the workstation, demonstrating that centralized policy management is functioning correctly.