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

Paul M. Cook · 2015-12-23T03:53:30+00:00

Does this activity found accidentally in my home broadband wireless router logs seem suspicious to you? Here is a screenshot of the suspicious log entries: When "I" log into my router, I see a line like this: [Admin login] from source 192.168.1.16, Tuesday, Dec 22,2015 19:16:15 But, I see the following (suspicious?) activity in my log file: [LAN access from remote] from 93.38.179.187:9000 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:42:41 [LAN access from remote] from 177.206.146.201:9000 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:41:54 [LAN access from remote] from 101.176.44.21:1026 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:34:19 [LAN access from remote] from 181.164.218.29:9000 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:34:19 [LAN access from remote] from 2.133.67.47:11233 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:34:19 [LAN access from remote] from 186.206.138.72:62531 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:34:19 [LAN access from remote] from 148.246.193.87:9000 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:34:19 [LAN access from remote] from 195.67.252.183:49076 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:34:16 [LAN access from remote] from 1.78.16.174:47891 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:34:16 [LAN access from remote] from 178.116.59.223:9000 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:34:16 [LAN access from remote] from 82.237.141.86:9000 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:34:16 [LAN access from remote] from 107.223.217.54:9000 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:34:11 [LAN access from remote] from 216.98.48.95:11020 to 192.168.1.5:9000, Saturday, Dec 19,2015 06:32:31 I don't know what this really means: "LAN access from remote". Looking at the router wired & wireless list of devices, 192.168.1.5 seems to not be attached at the moment. But, looking back, I can determine (from the MAC address) that it's my child's Sony Playstation (which has "UPNP events" whatever they are): [UPnP set event:...

Dec 23, 2015 83 Replies

Rate this thread:

J G Miller 10 years ago

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.)

Vote

Paul M. Cook 10 years ago

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?

Vote

J G Miller 10 years ago

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.

Vote