First I’d like to apologize in advance if this info is easily found, but I’ve spent a week trying to find something usable both here and on the net, and in the end had to generate a set of rules myself out of what I scraped together.
The starting point is a non-networked mobile device (eg a laptop) that will be able to connect to the internet for browsing only via any medium (eg WiFi, ISP, via cable or radio) and with the absolute minimum of exposure to attack.
Now before I try this out I’d like some expert input as to potential or actual weaknesses in this rule-set.
0: Allow TCP in/out any/any 80,443,8080/80,443,8080 - for browsing
1: Allow TCP/UDP in/out any/any 53/53 - for DNS
2: Allow ICMP out any - seems not unreasonable
3: Allow ICMP in echo reply - seems not unreasonable
4: Allow ICMP in destination unreachable - seems not unreasonable
5: Allow ICMP in time exceeded - seems not unreasonable
6: Allow UDP out any/any 67/67 - for DHCP request
7: Allow UDP in any/any 68/68 - for DHCP response
8: Block TCP/UDP in/out any/any all/all - seems necessary
9: Block ICMP in/out any/any all/all - seems not unreasonable
A: Block IP in/out any/any all/all - seems not unreasonable
The basic structure of the rules you have outlined looks good. There are a few things that can be streamlined a little bit.
6: Allow UDP out any/any 67/67 - for DHCP request
7: Allow UDP in any/any 68/68 - for DHCP response
DHCP is more of a handshake protocol. The requesting client machine uses port 68, and the DHCP server uses port 67. So you'll be seeing packets going from port 68 to port 67, and from 67 back to 68. You can reduce these two rules down to the one rule: Allow UDP in/out from any to any srcport 67-68 dstport 67-68
8: Block TCP/UDP in/out any/any all/all - seems necessary
9: Block ICMP in/out any/any all/all - seems not unreasonable
A: Block IP in/out any/any all/all - seems not unreasonable
Your rule A encompasses rule 8 and 9. Protocol IP is all inclusive of Internet protocols, which covers TCP, UDP, and ICMP. You can leave out rule 8 and 9, and keep rule A, and get the same thing as you intend, as a block-all rule.
I’ll suggest adding after your rule 5, an ICMP rule to allow the ICMP “Fragmentation Needed” message. That’s part of how the protocols adjust their MTU packet settings. Without that, it’s possible for your Internet connection to apparently “freeze up” when packet sizes have to change size because of reception problems.
All in all, you’ve got a good ruleset for a secure system.
The only thing I would be careful with is a “blanket” allow rule for port 443 (actually any ports other than 80) especially with FX3 with any add-ons, unless you log/monitor them at 1st. While a supposedly secure 443 connection is needed to log on to forums like this one, I generally don’t allow an outbound 443 unless it’s needed & it doesn’t seem like much of a problem for general 'net surfing thru my wired router. When 443 is open like it is now for this forum, the 2.4 application monitor will ask me if another 443 connection tries to connect outbound to another IP, & I usually get a few attempts. One is a 443 outbound to Mozilla, which I don’t feel comfortable about & I haven’t been able to shut down since upgrading to FX3.