Thank you so much for helping me make sense of it.
rb07 wrote:- ... Looking at the log would be interesting, I would expect an error logged about not being able to bind to that address;
I should've added that I grepped through Transmission Daemon's log and found nothing relevant. I "grep -i" for error, fail, rpc and bind as well as the rpc bind IP address.
rb07 wrote:- Who's doing this changes? I doubt it is an exploit aimed at the daemon (a RPC command -- are you using any 3rd party software to monitor/control the daemon?), more likely is something in the start-up script, or the options used by the script... but you already said that there is nothing wrong there;
I'm using Kylek's fun-plug package, like many tens or hundreds (or more) people. This only started recently.
I am using a 3rd party script - one that i wrote myself: A watchdog that restarts transmission when its memory usage (which tends to grow significantly over time - I seed hundreds of torrents 24/7) reaches some threshold value. It only interacts with the running daemon when it kills it. It kills it by sending it a SIGINT, not by RPC. You can find that script here:
http://forum.dsmg600.info/viewtopic.php?id=7132. Cron runs this script every 2 hours, and the daemon is restarted every 3 days or so.
So something changes (somehow) that rpc-bind-address, and the restart causes it to be written to settings.json and then used when started again?
rb07 wrote:[/list][*]How? As far as I know there are only 2 ways to change it: (1) editing settings.json, and sending a HUP signal so the daemon re-reads the configuration file (I'm not sure if the daemon will try to bind to the new address); (2) using the -r (or --rpc-bind-address) parameter. See why I still think this is done before the daemon starts?[/list]
hmm, before it happened the first time, I did play around with transmission-remote. I wanted to experiment a bit with the intention to expand that watchdog script to send me an email report of torrents that has problems, such as unregistered torrents. So I ran a few queries. "all" I did was run stuff like:
Code: Select all
transmission-remote --auth <user-name>:<password> -l | egrep "^[ ]*[0-9]+\*" | awk -F '*' '{ print $1}'
to grab torrent IDs and
Code: Select all
transmission-remote --auth <user-name>:<password> -t <ID> -i
To see what I need to grep in order to identify those errornous torrents.
I didn't know of the -r -or --rpc-bind-address. according to
transmission-remote --help is used to remove torrents. --rpc-bind-address isn't listed at all as an option.
That was a few days before this first happened. In the time period since it first happened and today I didn't use the command-line tool at all. Just the web interface and a couple of 3rd party front ends (transmission-remote-guy and transmission-remote dotnet).
rb07 wrote:Does your Linux distribution include the audit (or inotify, or dnotify) package? My NAS doesn't, and any of those needs a kernel configured to use it. There are other tools, FAM, Gamin, but these are unlikely to be on a NAS (they are used with GUIs).
[/quote]
That's a tougher one to answer. From searching the community hacking forum I'm pretty sure inotify isn't supported.