Your Peace of Mind is our Commitment

Contact Us English Recent Articles

Hardening Puremessage

First published: 31st January 2012

This technical note discusses how to reduce the exposure of a Puremessage server to network attacks. Sophos Puremessage is email security security software that protects against malware, spam and data loss. This note is based upon practical experience with Puremessage for Unix version 6 running on Ubuntu 10.04.3 LTS, but should apply to other unix-like operating systems. Earlier and later versions of Puremessage may have significant differences that make the specific recommendations inappropriate. The main focus is on open listening ports.

The discussion here has benefited from information provided by Sophos technical support, but it is not endorsed or recommended by Sophos. Your environment may be different, do not implement these measures without full understanding and consideration of the potential consequences.

Network Environment

Puremessage is designed to be a gateway server, examining and passing or rejecting incoming and outgoing email messages. Therefore, it is necessary for Puremessage to listen for SMTP (port 25) connections from the world. Puremessage is modular, with parts of the system communicating with each other via tcp connections, such as the database server (actually, a third-party product in its own right). Some modules may be hosted on separate systems. For large email loads, Puremessage can be deployed on a group of servers, so that they share the load. There must be communication between the Puremessage servers to allow them to be managed as a group. Also, administrators and email users need to connect to services for configuration and management purposes.

For simplicity of the discussion, the following assumptions are made:

Even with these assumptions, the Puremessage server could be deployed in a variety of ways:

Listening Ports and Services

A Puremessage system listens on these tcp ports:


Typically, the whole point of Puremessage is to accept incoming email connections from any source, and filter them according to policy. Therefore, Puremessage should listen on port 25 on all interfaces.

If you do need to restrict this, for a postfix-based installation edit the configuration file /opt/pmx6/postfix/etc/ uncommenting and modifying the line:

inet_interfaces = $myhostname, localhost

Replace $myhostname with the IP addresses of the interfaces to listen on.

4466 Blocklist Daemon

This service rejects messages originating from IP addresses blacklisted by Sophos. It listens on the loopback interface ( by default, and there is no need to change this.

5432 Postgres Database

The database stores metadata about the system, including information about quarantined messages, lists and maps, end users and reports. In a multi-server system, the database will need to accept connections from other parts of Puremessage on different servers. In the single-server case, only local connections are needed. By default, the database listens on all interfaces.

The database is configured during installation to trust connections from relevant IP addresses. The file /opt/pmx6/postgres/var/data/pg_hba.conf defines the trust, something like this:


# "local" is for Unix domain socket connections only
local   all         all                               trust
# IPv4 local connections:
# added by PostgreSQL POST_INSTALL
host    all         all        trust
host    all         all          trust
# IPv6 local connections:
host    all         all         ::1/128               trust

Commenting out the unneeded lines (and restarting the database) will stop the database trusting those connections. However, it does not stop the database listening on all interfaces. Restricting the listening requires two more changes. In the file /opt/pmx6/postgres/var/data/postgresql.conf uncomment the line:

listen_addresses = 'localhost' # what IP address(es) to listen on;

The startup script for the database, /opt/pmx6/bin/ contains a command-line option, -i that causes the listen_addresses parameter to be ignored. In that file, look for the section:

    else {
        $status = system("$pg_cmd", @pg_cmd_args, "-w", "-o", 
                        "-i -p $pg_config{pg_port}", "-l", 
                        "$PREFIX/var/log/pg.log", "start", @opts) >> 8;

and delete the -i. The man page for postgres notes, "This option is deprecated since it does not allow access to the full functionality of listen_addresses. It's usually better to set listen_addresses directly."

Puremessage uses the server's hostname to connect to the database for report generation, so, after restricting connections to the loopback interface, it is necessary to configure the server so that the hostname resolves to the loopback interface or report generation will fail. To do this, edit /etc/hosts and add the hostname to the loopback line: localhost

10025 Puremessage Mail Filter

This is the mail filter server. It listens on the loopback interface ( by default, and there is no need to change this.

10026 Postfix Listening to the Mail Filter

The mail filter talks to postfix on this port. It listens on the loopback interface ( by default, and there is no need to change this.

18080 Puremessage Manager

This is the port for SSL connections to the Puremessage Manager web interface. There is currently no way to restrict the interfaces it listens on.

28080 and 28443 Puremessage End-User Web Quarantine

28443 is the secure (SSL) connection to the end-user web quarantine manager, and 28080 simply redirects to 28443. It only needs to listen on the "internal" interface. The quarantine manager is actually an Apache webserver, and the configuration file is /opt/pmx6/etc/manager/httpd2/ssl/http.conf, find the lines:

Listen *:28443
<VirtualHost *:28443>


Listen *:28080
<VirtualHost *:28080>

and replace the "*"s with the IP address of the internal interface.


These configuration changes reduce the potential attack surface of a Puremessage server on the internet. It could be said that these changes are unnecessary, because the services involved are all well-designed and robust, but general principles of good security include least privilege and remove unnecessary services.

Related Articles