What do your firewall rules look like?

ex1580

I finally got around to creating a whitelist alias with a default deny rule on my internal interfaces and not trying to block everything under the sun (specifically in the geoip areas). After reading the pfblocker notes to not block the world enough times I wonder if @BBcan177 can share some examples with us, maybe what your personal firewall rules look like?

I'll go first! I personally dont host anything but a honeypot so my WAN rules are simple. Allow all to honeypot IP, default deny after that. The honeypot interface can access anything except RFC1918 IPs (via alias). My internal interfaces use feeds to block a handful of known bad places (dshield, cinsarmy, spamhaus, emerging threats), then either allow or block to internal IPs depending on which interface (internal or guest), and a geoip whitelist followed by default deny. I also use NAT to redirect DNS and DNS over TLS to use unbound. Good stuff! But my memory usage is a lot higher with a geoip whitelist compared to just blocking top spammers.

What do you do?

Raffi_

At home,
default rules on WAN
internal trusted VLAN only ports required open via alias.
internal gaming VLAN allow any and UPnP enabled.
Some DNSBL's. I can't remember which ones off the top of my head, but I'm not blocking ads, only malicious stuff.

At work,
Wan, mostly automatic rules created by default and OpenVPN. A couple port forwards created by NAT only accessible by one of our other external static IPs.

Floating

LAN

OPT1

Using unbound for cache and DoT via cloudflare for anything not cached in both home and work setups.

Edit, forgot to mention also using Suricata at work with trimmed lists which took months to get working with very few false positives so I can't post any really helpful info about that.

Edit part 2, thanks for posting this because it made me review my rules and I caught an issue in one of my OPT1 rules.

ex1580

@Raffi_ Very cool! Thanks for posting! I've been stewing about making better use of aliases myself. For example, right now I have a pile of auto created pfblocker rules at the beginning of the interfaces I use them on. Would probably be better to just make it one rule with a big alias.

Raffi_

I'm not sure how exactly those new pfBlocker auto generated rules work and how they can be consolidated, but yea, I can see why you want to do that. I guess I was originally using pfblockerNG for a long time and then switched to pfblockerNG-devel so I'm not sure if my auto generated rule in the floating tab was using the old method? I actually prefer it the old way, because I notice in the new auto rules in my home setup, it always goes to the top of my VLAN interface list and I can't organize the rule the same way I do at work. Not that it really matters, but I guess I like having more control over that.

ex1580

@Raffi_ There is a checkbox for floating rules under pfblocker > IP, and down towards the bottom. By default pfblocker likes to stick all of the auto rules at the top of whatever else you have. Right under the checkbox for the floating rules you can select the order but I have not found it helpful. But hey, I found some time tonight and switched everything over to aliases! I combined the block lists and they use a "deny alias" so the duplication and suppression still work. It looks much prettier!

Here is what my guest interface looks like. Feel free to comment, I may have missed something.

billl

@ex1580 I'm just a small-time user who stayed at a Holiday Inn, so take this with a grain of salt :)
I have a personal preference to keep my floating rules limited to those that really want or need to be there, rules that use matching and direction out mostly I guess. I like being able to keep rule screens short, it helps me keep track of what's going on. I use Alias Deny in pfBlocker so that I retain control over my pfB rules, and I put them into an interface group (see below). I use a lot of VLANs to keep things apart: separate VLANs for work, family, guests, IoT (four SSIDs on the WAP) along with more separate VLANS hard-wired devices that I don't trust or know anything about: TVs, VoIP, IP Cameras, Generator, but it is all pretty manageable for me, and helps me sleep a little better at night :)
Using interface groups, I only need one port forward for DNS and one for NTP, for all of the VLANs. My interface groups are numbered, gN_*, so that I could rearrange the order in which they run, if I want, without having to rely on the names (they run in lexical order of their names). DNS seems to run a lot and only has one rule so I gave that the first spot (g1_DNS) so that traffic gets a quick pass (not a scientific analysis, BTW). Next to run is the NTP rule in g2_NTP, followed by the pfB rules in g3_pfB, and so on.
Here are the pfB rules in my g3_pfB interface group, which consists of all LAN-side VLANS. Nobody should use these as an example of what you rulesets you should have, I'm still experimenting with pfBlocker:

ex1580

@billl Thanks for posting! I agree on the floating rules. I like to see my rules on the interface. I think my networking gear had a note though that performance starts to drop once you add more than a couple SSIDs, haha (something about interference). I currently have my network broken up into LAN which needs to communicate with other things, Guest which doesnt need to communicate with other things but uses infrastructure services (DHCP, DNS, and NTP), and a honeypot DMZ which cant communicate with anything except the internet, all on different subnets and VLANs, and the DMZ has it's own interface and cable color too just for good measure. I thought about doing an IoT network but it just isnt needed, I stick that stuff on the guest network. Simple is good! But as long as you know what's going on that's what's important.

I feel like blocklists are similar to insurance. You are going to pay for it every day but maybe someday it might save you. The trick is to find the right balance of what you are willing to pay in terms of performance. I have a very low tolerance for false positives myself and right now use blocklists from cins army which seems to update very fast, dshield which is also the honeypot I run and they do a lot of interesting research (it's funny that they do not recommend using blocklists in firewalls though), emerging threats compromised ips for the older stuff, and spamhaus drop and edrop (IDK why, should probably ditch them but the overhead is low).

billl

@ex1580 thanks for bringing up the multiple SSIDs concern. I've been meaning to drop the SSID for the work VLAN since everything can be hard-wired, and you've just nudged that effort onto the TODO list :) I think the neighbors are far enough away, but they might benefit from this also if we happen to share channels I guess (I should also see if I can turn the WAP power down some). I'll probably never feel comfortable having guests connect to a network that all the random wifi gizmos are on, but I don't want them on the family network either (as if family follows all of the rules:).

I've had little trouble with false-positives with the lists I'm using, just a handful really. I need to pay more attention to what they don't cover. I suspect that I have too much overlap, and need to make some decisions there.

ex1580

@billl I was able to restrict communication between devices using layer 2 isolation on the access points. This way devices on my guest network cant communicate with one another even if they are on the same AP (I test this regularly). That makes me feel a lot better about just sticking things on the guest network unless they need to communicate with something else.

Raffi_

@ex1580 said in What do your firewall rules look like?:

@billl I was able to restrict communication between devices using layer 2 isolation on the access points. This way devices on my guest network cant communicate with one another even if they are on the same AP (I test this regularly). That makes me feel a lot better about just sticking things on the guest network unless they need to communicate with something else.

It makes me wonder why isolation of all devices on a network is not the default for network equipment and making devices talk to each other should be something we have to configure in the few instances we actually want that. Too bad I'm not smart enough to start creating TCP/IP 2.0.

Gertjan

@home, because I trust myself :

Gertjan

@Raffi_ said in What do your firewall rules look like?:

It makes me wonder why isolation of all devices on a network is not the default for network equipment and making devices talk to each other should be something we have to configure in the few instances we actually want that.

That's exactly what's being asked by "Windows" when you hook it up to a new, unknown before, network (unknown gateway / router MAC) : Home, Business or Public. The latter limits incoming and outgoing traffic to the gateway only.

@ex1580 said in What do your firewall rules look like?:

2 isolation on the access points

@ex1580 said in What do your firewall rules look like?:

(I test this regularly)

Is wifi user A connected to AP 1 isolated from wifi user B, connected to AP 2 ?

You'll be needing on every AP something like this :

ebtables -t filter -A FORWARD -s 0:0:0:0:0:0/0:0:0:0:0:0 -d Broadcast -j ACCEPT
ebtables -t filter -A FORWARD -s 0:0:0:0:0:0/0:0:0:0:0:0 -d aa:bb:cc:dd:ee:ff -j ACCEPT
ebtables -t filter -A FORWARD -s aa:bb:cc:dd:ee:ff -d 0:0:0:0:0:0/0:0:0:0:0:0 -j ACCEPT
ebtables -t filter -A FORWARD -j DROP

This enforces that :
Any (Wifi) corrected device to the AP can broadcast (this handles the special DHCP sequence).
Any device can send traffic to the aa:bb:cc:dd:ee:ff NIC, which is the pgSense network NIC.
The pfSense aa:bb:cc:dd:ee:ff NIC can send traffic to any device - connected client or AP.
Drop the rest.

ebtables is a firewall specialized for bridging devices, like AP's - it runs on the AP.

edit : Sorry for going somewhat out of subject.
Still, the mentioned 'firewall' is important for pfSense public (captive) portal network. This firewall can not be part of pfSense when there is more then one AP involved on the same portal network, these will act as dumb wired switches.
That is, maybe I use AP's that are not expensive enough ;)

ex1580

@Gertjan I have seen on both Ubiquiti (which I have) and Cisco gear that there are options to restrict communications between devices on an AP. In my case it's in the SSID settings so it can be done for a guest network. There is a "Block LAN to WLAN Multicast and Broadcast Data" option in which you need to specify devices by MAC which are allowed to do multicast otherwise they break (chromecast). There is also an "Isolates stations on layer 2 (ethernet) level" option. Thus guest A on AP A cannot communicate with anything on AP A or AP B regardless of user. Mind you this is just for the guest network.

As for the Windows Firewall I would recommend opening Windows Defender Firewall with Advanced Security and looking at the rules. They are much more fine grained than you mention. By default Windows wants to block incoming and allow outgoing but they define that differently based on which rules are enabled for which profile. Oh, and application control. The gist of what they are trying to achieve is what you mention though. Good host rules are just as important as good gateway rules, but they are just a different thing because they can get up and move with the user.

ex1580

Here are some pretty pictures of what the guest network looks like. I made some small adjustments since the previous picture. Probably the biggest thing is logging TCP packets with SYN flag set at the bottom of the list to make logging more relevant. I then review the firewall log and add things I see a bunch of to one of the manual allow or block lists to get it out of the logs. There are less rules with the other interfaces although not as bold as @Gertjan because while I trust me I dont trust devices.

Here are the advanced options for the wireless I was talking about to isolate guests. I also have a minimum data rate requirement to facilitate roaming and prevent devices from getting stuck with a slow signal. No one want to be stuck trying to pull up navigation in the car in the driveway with only one bar, haha. No captive portal at home, I just change the password every once in a while to annoy the in-laws.

Raffi_

@ex1580 nice, good to be able to see how others do things. Gives you ideas.

I'm not fully understanding these rules with the loopback address as destination. Do those rules prevent clients from using the services mentioned in the description elsewhere? I'm guessing that has to be the loopback address of pfSense, which is itself.

Would the destination option "This firewall (self)" instead of 127.0.0.1 be the same I guess? Isn't that the same as the destination above with 192.168.30.1, assuming that is the Guest DMZ interface address.

ex1580

@Raffi_ Yeah, those are automatically created rules for my NAT redirect on those ports. The firewall rules are granting access to the instance of the service running on "localhost" (see picture). So with DNS and NTP running on localhost on pfsense in addition to the guest and LAN interfaces if someone tries to exit their subnet on those ports it will be redirected to localhost on the firewall rather than exiting the network. For example, if you have 9.9.9.9 setup as your DNS provider on your laptop and were on my guest network it will use my DNS instead of quad9 and you will never know. This lets me do filtering for phishing using a blocklist in DNSBL, although it's really a reactive way to do it but I cant find a better way without spending a bunch of money.

Raffi_

Ahh ok, cool. I probably should be doing something similar.

ex1580

@Raffi_ For this to work you might also need to block use-application-dns.net in your DNS server to prevent DNS-over-HTTPS (DoH) from accidentally bypassing your DNS server. I feel trying to stop DoH entirely is futile, but preventing the accidental bypass like this is easy. This can easily be done in DNSBL or you can create a custom zone in your DNS advanced settings like below.

server:
local-zone: "use-application-dns.net" always_nxdomain

https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet

EDIT: Updated local-zone to always_nxdomain

billl

If you have a number of interfaces/VLANs, you can put them into an interface group and reduce your port forward entries for DNS and NTP. Then also, just a single rule in each of the two interface groups to pass the translated traffic, rather than having them duplicated in every interface (or choose the "Pass" option for the associated rule).
ps. thanks @ex1580 for raising 853 (DNS over TLS), I need to look into that! Even more reason to consider using interface groups for this.

Raffi_

@ex1580 said in What do your firewall rules look like?:

@Raffi_ For this to work you might also need to block use-application-dns.net in your DNS server to prevent DNS-over-HTTPS (DoH) from accidentally bypassing your DNS server. I feel trying to stop DoH entirely is futile, but preventing the accidental bypass like this is easy. This can easily be done in DNSBL or you can create a custom zone in your DNS advanced settings like below.
server:
local-zone: "use-application-dns.net" redirect
local-data: "use-application-dns.net A 0.0.0.0"
https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet

I think I already have the prevent firefox DoH option in pfblocker. That is the main one I'm concerned with since it does that by default.