quuxpad

February 18, 2008: The Hacker's Diet

OK, I admit it. I’m in my 40’s, and I’ve gotten fat. In fact my Body Mass Index (BMI) of 32.5 says I am obese. O B E S E. Yuck, when did that happen?

Now at thise point I’m tempted to go on about how when I was younger I was always thin as a rail, could eat whatever I wanted, yadda yadda yadda. But you’ve heard all that before: it’s what all middle-aged guys say when confronted with their obesity. I’m also tempted to blame American lifestyle, mass media, McDonalds (or just corporate greed in general), my wife … oh, you name it, I’d like to blame it. And we’ve all heard that rap before, too. It doesn’t make anyone thinner.

But I’ve read The Hacker’s Diet (by John Walker) and I realize there aren’t any excuses. Also, there are no get-thin-fast cures, though a few years ago I had good (but temporary!) results from an Atkins diet over a 4-5 month period.

The answer is to find a system for a lifestyle change. The system you choose must be sustainable for the rest of of your life, or you’ll just get fat again. Now, you can take the time to read The Hacker’s Diet (it’s free on the web), but since I already did, I’ll give you the Quux Notes version:

1. Record your weight and calorie intake daily.
2. Compute weight gain/loss trend
3. Adjust calorie intake to make trend go in desired direction.
4. Optionally, excercise a little bit (15-30 minutes) a day. An easy calisthenics program is included.
5. Keep doing steps 1-3 (and optionally step 4) for the rest of your life.

That’s really the whole thing. There’s no call for diet pills, gym memberships, home exercise machines, milkshake mixes, attitude adjustments, special clothing, regular meetings… or anything else the get-thin-fast folks have been trying to sell you.

Oh, The Hacker’s Diet will explain why these things work, and give you some information about feedback loops and simple statistical analysis, and most importantly give you some tips on how to actually do this stuff. It’s definitely a worthwhile read.

But all you really have to do is start on the steps I’ve shown, today. Handily, Mr. Walker provides a free web-based tool for the weight recording and trend watching. I’ve just gotten through the first week and have lost a pound. It’s working.

Now all I have to do is devote 15-20 minutes a day (including the exercise) to this for the rest of my life. Shouldn’t be too hard …

(No, really, I’m serious. No sarcasm intended.)

February 17, 2008: What Google's honeynet found

This paper (pdf) is absolutely fascinating, in multiple ways.

The first thing that fascinated me was the infrastructure Google is dedicating to this malware analysis. They do a fairly deep analysis of a million web pages a day, by firing up a virtual copy of Windows (unpatched), telling it to go hit a web page, then seeing if anything bad happens to that (virtual) system within the next two minutes. Given that there are 1440 minutes in a day, this means that at any given time, they are running about 1400 virtual Windows systems in their honeynet.

Of course the other fascinating thing was the actual point of the paper: the malware analysis. There are a fair number of correlations they’ve found - 65% of malware sites in China, twice as many IIS infected sites as Apache ones, society and computer sites are more likely to have malware than porn sites (!!), etc. But two things really jumped out at me.

First, ActiveX is getting a bad rap. The paper reiterates that most of the client side exploits occur via javascript.

The second insight requires an explanation of the malware distribution model Google found. Here’s a quick diagram:

Basically, in (1) the client hits a landing site which contains a hidden link to one or more hop points, each of which redirects the browser to either another hop point or to the final link in the chain: the distribution site, which is the site hosting the malware for download by the client browser. That malware may go on to download more malware, but the distribution sites are the key.

And in 10 months, Google found 9,340 distribution sites. They found over 180,000 landing sites (a/k/a sites with links pointing to the distribution sites), which is troubling (because it means those sites were likely compromised in some way). But less than 10,000 sites hosting the actual malware is startling (in a good way!), because it means that it wouldn’t be very hard for a dedicated task force to shut a lot of them down. Or to simply tell all web browsers: don’t download from these 10,000 web sites, m’kay?

It gets better. All of the distribution sites are among only 500 Autonomous Systems (AS). An AS is essentially a group of IP’s under the control of a single entity such as a corporation or web hoster. And, get this: 95% of the malware distribution sites are under the aegis of only 210 Autonomous Systems.

So, Google could give their list of malware distribution sites to the 500 entities which own those 500 AS’s, and each AS entity would have (on average) somewhere between 18 and 50 sites to clean up. And malware via web exploits would be an almost solved problem.

Until the malware distributors found new web hosts, that is …

February 15, 2008: Microsoft/Yahoo

Oh, yeah. It occurs to me that a technical person with a blog more or less has to comment about the MS/Yahoo thing. Everybody’s doing it! And I did, on the day the news became public. But now Yahoo has said no, and MS has said they’ll keep trying, and all sorts of theories about motivations and futures are being put forth.

Bah, humbug. Here’s my ongoing sentiment about the deal:

I think it’s a silly strategy for MS. But aside from that, my crystal ball is extremely cloudy. And I just don’t have the bandwidth to engage in endless theories, theories about theories, comments on theories, and other miscellaneous rhetoric about the whole thing.

So, wake me up a few years after the deal (or deal failure) has concluded. By then I’ll probably have a better formed opinion based on facts. Till then, yawn, I’ll direct my attentions elsewhere.

February 15, 2008: The lessons of Amazon's S3 failure

Techie news sites have been all a-twitter about the Amazon S3 outage today. Many writers and commenters are venting their outrage and frustration, bandying about words like unacceptable and single point of failure and severe blow to confidence. Many seem to feel that Amazon has let them down, although Amazon’s SLA only promises 99.9% uptime.

There are a few lessons we can learn from this:

1. 100% uptime is not possible for any continuous service. Even the electric company, which has a much more mature, redundant, and well built-out system, experiences failures. Your data network will too.
2. Know your SLA. Really know it - exactly how it is measured and calculated, exactly who pays, and how much, when an SLA is missed. If you are the entity offering the SLA, are you sure you understand it? Are you sure you’ve done everything possible to help your customers understand it?
3. Be ready for the downtime. Ask yourself right now - if all computing systems were down, what would happen? How would my life and my business continue to operate, what would the priorities be? Do I have a way to meet those priorities?
4. Be ready and able to fully inform (or be informed) when downtime does occur. It’s not something you can sweep under the rug. People will notice it - and they’ll be a lot happier with candid and truthful answers.

Failure happens. The question is not if failure will happen, but when it will happen. The next question is how you’ll handle it when it does happen to you.

February 11, 2008: Troubleshooting XP's Offline files

I recently had an a problem with XP’s Offline Files. The system was XP Pro SP2 with all updates thru Feb 2008. Folder Redirection of the users’s Desktop and My Documents  folders is accomplished via Group Policy from the domain; the user had then set Offline Files to keep a local cache of the redirected folders. The computer displayed the following symptoms:

• Offline files never synchronize
• mobsync.exe (the Synchronization Manager) ate lots of CPU for days on end, and on shutdown or logoff, failed to gracefully shutdown, presenting dialog with “The program is not responding”
• The mapped drive where the offline files were redirected to (by domain policy) didn’t show all files that should be there - even the files/folders outside the redirected folders were incomplete.
• dir \domainname\sysvol failed - this was a big problem! GPO’s could not be applied
• Because of above, gpupdate /force would always create a USERENV 1058 error in Application Log
• logout took a really long time

It wasn’t really a pressing problem, but it was on my to-do list. I took a stab at it from time to time but never quite solved it. Today I finally took a systematic approach to the problem. Notice that it looks like two separate issues - GPOs failing to apply, and the local DFS client being terribly confused.

What finally did it was the following, in concert:

1. dfsutil /purgemupcache (dfsutil.exe is in the Windows 2003 Support Tools)
2. Checked the following Registry values (two were not present): HKLM\System\CurrentControlSet\Services\Mup\DisableDFS=0
   HKLM\Software\Policies\Microsoft\Windows\NetCache\Enabled=1
   HKLM\Software\Microsoft\Windows\CurrentVersion\NetCache\Enabled=1
   (The first is documented at EventID; the other two are documented by Jonathan Hardwick.)
3. Kill the mobsync.exe process
4. Re-initialize CSC cache as explained in Method 1 at KB230738. (Note that performing this step without killing mobsync didn’t have any effect.)
5. Reboot the system as directed.

After the reboot, both the GPO problem and the DFS problem went away, and I was easily able to Synchronize Offline Files. Finally, this nagging issue was off my plate. Hallelujah!

The interesting thing about this is that the Event Log was full of pointers to the GPO problem, but had nothing about the DFS problem, which was the real root of the issue. It’s just another reminder that the Troubleshooting Ninja needs to avoid tunnel vision and stay aware of all the symptoms a sick computer displays. And (regrettably), XP’s DFS client needs to log more to the Application Log!