Skip to content

Secure your rsync shares, please.

Recently I started doing a internet-wide scan for rsync servers, thinking it might be fun to write a toy search-engine/indexer.

Even the basics such as searching against the names of exported shares would be interesting, I thought.

Today I abandoned that after exploring some of the results, (created with zmap), because there's just too much private data out there, wide open

IP redacted for obvious reason:

shelob ~ $ rsync  rsync://xx.xx.xx.xx/
ginevra        	Ginevra backup
krsna          	Alberto Laptop Backup
franziska      	Franz Laptop Backup
genoveffa      	Franz Laptop Backup 2

Some nice shares there. Lets see if they're as open as they appear to be:

shelob ~ $ rsync  rsync://xx.xx.xx.xx/ginevra/home/
drwxrwsr-x        4096 2013/10/30 13:42:29 .
drwxr-sr-x        4096 2009/02/03 10:32:27 abl
drwxr-s---       12288 2014/02/12 20:05:22 alberto
drwxr-xr-x        4096 2011/12/13 17:12:46 alessandra
drwxr-sr-x       20480 2014/02/12 22:55:01 backup
drwxr-xr-x        4096 2008/10/03 14:51:29 bertacci
..

Yup. Backups of /home, /etc/, and more.

I found numerous examples of this, along with a significant number of hosts that exported "www" + "sql", as a pair, and a large number of hosts that just exported "squid/". I assume they must be some cpanel-like system, because I can't understand why thousands of people would export the same shares with the same comments otherwise.

I still would like to run the indexer, but with so much easy content to steal, well I think the liability would kill me.

I considered not posting this, but I suspect "bad people" already know..,

Comments On This Entry

  1. [gravitar] Franco

    I hope the names were changed, or this could give a potential attacker an edge (or an unscrupulous person an indication of target).
    If not, please change them.

  2. [gravitar] Daniel

    Franco, if Steve was able to find those by scanning the default rsync port with z/nmap "potential attackers" likely will be able to do same without knowing the exact share names.

  3. [gravitar] Edgar

    cPanel itself doesn't do anything with rsync or squid. I also haven't heard of a panel which does use those. However it's possible that admins at a web host have set up their own system.

  4. [gravitar] Martin

    Would it be unreasonable to suspect that some of the findings are honeypots?

  5. [author] Steve Kemp

    Daniel, exactly.

    If you have to scan the whole network, and connect to every server, to find that host you've probably found a million others already.

    Honeypots? Good point, entirely possible. I tried to connect to a few and was denied, others let me right in, but I didn't try to connect to all of them.

    Here's an example of one of the "standard" results I found:

    shelob ~ $ rsync rsync://a.b.c.d/
    www            	websites' folder
    sql            	databases' folder
    dotsql         	dotsql' folder
    

    The host was running Sendmail, and showing Apache's standard "Installation test page". Which made me think of some kind of control-panel / or hosting-in-a-box solution.

    I found hundreds of IPs running those exact same three shares, with the exact same comments. (All the ones I probed had them ACL'd so that was good :)

  6. [gravitar] mirabilos

    Why are you using rsync:// in the first place?
    rsync works much better with ssh, anyway.

    I fully blame Debian's insane default of starting any
    and all dæmons contained in packages installed, when
    I never used/needed an rsync dæmon, only the executable
    for calling it via ssh.

  7. [gravitar] mirabilos

    By the way, your website is broken: blog.steve.org.uk
    has got an AAAA record, but no IP connectivity (neither
    web nor ping respond), only Legacy IP. This does break.

  8. [author] Steve Kemp

    I personally am not using rsync, except in sensible fashions! In the general case I use rsync over ssh, to ensure that I get encryption and avoid issues with authentication.

    However I will say that Debian is not to blame here, by default rsync is not started as a service, not unless you set RSYNC_ENABLE in /etc/default/rsync.

    As for the IPv6 there does seem to be something wrong, but I'm thinking it is ISP-related rather specific with my host. Annoying though, thanks for reporting it.

  9. [gravitar] mirabilos

    The RSYNC_ENABLE option is pretty recent, though… it used
    to be (not too long ago) that it was automatically started.

  10. [gravitar] Ewen

    No, mirabilos, you are lying.

  11. [gravitar] Martin

    I tried it and after 5 min I found the first server with a backup public available. That's alarming. But the positive effect was: After writing to the webmaster it took approx. 10 minutes until user_auth got enabled. ;)

    Have you told the webmasters directly?
    I guess not everyone is reading your blog. ;o)

  12. [author] Steve Kemp

    Martin, sadly I could only find one IP which exposed private data and had an obvious contact address.

    As per my prior comment too often they were just associated with residential ISPs, and couldn't be pinned to a specific individual.

  13. [gravitar] Daniel
    • Added init.d script for those who want to start rsync in daemon mode
      automatically. You'll need to edit /etc/default/rsync and create an appropriate rsyncd.conf file to actually get it to start. closes:#211007

    -- Paul Slootman <paul@debian.org> Mon, 5 Jan 2004 16:00:22 +0100

    The /etc/default was added in the beginning of 2004. It is very likely that rsync was disabled by default even before that change.