Feed: The PureBlog - AggScore: 71.8

The last week or so we've seen a dramatic rise in a particular type of scam email, both to our personal inboxes, and more recently, to clients as well, the emails in question usually reads something like this:

From: noreply@
To: @
Subject: A new settings file for the has just been released

Dear user of the mailing service!

We are informing you that because of the security upgrade of the mailing service your mailbox () settings were changed. In order to apply the new set of settings click on the following link:

Best regards, Technical Support.

---

The second version we've seen omits the link, but actually has a zip file attached to the email that you are encouraged to open and run.

Let's just get this out of the way, These emails are not from our technical support staff, the emails are most likely designed to lure you into running the file (or visiting the website) in order to infect your machine with some form of... bad thing. Maybe it's spyware, maybe it's adware, maybe turns your machine into a bot and proceeds to start spamming out the same email to other unsuspecting folks.

It's extremely rare that anything we do will result in you getting an email from us that says it's from @yourdomain, there are, I believe, a couple of automatic emails (bandwidth warnings, etc) that may appear to come from email addresses such as "no-reply@ourservername.purenrg.com" or whatever, but never, ever, that I can think of, have we ever sent out an email that wasn't from @purenrg.com (not to say that someone couldn't spoof a fake "From" using our domain just as easily).

Moreover, I can't think of any instance where we've *ever* emailed a zip file to a client asking them to upgrade anything with it, especially to "update your email"... email settings are either entered by hand in your mail client software, or perhaps using the auto-configure links provided inside your cPanel, but never (Atleast from us), via an exe or other program file provided via a somewhat vague email from a invalid email address pretending to be your domain.

Normally we don't post about every new scam or virus email, but we've seen this one pop up quite a bit recently, and wanted to try and provide this post just in case. :) If it prevents one person from getting infected with whatever the payload is in that attachment, then it's worth the effort to post about.

Date Published: Oct 16, 2009 - 10:15 pm

Pushed a couple of changes out to the live website earlier today, aside from security updates (moving to Drupal 6.13) there's a few small things worth mentioning:

- Some more enhancements to the reports/tracking available to our Hosting Affiliates. Most of these changes and additions were the direct result of feedback from our testers and early adopters in the affiliate program. Please feel free to keep the feedback coming. ;)

- "Affiliate Links" block added to the site for affiliates. Folks who are logged into the site and have already joined our web hosting affiliate program will notice a new block over on the right side of the site. It contains the direct url for the page you are on, with your affiliate ID code already inserted (there's also a "share" button which is loaded with your personalized affiliate url as well). When we wrote the "Get Links" page for the affiliate program, we had a bit of a problem expressing "every page on our site can be used as an affiliate URL, just add your code".. so the block helps with that.. if you see the block, you can grab your own custom affiliate link for that specific page. ;)

Today I'm happy to unveil our new Affiliate Program, an easy way for clients and webmasters to earn commissions by referring others to our service. Word of mouth has always been a crucial method of marketing for us, and this finally sets up a framework for us to begin rewarding those folks who've been so crucial to helping spread the word. :)

Full details and the signup form can be found on our Web Hosting Affiliate Program page.

I also wanted to take a moment and thank the handful of people who've been helping us test this over the last couple months while it's been in development, there were the occasional glitch they helped us iron out, but most importantly, the feedback we received from our testers regarding the tracking and reporting system were incredibly valuable.

The previously discussed upgrades to Apache 2.2 will be occuring this morning. Downtime for each server should be 15-20 minutes at most. We will post a follow up to the news section once the update is complete.

Ever since early in the year it has been a goal to get all servers upgraded to the "latest and greatest major branches" of software... we started by introducing PHP5, then MySQL5, and now, finally, we'll be moving all servers over to Apache 2.2.x to replace the current 1.3.x lineup. We had actually looked at making this jump back when we first implemented PHP5 in January, but some glitches that cropped up during the testing phase left us well, concerned, and ultimately we decided to put the upgrade off a bit longer.

Over the next few weeks we will be doing some final testing with Apache 2.2.x and hope to have it ready for roll out to all servers sometime around the first week in December. The goal is to take advantage of some of the new performance gains to be found with 2.2, and clients should, with the exception of a brief outage while their server is upgraded, not notice any major differences to their account or it's behavior. Except maybe a bit of a performance boost, but nobody ever complains about those. :)

"It's getting there."
"No idea when it'll be done."

That's been me for the last two weeks, and in reality I'm not sure that I'm much further along then I was 14 days ago. I'm supposed to be in charge of the "Agents" for the new monitoring system. Little programs (not php code) that will run on a couple of servers around the internet and keep tabs on all of our services/equipment, and report their findings back to the main system and trigger alerts when something breaks.

Development of the monitoring system is still proceeding, albeit slowly, and it's pretty much my own fault. Making the jump back into regular old C++ development to code the monitoring agent programs after all this time has proven to be a bit more of a challenge then originally thought. The problem, believe it or not, is that PHPⁱ has spoiled me with it's easy to implement nature. :) I find myself constantly going "What do you mean you can just do it *this* way?" and then tracking down some obscure method to do the exact thing I need to do. I cut my programming teeth on C, and at one point used to pretty much dream in C++, but the last few years I've done pretty much nothing but PHP work, and it's showing now that I'm trying to go back to my roots and knock out this "quick little project" (Last time I'll use *that* phrase)...

Right now I have a binary that runs, spawns itself as a daemon, and retrieves an XML configuration file from the monitor master every X seconds... oh, and it can store some configuration variables in a local file. Yippie. I haven't even gotten around to writing the actual service checks themselves yet. The problem of the day? I need to figure out how to take the contents of that XML file (A list of servers and services to watch, and details of each such as service type, how often to test them, what ports they run on, etc) and parse them out in a manner that I can use elsewhere in the program. I've been through one XML parsing library for C++ already trying to make it work, ultimately tossed it aside, and the second one is quickly making my head hurt just as bad. It's not that C++ has gotten "harder", it's just that I'm way out of practice, and spoiled by the easy way everything flows in PHP, not to mention the sheer volume of information, libraries and resources out there for PHP compared to C++. Things that we take for granted in PHP (SimpleXML!) you end up scrounging around trying to find a library someone else cobbled together, or banging your head reinventing the wheel in C++.

Anyway, as a consolation prize, or perhaps as penance, the powers that be have decreed that I should post a blog entry sharing where we're at with the monitoring system, why it's not done yet, and share a couple of screenshots of what will, one day, become the monitoring system with everyone, to whet the appetite I suppose.

So here you go:

(Those of you with java reliable browsers only see one small little screenshot.. click it to blow it up bigger and see the other as well)

You'll notice the distinct lack of "Service Status" information on the first screen. Yeah, that is where the page is supposed to list all the pretty details as reported by my precious monitoring agents, but it's not... because there is no information... because I haven't finished them yet, so they can't report anything... oh well. Back to the drawing board.

Late yesterday afternoon the website here was updated from our subversion repository, and included in that update was the start of our new Network Status/Monitoring system. It is nowhere near complete, but it is beginning to take shape enough to start tinkering with it on the live site and collecting data.

What we have so far is the beginnings of the "master" for the monitoring system, integrated into our Drupal setup here. What is done so far in the code includes:

• Network Status Block - Will reside in the basic layout of our site (most likely on the right-hand side near the "Proudly Utilizing" block) and provide a quick "at a glance" way of seeing if there are any problems with our network.
• Network Status Page - Will provide a detailed list of everything in the network, along with a detail page for each device that will show Network Health measurements, System health measurements such as System Load, Memory Usage, Drive Space.
• Basic Network Health Monitoring - Network health and system health information is collected on a regular basis by the master and stored in the database.
• Communications support for the Monitoring "Agents" - The plan is that we will have multiple "agents" running on machines in multiple physical locations to monitor specific services (web server, mail server, etc) on each machine. These "agents" will need a central place to report their findings, and retrieve information about what they should be monitoring exactly. The master system as implemented so far has the beginnings of that communications stack already in place.

There's still an enormous amount of work to be done before we'll consider the project "finished" however, as the actual "Agents" themselves that will poll specific services still need to be written and deployed, and there is no actual "alerting" or reactions to any of the data collected. So obviously we've got a ways to go yet, but we wanted to get what we have in place awhile, so we can begin to record some actual data from the servers on the things that are in place (Network health, load averages, etc) so that we can verify it's working as intended, and also so we can get some ideas of what is "normal" for the new system, so that we can set the appropriate levels for the Alerts to kick in when the alerts portion is finished.

Last night after updating the code on the site, I spent a few moments tinkering with the module, before I realized that I had the permissions for the module set to "Staff Only", so everyone who visited the site was seeing the "Network Status" block and resulting data. There is nothing wrong with that of course, as the entire goal is to get more information out to everyone, but seeing as how the system is currently only collecting about 10% of the data it should, doesn't have all the correct devices in it yet, nor is the actual "status page" ready for public use yet (it has a lot of code debugging messages sprinkled throughout), I pulled the block from circulation once I realized what I had done.

This was the cause of the "mysterious disappearing block" that a couple of people reported last night. It is coming, hopefully within the next week or two there will be something firm to share with everyone... lets just consider last nights limited appearance a "sneak preview" if you will. :)

Had a bunch of changes uploaded to the live site over the last week, the only really noticeable one being the switch from "Share This" To "Add This" icons. The ShareThis icon just didn't look right to me on our layout for some reason. A petty reason to change, I know, but it irked me something fierce, just think that the AddThis based buttons look better.

Most of the recent changes have been behind the scenes, trying to tidy up quite a bit of API related functionality that we had previously started implementing in August: APIs for 2CheckOut, PayPal, and an API for the Datacenter's management system as well. So far there's nothing actually in production that uses these new APIs, but they are there and working for us to implement down the road. (Most notably for us, automating the recording of a successful payment into our system, no more manually entering a list of payments each day).

Right now we're refocusing everything into implementing the new Monitoring System, it has sort of grown into something more then just putting a pretty face on what we have already in use. Part of the hold up being that we've decided we need to write the monitors (yes, plural, we intend to monitor all systems from multiple locations, instead of relying on one central monitoring process) themselves as standalone C programs, which will retrieve their configuration from a central location, and then report back successful or failed monitoring attempts as they occur.

Basically we're building a whole new monitoring system from scratch, so it's going a little slower then we originally thought it would. But there is progress being made, so hopefully we'll have something to show for it soon.

As we've previously announced and discussed, we will be dropping support for PHP4 entirely from our servers as it has been discontinued by the PHP Team and no further fixes/upgrades will be coming for it. We currently we estimate this process will be completed across all server before the end of October, barring any severe security exposures in the current PHP4 release before then that causes us to accelerate it's removal.

We do not anticipate this being a widespread problem, as all client sites have been defaulting to using PHP5 for well over 7 months now. If by some chance you have a PHP script on your account that you are currently running in PHP4 mode specifically, and you have been putting off upgrading it to work with PHP5, now is definitely the time to do so.