Sensitive Ports & Warnings

Mark important service ports so firewall changes are called out before you approve them. View, add, remove and verify your sensitive-port list.

Search All Documentation

One-Click documentation · Rule Engine sensitive-port configuration

What this feature does

A sensitive-port entry is a warning marker, not an active firewall rule. It does not automatically deny traffic or reserve a port. One-Click uses the list when processing supported firewall actions to draw attention to potentially disruptive changes, particularly DROP, REJECT and DELETE.

1. See which ports are sensitive

Start by listing your configured ports. This includes the built-in defaults and any additional ports registered by an administrator.

one-click engine 'sensitive-list'

Typical built-in ports include SSH (usually TCP/22, or the detected SSH service port), FTP 21, SMTP 25, HTTPS 443, MySQL 3306, Cockpit 9090 and WireGuard 51820. The exact list depends on the installed source and configuration.

2. Mark your own service ports

For example, if you have a management application on port 899 and an internal portal on port 9443, register both so future firewall changes involving those ports receive additional scrutiny:

one-click engine 'sensitive:899'
one-click engine 'sensitive:9443'
one-click engine 'sensitive-list'

The original parser also recognises several numeric values after the colon, such as sensitive:899,9443. Use one port per command if your installed revision handles only single additions reliably. These entries are numeric ports; they are not service-name aliases and do not themselves specify TCP versus UDP.

3. How warnings work

After adding a port, a normal firewall action referencing it should produce additional context. ALLOW or OPEN reports that you are exposing the service; DROP, REJECT or DELETE should be treated as critical because they may interrupt access. A warning does not mean a rule has been applied.

one-click engine --dry-run 'allow tcp 899'
one-click engine --dry-run 'drop tcp 899'

Use the namespace sandbox where supported, and read its results rather than assuming a successful dry-run proves production routing, firewalld zone precedence or IPv6 behaviour. Some versions ask whether to apply the tested rules afterwards; answer n unless you explicitly intend to change the host firewall.

Missing custom-port warning?

An older check_sensitive_ports() implementation loads the custom list but only checks the default port map before displaying warnings. If sensitive-list shows port 899 but Rule Engine does not warn for it, inspect the installed checker version. Do not interpret silence as evidence that the port is safe.

4. Remove a custom sensitive port

If a service has been retired or reconfigured, remove the custom entry, then check the list again:

one-click engine 'sensitive-remove:899'
one-click engine 'sensitive-list'

Built-in defaults are recreated from their definitions when the list is loaded. Removing a default entry is not the way to bypass its built-in warning. Removing a custom entry does not remove any live firewall rule.

5. Where the settings are stored

The parser uses a local configuration file to persist the list:

/etc/one-click/rule-engine/.sensitive.ports

You can inspect the file without changing it:

sudo cat /etc/one-click/rule-engine/.sensitive.ports

The file may not exist until the feature has written configuration. Prefer the One-Click commands to maintain the list rather than editing it manually. Protect the file as part of your server configuration backups.

6. Verify before relying on it

A practical verification is: list the sensitive ports; add a non-critical test entry; list it again; invoke a supported ALLOW or DROP dry-run and confirm the warning mentions that port; decline any live-application prompt; then remove the test entry and re-list. Confirm the installed implementation respects custom entries, not only built-in defaults.

Sensitive-port warnings complement the Rule Engine's namespace checks, transaction snapshots and rollback workflow. They do not replace any of those safeguards. If the transaction or rollback path is currently failing, do not use a production firewall change as your verification test.

← Rule Engine Guard →