Category Archives: Security

DKIM Signing and Mail filtering

Spam is always a concern when you have email. We have successfully integrated DKIM signing to our email system. As it can break mail delivery this is not done automatically. DNS records need to be in place for it to work properly. Thus if you’re hosted at CLDMV please contact us in order to help you with the process of setting up DKIM.

Next upgrade we have put in place is our own custom mail filter. Right now there isn’t much to it but injecting a header into emails to show it working. But soon there will be SMTP Relay limits (used to prevent compromised emails from flooding emails outbound), Custom spam filtering though DB rules, and probably some other things which I’m not thinking of currently.

The two main issues we had with putting our own Filter in place was the ability to maintain our Anti-Virus and Spam systems that were already in place while also being able to provide a second content filter. After many hours and tons of caffeine we were able to produce a system which kept our current system intact while adding the secondary system on top of it. As always Security in this manner was a great concern. Especially considering we would be handling external content. Several limitations are at play in current mail systems which caused us to create innovate techniques in order to send emails to our own system securely. We even attempted to hack our own mail server through emails and were unsuccessful.

Server Updates along with Security Updates

As always security is a main concern in our network. We have updated a couple services already and are in the process of updating a few more services currently.

First we have updated NGINX (our webserver) with a few additional modules which will allow us to do a few more optimizations.

We have also increased the SSL security levels. There are some downsides to this. However we believe the upsides outway the downsides.

Cons:

  • Support for IE6 on XP SSL connections have been removed completely.
  • Support for Java6 SSL connections have been removed completely.
  • Support for YandexBot 3.0 SSL connections have been removed completely.

Note: The above were already not supported as none of them support SNI (Server Name Indication). SNI is how SSL connections are defined by domain names rather than IPs. Since our network serve SSL connections based upon Domain names primarily and IPs secondary. Thus the support for the above methods of viewing a SSL site were spotty at best.

Pros:

  • SSL Security score went from 90% to 96.25%, a 6.25% increase.
  • Encryption Speed has been increased.
  • SSL connections now have a subsidiary encryption which helps even more against MITM attacks.
  • Possible BEAST exploit has been removed completely.
  • Possible Lucky Thirteen exploit has been removed completely.
  • Possible CRIME exploit has been removed completely.

Note: Above exploits above were possible due to Encryption methods which were available in the server to support the above methods of a SSL connection. With these removed the possible exploits are removed as well.

Current Status of Control Panel, security updates, and server updates

First lets start with a screen shot of the dashboard in progress for the control panel.

current-cp

Unfortunately Data prior to the 28th of May 2014 is a bit skewed. But as you can see we have plenty of navigation so consumers never get lost. We also show are currently showing all site traffic for all sites hosted under a specific user. Though with some crashes here and there we might put these charts on their own separate page per domain but still give the user the ability to view an all domain report as it’s setup right now (at their own risk).

Currently the theming for the charts is still to be completed. But we have the ability to show and hide specific points of data if we want, select a range of the data from the range bar below. And most importantly reset it all to dive into more data.

Updates outside of the control panel:

A lot of reforming to the back-end has happened in preparation of the control panel.

Security is always a concern when dealing with the online world. We have adjusted some security features. The control panel (unlike commercial panels today) will not actually be able to modify anything within the network per-say. What I mean by that is every command done through the control panel will actually hit a sub-system which allows or disallows access at that level. Which then hits the root system which can only run specific commands pre-written into the system. So unlike most control panels today where the code is on the forefront of the system, CLDMV’s back-end is segregated to many systems to prevent hacking. While data can be retrieved from the control panel anything which has to change the system will always be done through our set of sub-systems to insure stability and security.

Also it’s important to note there was a brief downtime of FTP log in and email receiving on 2014/05/31 at approx 5pm PST to 5:30pm PST. This was due to a mass restructuring of the back-end in order to support the new changes to come.

DNS Mail Settings

While most people never have an issue with their emails. One of the most basic ways to help prevent being black listed and prevent spam from being spoofed from your domain name is to set up SPF records.

Here is http://cldmv.net/ SPF record:

We’ll go over what each of the portions mean now.

v=spf1

This specifies what version the SPF is. Currently the only version supported is spf1.

mx

Specifies that email originating from MX records of the domain name may send email as well.

ptr

Allows any sub domain of the domain to send out email. This can be spoofed but not very easily. Generally someone would need to have access to your DNS records to change this. Also if you have an A Record with “*” pointing to your server this helps prevent this as well.

include:cldmv.net

Specifies that any domain ending in cldmv.net may send email for the domain as well. Generally this would be for your hosting provider to determine based upon their setup.

-all

Notice the negative sign. It tells servers which follow SPF to reject all emails which do not meet the previously set rules.

Anyone hosting email with CLDMV should set their MX record to mx.cldmv.net as well as add the following txt record in order to insure emails are sent and recieved following SPF.

New Security Features

Previously we had been using the over-popular Fail2Ban to scan our logs as a temporary fix for the issue. While the anti-DDOS software written by CLDMV takes care of a ton of bans every day. The hacking attempts are still being attempted by some what smarter hackers.

Today we rolled out our first module for log scanning. With SSH probably being the #1 threat to servers out there that is what we chose to target for our scanner. Took several days but the results are amazing. While I can’t divulge the inner workings of the module. Let me just show you the first ban email we got after running it for the first time:

Keep in mind these numbers and bans are simply based upon the past 24 hours of logs.

Update:

This guy takes the cake for CLDMV’s Anti-DDOS software catching a potential intrusion. Just received this email:

Also the log processing module for SMTP hackers is in place as well now. Here’s the first email for the past 24 hours of attempts:

Heart bleed bug

A friend just pointed me to this: http://www.theepochtimes.com/n3/609175-heart-bleed-bug-imperils-web-encryption-putting-passwords-credit-cards-at-risk/ which in turn turned me to this: http://heartbleed.com/

Basically OpenSSL for 2 years had a major flaw in it which allows hackers to obtain 64 kilobytes of data from the server where OpenSSL was installed and being used. I rushed onto the server and checked the OpenSSL for it’s version number. While I will not specifically state what version the servers are running for security measures I will say that the service is NOT running OpenSSL versions which were vulnerable.

However after using a test site (http://filippo.io/Heartbleed/) on a client’s server I found that even though 1.0.0 was not supoused to be affect (their version was 1.0.0c) they were vulnerable. I would strongly urge ANYONE to either run their update program (centos/rhel: “yum -y update openssl”) or manually install 1.0.1g as soon as possible. Then broadcast to your account holders to change their passwords.

Keep in mind OpenSSL 1.0.0c was released in December of 2010. Which means if 1.0.0c was vulnerable this bug has been around for 3 1/2 years.


 

Excerpt from http://heartbleed.com/

 

What versions of the OpenSSL are affected?

Status of different versions:

  • OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
  • OpenSSL 1.0.1g is NOT vulnerable
  • OpenSSL 1.0.0 branch is NOT vulnerable
  • OpenSSL 0.9.8 branch is NOT vulnerable

Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.


Commands to update your own dedicated server:

Just in case the above command doesn’t clean up here is the clean up command:

In case you’re having issues with “openssl version” still showing you your old version and are using StorMan use the following commands:

If not using StorMan and still having issues of the old version being reported try:

To test your openssl version use the below command:

 Also keep in mind you will want to re-key your SSL Certificates if your server had a known issue. As someone could be sitting on your private key just waiting to use it.