Monday, information about a flaw in OpenSSL was released to the public.  This flaw allowed an attacker to grab a random 64k segment of memory contents from the server exploited with this flaw.  With enough attempts, it is possible they could obtain the private key rendering the encryption ineffective.

I became aware of this Tuesday evening thanks to notes from three of our customers and installed the necessary upgrades to OpenSSL to plug this hole.

However, because a small possibility existed that someone may have obtained the private keys in that period of time, I generated new private keys and CSR’s and asked Comodo to re-issue new certificates which they were willing to do at no charge.

These new encryption certificates were installed today.  If you use web mail or the web ssh client, there is a very remote possibility that your password information could have been obtained.

To change your password, ssh to eskimo.com (the old SunOS shell server), and from the command prompt (if you are using esh for a shell, use ‘!’ to get to the command prompt), type “passwd“. (Don’t type the quote marks).  It will prompt first for your existing password and then the new password twice.

Even though this exploit has only been known to the public since Monday, and we closed the hole Tuesday, it has existed in the code for approximately two years.  My concern is that NSA, KGB, and other such agencies probably have known about it and exploited it for several years.

The chances of a random hacker exploiting it successfully in the day it was open are much smaller since not only would they have to execute the exploit repeatedly to get the private key, then they’d have to be in a network position to intercept that encrypted traffic.

Because a number of ISPs are blocking ports used by a number of our services as well as restricting your use of other portions of the Internet, I’ve created a new forum that provides methods of working around these restrictions.

Please see: ISP Work-Arounds

The web server has been upgraded to Apache 2.4.9.

This month of March we had very few new trial accounts.

I’m somewhat mystified by this because the feedback I’ve gotten from the Advise Us survey has been very positive.

Our visual shell service solves some broadly present problems in today’s environment.  Specifically, it solves problems of restricted access by providers and governments, and it solves the issue of securing information on portable devices.

For example, if you’re somewhere that peer-to-peer is blocked or harassed, and you need to get something you can only get peer-to-peer, such as the “Full Monty Desktop release of PcLinuxOs“, you can login to shellx.eskimo.com, scientific.eskimo.com, or debian.eskimo.com, using x2go or if you are on a Mac for which the x2go client hasn’t fixed the keyboard issues yet, you can use the NoMachine 4.1 client/player or OpenNX client on shellx.eskimo.com or scientific.eskimo.com to get a remote desktop from our server on your computer.  Then you can use qbittorrent to download to your home directory and then ftp or scp the file from there.  Note you will need an account with adequate quota for the file(s) you will be transferring, if transferring 3.8gb ISOs, a power shell is recommended.

With this arrangement, your provider only sees an encrypted ssh connection and has no idea how it is being used.

If by chance you are behind a corporate firewall that blocks port 22, we also listen to port 443, the HTTPS port, on scientific.eskimo.com or shellx.eskimo.com.  So our service provides you a way of getting a full desktop on your machine inside a corporate fire-walled network or say behind the great firewall of China, outside that firewall.

Or let’s say you’ve say you’re a corporate technologist, and you’ve been sent on a trip to India to establish a manufacturing operation using some sensitive information your competitors would love to get your hands on.  You could take that information with you on a laptop, tablet, or smartphone, where the possibility for that device to be lost or stolen exists and along with it your valuable data, or you could use a shell account here to hold it, and access it with your laptop, tablet, or smartphone over a secure ssh session when you get to where you need it.  That way, if you lose your device, you don’t lose your data and it doesn’t fall into the wrong hands.

Now, no service is 100% secure, but you can also save your files encrypted here for an extra layer of protection, and unencrypt them only when you’re actually ready to use them.

I do my best to stay on top of things and keep this site as functional as it can be for you.  The more customers we have, the more resources I have to keep Eskimo current, up to date, and to have adequate resources for everything you want to do.

So please tell others about our service and how it can work for them, and if there is something you don’t like, please tell me!

I apologize for the brief interruption on 1/30 at 13:00 to mail service.  I rebooted the client mail server just to make sure the fixes I made to start up and configuration scripts were working properly and that everything would function properly after a restart.

Issues with outgoing mail were the result of an update to clamav, the anti-virus software we use, which replaced my existing configuration file with a new configuration file that was not functional in our environment.

It didn’t break things at the time of the update because it did not restart the milter (a mail filter) at the time of the update.  It restarted later to rotate logs and at that point it broke outgoing client mail.

Things did not go at all smooth this morning, bad Ethernet cable required a trip to the co-lo, problems with sessions in NX took much time to troubleshoot, an upgrade to clamav and clamd screwed up outgoing mail for a while.  All in all not a fun morning.

As a consequence, I will be in a bit late this morning.  Please be patient, I need to get some sleep.

This evenings planned maintenance activity is taking longer than expected because just as I rebooted the main file server, the Ethernet cable connecting it to the switch decided to die.

I had to make a trip to the co-location facility to troubleshoot.  Since I had just upgraded the kernel my initial assumption was the new kernel had problems with the Ethernet driver or bridge.

After rolling back to the previous kernel and still not having network connectivity, I noticed the LEDs on the Ethernet port were dark.  I replaced the cable and they came back to life.

I then upgraded back to the newer kernel and everything continued to work.  I am
now doing imaging on shellx, ftp/www, and mail.

Live customer support will be unavailable between approximately 4:30pm-7:30pm today as I will be attending a dinner / seminar / sales pitch during this time interval.

If you need assistance, please e-mail support or call and leave a message with your name, user ID, telephone number including how late that it is okay to call, and the nature of your need and I will return your call, or e-mail as soon as possible upon my return.

Early Saturday morning we will be rebooting and imaging a number of servers.  There will be outages lasting up to about twenty minutes for the shell servers, ftp, and mail, and the main file server.

Except during the reboot of the main file server which takes about 20 minutes, other servers will not be all down simultaneously so if shellx is down, you can use scientific, etc.