SCP speed question

[Bill Campbell]

On Sat, Jan 06, 2007, Matthew Carpenter wrote:
>On Saturday 06 January 2007 13:06, Bill Campbell wrote:
>> Using ssh with rsync permits access to any files/directories on
>> the remove system, but using rsync modules permits control to
>> individual directories and may restrict to specific IP addresses
>> and/or CIDR ranges.  Furthermore, having ssh keys with empty pass
>> phrases provides links to destination machines in the event that
>> the machine is cracked.
>
>Ok.  That is starting to make sense.  You could do it more securely and better 
>with SSH/rsync, but it is starting to become cumbersome to match your setup.  
>You can do the limiting by IP address through NetFilter and probably through 
>sshd itself, but in order to control file access appropriately in a similar 
>fashion, you'd end up with something like chroot, which is not as simple.

Of course there are many ways to handle this type of thing, and
we frequently have IPSec VPN connections between the systems thus
doing the transfers via secure connections without dealing with
ssh keys.

>> We provide secondary DNS for hundreds of domains, maintained by
>> several of our ISP customers.  It would be a major PITA for me to
>> maintain the appropriate files for zone transfers for these
>> domains.  The ISPs responsible for the primary records push the
>> djbdns data to our site using rsync when they're updated, and our
>> routines then process them along with the records for other ISPs
>> and the domains we maintain locally.
>
>So the data is traversing potentially anywhere on the Internet?  This adds to 
>my queasiness.  I understand that ssh keys to limited access accounts can 
>still give shell access to a box should the originating system be 
>compromised.  Unfortunately, you don't need to compromise a system in order 
>to tinker with the traffic.  The contents aren't completely in need of 
>confidentiality, although it is common to restrict the information so you 
>aren't giving away active machines and names to attackers.  But should the 
>data change, that would be a problem.

My guess is that it would be very difficult to reconstruct files from
rsync traffic as it does magical things with existing files, acting like
a binary diff/patch, minimizing network traffic.

>> While BIND provides the ability to push from primaries to
>> secondaries, it doesn't deal with updating the named.conf file
>> which controls the domains the name server handles.  The djbdns
>> data files are *MUCH* simpler than BIND's, and it's easy to
>> manipulate them with simple shell scripts.
>
>hmmmm.. so you're letting a whole bunch of third-parties manipulate the 
>named.conf-like file?  ew..  How frequently do you add primaries that you 
>secondary for?  How many systems do you have like this?  And how many ISPs do 
>you service like this?

The tinydns-data files are extremely simple, and not easily corrupted.
Domains come and go fairly frequently, several times a week on average.
I'm aware of the changes as they show up in our daily security checks,
but rarely have to do anything active regarding secondary domains.
We only do this for ISPs that we actively support and trust the folks
doing the technical maintenance.

Bill
--
INTERNET:   bill at Celestial.COM  Bill Campbell; Celestial Software, LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
FAX:            (206) 232-9186  Mercer Island, WA 98040-0820; (206) 236-1676

"If taxation without consent is robbery, the United States government
has never had, has not now, and is never likely to have, a single honest
dollar in its treasury." -- Lysander Spooner, Letter to Grover Cleveland 1886