I upgraded my ejabberd to 2.1.0-rc1 today and while doing so decided to start with a fresh ejabberd.cfg. This reminded me of something I noticed when I first switched to ejabberd but forgot to blog about. The default permissions in ejabberd are a bit surprising.
Before I go into details, I’m not arguing any of these problems are the end of the world but I think it would make lot of sense for ejabberd to ship with a safer configuration and allow administrators to open things up if desired.
MUC permissions
The default MUC (XEP-0045) access list is:
{access, muc, [{allow, all}]}.
This access list allows all JIDs, even those on remote servers. The default MUC configuration uses this access list for all operations.
{mod_muc [
%%{host, "conference.@HOST@"},
{access, muc},
{access_create, muc},
{access_persistent, muc},
{access_admin, muc_admin}
]},
As a result, the default configuration allows users on other XMPP servers to create rooms on the local MUC server. Probably not that big of a deal but I don’t see a good reason why my server should be hosting channels for external users. Worse, would I be responsible if the channel was used for some nefarious purpose?
I created a new access list which only allows local JIDs and used this access list for access_create and access_persistent.
{access, muc_create, [{allow, local}]}.
{mod_muc [
%%{host, "conference.@HOST@"},
{access, muc},
{access_create, muc_create},
{access_persistent, muc_create},
{access_admin, muc_admin}
]},
Pubsub permissions
The default Pubsub (XEP-0060) permissions are:
{access, pubsub_createnode, [{allow, all}]}.
Again, this allows all JIDs, even remote ones to create nodes on the Pubsub server. I changed this to the following.
{access, pubsub_createnode, [{allow, local}]}.
In-band registration
This really amazes me. In-band registrations (XEP-0077) allows users to connect to an XMPP server and create new accounts. This is enabled in the default configuration that ships with ejabberd.
{access, register, [{allow, all}]}.
I wonder how many ejabberd servers there are with unexpected users?
The solution is documented immediately above the register access list definition.
{access, register, [{deny, all}]}.
