While we take care that the WebApp contains no programming flaws that can reduce security, there are a few things that you, as system administrator, can do to improve security. The most obvious one is to only allow access to WebApp when using SSL, but there is more. For this article, we will assume that you serve WebApp using Apache, but other HTTP servers have similar options.
An official SSL certificate does not increase the security on a technical level at all. Some of these certificate authorities (I recently remember to a Dutch one being in the news) are even less secured as some would expect. All you get by an official certificate is a paid trust chain in the browser, which does not really increase security.
If you suggest official SSL certificates, you also should suggest introducing DNSSEC to avoid man-in-the-middle attacs which are possible with SSL and hacked/broken certificate authorities, too. By the way: Each time you log into a default installation of the WebApp, your feedback plugin does a backconnect to jira.zarafa.com via HTTPS, while zarafa.com is not secured via DNSSEC right now.
Additionally various of the certificate authorities create SSL certificates with vulnerable MD5 algorithm or weak key sizes or have a weak certificate chain. Some admins out there even create certificate signing requests (CSRs) for submission to the certificate authority with a weak key size (less than 2048).
Did you ever evaluate HTTP Strict Transport Security alternatively to "SSLRequireSSL"?
Disallowing SSLv2 is a good thing in general, but this is the default in nearly every current Linux distribution for years now. Instead you really should advise people to use at least TLS 1.1 or even better: TLS 1.2. And if you can not run this, because your Linux distribution still ships an old version of OpenSSL, you should recommend a good SSLCipherSuite (like "RC4-SHA:AES128-SHA:ALL:!ADH:!EXP:!LOW:!MD5:!SSLV2:!NULL") to also exclude weak ciphers or minimize the risk of already known SSL/TLS protocol issues - especially if your users may not run latest browsers and thus also not support TLS 1.2.
Another thing in the SSL/TLS world which is often forgotten by less knowledged administrators is the trust chain: Use SSLCACertificatePath (c_rehash from OpenSSL is your friend) or SSLCACertificateFile. I already have seen lots of Zarafa setups out there lacking the certificate trust chain. Note, that it still often works in nearly all browsers, even if you forget to configure this properly.
I wonder if you ever did things like Apache suEXEC or Apache MPM Worker with PHP in real life...however this brings me to my next point:
Why do you want to get later to SELinux? That work has been already done IIRC 1.5 years ago by Matěj Cepl, Miroslav Grepl and Daniel Walsh. Zarafa will work like a charm with SELinux enabled in e.g. Red Hat Enterprise Linux 5 and 6 (respectively also CentOS) and all current Fedora releases (like Fedora 14+). There is no need to re-invent the wheel. Ivo, I will invite you next time personally to my SummerCamp talk ;-)
With SELinux you even can cover one or the other operating system (library, service or similar) security issue, however, securing WebApp also requires a proper maintained system that regulary gets all security updates applied. And once the end-of-lifetime of the specific Linux distribution took place, an upgrade to a supported version needs to happen. You can't believe how many unsupported systems are out there or systems that run old software versions which are vulnerable. That is also securing WebApp!
If I was able to catch your interest in following up the hardening or if you would like to get your own Zarafa installation cross-checked regarding my proposal and thoughts, just contact me.
Robert Scheck 958 days ago
Robert, many thanks for your detailed response. A blog post like this can of course never be fully complete while still covering the details of all operating systems, so that's why it's more like a list of pointers. You really could write a book on only this topic :)
Ivo Timmermans 956 days ago