To make your communication secure, configure your Jabber server to encrypt all traffic between the server and the clients using SSL. Other options for encryption use SASL/TSL to authenticate users securely and encrypt the traffic; however, having a dedicated port for SSL is easier to configure and is supported by most clients. Before using SSL, you must create a certificate file. Because the goal is to use Jabber internally, a self-signed certificate will be sufficient. Perform the following steps on the shell while logged in as
root to create the certificate file:
# openssl req -new -x509 -newkey rsa:1024 -days 3650 -keyout privkey.pem \ -out server.pem # openssl rsa -in privkey.pem -out privkey.pem # cat privkey.pem >> server.pem # rm privkey.pem # mv server.pem /opt/jabberd2/etc/jabberd/server.pem # chown root:jabberd /opt/jabberd2/etc/jabberd/server.pem # chmod 640 /opt/jabberd2/etc/jabberd/server.pem
The relevant configuration file for SSL encryption is c2s.xml, specifically the
<local> section. Depending on whether you would like to enable SASL/TLS, this configuration will look different. In either case, make sure to disallow unencrypted communication.
Regardless of the encryption method used, provide the location of the newly created SSL certificate file:
Encryption with SSL
First, disable the default Jabber port (5222) to ensure that your clients will not accidentally connect using an unencrypted stream. To do this, set the
port parameter to
Also make sure to enable the port dedicated to SSL connections, usually 5223:
Encryption with SASL/TLS
This method uses the default Jabber port to start an encrypted channel, so it does not need an extra dedicated port. However, it's important to ensure that this port does not also allow unencrypted connections. To accomplish this, force
jabberd2 to always use SASL/TLS by adding the following single statement to the
<local> section of c2s.xml:
Unlike with the dedicated SSL port method above, be sure to enable port
5222 when using SASL/TLS, because all communication flows through this port.
If you would like to support older clients that do not implement SASL/TLS, it might still be a good idea to enable the SSL port even when SASL/TLS is enabled on the server.
Please note that
jabberd2 now allows the encryption of communication between its server components as well. It's a good idea to configure such encryption to ensure better security.
PGP/GPG-based peer-to-peer encryption
Some client implementations also support PGP/GPG-based peer-to-peer encryption of messages. Although this is nice to have, it is insufficient security for a corporate environment. PGP/GPG-based encryption of traffic requires a lengthy configuration process on each client and is difficult to enforce. It also involves the exchange of public keys between each party that will use this encryption method. However, employees may still use such peer-to-peer encryption as an additional layer of security if they wish.
Like all servers, Jabber servers also need to be secured and tightened before going online. A few simple steps can make your server more secure. First of all, disable all unnecessary services on the server. If you're using a default install of Linux or FreeBSD, services such as HTTP, FTP, SSH, and DNS might start up automatically. If you can dedicate Jabber to its own server, it makes sense to disable these services. Furthermore, because this is a server in a corporate environment, you can use a firewall to deny access to any port on the server other than the Jabber port from all IPs outside the corporate WAN. More security-conscious companies may also block the Jabber port to the outside world if they would like their employees to use the instant-messaging system only while they are in the office. However, a Jabber server that is accessible to authorized users from anywhere in the world is potentially more useful.
Because running services on the default ports for Jabber (5222 and 5223) does not require
jabberd2 can easily run as a user with very limited privileges. Therefore it's beneficial to create a separate user for this purpose and make
jabberd2 run as this user. I like to use the jabberd user and group.
Authenticating users via Active Directory uses the username and password info passed to the Jabber server from the client, so there's no need to use a separate LDAP account for authentication. However, the script needs to use an LDAP account to connect to Active Directory and retrieve the user and roster entries. Even then, it only needs to be able to read data from Active Directory, not write to it, so a read-only user account is sufficient.
Because this solution is open only to the employees, you can disable registrations altogether. Remember, the script will import all valid users, and they will authenticate on the domain server, so there is no concept of a conventional registration process in the workflow. By default,
jabberd2 allows users to register themselves. To disable this feature, find the
<register> section in c2s.xml and comment out the