Contribution to OS Hosting Panel: Asking for config review

87 views
Skip to first unread message

Michael F

unread,
Mar 27, 2018, 5:10:11 PM3/27/18
to Prosody IM Users
Hi there, 

I just made a contribution to ISPConfig hosting control panel that integrates a management module for prosody servers.
After the next release of this software some more servers may run prosody managed by generated config files.

Because I am not a prosody expert it would be a huge help if you could review the configuration as it will be generated for the servers.

Config structure is as follows:
a global config file, with global module settings and options, that can be altered with ISPConfig
a storage config file with MySQL database settings generated during setup
folder for host configs for each customer

The config below shows the full offered set of features. Stuff like muc, webpresence, pastebin or anon host can be disabled for each domain and thus won't show up in the config file.

I already have one question.
The configuration as shown below activiates http and http_upload for each virtual host.
I've already read that prosody doesn't support SNI for http and thus uses the global ssl certificate for all http hosts.
So would it be better to include a Component for http_upload using the servers FQDN in the global config and add it to disco_items for each host? 



--- FILE prosody.cfg.lua

Include "/etc/prosody/storage.cfg.lua"
Include "/etc/prosody/global.cfg.lua"
Include "/etc/prosody/hosts/*.lua"


--- FILE storage.cfg.lua

storage = "sql"
sql = {
  driver = "MySQL";
  database = "db_name";
  host = "localhost";
  port = 3306;
  username = "db_user";
  password = "db_pass";
}


--- FILE global.cfg.lua

plugin_paths = {
  "/usr/local/lib/prosody/modules",
};
use_libevent = true;
log = {
  -- optional: uncomment debug log here
  -- debug = "/var/log/prosody/prosody.dbg",
  info = "/var/log/prosody/prosody.log",
  error = "/var/log/prosody/prosody.err",
  "syslog",
};
use_ipv6 = true;
http_ports = {
  5290,
};
https_ports = {
  5291,
};
pastebin_ports = {
  5292,
};
bosh_ports = {
  5280,
};
admins = {
};
modules_enabled = {
  "roster",
  "saslauth",
  "tls",
  "dialback",
  "disco",
  "carbons",
  "pep",
  "private",
  "blocklist",
  "vcard",
  "version",
  "uptime",
  "time",
  "ping",
  "admin_adhoc",
  "mam",
  "bosh",
  "websocket",
  "http_files",
  "announce",
  "proxy65",
  "offline",
  "posix",
  "websocket",
  -- community modules
  "webpresence",
  "smacks",
  "csi_battery_saver",
  "pep_vcard_avatar",
  "omemo_all_access",
};
modules_disabled = {
};

allow_registration = false;
c2s_require_encryption = false;
s2s_require_encryption = true;
s2s_secure_auth = false;
s2s_insecure_domains = {
  "gmail.com",
};

pidfile = "/var/run/prosody/prosody.pid";

authentication = "external";

archive_expires_after = "2w";

statistics = "internal";

certificates = "certs";
bosh_max_inactivity = 60;
consider_bosh_secure = true;
cross_domain_bosh = true;
consider_websocket_secure = true;

ssl = {
  key = "/etc/prosody/certs/providerdomain.de.key",
  certificate = "/etc/prosody/certs/providerdomain.de.crt",
};


--- FILE hosts/customerdomain.com.cfg.lua
--- Maximum set with all offered features activated

VirtualHost "customerdomain.com"
  enabled = true;
  authentication = "external";
  external_auth_command = "/usr/local/lib/prosody/auth/authenticate_isp.sh";
  allow_registration = false;
  registration_url = "http://info.about.registration.com";
  registration_text = "Go there";
  no_registration_whitelist = true;
  
  modules_enabled = {
    "roster",
    "private",
    "vcard",
    "blocklist",
    "pep",
    "register_redirect",
    "admin_adhoc",
    "http",
    "http_upload",
    "server_status",
    "webpresence",
  };
  disco_items = {
    {
        "muc.customerdomain.com",
        "customerdomain.com Chatrooms",
    },
    {
        "pubsub.customerdomain.com", 
        "customerdomain.com Publish/Subscribe",
    },
    {
        "proxy.customerdomain.com", 
        "customerdomain.com Bytestream Proxy",
    },
    {
        "vjud.customerdomain.com", 
        "customerdomain.com User Directory",
    },
  };
  admins = {
  };
  ssl = {
    key = "/etc/prosody/certs/customerdomain.com.key",
    certificate = "/etc/prosody/certs/customerdomain.com.crt",
  };
  server_status_basepath = "/xmppd/";
  server_status_json = true;
  server_status_show_hosts = {
  };
  server_status_show_comps = {
  };


Component "muc.customerdomain.com" "muc"
  modules_enabled = {
    "muc_limits",
    "muc_log",
    "muc_log_http",
    "pastebin",
  };
  muc_event_rate = 0.5;
  muc_burst_factor = 8;
  muc_log_presences = false;
  muc_log_http = {
    show_join = false,
    show_presence = false,
    show_status = false,
    theme = "prosody",
    uri_base = "logs",
  };
  pastebin_threshold = 500;
  pastebin_line_threshold = 4;
  pastebin_expire_after = 48;
  pastebin_trigger = "!paste";
  name = "customerdomain.com Chatrooms";
  restrict_room_creation = "local";
  max_history_messages = 20;
  admins = {
  };

Component "pubsub.customerdomain.com" "pubsub"
  name = "customerdomain.com Publish/Subscribe";

Component "proxy.customerdomain.com" "proxy65"
  proxy65_acl = {
  }

Component "vjud.customerdomain.com" "vjud"
  ud_disco_name = "customerdomain.com User Directory";
  vjud_mode = "opt-out";


  enabled = true;
  authentication = "anonymous";
  allow_anonymous_multiresourcing = true;
  anonymous_jid_generation = "customerdomain.com Guest";


--- CREATED DNS RECORDS IN ZONE customerdomain.com

anon IN CNAME xmpp
muc IN CNAME xmpp
proxy IN CNAME xmpp
pubsub IN CNAME xmpp
vjud IN CNAME xmpp



--- FILE certs/customerdomain.com.cfg

oid_section = new_oids

[ new_oids ]

# RFC 3920 section 5.1.1 defines this OID
xmppAddr = 1.3.6.1.5.5.7.8.5

# RFC 4985 defines this OID
SRVName = 1.3.6.1.5.5.7.8.7

[ req ]

default_bits = 4096
default_keyfile = customerdomain.com.key
distinguished_name = distinguished_name
req_extensions = v3_extensions
x509_extensions = v3_extensions

# ask about the DN?
prompt = no

[ distinguished_name ]

commonName = customerdomain.com
countryName = DE
localityName = CITY
organizationName = CUSTOMER NAME
organizationalUnitName = UNIT NAME
emailAddress = MAIL@ADDRESS

[ v3_extensions ]

# for certificate requests (req_extensions)
# and self-signed certificates (x509_extensions)

basicConstraints = CA:FALSE
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth,clientAuth
subjectAltName = @subject_alternative_name

[ subject_alternative_name ]


otherName.0 = xmppAddr;FORMAT:UTF8,UTF8:customerdomain.com
otherName.1 = SRVName;IA5STRING:_xmpp-client.customerdomain.com
otherName.2 = SRVName;IA5STRING:_xmpp-server.customerdomain.com

otherName.3 = xmppAddr;FORMAT:UTF8,UTF8:muc.customerdomain.com
otherName.4 = SRVName;IA5STRING:_xmpp-server.muc.customerdomain.com

otherName.5 = xmppAddr;FORMAT:UTF8,UTF8:pubsub.customerdomain.com
otherName.6 = SRVName;IA5STRING:_xmpp-server.pubsub.customerdomain.com

otherName.7 = xmppAddr;FORMAT:UTF8,UTF8:anon.customerdomain.com
otherName.8 = SRVName;IA5STRING:_xmpp-server.anon.customerdomain.com

otherName.9 = xmppAddr;FORMAT:UTF8,UTF8:xmpp.customerdomain.com
otherName.10 = SRVName;IA5STRING:_xmpp-server.xmpp.customerdomain.com

otherName.11 = xmppAddr;FORMAT:UTF8,UTF8:proxy.customerdomain.com
otherName.12 = SRVName;IA5STRING:_xmpp-server.proxy.customerdomain.com

otherName.13 = xmppAddr;FORMAT:UTF8,UTF8:vjud.customerdomain.com
otherName.14 = SRVName;IA5STRING:_xmpp-server.vjud.customerdomain.com



Michael F

unread,
May 20, 2018, 7:32:07 AM5/20/18
to Prosody IM Users
So I can consider this configuration as good?

ISPConfig is heading towards its next release and so does its prosody integration using this configuration on hundreds of servers managed with ISPConfig.
So if you have any suggestions for security or performance tweaks or for simplification or the structure of the config itself, please tell me.

Matthew Wild

unread,
May 21, 2018, 6:11:11 AM5/21/18
to Prosody IM Users Group
Hi Michael,

Sorry this slipped through the cracks!

I don't see anything completely wrong with the config, that is - it
works (but I assume you knew that already).

So inline I have left some comments, which are things I would
personally consider before putting this config into production. They
differ in severity (some are really minor). I'll try to be as clear as
possible, but if you have any additional questions then let me know.

Here goes...

On 27 March 2018 at 12:51, 'Michael F' via Prosody IM Users
<prosod...@googlegroups.com> wrote:
> Hi there,
>
> I just made a contribution to ISPConfig hosting control panel that
> integrates a management module for prosody servers.
> After the next release of this software some more servers may run prosody
> managed by generated config files.
>
> Because I am not a prosody expert it would be a huge help if you could
> review the configuration as it will be generated for the servers.
>
> Config structure is as follows:
> a global config file, with global module settings and options, that can be
> altered with ISPConfig
> a storage config file with MySQL database settings generated during setup
> folder for host configs for each customer
>
> The config below shows the full offered set of features. Stuff like muc,
> webpresence, pastebin or anon host can be disabled for each domain and thus
> won't show up in the config file.
>
> I already have one question.
> The configuration as shown below activiates http and http_upload for each
> virtual host.
> I've already read that prosody doesn't support SNI for http and thus uses
> the global ssl certificate for all http hosts.
> So would it be better to include a Component for http_upload using the
> servers FQDN in the global config and add it to disco_items for each host?

Three options here:

- Use a single upload component for all domains (so I guess
something like share.yourisp.example.com)
- Use a reverse proxy in front of Prosody such as nginx, haproxy or
Apache which is capable of SNI (this will also remove TLS handshake
load off Prosody)
- Use mod_http_upload_external with an external share service that
supports SNI (this performs the best too, and bypasses Prosody's file
transfer limit)

I don't know how feasible options 2 and 3 are if you don't have access
to what is served on customer's domains.


>
> --- FILE prosody.cfg.lua
>
> Include "/etc/prosody/storage.cfg.lua"
> Include "/etc/prosody/global.cfg.lua"
> Include "/etc/prosody/hosts/*.lua"
>
>
> --- FILE storage.cfg.lua
>
> storage = "sql"
> sql = {
> driver = "MySQL";
> database = "db_name";
> host = "localhost";
> port = 3306;
> username = "db_user";
> password = "db_pass";
> }
>
>
> --- FILE global.cfg.lua
>
> plugin_paths = {
> "/usr/local/lib/prosody/modules",
> };

Using community modules is fine, but do note that obviously, as
implied by the name, community members have direct access to this
repository. The code is not routinely reviewed by the Prosody team and
we make no guarantees for the stability or security of these modules.

By all means use them, but consider reviewing and testing the modules
you choose to use, and pinning them to a specific version. Prosody
follows symlinks when loading modules, so you may point it to an empty
directory and then add symlinks to the modules that you want to use
from the community repo.

> use_libevent = true;

Ensure that you have LuaEvent 0.4.4+ to avoid
http://issues.prosody.im/460 - note that Debian only has 0.4.3 (though
it has a bug and reports itself to Prosody as 0.4.4). You can install
0.4.4 using luarocks.

> log = {
> -- optional: uncomment debug log here
> -- debug = "/var/log/prosody/prosody.dbg",
> info = "/var/log/prosody/prosody.log",
> error = "/var/log/prosody/prosody.err",
> "syslog",
> };

The "syslog" line needs to be "*syslog" if you want log entries to go
to syslog. I'm not sure if you actually want it going to syslog *and*
to log files, but that's what this config does (or would do after that
fix). Logging documentation is here: https://prosody.im/doc/logging

> use_ipv6 = true;

If you have Prosody 0.10+ I would remove this because it's redundant.
IPv6 is always used if available, this option exists only so it can be
disabled on buggy setups.

> http_ports = {
> 5290,
> };
> https_ports = {
> 5291,
> };
> pastebin_ports = {
> 5292,
> };
> bosh_ports = {
> 5280,
> };

This looks like config for 0.8.x, which is unmaintained and definitely
not recommended for production. 0.9.x+ uses only http_ports and
https_ports. All services are available on all ports. The defaults are
5280 and 5281 respectively. See https://prosody.im/doc/http
This is a duplicate (harmless, but can be removed).

> -- community modules
> "webpresence",

This can be used to find out if anyone on the server is online without
being on their contact list. Some people don't mind this, some do.

> "smacks",
> "csi_battery_saver",
> "pep_vcard_avatar",
> "omemo_all_access",
> };
> modules_disabled = {
> };
>
> allow_registration = false;
> c2s_require_encryption = false;

Pretty much all modern (and non-modern) clients support encryption, so
it might be worth considering changing this to true.

> s2s_require_encryption = true;
> s2s_secure_auth = false;
> s2s_insecure_domains = {
> "gmail.com",
> };

gmail.com no longer federates, and since you have s2s_secure_auth
disabled, s2s_insecure_domains doesn't do anything anyway.

>
> pidfile = "/var/run/prosody/prosody.pid";
>
> authentication = "external";

mod_auth_external... I personally wouldn't want to run this in
production. It's not always reliable, and has never received a
security review (which is why we don't ship it with Prosody).

> archive_expires_after = "2w";
>
> statistics = "internal";
>
> certificates = "certs";
> bosh_max_inactivity = 60;

> consider_bosh_secure = true;
> cross_domain_bosh = true;
> consider_websocket_secure = true;

The "consider secure" options should only be used when you have a
secure reverse proxy in front of Prosody (it's not clear to me that's
the case, because you asked about SNI earlier). If you tell Prosody
that all BOSH sessions are to be treated as secure, it will happily
allow plaintext passwords to be sent in the clear over the public
internet, which is extremely poor practice these days.

cross_domain_bosh is reasonable if you want web clients from
third-party sites to be able to connect.

> ssl = {
> key = "/etc/prosody/certs/providerdomain.de.key",
> certificate = "/etc/prosody/certs/providerdomain.de.crt",
> };

Above you are using the new 'certificates' option in 0.10. I recommend
choosing one or the other for consistency, not both. Docs are at
https://prosody.im/doc/certificates

>
> --- FILE hosts/customerdomain.com.cfg.lua
> --- Maximum set with all offered features activated
>
> VirtualHost "customerdomain.com"

> enabled = true;

Redundant, as this is the default.

> authentication = "external";
> external_auth_command = "/usr/local/lib/prosody/auth/authenticate_isp.sh";

See note about mod_auth_external above. I would lean towards using a
different module that performs authentication over a more reliable
protocol and transport than line-based text over stdio. There are
many, and if you have questions about integrating with a specific
service we'd be happy to advise:
https://modules.prosody.im/type_auth.html

> allow_registration = false;
> registration_url = "http://info.about.registration.com";
> registration_text = "Go there";
> no_registration_whitelist = true;

I'm not familiar with this module (mod_register_redirect), but I
suspect allow_registration is redundant. Since it's potentially
security-relevant though, safest to leave it if everything works as it
is.

>
> modules_enabled = {
> "roster",
> "private",
> "vcard",
> "blocklist",
> "pep",
> "register_redirect",
> "admin_adhoc",
> "http",
> "http_upload",
> "server_status",
> "webpresence",
> };

Many of these are duplicates from the global modules_enabled.
Harmless, but pointless.

> disco_items = {
> {
> "muc.customerdomain.com",
> "customerdomain.com Chatrooms",
> },
> {
> "pubsub.customerdomain.com",
> "customerdomain.com Publish/Subscribe",
> },
> {
> "proxy.customerdomain.com",
> "customerdomain.com Bytestream Proxy",
> },
> {
> "vjud.customerdomain.com",
> "customerdomain.com User Directory",
> },
> };

Redundant... Prosody (since possibly forever) automatically handles
this for you. Explicit disco_items configuration is only necessary to
add services that are not direct subdomains of the main domain. All of
these are direct subdomains and Prosody will automatically include
them (in fact it's possible this configuration would cause duplicates
to be added).

> admins = {
> "us...@customerdomain.com"
> };
> ssl = {
> key = "/etc/prosody/certs/customerdomain.com.key",
> certificate = "/etc/prosody/certs/customerdomain.com.crt",
> };

The 'certificates' option would be inherited from the global section
of the config, so the same note applies about this being potentially
redundant.

> server_status_basepath = "/xmppd/";
> server_status_json = true;
> server_status_show_hosts = {
> "customerdomain.com",
> "anon.customerdomain.com",
> };
> server_status_show_comps = {
> "pubsub.customerdomain.com",
> "proxy.customerdomain.com",
> "vjud.customerdomain.com",
> "muc.customerdomain.com",
> };

I'm not familiar with this module, and haven't reviewed what data it exposes.
This should just be 'name' like all the other components...

> vjud_mode = "opt-out";

There is no "opt-out" mode. The valid modes (from a brief skim of the
source) are "opt-in" (default) or "all". Note that if you choose
"all", then all users will be searchable by default and it will also
disable the ability for users on other domains to search for users. If
you really want to allow this, set allow_remote_searches = true (and
receive thank-you cards from spammers ;) ).

> VirtualHost "anon.customerdomain.com"
> enabled = true;

'enabled' is redundant (but harmless).

> authentication = "anonymous";

> allow_anonymous_multiresourcing = true;
> anonymous_jid_generation = "customerdomain.com Guest";

These options do not exist... I've no idea what you expect them to do?

> --- CREATED DNS RECORDS IN ZONE customerdomain.com
>
> xmpp IN CNAME fqdn.of.xmppserver.providerdomain.de.
> anon IN CNAME xmpp
> muc IN CNAME xmpp
> proxy IN CNAME xmpp
> pubsub IN CNAME xmpp
> vjud IN CNAME xmpp
> _xmpp-client._tcp.customerdomain.com. IN SRV 5 5222
> fqdn.of.xmppserver.providerdomain.de.
> _xmpp-server._tcp.customerdomain.com. IN SRV 5 5269
> fqdn.of.xmppserver.providerdomain.de.

It doesn't make much of a practical difference, but you probably
intend for most of those CNAMES to be SRV instead.

You may need A/AAAA/CNAME for:

- any domains that are accessed over HTTP (e.g. for HTTP upload,
BOSH and websockets)

- the file transfer proxy (the domain used for this can be set using
the proxy65_address option:
https://prosody.im/doc/modules/mod_proxy65.html

For SRV you need _xmpp-client records for any XMPP domain that will be
logged into by clients (i.e. the main domain, and possibly anon). You
need _xmpp-server records for any domain which you want to be
accessible from other servers (e.g. all the _xmpp-client domains, plus
the services like MUC, pubsub and proxy).
Again I don't think anything uses this 'xmpp' subdomain in your setup,
but maybe I missed something.

> DNS.5 = proxy.customerdomain.com
> otherName.11 = xmppAddr;FORMAT:UTF8,UTF8:proxy.customerdomain.com
> otherName.12 = SRVName;IA5STRING:_xmpp-server.proxy.customerdomain.com
>
> DNS.6 = vjud.customerdomain.com
> otherName.13 = xmppAddr;FORMAT:UTF8,UTF8:vjud.customerdomain.com
> otherName.14 = SRVName;IA5STRING:_xmpp-server.vjud.customerdomain.com

Hope this feedback all helps. If you have any questions, let me know!

Regards,
Matthew
Reply all
Reply to author
Forward
0 new messages