PeerGuardian2 - Blast from the past, who’s watching you? Or should I say me?
This little blast from the past got me thinking, who else but me is monitoring P2P file sharing networks, law enforcement agencies maybe?
From past research I remembered that peerguardian2 had hundreds of known agency IP’s blocked, so I thought I would give it a try. I run peerguardian2 and Limewire together and done a few searches for private file types, I have done this many times before with my research but never gave a thought to who else but the general public I was interacting with.
I didn’t realise until after I started doing this test just how many agencies are actually watching P2P networks. I was actually quite amazed by how many IP's peerguardian2 was blocking, within 30 minutes peerguardian2 had blocked 118 IP’s, some of which;
Net2EZ,
Centre Reseau et Communication Universite Louis Pasteur,
Greek Research and Technology Network S.A,
Phyber Communications-MediaDefender,
Limelight Networks LLC,
AAFES/Barracks,
Time Warner Telecom.
A number of universities were also blocked, some of which;
Bergen University Norway,
University of Cincinnati,
Southern Illinois University at Edwardsville,
University of Portsmouth,
University of Sunderland,
Virginia Union University.
At first I was quite impressed with how many agencies are actively monitoring these P2P networks, I’m not sure if there logging IP's for possible prosecution or just researching P2P networks in general. There was quite a few university IP’s amongst the blocked list, maybe they are researching P2P networks also, or it could just be some university student using a P2P file sharing program on his/her computer in there dorm room?
I bet with the amount of research I have been doing my IP has been logged a few hundred times across several agencies, I’m kind of expecting a knock at the door any day now, oops.
Hmmm, now whilst I’m writing this I just glanced back at peerguardian2 only to find more IP’s being blocked right now, I have not run any P2P program in the past 2 days or any program that should be attracting any attention what so ever, but that’s not the scary part. This is an outbound connection that has been blocked from me to “HQ-5th Signal Command” which is a military installation in the US, now looking back at the data from the test (AAFES/Barracks) which according to Google could be “Army and Air Force Exchange Service”.
It would be worrying enough to think that they where probing me, but for the connection to be coming from me to them is making me wonder what the hell is on my computer attempting connection with them?
I will be looking into this in more detail over the next few days.
Peerguardian2 will be added to my FREE software section because this program has very good security related properties, such as the ability to block known spyware/malware and popup advertising IP ranges.
After reading today about the latest laws allowing police to hack anyone’s computer without a warrant or without your knowledge, I believe everyone has the right to protect them self against privacy intrusion.
Part 2 tests with peerguardian2 and limewire continued ......
I decided to do a reverse test, I made up 500 files ranging from fake personal documents to known picture filenames, popular ones used by many digital cameras. I placed these 500 or so files into my shared folder.
I started limewire with peerguardian2 already running. Now I allowed limewire to share the test files.
On limewire under ‘Monitor’ tab, I ticked ‘Show Incoming Searches’. This allows you to see what files others are searching for.
Instantly hit after hit started to come in at a rate of about 1 per second. This was expected.
What weren’t expected were the repeated hits for some strange file requests over and over, when I say repeated I mean over 500+ hits each within the 50 minute test. I took a few screenshots see bellow.
The sorts of hits that I expected to get and did were;
Account, account bank, curriculum vitae, confidential, dsc00037, dscf0014, private, personal.
What I didn’t expect was the following repeated searches;
This was not random, I don’t have any files on my computer with those file names, and they where repeated over and over, in fact I just started limewire whilst I’m writing this and still a day later the same searches again, none stop.
Also during the 50 minute test no one actually downloaded any files from my limewire client, so it seemed someone or some agencies where just searching/logging the results and not actively downloading anything.
After doing some more research about how limewire sends and receives search results I decided that Limewire is not the best P2P client to use in this kind of test, this is due to limewire using Gnutella1 protocol.
If you’re not up to date with how gnutella1 protocal sends and receives search results read this extract from wiki bellow.
“When the user wants to do a search, the client sends the request to each actively connected node. Historically (version 0.4 of the protocol), the number of actively connected nodes for a client was quite small (around 5), so each node then forwarded the request to all its actively connected nodes, and they in turn forwarded the request, and so on, until the packet reached a predetermined number of "hops" from the sender (maximum 7).
With the advent of version 0.6, Gnutella is a composite network made of leaf nodes and ultra nodes (also called ultrapeers). The leaf nodes are connected to a small number of ultrapeers (typically 3) whilst each ultrapeer is connected to more than 32 other ultrapeers. With this higher outdegree, the maximum number of "hops" a query can travel was lowered to 4.
Leaves and ultrapeers use the Query Routing Protocol to exchange a Query Routing Table (QRT), a table of 64 Ki-slots and up to 2 Mi-slots consisting of hashed keywords. A leaf node sends its QRT to each of the ultrapeers it is connected to, and ultrapeers merge the QRT of all their leaves (downsized to 128 Ki-slots) plus their own QRT (if they share files) and exchange that with their own neighbours. Query routing is then done by hashing the words of the query and seeing whether all of them match in the QRT. Ultrapeers do that check before forwarding a query to a leaf node, and also before forwarding the query to a peer ultra node provided this is the last hop the query can travel.
If a search request turns up a result, the node that has the result contacts the searcher. In the classic Gnutella protocol, response messages were sent back along the route the query came through, as the query itself did not contain identifying information of the node. This scheme was later revised, so that search results now are delivered over User Datagram Protocol (UDP) directly to the node that initiated the search, usually an ultrapeer of the node. In the current protocol, therefore, the queries carry the IP address and port number of either node. This lowers the amount of traffic routed through the Gnutella network, making it significantly more scalable.”
So to put this in plain English, any agency or individual that sends a search will first go through a number of ultrapeer’s before it reaches me.
When my client sends a positive match this will probably go back to the ultrapeer of the searcher and not directly to the searcher. So during the search procedure at no given time will my client and the searcher have a directly connection, so there IP will be masked by the ultrapeer’s IP meaning peerguardian2 will have no logs of their IP and in fact not be able to block them from searching my client at all.
Peerguardian2 will block them from downloading any files from my computer, this is probably the reason that during the test no actual downloads occurred, only searches.
I will be looking into other P2P programs and networks such as gnutella2 for further tests.
