I am using VLANs to isolate a few networks in my setup. When I use nmap to scan from the IOT zone, I am able to see results on the LAN zone which should not happen. Is my setup flawed or is this expected?
LAN = 10.9.8.0/24 (VLAN ID 1)
Guest = 10.9.7.0/24 (VLAN ID 3)
IOT = 10.9.5.0/24 (VLAN ID 5)
For example, on the box in the IOT zone:
% ip a
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether ...
inet 10.9.5.245/24 metric 1024 brd 10.9.5.255 scope global dynamic eth0
...
# nmap -sn 10.9.8.0/24 -oG -
# Nmap 7.92 scan initiated Mon Sep 13 08:40:24 2021 as: nmap -sn -oG - 10.9.8.0/24
Host: 10.9.8.1 (pi4.lan) Status: Up
Host: 10.9.8.2 (AP.lan) Status: Up
Host: 10.9.8.3 (dumb-AP.lan) Status: Up
Host: 10.9.8.4 () Status: Up
Host: 10.9.8.5 () Status: Up
...
Host: 10.9.8.237 (treetop.lan) Status: Up
Host: 10.9.8.250 (printer.lan) Status: Up
...
# Nmap done at Mon Sep 13 08:40:37 2021 -- 256 IP addresses (254 hosts up) scanned in 12.80 seconds
I do have a firewall rule on my router which allows DHCP and DNS to the IOT zone. Without it, wireless devices are unable to connect.
I'm not sure that's the case. I think the issue may instead be that the VLAN tagging hasn't been done correctly and the RPi4 is treating all traffic as coming in on the LAN interface. It shouldn't be necessary to set the LAN zone to reject all input traffic if the VLAN setup was working correctly.
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
I am confused by that... right now the lan zone is allowed access to all others, but not the other way around. Am I missing something?
If @krazeh was correct, the tagging on the RPi4 and AP has been "fixed" relative to where I started it. Since this thread and this one I referenced above are linked, I want to make clear what the settings are. They are currently:
Even with these new settings, a box on the IOT zone can still see IP addresses and hostnames in the lan zone via that nmap command. Is that to be expected?
No... here is a sample from the box on the iot zone trying to ping the lan zone:
% ping 10.9.8.245
PING 10.9.8.245 (10.9.8.245) 56(84) bytes of data.
From 10.9.5.1 icmp_seq=1 Destination Port Unreachable
From 10.9.5.1 icmp_seq=2 Destination Port Unreachable
From 10.9.5.1 icmp_seq=3 Destination Port Unreachable
Perhaps the nmap command somehow access the router's DHCP table that is defined in /etc/config/dhcp ... what I find interesting is that every device I defined in that file with a static IP shows whether that device is powered on and pingable or not.
But it doesn't limit from which interfaces access is allowed. This is because of the weak host model which is implemented by OpenWrt and other Linux based operating systems:
If the IP stack is implemented with a weak host model, it accepts any locally destined packet regardless of the network interface on which the packet was received.
This isn’t usually a problem anyone will ever notice, until you and me start using multiple zones and multiple interfaces and multiple vlans and put the security to the test. Then the single cpu software based zone based firewall needs a more complex setup than just accept or reject/drop on input, output and forward.
But don’t be sad! Lateral network movement is the absolute hardest thing to detect and stop in cyber attacks. Firewalls are always very thick from wan to lan side, but once inside there is always movement possible.
IMO, this is a pretty simple problem to solve, and can be done with fairly simple firewall rules.
On the untrusted networks, set the following:
input: reject
output: accept
forward: reject
firewall traffic.rules to allow DHCP (67-68) and DNS (53), if desired
ensure that the untrusted networks have no forwardings set in the "allow forward to" except for WAN, if desired.
"allow forward from" would be empty unless there is a desire to be able to initiate connections from another network (such as the trusted LAN connecting to the IoT network)... this is a low risk situation since the connections must be initiated from another network.
That's it... those rules will fully isolate the VLANs and will prevent them from reaching the router (except for DNS and DHCP and any other services explicitly allowed).
@psherman - Interestingly, when I took your advice, than added a rule allow tcp/22 from lan to iot zone, the nmap command still produced the hostnames/IP addresses.
I'm not an expert with nmap and how it returns the results, but if you're allowing port 22 from lan > IOT and then running an nmap scan, seems totally reasonable that it would be able to scan the IOT network and return at least IP addresses of the responses... it could be then doing a DNS lookup on the upstream DNS (likely your router) to get a hostname, or maybe the hostname is actually reported as part of the standard responses on port 22 (I honestly haven't looked into this).
But I guess I'm confused about why you would find this behavior unusual given that you are explicitly allowing traffic through the firewall.
My apologies if I've misinterpreted your statements, but it sounded like you were saying that the firewall and security model was weak and insufficient.
It ain’t me saying the security model is weak either. That was the answer I got when I had the same problem as here but with uhttpd and dropbear access.
But the statement has a point!
The firewall controls data between zones but it doesn’t secure system access very well. Not at all actually since for dropbear and uhttpd you can call the system from all zones regardless of firewall settings and regardless of what your interface IP address is. The only way to protect the system and its data (probably route table in this case) is to define the listening posts for the system uhttpd and dropbear in combination with firewall input=reject/drop and very specific FW rules.
To do anything in the firewall only slows the process until you find out any interface ip address.
I’m not sure I agree with your assertion that the firewall doesn’t protect the router itself. Unless the firewall isn’t doing what it is supposed to (ie a bug) or I am misunderstanding how it is supposed to function. Does the reject/drop input not work? That is the way to secure the router, similar to other systems like vyatta/edge max, unifi, and more.
The firewall works as expected if configured right. But it is all or nothing in this non standard case! In a multi zone multi interface and multi vlan setup the firewall falls fast if one zone (most often the standard LAN) allows all on input like here.
In these cases all the zones must be on a short lease and very specific rules must be applied zone wise for what exactly is allowed in communication with the router.
Or like this, if more than one lan on the inside then all have to be treated as “guest networks”.
