How to prevent Firefox and Chrome from opening ports in the firewall?
One option would be to use Windows access controls to prevent changes to the firewall rules. If you first set the rule to Disabled (or simply deleted it), and then changed the ACLs on the firewall rule storage, it should be possible to avoid the rules re-appearing. While any administrator account could overwrite or bypass your modified ACL, it is highly unlikely that an automated installer would endeavor to do so, and consequently the attempts to change the firewall would simply get "Access Denied".
The good news is that the firewall rules are stored in a predictable location, HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules. They are even entirely human-readable, aside from their names, which are GUIDs; the actual rules are pipe-delimited English text (I am now curious what happens if I make a firewall rule with a pipe character in its description).
The bad news is that the rules are stored as values on a single key (the one given above), and registry ACLs are only available at the granularity of keys. This means that if you deny an account write access to that key, you deny that account the ability to change any firewall rule. This could impair functionality in a number of ways; in the extreme, you would need to manually change the ACL on that key before making any firewall rule changes yourself.
The ideal way to do it would be to use a Deny access control entry for the account that you want to block. Deny entries take precedence over Allow entries for a given specificity level (if an account is both allowed and denied an action, deny wins), and specific (account) similarly wins out over generic (Group). Thus, you can add a Deny entry for a specific account to block that account, without also doing something awkward like blocking the entire Administrators group. Unfortunately, all four Mozilla- or Google-related services installed on my machine (MozillaMaintenance, GoogleChromeElevationService, gupdate, and gupdatem) are configured to run as LocalSystem (a.k.a. SYSTEM). Blocking SYSTEM write access to that key might not be disastrous - in fact, blocking SYSTEM from writing to select registry keys is a common way to keep an admin from making specific changes to a machine via Group Policy - but it would probably break some things. If you end up needing to block actions which are elevated via normal UAC you would need to block either yourself or the Administrators group, and that's even more awkward than blocking SYSTEM.
A solution would be to create a new admin-level service account on the machine, and then modify the Google & Mozilla services to use that account and block that specific account at the registry key. This is not trivial - especially if the services rely on any of the special permissions of being SYSTEM, which by default even the Administrator account does not get all of (though this can, of course, be changed) - but it could be done.
You could also try removing the browsers (and any associated services, manually if needed) and re-installing them using unprivileged installers. This would limit their installer blast radius to your local account, and give them no way to elevate unprompted. Firefox supports portable installs, and Chrome actually used to by default install to your user profile (not your Program Files directory) using a per-user install, so in theory it should be possible to install either one without giving the installer admin rights. Nothing without admin rights can create a way to get admin rights (without a UAC prompt or an EoP vulnerability), so they would not have the ability to silently mess with your firewall, and they would probably not even try (after all, a program installed without Admin can be updated without Admin, and a non-Admin can't change the firewall).
You have reached one limit on computer security. Best practices ask to only allow elevated priviledges for so called trusted programs. But we all know that for common usage, we have to trust the OS and the browser(*). The problem that your are facing is that is one of this products does something that you do not like, little can be done: once you have allowed elevated priviledges, the system offers no additional protection.
I can hardly imagine a truely preventive strategy here because it is hard to guess what an installation procedure could do, and I know nobody that could say that they can detect and understand any change on a windows system. But when one problem has been identified, workarounds are often possible. Here I can imagine:
- group policies as you said. BTW, if you have many client machines, you should really considere using AD. You do not even need a AD server license for that because recent versions of SAMBA provide it. And AD can really add a lot when it comes to client machine security
- automate the process of detecting/resetting the firewall rules. Once automated it will appear as an additional step of the browser upgrade
- use a dedicated firewall (a dedicated machine) and implement the firewall rules there.
- maybe others I could not imagine...
Which one will be the more relevant will heavily depend on the real use case...
The best way would be to ask the editors to stop silently opening firewall rules, but I am afraid that this request is unlikely to succeed: there are certainly good reasons for those rules. That is the reason why I only searched for workarounds.
I do not mean here that the browser will run with evelated proviledges, but every updgrade does requires them. And for security reason we cannot use outdated software...