1

I wish to create a dropbox like service to reach my files remotely.

Let's say I setup a linux box, connect an external hard drive, share it via password protected ftp and use a dyndns service to be able to connect to my network.

Will I compromise the security on the other devices on the same LAN (other computers connected to my router)?

I mean hypothetically somebody who would hack the linux box could then be able to install sniffers and then from the linux box crash my other boxes. Correct?

Is this a realistic risk to consider? Are there other security implications I'm foreseeing?

Chris
  • 125
  • 4

1 Answers1

4

Installing anything creates a potential for vulnerabilities - e.g., if there's a vulnerability in the dropbox daemon (or whatever protocol you use for sharing files), or in any other software on your Linux box, it would be possible to exploit it (once it's known). You'll need to evaluate how much of a risk this is for each component that you want to use (e.g. an up-to-date vanilla SSH server install is somewhat safe for such home-server use that you're outlining - given other precautions)

For security considerations: I wouldn't use FTP, it's a plaintext protocol (which may be a vulnerability in itself: your password and your files go over the wire in the clear); I'd go for a SSH server - gives you shell access and SFTP (secure file transfer), both encrypted; it is possible to limit access only to SFTP without a shell though.

Also, there are various helper services which can help against automated attacks, e.g. fail2ban (blocks an IP address from connecting after several failed attempts).

Usual other considerations apply: don't allow superuser (root) remote access, don't use weak passwords (and if possible, don't allow authentication by password at all, instead, use public key authentication and encrypt the private keys), update regularly (or set up automatic update), etc.

Also, block any access to the box except what is actually used (e.g. using iptables, deny everything, then only allow what's needed) - this is a lesser concern on most Linux installs, as there aren't many services open by default, but still worth mentioning.

Piskvor left the building
  • 2,153
  • 1
  • 18
  • 18
  • I did not outline the case enough. The reason for ftp is that the shared space is also for non-tech-savy individuals. So ssh is not an option. However if sftp encrypts and enables access through password (without keys and known host lists) it is ofc preferrable. However, enabling sftp => enabling ssh - correct? This I find uneasing. When you say do not allow remote login. Do you mean remote login and remote file share differ? I mean ssh:ing in essentially is logging in, or am I misunderstanding? Thanks for the response @Piskvor – Chris Nov 11 '11 at 11:56
  • @chris: As for the biggest issue, there are user-friendly SFTP clients, looking just like FTP clients (FileZilla, WinSCP); they can even be pre-configured for a particular user. Yes, you need to login; I meant "don't allow **superuser** (root) remote access". Next: you can limit a user to SFTP, without giving a remote shell (file share without a command line shell). Encryption is enabled regardless of auth method (password, publickey, what-have-you). Known host list is actually a Good Thing - *your server* is checked for authenticity, so that the user doesn't give a password to an impostor. – Piskvor left the building Nov 11 '11 at 12:32
  • So I shall setup as follows: SFTP, restricted users, no root, no public/private-keys, username+password login, no ssh/shell acess. Thank you @Piskvor – Chris Nov 12 '11 at 12:58