I'm using PeerBlock at my apt in auburn al. via Charter.

About every 10 minutes i get spammed by a connection 8-12 times. Here is the connection info:

Range: F-SOS/F-Secure
Source: 5.207.228.242
Destination: 206.112.100.132
Protocol: Unknown

*sometimes* the source comes from my own ip (192.168.1.x)

The ARIN whois reports this:

Quote :

" MCI Communications Services, Inc. d/b/a Verizon Business NETBLK-UUNETCBLK-112 (NET-206-112-0-0-1) 206.112.0.0 - 206.115.255.255 Almar Networks, LLC UU-206-112-100-128-D (NET-206-112-100-128-1) 206.112.100.128 - 206.112.100.159 "

any thoughts?

1/10/2010 2:37:31 AM

Are you sure 206.112.100.132 isn't your address?

5.207.228.242 is unallocated.

1/10/2010 1:19:11 PM

negative, my ip is
71.91.20.xx

I'm confused as to why *sometimes* it originates from my 192.168.1.x ip in the middle of the spam. I.E. it will come from the 5.207.228.242 for say..the first 3 or 4, then maybe 2 or 3 from the 192.168.1.x, then back to the 5.207.228.242, but all sharing the same destination of 206.112.100.132.

The ARIN whois report of 5.207.228.242 is:

Quote :

"OrgName: Internet Assigned Numbers Authority OrgID: IANA Address: 4676 Admiralty Way, Suite 330 City: Marina del Rey StateProv: CA PostalCode: 90292-6695 Country: US NetRange: 5.0.0.0 - 5.255.255.255 CIDR: 5.0.0.0/8 NetName: RESERVED-5 NetHandle: NET-5-0-0-0-1 Parent: NetType: IANA Reserved Comment: RegDate: 1995-07-07 Updated: 2002-09-12"

How is a connection thats not me showing up as a source under PeerBlock?

1/10/2010 4:34:59 PM

do you have hamachi installed? my hamachi used to give me a 5.xxx address.

The 5.0.0.0/8 network is used to avoid collisions with private IP networks that might already be in use on the client side

1/10/2010 4:46:12 PM

5.207.228.242 is an unallocated address. Nobody should be using it.

Sure you don't have a trojan/malware/virus/etc?

I'm not familiar with PeerBlock...do you have logs to see what on your computer is originating requests?

[Edited on January 10, 2010 at 4:50 PM. Reason : I need to type faster...nobody should be using 5.xxx, certainly not anyone external to your LAN.]

[Edited on January 10, 2010 at 4:51 PM. Reason : hamachi is a really good idea, though]

[Edited on January 10, 2010 at 4:51 PM. Reason : now you're ghostediting ]

1/10/2010 4:47:11 PM

Nice call, I do have hamachi installed, and that may be the issue, ill disable the connection and see if it continues.

Ive done several different scans and am fairly positive i dont have any trojans/malware/virus

No, peerblock does not show what on my computer is originating the requests.

Ill post again with the update of disabling hamachi

1/10/2010 4:56:20 PM

Quote :

"Each Hamachi client is assigned an IP address from the 5.0.0.0/8 address block. This address is assigned when the client logs into the system for the first time, and is henceforth associated with the client's public crypto key. As long as the client retains its key, it can log into the system and use this 5.x.x.x IP address. The 5.0.0.0/8 network is used to avoid collisions with private IP networks that might already be in use on the client side. Specifically - 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. The 5.0.0.0/8 address block is reserved by IANA and is not currently in use in the Internet routing domain, but this is not guaranteed to continue. The IANA free pool is expected to be exhausted by February 2011.[1] If this range is allocated, Hamachi users will not be able to connect to any Internet IP addresses within the range as long as the Hamachi client is running. Additionally, using a separate network prefix creates a single broadcast domain between all clients. This makes it possible to use LAN protocols that rely on IP broadcasts for discovery and announcement services over Hamachi networks. Hamachi is frequently used for gaming and remote administration. The vendor provides free basic service and extra features for a fee."

1/10/2010 5:00:17 PM

Ok, after disabling hamachi i no longer have any outgoing connections from the 5.207.228.242 ip. However, I still have outgoing connection spams from my own internal ip: 192.168.1.3 as the source and 206.112.100.132 as the destination.

The connection was attempted 29 times, bursting 4-8 times within a minute or 2, then repeating that pattern every 10-15 minutes for over an hour.

for quick reference:

source: 192.168.1.3
destination: 206.112.100.132
Range: F-SOS/F-Secure
Protocol: Unknown
Action: Blocked

I wanted to also add that just recently, over xmas break, I was back home in apex, NC using my parents net. I had none of this spam and never a connection from my own computer as the source.

Here is a cap of my PeerBlock


Any more thoughts?

[Edited on January 11, 2010 at 1:37 PM. Reason : bad link]

[Edited on January 11, 2010 at 1:38 PM. Reason : .]

[Edited on January 11, 2010 at 1:39 PM. Reason : .]

1/11/2010 1:36:10 PM

http://www.dslreports.com/forum/r17871432-Charter-Corrupting-DNS-protocol-ie-hijacking-hosts

1/11/2010 1:47:58 PM

I had previously read that article and it would make sense if the connection was being made every time i entered an incorrect domain. But those connections are being attempted while the computer is idle.

That pic i posted above occurred while I was in class

1/11/2010 4:34:38 PM

something else is probably doing a DNS query and its getting eaten by comcast. Setup wireshark and look for dns queries prior to the 206.112.100.132 stuff. Wireshark will also show you the contents of the 206.112.100.132 packets too, so you can see what they actually are.

1/11/2010 5:07:51 PM

alternatively just get rid of peerblock since its dumb as hell

1/11/2010 5:14:39 PM

Quote :

"alternatively just get rid of peerblock since its dumb as hell"

this wouldn't fix my problem

I got wireshark up and running and filtered for 206.112.100.132. I will update you all when it caps it

1/11/2010 6:23:27 PM

i agree with ^^^

1/11/2010 6:57:50 PM

I have wireshark up and running, but i'm having trouble filtering it so that it only shows packets sent to 206.112.100.132.

From the help section examples, the filter should read "net 206.112.100.132" (i think) which i have applied. Is this the right way to filter it?

1/11/2010 7:20:17 PM

there are kind of two "filters" in wireshark. Theres the capture filture which you configure before starting the capture, and then theres the live filter which you put in that box during the cap to filter the results.

For the caputre filter i think its "host 206.112.100.132" (there should be saved filters you can look at for examples). For the live cap filter, it would be ip.addr==206.112.100.132. That filter will turn green when the syntax is all good.

1/11/2010 7:44:50 PM

I left wireshark running last night while active on my computer and left peerblock up this afternoon while in class, No connection attempts to the 206.112.100.132 have been made. But there have been several attempts from my 192.168.1.3 local to 67.159.44.118 which is FDC servers in chicago, which Peerblock lables as antiP2P. This all happened while i was in class, with utorrent seeding. Are these connections coming from my utorrent?

1/12/2010 3:31:28 PM

Looks like they're a hosting company. Could be the mpaa trying to steal your data or it could be some seedbox with a bunch of bandwidth that you cant get to becuase you use some piece of shit software to block it.


Seriously. peer bock does 0 to prevent anyone from seeing your computer in the swarm. All the MPAA/RIAA/whoever you're scared of has to do is scrape the tracker and they have everyone in the torrent.

That said, to actually figure out what type of traffic that is since peerblocker isn;t smart enough, you can either look at what ports your client is using (if its set to random consider setting it to a specific port) or remove your capture filter from wireshark and once you capped enough data, use the search tool to narrow down individual packets for inspection.

1/12/2010 3:38:55 PM

my utorrent uses 42000 which is why i was confused by the connection attempts to FDC servers coming from *seemingly* random ports, meaning utorrent wasnt the one trying to make the connection.

I'll run wireshark and see if i can figure out whats causing it

1/12/2010 5:06:39 PM

Quote :

"my utorrent uses 42000 which is why i was confused by the connection attempts to FDC servers coming from *seemingly* random ports, meaning utorrent wasnt the one trying to make the connection"

I don't think you understand how the internet works.

Quote :

"Seriously. peer bock does 0 to prevent anyone from seeing your computer in the swarm. All the MPAA/RIAA/whoever you're scared of has to do is scrape the tracker and they have everyone in the torrent. "

Being listed by the tracker means nothing. In order for the DMCA to be violated, a distribution must take place. If your computer does not respond to a request, then they don't have a legal leg to stand on. They can send you takedown notices all day, threaten to sue, and harass you, but it ultimately amounts to bullying. Consider:

- User 1 connects to tracker and shares a file on 1/1/2010
- User 1 then disconnects from the internet
- User 2 connects to the internet and the DHCP server assigns User 1's old address on 1/2/2010
- RIAA/MPAA agent connects to tracker on 1/2/2010 and finds the IP address in the tracker, which hasn't updated yet, or gets it from another peer.
- agent send request to ISP who identifies User 2 as the user who was using that IP address on that particular day
- agent sends takedown notice to bewildered User 2.

http://dmca.cs.washington.edu/

The agents use this method because it is cheap and it produces results (settlements) because people just assume they were caught red handed even though no evidence was collected against them. Collecting evidence is not feasible because it would require the agents to download files in their entirety and keep track of peers who sent pieces that didn't fail a hash check. (They can't know if the file contained intellectual property unless they download it.) I would respond to a DMCA notice with a request for a record of the actual bytes they downloaded from my computer that represented their intellectual property.

1/14/2010 7:53:12 PM

First off trackers contain completion info as well as ip information. If a client reports the to tracker that its downloaded information, the hashing system guarantees that data matches the files in the torrent. All they need to know is that the files in the torrent are copyrighted data and that someone has reported transfering the data back to the tracker. The dont need to connect directly to a peer to guarantee that they actually participated.

Second, this:

Quote :

"agent send request to ISP who identifies User 2 as the user who was using that IP address on that particular day - agent sends takedown notice to bewildered User 2. "

is wrong. ISPs have records of who has what ip address at any given time. If the MPAA/RIAA ask for information about who had the ip on 1/1 they'll get the right person from the ISP.

Thirdly, its the height of stupidity to assume that whatever moron maintains the peer block list knows every possible ip address the mpaa/riaa would use. Its dead simple for them to simply use a residential connection to get an address in a dynamic range which peerblock would never block (unless its ultra retarded).

Lastly, even if they can prove that you downloaded something directly from their client 100%, they cant prove it was you. The best that can happen is they use the clauses in your ISPs eula that say you're responsible for everything that happens on your connection.

1/14/2010 10:33:09 PM

Quote :

"First off trackers contain completion info as well as ip information."

This doesn't mean shit. The DMCA does not say you can't receive the material; it says you can't distribute it. Even if this data could be relied upon and weren't easily spoofed, it doesn't mean shit. (Notice the DMCA notices always tell you to stop sharing / offering for download / uploading. They don't say stop downloading.)

Quote :

"The dont need to connect directly to a peer to guarantee that they actually participated."

Yes they do. The information from the tracker is inherently unreliable because anyone can submit any data they want to it. The only way to prove you distributed the content is to actually observe the distribution. If I told the MPAA you were giving away bootleg copies of Transformers, they can't do shit (except make retarded legal threats) unless they catch you distributing it. You could have 50,000 clearly labeled copies in the back of a truck, but they can't do shit til one of them changes hands.

Quote :

"ISPs have records of who has what ip address at any given time. If the MPAA/RIAA ask for information about who had the ip on 1/1 they'll get the right person from the ISP."

Except they wouldn't ask for the 1/1 data because they checked the tracker on 1/2 in my example. Most trackers, especially public ones, won't keep up with the changes in peers. Find a public torrent online with tons of peers and get the peer list. Then try pinging them. You'll find that some of the peers are offline (and some that are online may not be active because they already disconnected). A client may not always report its disconnection to its own tracker and it won't report it to a different tracker that got it from a peer using DHT.

Quote :

"Thirdly, its the height of stupidity to assume that whatever moron maintains the peer block list knows every possible ip address the mpaa/riaa would use."

I didn't argue the for the validity of these lists. I agree that they do little to protect you, but little is not nothing. They are easily compiled because the MO is obvious (connect to a tracker and get the peer list for tons of torrents, but don't report any activity).

Quote :

"The best that can happen is they use the clauses in your ISPs eula that say you're responsible for everything that happens on your connection."

Your terms with the ISP (and actually some laws and the DMCA itself) protect the ISP from civil and criminal liability associated with activity on your connection. You can use the "it wasn't me" defense, but if civil litigation ensues, that will likely be verified.

1/14/2010 11:27:09 PM