Busted: BitTorrent Pirates at Sony, Universal and Fox(torrentfreak.com)
torrentfreak.com
Busted: BitTorrent Pirates at Sony, Universal and Fox
http://torrentfreak.com/busted-bittorrent-pirates-at-sony-universal-and-fox-111213/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Torrentfreak+%28Torrentfreak%29
6 comments
It's not exactly a knockdown argument by itself, but it just adds a little more to the pool of thought saying an IP address doesn't correspond to an individual. That viewpoint seems to be gaining more and more momentum, e.g. somewhat recently: http://torrentfreak.com/ip-address-not-a-person-bittorrent-c...
If you do layer 4 network address translation (NAT) - then a single IPv4 address can theoretically be used by circa 64000 people at the same time; depending on how multiplexing is done, by maybe even more.
The large-scale translators on the headends are the reality for quite a few service providers already.
So, the "IP address does not correspond to an individual" is not just a mere viewpoint gaining momentum, but an emerging hard technical fact. ;-)
The large-scale translators on the headends are the reality for quite a few service providers already.
So, the "IP address does not correspond to an individual" is not just a mere viewpoint gaining momentum, but an emerging hard technical fact. ;-)
Tinfoil hat Just wait, once the US government at large finally understands IPv4 networking, someone with too much power will look at IPv6 and the phrase "Look we don't have to do NAT anymore!" Then the government will assign a unique IPv6 address or two to every citizen to use as ID (they'll need a replacement anyway once they get rid of social security). Then they mandate the ISPs to track IPs, and they make it illegal to share or mask IP/IDs since that's something only pirates and thieves and other bad people do anyway. And we'll look back and say "Remember The Right to Read? rms was right again!"
If governments were to do that, they would also be forced to solve the problem of the routing table explosion. Which is a hard problem.
As for unique ID - it's already doable and being done without any IPv6. Read up on evercookie. There was an article on HN a while ago about a bunch of advertisers doing just that.
This is worse than the government having it - not only it gets abused, but someone gets rich on this.
As for unique ID - it's already doable and being done without any IPv6. Read up on evercookie. There was an article on HN a while ago about a bunch of advertisers doing just that.
This is worse than the government having it - not only it gets abused, but someone gets rich on this.
Unique internet IDs are far from a conspiracy theory. They're being actively developed in China and South Korea to name a few. While the South Korean one has faced setbacks it's only a matter of time before they become common place in other countries in my opinion.
There are 16 million IPs in 10.x.x.x.
But there are at most 2^16 TCP ports available on the other side. I think this doesn't theoretically prevent one from reusing an exterior port multiple times for multiple connections to different other IP addresses or ports, but that would be both rather tricky and inconsistent with some cultural expectations regarding the use of initiating ("client") ports, and so I doubt any current NAT stack in common use uses that approach (though I'd love to be proven wrong). It also fails naturally if all sixteen million hosts try to communicate with the same host/port on the other side. UDP has similar but nonidentical constraints.
> (though I'd love to be proven wrong)
one-up-manship sucks, but correct information is beneficial. ;)
The problem with the term "NAT" as "Network Address Translation" is the term is often misused/incorrect; most all modern "NAT" implementations are actually "PNAT" ("Port and Network Address Translation") where the translator system modifies both the source address and source port rather than just modifying the source address.
For notes, the earliest translation implementations really were just address modification, and hence, really were plain "NAT," but the problem of conflicting port numbers is the reason why just about every implementation moved to PNAT.
When running a PNAT implementation, you can exhaust the number of available TCP ports with enough load from client systems. The number of available TCP ports is typically, but incorrectly, stated as 2^16 ports, but in practice, you can't use all of them.
Getting around the TCP port count limitation is entirely possible, and regularly done in large scale networks. The early implementations were standard "proxy systems/servers" (typically requiring client-side configuration like, address, port, user/pass, etc.). More modern implementations are "transparent proxies" and require no client-side configuration. Transparent proxy implementations (typically) count on PNAT in order to be "transparent" to the client systems and prevent the need for client-side configuration.
The mental leap one needs to make in order to understand how to get past the TCP port count limitation is, understanding that a single public IP address can be shared by multiple systems simultaneously without NAT/PNAT or proxies. There are many ways to do it from "load balancing appliances," to CARP (Common Address Resolution Protocol - free in OpenBSD), to VRRP (Virtual Router Redundancy Protocol - patented by Cisco), to other methods. This is often combined with multiple stateful firewalls where all of the firewalls share their state tables.
Similarly, pools of public IP addresses can also be shared amongst multiple systems simultaneously. Let's say your shared state table already has an entry with your source of "aaa.bbb.ccc.ddd port 1331", with a pool of address, you now have your choice of changing either the port number or the source address. --This isn't particularly precise, but it is a good way to reason through it.
AOL used to (and maybe still does?) run some humongous transparent proxies. If you search around, you'll find some (historic?) complaints from sites about not being able to block trolls or malicious traffic from jerks on AOL without blocking everyone on AOL. The only IP the site owners got was the from the small block dedicated to the AOL transparent proxies. I think this issue may have been resolved by the "proxy-for" header being added eventually (i.e. often called a "non-anonymous proxy"), but my recollection is a bit fuzzy.
The point to take away from this is, AOL, at its height, was able to stuff all of it's millions of users behind a couple dozen proxies/IP's, so the number of TCP ports is only a limitation in theory, but it's not a limitation in practice.
Yogi Beara once said, "In theory, practice and theory are the same, but in practice, they're not."
one-up-manship sucks, but correct information is beneficial. ;)
The problem with the term "NAT" as "Network Address Translation" is the term is often misused/incorrect; most all modern "NAT" implementations are actually "PNAT" ("Port and Network Address Translation") where the translator system modifies both the source address and source port rather than just modifying the source address.
For notes, the earliest translation implementations really were just address modification, and hence, really were plain "NAT," but the problem of conflicting port numbers is the reason why just about every implementation moved to PNAT.
When running a PNAT implementation, you can exhaust the number of available TCP ports with enough load from client systems. The number of available TCP ports is typically, but incorrectly, stated as 2^16 ports, but in practice, you can't use all of them.
Getting around the TCP port count limitation is entirely possible, and regularly done in large scale networks. The early implementations were standard "proxy systems/servers" (typically requiring client-side configuration like, address, port, user/pass, etc.). More modern implementations are "transparent proxies" and require no client-side configuration. Transparent proxy implementations (typically) count on PNAT in order to be "transparent" to the client systems and prevent the need for client-side configuration.
The mental leap one needs to make in order to understand how to get past the TCP port count limitation is, understanding that a single public IP address can be shared by multiple systems simultaneously without NAT/PNAT or proxies. There are many ways to do it from "load balancing appliances," to CARP (Common Address Resolution Protocol - free in OpenBSD), to VRRP (Virtual Router Redundancy Protocol - patented by Cisco), to other methods. This is often combined with multiple stateful firewalls where all of the firewalls share their state tables.
Similarly, pools of public IP addresses can also be shared amongst multiple systems simultaneously. Let's say your shared state table already has an entry with your source of "aaa.bbb.ccc.ddd port 1331", with a pool of address, you now have your choice of changing either the port number or the source address. --This isn't particularly precise, but it is a good way to reason through it.
AOL used to (and maybe still does?) run some humongous transparent proxies. If you search around, you'll find some (historic?) complaints from sites about not being able to block trolls or malicious traffic from jerks on AOL without blocking everyone on AOL. The only IP the site owners got was the from the small block dedicated to the AOL transparent proxies. I think this issue may have been resolved by the "proxy-for" header being added eventually (i.e. often called a "non-anonymous proxy"), but my recollection is a bit fuzzy.
The point to take away from this is, AOL, at its height, was able to stuff all of it's millions of users behind a couple dozen proxies/IP's, so the number of TCP ports is only a limitation in theory, but it's not a limitation in practice.
Yogi Beara once said, "In theory, practice and theory are the same, but in practice, they're not."
The number of available TCP ports is typically, but incorrectly, stated as 2^16 ports, but in practice, you can't use all of them.
That's mainly why I wrote “at most” instead of trying to compute the exact available number, yes.
You don't even theoretically need application-layer gateways to multiply the effective number of ports by a large factor for common loads, of course, as I mentioned; I just erroneously thought such technique was not in common use, per my reply to eggnet.
That's mainly why I wrote “at most” instead of trying to compute the exact available number, yes.
You don't even theoretically need application-layer gateways to multiply the effective number of ports by a large factor for common loads, of course, as I mentioned; I just erroneously thought such technique was not in common use, per my reply to eggnet.
This is very practical and RFC3489 (http://www.ietf.org/rfc/rfc3489.txt) has a definition for this - "Port Restricted Cone NAT".
For the reference to some of the port restricted NATs, take a look at http://tools.ietf.org/html/draft-jennings-behave-test-result...
As for cultural expectation, yes, the port-restricted cone NATs are a pain.;-)
For the reference to some of the port restricted NATs, take a look at http://tools.ietf.org/html/draft-jennings-behave-test-result...
As for cultural expectation, yes, the port-restricted cone NATs are a pain.;-)
Only this tuple needs to be unique:
(source ip, source port, dest ip, dest port, protocol)
For protocols that don't have ports, then it is this tuple:
(source ip, dest ip, protocol)
that needs to be unique.
Openbsd's pf works that way, I'd be utterly shocked if any other linux or bsd kernel-integrated nat system worked any differently.
(source ip, source port, dest ip, dest port, protocol)
For protocols that don't have ports, then it is this tuple:
(source ip, dest ip, protocol)
that needs to be unique.
Openbsd's pf works that way, I'd be utterly shocked if any other linux or bsd kernel-integrated nat system worked any differently.
I was originally thinking this would break things like IDENT, but then I remembered that they use the entire tuple (d'oh). I'll take your word for the pf behavior, and retract my bogus guess about kernel NAT. :-)
Oh, good point, I didn't really think of "at the same time" as actually meaning simultaneous connections to the same dest.
Only 16 bits worth of ports, though.
I thought that BitTorrent used TCP? If so, spoofing a connection requires being in a position where you can intercept the return packet in order to be able to complete the TCP handshake. Possible, but requires a spoofer to be very well connected.
You don't need to spoof a TCP connection to register a spoofed IP address on a tracker. The tracker GET request has an optional `ip` field, the contents of which is registered as the client's address, regardless of the source address of the actual request. So it's trivial to write a Bittorrent client that reports a false address to the tracker.
http://bittorrent.org/beps/bep_0003.html
http://bittorrent.org/beps/bep_0003.html
So does this optional parameter fully override the peer's address in the reporting ?
Probably. When the tracker responds with a list of peers, each peer only has an id, an ip & a port; there's no real_ip or reported_ip parameters. Of course there could be tracker software in the wild that ignores the ip parameter entirely; it's just a spec, not a contract.
Thanks for the clarification. This makes it entirely possible to spoof someone's address then by a third party.
Wow, that's very interesting. Thanks!
I don't think they mean spoof in such a technical way. I think they just mean it as "the You Have Downloaded website could be just generating files to go with IPs", and similarly "any torrent logs may have been spoofed/made up."
Obviously the next step for the You Have Downloaded site is to track in real-time and say "This IP is currently downloading x,y,z."
Obviously the next step for the You Have Downloaded site is to track in real-time and say "This IP is currently downloading x,y,z."
It depends on the TCP stacks on each side; some crappy TCP stacks let you forge connections rather easily. I don't think Bittorrent works over UDP, but if it does, that's very easy to forge in theory (assuming your ISP doesn't do egress filtering).
The best excuse is probably, "I installed some malware and I guess it turned my box into a torrent gateway".
The best excuse is probably, "I installed some malware and I guess it turned my box into a torrent gateway".
Spoofing IP addresses is wildly more difficult than this, and implausible in the BitTorrent scenario.
* There are no mainstream TCP stacks that have the vulnerability you're alluding to (poorly randomized sequence numbers).
* Even during the Mitnick/Shimomura days, the attack only got you the transmit side, not the receive side; it was sufficient to push an RSH command, but not to dump a file.
* There are network-level controls that make this attack more difficult; for instance, ISPs increasingly do reverse path filtering to ensure they're only egressing traffic from their own ISP space (we'd watch this happen while monitoring DDoS attacks at Arbor, seeing "randomized" source addresses constrained to prefixes from specific ASNs).
There is still IP spoofing, but it's got dollar signs attached to it, significant enough to merit BGP tampering.
When laypersons claim to be victims of spoofing, they are overwhelmingly likely to be full of it.
I couldn't possibly be less interested in the politics of Bittorrent and labels ("Movie theater employees caught sneaking into shows without tickets --- FILM AT 11") and admit to reading this thread only out of masochism, but my nerd brain can't get past 'jrockway talking about IP spoofing; if it was anyone else, sure, but 'jrockway should know what he's talking about here. :)
* There are no mainstream TCP stacks that have the vulnerability you're alluding to (poorly randomized sequence numbers).
* Even during the Mitnick/Shimomura days, the attack only got you the transmit side, not the receive side; it was sufficient to push an RSH command, but not to dump a file.
* There are network-level controls that make this attack more difficult; for instance, ISPs increasingly do reverse path filtering to ensure they're only egressing traffic from their own ISP space (we'd watch this happen while monitoring DDoS attacks at Arbor, seeing "randomized" source addresses constrained to prefixes from specific ASNs).
There is still IP spoofing, but it's got dollar signs attached to it, significant enough to merit BGP tampering.
When laypersons claim to be victims of spoofing, they are overwhelmingly likely to be full of it.
I couldn't possibly be less interested in the politics of Bittorrent and labels ("Movie theater employees caught sneaking into shows without tickets --- FILM AT 11") and admit to reading this thread only out of masochism, but my nerd brain can't get past 'jrockway talking about IP spoofing; if it was anyone else, sure, but 'jrockway should know what he's talking about here. :)
> When laypersons claim to be victims of spoofing, they are overwhelmingly likely to be full of it. </quote>
What prevents a tracker to mix up some random IP. How do you know that it is not correct unless your torrent client tries to connect to it?
What prevents a tracker to mix up some random IP. How do you know that it is not correct unless your torrent client tries to connect to it?
Usually for any torrent case just being on the tracker is not enough for conviction, they have to record the user sending copyrighted data to the investigator.
In many cases the term "spoofed" is probably used loosely to mean "they stole our wifi". I understand that that's not what the press release claimed, but such excuses still benefit filesharers because all of the industry's lawsuits heretofore have been based on matching IP address to registered ISP user and holding that user accountable for the activity that occurred on their network. Making this excuse, then, only seems to serve the little people that are next on their "to sue" list.
The best excuse is probably, "I installed some malware and I guess it turned my box into a torrent gateway".
Unless the law says that you are responsible for everything that happens on your internet connection. I don't know if or where this is the case, but it seems realistic and even reasonable.
Unless the law says that you are responsible for everything that happens on your internet connection. I don't know if or where this is the case, but it seems realistic and even reasonable.
Which would be easy to dump off on the provider. "I have a firewall and anti-virus, what more can I be responsible for if my provider isn't securing THEIR network?"
Ignorance of the law isn't a plausible defense in the eyes of the law, but you when you have so many parties besides yourself involved, I would think it would be easier to claim it was something on their end.
Ignorance of the law isn't a plausible defense in the eyes of the law, but you when you have so many parties besides yourself involved, I would think it would be easier to claim it was something on their end.
It is the case in France. You could see it the same way as a car insurance, you're responsible for any damage it does, except your car can be safely locked in your garage when someone else wrecks it into a porcelain store, and you can't possibly prevent it from happening nor prove that it wasn't yours.
In the US, you aren't responsible for crimes you didn't commit. That means if someone uses your computer to commit a crime, and you didn't intend to help them, you didn't do anything wrong.
Doesn't that not allow for "strict liability" rules?
attractive nuisance.
Some versions of BitTorrent use uTP, which is a delay based congestion control algorithm implemented on top of UDP. It is extremely TCP friendly and in fact succumbs to ongoing long TCP flows, which tend to fill up buffers at your access point.
I might have worked at one of the mentioned companies and employees were running their own servers with torrents in company's racks. Not to mention that couple of the boxes were parts of botnets and spam farms.
As someone inside the music industry, this comes as no surprise. The spotlight of the attempts of anti-piracy actions on the part of the big four and rights groups overshadows the actions of the individuals working at these companies and the others in the industry. Not everyone in these companies agrees with what the rights groups and major labels/studios are doing, or see it as case of "it's okay for as long as it's not ours".
The first rule of leadership is to be willing to do what you ask of others.
The stink of hypocrisy is to ask others to do what you are unwilling to do yourself.
I am sure all of the companies involved have a "no piracy" company policy on their books with severe penalties (probably reprimands leading to dismissal on repeated offenses). If they are unwilling to enforce their own policies on their own employees, they are being hypocrites, not leaders.
The stink of hypocrisy is to ask others to do what you are unwilling to do yourself.
I am sure all of the companies involved have a "no piracy" company policy on their books with severe penalties (probably reprimands leading to dismissal on repeated offenses). If they are unwilling to enforce their own policies on their own employees, they are being hypocrites, not leaders.
You're probably right. And you may find those who are breaking these rules are the ones entrusted (sysadmins) to uphold and enforce these rules.
When someone at Sony, Universal and Fox use bittorrent, why is that not legal distribution? Especially when they hire someone to spy on bittorrent users, because in that case their distribution is clearly authorized. Maybe the blocklists used by torrent clients should be inverted?
It's about intent. If you didn't know that Sony was distributing this film, you cannot claim you were downloading a film from Sony directly. You'd have to prove you knew that before downloading it, which you generally cannot do. I don't know of any tracker that will tell you what IPs are currently connected (though it might be possible).
Even then, while downloading you're generally uploading as well, so you could still be charged with distribution.
Even then, while downloading you're generally uploading as well, so you could still be charged with distribution.
> I don't know of any tracker that will tell you what IPs are currently connected
Maybe I don't fully understand your comment but every tracker will tell you what IPs are currently connected. That is what trackers do, that is the very feature that make them trackers.
Maybe I don't fully understand your comment but every tracker will tell you what IPs are currently connected. That is what trackers do, that is the very feature that make them trackers.
Sorry, my brain made the connection from the previous sentence between "before you begin to download" to "telling you the IPs". I should have added that to the sentence that confused you as well, I haven't seen any that tell you the IPs that are currently connected before you begin to download. So you have to initiate the download before you can find out who is connected.
They (more precisely, individuals within the corporation) are not downloading their own material but other company's copyright material.
I've always felt that when two torrent clients start talking, they should require each other to say something to the effect: "I am an agent of the copyright holder of this material, and I hereby authorize you to use and distribute this material freely" before sending any data. Try to sue someone in court when you have your investigator on record telling them they can use and distribute your works.
Won't work for FLOSS/CC licensed material, or public domain works. The distributor is not an agent for the copyright holder; she either has a license which allows redistribution, or does not need one to legally redistribute.
So, your disclaimer is reduced to "I am legally allowed to redistribute this media". Which is pointless. It's inherently implied by the fact that you are redistributing the work. Unless you are breaking the law - in which case, why would lying about it bother you?
Oh, yes, I am totally authorised to redistribute this media. And these genuine Rolex watches I am selling for $20 fell off the back of a truck. They are definitely not fakes infringing on trademarks, nor are they actual genuine articles which are stolen and being fenced, no siree!
So, your disclaimer is reduced to "I am legally allowed to redistribute this media". Which is pointless. It's inherently implied by the fact that you are redistributing the work. Unless you are breaking the law - in which case, why would lying about it bother you?
Oh, yes, I am totally authorised to redistribute this media. And these genuine Rolex watches I am selling for $20 fell off the back of a truck. They are definitely not fakes infringing on trademarks, nor are they actual genuine articles which are stolen and being fenced, no siree!
So the other 99% of torrents would still be infringing.
I thought it was interesting everybody thought the site was s joke. Now we have a highly trafficked site using it as a means to convict the companies who are going after the pirates.
There were plenty of people coming from the IPs of music labels on Napster back in the day so it doesn't surprise me that they continue to use P2P services. IIRC, it was on the order of tens of thousands though that included parent companies and subsidiaries.
Our lawyers told us it wasn't useful (and might have been harmful) to our case so we never did anything with the information.
Our lawyers told us it wasn't useful (and might have been harmful) to our case so we never did anything with the information.
>In a response [another copyright advocate caught 'stealing'] issued a press release stating that their IP-addresses were spoofed. A very unlikely scenario, but one that will be welcomed by BitTorrent pirates worldwide. In fact, we encourage Sony, Universal and Fox to say something similar. After all, if it’s so easy to spoof an IP-address, then accused file-sharers can use this same defense against copyright holders.
Could such a defense be expected to work ? Has it ever ?