Testing MITM Attack and Firewall Blocking: Discussion

[hsing]

Hi everyone, as mentioned in the title, I have been testing whether OPNsense can block MITM attacks. Below are the environment and settings I used during the test. If there are any mistakes, please feel free to correct me.

Target_1 PC (setting):

    IP: 192.168.1.111
    MAC: 00:0c:29:19:98:4a

Set static ARP for Target_2:

Code: [Select]

C:\Windows\system32>arp -a
Interface: 192.168.1.111 --- 0x3
  Internet Address       Physical Address       Type
  192.168.1.12           a0-02-4a-51-1c-0c      Static
Target_2 Device (setting):

    IP: 192.168.1.12
    MAC: a0:02:4a:51:1c:0c

Note: Target_2 cannot set a static ARP for Target_1, so a filter is needed to block traffic.

Firewall (settings):

Interfaces:

    igb1 (linked to Target_1) 00:07:32:a2:76:6d
    igb2 (linked to Target_2) 00:07:32:9c:ca

Interfaces: Other Types: Bridge

    bridge0: target_1, target_2 - bridge Off

Interfaces: Neighbors

    Manual: 00:0C:29:19:98:4A 192.168.1.111 target_1
    Manual: A0:02:4A:51:1C:0C 192.168.1.12 target_2

Firewall: Aliases

    target_1: MAC address - target_1_mac 00:0c:29:19:98:4a 1 2024-08-19 02:18:22
    target_2: MAC address - target_2_mac a0:02:4a:51:1c:0c 1 2024-08-19 02:20:00

Firewall: Rules: Floating

    PASS_Rule: IPv4 * target_1_mac * target_2_mac * * * 1 target1_target2_PASS
    BLOCK_Rule: IPv4 * * * target_2_mac * * * 1 target2_BLOCK

The idea behind these settings is that the first rule allows target_1 and target_2 to communicate normally. The second rule blocks all other traffic to target_2.


These are my settings, and then I used a testing tool (Ettercap) to test the setup.

When I tried an ARP poisoning attack, I could see in the firewall logs that the attacker's computer was using the IP of target_1 to ICMP target_2.

Code: [Select]

bridge 2024-08-19T05:57:08 192.168.1.111 192.168.1.12 icmp target1_target2_PASS
bridge 2024-08-19T05:57:08 192.168.1.111 192.168.1.12 icmp target1_target2_PASS
bridge 2024-08-19T05:57:08 192.168.1.111 192.168.1.12 icmp target1_target2_PASS
bridge 2024-08-19T05:57:08 192.168.1.111 192.168.1.12 icmp target1_target2_PASS
bridge 2024-08-19T05:57:08 192.168.1.111 192.168.1.12 icmp target1_target2_PASS
bridge 2024-08-19T05:57:08 192.168.1.111 192.168.1.12 icmp target1_target2_PASS
When I performed a MITM attack using Ettercap, I could see the connection between Target_1 and Target_2, and I was able to manipulate the connection to cause them to disconnect.

Does this mean my filter only checks up to layer 3 and does not filter at layer 2?

I would appreciate any advice from those with experience in this area.

[doktornotor]

Firewall: Aliases

    target_1: MAC address - target_1_mac 00:0c:29:19:98:4a 1 2024-08-19 02:18:22
    target_2: MAC address - target_2_mac a0:02:4a:51:1c:0c 1 2024-08-19 02:20:00

This does not work as you are imagining. https://docs.opnsense.org/manual/aliases.html#mac-addresses

The way these aliases function is approximately the same as hostnames in host type aliases, they are resolved on periodic intervals from the arp and ndp tables.

If you want L2 filtering, it's only used for captive portal, using ipfw.

[hsing]

OK, thank you very much. I am trying to test using the captive portal. So, does the captive portal feature use IPFW for filtering?

[doktornotor]

Yes, it does. But it's not exactly made for this purpose, you cannot design your own ipfw rules there directly.

[hsing]

Today, I tried adding two rules to ipfw.rules.

I found that I couldn’t directly add them under /usr/local/etc/ipfw.rules because they get overwritten when the system restarts.

However, I later discovered that if I add them under /usr/local/opnsense/service/templates/OPNsense/IPFW/ipfw.conf, they will be included in /usr/local/etc/ipfw.rules, and they won't be overwritten upon reboot. But when I tested the blocking rules, they didn’t seem to work very well. I’m not sure if it’s due to the order of operations between pf and ipfw, but I did disable pf from the Firewall: Settings: Advanced section. I’m not sure if this completely disables it.