I want to copy files from a BeagleBone Black (running Ubuntu) to my home dmz system. This has got to work unattended as the BBB is sat on our boat moored on the Somme. It's also got to be a 'push' from the BBB as it's connected via WiFi and while I can connect to it through an ssh tunnel copying files via that connection would be decidedly tricky.
So, as I see it, I have two obvious options:-
1 - Set up a public key login for the BBB on my dmz that requires no passphrase, so it's effectively passwordless. Then the BBB can run rsync to copy the files. The security hole in this approach is that if someone accessed the BBB then they could login to the dmz without further difficulty.
2 - Run an rsync daemon on the dmz and copy the files by connecting to this from the BBB. The advantage is that someone at the BBB end can't do anything but copy files (and I can limit what can be copied with the rsyncd configuration), the disadvantage is that the connection isn't encrypted at all.
There's nothing valuable in the files, they're just temperature and electrical measurements from the boat so I don't care at all about the files being visible to the world. My security concern is to minimise the risk of someone getting into my dmz system. OK, it's a dmz and it's just a Raspberry Pi so is hardly full of valuable data but it would be a nuisance and *might* be a jumping off place for further nefarious deeds.
I guess I'm being a bit paranoid really, the BBB on the boat is headless and anyone breaking into the boat is hardly likely to be an accomplished Linux hacker. Option 1 above is certainly the easiest as rsync daemon takes a bit of setting up. Are there any really obvious flaws - is it only really vulnerable to someone who accesses the BBB?
There is an option 3 but it's more difficult to set up, I could implement a passphraseless rsync connection from the BBB to the dmz that only allows rsync file copying to a specific directory. I've done this on one other system and it works pretty well (you do it by adding a command= at the front of the authorized_keys file) but like the rsync daemon it takes a bit of setting up and I'm wondering if it's worth the effort.
Any comments anyone? Are there more obvious and/or easier ways of copying files without making systems vulnerable to other attacks?
On 29 May 2014 12:22, Chris Green cl@isbd.net wrote:
2 - Run an rsync daemon on the dmz and copy the files by connecting to this from the BBB. [...] the disadvantage is that the connection isn't encrypted at all.
.. but you go on to say:
There's nothing valuable in the files, they're just temperature and electrical measurements from the boat so I don't care at all about the files being visible to the world. My security concern is to minimise the risk of someone getting into my dmz system.
If you're not concerned about the content of the files being accessible to the world once you have them in your DMZ, then is the paranoia about them being available to wire-sniffers a big issue?
Anyway, my first thought was to go old-school and look at something like FTP; ftp servers have long been tasked with allowing anonymous uploads (and preventing them being downloaded again, and from preventing users getting anywhere onto the server that they shouldn't). FTP can be encrypted (FTPS) although that's not something I've played with. But it looks like all the major FTP servers out there support FTPS, so that would be the way I'd go, which should take care of both your concerns.
Mark
On 29 May 17:39, Mark Rogers wrote:
On 29 May 2014 12:22, Chris Green cl@isbd.net wrote:
2 - Run an rsync daemon on the dmz and copy the files by connecting to this from the BBB. [...] the disadvantage is that the connection isn't encrypted at all.
.. but you go on to say:
There's nothing valuable in the files, they're just temperature and electrical measurements from the boat so I don't care at all about the files being visible to the world. My security concern is to minimise the risk of someone getting into my dmz system.
If you're not concerned about the content of the files being accessible to the world once you have them in your DMZ, then is the paranoia about them being available to wire-sniffers a big issue?
Anyway, my first thought was to go old-school and look at something like FTP; ftp servers have long been tasked with allowing anonymous uploads (and preventing them being downloaded again, and from preventing users getting anywhere onto the server that they shouldn't). FTP can be encrypted (FTPS) although that's not something I've played with. But it looks like all the major FTP servers out there support FTPS, so that would be the way I'd go, which should take care of both your concerns.
Except FTP is a nightmare when nat is involved, and more so when using FTPS. Personally I'd just set up a seperate key and account on the machine that the data is going to and throw the files over rsync over ssh using a passphraseless key. Less messing about with configuration, single port to worry about, etc, etc.
On 30/05/14 14:44, Brett Parker wrote:
Except FTP is a nightmare when nat is involved, and more so when using FTPS. Personally I'd just set up a seperate key and account on the machine that the data is going to and throw the files over rsync over ssh using a passphraseless key. Less messing about with configuration, single port to worry about, etc, etc.
Agreed, except I'd use scp via cron with a passphraseless key.
Cheers, Laurie.
On Fri, May 30, 2014 at 04:01:52PM +0100, Laurie Brown wrote:
On 30/05/14 14:44, Brett Parker wrote:
Except FTP is a nightmare when nat is involved, and more so when using FTPS. Personally I'd just set up a seperate key and account on the machine that the data is going to and throw the files over rsync over ssh using a passphraseless key. Less messing about with configuration, single port to worry about, etc, etc.
Agreed, except I'd use scp via cron with a passphraseless key.
scp/rsync makes little odds really. Yes, I think this is the simplest and easiest way to go.
On 30 May 2014 14:44, Brett Parker iDunno@sommitrealweird.co.uk wrote:
Except FTP is a nightmare when nat is involved, and more so when using FTPS.
Just goes to show it's been a while since I set FTP up, I'd forgotten about that joy!
As I mentioned I haven't tried FTPS but does that bring a particular complication over NAT? Aside from accepting passive connections over a narrow port range that has been forwarded through anyfirewall/NAT setup, is there more to it?
The advantage of FTP(S) is that the server doesn't have the capability to provide access to anything in the way the SSHd does, which means you're less reliant on locking down all the things the server can do but that you don't want it to allow.
On 30 May 17:08, Mark Rogers wrote:
On 30 May 2014 14:44, Brett Parker iDunno@sommitrealweird.co.uk wrote:
Except FTP is a nightmare when nat is involved, and more so when using FTPS.
Just goes to show it's been a while since I set FTP up, I'd forgotten about that joy!
As I mentioned I haven't tried FTPS but does that bring a particular complication over NAT? Aside from accepting passive connections over a narrow port range that has been forwarded through anyfirewall/NAT setup, is there more to it?
yes... with ftp you can use the nat ftp module with ftps the connection is encrypted and the kernel can't spy on the traffic, so you have to open a dedicated set of ports.
The advantage of FTP(S) is that the server doesn't have the capability to provide access to anything in the way the SSHd does, which means you're less reliant on locking down all the things the server can do but that you don't want it to allow.
force-command internal-sftp is good for restricting ssh
--
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) @ 13 Clarke Rd, Milton Keynes, MK1 1LG
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On Fri, May 30, 2014 at 07:43:56PM +0100, Brett Parker wrote:
The advantage of FTP(S) is that the server doesn't have the capability to provide access to anything in the way the SSHd does, which means you're less reliant on locking down all the things the server can do but that you don't want it to allow.
force-command internal-sftp is good for restricting ssh
Much like a 'command=' in the authorized file I guess.
On Fri, May 30, 2014 at 05:08:15PM +0100, Mark Rogers wrote:
On 30 May 2014 14:44, Brett Parker <[1]iDunno@sommitrealweird.co.uk> wrote:
Except FTP is a nightmare when nat is involved, and more so when using FTPS.Just goes to show it's been a while since I set FTP up, I'd forgotten about that joy!A As I mentioned I haven't tried FTPS but does that bring a particular complication over NAT? Aside from accepting passive connections over a narrow port range that has been forwarded through anyfirewall/NAT setup, is there more to it? The advantage of FTP(S) is that the server doesn't have the capability to provide access to anything in the way the SSHd does, which means you're less reliant on locking down all the things the server can do but that you don't want it to allow.
Much the same as an rsync daemon. All that's required for the rsync daemon is a configuration file at the server end which specifies which directories are accessible (to who) and what the user can do there.
On 29/05/14 12:22, Chris Green wrote:
I want to copy files from a BeagleBone Black (running Ubuntu) to my home dmz system. This has got to work unattended as the BBB is sat on our boat moored on the Somme. It's also got to be a 'push' from the BBB as it's connected via WiFi and while I can connect to it through an ssh tunnel copying files via that connection would be decidedly tricky.
So, as I see it, I have two obvious options:-
1 - Set up a public key login for the BBB on my dmz that requires no passphrase, so it's effectively passwordless. Then the BBB can run rsync to copy the files. The security hole in this approach is that if someone accessed the BBB then they could login to the dmz without further difficulty.
2 - Run an rsync daemon on the dmz and copy the files by connecting to this from the BBB. The advantage is that someone at the BBB end can't do anything but copy files (and I can limit what can be copied with the rsyncd configuration), the disadvantage is that the connection isn't encrypted at all.
There's nothing valuable in the files, they're just temperature and electrical measurements from the boat so I don't care at all about the files being visible to the world. My security concern is to minimise the risk of someone getting into my dmz system. OK, it's a dmz and it's just a Raspberry Pi so is hardly full of valuable data but it would be a nuisance and *might* be a jumping off place for further nefarious deeds.
I guess I'm being a bit paranoid really, the BBB on the boat is headless and anyone breaking into the boat is hardly likely to be an accomplished Linux hacker. Option 1 above is certainly the easiest as rsync daemon takes a bit of setting up. Are there any really obvious flaws - is it only really vulnerable to someone who accesses the BBB?
There is an option 3 but it's more difficult to set up, I could implement a passphraseless rsync connection from the BBB to the dmz that only allows rsync file copying to a specific directory. I've done this on one other system and it works pretty well (you do it by adding a command= at the front of the authorized_keys file) but like the rsync daemon it takes a bit of setting up and I'm wondering if it's worth the effort.
Any comments anyone? Are there more obvious and/or easier ways of copying files without making systems vulnerable to other attacks?
Perhaps it's a silly question, but why rsync? Is it that you do not know the file names, but do know the destination directory? I'm just asking because there's always scp (secure copy), or sftp/ftp (secure/ File Transfer Program).
If the data is not confidential, then why are you trying to copy it in a confidential way? Could you upload it to a webserver somewhere, a dropbox or a cloud server if you have one. Even email the files to yourself?
Are you the chap who has to ssh from home to an intermediate cloud server and also ssh from the boat to the same server to get a connction? If that's the case, and if you can configure the cloud server, could you do a double rsync?
1) scheduled rsync 1 Boat -----> rsync ---> Cloud
2) scheduled rsync 2 Cloud ----> rsync ---> Home
3) Cronjob to delete files older than X days on Boat.
Any of that any use? Steve
On Fri, May 30, 2014 at 12:28:11AM +0100, steve-ALUG@hst.me.uk wrote:
Any comments anyone? Are there more obvious and/or easier ways of copying files without making systems vulnerable to other attacks?
Perhaps it's a silly question, but why rsync? Is it that you do not know the file names, but do know the destination directory? I'm just asking because there's always scp (secure copy), or sftp/ftp (secure/ File Transfer Program).
Do scp (which I use often when copying a single file) or sftp offer anything that rsync doesn't? They all simply use an underlying ssh connection don't they?
If the data is not confidential, then why are you trying to copy it in a confidential way?
I'm not, as I explained it's not the data I'm concerned about, it's the security of the receiving end.
Could you upload it to a webserver somewhere, a dropbox or a cloud server if you have one. Even email the files to yourself?
Are you the chap who has to ssh from home to an intermediate cloud server and also ssh from the boat to the same server to get a connction? If that's the case, and if you can configure the cloud server, could you do a double rsync?
- scheduled rsync 1
Boat -----> rsync ---> Cloud
- scheduled rsync 2
Cloud ----> rsync ---> Home
- Cronjob to delete files older than X days on Boat.
That's effectively what I do at the moment, it's just rather messy and I'm looking for a simpler method.
What I actually do at the moment is:-
Boat -----> rsync -----> Cloud Home <----- rsync <----- Cloud
I.e. the home system 'pulls' the data from the cloud, I do it this way so there is no 'hole' for the cloud to access my home system. However it means the copy times etc. have to be done by 'dead reckoning', I'd prefer something that was all driven from 'one place' as it were.
On Fri, 30 May 2014 00:28:11 +0100 steve-ALUG@hst.me.uk allegedly wrote:
On 29/05/14 12:22, Chris Green wrote:
I want to copy files from a BeagleBone Black (running Ubuntu) to my home dmz system. This has got to work unattended as the BBB is sat on our boat moored on the Somme. It's also got to be a 'push' from the BBB as it's connected via WiFi and while I can connect to it through an ssh tunnel copying files via that connection would be decidedly tricky.
Even email the files to yourself?
+100 for email. Sooooo much simpler. Cron job emails the (non-confidential) files out.
Mick
---------------------------------------------------------------------
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
On Fri, May 30, 2014 at 04:37:13PM +0100, mick wrote:
On Fri, 30 May 2014 00:28:11 +0100 steve-ALUG@hst.me.uk allegedly wrote:
On 29/05/14 12:22, Chris Green wrote:
I want to copy files from a BeagleBone Black (running Ubuntu) to my home dmz system. This has got to work unattended as the BBB is sat on our boat moored on the Somme. It's also got to be a 'push' from the BBB as it's connected via WiFi and while I can connect to it through an ssh tunnel copying files via that connection would be decidedly tricky.
Even email the files to yourself?
+100 for email. Sooooo much simpler. Cron job emails the (non-confidential) files out.
After thinkinmg about this I may well use E-Mail, sending is a doddle and I can have a dedicated user at the receiving end whose .forward file will feed the E-Mails into a script (bash or python) than gets the data out and processes as required.
On 31/05/14 09:37, Chris Green wrote:
After thinkinmg about this I may well use E-Mail, sending is a doddle and I can have a dedicated user at the receiving end whose .forward file will feed the E-Mails into a script (bash or python) than gets the data out and processes as required.
A late alternative. I've just spotted this on my Facebook feed. There's a Pi build for it apparently. Don't know if it'd cope with your access problems though.
http://www.webupd8.org/2014/06/syncthing-open-source-bittorrent-sync.html
Steve
-
Brett Parker -
Chris Green -
Laurie Brown -
Mark Rogers -
mick -
steve-ALUG＠hst.me.uk