Jump to content

Latest Bittorrent Poisoning attack from the U.S.A.

Download Dick

Recommended Posts

Fortunately, all those ip ranges have been included in the latest blocklists.

And I've made it a habit for a LONG time now to block most/all the 38.x.x.x range as a precautionary measure while using file sharing.

Occasionally, I'll do a little research to discover if a blocked ip is a false positive, but most of the time there's no WHOIS information on them or it points to "shell" companies without much of a hint as to the nature of what those companies do.

Link to comment
Share on other sites

I have the "Safepeer" plugin, but I don't run it in blocklist mode, because it blocks far too many IPs. I was only getting a drip from a torrent that was not under attack, and when I turned off blocklist mode then it completed normally.

There has to be a better mechanism.

Can the original uploader specify (ala a Bittorrent protocol) banned ranges after the torrent is underway? This would be ideal when there is an attack. Also, I can't email the uploader anymore on TPB, clicking on the name no longer gives an email form, but instead a list of torrents that they've uploaded.

You're running the "latest blocklists" doesn't help even yourself.

This one seems thoroughly poisoned:


It went from 20.9% to 21.1% completed for everyone overnight. That's it.

I've got the poisoning IPs blocked, but the torrent is going nowhere. It would be the same for you.

Link to comment
Share on other sites

If there's no seeds left on a torrent and availability is stuck at 21-something percent, then yeah that torrent WON'T complete even if there's no poisoners left.

The damage is already done.

Ironically, the only ips I see blocked in my logs are the ones in the ranges you said to block.

...So my blocklist is nowhere nearly as severe as many. I gave up blocking "bogons" when I realized that bogons were being mapped out by new ISPs and old ISPs alike that were looking for unused ip ranges. That VASTLY reduced the "area" of block ranges even though the number of blocked ranges only decreased by maybe 15%.

I'm just using ipfilter.dat rather than any external program. Better to let µTorrent avoid TRYING an ip that is probably hostile than rely on a separate program to block/stop/break the connection after µTorrent tries to initiate it. Even if there's no issue of the other ends seeing a very brief connection to them from me, there's still the issue of system resources/cpu cycles getting tied up. Some networking hardware + software don't even like connections being made and broken quickly.

Link to comment
Share on other sites

There's no fix you can do on your end that would help. A 'centralized' blocklist that everyone is forced to use wouldn't help either...the wrong people would be blocking everyone they could if they got control of such a blocklist.

It is remotely possible the tracker server could block hostile ip ranges, but that would require manual control of the tracker...which may not be possible either.

With the problem not being on your end, you really can't do much. :(

Link to comment
Share on other sites

Switeck wrote: There's no fix you can do on your end that would help.

Exactly. And in the war between us and the RIAA/MPAA, it is now our move.

You sound defeatist.

It's a matter of listing possbile new defensive mechanisms, then implement them.

I think there should be a mechanism to spot poisoners (a plugin) and another for communication (from the plugin or the original uploader) about possible poisoning and the IP ranges to block if you so choose.

Link to comment
Share on other sites

I'm "defeatist" the same way as not wanting to attack a rabid bull elephant with a butterknife is defeatist. When the problem is external and indirect to you, you can only go on the defensive.

If the initial seeder has a decent blocklist and/or the tracker has a decent blocklist, this may not even be a problem.

There's no need for NEW defensive measures as just actually using the existing ones. A tracker could change its blocklists as little as once a month and still eliminate the vast majority of the problem. (...or be a private invite-only tracker.) The server farms that poison are often "locked" in narrow ip ranges that show up like a sore thumb for everyone on the torrent. They can buy/rent new ip ranges, but that gets expensive and self-defeating as a long-term strategy...adding a new blocked ip range is trivial.

"Home grown" poisoners aren't nearly as effective as they have neither the numbers nor the bandwidth compared to the server farms, so they would have to be considerable in number before they'd even have a noticeable influence. ...even moreso if they're firewalled! :lol:

The default treatment of hash fails does need to change, and it IS slowly evolving so that even without a blocklist you have a reasonable chance of downloading a poisoned torrent. So if you want that to improve, describe the logic in as great a detail as you can muster for how to improve it. The biggest problem I see myself is innocent ips get blamed for poisoning due to multiple ips contributing to individual 1/2/4 MB pieces of a torrent.

Link to comment
Share on other sites

Like I said, I'm not an expert on the low-level details.

Did you say a tracker can propagate block lists to peers?

If not, that's not going to be a solution.



# If you see something like 12 (4) it could mean the tracker knows about 4 seeds in the swarm, but thanks to DHT you did connect to even more!

Should a tracker be allowed to turn off a peer's use of DHT to in effect pass on the effect of its blocklists? Right now I don'r think the P2P clients support this.

Link to comment
Share on other sites

It is nothing new for trackers to disallow the use of DHT for the torrents on that tracker. That's called a private tracker or private torrent.

People, or rather their ips, can and DO get blocked/locked out of a torrent by a (private?) tracker. Even public trackers block ips from time to time for particularly hostile behavior. And if the tracker doesn't allow certain ips on that torrent, then they WON'T be on that torrent. That part's already been done, for better and worse.

However, a tracker cannot "give" the peers/seeds anything in the way of blocklists.

And it shouldn't. A central point of origin is also a central point of failure. It can be "strongly recommended" at the tracker's website to use certain blocklists, but it would probably be for the best to not make it mandatory.

I've already seen what happens when blocklist makers decide to include ips of people they have personal grudges against, instead of legitimate, justified reasons. ISPs are already doing pretty much the same thing against their own customers that use file-sharing programs. It's the wrong approach, the wrong route, and it arrives at the wrong destination. We'd end up with an "internet" that has many parts blocked off from the other. Communication could just die. This is already happening, and to a lot more than just file-sharing. Read about the "Great Firewall of China", or the filters countries like United Arab Emirates and Saudi Arabia uses.

A good blocklist needs to be as short as possible and as RECENT as possible. Old entries should be rechecked and probably dropped from time to time. The internet is a changing place, ips of consumer connections can be presumed to change roughly once a month. Some change more, others less...but it's still a decent "yardstick" for how long to keep an "offending" ip in a home consumer ip range. And even businesses may have their ips change every few years, especially if they become dissatisfied with the parent ISP they use!

Link to comment
Share on other sites

Switeck: A good blocklist needs to be as short as possible and as RECENT as possible.

Agreed. The owner of the tracker/torrent should propagate an emergency blocklist (very short) and only when under attack (very recent).

Yet another torrent is under attack:


What are your suggestions for mechanisms to disconnect the poisoners from killing a swarm?

Keep in mind that depending on peers to blocklist isn't working, and there's no way for a peer to know which other peers are losing share by feeding poisoners.

I'm at a 10.27 share, having uploaded 2.82 Gb on a torrent that's only 430 Mb in size, trying to overcome the poisoners, but I think we've finally lost the true seed, which must have been overwhelmed. They killed the torrent.

Can you come up with something?


Edit update, May 10th, 2007.

I disabled filters, waited 30 minutes for several dozen of the poisonous IPs to become peers and let it run for a while longer.

I then copied the profuse log to a text file, made a one-line shell script to grep out the four IP ranges...

None of them are sucking up share.

(I run Azureus.)

What I did notice is that they sent a lot of "AZ_PEER_EXCHANGE for infohash ... with 40 added and 0 dropped peers."

Can that kill a torrent?

As shown in the torrent pictures that I've put up, there are more "poison" IPs than legitimate ones. Can that be accomplished via repeated transmissions of peer exchanges that specify only the bad guy's IPs?

It seems like they are isolating sets of good peers into swarm sets, and effectively blocking the one true initial seed from uploading.

In this torrent:


...I am seeing 93 valid peers, cos I'm blocking the bad guys. But we're still dead at 65.1%. One peer is at 69.6% which is the only reason we ever so slowly creep upward. But only 2% over the last 24 hours. That's the one where I'm at a 10 share.

I'm guessing most of the other peers aren't blocking the right IPs, and so they get isolated such that there are more bad IPs in their current swarm than good ones.

The TPB page for that torrent says there have been 718 downloads. But there have been zero downloads, I joined the torrent early and would have completed.

The page also says there are 17 seeds. There was only one seed to begin with, and I think it's given up.

So the TPB tracker involved is displaying false stats due to the poisoners.

In this torrent:


...I got in early and completed in 10 minutes. I actually have that CD in front of me, I purchased it from Amazon. But they sold me the child's version, wiped of naughty words. I was going to send it back and order the "PA" one, but what the hell...

Regarding the torrent, I seeded for a while. When I tested the effect of turning off my filters, after a while I ended up with *only* the bad guys connected to me. When I turned the filters back on, after a while four real peers connected again.

So, I'm guessing that repeated transmissions of peer exchanges are causing swarm fragmentation such that no one is getting data anymore. I have seen bad guy seeds connect in too.

What do you think?

I'm not technical on the Bittorrent protocol, although I am an admin type.

My Azureus logs don't show the IPs in the peer exchanges.

Can someone further analyze this? Is it a clever attack using a weakness in the Bittorrent protocol itself?

Link to comment
Share on other sites

It's not an especially clever attack, it just takes advantage of the protocol. I recently was on a poisoned torrent and was getting 10 or more connection attempts a second from the poisoners. All they would do was upload 20-60% of a piece of bad data, and stall. Then, when peers with legitimate data filled in the rest of the piece, they would all get marked with a hashfail.

At first, I kept reseting bans. Eventually it became obvious that the people with 25-30 hash fails were the 'good guys' and the bunch of connections with 1 hash fail each all from the same ip range were the poisoners. Looking at incoming incomplete piece data, I had 20 pieces 20-60% complete waiting to fail more legitimate peers.

After I realized what was happening, I started up peer guardian 2 and it saved the swarm for me.

It should also be noted that mp3 torrents experience a lot of accidental poisoning. A lot of people either use players that add to or change the ID3 tags automatically, or they change them themselves without thinking. If those people continue to seed data, they'll be poisoning without realizing it.

Link to comment
Share on other sites

Huh? This is different from what I am describing as an attack.

I only have 25 hash fails (12.50 Mb) and it's not growing, despite over 50 of the bad guy IPs connected in. What were the poisoner IP addresses on yours?

I'm pretty sure the bad guy IPs are not sending or receiving data, despite both of us doing occansional REQUEST PIECE and HAVE PIECE.

Link to comment
Share on other sites

What you're describing isn't a poisoned swarm then. A poisoned swarm is one where you constantly get hashfails. As Xu said, you're describing a swarm where peers are abusing the protocol, but that's not poisoning -- it's more along the lines of cheating.

Link to comment
Share on other sites

Not possible, as PEX compatibility depends on the clients being used -- Azureus PEX isn't compatible with µTorrent PEX isn't compatible with BitComet PEX (the three major PEX implementations). In any case, just spamming the peer exchange lists isn't really poisoning either, it's just spamming it.

Link to comment
Share on other sites

I think you're misunderstanding terminology here... Peer exchange is a method of exchanging peer lists with other peers that are compatible with your client's PEX implementation. PEX itself doesn't have a standard, which is why there are three different major implementations.

It still sounds more like you're only referring to a simple abuse of the protocol more than anything :|

Link to comment
Share on other sites

The poisoning may be in different phases depending on the state of the torrent.

Initially, it probably tries to drain the 1 seed dry by downloading quickly to tie up its upload bandwidth.

Then it tries to upload garbage to the joining peers to trick them into blocking each other due to hash fails.

Lastly, it just monitors the torrent and starts uploading junk again if the torrent's availability approaches or tops 1.

This all suggests the poisoner's bandwidth capacity isn't as massive as I had once feared.

Link to comment
Share on other sites

I've downloaded the uTorrent 1.7 Beta, am running the poisoned torrent and logging to a file.

1) What does "Sending 9 bytes of aggregated data" mean?

2) What data is being passed?

3) What does "Got Have 527" and "Got Bad Have 520" mean?

4) What is the generalization for "IP...sending/receiving?"

5) Who is sending or receiving, me or them?

6) What does "IP...Disconnect: Too many local connections" mean?

7) How do I interpret the Peers "Reqs" and "Debug" columns?

8) What is the best way to turn on the most detailed logfile?


Ultima: Numbering added to list...

Link to comment
Share on other sites

1) Standard peer communication.

2) See 1.

3) How many pieces the peer has

4) Not sure what you mean.

5) You are sending and receiving (as are the other peers), but the logger tab refers to you.

6) You've reached your connection limit for the torrent, or globally.

7) Check the manual.

8) First three options in the logger tab's context menu...

Link to comment
Share on other sites

  • 2 weeks later...


This topic is now archived and is closed to further replies.

  • Create New...