robbat2 | Entries tagged with rsync

I was doing some statistics about Gentoo mirrors to see about future plans, and thought that the indirect crowd that read my blog via the various aggregators might be interested in numbers.

These are the traffic for boobie.gentoo.org, which is a newer box in the official rsync.gentoo.org box directly maintained by the Infrastructure team. Hardware specs are 2x Xeon 3050 @2.13Ghz, 4GB RAM. Disk is mostly irrelevant - the rsync workload is served purely from RAM (tail-packing reiserfs, backed via loop device pointing to a file on tmpfs).

Inbound traffic is spiky, but does not exceed 10Mbit by more than a little bit - we can the inbound rsyncs from the rsync1 master to 10Mbit. Outbound traffic varies between 4Mbit and 9Mbit, with an average around 6-7Mbit.

( Numbers )

Current Music: Wolfgang Amadeus Mozart - The Abduction From Seraglio

So on Slashdot today, there was a link to the latest research into Package manager security. Specifically, their focus was on defeating signed packages by use of malicious mirrors and replay attacks of signed content. Recording the source of client requests, and possibly denying specific security updates (having an older tree that doesn't contain the security updates).

This plays into some of my long-ongoing tree-signing research in Gentoo. The GLEPs with the exception of 02 and 03 have been mailed to the GLEP editors as well as the portage-dev mailing list, and will be going to the gentoo-dev mailing list after the GLEP editors have reviewed them.

For dealing with the new issues raised by Cappos et al, at Gentoo we are really lucky to have our own infra maintained hardened rotation of mirrors at rsync://rsync.gentoo.org/ in addition to the community mirrors at rsync://rsync$N.$CC.gentoo.org/. Nobody using just the infra-maintained mirrors (barring MITM attacks) would be vulnerable to the new attacks described by Cappos, however those using a community-maintained mirror could be.

Using the main mirrors for new signing purposes, this will enable us to deliver the new MetaManifests reliably via our own infrastructure, even when the user has a community mirror for their actual tree content. The actual changes to the GLEP for this weren't very big at all. Just a timestamp header inside the signed area, as well as distributing the MetaManifests via a trusted medium.

As a minor side note on the infra-maintained rsync.gentoo.org rotation, this would be a good time to consider sponsering a box to Gentoo for that purpose. Each of the 5 existing boxes in the rotation does 50-65GiB of traffic every day - averaging to 6.5Mbit/sec, over a 24-hour period. These boxes are bandwidth, memory and CPU intensive, however they don't hit disk very hard (we serve the trees directly from memory). 4GiB RAM, 2+ 64-bit processors (single core or dual core is fine), ~16GiB of disk (optional: software RAID1 is nice for avoiding downtime, and fancy fast disks aren't needed). We need a serial console or KVM to install it securely - you just boot the box to a livecd, get the access details to infra, we install it from there with our own stage4 tarball that links into cfengine. The machine continues to be owned by the sponsor, in your data centre.

If you use 'PermitRootLogin no' in your sshd_config and a locked-down sudo (requiring a password to upgrade powers), logging in to a machine as root is not allowed. This can be a pain when you want to rsync files between two machines, as root on both sides to preserve permissions and ownership. There is a fun little hack that you can use to get around this, that I'll document here.

Ensure your SSH agent is running and has a key present.
Open two shells, we will call them A and B (instructions prefixed with either or 'Both' below)
We will use A to connect to the source, and B to connect to the destination.
Both: SSH to the relevant machines, forwarding your agent, using 'ssh -A hostname'
Both: Run 'sudo su', authenticating to sudo. Do not use 'sudo su -', as we need to preserve our SSH agent information.
B: Run your rsync command as normal, but include the following option: --rsync-path='sudo rsync'

You should not get a password prompt! If you do get one, your sudo authentication did not propagate on the source machine properly. You cannot enter a password at this prompt either, it will never reach sudo, as rsync does not pass your input to it.

Alternatively, if your rsync version does not have a usable 'rsync-path' option (non-existant or wants a full path to a single program), you can use the -e option as: -e 'ssh user@source sudo /usr/local/bin/ignorefirst'. /usr/local/bin/ignorefirst is the following tiny script:

#!/bin/sh
shift
exec "$@"

The '-e' method is a lot more flexible, you can chain SSHs in it for example. You only need the 'ignorefirst' script because rsync puts the the hostname as the immediate next argument to the contents of '-e' commands.

S	M	T	W	T	F	S
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31

Move along, nothing to read

A dis-illusioned software engineer

gentoo mirrors stats: a rsync.gentoo.org box

Tree-signing in Gentoo and recent research into Package Manager Security

root-to-root rsync without direct root login

Profile

May 2017

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags