For the 43rd UAE national day last week, His Highness Hamdan bin Mohammed Al Maktoum, Crown Prince of Dubai (the second son of Dubai’s monarch), installed an open-air, 2.2 km long continuous graffiti wall created by more than 100 artists, shaped in the form of a map of the UAE:
Here’s a sample of the better ones:
The internet is censored in the UAE. Not really bad like in China – it’s rather used to restrict access to “immoral content”. Because you know, the internet is full of porn and Danish people making fun of The Prophet. – Also, downloading Skype is forbidden (but using it is not).
I have investigated the censorship mechanism of one of the two big providers and will describe the techniques in use and how to effectively circumvent the block.
If you navigate to a “forbidden page” in the UAE, you’ll be presented with a screen warning you that it is illegal under the Internet Access Management Regulatory Policy to view that page.
This is actually implemented in a pretty rudimentary, yet effective
way (if you have no clue how TCP/IP works). If a request to a
forbidden resource is made, the connection is immediately shut down by
the proxy. In the shutdown packet, an <iframe>
code is placed that
displays the image:
<iframe src="http://94.201.7.202:8080/webadmin/deny/index.php?dpid=20&
dpruleid=7&cat=105&ttl=0&groupname=Du_Public_IP_Address&policyname=default&
username=94.XX.0.0&userip=94.XX.XX.XX&connectionip=1.0.0.127&
nsphostname=YYYYYYYYYY.du.ae&protocol=nsef&dplanguage=-&url=http%3a%2f%2f
pastehtml%2ecom%2fview%2fc336prjrl%2ertxt"
width="100%" height="100%" frameborder=0></iframe>
Capturing the TCP packets while making a forbidden request – in this case: a
list of banned URLs in the UAE, which itself is banned – reveals one crucial
thing: The GET
request actually reaches the web server, but before the answer
arrives, the proxy has already sent the Reset-Connection-Packets. (Naturally,
that is much faster, because it is physically closer.)
Because the client thinks the connection is closed, it will itself send out Reset-Packets to the Webserver in reply to its packets containing the reply (“the webpage”). This actually shuts down the connection in both directions. All of this happens on the TCP level, thus by “client” I mean the operating system. The client application just opens a TCP socket and sees it closed via the result code coming from the OS.
You can see the initial reset-packets from the proxy as entries 5 und 6 in the list; the later RST packets originate from my computer because the TCP stack considers the connection closed.
First, we need to find out at which point our HTTP connection is being hijacked. To do this, we search for the characteristic TCP packet with the FIN, PSH, ACK bits set, while making a request that is blocked. The output will be something like:
$ sudo tcpdump -v "tcp[13] = 0x019"
18:38:35.368715 IP (tos 0x0, ttl 57, ... proto TCP (6), length 522)
host-88-80-29-58.cust.prq.se.http > 192.168.40.73.37630: Flags [FP.], ...
We are only interested in the TTL of the FIN-PSH-ACK packets: By substracting this from the default TTL of 64 (which the provider seems to be using), we get the number of hops the host is away. Looking at a traceroute we see that obviously, the host that is 64 - 57 = 7 hops away is located at the local ISP. (Never mind the un-routable 10.* appearing in the traceroute. Seeing this was the initial reason for me to think these guys are not too proficient in network technology, no offense.)
$ mtr --report --report-wide --report-cycles=1 pastehtml.com
HOST: mjanja Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.40.1 0.0% 1 2.9 2.9 2.9 2.9 0.0
2.|-- 94.XX.XX.XX 0.0% 1 2.9 2.9 2.9 2.9 0.0
3.|-- 10.XXX.0.XX 0.0% 1 2.9 2.9 2.9 2.9 0.0
4.|-- 10.XXX.0.XX 0.0% 1 2.9 2.9 2.9 2.9 0.0
5.|-- 10.100.35.78 0.0% 1 6.8 6.8 6.8 6.8 0.0
6.|-- 94.201.0.2 0.0% 1 7.7 7.7 7.7 7.7 0.0
7.|-- 94.201.0.25 0.0% 1 8.4 8.4 8.4 8.4 0.0
8.|-- 195.229.27.85 0.0% 1 11.1 11.1 11.1 11.1 0.0
9.|-- csk012.emirates.net.ae 0.0% 1 27.3 27.3 27.3 27.3 0.0
10.|-- 195.229.3.215 0.0% 1 146.6 146.6 146.6 146.6 0.0
11.|-- decix-ge-2-7.i2b.se 0.0% 1 156.2 156.2 156.2 156.2 0.0
12.|-- sth-cty1-crdn-1-po1.i2b.se 0.0% 1 164.7 164.7 164.7 164.7 0.0
13.|-- 178.16.212.57 0.0% 1 151.6 151.6 151.6 151.6 0.0
14.|-- cust-prq-nt.i2b.se 0.0% 1 157.5 157.5 157.5 157.5 0.0
15.|-- tunnel3.prq.se 0.0% 1 161.5 161.5 161.5 161.5 0.0
16.|-- host-88-80-29-58.cust.prq.se 0.0% 1 192.5 192.5 192.5 192.5 0.0
We now know that with a very high probability, all “connection termination” attempts from this close to us – relative to a TTL of 64, which is set by the sender – are the censorship proxy doing its work. So we simply ignore all packets with the RST or FIN flag set that come from port 80 too close to us:
for mask in FIN,PSH,ACK RST,ACK; do
sudo iptables -I INPUT -p tcp --sport 80 \
-m tcp --tcp-flags $mask $mask \
-m ttl --ttl-gt 55 -m ttl --ttl-lt 64 \
-j DROP;
done
NB: This checks for the TTL greater than, so we have to check for greater 56 and substract one to be one the safe side. You can also leave out the TTL part, but then “regular” TCP terminations remain unseen by the OS, which many programs will find weird (and sometimes data comes with a package that closes the connection, and this data would be lost).
That’s it. Since the first reply packet from the server is
dropped, or rather replaced with the packet containing the <iframe>
code, we rely on TCP retransmission, and sure enough, some 0.21 seconds
later the same TCP packet is retransmitted, this time not harmed in
any way:
The OS re-orders the packets and is able to assemble the TCP stream. Thus, by simply ignoring two packets the provider sends to us, we have an (almost perfectly) working TCP connection to where-ever we want.
I suppose the provider is using relatively old Cisco equipment. For example, some of their documentation hints at how the filtering is implemented. See this PDF, p. 39-5:
When filtering is enabled and a request for content is directed through the security appliance, the request is sent to the content server and to the filtering server at the same time. If the filtering server allows the connection, the security appliance forwards the response from the content server to the originating client. If the filtering server denies the connection, the security appliance drops the response and sends a message or return code indicating that the connection was not successful.
The other big provider in the UAE uses a different filtering technique, which does not rely on TCP hacks but employs a real HTTP proxy. (I heard someone mention “Bluecoat” but have no data to back it up.)
Ich bin wieder in Berlin. Ich habe es keinesfalls bereut nach Dubai zu gehen, aber am Ende der Zeit wurde es mir doch ein bisschen langweilig. Ist nicht wirklich meine Stadt, auch wenn der Strand und das Essen vorzüglich sind.
Hier noch ein paar Bilder. Die Metro-Stationen sehen ziemlich futuristisch aus, und werden nonstop von innen gereinigt.
Das Burj Khalifa aus der Ferne…
… und der Blick vom 124. Stock runter:
Und in der Wüste war ich natürlich auch:
Ich bin nun seit einer Woche in Dubai. Als letzter Teil meines langen Weges zu einem Bachelor-Abschluss muss ich ein Betriebspraktikum machen, das mindestens sechs Wochen dauert. Laut Regulation darf das nicht an meiner Heimatuniversität sein, und auf Nachfrage wurde mir gesagt, dass man eine potentielle Berufslaufbahn erkunden soll, und deswegen freiberufliche Tätigkeiten nicht anerkannt werden (?!). – Also habe ich mich bemüht, das Angenehme mit dem Nützlichen zu verbinden und bin nun in Dubai, um ein Praktikum bei einer Firma abzuleisten, die Netzwerkdienstleistungen für Fluggesellschaften anbietet.
Ganz anders als die anderen Großstädte, in denen ich in den vergangenen Jahren so war, ist Dubai erwartungsgemäß luxuriös und hoch technisiert. Hier scheint alles neu zu sein: Die Metro wurde erst vor zwei Jahren eröffnet, die knapp 80 Jumeirah Lake Towers, die das Viertel ausmachen, in dem ich arbeite, wurden in einem Kraftakt innerhalb von wenigen Jahren gebaut – schön mit künstlichen Seen und einer Metro-Station direkt vor der Tür. (Siehe auch auf Google Maps.)
Ich wohne glücklicherweise direkt an der Metro-Station Business Bay, direkt an der Sheikh Zayed Road, einer in beiden Richtungen sechsspurig verlaufenden Stadtautobahn. Die Straße überquert man bei den Metro-Stationen über (natürlich klimatisierte) und mit Laufbändern wie in Flughäfen ausgestattete Fußgängerbrücken. In meinem Stadtteil sieht man von fast überall das Burj Khalifa, das (momentan noch) höchste Gebäude der Welt.
Dubai ist leider gar nicht so warm, wie ich mir das vorgestellt habe, wobei jetzt wohlgemerkt auch hier noch Winter ist. Tagsüber ist es ganz nett, aber da muss ich ja arbeiten. Ansonsten ist hier alles klimatisiert: Nicht nur alle Wohnhäuser, Büros, die U-Bahnen: Nein, auch die U-Bahn-Stationen und sogar die Bushaltestellen!
Da ich zu Hause weder einen Stuhl noch einen Tisch besitzte, verbringe ich die Abende meist in irgendwelchen Cafés, gestern mit einem meiner Kollegen in Dubai Marina, einem Viertel, das genau wie JLT fast nur aus Wolkenkratzern besteht. Die künstlichen Seen zwischen den Häusern sind dort aber viel tiefer und auch mit Booten vom Meer aus zu erreichen.
Insgesamt ist die Stadt großteils extrem Fußgänger-unfreundlich und zentralisiert. Anstatt ziellos durch die Gegend zu laufen und zufällig ein nettes Restaurant oder Cafe zu finden, fährt man häufig in die nächste Mall, wo dann dutzende oder sogar hunderte Gelegenheiten sind, etwas zu essen. Die Malls sind hier so riesig, dass es Computerterminals gibt, mit Hilfe derer man sich zurecht finden kann und die Auswahl der Läden erkunden kann. Ich hasse Shopping, aber ich werde mich für die Zeit wohl damit abfinden müssen, dass das hier eines der größten Dinge ist.
Dass das Internet hier zensiert wird, ärgert mich. Ich habe mittlerweile herausgefunden, wie man die Maßnahmen umgehen kann, ohne ein VPN zu benutzen; mit der Veröffentlichung der technischen Details warte ich aber sicherheitshalber, bis ich wieder außer Landes bin…