Review of my home broadband router logs (suspicious activity?)

On Friday, January 1st, 2016, at 19:07:29h -0500, Paul M. Cook reported:

Did you restart transmission after making all the changes? Sometimes it (and other software) can be unreliable at changes whilst running.

However more than probable that is not the issue, so here is the check list with the most likely cause being #2

1) On the router did you assign a fixed IP to the MAC address of wlan0 2) Did you check that the IP address on the host had changed, either by manually restarting the WiFi or rebooting the machine, and then checking again with ifconfig that wlan0 had the fixed IP address that you think it should 3) On the router did you check, after rebooting the router, that the rule was there to forward both TCP and UDP from external port NNNN to intenal port NNNN 4) Did you check that transmission was set to use port NNNN as the communications control port? 5) Did you restart transmission just to be sure the new setting was activated and then do the check port test?

Leave that box unchecked since turning it on will cause transmission to try both when it does not need to because you are doing the port forwarding on the router.

Also if you are p2ping with a private tracker make sure that DHT and PEX are turned off, or you will get banned from using the private tracker.

Reply to
J G Miller
Loading thread data ...

This is incorrect. bittorrent is a protocol. The number of queues and their priority is something which is client dependent. The clients may contain code which lowers their upload priority to other clients who are not sharing (leech only mode) either wilfully or because their communication control port is blocked.

No there are many queues. The remote p2p client may be sharing many other files and the sharing of those other files may be set at a much higher priority than the one you are trying to get. Also some clients allow setting a maximum number of connections per torrent. So if remote p2p client is already sharing with say 4 others, and has a maximum of 4 clients set, you will just have to wait until one of those other 4 drops off before you can download from that particular remote p2p client.

p2p is all about sharing which means both uploading (seeding) and downloading (leeching). If other people were not prepared to share, you would not be able to download anything, so it is only fair and proper for you to be connectable and share what you have downloaded with others who are trying to download.

You do not have to use uPnP in order to turn on random port feature. What you do have to do is to set a limit on the random port range and then use that random port range (external port start through external port end to forward to internal port start through internal port end) in your port forwarding on the router.

So do not use the default - pick something else. Security by obscurity must never be relied upon, but it does not hurt.

Also something else which should have been emphasized -- do not run a p2p client from your own userid.

Create a separate user p2p with its own password and home directory etc and run any p2p client solely under that user account.

NEVER EVER, EVER run p2p client as root, because it is not just a client but is a daemon as well, and daemons with bugs are ways of compromising (ie cracking into) a system.

(And on distributions which have sudo facilities, ensure that the p2p account cannot sudo to anything.)

Reply to
J G Miller

I loved all your corrections, and I understood all but this one. I can "guess" why, which, I guess, is so that you have plausible deniability? Or is there another reason not to use you own login for P2P downloads?

Reply to
Paul M. Cook

As explained the p2p software is running as a client but also as a daemon.

If there is some, unyet discovered bug in the daemon part of the software, a cracker could connect to the daemon and possibly get shell access.

If the daemon is running as p2p, then only the files belonging to p2p are compromised and anything else which is world readable and of course that keeps files belonging to pmcook safe so long as files/directories for pmcook are not world readable of course.

Afterall pmcook may use gnucash or some other personal finance tool and would not want details of his transactions revealed to unauthorized malicious intruders, because, unless it has changed and I am not aware that it has,

"GnuCash does not use any built-in encryption."

If the daemon was running as root, it is game over, and the cracker can as root do anything, unless of course limitations were imposed by either selinux or apparmor.

Disapointingly (as far as I am aware) none of the main distributions have included an apparmor profile for transmission or similar p2p software to limit capabilities.

Reply to
J G Miller

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.