AMP icon indicating copy to clipboard operation
AMP copied to clipboard

FR: Create/Maintain AMP Firewall Rules via CLI/WebUI above current abilities

Open southnode opened this issue 1 year ago • 2 comments

This is not for requesting support for new games/applications

To do this you should go to https://github.com/CubeCoders/AMPTemplates and first attempt to build a configuration yourself - otherwise you can request a template from this repo.

Feature Request

Add the ability to add ports/firewall rules via the CLI, and have them stick to an instance.

Feature Information:

I confirm:

  • [x] that I have searched for an existing feature request matching the description.

This would be an addition to the ports changes, wherein we need the ability to actually update a template, and have those port changes work (say for example with satisfactory lately). But, that being said, there are some cases where we need the ability to, in some circumstances, add an additional firewall exception to add additional connectivity.

For example, the original Satisfactory template did not include a TCP exception in the firewall - the template was amended to be both UDP and TCP, however this was not able to be superimposed on existing templates. Thus operators would have to manually create a firewall rule outside of AMP, that was not controlled by AMP. Or additionally for example AMP does not create :80 or :443 exceptions for ADS01 on the firewall - whilst this isn't the case 100% of the time wherein that is the ingress point, it would be great for AMP to be able to handle this itself in the case of a restart, so that all things will be "as they should be".

Suggestion

Allow a CLI command to add additional rules tied specifically to an instance, and; Allow a flag to be placed in the comment section of IPTables rules so that the AMP Firewall sync doesn't kill it when it checks and sees a firewall rule that doesn't match to an existing instance configuration.

Example:

ampinstmgr firewall-add [-force] [-persistent|-tied|-ephemeral] [Instance] [port|portname] [tcp|udp|both] [-comment ""] For this example we'd have a -force argument which would do the addition even if the port already had a firewall exception (prevents potentially AMP going "well I already have a port argument here, go away". The second switch is either -persistent (which will make the rule always, such as for wanting ports 443 or 80 open all the time for ADS, -tied for if it's tied to a specific instance and should be added/removed as per normal when an instance is deleted, or -ephemeral which is basically a temporary firewall addition that won't maintain itself if the system restarts. An instance flag for if -tied is used, a port flag which will take either a port number, or the name of the port given to an instance, and then the normal tcp udp or both flag. Comments are additional comments at the end.

The above could be used in the following way

ampinstmgr firewall-add -persistent 80 tcp -comment 'HTTP for ADS01' ampinstmgr firewall-add -persistent 443 tcp -comment 'HTTPS for ADS01' ampinstmgr firewall-add -tied Satisfactory01 7777 tcp

Which would add good functionality for administrators.

Additional Example/Functionality

Additionally this could also open up the doors to firewall managers within the WebUI using an API call that specifically needs the -tied flag with portname specified. Doing so could open the door to blocking IP's from ports in a self-serve manner for users. The same call could substitute port|portname for an IP address and instead of being --dport for IPtables for example, it instead uses -s as the IP source. Have a limit (settable by the administrator as a flag for an instance) that it can have x amount of rules.

southnode avatar Sep 21 '24 04:09 southnode

The real solution is for the generic module to finally support changes to template ports being applied to existing instances.

Though if you add custom ports to an instance, firewall rules will be created for them. Doesn't that achieve what you want (for the most part)?

Greelan avatar Sep 21 '24 04:09 Greelan

Well, yes that'd be the solution there.

Yes, that'd achieve it.

But, for instances where the template can't be changed, won't be changed, takes too long to change, or needs an immediate fix (or even a bespoke fix), this would be a boon. Allows a little more extensibility.

southnode avatar Sep 21 '24 04:09 southnode