Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

Spotting Cleanfeed/TalkTalk broke Rapidshare

Name: Anonymous 2008-07-21 17:00

TalkTalk (really crappy British ISP I'm on) have broken Rapidshare, and I doubt it's the only one. They're feeding it - but not other web traffic - through a transparent proxy, so everyone shares the same IP address and someone else will always be trying to download something. (How do you tell? It tells you that someone from the same IP is downloading something, the IP isn't yours, and whatismyip.com gives your real IP.) Plus, even if you do get through, the download server isn't proxied, so the IPs won't match and it won't let you download.

Why? Cleanfeed - the same content filter that blocked /b/, and which all UK ISPs are supposed to have now. The way it works is by sending all traffic to the server hosting the blocked content via a transparent proxy, and I'm going to show you how to spot it in action.

First, get nmap from http://nmap.org/download.html and install it. It's a really powerful network probing tool, and we'll need it later. Also, make sure you have a decent version of either traceroute, tracepath or tracert installed. (If you're using Windows, you should have this already).

Now, run "nmap --traceroute -p 80 megaupload.com" (as admin/root). You'll get something like:

TRACEROUTE (using port 80/tcp)
HOP RTT    ADDRESS
[ ... snip ... ]
5   39.73  gig-9-1-rtr001.hex.opaltelecom.net (62.24.254.10)
6   37.61  gig-10-1-rtr001.man.opaltelecom.net (62.24.254.50)
7   36.31  gig-2-1-498.rtr020.man.opaltelecom.net (62.24.251.235)
8   123.30 mega038.carpathiahost.net (209.222.148.135)

What you'd normally get is the traffic passing through your ISP's network, across a few intermediate systems, and through the destination network. opaltelecom.net is TalkTalk, so the request is being answered from within their network. (There can be valid reasons for this, like if it's one of their sites or a CDN like Akamai, but they should be obvious). Now let's use "tracepath 209.222.148.135" to find the path the traffic should be taking:

[ ... cut for privacy ... ]
 5:  gig-9-1-rtr001.hex.opaltelecom.net (62.24.254.10)     63.474ms asymm  8
 6:  gig-10-1-rtr001.man.opaltelecom.net (62.24.254.50)    64.322ms
 7:  gig-2-1-498.rtr020.man.opaltelecom.net (62.24.251.235)  63.444ms
 8:  62.24.251.41 (62.24.251.41)                           63.412ms
 9:  gig-14-1-rtr001.thn.as13285.net (62.24.254.81)        72.232ms asymm 10
10:  xe-11-2-0-scr001.thn.as13285.net (78.144.1.4)         71.208ms asymm 12
11:  host-78-144-0-119.as13285.net (78.144.0.119)          71.210ms asymm 13
12:  cr02.ldn01.pccwbtn.net (195.66.224.167)               73.080ms asymm 14
13:  carpathia.ge12-1.br02.ash01.pccwbtn.net (63.218.94.166) 150.612ms asymm 16
14:  mega038.carpathiahost.net (209.222.148.135)          153.695ms reached
     Resume: pmtu 1432 hops 14 back 46

Notice the much longer path that actually leaves the TalkTalk network and passes through intermediate routers. So some server within TalkTalk, and not the proper destination, was replying to the previous requests. Some cheap providers do this sort of transparent proxying with all sites, but that's easy enough to spot by doing the same test on other sites. TalkTalk is just doing this for selected sites, and Cleanfeed is the only reason I can think of.

Name: Anonymous 2008-07-25 1:49

ISP automates local caching of high-traffic websites without considering cancerous systems like Rapidshare's, and skiddies don't know how networking works -- news at 11.

Name: Anonymous 2008-07-28 6:47

>>2

Name: Anonymous 2008-08-10 14:49

>>2
The thing is, the download servers - which are the actual high-bandwidth parts of Rapidshare - aren't going through the cache, just the low-bandwidth web frontend that's probably mostly non-cacheable stuff anyway. Plus I know that people upload CP to sites like Rapidshare.

(Besides, you'd have to be insane to do automatic selective caching - it'd risk breaking anything that used multiple servers and tied sessions to IPs. You'd have to be doubly-insane to do the proxying via an IP address that appears to be a normal broadband IP, which is what it seemed to be when I did a reverse lookup.)

Name: Anonymous 2008-08-15 17:17

Name: Anonymous 2008-12-09 10:09

Thought the situation with Rapidshare and Megaupload was bad? Now it's WIKIPEDIA.

Someone needs to blow that whole organisation (or at least their online presence) out of existance.

Name: Anonymous 2008-12-09 11:06

NEVER FORGET THE HEROES THAT GAVE THEIR TIME AND THEIR LIVES TO DIE FOR THE GREATER CAUSE OF MAKING THE PLEASURE OF BEING CUMMED INSIDE A GOOGLE MEME. YOUR SACRIFICE WILL NOT BE FORGOTTEN.

NVR FGT

Don't change these.
Name: Email:
Entire Thread Thread List