Skip navigation

With the end of support quickly approaching for MEG 7.0 in 8 months for Feburary 2015 we often get questions for how to migrate appliances from 5.6 or 7.0 to MEG 7.5 or 7.6.  This blog post is to share steps which can make migrating versions easier.


How to migrate Email Gateway using the rescue image on the Appliance hard disk

Technical Articles ID:  KB81845



McAfee Email Gateway 7.x

McAfee Email and Web Security 5.6



Installing from the rescue image on the Appliance hard disk can make migration easier, while keeping the Configuration and Emails on the disk. This is useful when the Appliance is not local and needs to be migrated to the latest software version.



IMPORTANT: McAfee strongly recommends that you perform the following actions before you perform the migration:


    Patch the current installed version to the latest patch before performing the migration.

    Ensure that you have saved a backup of the latest configuration prior to migrating.


To perform the migration:


    Download the required ISO rescue image from the McAfee website.


    Export and extract the Appliance configuration file:

        Create a new folder and provide a descriptive name. For example, Appliance_config_backup.

        On the Appliance, select System, Cluster Management, Backup and Restore Configuration.

        Click Backup Config, and then click the link to save the configuration.

        Save this configuration to the new folder.


    Import the latest ISO:

        Open the Appliance Management Console.

        Click System, System Administration, Rescue Image.

        Click Import Image.

        Browse to the ISO that the Appliance is going to be migrated to and click OK.


    Perform the migration to the latest version:

        Click System, System Administration, Rescue Image.

        Click Force Boot from Rescue Image.

        Select Install software preserving configuration and email messages.

        Enter the Appliance password.

        Click OK.


        The Appliance reboots, and uses the rescue image to reimage the Appliance using the installation options selected.


        Once the migration is complete, the Appliance will boot under the upgraded version.


TLS and Vulnerability Testing

Posted by eplossl May 27, 2014

We pretty regularly have customers calling in looking for assistance with adjusting their MEG TLS configuration due to a vulnerability test they just had done on their systems.  Usually, the request is that we do something with the key lengths the MEG will accept, although sometimes it has to do with one cipher or another that customers would like to discard from use.  Both can be handled, but there are some considerations which admins should take into account before having these things done.


1.  What is the problem being reported?


Generally, the change desired is either to require larger keys for TLS encryption or restrict the appliance from using lower-security ciphers.  This is triggered on because a larger key length is harder to break as are higher security ciphers.  Knowing what the issue is then pretty much gives us the next answer we need.


2.  What is the goal of the change?


In the case of an issue with key length, the vulnerability scan wants to have the appliance using a longer cipher key length.  If cipher strength is at issue, the vulnerability report wants a more secure cipher used.


3. Why is the vulnerability scan calling for this change?


Generally, the point of a vulnerability scan is to verify that systems aren't vulnerable to attack.  When a vulnerability scanner reports that TLS is an issue, it is generally complaining that the key length is not long enough or that the server uses insecure ciphers.  But what does that mean?  Have ciphers really been broken?  In some cases, yes, they absolutely have.  In other cases, there is a weakness which has been found, but the cipher hasn't been broken yet.  In some cases, no specific weakness has been found, but the key lengths and types are simply generally weak. 


When it comes to key length, the system is talking about the symmetric key used by the internal encryption inside TLS, not the public-private key pair(s) used to set up the TLS connection.  This key is negotiated by the two servers in the TLS conversation.  A longer key means a harder-to-break key.  The harder it is to break, the more effort someone is going to have to go to in order to break the encryption, and thus read the data passing through the TLS tunnel.


4.  What are the possible impacts of the change?


First, we have the obvious impacts: 

1.  We'll disallow the use of weaker encryption keys

2.  We'll disallow the use of weaker ciphers


And then we get into secondary impacts:

1.  We'll have to transfer data in the clear to hosts which don't support stronger keys

2.  We'll have to transfer data in the clear to hosts which can't use stronger ciphers

3.  Bigger keys require more processor cycles

4.  More complex ciphers likewise take more processor cycles


So now this brings us to the final question we should ask ourselves.


5.  Does this make sense to do?


And there is the rub.  Does it make sense to restrict the use of lower security keys or lower security ciphers, considering that anyone out there who doesn't have access to those ciphers would be unable to communicate with you?  Does it make sense to refuse to encrypt data with even a weak cipher, and instead send the requested data in the clear?  Let's face facts: Encryption keys are like the keys to your house.  Having locks on your house won't keep out a determined invader.  If someone is determined to break the encryption on your data, they will find a way, regardless of the security measures you have in place.  But the presence of that lock will keep people who aren't determined to break in from doing so.  Thus, admins should take into account all the ramifications of restricting key lengths and cipher strengths when deciding their policy on this subject. 


As a whole, McAfee does not recommend any particular choice here.  Obviously higher security ciphers are better than lower security ones, just as longer keys are better than shorter ones.  However, each company's needs are different, and thus each company should make that decision for themselves.  For customers needing to ensure minimum key lengths, please see KB76384, which discusses how to configure TLS.  In there is included information on how to adjust the cipher strength requirement.  For those needing to restrict the use of particular ciphers or classes of ciphers, it is recommended to call in to Support to discuss with us the precise ciphers you wish to restrict.  Ultimately, steps similar to those found in KB78818 will need to be followed to perform the change.

With the Release to Support of the MEG 7.6.2 software, we are officially moving away from Controlled Release software and over to FeatureStream.  So what does this mean for our customers?  Let's go through this and explain what it all means.


You may recall that around the time we released 7.5, we announced a new release process we were going to call Controlled Release.  Basically, this was a full version of the software, but support would be somewhat limited.  Specifically, version numbers not of the form x.0.y or x.5.y were considered Controlled Release versions.  New versions would come out about once every 3-4 months, and once the next minor version revision came out, the previous minor version that wasn't a .5 or .0 release would have to be upgraded to maintain support.


Unfortunately, this caused some anxiety among some of our customers because they really wanted the new features in the newer versions of the software, but didn't want to be on a piece of software that was going to lose support. Meanwhile, our developers need to be able to release updates quickly, but cannot maintain too many versions at the same time while still being able to get timely updates out.  As a result, we chose to adjust the release model and rename it.  This model is now called the FeatureStream Release model.


So how does it work?

In our FeatureStream Release model, we have three versions of our software which we maintain; two Long Term Support (or LTS) versions and the FeatureStream version.  MEG 7.6.2 is the first FeatureStream release.  At this time, MEG 7.0 and 7.5 are the available LTS versions.  Starting with MEG 7.6, after ~3 patches, the MEG software will enter a stabilization period where no new features will be added to the product.  At the end of this period, the version number of the software will go from x.y.z to x.y.z00.  Once this happens, the software is considered LTS, and will be supported for ~2 years from that date.  LTS software gets hotfix and patch updates, but does not get new features, for the most part.  Patches on LTS will increment the version number by 1 as in FeatureStream, but since the version number is x.y.z00 to start, the first patch would be x.y.z01. 


New features will show up in our FeatureStream version.  Once a version gets promoted, a new FeatureStream release will be created.  Additionally, new install CDs are created when a new FeatureStream package is created as well as when a version gets promoted to LTS.  We are currently working to ensure that our patch updates will be able to maintain FIPS compliance without requiring a full rebuild, for those who need that feature.


How often can we expect new releases?

Long Term Support promotions will happen approximately once a year.  At the same time a version gets promoted to LTS, a new FeatureStream version would be created.  Additionally, an old LTS version would go End of Life about the same time.  Patches on the FeatureStream would be released about every four months.  These patches would roll up any earlier hotfixes as well as add additional new features.  Patches for Long Term Support versions would be somewhat more frequent, coming approximately every two months.  Additionally, customers on the FeatureStream who choose not to upgrade to the new FeatureStream version at the promotion of the previous will find themselves on the LTS version of that software release.  For instance, when MEG 7.6 is promoted (currently expected after the release of 7.6.3), it will become MEG 7.6.300.  Once on that version, a customer will be on the LTS version of the MEG 7.6 software, and can expect normal support and patch schedules from there.

A long time ago, email was designed for one purpose: Delivering text messages from one place to another.  Since it was developed in the States, the primary language of email was set to be English.  And since the English language uses exactly 26 letters (52, if you consider capitals and lower case letters different) and a few assorted characters, ASCII was chosen to be the de-facto character set for email.


Since that time, many things have changed.  We now have the ability to specify the character set to use in email.  Most commonly, that's either ASCII or UTF-8.  We also have put email to use for a lot more than just sending short text messages from place to place.  At some point, someone decided that an email message would be a great way to send a file to someone else.  The difficulty they encountered, however, is that a file exists in binary format on the source computer and they wanted to transfer it to another computer, for delivery in binary format, over an ASCII connection medium.  Obviously, this requires re-encoding the message through some means.  It was at this point that UUEncode and UUDecode appeared.  UUencode would encode a file in ASCII format for transmission over electronic mail.  UUDecode would take that file and decode it again.  The problem with these tools was that they were inefficient and difficult to use; encoding and decoding had to be done outside of the email window. Over time, Quoted-Printable (Q-P) and Base 64 came about, and pretty much took over the binary attachment handling world.


But even these tools have some inefficiencies.  Specifically, a file encoded using Q-P or Base64 is going to necessarily expand in size.  A file containing only ASCII text can be easily converted with almost no size increase, whereas an executable or other binary file is going to tend to get quite a bit larger.  Worse, smaller files grow by a larger percentage than do bigger ones.  This is due to the fact that smaller files tend to have fewer repeatable patterns than larger ones, as well as more expansion due to administrative overhead.  Overall, as file size grows, it approaches a growth rate of 33% (depending on the encoding mechanism), although small files can be as much as 50-75% larger when encoded for email transmission. 


So what sort of size limits should admins set?  Generally, it is a good idea to think of the largest file attachment size you want your users to be able to receive via email.  Once you have that size, multiply it by 4/3 or 133%.  That is approximately the size of file attachments you need to allow through the appliance.  It's also worth noting that transmission of large attachments is *MUCH* more efficient over FTP or some other binary file transmission mechanism. 


Either way, it is recommended that customers set their file attachment size filtering feature to filter for files about 33% larger than the actual maximum file size.



Notable links: l html

Filter Blog

By date:
By tag: