[Macpartners] How safe/secure is 'Personal File Sharing' on Mac OS X?

Timothy Boyden trboyden at MIT.EDU
Thu Mar 25 20:19:27 EST 2004


My preference for transferring files back and forth between my home and  
work Macs and Athena locker is using the Fugu SFTP/SCP tool created by  
the Research Systems Unix Group at the University of Michigan.

Here's a link:  http://rsug.itd.umich.edu/software/fugu/

It's easy to setup and I like the interface better than Fetch. It's  
basically just a nice Cocoa facade to the built-in SSH, SFTP, and SCP  
utilities of OS X. Even though SSH has had it's security holes every  
once in a while, I feel better about leaving SSH enabled on my Mac,  
plus it's has many uses including being able to run a shell and X11  
applications remotely.

Tim Boyden
MIT Department of Facilities
IT Support & Training Group



On Mar 25, 2004, at 7:09 PM, Kerem B Limon wrote:

> This is a good question, and I'd like to hear others' comments on it,  
> as well.
>
> According to my knowledge, AFP, the Apple/AppleTalk Filing Protocol,  
> which 'Personal File Sharing' uses, makes use of TCP ports 548 and  
> 427. If you have the built-in firewall turned on in Mac OS X 10.2 and  
> higher (and you should, unless there's good reason for not doing so),  
> turning on 'Personal File Sharing' will automatically update the  
> firewall configuration to allow access to these ports. This should be  
> the minimal precaution to take.
>
> You can, of course, configure the built-in software firewall further  
> to limit IP ranges, etc. to your liking. Do a search on 'firewall' at  
> MacUpdate (http://www.macupdate.com/) or VersionTracker  
> (http://www.versiontracker.com/macosx/) for a variety of free and  
> commercial tools to configure the built-in firewall; or Google for  
> instructions on manually modifying the config files.
>
> As far as the protocol goes, the latest Apple documentation on AFP  
> (http://developer.apple.com/documentation/Networking/Conceptual/AFP/ 
> Preface/chapter_1_section_1.html#//apple_ref/doc/uid/TP30000941)  
> indicates the protocol can use a variety of user authentication  
> methods, from cleartext to Kerberos (if set up properly), some in  
> danger of man-in-the-middle attacks. To the best of my knowledge, the  
> data stream is typically unencrypted and susceptible to eavesdropping.
>
> That said, you can always tunnel mounting the file share through an  
> SSH connection. Actually, word is that Apple modified the AFP  
> client/server to do this automatically, using SSH to transparently  
> encrypt the connection stream, but there was a recent security flag  
> and reports of it not working (or rather, failing to indicate an SSH  
> connection not being possible and silently falling back to an  
> unencrypted stream). Some also claim the feature is only supposed to  
> work between shares on a Mac OS X Server edition and Mac OS X clients.  
> You can read more about it at
>
> http://www.eweek.com/article2/0,,1540556,00.asp
> http://neworder.box.sk/explread.php?newsid=10717
>
> This may or may not have been fixed yet--you should check around. As  
> the latter article suggests, however, you could always 'manually' do a
>
> ssh -aCN -L <local_port_no>:localhost:548  
> <login_username>@<AFP_server_host>
>
> from the Terminal, where you substitute for <local_port_no>,  
> <login_username>, and <AFP_server_host> appropriately. This will also  
> provide some compression, and may or may not speed up things depending  
> on the files transferred back and forth. If you are not file sharing  
> on the client machine, <local_port_no> might as well be 548, and then  
> the user can simply do Connect To Server... (Command-K) from the  
> Finder and enter afp://localhost . If you are sharing locally on the  
> client, however, set it to something typically unused, say 5480--easy  
> to remember--and use the URL afp://localhost:5480 . The rest is the  
> usual login/selecting shares to mount process. One advantage of this  
> is across blocked/firewalled networks, where ports 427/548 may not be  
> open in either direction, but SSH (22) is.
>
> All this depends on how savvy the user is and if they can follow these  
> directions; at the most complicated end of things, there are options  
> like setting up IPsec between the machines and the like. And if the  
> user just needs to get to files and transfer them back and forth, then  
> an SFTP connection may be easier and pain-free; having an AFP mount  
> really helps when you really need a very basic, familiar interface for  
> the user and/or frequent access (e.g. to preferences) kept on a remote  
> share are needed--and then, of course, there are performance concerns.
>
> Bottomline, I think if they are not concerned about the data stream  
> being interrupted or man-in-the-middle attacks, basic File Sharing  
> authentication (as long as it isn't cleartext) should be OK with  
> strong passwords that are frequently changed, and the firewall up to  
> block unnecessary ports. If they are, and Apple hasn't fixed the SSH  
> issue, write up instructions for manual tunneling as above.
>
> Kerem
>
>
> At 04/03/25 15:56  Thursday, Stefan Stasik wrote:
>
>> Hi Mac Partners:
>>
>> I have a user who is inquiring about turning on and using Mac OS 10.3
>> 'Personal File Sharing' so that he can access his systems drives at  
>> MIT
>> from home.  He wanted to know if this is recommended and/or safe.
>>
>> Anyone have any thoughts on this service??  What protocol is this  
>> using?
>>
>> Is there a way you can lock it down somehow, by IP range, that makes
>> sense?
>>
>> Thanks for any suggestions/tips.
>>
>> - Stefan
>>
>> Stefan Stasik - stasik at mit.edu - (617) 253-7208 - Building 9-250
>> System Administrator - MIT Academic Media Production Services
>>
>> _______________________________________________
>> Macpartners mailing list
>> Macpartners at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/macpartners
>
>
> _______________________________________________
> Macpartners mailing list
> Macpartners at mit.edu
> http://mailman.mit.edu/mailman/listinfo/macpartners



More information about the Macpartners mailing list