Have you ever received an email bounce for an email from your email address, or your email domain, that you never sent? We get a lot of emails and calls from people that this has happened to with the concern that their email accounts have been hacked.
While this may be the case, it's not the only reason why this could have occurred.
It's actually quite easy to send email email purporting to be from a different email address. The code below shows how you can send an email saying that you're the CEO of Microsoft.
SmtpClient smtp = new SmtpClient();
MailMessage fakeemail = new MailMessage();
fakeemail.Subject = "You've won a free copy of Windows";
fakeemail.Body = "Click this suspicious link to get your free copy of Windows";
fakeemail.From = new MailAddress("firstname.lastname@example.org");
If I run this code and send it through an email server, it will go to email@example.com and look like it's from firstname.lastname@example.org
There is a mechanism in place to help stop this from happening called Sender Policy Framework, commonly known as SPF. SPF is a DNS TXT record that lists what servers are allowed to send on behalf of this domain. An example of an SPF record is
"v=spf1 a mx -all"
Lets say this SPF record is for the bloggs.com domain from our example above
What this is saying is that for this domain, the only servers that may send on behalf of bloggs.com are those with a A record listed for bloggs.com, or those servers listed as part of the MX record for bloggs.com
Looking at the example below, email would be allowed from the servers with the IP's 126.96.36.199 (the blank A record), and from 188.8.131.52 (the IP of mail.bloggs.com in the MX record)
The "-all"" on the end says that no other server can send and if they try they should do a hard fail. A hard fail means that the email should be rejected. If you want email to do a soft fail from other servers, which usually means that the email will be tagged as having failed SPF, but still be allowed through, you would set the all to be "~all", rather than "-all"
If you send email out via your ISP's email server rather than the same server that your email is received to (via your MX record), then you should ask your ISP what information needs to be added to your SPF record to allow this. The same applies if you send email from your domain via an online newsletter tool such as MailChimp.
If you host your email (and DNS) with Expeed, then the default SPF record above is added to your DNS as soon as you add an email account to your domain.
If you're not sure if this record exists for your domain, you can contact our support department.
This Sender Policy Framework is an optional framework and is not implemented on all email servers, so it is not the silver bullet to solve this issue, but it always pays to ensure that it is correctly configured to try to minimise the issue. If you want to find out more about the SPF syntax, then head over to the Sender Policy Framework record syntax page
As mentioned above, there is still a possibility that the password for your email account has been compromised, so if you're not sure, change your password and be sure to set it to a long complex password.
With Wordpress being one of the most ubiquitous content management system used on the web today, it's no surprise that it's heavily targeted by hackers.
The ease of setup and management, together with the extensible plugin architecture of Wordpress, make it a great tool to quickly build a new website.
This however, is also one of the key reasons why it's the most targeted platform on the web. Some of the users that setup and manage these websites are not experienced at keeping the Wordpress application and its plugins up to date. Over time, vulnerabilities are discovered in different versions of the application and are usually patched by the developers when they become aware of them. If a user fails to regularly update their website, hackers can easily exploit these vulnerabilities.
Some of the risks of these vulnerabilities include; uploading a file to the website which can then be used to allow further access into the server, send spam email, corrupt or replace website files, launch attacks on other sites and servers, as well as changing content, or injecting additional content into the pages to help spread Malware and Viruses around the web.
Please don't think that because of these issues we are against Wordpress in any way. It's a fantastic free CMS that we use ourselves on a few of our own personal sites. The key is to ensure that you keep your Wordpress website (any CMS system for that matter) updated with the latest versions.
Our tips for managing your Wordpress site are:
For those of you that are so inclined, you can search the online exploits database at https://www.exploit-db.com/search/ for Wordpress and see some of the nearly 1000 vulnerabilities listed for Wordpress and its plugins.
If you want to add an extra layer of protection to your Wordpress website, we offer a tool called WPScan that we can run against your website which may be able to detect any known vulnerability. Please contact us at email@example.com for more information.
Changing the PHP version, configured extensions and basic settings is easy in cPanel using the built in PHP Version Selector.
1. In the main cPanel screen, scroll down to the Software section and click on the Select PHP Version link
2. From the following screen, select the version of PHP that you want to use, and click the "Set as current" button.
3. Once you have set the version, you can then edit the enabled extensions for PHP.
4. If you click on the "Switch to PHP Options" link on the right hand side of the page, you can change options like memory_limit and post_max_size
We are always looking for ways to bring you new products and services or improve our existing services. Our new premium anti-spam system is a combination of both.
We have partnered with SpamExperts to implement their hosted cloud solution.
With the sole focus on anti-spam and anti-virus, a dedicated solution like SpamExperts can provide a much higher level of protection than the standard filtering that email server software can offer. We have been trialling this service for several weeks to and have seen a significant reduction in the amount of spam we’re seeing in our mailboxes.
Our premium service is based on per domain pricing rather than the per mailbox pricing that a lot of premium services offer. With the low per domain cost, you will save money even if you have only a few mailboxes. Those people with domains with a high number of mailboxes will see significant savings.
Incoming filtering is very easy to configure and just requires a small DNS change. Outgoing filtering requires a little more work, but our friendly support staff can help you through the process quickly and easily.
Pricing starts from less then $2/month for incoming filtering and $3/month for both incoming and outgoing.
Order your premium anti-spam filters service now and forget about spam.
We have been receiving more than the average number of support tickets relating to SSL (Secure Sockets Layer) certificates of late, so we have decided to put together this post which will hopefully answer any questions that you might have about SSL certificates: how to get them, how they work etc., as well as some questions you didn't know you had yet.
It's always a good idea with these sorts of posts to start at the very bottom and work our way up, so let's start with what an SSL certificate is, what it is meant to do, and have a look at the various types of certificates that are on offer: You will see these things all over the web now, and their usage is becoming increasing common (which probably explains our recent spike in support calls about them) as general Internet users become more aware of their online security.
The purpose of an SSL certificate is allow for Internet traffic to pass through a secured channel (and you'll see this with web addresses prefixed with https:// rather than the more standard http:// - the additional 's' standing for secure), as well as to confirm the identity of the owner of the website. When looking at a website, apart from the presence of the https:// prefix, you will often see somewhere - either in the address bar at the top or the status bar at the bottom of the screen - a padlock, which when clicked, will display the full SSL certificate. That certificate shows the holder's details and the website address to which it belongs.
We have the https:// prefix shown in our browser's address bar as well as the padlock icon. We have clicked that to show the details of the certificate which shows that the certificate is issued for google.com.au which is indeed the site that we are looking at, and the circled items show that the certificate is currently valid (it's 1st October 2012 as this post is written).
Types of certificate
As with everything that really ought to be easy, it is in fact considerably more difficult than it would first appear to get an SSL certificate because there are in fact a vast number of different types of certificate available, from any number of different providers.
We couldn't possibly hope to show every type of certificate from every provider, and wouldn't even try, but we can show the general "types" of certificate that pretty much all providers will be able to supply. Of course, some will be able to provide more and/or different certificates, but these are the base. A basic SSL certificate will link to one SUB-DOMAIN, nothing fancy, just a simple SSL certificate which confirms the identity of the website that you are looking at matches the address that you have navigated to. There are a couple of points to note here, as follows:
Almost identical to the basic certificate above except that it avoids the problem pointed out in pitfall number one, whereby multiple sub-domains are used. A wild card SSL certificate allows you to confirm an entire domain name so anything.example.com would be covered as well as www, ftp, mail and any other sub-domain that you choose to create. Pitfall two above still applies however, in that there is no actual identity check of the website owner, only the address itself. With BusinessID (and the name may change between providers), we are able to eliminate pitfall number two above.
When requesting this type of certificate, one must provide full contact details as well as other information for the identity of the certificate holder. The certificate provider will then make the necessary enquiries using whatever means they can to establish definitively that the entity requesting the certificate is who they purport to be. Business ID certificates look slightly different when viewed because they actually show the name of the entity (usually a company) which holds the certificate as well as just the domain name to which the certificate applies. This is the top-of-the-line solution, and the way to tell it is that the address bar of your web browser will go green (usually), and display the full name of the certificate registrant in the address bar.
Obtaining an SSL certificate
Generally speaking, obtaining an SSL certificate is as easy as placing an order for it as most people will opt for either a Basic or a Basic with wild card certificate - mostly due to the cost implications of the others. In this case, you would place an order through the billing system and the process will largely be taken care of for you. As usual though, there is a gotcha in the process which should be explained so that it doesn't become a blocking issue: When you order your SSL certificate, you would generally do so through a reseller company (we at Expeed are resellers for example).
That reseller is allowed to place the order on behalf of the registrant, but the registrant must be the one who "fulfils" the application given that they will be the ultimate holder. Therefore, the registrant (you) will receive an e-mail from the SSL certificate issuer asking you to confirm that an SSL certificate was requested in your name, or for your website, so that it can be fulfilled.
This is done to prevent an unauthorised third party requesting an SSL certificate on behalf of a website that they were wishing to target and making it appear legitimate. For example, if you were to set up shop using your domain name of MyWidgets.com but a nefarious third party requested an SSL certificate for that domain name, that third party could easily pretend to be the legitimate owner of the domain. The fulfilment requirement ensures that only the legitimate owner of the domain is the one who requests the SSL certificate. As a further complication to this process, there are only a few e-mail addresses that are considered "valid" from which to request that fulfilment takes place, as follows:
If you are going to request an SSL certificate, make sure you have one of those e-mail addresses set up before you start. It will just make the process so much easier.
The tricky questions you will get asked
During the order process, besides the standard contact name and address details, you will be asked for a few data items that are specific to SSL certificates. At first glance, they can appear to be slightly non-sensical, so they are worthy of special mention below: SSL Website URL: This is the full name of the website that you would like to secure. Remember that in the case of a non-wild card certificate, this may want to include the www. Refer to pitfall one (above) in the Basic SSL section.
Approver e-mail address: This must be one of the "valid" e-mail addresses shown above
Organisation name: The name of the company that is the registrant. If you are not getting the certificate on behalf of a company, then this would be your name
Organisation unit: This is the department name within a company. If no such thing exists, enter IT Department or something similar. It is of little importance but must be supplied.
City: The city in which you or your company are located
State: The state in which you or your company are located With those questions answered, an SSL certificate and be requested and the rest of the process should be pretty transparent to you.
Activating the certificate for your website(s)
If you have shared hosting then you have no need to worry about adding the certificate to your site because it will be done for you. If, on the other hand, you have a VPS (Virtual Private Server) then you are going to need to do some work in order to create the request item, accept the response certificate and update the website bindings to use the certificate. From within Internet Information Services (IIS), you will need the Server Certificate's applet (accessed by clicking the server name node from the left menu)
From here, click "Create certificate request" from the right hand bar to begin the process. You will need to complete the fields as per the "tricky questions" section above; bear in mind here that the website url will be asked for by the name of "Common Name". If you are requesting a wild card certificate then your common name will need to begin with the wild card character which is an asterisk (*), therefore, your common name will be *.domainname.com.
Other settings will be advised to you by your certificate provider but generally the default cryptographic provider (Microsoft RSA SChannel Cryptographic Provider) is the one you need. Be aware though that you will usually need a bit length of at least 2048 - in fact, 2048 is generally the requirement. This process will create a text file which contains the request string. When your provider asks you for that request string, they will need the entire contents of the file including the -- BEGIN -- and -- END -- lines.
What you will receive back from your certificate provider is the textual content of a certificate. Again, as above it will be prefixed and suffixed with -- BEGIN -- and -- END -- lines, and once again, these lines also make up the certificate reply. Paste the entire text that you receive into a new text file on your server, but name it with a file extension of .cer (for certificate).
Bear in mind also that you may renew the certificate every year or two, so try to choose a name that is easily distinguishable. So, www.mydomain.com.2012.cer is a reasonable format. It is important that the text be pasted unedited, so you will need to use a simple word processor such as Notepad. It would not be advisable to paste into Microsoft Word or WordPad as they will add their own hidden characters that will render the certificate useless. Also, make sure that the file name has an extension of .CER otherwise it will not be found in the next step.
Be aware than if you are hiding the file extensions for known file types, your new document will end up with a .txt.cer extension and that will fail! In order to import the certificate, you will once more need to be in IIS's Server Certificates apples (shown above), but this time, from the right hand side choose "Complete Certificate Request".
You will be asked to locate the .CER file created above, and to select a friendly name. It is of utmost importance that the Friendly name contain the year, otherwise, when you come to bind the certificates you may find many certificates - all for different years - with the same name in the list, and there is no order with which to make an educated guess. This is a frustration you learn to deal with in advance after the very first time of encountering it! All being well, your certificate will be incorporated and can now be bound to a website.
Now that we have made our request, received our response, and incorporated our certificate, we need to attach (or bind) the certificate to the website that we would like to use it for. Back into IIS, and we select the website that we are interested in from the list on the left (remember to expand the server name and then the sites node to see all of the websites and BE SURE to select the correct website). On the right hand side menu, we click the item called "Bindings ..." to display the dialogue box below (yours may have different items listed but that doesn't matter)
Click the "Add" button from the right hand side of the dialogue box. Change the "Type" field to https and you will notice that a new dropdown field entitled "SSL Certificate" is shown. From here, you can select the certificate - based on the very important friendly name from before - and click OK. The processing can take a little while, but then you are done. Remember to test your website with the https:// prefix and ensure that there are no error messages, and that clicking the padlock shows the correct information.
Renewing your certificate
Like domain names, SSL certificates are only valid for a set period of time - usually one or two years - after which they need to be renewed. You will get a number of automated e-mails about renewal so be sure that your registered e-mail address is kept up-to-date. Usually, you will receive e-mails 90 days before expiry, 60 days before, 30 days and five days before, and then finally on the date of expiry. Renewing is done by purchasing a new certificate and starting over. A note for those of you with VPS installations: generally the SSL certificate renewal system from within IIS is unsuported with providers now. Therefore, treat every renewal as a brand new certificate and follow the steps outlined above. This is where the friendly name as mentioned becomes very important.
An SSL on your website shows that you take your users' security seriously, and do as much as you can to provide them with a safe browsing session on your website and that you have taken at least the steps necessary to preven their confidential data from being leaked out to the world. SSLs are not the be-all and end-all of security, they are a small fraction of the entire security requirements, but they are reasonably inexpensive, easy to install and are an important peice in protecting you and your website visitors. Users are increasing savvy about interactions over the Internet and are increasing weary of who they give their data to, and what those companies do with that data. Users now activiely look for the padlock or the green address bar when filling in forms whereas they didn't a few years ago. If you have neither then you will be losing registrations and customers, there is absolutely no doubt about that.
Securing your Virtual Private Server is of utmost importance: it is part of your Internet life, and may well be part of your infrastructure that is absolutely mission-critical, and if it were to be compromised the ramifications could be anything from minor irritation to complete disaster.
We are not claiming that this post is a full-proof defence and will render you impervious to hacker attack, but anything you can do will certainly help, and these are useful steps.
Brute force attacks on password are extremely common throughout the Internet, yet still, a large number of users use passwords that are easy to guess. are dictionary words, or are the same passwords that they use for every other location. Quite often, brute force attacks will have a huge dictionary of words - everything in the English language to start with, then common password combinations like "qwerty", "asdfgh", almost all names or people, cats, dogs and pets. If your password is one of those sorts of things, you're really asking for trouble and it's really just a matter of time! These attacks are automated, and computers are really good a doing repetitive tasks at a fantastic speed. So, make sure that you use passwords which have the following characteristics:
Remember that the more complex the password, the less likely it can be guessed or brute forced. It may be a slight inconvenience for you, but your business may depend upon it. It's worth the hassle.
Changing your administrator password
Passwords for your VPS can be changed easily; below is screenshot of a of the Server Manager with the right-click menu shown for the Administrator account. Click the Set Password link from that menu and enter the new, secure password. Be aware that if your server run any services under the Administrator account (this is not the default setup) the you will need to change the password on each of those services too.
Additional tips for password security
Limit users and user privileges
Having administrator access to the server is great when you need to get things done, but being the administrator, you can do anything you want on there. That includes deleting everything! If you must have a number of people accessing the server via Remote Desktop Connection, do they need to be administrators? It's unlikely. It's actually more likely that they need to do day-to-day tasks and for that they need not be administrators; normally non-administrative users will be just fine for the most part, and they cannot cause too much damage. In the Server Manager (pictured above), add new users as required, then limit their privileges as required - that includes setting the relevant privileges at the folder - and possibly file - level, so that only some users can access certain areas of your server. Remember this: The more users there are on the server, the more likely a password will be compromised. The more a user is able to do on the server, the more damage that user can cause in the wrong hands.
Lock down access to the desktop via the firewall
By default, if you know the IP address of the server, and the administrator password, you can get access to the desktop. Obviously, that could be secured far better. If you only connect to the server from the office, and you have a fixed IP address for the office, lock down the firewall so that only that IP address can access the server via remote desktop. The more locked down the firewall is, the more secure your server is. You should only then open IP addresses as required.
WARNING: If you lock down the access to remote desktop to a fixed IP address, and your IP address changes, you will lock yourself out of the server and you will need to contact us to reset the firewall for you
Do you need desktop access at all? It's not always necessary to have access to the desktop; there are control panel software packages available - some free, some charged - which abstract all of that configuration work into a server that you access via the web, thereby avoiding the need for desktop access completely. Talk to us about control panel integration as we have solutions which may help.
Keep your server up-to-date
Security updates, hot-fixes and patches are released quite regularly for Windows Server and you should make sure that your server is kept up-to-date. If a patch has been released for a security issue, that means that a bug has been found in one or more applications which could be exploited to be a security threat. News about security exploits travel fast around the communities that try to exploit them, so an un-patched system is a gold mine to them. Updates are done for Windows Server in the same way that they are for Windows 7 or Windows Vista ... you use the Windows Update tool. It is advisable to log into your server every so often to make sure that there are no patches outstanding that need to be installed.
Pay attention to what is happening on your server
This may sound obvious, but many people fail to notice things are are staring them in the face when it comes to computers. Let's look at what you can do in order to keep on top of things, or in the worst case, notice quickly when something has happened if indeed it has:
Security is generally overlooked on a server, that is, right up until the time that an Administrator password is compromised and your world falls apart. You may be able to put everything back together again, but at the very least, it is going to cost you time to fix - quite a lot of it generally, money often - quite a lot of that too, and then there is the unmeasurable costs of loss of reputation and so forth. Don't put yourself in a position where you are having to recover from a security breach; stay ahead of the game. It only takes a little bit of time to keep the bad guys out of your server and from potentially ruining your business but it makes life harder for those bad guys. The harder it is for them, the more likely they are to leave you alone. These steps will not make you immune from a hacker attack, and they will not mean that your server will never be compromised, but they reduce the risks considerably. If you are ever in any doubt about how to proceed with security matters, always consultant a qualified professional.
1. Choose the domain you want for your SSL certificate, then create an admin email account on that domain, eg firstname.lastname@example.org.
The name of this account is important, so don't change it.
2. Go to the billing website and click Order, then SSL Certificates, or you can follow this link.
3. Click Order Now.
4. Enter your domain and company details for the website you wish to have an SSL certificate. A basic SSL certificate will only work on either your base domain, and www, or a single subdomain, e.g. test.yourdomain.com.au OR shop.yourdomain.com.au. Once completed click Update Cart.
5. Click Checkout and complete the order process.
6. Once the order has been processed you will receive an email to the admin account asking you to authorise the certificate.
7. Once the certificate has been authorised, it will be delivered to us and we will bind it to your site, then notify you.
We are sometimes asked why emails are being flagged as spam. Mail servers use a disparate variety of methods to combat spam and in most cases we are not in control of the system that is flagging these emails as spam. This is therefore not a question we can answer with authority, but is something the recipient network administrator can answer. However, two common issues have emerged:
1. Message content - your message may contains words or phrases which are spammy.
2. SPF record - mostly affecting mail sent from outside our network. Explained below. The default SPF record we give domains does not allow sending from all IPs, rather it specifies only the A and MX records.
What this means is that unless you've made changes to your DNS by either changing the SPF record or the MX record, mail sent from an external mail server masquerading as mail from a domain on our network has the potential to be flagged as spam by a receiving mail server. If you are finding emails being flagged as spam and are not using our mail server to send, you can try changing the SPF record (currently a TXT record in the DNS) to "v=spf1 +all" without the quotation marks.
This may result in your messages no longer being flagged as spam. Be aware that changing the SPF to +all will result in mail from any server passing SPF, and increases the chance that a third party can pretend to be sending from your domain without being flagged as spam.