There are three protections, and they fail in different ways, so they are worth keeping apart.
The first is an address list, and by default it is empty. A fresh node answers a browser with a refusal, not with data; the manual warns about this separately, because the refusal looks like a malfunction and is not one. The level is assigned to a range with the http-access line: monitor, operator or admin, with the deny-logs qualifier for logs.
There is not a single account. A level is given to an address range, and everyone coming from it is one and the same anonymous visitor. A range with the admin level can read the configuration, replace the license, download accounting files and run a command — and no trace of who did it will remain. Levels narrow what can be done but do not make what happens traceable.
The second is encryption, and the certificate for it is generated at installation, self-signed. Browsers warn about it; it is fixed not with a configuration line but by replacing the /var/lib/pmta/webmon.pem file and restarting the monitor. The vendor names one specific consequence: Internet Explorer on Windows works very slowly with such a certificate.
The third is not a protection but an instruction: the monitor must be reachable only on the local network and not from the internet. The vendor’s wording is a warning, not advice, and it is justified: through the monitor you can see the configuration file, the license, logs, accounting files, the list of local addresses and the command execution page.
🔴 And this is worth checking on the fleet. On a fleet node the monitor port turned out to be reachable from an arbitrary machine on the internet — the 403 refusal came, but it came after the connection was established, and in the refusal body the engine named the configuration path, the log path and the line that grants full access. This is the only surface of the node where the error is not visible and can be exploited remotely.
The mechanism has no values of its own: they are set by three directives.
| What | Set by | Default |
|---|---|---|
| port | http-mgmt-port | 8080 |
| who is let in | http-access | no one |
| whether encryption is mandatory | http-redirect-to-https | true since version 5.0 |
The certificate is not a directive but a file, /var/lib/pmta/webmon.pem.
# three protections in one place: the port, the list, mandatory encryption http-mgmt-port 1000 http-access 127.0.0.1 adminhttp-access 10.0.0.5 monitor http-redirect-to-https true
what people get wrong and how it ends3 mistakes▶
§ 5.1
our experience
§ 5.1
4 relations
ConsoleThe command execution page — the very reason access levels have to be distinguished. § 5.2ConfigurationThe page shows the whole configuration file, together with all the secrets in it. § 5.6
Monitor response formatsThe same setting at another level. § 5.1The monitor's home pageAccess to the screen is decided by rights and addresses set at the node level. § 5.1LicenseAccess to the screen is decided by rights and addresses set at the node level. § 5.1Connect the node to the vendor's consoleThe mechanism the command works with. § 6.3.33How the node decides whether to let an HTTP request inThe three HTTP interfaces have the same admission rule as the monitor itself: they answer on one port. § 8.2Exposing metrics over SNMPA related mechanism: they work together. inference
curl -s -o /dev/null -w '%{http_code}\n' --connect-timeout 5 http://NODE:1000/status
3 articles
◇How the node decides whether to let an HTTP request inTwo ways to identify yourself — an access level by address and a key; the key is stronger and works from any address.◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.