December 31, 2007

Production Virtualization for SMB

I'm a big fan of virtualization. Most of you know that. But you probably don't know that we use SBS + SCVMM together very successfully around here.

Recently I wrote a post over on Microsoft Canada's TechNet IT Pro blog about Production Virtualization for SMB - SC-VMM, Server 2008 and Virtual Server 2005 R2 SP1.

When I show people how cool SCVMM is, the first thing I hear is about how expensive it must be. It's not. Microsoft is coming out with a SMB version in the new year which they are calling "Workgroup Edition". That allows you to manage 5 hosts and as many guests as you like, for about $100 a physical box. Great value for the money when you consider the centralized management and great visualization. Never mind the VM checkpoints which makes patch management much easier to manage.

So check out the post. And then give SCVMM a try. You might be pleasantly surprised how well it works in the SMB space.

Posted by SilverStr at 01:39 PM | Comments (0) | TrackBack

December 28, 2007

Bloglines DOESN'T suck. The dynamics and power of WOM and blogging

I love my circle of influence. I am friends with some amazing people, with influence across many gambits. And that circle reminds me why word of mouth, combined with blogging goes a long way in the way we live each and every day.

Only yesterday I blogged that I was having real difficulties with Bloglines reading Robert's feed. This was after I talked to someone inside Bloglines who told me this was an issue with how the feed was being intepretted. Robert saw my post, and wrote his own post (in his always controversial subject line way) that got the attention of Paul over at Bloglines who responded in kind.

Paul made it clear that the issue related to how their "Last-Modified" feature worked. As an interm fix, he disabled how that worked, and sure enough... it's working fine again.

Funny though, shortly after this all transpired Matt from Wordpress commented on Scoble's post that this was indeed an issue with how Wordpress was handing things, and that they are working on a fix for the bug. That's right... it's Wordpress's issue... NOT Bloglines.

So in just 24 hours, both Bloglines and Wordpress are on it... OVER the HOLIDAYS!. That's the power of word of mouth and blogging.

Now, I received a few comments and a LOT of email from people telling me to drop Bloglines and move the Google Reader. Forget that. I am a HAPPY fan of Bloglines. I have been using their new beta for some time now, and its been an AWESOME asset to how I manage all the feeds I read on a daily basis. I have tried Google Reader and just don't like how it lays out, how it handles the displaying of content and just how it works. I love the way the Pin and Save Library in the new beta works along side the new UX, and there is no way I am going to abandon a tool that is maturing like this that just works for me. Ya, they had an issue here... but the way they handle Last Modified content is MUCH nicer that how Google does it. At least for now (when it's turned back on) anyways.

My only complaint with Bloglines is their attitude towards support sometimes. Not with me directly. As you can see, thanks to someone I know inside Bloglines and Robert's post... it cascaded to a fix pretty quickly. What bothers me is the number of people that have commented on Robert's post, in the forums and in email to me that they are getting no help from Bloglines when they saw this issue earlier. Which has caused by my count at least 10 people in my circle of influence who have abandoned the service. That's really to bad. You really need to try the beta!

And I cringe when I see people like Paul say things like "In regards to placing blame". Holy cow. This isn't about blame. It's about just getting the damn thing fixed. BTW, if Bloglines is reading... you can close the latest support case on this matter. It's being addressed :-)

I love Bloglines. Their team makes great stuff. And as we can see over the last 24 hours, they do indeed care about what they do... as long as it gets enough attention in the community. Again... WOM and blogging reflecting the power of change.

Thanks to Robert, Paul and Matt for getting things together to make the blogging world a better place. And for reducing the number of duplicated posts from Robert. There is only so much Scoble one can take :-)

Posted by SilverStr at 01:36 PM | Comments (1) | TrackBack

December 27, 2007

The battle between Bloglines and Robert Scoble's feed. Enough already!

Ok, I don't know if it's Bloglines or Robert Scoble's feed, but the duplication has to STOP already. Or I will be forced to unsubscribe from Scobleizer.

Robert, Bloglines says it's not them... so I am turning to you. Every time you post a new item in the feed at http://scobleizer.wordpress.com/feed/ it seems that the previous 50 items get "updated" in the last modified date... making me have to wade through the same posts EVERY time you make a new one. It's crazy... I have over 500 feeds to wade through every day, and an extra 50 posts from a single feed in that category is quite detracting. Why the heck is your feed updating the date on each post???

Please fix it.

Posted by SilverStr at 11:42 AM | Comments (13) | TrackBack

December 08, 2007

You really think that can stop me? Another example of secuity through obscurity which is futile.

So the last few nights I have been doing a bit of research on AJAX UX, where I came across a site that I found interesting. I went to "View Source" to see how they were doing something and the darn thing wouldn't let me, with some progammer's brain drain of a secure method to prevent that action. This annoyed me a bit and I decided to figure out what was going on.

This sort of protection shows why security by obscurity is a poor security safeguard. It takes very little to bypass it. Especially since this is code on the client side being rendered. I could of course simply sniff the traffic, but there is a simpler solution which I figured out pretty quick.

My solution? Inject a bit of Javascript into the session and barf out the innerHTML in a popup window. :-)

So the next time you come across somebodies idea of copy protection for web content, try typing this in your URL bar and hit enter:


javascript:window.open( '', '', '' ).document.write( '<textarea cols=80 rows=40>' + document.body.parentNode.innerHTML + '</textarea>' );

Blows by such idiotic protection schemes that gives a false sense of security to the content owner.

Normally, I wouldn't show this sort of thing publicly. I contacted the original site webmaster to explain this attack vector to his code, only to receive a nasty email in poor taste where he referred to me as a "two-bit wannabe hacker that doesn't know what [I am] talking about" (his words... not mine). It's this kind of attitude of many web developers that has me up in arms, and has me feeling its appropriate to show the attack.

Posted by SilverStr at 10:49 PM | Comments (6) | TrackBack

December 02, 2007

Don't waste your time renaming the Administrator account in Windows

There has been a LOT of recent attack attempts against Windows Server when it comes Terminal Services logins, and many communities I belong to are all in arms on how best to protect themselves against this.

First off, some people have been recommending using stronger password policies that include lockout thresholds. Great idea, but useless against the primary Administrator account; it is NOT allowed to be locked out. In other words, you can set the duration and threshold all you like in group policy... a DoS attack won't lock down the account. Nor should it. That would be an insanely easy way to make a Windows Server ineffective otherwise.

Lately I have been hearing advice by proficient security professionals that renaming the Windows Administrator account is a first step best practice, and I thought I would debunk the myth that this will solve your woes when it comes to attacks to a Windows server.

Security through obscurity isn't always a bad thing. After all, renaming the Administrator account prevents an adversary from easily guessing or brute forcing the username/password to log into the system. But security through obscurity alone is not a proper defence against this attack vector.

It is true that it makes it harder for an untrusted user to log into your server remotely. However, there are simple ways to collect the information in indirect ways. If the adversary can get a trusted user on your network to execute a single script, the game is over. You see, the domain administrator account on a Windows machine is ALWAYS in the format of S-1-5-domain-500. Through WMI or pure Windows API it is possible to first get the full domain SID for the admin account, and then use that to get the name currently associated with the SID. In other words, it can rip through your defense like a hot knife through butter (so to speak).

Of course, it is possible to create a SECONDARY admin account which does NOT fall under the "500" SID issue, and it can have full control of the domain just like the primary account. Then by disabling the primary admin account, this attack vector gets plugged up.

But does it?

When deploying a security safeguard to reduce the risk of exposure in this way, we need to weigh the benefits against the drawbacks. And we need to evaluate if the risk reduction impacts other parts of the system(s) in question that may actually cause MORE problems than it's worth. It is something I commonly refer to as "relational security". The impact of deploying a technical safeguard may adversely affect other parts of the system, which may make the safeguard an unacceptable solution.

This is such a case. In some Windows servers, such as SBS 2003, there is a reliance on the "Administrator" account for scheduled tasks, jobs and wizards. Renaming the account could actually BREAK some of the services on the system, impacting the system in a negative way. Many 3rd party applications and installers LOOK for this specific 500 account and will not install, or will install incorrectly, making this sort of "best practice" much less effective; it causes other systems to function incorrectly and possibly opens the system to more risk due to misconfiguration or poor installation. So you should be leaving the Administrator account alone.

Another recommendation I have heard was to simply change the Terminal Services RDP port from 3389 to something else. This is ludicrious. A simple nmap scan with fingerprinting will expose the alternate port in just a few minutes. Although you may be raising the bar, we are talking millimeters here; most script kiddies already blow by this sort of defense.

So what is the proper solution? How DO we prevent adversaries from attacking our Windows servers and brute force the account?

How about not letting them connect in the first place?

This is the whole point of least privilege and access control lists. You can easily apply an ACL on the firewall for the 3389 port and only allow trusted hosts to connect to it. Problem solved. Now unknown and untrusted users cannot even send an attack to the server. But what if your remote users do not have static IP addresses? Fine. Nothing prevents you from using an ISP class C block as allowed hosts, eliminating foreign hosts who are usually the ones trying to get in.

Remember, security is about risk mitigation, NOT risk avoidance. If we cannot prevent EVERYONE from connecting, we could atleast reduce it to a very small portion of the world. That would increase our security posture immensly.

But what if you need more security than that? What if you are worried about people that WILL have the opportunity to connect in? Then use identity assurance technology like strong authentication. Two-factor authentication solutions like AuthAnvil can bind the login transaction to a physical hardware authentication token, ensuring that the person logging in is indeed a trusted user allowed access. And this offers you the ability to loosen the ACL on the port and put the authentication check squarely on the incoming user.

So don't fret about renaming the Administrator account on a Windows Server. Instead prevent people from accessing it in the first place. And when that isn't available, consider using strong authentication to provide identity assurance before they can even log in.

YMMV. But I'd rather focus on more interesting pursuits than worrying about door rattling from automated script kiddies. Wouldn't you?

Posted by SilverStr at 04:18 PM | Comments (1) | TrackBack