June 2006

Over the last few days, I’ve been trying to fine-tune the settings for the firewall on my PowerBook.  To configure the built-in ipfw firewall in Mac OS X, I use a shareware utility called Flying Buttress (formerly BrickHouse).  Every time I think I have the rules configured the way they should work, something is messed up.  There’s some kind of wierdness going on.

For example, I had the following rules defined in the Expert mode interface of Flying Buttress (rule numbers have been randomized):

add 11350 check-state
add 11351 allow tcp from any to any in established
add 11352 allow tcp from any to any out keep-state
add 11353 allow udp from any to any out keep-state
...
add 65000 deny log ip from any to any

I did not have any rules to specifically allow DHCP/BootP or DNS, since it was my understanding that those rules would be covered by the stateful outbound rule 11353 above.  What I found, though, was that DHCP and DNS information was being blocked and logged in Console.app.

I could kind of/sort of understand the DHCP thing, since my computer was apparently sending out a unicast UDP packet but the DHCP server was responding with a broadcast, and the broadcast didn’t “match” the dynamic stateful rule created by ipfw.  So, I added one rule:

...
add 11450 allow udp from any 67 to any 68 in
...

That solved the DHCP/BootP issue.  But what about DNS?&nbps; My laptop was configured for a specific DNS IP address, and I could see the responses from the configured DNS server being blocked by rule 65000 above (the default “deny everything else” rule).  What was up with that?

I understand the UDP is not a session-oriented protocol, and there isn’t the same idea of “state” as with TCP sessions.  However, all the research I performed (as well as my own experience with the pf firewall on OpenBSD) indicated that ipfw could maintain state for UDP conversations.  So why was the return DNS traffic being blocked?  I still don’t know why even now, but eventually I had to do the same thing with DNS as I did with DHCP:

...
add 11550 allow udp from any 53 to me 49152-65535 in
...

That finally allowed the return DNS traffic to be admitted.  I also experimented at various points with changing rule 11351 (the “tcp established” rule) to deny instead of allow, under the guise that the previous “check-state” rule would match a dynamic rule first, and that any traffic that didn’t match the dynamic rule probably wasn’t valid and should therefore be dropped anyway.  However, that didn’t work out so well, I think primarily because the lifetime for ipfw’s dynamic rules was shorter than the communication windows of some of my applications, and so the dynamic rules were expiring before traffic could renew the rule.  This particularly affected IM client traffic from my Adium client to MSN, AIM, Yahoo, and Google Talk.

If anyone has any insight on why exactly the rules weren’t behaving as I expected, please let me know.  Post in the comments for this post or even send me an e-mail directly.

Two articles recently surfaced amid the wave of information that deluges me daily, and both were regarding the extension of Group Policy—a key feature of Active Directory—into areas that were previously untapped.

First, there came the announcement of the FrontMotion Firefox Community Edition, a version of Firefox that is deployable and configurable via Group Policy in Active Directory.  With this build of Firefox, organizations can deploy Firefox and centrally manage Firefox settings via Group Policy, much in the same way that organizations can centrally deploy and manage Internet Exploder, er, Explorer.  (Sorry about that.)  Given that the lack of central configuration control over Firefox is one key sticking point to many organizations deploying Firefox en masse, this is good news.

Second, I saw the announcement of Group Policy for Mac OS X, from Centrify and their DirectControl for Mac OS X product.  DirectControl extends Group Policy to allow Macintosh-specific settings to be controlled centrally via Active Directory.  In addition, it also provides single sign-on (SSO) to Active Directory from Macintosh systems.  Of course, we know that we can achieve SSO to AD from a Mac today without DirectControl, but DirectControl also gives us the Group Policy functionality as well.  As a side note, it’s also worth mentioning that Centrify offers DirectControl for Samba (enabling Windows users to seamlessly authenticate to UNIX Samba shares), DirectControl for VMware ESX Server (for automatic provisioning of ESX Server accounts; not terribly useful in deployments using VirtualCenter), and DirectControl for ADFS (Active Directory Federation Services).  Pretty neat stuff, although I haven’t had the chance to see it in action yet.

These announcements show that independent software vendors are now becoming comfortable and knowledgeable enough about Active Directory to begin building these kinds of add-on products to extend the usefulness of Active Directory to non-Windows platforms.

As if Microsoft didn’t have a reputation that wasn’t already bad enough, now comes the news that their anti-piracy initiative—Windows Genuine Advantage—is “phoning home” to Microsoft every day.

According to this article, Microsoft has acknowledged that the Windows Genuine Advantage tool, installed automatically by Windows Update in order to “verify” the authenticity of the installed copy of Windows, makes contact with servers at Microsoft daily.  Supposedly this is to see if it should continue to run, but it also turns out that Microsoft may be updating the list of “invalid” Windows product keys.

Now this would be no big deal if Microsoft had fully disclosed this information.  (OK, so it wouldn’t be as big of a deal.)  Instead, Microsoft is now having to talk about this after others have learned of the tool’s true behavior.

Will Microsoft ever learn?

UPDATE:  A private firewall testing company has released a utility to remove the WGA Notifications portion, which is the portion that is “phoning home” to Microsoft daily.  See these links for more information.

eWeek article on the new utility:  http://www.eweek.com/article2/0,1759,1979756,00.asp
RemoveWGA:  http://www.firewallleaktester.com/removewga.htm

Yesterday’s edition of the “Security Watch” newsletter (also available online) contained a brief blurb about a whitepaper recently released by McAfee that contained a statistic regarding Mac OS X malware.  Intrigued by the mention of this whitepaper, I hunted it down and read it myself.

The whitepaper (available from McAfee’s web site) does indeed lead the user into thinking that security vulnerabilities from Mac OS X far outstrip those of Windows:

The National Vulnerability Database shows an increase of 228 percent in the annual vulnerability rate for Apple’s products from 2003 (45 vulnerabilities) to 2005 (143 vulnerabilities). In contrast, the annual discovery rate of vulnerabilities in Microsoft’s products only grew 73 percent over the same period.

What is failed to make completely clear is the number of vulnerabilities for each vendor.  In 2003, Microsoft had 92 vulnerabilities and in 2005, Microsoft had 159 vulnerabilities.  While this is explained via a footnote (does anyone ever really read the footnotes?), McAfee fails to properly contrast the numbers and the percentages, instead allowing this statistic to lead readers into believing that the state of Mac OS X security is in far worse shape than Microsoft’s.

I won’t belabor the point, as Russ Cooper (the author of the Security Watch column mentioned above) does an excellent job of pointing out why raw statistics like the number or percentage of vulnerabilities are very poor indicators of overall security quality.

All of this is not to say that Mac OS X is without security flaws and problems.  This article over at Linux-Watch.com says it perfectly:  “Linux is insecure. Open source is insecure. Windows is insecure. All software is insecure. Deal with it.”  Anyone who says otherwise is just plain wrong, and time will prove that to be the case.

So, while Mac OS X may not be “immune” to viruses and “free” of security flaws, at least you don’t hear stories like this one about it.

While I’m not a Citrix expert, I have designed, implemented, and supported Citrix environments for a while now.  I was therefore a bit surprised when I read an article about some of the unsupported features in Citrix Access Essentials.

The article references a Citrix Knowledge Base document that describes some of the unsupported features in Citrix Access Essentials.  Citrix Access Essentials, in the event you aren’t aware, is an SMB bundling of Citrix products in an effort to make their solutions more competitive in the smaller environments.

It’s fully understandable that vendors will remove certain pieces of functionality from their products when creating “SMB” versions; there are simply some things that smaller business don’t need their software to do.  In this instance, no one would expect support for multiple servers in a farm, load balancing of published applications across multiple servers, or similar features.  Small businesses just don’t need that.

What did catch my eye, though, was this note about Program Neighborhood and Program Neighborhood Agent:

Connections via Program Neighborhood or Program Neighborhood Agent are not supported. Only connections through Web Interface are supported.

Huh?  No support for Program Neighborhood?  This completely caught me off-guard.  This was not the kind of functionality that I expected Citrix to remove from Access Essentials.  This substantially differentiates Access Essentials from other Presentation Server-based solutions—not just by limiting certain enterprise-oriented features, but instead by removing common functionality.  The commonality of being able to use Program Neighborhood to connect to just about any server running MetaFrame or Presentation Server is now broken, since Access Essentials only supports the web interface.

Otherwise, the list of unsupported features is pretty much what I expected it to be.  If you work with Citrix Presentation Server in any sort of design, implementation, or support role, I encourage you to have a look at the full Citrix Knowledge Base document.

While browsing digg.com, I came across this article regarding the truth about switching to the Mac.  It’s pretty accurate, too, both on the good points as well as the bad points (and yes, there are a few bad points).

I can echo some of the author’s comments:

• It’s true that some people will “look down” on you for owning a Mac.  For the most part, your professional peers won’t really care one way or the other, but there are those occasions where people will make the comments like, “Whoa!  Watch out, he’s using out a Mac!”  The comments are made in a light tone, but there is an underlying hint of seriousness that gives it away.  I think that some of it is a lack of knowledge (see next point).
• Using a Mac will cause people to ask questions, and talk to you about your Mac.  On more than one occasion, I’ve had people ask me why I use a Mac, or what it is about Mac OS X that makes it so different from Windows, or if it’s true that Mac OS&nbps;X is more secure than Windows.
• I have to disagree about regretting the purchase when you switch; I switched almost three years ago and haven’t really looked back since then.

All in all, it’s a pretty good article, and it was particularly refreshing to see someone willing to point out the good things and the bad things about being a Mac switcher.  I encourage you to read the whole article.

In the next few days, I’m going to try out StrataGuard Free, a freeware version of StrataGuard, a Snort-based IDS/IPS.  StillSecure is making StrataGuard Free available as a VMware image for easy testing.

StrataGuard Free is rate-limited, meaning it only handles traffic streams up to 5Mbps.  Of course, that is more than sufficient for small businesses and home offices, and it’s a great way to become more familiar with the commercial product (StrataGuard)—which, of course, is not rate-limited and offers more features (such as automated rule updates).

I’m going to be trying out the VMware appliance on ESX Server in my test lab; hopefully, I won’t run into any hardware issues.  (Remember that my test of FreeNAS, which was also packaged as a VMware image, did not work on ESX Server due to a SCSI adapter issue.)  As soon as I get it up and working (or don’t), I’ll post more information here.

Thanks to DABCC for alerting me to the release of StrataGuard Free as a VMware image.

A recent posting on virtualization.info discussed a presentation at WinHEC 2006 regarding the Windows Hypervisor and its (projected) capabilities.  Here are my thoughts.

First, and perhaps foremost, Windows Hypervisor (code-named “Viridian”) is at least 3 years away.  Based on the above article and others, Windows Hypervisor is slated for released in the Longhorn R2 time frame (“Longhorn R2” would be the minor release scheduled for two years after the release of Longhorn Server).  That makes any discussion of Windows Hypervisor, its capabilities, its pricing and placement, etc., nothing more than vaporware—classic Microsoft vaporware.

Microsoft’s demonstrations of Windows Hypervisor seem to be like their early demonstrations of Windows Vista, which then got put on the chopping block and had most of the major features Microsoft had touted so heavily taken out.  WinFS?  Sorry, that’s not going to make it into Vista.  Live modification of virtual hardware?  Sorry, that’s not going to make it into Windows Hypervisor.

I’m sure that Microsoft will eventually deliver a hypervisor-based version of Windows, and that significant portions of the functionality that now requires Xen or VMware will be handled by the hypervisor.  I’m also reasonably sure that the product will be late and most likely will not have all the features Microsoft says it will have.  Finally, I’m equally sure during the two to three years that Microsoft will be baking the Windows Hypervisor that vendors such as VMware and projects such as Xen aren’t going to stand still; they will continue to innovate and drive the future of server virtualization.

Via thincomputing.net, I was alerted to the PN Agent Filter, a mechanism for hiding applications from the Program Neighborhood Agent.

Apparently (I haven’t yet tested it myself), it hides applications that have a “#” placed at the beginning of the published application.  Seems straightforward enough, but the real question I have is why?  If the PN Agent only shows those applications the user is authorized to see (based on the permissions of the published application), why do you need to hide applications?  The only possible scenario I can come up with is that applications should appear in an application set in the full Program Neighborhood client, but should not appear in the PN Agent.  In that case, a utility like this would be helpful.  But how often would this really be the case?