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:
- Users and administrators are "inside" the organisation's network. There is no need for external connections to the management and user interfaces.
- Only port 25 (SMTP) should be exposed to the world.
- There is a single Puremessage server, with all the modules installed locally.
Even with these assumptions, the Puremessage server could be deployed in a variety of ways:
On an exposed network. This would be dangerous, as anyone could connect to the management services and attempt to login and change the configuration, or do other mischief.
On a DMZ. All services are exposed on the DMZ, and it is the firewall's responsibility to control access to them. The description of Puremessage's listening ports below may be of use in deciding on the appropriate firewall rules.
As a dual-homed host on a screened subnet. In this scenario, the Puremessage server has two network interfaces, and configuring the non-public services to only listen on the internal interface is important. It is this case that the remainder of this note concentrates on.
Listening Ports and Services
A Puremessage system listens on these tcp ports:
- 25 SMTP, postfix or sendmail
- 4466 Puremessage Blocklist Daemon
- 5432 Postgres Database
- 10025 Puremessage Mail Filter
- 10026 Postfix Listening to the Mail Filter
- 18080 Puremessage Manager
- 28080 Puremessage End-User Web Quarantine (redirects to SSL 28443)
- 28443 SSL Puremessage End-User Web Quarantine
25 SMTP
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/main.cf 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 (127.0.0.1) 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:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
# added by PostgreSQL POST_INSTALL
host all all 172.1.1.103/32 trust
host all all 127.0.0.1/32 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/pmx-database-pg.pl 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:
127.0.0.1 localhost hostname.example.com
10025 Puremessage Mail Filter
This is the mail filter server. It listens on the loopback interface (127.0.0.1) 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 (127.0.0.1) 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>
and
Listen *:28080
<VirtualHost *:28080>
and replace the "*"s with the IP address of the internal interface.
Conclusion
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.