Best Practice for Securing AFP Access

[nello]

I have FreeNAS working well and am using it as an AFP server for backing up Macintoshes using CrashPlan. These shares are available from the Internet via ddns and port-forwarding (548) on my TomatoUSB router.

I'm wondering what I should be doing to tighten authentication to these shares.

Other than long/strong user passwords, is there anything else I should be doing to deter hackers from breaking in?

Thank you for your attention.

- nello

 

[paleoN]

I'm wondering what I should be doing to tighten authentication to these shares.

Don't run AFP directly over the Internet. Tunnel it through something, i.e. SSH/VPN.

 

[nello]

Don't run AFP directly over the Internet. Tunnel it through something, i.e. SSH/VPN.

That certainly sounds secure.

But, that means that CrashPlan has to make the SSH/VPN connection just before it starts a backup. I'm a bit puzzled how I teach CrashPlan this new trick.

 

[JaimieV]

Stop - you don't need to make the shares available to the Internet at all.

You add a Crashplan client to a computer locally, and that computer is where the Crashplan data arrives - this is all handled by the Crashplan app. That computer can be set to store the Crashplan files on the NAS, no problem there.

There should be no direct communication from the Internet to the NAS, that's both unsafe and unnecessary.

 

[nello]

You add a Crashplan client to a computer locally, and that computer is where the Crashplan data arrives - this is all handled by the Crashplan app. That computer can be set to store the Crashplan files on the NAS, no problem there.

Sorry, but I need to take this in smaller, more detailed steps.

Okay, so let's call the two computers ‘Local’ and ‘Remote'.

Remote has a copy of CrashPlan installed on it. It has its own CrashPlan account, different from the CrashPlan account used by Local, right? Remote’s destination is Local (configured as a “friend”).

That much I think I understand.

Now, how does Remote’s backup get to FreeNAS?

- nello

 

[nello]

Now, how does Remote’s backup get to FreeNAS?

Never mind. I took a close look at the CrashPlan screens and understand how this is specified.

So, here's the model I have in mind:

1. Separate datasets for each remote user so I can control each remote quota individually.

2. Separate AFP Share for each remote user so I can put the backups in the right dataset.

3. All datasets have the same permission on them and allow local read/write. None of the remotes have FreeNAS accounts because CrashPlan handles the authentication for remote users.

4. Local must be running 24/7 to accept remote requests.

5. All the AFP share points corresponding to remote users must be mounted by Local 24/7.

6. No firewall ports need to be open for this to work.

Anything I've missed?

Thank you!

- nello

 

[JaimieV]

1: Crashplan has its own per-remote-user quota system, do not use datasets instead use the Crashplan facility. Crashplan prefers this as it can manage the backups better this way than just running out of space.

2: There's only one defined data destination folder in Crashplan, so just one share (or a folder in an existing share, which is how I do it).

3: The remote users only see your Crashplan ID (the ABCDEF one); the local Crashplan only sees a folder (which happens to be on the NAS). The share containing that folder needs to be mounted and the folder needs to be read/write for the user who has Crashplan running and has the folder mounted.

4: Yes, but even if it's not Crashplan will pick up next time both ends are running. One of my destinations only has her computer on a couple of hours a day: the Crashplan backup is nevertheless almost always within 1 day of up to date.

5: Yes, but again Crashplan will simply wait for its folder to exist - if the share drops off (eg doesn't automount at reboot) it'll pick up when you mount the share.

6: Yes, all the Crashplan.apps intermediate their own connections. There are situations where you might want to set up a port-forward but that would point at the local host running Crashplan, not the NAS, and would be to work around network issues.

 

[nello]

@JamieV

Thank you so much for your detailed reply!

I have just one more question.

Is CrashPlan's networking smart enough to know whether the destination is the same LAN?

For example, suppose I have a desktop and laptop. I set up the desktop as the destination for the laptop's CrashPlan's backups. (And the desktop, in turn, stores these remote backups to my FreeNAS.) When I'm home, I want the laptop to backup to the desktop via my (private) LAN and not go out to the Internet and back in. When I leave home with my laptop, I want the backups to go from wherever I am to the desktop and the only way to to that is over the (public) Internet.

In other words, when my laptop is home, does my ISP count CrashPlan backup traffic between computers on the same LAN against my upload/download limits?

I'm sorry if the answer is obvious. CrashPlan's network intermediation is opaque to me.

Thank you again!

- nello

 

[JaimieV]

Yes. When your laptop is at home, the traffic will travel locally to the Crashplan destination on the same network. It doesn't go via the Internet. Notice that Settings/Network has separate limits for WAN and LAN communication.

(Crashplan.com only counts backups to their pay-for "Crashplan+" or "Pro" services, in passing - Anything else is peer-to-peer (including local LAN) and doesn't travel via Crashplan.com. Only the initial connections are mediated by Crashplan.com.)

 

[nello]

Only the initial connections are mediated by Crashplan.com.

I've been running CrashPlan as you suggested for the past several months.

My (initial) configuration did NOT involve opening port 4242 (used for all peer-to-peer communications) and it worked flawlessly as long as computers stayed where they were set up. However, when laptops moved to locations behind different routers, CrashPlan often could not make a connection until they came back to their initial locations. (See below for more details.)

For example, my mother's laptop backed up remotely from her house, which is where I'd configured it; CrashPlan traversed just fine through both her firewall and mine without either having 4242 open on either. But when she went to other locations, CrashPlan reported that it couldn't make a connection unless I open 4242 on my side.

Is there something about the *initial* connection that is stored and therefore is easier to make again? Is more information/negotiation required to connect at at new location?

CrashPlan Support says that I must open 4242 for peer-to-peer, remote backups:

Jake B. (CrashPlan Support)
May 24 10:31 am (CDT)

Nello,

Unfortunately CrashPlan will require you to have ports 4242 open for inbound and outbound traffic if you want to achieve peer-to-peer backups. This is something that is required by the application and cannot be changed.

If you are attempting to access CrashPlan Central in anyway, that will require port 443 to be open for inbound and outbound traffic.

Have these ports open allows CrashPlan to backup to your archive but also report information back to the CrashPlan application to ensure your backup archives are accurate and consistant. The method in which the data is sent will be encrypted before being sent anywhere, so your data is safe during the transfer.

Please let me know if you have additional questions.

Thanks,

Jake

I feel uneasy about opening a port on my firewall that forwards into my LAN.

Is my concern reasonable? Is there something else that I should do to mitigate risks from port forwarding?

As always, thank you for your time and attention!

- nello





Configuration

Network: ATT Uverse broadband service using a 2Wire modem/router connecting to an ASUS RT-N16 flashed with Tomato Firmware 1.28.0000 MIPSR2-102 K26 USB AIO. (I use this firmware for its OpenVPN service.)

CrashPlan Server Hardware: iMac 27" 2010 (aka "Argus") uses drive mounted via AFP on FreeNAS server with 16GB RAM and four Western Digital 3TB Red NAS drives configured as RAIDZ2.

CrashPlan Client Hardware: MacBook Air 13" 2012 ("Decartes"); MacBook Air 11" 2012 ("Champagne"); MacBook Pro 13" 2012 ("Traveler").

Client Connections: Argus (wired LAN); Descartes, and Champagne (WiFi "G" LAN); Traveler (WAN)

Reliability

Argus never fails.

Descartes and Champagne work flawlessly locally; they do not backup from wireless access points away from home, i.e., outside of my firewall.

Traveler is my mother's computer and as long as she uses her home Comcast connection to the Internet, her backups kickoff like clockwork; there is never a problem. Unfortunately, when she travels, she connects to Argus at some locations and not at others.

Attempts to Improve Reliability

I presume that all of these reliability issues are routing problems.

I had assumed that Traveler working from my mother's home implied that port 4242 on Argus (used by CrashPlan) was accessible from the Internet. CrashPlan recommends testing connectivity by trying to make a telnet connection to port 4242. Unfortunately, this test fails consistently from outside my firewall using my dyndns domain, ***.dyndns.biz, e.g, telnet ***.dyndns.biz 4242. So, I set up the Asus to forward port 4242 to Argus (after assigning Argus a static IP address). Voilà, the telnet test passed and Traveler made a connection to Argus from a location where it had always failed before.

After reflecting further on these results, I thought that the erratic connections to Argus' port 4242--works from some locations, not others--might have been the result of inadvertently double NATing the 2Wire and Asus routers. Apparently, the only way to turn off NAT on the 2Wire is to create a DMZ between it and the Asus, which I did. Unfortunately, the telnet test still fails without forwarding port 4242 to Argus.

 

[JaimieV]

That's interesting. I haven't used it on any laptops, and haven't come across that problem. I'll bear it in mind though, and thank you for the advance warning!

However, I can tell you that opening port 4242 on your firewall and forwarding it to a specific host on the inside will be pretty safe. Only Crashplan will be listening on that port, and it does seem to be solidly reliable about interpreting spurious data coming through, simply ignoring it until it recieves a normal Crashplan application connection.

I tested that out rather amateurishly by messing around in telnet and then throwing random output packets from netcat at Crashplan on port 4242, and failed to get any positive/negative reaction (eg crashing) out of it, running for a couple of days.