Security implications when using rsync

Before using a utility like rsync, first identify the contexts in which rsync is intended to be implemented. Consider the strengths of various authentication methods and the validity of trust between machines. Utilities like rsync can propagate several things: i.e. updated data as intended, malice in the form of trojans or exploits from hackers, mistakes from ill conceived commands. It could also facilitate "data siphoning." The underlying data transfer protocol should be free of potential to be subverted if it is used over public network facilities. Rsh can be subverted by another machine masquerading as the trusted host. If the hosts know each other but an individual is not trusted on both machines, a clear text password may be exchanged over an insecure channel. Ssh is a step in the right direction but not necessairly complete depending on how it is employed. Kerberos in combination with ssh takes things a step further and is sufficient for most needs "IF" the kerberos server is genuinely secure.

All that being said, I might use PGP signed and encrypted mail to exchange pass phrases or session keys before the initiation of any rsync session and just use ssh. If more paranoia than that is rampant, I'd establish a web of trust between several machines, and then have those machines vote on the authentication of any single host within a limited amount of time. I'd also log the living daylights out of things including using traceroute to enumerate the public paths used, and nslookup with several name servers, and checking that against an encrypted cache of what should be so to see if everything's as expected. Compromised machines or communications channels should be detectable and voted out of the web of trust, and appropriate notification delivered through still trusted channels to alert those responsible for maintaining trust. A method of rapidly purging a compromised machine should be established. Having several alternate /boot, / and other filesystems and several alternate lilo.conf files might provide a means to rapidly reboot to fresh storage media so that a machine might be re-validated and readded to the web of trust while providing a snapshot of what had been compromised for purposes of discovering the nature of the damage done and methods used to attempt forced entry. I might also consider setting up nodes in twos or threes with each location with each having the ability to immediately remove power to the others in the event of a breach of trust. I like the idea of a two stage boot with the first part from read-only media asking the other hosts if it has been voted out of trustworthyness before continuing on to use writable storage.

Were I to be an ISP or something of the sort with several farms of machines, I'd do all this stuff. Is that enough paranoia for you?

Brian