Have you Input=reject or drop on all zones?
All need to be rejected, LAN also and you need to open DHCP and DNS port for LAN.
Now the LAN zone allows everything from anyone.
Remember also to controll the port 22, 80 and 443 to keep access to OpenWRT!!!
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.
Does nmap see the other zones?
But the case feels very similar to this thing I had problem with a while back.
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:
cat /etc/config/network cat /etc/config/wireless cat /etc/config/dhcp cat /etc/config/firewall
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:
- RPi4 is primary router
- 5 VLANs are in play
- R7800 as dumb AP
- They are directly connected (not going through a switch
The R7800 dumb AP currently has:
- Port 2 connected to an unmanaged switch (rest of the wired network)
- Port 3 connected to the on board NIC on the RPi4 router
- Port 4 connected to the POE switch for camera
VLAN ID1 = lan
VLAN ID2 = wan
VLAN ID3 = guest
VLAN ID4 = virtual
VLAN ID5 = iot (for cameras)
For context, the RPi4 router has the onboard NIC setup to use a bridge device using VLAN filtering thanks to DSA like this:
Enable VLAN filtered [X] VLAN ID Local eth0 ---------------------- 1 [X] t* 3 [X] t 4 [X] t 5 [X] t
The RPi4 zones are setup like this:
Finally, the switch settings on the AP are like this:
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?
If you just use the ping command to try and reach a LAN IP address from the IOT box does it still go through?
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
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.
From the answer in my link above:
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.
Why do you tell me this?
Please read from the top! I said exactly this already at the beginning.
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”.
I'm still not sure I really follow your logic as to why the firewall model is fragile, but I will PM you and we'll discuss there (I'm enjoying the discussion)... although it is related to the thread topic, we might be getting of into the weeds a bit .