# ftp to home from work - security advice please

## greyspoke

OK, networking and security is an area I know even less about than the rest of it  :Embarassed:   but yesterday I got really pissed off that I forgot to send stuff from home to work.  On the plus side I got a bit more exercise in riding home, sending the stuff over, and riding back on my bike - about 35 minutes.  But the rest of the day was a bit of a scramble because of that and the quality of what I did was probably somewhat sub-optimal as a result.

So last night, I installed and set up pure-ftp on my always-on home server and added some port forwarding to the Bipac router that it connects to the internet through.  To my surprise I find this morning that I can reach it from work.  It is currently set up in the most minimal way possible, as a passive server recognising local unix users.

The question is, is this wise?  Should I be taking any security precautions?  Work is a large university so limiting access to its IP address is not going to be that great I would think (not that I have done even that yet).

I  am currently relying on my dynamic IP from my ISP not changing much, if this is a runner I can pay them a fiver to get a static one.

----------

## chithanh

ftp traffic including the authentication is unencrypted, unless you use an ftps enabled server and client. That could be a security problem.

A better option might be to forward the ssh port, and allowing only key-based authentication for IP addresses outside the local network. Then files could be transferred using scp, sftp or rsync -e ssh.

About the dynamic IP, you can just use dyndns or similar services.

----------

## i92guboj

 *greyspoke wrote:*   

> OK, networking and security is an area I know even less about than the rest of it   but yesterday I got really pissed off that I forgot to send stuff from home to work.  On the plus side I got a bit more exercise in riding home

 

Monty Python sung "always look at the bright side of life"  :Wink: 

 *Quote:*   

> 
> 
> So last night, I installed and set up pure-ftp on my always-on home server and added some port forwarding to the Bipac router that it connects to the internet through.  To my surprise I find this morning that I can reach it from work.  It is currently set up in the most minimal way possible, as a passive server recognising local unix users.
> 
> The question is, is this wise?  Should I be taking any security precautions?  Work is a large university so limiting access to its IP address is not going to be that great I would think (not that I have done even that yet).
> ...

 

Usually, I recommend using ssh instead. It's more secure and you can use about any ftp client (such as filezilla) to connect to it. If you are in windows you can use Filezilla as well, or WinSCP. You get some nice goodies, such as X forwarding (if you have a use for that at all) and everything is encrypted. And you could as well setup keypair authentication for really strong extra security.

 *Quote:*   

> I  am currently relying on my dynamic IP from my ISP not changing much, if this is a runner I can pay them a fiver to get a static one.

 

Or you could just open yourself an account in one of the providers that there are around the net that will give you a domain name. Most routers support at least a couple of these services directly, so all you have to do is to configure the router with your credentials for the account, and each time it gets a new ip the domain name will be updated, in a way that you can always reach your LAN using that domain name, without worrying about the current public ip of your router.

If you don't know what I am talking about I can send you the name of a couple of dinamic ip domain name providers, because I don't want to do any advertising here. This should be cheaper than having a fixed ip. However, having a fixed ip does have a number of advantages, so you'll have to decide yourself.

----------

## greyspoke

Thanks chithanh and i92.  I had not really considered SSH, I suppose I assumed that as it allowed access to a shell (from which you could do more than copy files) and I only want to copy files, then something like ftp would be the tool.  But I take the point about security, I will investigate configuring sshd.  Not sure I can forward ports from work, but there is an ssh client available.

I am aware of dynamic domain name providers i92, but for a one-off fiver (paying a lot more per month for the family fibre broadband) a static IP looks attractive.

----------

## i92guboj

 *greyspoke wrote:*   

> Thanks chithanh and i92.  I had not really considered SSH, I suppose I assumed that as it allowed access to a shell (from which you could do more than copy files) and I only want to copy files, then something like ftp would be the tool.  But I take the point about security, I will investigate configuring sshd.  Not sure I can forward ports from work, but there is an ssh client available.

 

Well, ports shouldn't be a problem. You can run sshd at any port you want (in fact, you should, because that alone will avoid most attacks).

 *Quote:*   

> I am aware of dynamic domain name providers i92, but for a one-off fiver (paying a lot more per month for the family fibre broadband) a static IP looks attractive.

 

Agreed  :Smile: 

Plus with a dynamic ip, the connection might stop working every random day, each time you get a blacklisted IP. That happens from time to time to my customers, who start wondering why the mails they send do not reach destinatio, and they don't get any failed mail notice.   :Laughing: 

In those cases you can always torify the connection though. That can help in most situations, though it has its own assortment of issues.

----------

## depontius

Since ssh is a frequently attacked port, there are a few other things you could do.  Many move their outside-facing ssh to a different port, basically a little security-by-obscurity.  Another thing is to not universally forward ssh in from your firewall - filter it first.  Once you learn your workplace outgoing IP, you could set things up to forward only incoming ssh from that IP.

----------

## chithanh

Against drive-by password guessing attacks, it is already enough to disable password authentication for remote IP addresses.

Changing the ssh port will also help somewhat, but only to the extent that you are creative in choosing a new port. Most people I know aren't, and use easily predictable ports like 222, 2222, 20122, etc. so their security gain is limited. And it is unnecessary if you disable password authentication.

----------

## cwr

If ssh works, then scp will work.  I wouldn't expose an ftp server to the current

internet if I were you.

Will

----------

## i92guboj

Yeah, it would be like throwing a poor samurai against a modern army with tanks, nuclear submarines, drones and all that stuff.   :Laughing: 

----------

## Hu

If you dislike the idea of allowing remote shell access, you can configure the sshd to permit only sftp, but not a full shell.  However, if you take the security advice in this thread to prevent malicious users from getting a successful authentication, then the exact permissions available to an authenticated user do not matter.

X11 forwarding requires cooperation from both the sshd and the ssh client.  It is possible that your system administrator might disable X11 forwarding on the client, but there is no reason for this to be done.  Thus, it is likely that you can use port forwarding from work if you wanted to do so.

----------

## shuuraj

Well just go and create a user who does not get any shell access... much easier then setting up a chrooted env.

/etc/passwd

```
youruser:xxx:xxx::/home/youruser:/sbin/nologin
```

----------

## greyspoke

Thanks again everyone.

What I should have done is looked first at the tools available from work (which likes to keep administrator control of its Windows workstations).  I can have SSH(R) Secure Shell(TM) which has a nice looking graphical SCP thingy with it.  I got this to talk to home via a secret-squirrel port number, just got to convert its public key to OpenSSH format if I want to avoid passwords, but that looks do-able.

----------

## 666threesixes666

id serve files off of http instead since you just need to shuck files out to your work.

----------

## Hu

 *666threesixes666 wrote:*   

> id serve files off of http instead since you just need to shuck files out to your work.

 He already has ssh almost the way he wants it.  He may want confidentiality and/or integrity of the content, neither of which can be guaranteed with plain http.  Restricting access to only selected users can be done over http, but not securely.  Using ssh solves all those problems.  He could serve the content over authenticated https, but since he has ssh almost the way he wants it, that seems like a much simpler choice.

----------

## greyspoke

Thanks Hu, I was going to say something similar (only less well-informed) about http.

Got the rsh keys working at both ends.  Now to experiment with my sshd_config to limit access from outside the home network more than from inside it.  Looks like I can change the login to a no-shell one and still use SFTP (not SCP as I said above) to transfer files, so that should keep my home server pretty secure, and my work files at least as secure as work treats them.  In fact, my files at work are just one stolen password away from being available to the whole world if I keep them on the network as we are recommended to do.

Edit - just realised that my private key is stored on the work network, so that is available to anyone who has nicked my password.  Security is tricky stuff isn't it?  :Confused: 

----------

## 666threesixes666

http is not attacked the way ssh is in the wild.  ssh it is?  disable ssh password logins, disable ssh root logins, accept keys only, install fai2ban & jail ssh.  i suggest passwords over 20 characters long.

the key is a pair, your PUBLIC key pair is the one you mail out.  you can optionally pass phrase them too.

i disable root login on my systems except through sudo su....  its in the sudo wiki talk page.  they have to guess the wheel/sudoer user 1st then the password second.

----------

## Hu

If you have the ability to use external media at work, you can get some extra protection by keeping the ssh private key on a USB stick or other removable media, so that it can only be attacked while you have the media connected.  You still need to protect the key via password, especially if the removable media is easily lost or stolen.

----------

## 666threesixes666

again non root wheel sudoer user would make them guess the user name even with the ssh key in hand....

----------

## NeddySeagoon

666threesixes666, 

 *666threesixes666, wrote:*   

> id serve files off of http instead since you just need to shuck files out to your work.

 

Heh, then he can get the files out of Googles cache too :)

----------

## 666threesixes666

even with no domain name?  i didnt really think about that one, im always thinking keep ports blocked and access via vpn.  and or password protect.  some of my sites dont index areas so im sure theres a way to stop it from indexing and publishing.

----------

## greyspoke

This is beginning to get a bit above my head, but I am getting the gist.  Thanks for all the comments I have learned a lot  :Smile:    I hadn't heard of fail2ban sixes, thanks I might try it.

For interest, 

I'm using a different key pair for work, and using the available delivered-over-the-network ssh client software I can't configure it to keep the keys anywhere else.  But I do have a password on the private key.  I have set up my home user to have /usr/lib/misc/sftp-server as its login shell, it needs that to work with sftp.  And I am not keeping any personal personal files on the server where it lives, I have adjusted things so my "work" folder on my desk computer points to a share on the home server rather than the hard disk (which is where the rest of my stuff is). And I have a separate sshd running on the server listening to a different port just for outside traffic and configured not to allow much.  As I said, I think this makes the stuff at least as protected as it would be on the work system, and protects the rest of the home system more so.

----------

## Hu

If you do not understand something that seems relevant, please ask for clarification.  Our advice does no good if you cannot apply it.

Your setup sounds sufficient against opportunistic attackers, assuming that your setup works the way you described it to work.  Without testing all the various attack modes, you can only trust that your configuration works the way you think it should.  Remember: "computers are stupid; they do what you tell them to do, not what you want them to do."

Most ssh clients should provide some way to specify the private key, but even if this one does not, you could copy the key onto the system when you need it and delete it when you are done.  This is probably not necessary with the other precautions you described.

----------

## NeddySeagoon

Hu,

That will be for a low value of 'delete' unless the key is always in RAM.

----------

## Hu

I meant that mainly in the sense that he should delete it off the work filesystem when not in use so that a would-be attacker would need either to take it from system cache or take it while he was connected, but not after he goes home for the day.

----------

