dmwasielewski

Attacker to Victim Rule Validation

3 min read

Summary

This scenario validates a simple but useful firewall workflow: one host attempts to reach another host through OPNsense, the firewall rule set decides the outcome, and the result is verified in logs. The point is not to imitate a red team exercise. The point is to show that traffic control decisions can be tested and explained.

Scenario Goal

The goal is to answer three practical questions:

  • did the firewall rule behave as expected
  • what did the attacker host experience
  • what evidence does OPNsense provide about the decision

Lab Components

  • OPN-FW-01 or equivalent OPNsense VM
  • KALI-ATTACK-01 or another Linux attacker VM
  • UBU-TARGET-01 or another Ubuntu victim VM
  • separate interfaces or segments routed through OPNsense

Test Pattern

The basic pattern is:

  1. place the victim behind the OPNsense-protected segment
  2. attempt a connection from the attacker to the victim
  3. compare behaviour with a permissive rule and a restrictive rule
  4. inspect OPNsense logs to confirm the exact action taken

The connection test can stay simple. Examples:

  • ping if ICMP is part of the rule test
  • curl for HTTP or HTTPS
  • ssh if validating administrative access
  • nmap if checking how blocked probes appear in logs

Validation Walkthrough

1. Establish a baseline

Start with one rule set where the selected traffic is temporarily allowed. Confirm that the attacker can reach the victim in the expected way. This gives you a clean “before” state.

2. Tighten the rule

Change the rule or insert a higher-priority block rule so the same traffic path should now fail. Apply the rule change in OPNsense.

3. Repeat the connection attempt

Run the same test from the attacker host. The expected result is now:

  • timeout
  • refusal
  • blocked scan result

depending on the protocol and the exact rule design.

4. Inspect OPNsense logs

Open the firewall log view and find the event matching the test. Confirm:

  • timestamp
  • source IP
  • destination IP
  • destination port or protocol
  • action taken by the firewall
  • rule label or interface if visible

5. Record the conclusion

Write one short conclusion:

  • what was tested
  • which rule caused the outcome
  • how the logs confirmed it

That conclusion is as important as the screenshot.

Suggested Commands

Use only what matches the rule you are testing. For example:

ping 10.10.20.15
curl http://10.10.20.15
ssh user@10.10.20.15
nmap -Pn -p 22,80,443 10.10.20.15

The project does not need every command. It needs one clear test path and one clear result.

Evidence To Capture

  • attacker command and output
  • victim-side service status if relevant
  • OPNsense rule list
  • matching OPNsense firewall log entry
  • one note explaining whether the result matched the intended rule design

What This Scenario Proves

This scenario proves that:

  • the firewall is part of a real traffic path
  • rule changes have visible effects
  • logs can be used to validate a decision
  • the operator understands the difference between “connection failed” and “firewall blocked it”

Common Failure Points

  • testing from the wrong network segment
  • assuming the firewall blocked traffic when the target service was simply down
  • forgetting rule order
  • reading the wrong log entry because timestamps or host IPs were not noted during the test

Follow-On Improvements

Useful later improvements would be:

  • adding rate limiting on a chosen service
  • forwarding relevant firewall events into Wazuh
  • comparing a simple allow-list model against a permissive baseline

Graph View