OVH can see if you torrent?

[Phogo]

Found this while looking for something on Pastebin. Its quite interesting, Does anyone have a OVH dedicated?

Background: OVH employs a set of perl scripts that are installed on their linux distros that allow you to view your system status; including processor utilization, hard drive status and utilization among other things in the OVH Manager - Server Status > Real Time Monitoring. These scripts also allow for OVH to proactively support your server if there are errors. These scripts are installed at the end of the installation process by a file that is left behind called 'install_rtm.sh' in the /root directory.

These scripts run via cron. There are a set of scripts that run each minute, each hour and daily.

Note: There may be an equivalent type of script/app on OVH Windows installs, however I've not run one yet, so I cannot confirm.

Now, most of the data is harmless and quite useful (smart status, drive errors, etc) the alarming item that I found was an hourly script called listen_ports.pl. This is a script that takes all of the processes, executable paths, ports used, and pid and transmits that data to the OVH RTM server so that it can be viewed in the OVH Manager. Now that may not sound bad, but you have to consider that every torrent you run is very identifiable.

As an example, this is what gets is reported to the OVH Server by this script on one torrent I have running (Spore):

hINFO_TCP_LISTEN_IP-0-0-0-0_PORT-61440_pid|5366
hINFO_TCP_LISTEN_IP-0-0-0-0_PORT-61440_procname|python
hINFO_TCP_LISTEN_IP-0-0-0-0_PORT-61440_cmdline|/usr/bin/python -OO /var/www/vhosts/domain.info/httpdocs/tf2/TF_BitTornado/btphptornado.py False 0 /var/www/vhosts/domain.info/httpdocs/tf2/files/.torrents/spore_reloaded.stat admin --responsefile /var/www/vhosts/domain.info/httpdocs/tf2/files/.torrents/Spore_RELOADED.torrent --display_interval 5 --max_download_rate 99999 --max_upload_rate 99999 --max_uploads 150 --minport 400 --maxport 500 --rerequest_interval 300 --super_seeder 0 --crypto_allowed 1 --crypto_only 0 --crypto_stealth 0
hINFO_TCP_LISTEN_IP-0-0-0-0_PORT-61440_exe|/usr/bin/python
hINFO_TCP_LISTEN_IP-0-0-0-0_PORT-400_username|apache
hINFO_TCP_LISTEN_IP-0-0-0-0_PORT-400_uid|48

You can see this data in OVH Manager by going to Dedicated Servers > Server state > Real Time Monitoring > RTM software

Note the .torrent file and port! That data for EVERY running process gets sent to the OVH servers. Now in theory this data is strictly for their proactive monitoring.... however, I think it can be used in a far more destructive way (as far as we're concerned - torrenting).

So, how do you stop it? Well there are a couple ways.

The first method - remove the script that sends up that data. The file that generates this data for the cron script is in the following location (at least on centos):

/usr/local/rtm/scripts/hour/listen_ports.pl

As su or root issue the following command:

mv /usr/local/rtm/scripts/hour/listen_ports.pl /root

This moves the script out of the directory that the main cron script looks at and puts it into the /root directory... that way you still have it if you want/need to put it back.

Now the second method is to simply stop the server from reporting ANY data from your server to their RTM server. For this we edit the cron job (recurring task) that runs the main script:

Using your favorite editor (nano, vi or pico) edit the following file:

/etc/crontab

And either comment out (using #) or removing the line:

*/1 * * * * root /usr/local/rtm/bin/rtm 46 > /dev/null 2> /dev/null

I would suggest simply commenting it out so that you can re-enable at any time without looking for what command was there. Commenting it out would simply look like:

#*/1 * * * * root /usr/local/rtm/bin/rtm 46 > /dev/null 2> /dev/null

Some important notes. I do not know if the lack of receiving the data sends up any alarms....so the first method of simply removing the listen_ports.pl file is probably best since the server will still receive data regarding the other aspects of the system. Also, on different distros there may be different locations, however the method of moving stays the same, just the location is different- use locate or whereis commands to find.

Source