blog.scottlowe.org

I found this little post while searching over at Technorati.  How true!

This is something that only a computer junkie could enjoy.  In conjunction with the FUSE project (now an official part of the Linux kernel as of version 2.6.14), an SSH-wrapped remote filesystems—called sshfs—has been created.

This recent article describes sshfs in a bit more detail and provides some additional information.

So what does this mean?  It means that for any remote system you can reach via SSH, you can mount that remote system’s filesystem inside an SSH tunnel.  I can think of numerous possibilities, not the least of which involves easily updating a web site hosted on a remote web server without having to FTP (or SFTP) the files back and forth.

Now, if only there was a Mac OS X version of sshfs…it’s currently only available for Linux and FreeBSD.

Not suprisingly, Microsoft’s moves to “open” up its XML-based file formats for current and future versions of Microsoft Office have swayed the State of Massachusetts back to its side again.  Get the details here.

Microsoft recently made a move to “open” up its XML-based file formats for Microsoft Office 2003 and the forthcoming Office 12.  These file formats were offered to ECMA International for consideration as a formal open standard.  However, the “license” for these file formats was merely a promise not to sue people violating its patents on the use of the file formats.  Read more here.

Also see these comments from a legal analyst regarding Microsoft’s Patent Protection Covenant.

Personally, a promise “not to sue” from any large corporation—not just Microsoft—wouldn’t be good enough for me were I a developer.  Somehow, I don’t think that many developers are going to feel completely comfortable incorporating Office 2003/12 XML-based file formats into their applications based solely on the Patent Protection Covenant.  What happens when (not if) the covenant changes?

As a follow-up to my posting Zero-Day IE Exploit, it has now been discovered that this exploit is no longer just a denial of service (DoS) flaw, but rather a flaw that can allow remote code execution (see here for more information).  As of this writing, there is no patch for this vulnerability and the only workaround is to disable Active Scripting in IE.

For your convenience, here’s a link to a Microsoft KB article that describes how to disable Active Scripting.

Alternately, you can just switch to Firefox (which, by the way, is supposed to release Firefox 1.5 sometime today).

I originally published this information on my business website, but thought I’d reproduce it here in the event someone needs it.

Apple’s Bonjour (formerly Rendezvous) auto-discovery service is used in a number of Apple-branded products as well as a growing number of third-party applications (for example, my HP Color LaserJet 2550N supports Bonjour).  It’s used to advertise and discover iTunes music libraries, and Apple’s Airport Admin Utility also uses Bonjour to discover Airport Extreme and Airport Express wireless base stations for configuration.

Bonjour uses multicast DNS (known as mDNS), part of the IETF standard known as Zeroconf.

All that is well and good, but if you are using the built-in firewall you most likely are preventing Bonjour from working correctly.  I grew frustrated trying to utilize Bonjour-related services while also keeping my PowerBook protected against unwanted network traffic.  Using a packet sniffer and Brian Hill’s Brickhouse application, I observed Bonjour traffic and created a set of ipfw rules that can be used to allow this traffic.

Multicast DNS operates over UDP (IP protocol 17) with a destination port 5353 and a source port above 1024. The destination address is, of course, a multicast address (in the 224.0.0.0 range).  Responses to mDNS multicasts originate from UDP port 5353, but are bound for a random high port above 1024. Simply defining a rule that allows traffic to and from UDP port 5353 won’t work, because while outbound traffic will be correctly matched the responses to those outbound requests won’t be matched and will be dropped (assuming the default action is to deny traffic). So, a sample rule to be added to ipfw might look something like this:

add 2008 allow udp from 10.1.1.0/24 5353 
   to any 1024-65535 in via en0

(I’ve wrapped the line above for readability, but it should be entered all on a single line.)

This rule allows traffic from the source network 10.1.1.0 (the “/24” indicating a 24-bit mask, i.e., a subnet mask of 255.255.255.0) from UDP source port 5353 to any port above 1024 on any destination address inbound via the en0 interface.  The en0 interface is typically the built-in Ethernet interface on most Mac OS X-based systems.  (Likewise, en1 is typically the built-in AirPort/AirPort Extreme wireless interface.)

If you are tightly restricting outbound traffic as well, you’ll need a matching outbound rule (of course).

My own experience has shown that adding this rule to my ipfw ruleset has allowed Bonjour to work as expected without sacrificing the security of my system.

I love DVDs.  Ever since I bought my surround sound system around Christmas of 2000, I have preferred DVDs over VHS for any new movies that we purchase.  The big problem, though, is that DVDs aren’t nearly as durable as videotapes, and in a family with kids that’s a big deal.  I have younger kids, and it doesn’t take much for a kid to scratch a DVD when putting it into or taking it out of the DVD player. All it takes is one scratch and that’s pretty much the end of that movie.

Even before I switched to Mac OS X, I have been making digital copies of every CD that I purchase, so that I can quickly and easily make another copy in the event that the original CD gets damaged in any way.  The introduction of iTunes and my iPod have made this easier.  I hadn’t considered, even with the introduction of the 5th generation iPod with video capabilities, that I could do the same with my DVDs until just the other day.

So I set out to see if it was possible to do the same with my DVDs.  I’d researched this a little bit earlier, so I already knew about MacTheRipper (MTR), a program for extracting the digital video from a DVD.  I used MTR to extract the video for I, Robot to an external FireWire hard drive attached to my PowerBook.  That process went well, didn’t take too terribly long, and the resulting VIDEO_TS folder created by MTR worked flawlessly using VLC.  I then turned to a program called DVD Imager, which is designed to turn a VIDEO_TS folder into a DVD image that can be burned to a DVD.  The problem, however, was that the VIDEO_TS folder and the resulting DVD image were 6.87GB in size.  As a result, I was not able to burn the image back to a standard DVD-R using my PowerBook’s SuperDrive.

I tried another DVD (Robots this time) and ended up with 4.62GB of data.  OK, I thought, a single-layer DVD holds 4.7GB of data so I should be fine.  Wrong!  That didn’t work, either.

That means I’m currently stumped as to the next step.  A number of online searches have turned up recommendations for Popcorn (from Roxio), but I’m trying to see if I can avoid having to purchase software and instead make do with freeware and/or open source applications.

For those of you that celebrate the holiday, I’d like to wish you a very happy Thanksgiving.  May the Lord richly bless you in the coming year!

Rather than publishing this information in PDF form on my business website, I’ve decided to try something new and post it here as a blog entry.  So, here goes.

This information assumes that you have some experience with the Cisco PIX firewall (i.e., you know how to enter configuration commands and have a basic idea of what the configuration commands actually do) as well as some experience with Windows and Active Directory.

With that information in hand, let’s get started.

Configuring the Cisco PIX

First, we’ll need to setup the PIX firewall.  Use the commands below to configure the PIX for PPTP-based VPN connections that will authenticate against an Active Directory back-end.

ip local pool vpn-pool 10.10.10.1-10.10.10.254
aaa-server vpn-auth inside host 10.10.10.5 secretkey
aaa-server vpn-auth inside host 10.10.10.6 secretkey
aaa-server vpn-auth protocol radius
vpdn group vpn-pptp-group accept dialin pptp
vpdn group vpn-pptp-group ppp authentication mschap
vpdn group vpn-pptp-group ppp encryption mppe 128 required
vpdn group vpn-pptp-group client configuration 
    address local vpn-pool
vpdn group vpn-pptp-group client configuration 
    dns 10.10.10.5 10.10.10.6
vpdn group vpn-pptp-group client configuration 
    wins 10.10.10.6 10.10.10.5
vpdn group vpn-pptp-group client authentication aaa vpn-auth
vpdn enable outside
sysopt connect permit-pptp
access-list acl-nat0 permit ip 10.10.1.0 255.255.255.0 
    10.10.10.0 255.255.255.0
nat (inside) 0 access-list acl-nat0

(Note that I have placed a backslash to indicate text that is wrapped onto two lines here but should be entered all on a single line in the PIX configuration.)

In this configuration, replace the IP addresses on lines 2 and 3 (the “aaa-server vpn-auth” commands) with the IP addresses of the servers running Internet Authentication Service (IAS) on Windows.  See the next section for more information on configuring IAS.

On those same lines, replace the text “secretkey” with the RADIUS shared secret that will be used when configuring the RADIUS/IAS server in the next section.

Likewise, replace the IP addresses on lines 9 and 10 (the “vdpn group vpn-pptp-group client configuration” lines that pass out the DNS and WINS servers to VPN clients) with the IP addresses of your DNS and WINS servers, respectively.

That should do it.  Save the configuration to the PIX and then move on to configuring IAS.

Configuring Internet Authentication Service

Before doing anything else, create a new global security group in Active Directory.  Call it something like “VPN Users” or similar.  We’ll use this group later as an additional security check in validating VPN connections.

Next, install IAS using the Add/Remove Programs icon in Control Panel.  Once it has been installed, launch it from the Administrative Tools folder on the Start Menu and we’ll proceed with configuring it for authenticating VPN connections to the PIX firewall.

First, we need to grant IAS permission to read dial-in properties from user accounts in Active Directory.  To do this, right-click on the “Internet Authentication Service (Local)” and select “Register Server in Active Directory”.  Select Yes (or OK) if prompted to confirm.

With that done, we can now configure the PIX firewall as a RADIUS client.  Right-click on RADIUS Clients and select New RADIUS Client.  In the wizard, specify the IP address (or DNS name) of the PIX firewall’s internal IP address and the shared secret.  Note that this shared secret is the same secret key specified in the PIX configuration above.  RADIUS clients use this to authenticate to RADIUS servers, so make it a reasonably strong password.

Now create a remote access policy.  Right-click on Remote Access Policies and select New Remote Access Policy.  In the wizard, specify a name, select to create a custom policy, and then add the following conditions to the policy:

• NAS-IP-Address:  This will be the IP address of the PIX firewall’s internal interface.  This helps to ensure that this policy only applies to VPN requests from this firewall and not from any other RADIUS client.
• Windows-Groups:  This should be the security group created earlier.  Any user that should be allowed to authenticate on a VPN connection will need to be a member of this group.

The rest of the policy should be very straightforward.  Make this policy the first policy (using the Move Up/Move Down commands in the IAS console), add a user to the group created earlier, and then test your connection.  Remote systems attempting to connect via PPTP should now be able to authenticate the VPN connection using their Active Directory usernames and passwords.

Although this was written from the perspective of authenticating PPTP connections, the process should be very similar for IPSec VPN clients as well.

In my earlier posting about Lifesong, the second CD by the Christian group Casting Crowns, I spoke primarily about their musical style and their sound.  At the time, I was so wrapped up in how the music sounded in comparison with their debut album that I was disappointed in this latest effort.

I continued listening to the CD, concentrating mostly on the tracks that I really enjoyed—“Lifesong”, “Praise You in This Storm”, “Set Me Free”, and “Father, Spirit, Jesus”.  As I listened—truly listened—to the words of these songs, and then took the time to listen to the other songs on the album as well, I realized that I was guilty of the very things that Casting Crowns sings about in these songs.  And my first review was the perfect indicator of this.

So many people practice Christianity on the surface.  Sure, they go to church.  They may even teach Sunday School, or lead a Bible study group.  But do they really serve the Lord?  Is their service—my service—just “empty hands held high”?  How often do we high our true feelings from others, even our fellow Christians, becoming “happy plastic people under shiny plastic steeples”?  Can we see past that young unwed mother’s sin, see “past her scarlet letter” and actually get to know her?

This entry isn’t just about a CD, though; that’s why I titled this post “Another Take on Life(song)”.  It’s not just about Lifesong, it’s about life.  It’s time for us—for me—to move past superficial Christianity and into true service for the Lord.

That doesn’t necessarily mean full-time ministry, and it doesn’t mean just going to church.  It means serving the Lord with all that we are and in all that we do (and my use of the term “we” here includes myself).  It means living a life that “brings a smile” to the Lord, where we take to heart Jesus’ teachings and actually apply them in all areas of life, not just the areas that are convenient or comfortable.

It means letting our life(song) sing to the Lord.