HA XMLRPC sync cleartext password: recommendations for username?

[mfedv]

Hi,

when configuring XMLRPC sync in System / High Availability / Settings, you enter a web GUI username/password of the backup firewall. While passwords are otherwise only ever stored in encrypted form in the XML config, this one is not (as the XMLRPC push needs it in cleartext for authentication with the slave fw).

But backups of /conf/config.xml then contain a cleartext secret to the web GUI, which might compromise security if stored outside the fw box itself (e.g. a backup server) and if web GUI access is not tightly restricted to certain limited and trusted systems(*).

Is it possible to configure a user/password exclusively for XMLRPC sync use, such that it could only be used when connecting from the master fw? Then the cleartext secret would be useless to an attacker.

Regards
Matthias Ferdinand

(*) while encrypted passwords could still be guessed with offline dictionary attacks / bruteforcing, for non-trivial passwords they considerably raise the bar. Trivial passwords to intruder-accesible services would be a security threat on their own, and encryption would not help defend here.

[franco]

Hi Matthias,

Since the password is needed in order to be verified on the other side there's no other way of doing this.

You can, however, restrict the target user to only contain the "XMLRPC Library" privilege so the user won't have access to any other page but xmlrpc.php which in turn only accepts basic authentication.


Cheers,
Franco

[mfedv]

Thank you very much!

To recap:

 - Create new user at System / Access / Users (e.g. "xmlrpc")
 - do NOT add it to admins group
 - under "Effective Privileges", click Edit button
   - scroll down the long list of available privs or use search box for XMLRPC
   - select "GUI XMLRPC" privilege
   - save
 - push change to slave fw (System / High Availability / Status: "Synchronize config to backup")
 - enter the new user credentials in System / High Availability  / Settings in section "XMLRPC sync"

Regards
Matthias Ferdinand

[franco]

Hi Matthias,

Looks good, thanks for the thorough step-by-step guide.


Cheers,
Franco

[mimugmail]

Worth it to add it to the docs repo

[mfedv]

Restricting Effective Privileges is not enough. This user is still able to access /xmlrpc.php to e.g. POST a malicious config.

IIUC, from wherever (interface, client ip) the GUI is accessible, so is /xmlrpc.php, both being served from the same lighttpd instance. There are no per-client-ip restrictions in lighttpd conf for /xmlrpc.php, nor in /xmlrpc.php itself.

And due to the anti-lockout rules, both GUI and /xmlrpc.php are always accessible to anybody on the LAN interface. If you have a VPN box there, this might include all your VPN peers.

Perhaps /xmlrpc.php would better be served by a separate lighttpd instance on a different port. Access to /xmlrpc.php could then easily be restricted using standard firewall rules.

[mimugmail]

You can easily disable anti-lock out rule, and don't foget, you need to know the credentials.

[franco]

> Restricting Effective Privileges is not enough. This user is still able to access /xmlrpc.php to e.g. POST a malicious config.

But that means the attack vector is the feature itself--- I don't know how to make this more secure without rewriting the procedure.

[mfedv]

Correct, and that is what I proposed :-)

Currently a client IP can access /xmlrpc.php if it can access the web GUI.
You can't always restrict the web GUI as tightly as you would wish (e.g. password self-service)

Most HA installations will have a dedicated interface for master/slave communication, and /xmlrpc.php needs only be accessible to a) localhost and b) to the master fw on that dedicated interface.

If you limit access to /xmlrpc.php this way, the cleartext secret will be useless to an attacker.

lighttpd config syntax allows for restrictions per URL and client IP. Requires adding configurables to the GUI though.

Or you could have a separate lighttpd instance just for /xmlrpc.php and trust the fw admin to properly restrict access to it. Requires documentation effort and changes to the backends using /xmlrpc.php, perhaps as little as using a different port.

[franco]

It would be nice to have a feature request for this, but I can't make any promises at the moment:

https://github.com/opnsense/core/issues/new?assignees=&labels=&template=feature_request.md&title=

But I do agree that this sounds like a good road to improvement.


Cheers,
Franco

[mfedv]

Tried signing up at Github in several variations (all involving Tor), but they all failed. Sorry, for the time being I can't bring this as a feature request to Github.

---------------
boring details: following their troubleshooting-the-captcha link, all external captchas report success. Entering account details, I see a green checkmark at "Verify your account". When clicking on "Next: Select a plan" it reports a failed captcha (but no captcha was ever displayed). It seems that even the pros at github have difficulties binding together their own services with external ones (captcha providers) into a working logical unit.