Scalix and Security

Exclusive offer: get 50% off this eBook here
Scalix: Linux Administrator's Guide

Scalix: Linux Administrator's Guide — Save 50%

Install, configure, and administer your Scalix Collaboration Platform email and groupware server

$23.99    $12.00
by Markus Feilner | March 2009 | Linux Servers Open Source

The standard setup of the Scalix server may be satisfactory for most installations, but if you are running Scalix on an internet site or if your local server is available from the Internet, extended security measures have to be taken. In this article by Markus Feilner, we will deal with several recommendations that make your Scalix server safe—like minimizing the number of services running and listening. We will set up a firewall which allows the Scalix users to connect to. After that, we will set up Stunnel to provide SSL-encrypted Scalix services. Then, we will use OpenVPN to protect the server. Last but not least, we will have a look at the services running and discuss advanced possibilities of securing the server.

Basic Security and Firewalls

An administrator installing a Scalix server in a productive environment must make some considerations before setting up his system:

  • Is the server accessible from the Internet?
  • Is the server accessible to untrusted users?
  • Who must access Scalix? Who must access administration?
  • Who must be prevented from gaining access?
  • Which services must be accessible from where?

Though this may sound theoretical, such thoughts always play an important role when you are planning any productive server. In most cases, there are only three different setups for a groupware server:

  • There are only local users in the company's network and the server is located in the company.
  • There are local users and remote users connecting to the Scalix server located in the company.
  • There are both local and remote users connecting to the Scalix server located on the Internet.

While the installation leaves a perfectly configured system that is stable, there are several possible precautions that should be taken when your Scalix server is accessible from the Internet — the access should be controlled by a firewall, connections should be encrypted, and users must be forced to use strong authentication mechanisms. As always, there are several ways to achieve this.

Before we start, here is a list of services that have to be available for Scalix users accessing the server remotely:-

  • SSH: TCP port 22, the standard remote administration for the admin.
    • SMTP: TCP port 25 — Sending mail.
    • IMAP: TCP port 143 — Retrieving mail with the IMAP protocol.
    • POP: TCP port 110 —  Retrieving mail with the POP protocol.
  • HTTP: TCP port 80: Accessing the Web interface.
  • Scalix UAL uses port 5287
  • And as of 11.3, secure UAL connects over 5767

Linux Firewall Terminology

Basically speaking, a firewall is a piece of software that controls internet connections to and from a server. SUSE's Linux systems come with a built-in firewall named SUSEfirewall that can easily be configured with YaST. On Red Hat Linux systems, there is Bastille and firewall GUIs like Shorewall, which are all good choices for any Linux system. All common Linux firewalls are based on iptables or its predecessor ipchains. Its concept is pretty simple: the administrator defines a chain of rules that are worked through by the operating system one after another for every incoming or outgoing connection or package. So-called targets define what to do with packages matching the rule specified. Targets may be, for example, Accept, Reject, Drop or Log. Furthermore, there are policies that define the default behavior for connections where no rule matches. The Linux program iptables controls these rules. A little glance on this tool may help understanding how a Linux firewall works.

iptables—the Standard Linux Firewall Tool

iptables (http://www.netfilter.org) is a simple command-line tool that controls the kernels' IP tables. In these tables, rules that define how network packets are treated on this system can be stored. As always, the simple commands offer the best solutions when they are combined with an abundance of options. There is a vast amount of options and extensions for iptables, so this short description is far from perfect and far from complete.

The iptables syntax is very simple:

iptables <rule command> <chain> <matching extensions><target>

A typical rule command is A, which means Add the following rule. Since iptables use different chains (by default, INPUT, FORWARD, OUTPUT), we must declare a chain where this rule is to be added to. The following table shows three examples:

Iptables Command

Function:

iptables -A INPUT <rule>

Adds a rule to the INPUT chain, which affects all incoming packets heading for the firewall itself.

iptables -A OUTPUT <rule>

Adds a rule to the FORWARD chain, which affects all packets that are supposed to be forwarded by the firewall.

iptables -A FORWARD <rule>

Adds a rule to the OUTPUT chain, which affects all outgoing packets originating from the firewall.

Another typical command is -P that sets the default policy for a chain. This should always be set to DROP, because then all packets arriving in this chain are dropped if not specified explicitly by another rule. This is the only way to make sure that only the traffic allowed by us is handled and any unspecified traffic is dropped.

A typical example for this is:

scalixbook:~ # iptables -P FORWARD DROP
scalixbook:~ #

This would prevent your system from forwarding any traffic, unless specified otherwise, later on.

Then there are iptables' targets. A target can be either DROP, REJECT or ACCEPT (among others) and is invoked by the switch — j. Furthermore, so-called "matching extensions" are like a filter specifying exactly which packet is meant.

Thus a rule like iptables -A INPUT <matching extension> -j DROP  means: Drop every packet that is headed for my firewall and matches the <matching extension>.

Matching Extension

Meaning

-i <interface>

The incoming interface of the datagram

-o <interface>

The outgoing interface of the datagram

-p <protocol>

The IP protocol of the datagram

--dport <destination port>

The destination port of the datagram

--sport <source port>

The source port of the datagram

-s <source IP>

The source IP of the sender

-d <destination IP>

The destination IP of the recipient

There are many other matching extensions, but these here should be sufficient to understand the basics of iptables. Have a look at these lines:

#!/bin/bash
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 143 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 143 -j ACCEPT
(...)

Do you already understand them? If you do, congratulations; if not, don't worry, it's easy. These lines represent a shell script that can be used to start a very simple firewall example. iptables is a command-line tool and therefore is simply called from a script with parameters like the following:

Command

Meaning

iptables -P INPUT DROP

Drop all incoming packets that are not specified by any other rule

iptables -P OUTPUT DROP

Drop all outgoing packets that are not specified by any other rule

iptables -P FORWARD DROP

Do not forward any packets that are not specified by any other rule

iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

Accept TCP connections for port 22 (SSH) coming in on network interface eth0

iptables -A INPUT -i eth0 -p tcp --dport 25 -j ACCEPT

Accept TCP connections for port 25 (SMTP) coming in on network interface eth0

iptables -A INPUT -i eth0 -p tcp --dport 143 -j ACCEPT

Accept TCP connections for port 143 (IMAP) coming in on network interface eth0

iptables -A OUTPUT -o eth0 -p tcp --sport 22 -j ACCEPT

Accept outgoing TCP connections for port 22 going out on network interface eth0

iptables -A OUTPUT -o eth0 -p tcp --dport 25 -j ACCEPT

Accept outgoing TCP connections for port 25 going out on network interface eth0

iptables -A OUTPUT -o eth0 -p tcp --dport 143 -j ACCEPT

Accept outgoing TCP connections for port 143 going out on network interface eth0

Scalix: Linux Administrator's Guide Install, configure, and administer your Scalix Collaboration Platform email and groupware server
Published: April 2008
eBook Price: $23.99
Book Price: $39.99
See more
Select your format and quantity:

In a nutshell:

  • eth0 is the external interface, where all traffic except SSH and mail services will be dropped.
  • SSH Remote Administration is allowed via Port 22.
  • SMTP Mail Services are allowed via Port 25.
  • IMAP Mail Services via Port 143 are allowed.

The NIC eth0 is the external interface where all traffic except for TCP Ports 22 (SSH), 25 (SMTP), and 143 (IMAP) will be dropped. With this setup, clients could access the Scalix server for sending and retrieving mail. If you want to allow Web access, you will need to open TCP ports 80 (http), and 443 (https). Remember that for any service you want to allow, you have to add several iptables rules. The above example is only rudimentary. There are lots of other options that may be necessary for your system.

If you need more information, the manual page of iptables is the best place to look for help.

The SUSEfirewall

On SUSE Linux, there is a very sophisticated firewall solution named SUSEfrewall2 (http://www.netfilter.org) with an administration GUI embedded in YaST. The big advantage of this system is that the administrator only needs to understand basic firewall concepts, and nevertheless is able to configure his system, at least, with a minimum security setup.

Start YaST on your SUSE Linux system and change to the Firewall module, which can be found in Security and Users. You can invoke this module by simply typing yast firewall at the command line:

 

Scalix and Security

The YaST firewall setup is very straightforward. In the left part of the window, we can select the dialogs to be set up for the interfaces, services, and some special features like logging, etc the parameters and options for these features are entered in the right part of the window. The following list will give a step-by-step configuration:

Let the SUSEfirewall start on boot time. Activate the When Booting in Service Start.

  • Change to the entry Interfaces in the left part of the window. Look up the MAC addresses of your network cards; double-click them in the interface list, and select the proper entry from the drop-down menu Interface Zone. Here, we must define our internal and external network devices. If there is only one, define this as the external interface.
  • Click on the entry Allowed Services in the list on the left. Select External Zone in the drop-down menu, Allowed Services for Selected Zone and SSH from the drop-down menu, Service to Allow. Click on the Add button to confirm your changes. Now SSH access on the external interface is permitted. 

    Scalix and Security

  • Repeat this step for SMTP, IMAP, and HTTP to open mail and Web services for the Scalix users.
  • Add any other services if you need to access them. For Outlook Clients Ports 5729/TCP and 5757/UDP will be needed. You can enter any port with YaST's Advanced firewall configuration dialog.
  • Click on OK to close this window and on the button Next to finish SUSEfirewall setup. Check the settings displayed and click on Accept twice.

Now we have the SUSEfirewall configured to deny any access via the external interface except SSH, mail, and Web services. If you do not want to reboot and have your firewall start at once, type rcSuSefirewall start. You can control the ruleset with iptables -L, but don't be surprised the SUSEfirewall establishes quite a complex, and pretty safe firewall on your system.

For advanced configuration, there is a config file named /etc/sysconfig/SuSEfirewall2 where you can enable logging, and define an external iptables script. Enter the name of the script in the variable FW_CUSTOMRULES. By default, this entry is in comments and points to the well-documented template script /etc/sysconfig/scripts/SuSEfirewall2-custom. It is a very good idea to read the two files /etc/sysconfig/SuSEfirewall2 and /etc/sysconfig/scripts/SuSEfirewall2-custom, because the abundance of comments gives a thorough understanding of the concepts of the SUSEfirewall.

Securing Scalix with OpenVPN

If you have external users who you want to grant access to your Scalix system, a Virtual Private Network software may be a convenient way to do so. With a VPN, all traffic between the local client and the remote system is encrypted once the tunnel is set up. Though there are many VPN technologies available, OpenVPN (http://openvpn.net) seems to be the most interesting one, because it is free, open source, safe, transparent, compatible, and available for every platform. And it's very easy to set it up. The easiest setup would be providing a configuration file and an encryption key like a long passphrase to every user, that is supposed to have access to the VPN server. This method is perfect for a quick setup with only two or three users, but in a groupware scenario with many notebooks or home workers, certificate-based VPN-management suits much better.

The general scenario looks like this: A VPN server (we will use the Scalix server for that) accepts encrypted connections on a specified port. Encryption and configuration parameters are copied to all clients that shall connect. Furthermore, when a client establishes the VPN tunnel, a sophisticated authentication procedure is taking place. In our first example, the client would only send the key (a passphrase) and the server would grant access if the passphrase is valid. The better setup includes an encrypted handshake, where the server and clients authenticate each other with x509 certificates. These are far longer than a passphrase, and because the authentication mechanism and encryption is much more complex, this method is also more secure. Furthermore, the administrator holds a list of valid certificates and is able to lock out single users or machines. For example if a laptop is stolen, Key Management software lets him create and delete certificates at a mouse click.

In this scenario, the administrator has to do a little work to connect a client to the Scalix server:

  • Install OpenVPN on the server.
  • Create a suitable configuration for the server.
  • Generate server certificates.
  • Create client certificates and configuration.
  • Roll out OpenVPN, configuration, and certificates to the clients.

The first step is the easiest: Type yast -i openvpn or select OpenVPN from your installation source. This installs the OpenVPN software, documentation, and sample configuration files. A suitable server configuration file for use with certificates may look like this:

port 21
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
server 10.10.10.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 3

Place a file like this in /etc/openvpn/ and name it something like server.conf. Upon start, OpenVPN will look for .conf files in this directory and start the tunnels defined in these files. The following table gives an overview of the meaning of each of the configuration parameters specified above.

Openvpn parameter

Function

port 21

Openvpn connection will be setup over port 21. make sure this is open in your firewall. We are using port 21 (FTP) because this is open per default in most outgoing firewalls.

proto tcp

Openvpn can use TCP or UDP connections.

dev tun

The network device used will be called tun0 and uses the TUN driver.

ca ca.crt

cert server.crt

key server.key

The locations of the certificates the server will use, relative to "/etc/openvpn/".

server 10.10.10.0 255.255.255.0

This is the IP of the virtual subnet the tunnel partners are about to use. The VPN machine shall run as a VPN server.

ifconfig-pool-persist ipp.txt

The server assigns IPs to the clients. In this file he stores the IP, so that a client will mostly have the same IP.

keepalive 10 120

Every 10 seconds the server checks if the tunnel is up. If it has not receieved an answer for 120 seconds, the server will try to reestablish the tunnel.

comp-lzo

Openvpn uses sophisticated, adaptive LZO compression.

status /var/log/openvpn-status.log

log-append  /var/log/openvpn.log

verb 3

Logs the status and the general protocol to the specified files. Log Level is defined with "verb", allowed range is from 0 (no logging) to 9 (very verbose).

 

On the VPN client, a configuration like the following is required:

client
dev tun
proto tcp
remote scalixbook.org 21
resolv-retry infinite
ca ca.crt
cert mfeilner.crt
key mfeilner.key
comp-lzo
verb 3

Openvpn client parameters

Function

client

This machine is a VPN client that has to connect to the server.

dev tun

The network device used will be called tun0 and uses the TUN driver.

proto tcp

Use TCP connections.

remote scalixbook.org 21

This parameter specifies the VPN server and Port to use.

resolv-retry infinite

The client will try endlessly to set up a connection, regardless DNS failures.

ca ca.crt

cert mfeilner.crt

key mfeilner.key

The file names of the certificate files.

comp-lzo

The client uses compression, too.

verb 3

The client has a log level of 3.



Scalix: Linux Administrator's Guide Install, configure, and administer your Scalix Collaboration Platform email and groupware server
Published: April 2008
eBook Price: $23.99
Book Price: $39.99
See more
Select your format and quantity:

Generating Certificates

In the next step, a set of certificates have to be created for which we need:

  • A certificate for the Certificate Authority. This authority is the common ground, on which all client and server certificates are built. It is stored in the file ca.crt and must be copied onto every machine involved.
  • A server certificate and key for each machine involved. On the server, this is called server.crt, whereas we used to call the client file by the name of the user or client machine (mfeilner.crt)

The files ending in .key are secrets and should be handled with great care, because here are the keys identifying your client. Creating these client certificates and keys is a two-step-process: first, a certificate is created ,which then needs to be signed by the CA. Don't worry: OpenVPN comes with several scripts that create these certificates for you. The toolbox is called easy-rsa and resides in the easy-rsa subdirectory of the OpenVPN installation.

I recommend reading the documentation of easy-rsa and following these steps:

  • Edit the vars file, entering your company's parameters.
  • Build the Certificate Authority file. Run build-ca to create it according to your company's data. With this file, you can create more client certificates for your VPN machines.
  • Run build-key-server and build-key-client to generate certificates for your machines.

For each client, you should now have four files: a client configuration file client.conf, a CA certificate ca.crt, a client certificate client.crt and a client key file client key. Rename the .conf configuration file to .ovpn if you are using a Windows client.

A very sophisticated tool to administrate your certificates for Linux users is tinyca (http://tinyca.sm-zone.net). If you're running Windows or a Mac, xca (http://xca.sourceforge.net) may be the program for you.

VPN Client Access to the Server

All you have left to do now is: initial OpenVPN on the client, copy the configuration file and the certificates to the client's OpenVPN configuration directory, and start OpenVPN. For Windows and Mac, there is graphical software available, on Linux there are runlevel scripts called /etc/init.d/openvpn

Once successfully started, OpenVPN adds a new network device on the machines involved, called tun0. In our example, the clients will have addresses in 10.10.10.0/32, whereas the server has 10.10.10.1. All mail services like IMAP, SMTP, and POP of the Scalix server are now available only to the VPN clients on the tunnel interface, with the IP 10.10.10.1.

Now, we can change the firewall configuration on the server, shutting down external access to SSH only, at the same time allowing access to all Scalix services from the VPN. We can do that with YaST, but it's faster to edit these two lines in

/etc/sysconfig/SuSEfirewall:
(...)
FW_SERVICES_EXT_TCP="ssh"
(...)
FW_DEV_INT="tun0"
(...)

In our iptables example script above, you would need some lines that only allow SSH from outside and everything from the VPN:

#!/bin/bash
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -j ACCEPT
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A OUTPUT -o tun0 -j ACCEPT
(...)

Setting Up a Web Proxy

However, if you need the web administration console and the SWA, there is still a little work to be done. Unfortunately, the Tomcat connector listens by default only on the external interface, not on tun0. We could change that in the Scalix-Tomcat connector configuration and configure the Apache for the tunnel interface only, rewriting access with mod_proxy; but this would be lost after every Scalix update. It's easier to install a Web Proxy on the Scalix server. yast -i squid or yum squid installs the mighty Squid proxy (http://www.squid-cache.org). Only three settings in its configuration file /etc/squid/squid.conf need to be adapted:

Uncomment # http_port 3128 to make the proxy available to your VPN, and the two lines:

acl vpn src 10.10.10.0/255.255.255.0
(...)
http_access allow vpn

The latter one needs to be added at the very beginning of the http_access definitions. Make sure that you do not allow port 3128 for external connections in your firewall. Once you enter the proxy URL 10.10.10.1, port 3128 in your browsers connections tab, you will be able to access the Scalix web admin and webmail. Without the tunnel and the proxy, this is impossible. Pretty safe, isn't it?

Stunnel

If you consider the setup of openVPN as oversized, there are some other solutions that may be suit your need. Because all Scalix versions before 11.3, unfortunately, do not allow SSL/TLS encryption of its mail services, a workaround has to be found. Scalix encourages the use of the program Stunnel (http://www.stunnel.org) for redirection and encryption of mail connections. For example, a configuration like:

accept = 995
connect = 110

in its configuration would redirect SSL/TLS encrypted connections to port 993, (the standard POP3S port) to the unencrypted POP3 port 110. Thus, we can allow only connections to ports 993 (POP3S), 993 (IMAPS), and 465 (SMTPS) from our clients and internally redirect them to the local ports 110, 143, and 25. The firewall configuration could then be arranged to allow only the secure ports, while Scalix is running unencrypted. Don't close your SMTP port 25 in your firewall, if your Scalix server might receive Internet mail by SMTP via its DNS entry.

Installing Stunnel is easy: yast -i stunnel or yum stunnel installs the software, and the configuration file in /etc/stunnel/stunnel.conf only needs these entries:

[pop3s]
accept = 995
connect = 110
[imaps]
accept = 993
connect = 143
[ssmtp]
accept = 465
connect = 25
(...)
cert = /etc/stunnel/stunnel.pem

The last line specifies the SSL certificate Stunnel is supposed to use for encryption. This file can be built with the OpenSSL tools in /usr/share/ssl/certs — Enter a simple make stunnel and follow the instructions. The "common name" entry in this certificate must be the full-qualified hostname of your server, if you don't want to run into any problems.

Securing Scalix with https Redirection

Stunnel helps with SSL/TLS encryption of mail services. Enabling https web service is a little more tricky. Depending on the platform you are using, Scalix may or may not automatically use https. For example, on Red Hat Enterprise Linux, https seems to be the default. However, this is not the case with SUSE and other systems. Once you have your system up and running, it might be a very good idea to restrict access to both webmail and administration console to connections using the secure https protocol.

Please note that the following how to proved to be very tricky, and maybe it will not work at all on future releases or untested environments. Also, know-how of the Apache2 Web server (http://httpd.apache.org) and the Tomcat application server (http://tomcat.apache.org) configuration is needed. We have tested the following procedure on open SUSE 10.1, using various Scalix 11 versions. Unfortunately, because these changes are so deep in the Scalix-Tomcat and Apache configuration, an upgrade of Scalix will almost certainly kill this setup. Nevertheless, the work we are going to do here gives you an insight in how the web server and Tomcat on a typical Scalix system work together, and how you can adjust and restrict access for your users. Needless to say, back up all files edited in the following process and don't try it on a productive system before you have had success on a test system and know what you are doing.

  • Create a SSL Key for Tomcat with:
    /usr/java/jre1.5.0_06/bin/keytool -genkey -alias tomcat -keyalg RSA
  • When asked, use change it as a temporary password (this is specified in the Scalix-tomcat connector configuration).
  • Edit /var/opt/scalix/sx/tomcat/conf/server.xml, beginning with line 82 to the following:
    <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
    <!--
    <Connector port="8080" maxHttpHeaderSize="8192"
    maxThreads="150"
    minSpareThreads="25"
    maxSpareThreads="75"
    enableLookups="false"
    redirectPort="8443"
    acceptCount="100"
    connectionTimeout="20000"
    disableUploadTimeout="true"
    URIEncoding="UTF-8" />
    -->
    <!-- Note : To disable connection timeouts, set connectionTimeout
    value to 0 -->
    <!-- Note : To use gzip compression you could set the
    following properties :
    compression="on"
    compressionMinSize="2048"
    noCompressionUserAgents="gozilla, traviata"
    compressableMimeType="text/html,text/xml"
    -->
    <!-- Define a SSL HTTP/1.1 Connector on port 8443 -->
    <Connector port="8443" maxHttpHeaderSize="8192"
    maxThreads="150"
    minSpareThreads="25"
    maxSpareThreads="75"
    enableLookups="false"
    disableUploadTimeout="true"
    acceptCount="100"
    scheme="https"
    secure="true"
    clientAuth="false"
    sslProtocol="TLS"
    URIEncoding="UTF-8" />
    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="8009"
    address="scalixbook.org"
    enableLookups="false"
    redirectPort="8443"
    protocol="AJP/1.3"
    URIEncoding="UTF-8" />
    (...)

    These changes make Tomcat listen for encrypted connections. You may now restart Scalix with /etc/init.d/scalix restart; restart Tomcat only with /etc/init.d/scalix-tomcat restart or do a reboot. Test success of your changes with lsof -i :8443:

    scalix:~ # lsof -i :8443
    COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
    java 1739 root 10u IPv4 4950 TCP *:pcsync-https (LISTEN)
    scalix:~ #

    Or point your Browser to https://scalixbook.org:8443, replacing scalixbook.org with your server name. You should receive the Tomcat testpage. Add /sac to the URL and you will see the Scalix admin console.

Configuring Apache2 for SSL Redirection

While we have successfully configured Tomcat, we now have to prepare Apache for http redirection to https, so that users addressing http are automatically redirected to https. For this purpose, Apache also needs a SSL certificate:

  • Create a TLS/SSL key:
    openssl req -new -x509 -newkey rsa:1024 -days 3650 -keyout 
    privkey.pem -out server.pem
  • Remove the passphrase:
    openssl rsa -in privkey.pem -out privkey.pem
  • Merge private key and public key into a single file.
    cat privkey.pem >> scalix-apache.pem
  • Copy this file to /etc/ssl/cert/.
  • Make Apache listen on port 443, too: Add listen 443 to the Apache's config file listen.conf.
  • Add the mod_rewrite module by adding rewrite to this line in your server's config in /etc/sysconfig/apache2:
    # Added by Scalix installer: proxy proxy_ajp deflate
    APACHE_MODULES="actions alias auth_basic authn_file authz_host
    authz_groupfile authz_default authz_user authn_dbm autoindex
    cgi dir env expires include log_config mime negotiation setenvif
    ssl suexec userdir php5 proxy proxy_ajp deflate rewrite"
  • Edit the file /etc/opt/scalix-tomcat/connector/ajp/instance-scalix.conf:
      <VirtualHost *:80>
    Include /etc/opt/scalix-tomcat/connector/ajp/app-scalix.*.conf
    <LocationMatch "^/sac/*">
    RewriteEngine on
    RewriteRule ^(.*) https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
    </LocationMatch>
    <LocationMatch "^/webmail/*">
    RewriteEngine on
    RewriteRule ^(.*) https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
    </LocationMatch>
    </VirtualHost>
    <VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/scalix-apache.pem
    Include /etc/opt/scalix-tomcat/connector/ajp/app-scalix.*.conf
    </VirtualHost>

    Another convenient thing is to redirect all http or https access to the Scalix server to webmail. This will not affect the admin console. Simply place a file like the following in the document root of your Web server:

    <html>
    <head>
    <title>Redirect</title>
    <meta http-equiv=refresh content="0; url=https://scalixbook.org/webmail/">
    </head>
    <body>
    <br>
    <p>Redirecting to Scalix Webmail via a Secure Connection... </p>
    </body>
    </html>

Some More Ideas ...

If you prefer not to do encryption in Tomcat at all, but do it all in Apache, here is an example that is reported to work on CentOS 5. For other RHEL4 derivatives, you will need mod_jk instead of mod_ajp and mod_proxy. This is a custom vhost definition; it may need to be rolled into the standard Scalix files. Things like /caa and /res can't be rewritten, so there will need for an exclusion rule. This configuration was taken from a DMZ machine; it forwards the requests to the real Scalix server.

<VirtualHost *:80>
ServerAdmin <address>
ServerName mail.domain.com
RewriteEngine on
RewriteRule ^(.*) https://mail.domain.comconcurrent.
co.za:443$1 [R,L]
</VirtualHost>
<VirtualHost *:443>
ServerAdmin <address>
ServerName mail.domain.com
ErrorLog logs/mail.domain.com-error_log
CustomLog logs/mail.domain.comconcurrent.co.za-access_log
common
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
SSLEngine on
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:!SSLv2
SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
<Location />
SSLOptions +StdEnvVars
AddOutputFilterByType DEFLATE text/xml text/html
text/css
AddOutputFilterByType DEFLATE application/x-javascr
Order Allow,Deny
Allow from all
</Location>
<IfModule mod_setenvif.c>
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-
shutdown
downgrade-1.0 force-response-1.0
</IfModule>
<IfModule mod_log_config.c>
CustomLog logs/ssl_request_log
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x "%r" %b"
</IfModule>
Alias /mail /usr/share/squirrelmail
ProxyPass /api ajp://scalix.domain.comconcurrent.co.za:
8009/api
ProxyPass /m ajp://scalix.domain.com:8009/m
ProxyPass /m ajp://scalix.domain.com:8009/m
ProxyPass /webmail ajp://scalix.domain.com:8009/webmail
ProxyPass /Scalix http://scalix.domain.com/Scalix
ProxyPass /omhtml http://scalix.domain.com/omhtml
</VirtualHost>

The following table shows some more ideas and concepts that will help to make your Scalix server even more secure. Unfortunately, describing them in detail is beyond the scope of this article.

Action

Function

Tripwire (42)

Intrusion detection, notices unwanted file changes.

Change Greetings of the Servers (SMTP, IMAP, POP, Apache, Tomcat)

No version number may be displayed. Attackers have to find out what kind server is running here. (Security by obscurity?)

Change ports of Servers

Redirect Ports from unusual ports, using stunnel.

AppArmor (43), SElinux (44) and (45) etc.

Restrict access to ressources, files, hardware etc. with policy-based software

Run servers as non-root user

A compromised server does not offer root-priviledges to the attacker any more. Works with tomcat and apache on Scalix.

Deny root-logins for SSH

If you have several admins logging in as root, you can trace who asquired root priviledges by su. This is not possible with normal root logins.

There are many more possible ideas that help securing a Scalix server. The Scalix Wiki and Forums are the best place to look for guidelines.

Summary

In this article, we have learnt how to secure a Scalix server. Firewalls and OpenVPN do a very good job, but there are some quirks where the admin has to pay attention. Stunnel works flawlessly, whereas https redirection does not survive updates and cannot be recommended, but it helps understanding the structure of the Scalix web server.

If you have read this article you may be interested to view :

 

About the Author :


Markus Feilner

Markus Feilner is a Linux professional from Regensburg, Germany, and has been working with open-source software since the mid 1990s. His first contact with UNIX was a SUN cluster and SPARC workstations at Regensburg University (during his studies of geography). Since the year 2000, he has published several documents used in Linux training all over Germany. In 2001, he founded his own Linux consulting and training company, Feilner IT.

He was working as a trainer, consultant, and systems engineer at Millenux, Munich, where he focused on groupware, collaboration, and virtualization with Linux-based systems and networks.

Since 2007, he is an editor at the German Linux-Magazine, where he is writing about Open-Source-Software for both printed and online magazines, including the Linux Technical Review and the Linux Magazine International www.linux-magazine.com. He regularly holds speeches and lectures at conferences in Germany.

He is interested in anything about geography, traveling, photography, philosophy (especially that of open-source software), global politics, soccer and literature, but always has too little time for these hobbies.

Markus Feilner supports Linux4afrika - a project bringing Linux computers into African schools. For more information please visit www.linux4afrika.de!

Books From Packt

Learning Nagios 3.0
Learning Nagios 3.0

Learning jQuery 1.3
Learning jQuery 1.3

trixbox CE 2.6
trixbox CE 2.6

Learning FreeNAS
Learning FreeNAS

Hacking Vim: A Cookbook to get the Most out of the Latest Vim Editor
Hacking Vim: A Cookbook to get the Most out of the Latest Vim Editor

Lighttpd
Lighttpd

Spring 2.5 Aspect Oriented Programming
Spring 2.5 Aspect Oriented Programming

Asterisk Gateway Interface 1.4 and 1.6 Programming
Asterisk Gateway Interface 1.4 and 1.6 Programming

 

 

 

 

No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
f
3
K
s
v
p
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software