Sercurity Update 2007-004 kills FTP on OS X Server
Man, I wish my Google skills were a bit better. Instead of spending hours solving a problem, I would have spent minutes implementing someone else's solution. So it goes.
For you OS X Server admins out there, if you run FTP services the most recent security update is going to cause some pain. After I updated my servers, I went about testing all services to make sure everything was running correctly. At first glance, everything was fine.
Then I tried to update my website and got some really strange errors from Blogger. It kept telling me the path to my website did not exist on the FTP server. I manually connected with Transmit to make sure everything was working--and found myself staring at the root of my disk! I assumed some configuration file got hosed, so I launched Server Admin only to see that all my FTP server settings were dandy.
Logging into several servers all yielded the same result.
Lucky for me, I clone my server boot drives before applying updates. I started using diff to see what had changed between the updates. I found that the ftp.plist file in /System/Library/LaunchDaemons was different so I looked at both versions. I was shocked to see that ftpd was being invoked instead of xftpd. Copying the file from the cloned, pre-update, drive and rebooting fixed the issue.
Here's a great discussion I found on the issue this morning, along with the text needed to resolve the issue.
For you OS X Server admins out there, if you run FTP services the most recent security update is going to cause some pain. After I updated my servers, I went about testing all services to make sure everything was running correctly. At first glance, everything was fine.
Then I tried to update my website and got some really strange errors from Blogger. It kept telling me the path to my website did not exist on the FTP server. I manually connected with Transmit to make sure everything was working--and found myself staring at the root of my disk! I assumed some configuration file got hosed, so I launched Server Admin only to see that all my FTP server settings were dandy.
Logging into several servers all yielded the same result.
Lucky for me, I clone my server boot drives before applying updates. I started using diff to see what had changed between the updates. I found that the ftp.plist file in /System/Library/LaunchDaemons was different so I looked at both versions. I was shocked to see that ftpd was being invoked instead of xftpd. Copying the file from the cloned, pre-update, drive and rebooting fixed the issue.
Here's a great discussion I found on the issue this morning, along with the text needed to resolve the issue.
Labels: apple, os x server, updates, workarounds
posted by Mike McHargue @ 8:36:00 AM
9 Comments:
At 2:05 PM ,
Anonymous said...
MacFixIt posted a piece on this as part of their security update special report: http://www.macfixit.com/article.php?story=20070427000142499
At 3:06 PM ,
Anonymous said...
Given the choice of running wu_ftpd (what Apple calls xftpd) and the old BSD ftp daemon, I'll go for the old one every time. wu_ftpd is just too big and complex a package. If I was doing something that was too complex for ftpd, I'd likely use something other than ftp.
But, really, if I was going to run an ftp daemon these days I'd probably pick Troll-FTPd or one of its descendants. And I'd ask myself "do you really want to run an FTP daemon" a couple of times before going that far.
At 3:10 PM ,
Mike McHargue said...
I very much fall into the camp of not wanting to use an FTP daemon. Sadly, I work for an ad agency and most of the vendors we use will only transfer files via FTP.
The easiest way to do this is to set up a folder as both an AFP share and the FTP root. My clients inside the building just see another share point on a server, while people outside the company see an FTP server.
Using Apple's supplied solution means that integration with directory services is easier than with other packages.
Ultimately, I'd like FTP to go away. For now, Apple's solution makes the most sense for our business.
At 5:25 PM ,
Kevin said...
At the suggestion of one of the posters in the Apple Discussions thread, I went ahead and installed PureFTPd on my OS X Server, along with the excellent PureFTPd Manager GUI, available from http://jeanmatthieu.free.fr/pureftpd. While I've experienced a few minor bugs, the new FTP server is a huge improvement over the stock Apple one, especially in the areas of user management and permissions. I can set up different root folders for specific users, but give them access to "virtual folders" linked to different locations on my server. I especially love the detailed logging, as well as the bandwidth allocation feature. It's much easier for me to tell who's trying to hack into our site -- the Apple logs didn't always provide the IP addresses, and PureFTPd does reverse DNS lookups, too. So, if someone persists in their hacking attempts, I can just add them to a firewall rule.
At 5:32 PM ,
Mike McHargue said...
How's the integration between PureFTPd and Open Directory?
At 6:23 PM ,
Kevin said...
While I haven't tried it, LDAP is a choice for authentication, so I imagine there shouldn't be any problems.
At 6:33 PM ,
Anonymous said...
I am running CrushFTP and seem to have some recent troubles.
Could this be the issue?
At 10:07 PM ,
Anonymous said...
Am I missing something here? Why would anyone in their right mind be running FTP, which passes passwords in clear text?
SFTP, SSH, SCP, HTTPS, **ANYTHING** with encryption is better than FTP.
Time to join the 21st century! :-)
At 11:37 PM ,
Mike McHargue said...
"Am I missing something here? Why would anyone in their right mind be running FTP, which passes passwords in clear text?
SFTP, SSH, SCP, HTTPS, **ANYTHING** with encryption is better than FTP.
Time to join the 21st century! :-)"
Business Reality! We're an ad agency. 80% of our vendors and pubs WILL NOT USE ANYTHING OTHER THAN FTP for file transfers. We can choose between FTP and FedEx.
I agree that FTP is a pretty shoddy way of doing things in terms of security, but at the end of the day, business needs come first.
Post a Comment
Links to this post:
Create a Link
<< Home