What do your firewall rules look like?



  • 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?



  • 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
    21721cd3-5fa5-4927-ad07-e1ca38f58e7e-image.png
    LAN
    2a6b9def-1bf7-4e21-b8fb-dc2a2054692a-image.png

    OPT1
    8fab1b48-3308-453d-9ebf-07b153d516f3-image.png

    d503431c-55fb-4d57-af76-09ac86d3bbee-image.png

    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.



  • @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.
    80051548-7635-403c-8b33-84e7a43d8f1f-image.png



  • 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.



  • @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!
    6fd12761-f497-45ca-97b9-89b559c620d8-image.png
    Here is what my guest interface looks like. Feel free to comment, I may have missed something.
    1b8b7077-2018-471d-bf14-a8d450c2ed5b-image.png



  • @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:
    pfBs.png



  • @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).



  • @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.



  • @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.



  • @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.



  • @home, because I trust myself :

    18fe3844-56d9-423a-835c-8cb11e61f4ef-image.png



  • @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 ;)



  • @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.



  • 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.
    770e5996-4469-4cc5-8fec-0eca8a7d3137-image.png

    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.
    b36f5e51-3d4d-499e-9772-9efcad096be1-image.png



  • @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.
    d1d875bd-b494-4eb9-84d7-1b51725e61ed-image.png

    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.



  • @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.
    fdde25ac-a066-4b6c-ad8d-4b49b3cd2009-image.png



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



  • @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



  • 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.
    natRules.png
    g_DNS_rule.png
    g_NTP_rule.png



  • @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.



  • @billl Thanks! I looked into the groups when you first mentioned it and will keep it in mind next time I redo my rules! I didnt jump on it right way as it would be a big change from my rules for each interface. Looks nice though.



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

    server:
    local-zone: "use-application-dns.net" redirect
    local-data: "use-application-dns.net A 0.0.0.0"

    With blind trust, I have been using @jimp's recommendation of:
    local-zone: "use-application-dns.net" always_nxdomain
    though I have also seen @johnpoz using:
    local-zone: "use-application-dns.net" static

    Does it not matter what the parameter is, as long as it is not NOERROR?

    I'm curious about your local-data setting:
    local-data: "use-application-dns.net A 0.0.0.0"
    I haven't seen that one before ..


  • LAYER 8 Global Moderator

    I am currently using

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

    This needs to return NX.. So this is the easiest method to do that.



  • Thanks @johnpoz ! NXDOMAIN is the optimal response however their website lists a few other options. I will update my documentation now. https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet



  • Are any of you using a port alias to filter outbound ports? I find that for incoming traffic it's a no-brainer to filter protocol, ports, and even geoip but outgoing is another story.

    I was looking around at port filtering recommendations and while I believe that it depends on what you need, and if I was being paid to do this at home and for friends and family would certainly track down every device and app, I see people posting things like "80, 443, and 21 are all you need outbound" which I find laughable. If I did that at home I think most of my stuff would stop working (but at least I would have a web browser to search for why).

    I recently got around to adding a "allowed_ports_outbound" alias to my rules that allow internet access (this is a default deny scenario) and I feel like once you get above port 1000 it's the wild west as far as each app and service wanting it's own thing. Take for instance if I wanted to allow Zoom, Google Meet, and Skype. Sure 80, and 443 are the base requirement but give them an inch and next thing you know they want TCP nearly everything (looking at you Skype). That doesnt even take into account smart devices.

    So, as I was going from "allow all ports" to something which will make no difference but may someday make it easier to block a port, I decided to carefully filter below 1000 then not so much above that number, just knocking out a chunk of IRC in the 666X range per SANS recommendations. It's been good so far! What are you doing?

    a4217af6-6d4c-4180-8be9-e7701ab85ff1-image.png



  • @ex1580 yeah, I think you'd go crazy trying to keep track above 1024.
    Thanks for the tip about 666X - I need to look into that!

    Here are my rules for a standard user device VLAN:
    userVlanRules.png
    and here are my rules for the VLAN I use for work:
    powerUserVlanRules.png



  • @billl Looks good, thanks for sharing! In regard to your TCP port 547 for DHCPv6 this may be helpful (replace with your management address of course): https://192.168.0.1/status.php#FirewallpfFirewallRules


  • LAYER 8 Global Moderator

    You don't need any rules for dhcp.. They are auto enabled when you enable dhcp and are hidden.



  • @ex1580 @johnpoz Thank you both!


Log in to reply