Umm, like, I told ya so…

So, just a few days after I posted about new “stealth” maulware, Microsoft smartly added HackerDefender code detection to their MSRT (http://www.eweek.com/article2/0,1759,1785621,00.asp). Go download.

Virtual Ned 2005 Enterprise Edition

It has been quite a while since I last updated my blog. I suppose I really should be more diligent about updating, but I have been really busy working on some pretty interesting stuff.

Let me start off by saying that while I am a fan of virtualization technologies such as VMWare and MS VirtualPC/Server, they don’t fit the bill for everything. Most importantly, there are times when physical resources really are required, especially in low-latency or highly transactional applications. VMWare has some excellent technology with VMWare ESX, and virtual machines make tremendous sense when attempting to consolidate underutilized physical infrastructure.

The problem faced by many shops however, is that for every server consolidated physically, there still remains and operating system foot-print, complete will all that it entails, including such items as system maintenance, system administration and patch management. This brings me to my first point: the Windows world needs to embrace and learn how to implement native systems consolidation. What I mean by native systems consolidation is implementation of either more that one application instance on a given physical server, or the implementation of separate desperate applications on a given server.

Traditionally, the concept of native (multi-instance or mixed workload) consolidation has not been something most administrators and application support personnel have been comfortable implementing on the Windows platform. The general arguments being that Windows was not stable enough, scalable enough and that Windows didn’t provide the necessary tools for siloing resources for multiple applications or instances.

In my experience these issues have been largely addressed in Windows Server 2003. The core OS is significantly more reliable than previous iterations of the NT platform when subjected to heavy loads and the addition of Windows System Resource Manager to the mid-level Enterprise Edition of Windows 2003 provides a very effective tool for software based resource provisioning.

However, simply having a stable base platform and resource provisioning support is not, for business critical applications, enough of an argument for placing many eggs in one basket. The key is to combine high-availability solutions with consolidation. One of the solutions I have had tremendous success with is consolidating multiple applications and instances into an MSCS cluster implementation.

An example would be one that I am currently working on for my own company in which we will use a single four-node cluster with 1 node active for Exchange, 1 node active for file and print services (meaning no discrete application instances) that will act as the perferred fail-over for the Exchange cluster virtual server instance and 2 nodes running 8 SQL virtual server instances. For various application related processes, WSRM is used to prevent (especially during fail-over events) certain applications from monopolizing CPU resources on each node, while guaranteeing others a certain amount of CPU time (for more info and a on-line training for WSRM, see :
http://www.microsoft.com/windowsserver2003/techinfo/training/wsrm/default.mspx).

This solution, using 4 physical servers will support the application workload that, using a 1 to 1 server ratio, would have formerly required 10 servers. That is a 60 percent reduction in server count WHILE adding high-availability.

Of course, there is a little bit of secret sauce to this equation as those astute readers (like anyone reads my blog) may have noted. The solution if implemented using mid-line SANS would require a serious investment in storage. Specifically, a bare minimum of 24 LUNS would be required, which adds up to a lot of disks. The key is hardware computing and storage virtualization. This is where the cool stuff comes in. Egenera combined with 3Par storage solutions provides one of the coolest computing and storage solutions I have seen in a long time.

Egenera makes a blade computing solution they refer to as a BladeFrame. Where the BladeFrame differs greatly from traditional blade computing solutions is in the sophistication of resource provisioning. Each blade is essentially a separate solid state computing domain consisting of processors and memory. Everything else, including storage connectivity and network interfaces is virtualized and connected via a massively high-bandwidth backplane, much like a big-iron system such as a Unisys ES7000 or HP Superdome. Combined with a 3Par SAN storage solution, which provides highly flexible LUN virtualization (a whole lot cheaper than competitors) and you have the ability to build very flexible, very easy to provision, closely coupled clusters (I might add that you also get all kinds of neato recoverability solutions natively because LUN reassignment in an Egenera & 3Par computing environment takes very little effort and time and can be scripted, meaning that a failed blade can have its storage reassigned in very short order). Most importantly, since LUNS are virtual, they can be comprised of mere portions of a physical disk group and can be sized dynamically. This allows for large numbers of LUNS, which are all right-sized, preventing needlessly overbought storage.

With all that said, one company that has done an excellent job of leveraging the Egenera and 3Par solution is Savvis Communications. Savvis’s Utility Computing solutions are built around the Egenera and 3Par infrastructure (along with a critical physical networking infrastructure solution that I can’t speak to, provided by a company named Inkra). In a future posting I will describe Savvis utility computing model in more detail as it is the basis for the clustering model I described above. Needless to say this is really neat stuff when you put it all together. Combine all of this with a standard virtualization strategy and you can make some serious headway at reducing complexity.

Now for some ranting:

I have noticed a lot of whining and complaining in certain forums about the upcoming requirement that for future updates to Windows XP, SP2 will be a prerequisite. Quite frankly, I am astounded that people are complaining this late in the game. I understand that certain (though not nearly as many as some claim) applications break under SP2. Tough! There has been plenty of time to resolve these issues and SP2 provides significantly improved security and more than a few reliability improvements. To expect Microsoft to continue supporting pre-SP2 deployments for security patch and hotfix recursion testing is simply idiotic. Get with the program and quit complaining.

Last, but not least, a new breed of particularly nasty malicious code is coming soon to an insecure Windows system near you. Unlike previous generations of malicious code which could usually be identified pretty quickly by a knowledgeable person by examining the process list or modified system files, this new generation of code will likely adopt native NT API hooking as demonstrated in pioneering bad-guy code Hackerdefender (http://www.megasecurity.org/trojans/h/hackerdefender/Hackerdefender1.00.html). By the way, it’s called hacker defender because it defends the hacker, not the computer/user.

Now what does native API hooking mean? It means that calls to retrieve certain system information are filtered below the Win32 layer, effectively “hiding” processes (and any other system information deemed necessary by the malicious code) by returning only the information the malicious code wants you to see. This not only hides it from basic tools like Task Manager and Process Explorer, but potentially makes detection of code by AV products very difficult. Really not cool! (This by the way is nothing all that new, its just more people understand how to do it now than a few years back). Before I hear a whole bunch of “Windows isn’t secure by design” nonsense, it would be fairly trivial to effect the same type of attack on a ‘nix platform by doing the same thing to the ‘nix system call interface.

Now why do I bring this up? Because the best defense against this type of attack is one of my oldest recommendations: STOP RUNNING YOUR SYSTEM AS ADMIN! Yes, I know some apps don’t work well as a standard use, but as I have said before, learn how to use the runas command. Trust me on this, combining this with standard AV and anti-spyware software will prevent bad things from happening to your computer. This nasty code needs admin privileges to do its thing, so running as a standard users is the best first line of defense.

Well that’s it for this edition.