Block Luci access from Wifi

OK. Thanks for the fast reply. Is there no way to just block traffic to LuCI from the WiFi interface? Maybe blocking using the WiFi MAC address (the MAC addr on the wifi router, not the MAC addr's of the clients)?

No, the only way to do so would be to create a [management] vlan on one of the ethernet ports.

As to MAC filtering, even if that wasn't possible, you wouldn't want to do that since it takes all of a few seconds to change a MAC.

A management VLAN would be fine. I just switched from Tomato and the wifi block was just a checkbox, so let me know if this is the right way to do it in LEDE.

In LuCI go to Network Switch.
Currently I have:

  • VLAN 2 that is off for CPU-eth0, untagged for CPU-eth1, untagged for LAN1-4, and off for WAN
  • VLAN 3 that is untagged for CPU-eth0, off for CPU-eth1, off for LAN1-4, untagged for WAN
    Add a new VLAN (say 20)
    Pick a LAN port (say LAN 1) and set it off for all other VLANs (2 & 3) and untagged for VLAN 20
    Set VLAN 20 to tagged to the CPU

Is the above right? Don't I also have to somehow tell LuCI to only interact with VLAN 20, and but ignore VLAN 2 and 3? How do I do that?

Thanks.

While this is an absolutely valid point and should be taken into consideration, if the technical knowledge of the "attackers" is low, would it not be a much easier solution to assign IP reservation to an "admin" computer with specific mac and create iptables/firewall rule to filter out access to router's 80/443 ports for all IPs except that one?

PS. @directly whichever way you decide to go with -- please post your solution when you find one.

1 Like

/etc/config/uhttp to set the listening IP for "LuCI"

You'll need to block cross-VLAN access in either pre-routing or input rules (I don't use LuCI-driven firewall or even iptables, so I can't help much on that one.)

A management interface that is distinct from your operational interfaces has other advantages as well.

Check your switch capabilities (swconfig dev switch0 show) for the number of distinct VLANs it supports. One way or another, you may want to use the vid parameter to define the VLAN tag, independent of the vlan parameter (table-entry number). Somewhat confusingly, the pvid parameter refers to the table-entry number, not the VLAN tag (unless they are the same, as they are by default). https://openwrt.org/docs/guide-user/base-system/basic-networking#switch_configuration

OK, I think we are getting most of the pieces here. A remaining question is in the last post:

  • How can one block cross-VLAN access to LuCI in either pre-routing or input rules (preferably using LuCI to make this change)?

BTW, looking at /etc/config/wireless (which has the plaintext wifi password in it), I see it has permission 644. Shouldn't this be 600?

Anyone?

Thanks.

  • If you haven't already done so, here are wikis related to vLANs
  • I recommended running the following /etc/config/uhttpd config
    • Change listen_http and listen_https to and IP within the management vLAN
    #
    
        ##::[[---  OpenWrt uHTTPd Config  ---]]::##
    
    ####################################################
                 ##----- Servers -----##
    ####################################################
    
       # Main #
    #---------------------------------------------------
    config uhttpd 'admin'
       list    listen_http         192.168.255.1:80
       list    listen_https        192.168.255.1:443
       option  redirect_https      1
       option  home                '/www'
       option  rfc1918_filter      1
       option  max_requests        3
       option  max_connections     100
       option  cert                '/etc/ssl/certs/uhttpd.crt'
       option  key                 '/etc/ssl/private/uhttpd.key'
       option  cgi_prefix          '/cgi-bin'
       option  lua_prefix          '/luci'
       option  lua_handler         '/usr/lib/lua/luci/sgi/uhttpd.lua'
       option  ubus_prefix         '/ubus'
       option  script_timeout      60
       option  network_timeout     30
       option  http_keepalive      20
       option  tcp_keepalive       1
    

  • You're going to want to ensure you create certs via an openssl.cnf, as self-signed certs should not be utilized. Unfortunately, the luci-ssl package does this and it's not acceptable.
    • You can utilized this pre-built openssl.cnf, with all information and commands beginning on Line 430
      • Chain of Trust would be as follows:
        • Self-Signed CA >> uHTTPd cert signed by Self-Signed CA

    • While you can generate the CA and sign the cert on the router, it's not the recommended way to securely do so... that being said, users often do out of convenience.

      If you choose to generate everything via your router, perform the following:
      # Install required packages
        opkg update && opkg install openssl-util
      
      # Rename default openssl.cnf
        mv /etc/ssl/openssl.cnf /etc/ssl/openssl-original.cnf
      
      # Garnish the pre-built openssl.cnf
        wget -O /etc/ssl/openssl.cnf https://raw.githubusercontent.com/JW0914/Wikis/master/Scripts%2BConfigs/OpenSSL/openssl.cnf
      
      # Modify for Unix OSes
        sed -i 's|\\|/|g' /etc/ssl/openssl.cnf && sed -i 's|//|/|g' /etc/ssl/openssl.cnf
      

You may want to also read the Accessing Luci Web Interface Securely wiki

Changing the listening address isn't enough. You still need to configure the firewall, probably setting the wifi zone to input:reject and adding traffic rules that allows at least DHCP (port 69) and DNS (port 53) to the router from that zone.

I never said one wouldn't have to add firewall rules, I was simply offering the recommended configuration for uhttpd... the listen addresses must point to whatever ip one wants them to listen on, else they'll listen across all configured local networks.

As to the firewall, specific iptables rules wouldn't be required since there's no way for a wireless client to access an ethernet vLAN configured with a specific pvid, unless that traffic is explicitly allowed.

@directly If you're using a Windows PC to access the management vLAN, you're going to want to install OpenVPN and use the TAP setup link to configure a second TAP interface, changing it's properties for Media Status to Always Connected, and setting it with a static IP from your normal LAN subnet (I could be wrong, but I don't believe you can vLAN tag the TAP interfaces)

  • The Windows network stack is nothing like Linux's, so the easiest way to create a dummy interface for a vLAN is via the TAP network interface script OpenVPN employs.

Yes but listening on all IP addresses shouldn't be a problem since firewall traffic rules need to be used to control the access anyway.

Normal firewall traffic rules should be enough. Custom rules shouldn't be needed.

No firewall rules would need to be created at all, as fw3 blocks all traffic between zones by default.

  • A management vLAN would be on its own network and have it's own firewall zone, so provided thats done, nothing needs to be configured to prevent WLAN access.

How are you configuring uhttpd? :face_with_raised_eyebrow:

  • If you're leaving it open to listen on all interfaces, then creating firewall rules to prevent this network or that network from having access, you're making your life far more difficult than it needs to be.

I have changed uhttpd to listen on one IP address only now. The IP address is assigned on an interface which I don't allow forwarding to and from the lan interface, and the lan interface is configured with forward=reject. But I am still able to connect to port 80 on that IP address. How is it possible? Please explain. (My explanation is that the access is allowed by input=accept on the lan interface.)

Please post output of /etc/config/firewall, /etc/config/network, and /etc/config/uhttpd in code blocks

should it not be possible to filter it with iptables custom rules, like this:

iptables -A input_rule -i wlan0 -d 192.168.1.1 -p tcp --dport 443 -j reject
iptables -A input_rule -i wlan1 -d 192.168.1.1 -p tcp --dport 443 -j reject

maybe in combination with: http://ebtables.netfilter.org/documentation/bridge-nf.html

EDIT:

ok, it should be possible with this command, when we install iptables-mod-extra package:

iptables -A input_lan_rule -m physdev --physdev-in wlan0 -d 192.168.1.1 -p tcp --dport 80 -j reject
iptables -A input_lan_rule -m physdev --physdev-in wlan1 -d 192.168.1.1 -p tcp --dport 80 -j reject
iptables -A input_lan_rule -m physdev --physdev-in wlan0 -d 192.168.1.1 -p tcp --dport 443 -j reject
iptables -A input_lan_rule -m physdev --physdev-in wlan1 -d 192.168.1.1 -p tcp --dport 443 -j reject

no vlan needed... :wink:
just edit your wlan interfaces and router ip and maybe your rule name.

ok sorry - I tested it on current developer build... but the physdev iptables module is missing there.
On https://wiki.openwrt.org/doc/howto/netfilter it is written, that it is in iptables-mod-extra included.

Maybe someone file a bug report?

EDIT: https://bugs.openwrt.org/index.php?do=details&task_id=1491
EDIT2: ok, wee need to install iptables-mod-physdev

Hi there!
Since this still has no proper answer I decided to post what I did.
My config is different, more complex, but works nonetheless.

I am running trunk/snapshot on a TP-LINK ARCHER C7 AC1750 v4.
My config is setting 4 VLANs, while also using the original LAN and WiFi networks.

So we have these interfaces:

  • LAN: Port1 Eth + main dual WIFI (WiFi2.4GHz + WiFi5GHz) (10.0.0.1)
  • guest: secondary dual WIFI (WiFi2.4GHz + WiFi5GHz) (10.0.95.1)
  • VLAN_ETH2: Port2 Eth (10.0.20.1)
  • VLAN_ETH3: Port3 Eth (10.0.30.1)
  • VLAN_ETH4: Port4 Eth (10.0.40.1)

Each of those interfaces has its own DHCP server and firewall rule. I will not describe how to configure that here as it is out of scope. Also, I had problems when setting this through Luci on trunk, so I had to do it from cli by editing the /etc/config files (network, firewall, dhcp, etc). After editing from CLI, all went fine and Luci was also showing the proper info.

I wanted to leave Luci and SSH only available to the LAN interface and block it on all else.

Easiest solution for me required 2 steps:

  • Blocked "everything" on firewall ZONES
    • Check reject for both input and forward
    • Check accept on Output

Did that for all VLANs (guest, VLAN_ETH2, VLAN_ETH3, VLAN_ETH4).
This is enough to block Luci and SSH for all VLANs, but now we have no internet or even a valid IP because the DNS and DHCP ports are also blocked. The solution is to just open the needed ports for those interfaces/zones.

DNS uses port 53
DHCP uses ports 67 and 68

Easiest way is to edit the file /etc/config/firewall.
You may also add the firewall zones directly to this file.


Example of firewall zone definitions

Note the input-reject / output-accept / forward-reject

config zone
        option name 'guest'
        option forward 'REJECT'
        option output 'ACCEPT'
        option network 'guest'
        option input 'REJECT'

config zone
        option name 'VLAN_ETH4'
        option output 'ACCEPT'
        option network 'VLAN_ETH4'
        option forward 'REJECT'
        option input 'REJECT'

config zone
        option name 'VLAN_ETH3'
        option output 'ACCEPT'
        option network 'VLAN_ETH3'
        option forward 'REJECT'
        option input 'REJECT'

config zone
        option name 'VLAN_ETH2'
        option output 'ACCEPT'
        option network 'VLAN_ETH2'
        option forward 'REJECT'
        option input 'REJECT'

Example of DNS and DHCP rules

Interface names (src) ARE IMPORTANT

config rule
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_port '53'
        option name 'Guest DNS'
        option src 'guest'

config rule
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_port '67-68'
        option name 'Guest DHCP'
        option src 'guest'

config rule
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_port '53'
        option name 'VLAN_ETH2 DNS'
        option src 'VLAN_ETH2'

config rule
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_port '67-68'
        option name 'VLAN_ETH2 DHCP'
        option src 'VLAN_ETH2'

config rule
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_port '53'
        option name 'VLAN_ETH3 DNS'
        option src 'VLAN_ETH3'

config rule
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_port '67-68'
        option name 'VLAN_ETH3 DHCP'
        option src 'VLAN_ETH3'

config rule
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_port '53'
        option name 'VLAN_ETH4 DNS'
        option src 'VLAN_ETH4'

config rule
        option target 'ACCEPT'
        option proto 'tcp udp'
        option dest_port '67-68'
        option name 'VLAN_ETH4 DHCP'
        option src 'VLAN_ETH4'

I have more rules because I have four VLANs.
A single VLAN would obviously make the config 4 times easier/smaller.
Hopefully it is not too confusing for people to understand.

Edit: Be careful not to lock yourself out of the router (soft-brick). Leave at least one interface with SSH/Luci access for you to use.

Cheers!
Gus

2 Likes

Can these rules with -m physdev --physdev-in be generated by fw3 somehow?
If not, what can be the solution here?

Just put the WiFi in another network that is properly firewalled.

In the future, you may wish to open another thread.

1 Like

My use-case is different - I have to make bridged firewall instead of conventional router, due ISP-specific configuration.
I've created another thread: Help with fw3 for Bridged Firewall

Any help is appreciated, thanks.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.