The EdgeRouter Lite SOHO network firewall rules are explained in detail. This project is continued from Ubiquiti EdgeRouter Lite SOHO Network Configuration. Also see the project introduction for network requirements, logical and physical network design.
My network design diagram is:
The EdgeRouter Lite print configuration and CLI commands were discussed in the previous project. Now I’ll explain the firewall setup.
EdgeRouter Lite SOHO Network Firewall Rules
Firewall Basic Concepts and Definitions
Please review the Layman’s firewall explanation before proceeding. I’ve followed the EdgeRouter community conventions for naming the WAN firewall rule sets:
- WAN_IN – Inbound Internet traffic that is forwarded through the router to the LAN.
- WAN_LOCAL – Inbound Internet traffic to the router itself.
- WAN_OUT – Internal traffic forwarded through the router to the Internet.
The above rule sets are then applied to an interface.
The EdgeRouter firewall tracks the state of IP packets and traffic flows via the connection tracking (conntrack) table. The four states are new, established, related and invalid. For example, the following WAN_IN rule 10 has a default action of accept and matches established & related packets:
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
Rule 10 (above) does not match new and invalid packets because these states are not in the rule. The CLI commands are:
set firewall name WAN_IN rule 10 action accept set firewall name WAN_IN rule 10 description 'Allow established/related' set firewall name WAN_IN rule 10 state established enable set firewall name WAN_IN rule 10 state related enable
Network and Address Group Block Rules
Internet IP addresses are constantly bombarded with bad traffic (BOGONS, RFC1918 Private Networks), scanners and infiltration attempts. address-groups (for individual IPs) and network-groups (for subnets) are defined to block most of the undesirable traffic. I borrowed this technique from the EdgeMax forum. The following entries are from published lists and sources found by monitoring my EdgeRouter log. For example, to display the last 150 lines of the log from the CLI: ubnt@ubnt:~$ tail -n 150 /var/log/messages.
firewall {
all-ping enable
broadcast-ping disable
group {
address-group Shodan {
description "Shodan and other scanners"
address 208.180.20.97
address 198.20.69.74
...etc...
address 54.206.70.29
}
network-group BOGONS {
description BOGONS
network 10.0.0.0/8
network 100.64.0.0/10
network 127.0.0.0/8
network 169.254.0.0/16
network 172.16.0.0/12
network 192.0.0.0/24
network 192.0.2.0/24
network 192.168.0.0/16
network 198.18.0.0/15
network 198.51.100.0/24
network 203.0.113.0/24
network 224.0.0.0/3
}
network-group Blocklist {
description "Block scanners by CIDR"
network 74.82.47.0/24
network 184.105.139.0/24
...etc...
network 185.35.63.0/24
}
network-group LAN_NETWORKS {
description "RFC1918 LAN Networks"
network 192.168.0.0/16
network 172.16.0.0/12
network 10.0.0.0/8
}
WAN_IN and WAN_LOCAL Firewall Rules
Recall the the WAN_IN and WAN_LOCAL definitions:
- WAN_IN – Inbound Internet traffic that is forwarded through the router to the LAN.
- WAN_LOCAL – Inbound Internet traffic to the router itself.
The single most important firewall rule is to drop all new connection attempts from the Internet to the router and only allow responses to LAN side requests back in. The WAN_IN and WAN_LOCAL firewall rule concept is illustrated in the following diagram:
The only exception to dropping new Internet connections is allowing OpenVPN traffic through an encrypted tunnel after rigorous authentication:
See the Ubiquiti EdgeRouter OpenVPN Server-Client Configuration Tutorial for details.
My WAN_IN and WAN_LOCAL firewall rules:
- drops traffic that doesn’t match a numbered firewall rule: default-action drop
- allows established and related
- drops BOGONS, undesirable sources (Blocklisted CIDRs) and scanners
The rule order 10, 20, 30, etc. is important because the EdgeRouter evaluates rules in ascending numerical order and stops processing rules when it finds a match:
name WAN_IN {
default-action drop
description "WAN to internal"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
rule 30 {
action drop
description "Drop BOGONS"
log enable
protocol all
source {
group {
network-group BOGONS
}
}
}
rule 40 {
action drop
description "Blocklisted CIDRs"
log enable
protocol all
source {
group {
network-group Blocklist
}
}
}
rule 50 {
action drop
description "Drop Shodan scanners"
log enable
protocol all
source {
group {
address-group Shodan
}
}
}
}
name WAN_LOCAL {
default-action drop
description "WAN to router"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
rule 30 {
action drop
description "Drop Shodan scanners"
log enable
protocol all
source {
group {
address-group Shodan
}
}
}
rule 40 {
action drop
description "Drop BOGONS"
log enable
protocol all
source {
group {
network-group BOGONS
}
}
}
rule 50 {
action drop
description "Blocklisted CIDRs"
log enable
protocol all
source {
group {
network-group Blocklist
}
}
}
rule 60 {
action accept
description OpenVPN
destination {
port 443
}
log disable
protocol tcp
}
}
Note that WAN_LOCAL rule 60 for OpenVPN is last in the rule order. Why? Because the scanners and hackers are probing port 443 and I want to silently drop that traffic first. This way hackers don’t get a failed port 443 connection attempt which indicates something is at my public IP address.
Security Camera Firewall Rules
I defined network-groups to isolate the security cameras. VIDEO_VLAN is the camera subnet and VIDEO_VLAN_BLOCK_NETS are the other VLANs which have no reason to communicate with the security cameras:
network-group VIDEO_VLAN {
description "Video Camera VLAN subnet"
network 10.10.1.0/24
}
network-group VIDEO_VLAN_BLOCK_NETS {
description "Drop Video Camera traffic to other VLANs"
network 10.10.2.0/24
network 10.10.4.0/24
network 10.10.5.0/24
network 10.10.6.0/24
}
Block Video Camera New Connections to the Internet
The WAN_OUT firewall rule blocks new security cameras connections to the Internet but allows related and established traffic through – “cameras should speak only when spoken to”. This prevents a possibly rogue or malware infected camera leaking private information or participating in a botnet/DDoS attack. The camera operates normally when I remotely connect to the EdgeRouter via an OpenVPN tunnel because that is an established/related connection:
The camera Internet access rules are defined in the WAN_OUT rule set:
name WAN_OUT {
default-action accept
description "Internal to WAN"
rule 10 {
action accept
description "Accept Established/Related security camera to WAN"
log disable
protocol all
source {
group {
network-group VIDEO_VLAN
}
}
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Block security camera initiated connections to WAN"
log enable
protocol all
source {
group {
network-group VIDEO_VLAN
}
}
state {
new enable
}
}
}
And the WAN_OUT rule set (along with WAN_IN and WAN_LOCAL) is applied to the EdgeRouter interface eth0 which is connected to my cable modem:
interfaces {
ethernet eth0 {
address dhcp
description Internet
dhcp-options {
default-route update
default-route-distance 210
name-server no-update
}
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
out {
name WAN_OUT
}
}
speed auto
}
After configuring the WAN_OUT firewall rule I checked the log (ubnt@ubnt:~$ tail -n 150 /var/log/messages) and saw that the cameras and Network Video Recorder (NVR) were trying to initiate new Internet connections which were blocked by the firewall. The cameras were sending NTP requests because I forgot to update the camera configurations to use the EdgeRouter IP address (10.10.0.1) as the NTP server.
I also saw DDNS requests from a camera because I’d overlooked disabling the manufacturer’s factory enabled DDNS service. After making the NTP and DDNS updates my foreign made cameras are well behaved with no further Internet connection attempts.
Isolate the Security Camera VLAN
The security cameras are isolated from most other VLANs by applying the VIDEO_VLAN_IN firewall rule set to virtual interface vif 10 (VLAN 10). I say “most” because I didn’t block access to the management VLAN 1 and private WiFi VLAN 30 networks that I use when at home to access the cameras. The concept is illustrated in the following diagram:
The VIDEO_VLAN_IN firewall rule 20 drops traffic if destined to one of the blocked VLANs. If the packet doesn’t match rule 20 the default action allows the packet through:
name VIDEO_VLAN_IN {
default-action accept
rule 20 {
action drop
destination {
group {
network-group VIDEO_VLAN_BLOCK_NETS
}
}
}
}
The firewall rule set is applied to the eth1.10 in interface. This is an example where VLANs enable the application of highly specific firewall rules:
ethernet eth1 {
address 10.10.0.1/24
description LAN
dhcp-options {
default-route update
default-route-distance 210
name-server update
}
duplex auto
speed auto
vif 10 {
address 10.10.1.1/24
description "Video - Security Cameras"
firewall {
in {
name VIDEO_VLAN_IN
}
}
mtu 1500
}
Isolate the Guest WiFi Network
Guest WiFi network users are only allowed to access the Internet. Firewall pinholes are opened for the EdgeRouter DNS and DCHP services. These rules are from the EdgeMAX – How to Protect a Guest Network on EdgeRouter tutorial. I didn’t need have to specify the various VLAN subnets (10.10.x.x) because they are within the 10.0.0.0/8 network defined in LAN_NETWORKS.
name GUEST_PROTECT_IN {
default-action accept
rule 10 {
action accept
description "Accept Established/Related"
protocol all
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop LAN_NETWORKS"
destination {
group {
network-group LAN_NETWORKS
}
}
protocol all
}
}
name GUEST_PROTECT_LOCAL {
default-action drop
rule 10 {
action accept
description "Accept DNS"
destination {
port 53
}
protocol udp
}
rule 20 {
action accept
description "Accept DHCP"
destination {
port 67
}
protocol udp
}
}
Because my Guest WiFi network is on VLAN 40 the firewall rule set is applied to virtual interface 40 (vif 40) on interface eth1. Recall EdgeRouter port eth1 is connected to my EdgeSwitch and then to the UniFi Access Point:
ethernet eth1 {
address 10.10.0.1/24
description LAN
dhcp-options {
default-route update
default-route-distance 210
name-server update
}
duplex auto
speed auto
...etc..
vif 40 {
address 10.10.4.1/24
description "WLAN Guest"
firewall {
in {
name GUEST_PROTECT_IN
}
local {
name GUEST_PROTECT_LOCAL
}
}
mtu 1500
}
This series is continued in Ubiquiti EdgeRouter OpenVPN Server-Client Configuration Tutorial.
Best,
Bob Jackson
