search

mjp66 / Ubiquiti

765 stars 70 forks source link

Firewall suspicions #54

Closed scottj97 closed 2 years ago

scottj97 commented 3 years ago

Thank you for this guide. I learned so much about networking, firewalls, etc.

There are several things in the doc that I found suspicious. I'm not sure if I'm misunderstanding or if these things are unnecessary.

  1. page 86 WIRED_IOT_LOCAL rules: I thought "local" rules applied only to traffic destined for the ER-X itself. Therefore rule 2 here ("Allow Only OpenDNS") seems like it would never match since it only matches OpenDNS IPs. Wouldn't an OpenDNS access use the "in" rules and not the "local" rules? Same question for step 59 WIFI_SPARE_LOCAL.
  2. page 87 WIFI_IOT_LOCAL rules: these are identical to the previous page. Why not just create a single ruleset called IOT_LOCAL and apply that one ruleset to both switch0.7/local and eth1/local (and later, in step 59, to switch 0.8/local too)?
  3. page 88 WIFI_GUEST_LOCAL rules: rule 2 "Allow DNS" seems unnecessary since WifiGuestDHCP was configured back in step 30 to use OpenDNS and not 192.168.6.1. Same question for step 61 WIRED_SEPARATE_LOCAL.
mjp66 commented 3 years ago

Sorry for the delay, yes, I will have to investigate your items.

mjp66 commented 3 years ago

Stated In section 57. WIRED_IOT_LOCAL, WIFI_IOT_LOCAL Firewall Rules: The purpose of these rules is to block the use of EdgeRouter local services from these two IOT Networks, except for the use of DNS and the operation of DHCP.

All of the rules in sections 57, 58, and 59 have a default-action of drop, and then (only) allow the DHCP protocol (udp ports 67, 68) and allow DNS requests (port 53).

  1. I believe the EdgeRouter determines that traffic for these ports will appear on the firewall as "LOCAL" and not "IN". I don't want any of my IOT equipment to be able to get into the router. Read 60. Optional DNS Forcing of the WIFI_GUEST_LOCAL Network Note that although a client's DNS request may specify an external (non-ER-X) DNS resolver addresses, the actual DNS request(s) are still managed via port 53, mentioned above. You can prove this by following the provided testing method.

  2. Combining firewall rules will likely work, but I suggest you test your changes. Looks like you could use the "+ Interfaces" button. I used separate rulesets, so that users could more easily change any particular Network's operation, while they were learning.

  3. Easy to test this: A. For a Network: Ensure DHCP hands out an external (non-ER-X) DNS resolver address. Change that Network's DNS firewall rule into action = drop. You many need to reboot your impacted equipment or otherwise cause them to phone-home. B. Perform the testing from section 60, mentioned above.

Note that some IOT equipment may make DNSish requests (or otherwise phone home) using other port numbers.

Hope this helps, -Mike

GeoffWy commented 3 years ago

I believe the EdgeRouter determines that traffic for these ports will appear on the firewall as "LOCAL" and not "IN".

I just checked that out and confirmed that that is not the case. To be considered LOCAL the destination address has to be a switch address, the port number is not relevant. The test I did was as follows:

  1. In normal operation my devices are automatically allocated the switch as DNS server by DHCP.
  2. I set one of my devices to a fixed dns server at 4.4.4.4
  3. I set firewall rules on HOME_IN and HOME_LOCAL to catch traffic to 4.4.4.4:53
  4. The HOME_IN rule was triggered all the 4.4.4.4 dns accesses (seen by observing rule statistics)
  5. The HOME_LOCAL rule caught nothing.

Hope that helps. Geoff

mjp66 commented 3 years ago

Thanks guys, I will add text about this in my next guide release.

mjp66 commented 2 years ago

Latest release should clear up this confusion, Thanks.