This material is copyright and is licensed for the sole use by Kliwon Klimis on 28th October 2008 425 cilce, , frood, grradt, 525254

Securing Zimbra

Built-In Security

One of the strongest selling points of the Zimbra Collaboration Suite, is that it is developed with security in mind. By this, I mean they have built in some security mechanisms that are already pre-configured, or require very little fine tuning on the part of the administrator. The first component of Zimbra is the AJAX Web Client.

Web Client Security

As discussed previously, the Zimbra AJAX Web Client is a user-friendly interface that offers many collaborative tools for the users. These tools include document storage and sharing, address books, calendars, and Zimlets (mash-ups). So what does all this have to do with security?

Although the AJAX Web Client is run on the client-side, through the browser, access to resources through Zimlets and other programs within the Web Client are controlled and secured via the server. For example, a Zimlet may allow users to import RSS feeds into their email box, to read news events. This is both a common and popular request now. Users do have the ability to add and choose the feed or feeds that show up in their web client, only after a system administrator has allowed access feeds to the site. The Zimlet will simply error out until the administrator

has opened up a pathway to that RSS feed's host site. This is out-of-the-box functionality. All of the Zimlets and programs have similar functionality in which they give the user the ability to use tools within their web client, but only if a systems administrator gives them access to do so.

Also, out-of-the-box the Web Client uses SSL/TLS security offering secure communication, via HTTPS, that uses encryption to keep potential attackers from sniffing your network traffic and gaining access to email files.

Lastly, because the Web Client is run through the client's browser, even if an attacker were to gain access to a user's mailbox and even if they had that user's password, they would not be able to access the server and compromise other user's data or the server itself. Sure, they could definitely do damage to the one user's email, but the damage is now contained to that user.

[ 120 ]

This material is copyright and is licensed for the sole use by Kliwon Klimis on 28th October 2008 425 cilce, , frood, grradt, 525254

Chapter 5

Mail Transfer Agent

The Mail Transfer Agent (MTA) that is built into Zimbra uses Postfix. The MTA is used for sending and receiving email to and from the Zimbra server. Essentially, when a user composes a message and sends it out, Zimbra uses DNS to look up the mail exchange (MX record) of the intended recipient and relays the message to that host. The MTA also receives email directed to it and forwards the message to the intended user. It is a pretty straightforward process, however there is a security risk involved.

Spammers are always on the lookout for what is called an "open relay". Open relays are email servers, specifically SMTP servers, that are running a mail transfer agent that does not require any authentication, origination information or verification in order to send an email out. What this means to spammers, is that they can compose a message that is intended to go out to thousands of users, and then tell their email client to use the SMTP server of the unsuspecting server that is running an "open relay". Thus all of the processing power will now be taken away from that server thus bogging down the server and possibly leading to down time. Lastly, the header information of the spam email will contain the host information of the server used to send the email, and may cause that email server to be blacklisted. Thus, making it difficult for users to send legitimate messages to legitimate customers. Zimbra's MTA has built-in security and verification, so that it is a closed relay to be used by authenticated users only.

Anti-Spam

Not only is having a server that is used to send out spam a security a risk, but users receiving spam is definitely a hot topic and a risk that needs to be mitigated.

Spammers use spam for phishing expeditions, essentially trying to trick users into visiting fake sites designed to acquire personal information, or could be used to send unsolicited messages for soliciting products, and finally to be used to spread viruses and other malware.

Zimbra uses SpamAssassin as its built in anti-spam program. It also makes use of whitelists and blacklists to control known spam offenders, and to make sure some email is never blocked.

SpamAssassin uses a process to "score" all incoming email. The score is used to determine the validity of the email and the higher the score, the more likely the piece of email is spam and should be discarded.

[ 121 ]

This material is copyright and is licensed for the sole use by Kliwon Klimis on 28th October 2008 425 cilce, , frood, grradt, 525254

Securing Zimbra

To enable spam checking, you will need to log into the admin console at http://zimbra.emailcs.com:7071. Once logged in, click on Global Settings in the Navigation Pane and click on the AS/AV tab. Place a check mark in the checkbox next to "Enable spam checking and antivirus" as shown in the following screenshot.

By default, the Spam Checking Settings include a "Kill percent" of 75 and a "Tag percent" of 33. So what we are telling SpamAssassin is that we consider score of 15 (20 * 75%) as spam. So any email that scores a 15 or higher is automatically discarded. The Tag percent is used to send email that may possibly be spam to the user's Junk folder. With a Tag Percent of 33, any email with a score of about 6.6 (20 * 33%) will be sent directly to the Junk folder. The subject prefix is used to append to the subject line of any emails that were suspected of being spam. So for example, if the Subject prefix was set to "SPAM", if the original subject line of the suspected email message was "Pharmaceuticals R Us" now it would say something like "[SPAM] Pharmaceuticals R Us ". The systems administrator is encouraged to play with the percentages to determine what is right for their organization.

However, the score could be fairly arbitrary, and sometimes you just want to stop messages from coming in from a particular host, or you want to make sure messages from a particular host are not scored. This could be done by creating Whitelists

and Blacklists.

Whitelists and blacklists are not officially supported by Zimbra, but it works.

[ 122 ]

This material is copyright and is licensed for the sole use by Kliwon Klimis on 28th October 2008 425 cilce, , frood, grradt, 525254

Chapter 5

A blacklist is a list of email hosts or users that you know are bad. They are spam and no matter what, you do not want your users receiving email from this domain. To create a blacklist, you need to go through a couple of steps. First of all, we will create a list of blacklisted hosts, and then we will tell our spam filter where the list

is located.

To create the list, we will create a file in the /etc directory of our server.

1. Switch user to root: su -

2. From a command line type the following:

Vi /etc/zimbra/blacklist

3.With the file open, hit the I key on your keyboard to place vi in insert mode.

4.Now, we will add one site to test out the blacklist. To test the blacklist functionality, enter a domain of a personal email account you have. In my case I will use gmail.com:

gmail.com

5. When completed, to save the file type:

:wq!

Once the file is created, we will create a whitelist file. The whitelist file will list all domains, or particular users from a specified domain, that will not be blocked by

Spam Assassin for any reason. In the case of our blacklist, we entered gmail.com to be blacklisted. All users from the domain gmail.com will be blocked from emailing to our server. Well, let's say, for example, that we know [e-mail] is a known sender and that his mail should always get through. We could add just that email address to our whitelist, thus allowing this email to come through, but no other email address from gmail.com will be passed through. It is important to note that the whitelist takes precedence over the blacklist. Therefore, if a domain is listed

in both, or a user is listed in both the blacklist and the whitelist, the whitelist prevails and the user will be able to send email in. To edit the whitelist, we will follow similar steps as to the blacklist above:

1. Switch user to root: su -

2. From a command line type the following:

Vi /etc/zimbra/whitelist

3. With the file open, hit the I key on your keyboard to place vi in insert mode.

[ 123 ]