Symantec 8300 Virtual Appliance – Ultimate protection

(2 votes, average: 5.00 out of 5)

Loading...

Given our experience with GFI MailEssentials and MailSecurity, we have been looking for a replacement E-mail security gateway replacement product.  Like most administrators, we know about the major players and we decided to go back and see where they were at.  We stumbled upon the Symantec 8300 Mail Security Appliance during that investigation.  From the initial review, it met most of our major criteria.

1. MTA mail gateway appliance.  The product must operate as an independent gateway to our Exchange back-end servers
2. Product licensing should be based on number of protected mailboxes and not the number of appliances.
3. Multiple appliances must work together.  That is they must be able to share configurations, quarantines, statistics, etc.
4. A separate management appliance would be helpful, but not mandatory
5. Classification of SPAM to identify why a message was quarantined
6. Support definition of business rules (for example, no outgoing message with attachments greater than 10MB)
7. Customized notifications and bounce messages
8. Legal disclaimers – optional
9. SPAM quarantine managed by administrative staff – not users
10. Must not rely on whitelisting as a part of their SPAM maintenance, but must support it

We originally spent a few weeks reading the installation and administrator’s guides for the product and the flexibility, customizations and features exceeded our expectations.  But most of all, the guys at Symantec did something that is absolutely brilliant — a version of the product is sold as a virtual machine running under VMware ESX 3.5.  No more worrying about scalability and buying outdated hardware and support contracts and then having to upgrade as the enterprise grows.  On a virtual machine, we can move it to more powerful hardware and networks with bigger pipes just by hosting the VM on a different machine or upgrading the current hardware.  This is the wave of the future for appliances and I was amazed that I had not thought of it before.

The product can be installed as a single instance with a scanner (MTA) and a Control Center (management console) or separate virtual machines.  You are allowed to create as many scanners as you want, as the license is based on the number of protected mailboxes and not by the VM instance, amount of RAM, CPUs or other metrics that are so popular.

As a matter of fact, the “installation” is so simple as they allow users to download an ISO image of the product which can be instantiated in a VM in a matter of minutes.  The default configuration is ready to go to work immediately and you can fine-tune it in real-time if necessary.  We did not take this approach as we wanted a more controlled evaluation and installation.

Management of the product is very simple and intuitive.  The Control Center uses a web-based interface (GUI), although a command-line interface (CLI) is also available.  Both are very useful and have their place in managing the product.  Even if the Control Center is unavailable or down, the scanners can still be managed through the CLI.

Just clicking on “scanners” gives a status check on the scanners as shown above.  This is very useful in managing the health of the appliances,  With logging enabled, administrators have complete access to the Message Audit Logs.  These are the same types of logs used in Exchange Server for tracking E-mail.  You can quickly determine what happened to any particular message and see full headers for details.  Symantec also provides a quick overview of the past 24 hours, 7 or 30 days.

Evaluation
We installed the evaluation version of the product and had it up and running within a few minutes.  Since we already had GFI MailEssentials and MailSecurity running in production, we decided to run the same mail through the 8300.  To do that, we took all of the quarantines and forwarded them to another Exchange server through the 8300.  We also took user mailboxes and sent them through the same process.

This allowed us to see if:

1. What GFI marked as SPAM in our environment was being caught by the 8300
2. What GFI allowed to get to our users would be allowed by the 8300

We ran these tests for about a month and our tests showed that the 8300 was far superior to the two GFI products in every way.  False-positives that GFI was blocking, were getting through the 8300 cleanly.  SPAM that was getting to our users, was totally eliminated by the 8300.  These results were amazing and surprised us.  We expected improvement, but this thing was working flawlessly.  We also watched performance.  We had two Exchange front-end servers in a load balancing cluster to handle the E-mail load at the company.  While we don’t have a lot of employees (<150), our front-end servers were almost 100% CPU bound and mail would frequently be queued for hours.  Those front-end servers were dual 3.0GHz Xeon hyperthreaded processors with 4GB of RAM.  The 8300 never queued input or output coming from these two servers.  As a matter of fact, it was barely breathing hard.

We were convinced and processed a purchase order to get this into production.

Architecture
For incoming mail we  built three MX records at different priorities as follows:

In this scenario, most incoming E-mail will arrive on SMTP0 if it is available.  Some spammers will attempt to use a secondary or lowest priority MX record in hopes that those systems do not have the same levels of security and SPAM handling as a primary server.  This is usually the case, since most product charge by the appliance instance.  Not so with the 8300.  We can provide the same level of security on all incoming gateways at no additional cost.  The last server, smtp-backup.domain.com, is a fake DNS entry or non-existent server in an attempt to get spammers that are looking for a path of least resistance go after a dead box and hopefully give up.

The appliance only allows for a single DNS name or IP address to forward all mail.  For this reason, we have smtp0.domain.com send all mail to Exchange back-end server mail.internal.domain.com and smtp1.domain.com sends all mail Exchange back-end server mail1.internal.domain.com.  The internal Exchange routing group will send the mail to its final destination mail store within the enterprise.  A stand-alone Exchange front-end server is still required as a gateway for webmail access for our users.

Mail leaving an Exchange server, is sent directly to either smtp0.domain.com or smtp1.domain.com.  This is done in the Exchange routing group where both names appear as forwarders.  In this configuration, the Exchange servers use a round-robin method to determine which gateway to send the mail to.  Both mail servers use the same NAT address from a PIX firewall to the Internet.  This IP address is also identified in the SPF record within DNS as the only allowed address to transmit mail on behalf of the company.

A third virtual server is called smtp-cc.domain.com.  This is the control center server for the 8300 gateways.  This is the only server with a GUI and collects all of the SPAM Quarantine and Compliance folders.  All configuration of the gateways is done through this server.  But, even if this server is down, mail processing will continue.

Design

In our environment, the 8300 virtual appliances run on ESX 3.5 servers running on LS-21 blades within an IBM BladeCenter H.  Their configuration are set to match the highest values as recommended by Symantec in their installation documentation.  With two dedicated scanners, we easily exceed the current throughput of the Exchange front-end servers with GFI and provide better management, security and reliability.

The SPAM handling rules of the gateways have shown that they exceed the false-positive numbers we have seen with GFI with outstanding performance, better reporting and easier/faster to find items.  The separation of the control center from the scanners also makes management tasks far quicker and easier to handle.  We have found that all of the relevant rules and conditions that we used and configured within GFI are all possible with this product and much, much more.  While there are some differences, it does not impact our ability to manage and provide quality security to our users.

One of the major decisions was whether or not to allow end-users to have access to their SPAM quarantine.  This is a feature of the product which GFI did not have.  After some debate, it was decided that we would not implement this feature.  The amount of SPAM is staggering and we feel that the number of false-positives will be so low that it will not be necessary.

Since we already have an Akonix (now Quest) IM Gateway A6000 security appliance in our environment, we will not be implementing the IM security features of this product.    We are very skeptical about the future of this product now that Quest has acquired the company, so having a backup strategy and appliance that is ready to take its place is reassuring.

Implementation

Since we are not allowing users to access the quarantine, we did not configure the LDAP synchronization with Active Directory.  We will install separate administrator accounts for the IT staff that administers the system.  To begin with, only two users have full administrative rights, while all others have view-only rights, except for the quarantine and compliance folders.  For them to release mail from those holding areas, they require modify rights.

Alerts are sent using the E-mail address smtp-cc@domain.com and we activated all alert conditions.  This may change over time with more experience with the product, but for now we want to make sure we are aware of any issues as soon as possible.  Already, we know that our outbreak conditions are too tight as we get notiifcations almost every hour of the day.  Too many notifications is like Chiken Little, soon they are ignored by everyone.

While we are not configuring LDAP sync, we still need to define an LDAP server for blocking directory harvesting messages.  For this purpose, we point at a domain controller with the global catalog on port 389 and set it for “Recipient Validation” only.  We set the Control Center server to use the Active Directory settings and just “Auto Fill” options for the query details.

All scanners have the message logs enabled at the “warning” level and are retained for 60 days regardless of size.  Reports will contain all possible data items to begin with and again kept for 60 days using the same E-mail address as alerts.

Invalid recipient handling (directory harvesting) is enabled.  We reject any message that contains an invalid recipients with a standard response from the MTA to the sending mail server saying, “Recipient address rejected: User unknown”.  It may be better security to drop the invalid recipient connection, a great feature of this product, but we want to make sure of our configurations and settings before taking that step.  Our experience is that this really cuts down on the amount of time wasted by these attacks.  Over 90% of the incoming mail to our servers are of this type.  We have reviewed other domains and this is fairly consistent everywhere we look.

The SPAM quarantine of this product allows for a lot of options and features.  By default, we only implemented two rules and turned off all default rules that come with the product.  We decided to put headers into all mail that goes in the quarantine to identify why it was rejected by the scanners.  While it would be possible to coordinate the message audit logs with the quarantine, it is an unnecessary and time consuming step.  Our header will be called “X-companyname-verdict”.

The first rule is to send suspected SPAM to the quarantine, add our header with a value of “Suspected SPAM” and bounce the message to the sender.  The bounce will state, “In an effort to eliminate junk E-mail, the attached message was not delivered. If you believe that this should not have been blocked or if you require additional information about this message, please contact postmaster@domain.com. Please be aware that a lot of junk mail is sent using someone else’s address, so if you don’t know why you received this, it’s possible that someone tried to junk mail a user on our servers using your address.”

The second rule is to send all SPAM to the quarantine and add our header with a value of “SPAM”.  Since the product has determined that this is undeniably SPAM, we don’t send a bounce.  The odds are that the sender is forged or fake and there is no need clogging up our systems trying to send a bounce and queuing it up.  Its a waste of time.

As noted above, LDAP had to be defined in order to enable Directory Harvesting.  We set the minimum percentage at 20, the minimum number of bad recipients to 5; the qualification time window to 10 minutes and the penalty box time to 3 hours (180 minutes).  The message is marked with our header, with a value of “Directory Harvest” and sent to the quarantine.  This is a true directory harvesting approach which is non-existent in GFI.  That product only blocks invalid recipients under the term of “Directory Harvesting”, but does nothing about the issue of recurring attempts and shutting that down.  This is vast improvement and one that keeps these idiots completely off our systems and a great feature.

By default, we do not send misidentified messages to Symantec or any administrator.  Only the two full administrators can change this value.  Most released messages will not actually be false-positives, but more compliance or violations that do not need Symantec involvement.  Messages are stored in the quarantine for 30 days with no thresholds set on the size of the quarantine, number of messages or messages per user.  Only time will tell if this is practical or if changes need to be made as the company grows.

Early testing showed that we can use a fairly small value for the Scan Settings.  Consequently, we have set the Suspected SPAM score to be between 60 and 89.  It may be possible for this value to be lower, but it is not possible to obtain the value of a suspected SPAM message to make that determination.  This would be a real improvement to the product.  We have requested Symantec to enhance the product to allow us to put the threshold value in the mail headers within the quarantine to help focus in on the right value for our company.

We support the SPF community and enable sender authentication.  We do not have any direct experience with “Sender ID”, so we started the same as GFI, supporting SPF only.  We will authenticate all domains despite any performance impacts and any message are held in the SPAM quarantine with the header value set to “SPF”.

We configured four of the Email firewall sender groups.  For “Blocked Senders (Third Party Services)”, we use bl.spamcop.net and zen.spamhaus.org which are the same ones we used with GFI.  Our experience has shown that these two are the most complete and accurate.  Blocked messages are held in the SPAM quarantine and header value set to “3rd party blocked sender”.  Next is “Allowed Senders (Domain-based)”.  While we are generally opposed to any whitelisting of user accounts or domains, one particular sender has been a big pain in our backside.  Rather than continually teach her and her company on mail security and etiquette, it is just simpler to just accept mail from her specific address.  For “Zombies” we will simply hold the message in the quarantine and add our header value of “zombie”.  Last is “Suspected Spammers”, which will also go into the quarantine with a header value of “Suspected spammer”.

Virus Handling
We disabled all of the default policies instead of deleting them just in case we wanted them for future reference.  We built our own custom policies based on their example.  The product has a great feature which allows policies to be copied and then customized, saving a lot of time and effort in the process and minimizes errors.  Our policies are:

1. Send virus to quarantine – hold message in the quarantine and set header value to “Virus”
2. Send worm to quarantine – hold message in the quarantine and set header value to “mass-mailing worm”
3. Send suspicious attachment to quarantine – hold message in the quarantine; set header value to “suspicious attachment” and bounce the message to the sender with the comment “Suspicious attachment found in message”
4. Send spyware/adware to quarantine – hold message in the quarantine and set header value to “spyware/adware”
5. send unscannable Email to SpamDepot – forward the message to spamdepot@company.com and add an annotation “Unscannable”.  This is not sent to the quarantine because we have seen where messages greater than 1MB were not going into the quarantine.  We need to verify this with Symantec and see if there is a way to change or configure this requirement.  Until then, we keep the message for later possible review and/or release into an E-mail box on our Exchange server.
6. send encrypted attachments to quarantine – hold message in the quarantine and set header value to “encrypted attachment”.  For the same reason as above, a copy is also sent to spamdepot@domain.com

We will enable the virus attack settings.  The action taken will be to defer the SMTP connection, using the values of:
minimum percentage of virus messages = 50
minimum number of virus messages = 2
qualification time window = 10 minutes
penalty box time = 180 minutes

Because of the increasing incidents of SPAM, we have elected to use the “Enable Rapid Response updates” for this product until and unless we experience problems with these untested updates.  We will also download the platinum virus definitions from the Symantec web site.

Suspected viruses are automatically released after a 24-hour holding period and there is no maximum size for the suspected virus quarantine.  It is expected that this will rarely if ever occur.

Compliance
We configured three compliance policies, once again leaving as many default policies alone.  The policies will be:

1. block mail greater than 10MB in size – company policy does not allow for any E-mail to leave the company if it has an attachment greater than 10MB (compressed or decompressed).  Note that some attachments may actually “look” smaller, but their MIME may be larger than the resulting file.  In this case, a notification is sent to the sender that states, “The attached message contains an attachment greater than 10MB, which violates our email policy. The message was not delivered.  Please submit a helpdesk ticket to http://helpdesk.domain.com to request this message to be reviewed and released by IT security.”  The mail is then put in the “10MB attachment Compliance Folder”.  If the message if approved (released) by an administrator, then the message will be sent to the recipients and the sender will get a notification stating that the message was transmitted.
2. block password protected mail – company policy does not allow for the receipt of E-mail containing password protected attachments.  If detected, the message is sent to the quarantine, our header value is set to “password protected”; the message is forwarded to spamdepot@domain.com (see about notes); and the recipient(s) are sent a notification of the violation and that the message is being held for review.
3. block executable files – company policy does not allow for the receipt of E-mail messages containing executable programs, macros, or other objects.  If detected, the sender is sent a notification about the policy and the entire message is attached.  The message is then sent to the quarantine, our header value is set to “executable attachment”; and finally forwarded to spamdepot@domain.com (see above notes).  Note here that we had to make a single change to the default attachment list for executable files.  Turns out that Microsoft Office 2007 can insert call-outs to .bin files for printer settings, Active-X objects and other items.  By default, the “.bin” extension is classified as an executable.  We removed that extension from the list.  Here another improvement could be made in the product.  In most areas, we can copy or duplicate a setting and then modify the copy for customization and leave the original alone.  However, this is not possible in the attachment lists.

At the current time, we will not be using any of the other sophisticated compliance rules that are available in the product.  However, this is another good feature of the product and would be very helpful and improve security — especially for public companies and global enterprises that have to follow different country laws.

One item still under review is a legal disclaimer. Initial testing shows that this works well enough, and we are trying to configure the rule to minimize the continued additions to messages after subsequent replies.  We would also like to give users the ability to “opt-out” of having a disclaimer on a particular message.  However, we have been unable to develop a set of rules, criteria or methods to make this work.  We will submit a request to Symantec to see if they have a way to do this or suggest an enhancement to the product.  Another product that we will evaluate for this purpose is Sunbelt Software’s E-mail disclaimer product.  They recently removed that product from production as they undergo some improvements and changes.

Conclusion
Our configuration has been in full production now for  just about a month and things are going very well.  My users have commented about how much quicker mail is moving in and out of our network and that their mailboxes are finally cleared of all SPAM.  The biggest improvement to them is the apparent elimination of all false-positives in handling messages.  In the past, we were asked almost daily about a missing mail that was “caught by the filter” and we had a substantial whitelist that was growing all the time.  That caused mail to slow up even more.  With this product, the whitelist is virtually empty and we have more time to work on other things.  This product is quickly becoming a “set it and forget it” appliance with high availability, reliability and we are very confident in its ability.

It is not perfect, but it is by far the best anti-virus, anti-spam, compliance management E-mail gateway that we have evaluated.  The price is excellent and as a virtual machine, it will easily grow with our company without significantly increasing cost.

Tagged as: Anti-SPAM, E-mail, SMTP, Symantec

Article by Steve Van Domelen

Steve has written 47 awesome articles.