I'm surprised a flood that regularly takes an AWS load balancer offline isn't showing more link congestion...<p>get /:<p><pre><code> tsl@crabapple:~> time curl http://wikileaks.org/ > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5837 100 5837 0 0 20684 0 --:--:-- --:--:-- --:--:-- 30087
real 0m0.298s
user 0m0.003s
sys 0m0.005s
</code></pre>
where:<p><pre><code> tsl@crabapple:~> dig wikileaks.org A | grep -A 1 "; ANS"
;; ANSWER SECTION:
wikileaks.org. 2517 IN A 184.72.37.90
tsl@crabapple:~> dig -x 184.72.37.90 PTR | grep -A 1 "; ANS"
;; ANSWER SECTION:
90.37.72.184.in-addr.arpa. 300 IN PTR ec2-184-72-37-90.us-west-1.compute.amazonaws.com.
</code></pre>
palo alto:<p><pre><code> 3 rtr-border1-p2p-core1.slac.stanford.edu (134.79.252.133) 0.796 ms 0.433 ms 0.400 ms
4 slac-mr2-p2p-rtr-border1.slac.stanford.edu (192.68.191.245) 0.371 ms 0.415 ms 0.400 ms
5 sunnsdn2-ip-slacmr2.es.net (134.55.217.2) 0.668 ms 0.709 ms 0.676 ms
6 sunncr1-sunnsdn2.es.net (134.55.209.98) 0.808 ms 0.842 ms 0.823 ms
7 eqxsjrt1-te-sunncr1.es.net (134.55.38.146) 1.231 ms 1.268 ms 1.247 ms
8 equinix01-sfo5.amazon.com (206.223.116.177) 1.930 ms 1.780 ms 1.516 ms
9 * * *
</code></pre>
nyc:<p><pre><code> 3 te2-7.ccr01.jfk07.atlas.cogentco.com (154.54.1.134) 0.564 ms 0.575 ms
4 ntt.jfk07.atlas.cogentco.com (154.54.12.66) 0.664 ms 0.659 ms
5 ae-2.r22.nycmny01.us.bb.gin.ntt.net (129.250.4.174) 0.760 ms 0.731 ms
6 ae-1.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9) 31.672 ms 7.974 ms
7 ae-0.r20.sttlwa01.us.bb.gin.ntt.net (129.250.2.53) 90.576 ms 98.458 ms
8 ae-4.r20.snjsca04.us.bb.gin.ntt.net (129.250.4.103) 93.544 ms 85.011 ms
9 ae-1.r21.plalca01.us.bb.gin.ntt.net (129.250.5.32) 90.292 ms 108.205 ms
10 po-2.r03.plalca01.us.bb.gin.ntt.net (129.250.5.142) 78.070 ms 82.080 ms
11 xe-3-3.r03.plalca01.us.ce.gin.ntt.net (140.174.28.118) 91.133 ms 91.491 ms
12 * *
</code></pre>
dallas:<p><pre><code> 3 vb1300.rar3.dallas-tx.us.xo.net (216.156.0.81) 4 msec 0 msec 4 msec
4 ae0d1.cir1.dallas2-tx.us.xo.net (207.88.13.125) 12 msec 0 msec 4 msec
5 dap-brdr-04.inet.qwest.net (63.146.26.169) 0 msec 0 msec 0 msec
6 snj-core-01.inet.qwest.net (67.14.34.14) 44 msec 44 msec 44 msec
7 snj-edge-01.inet.qwest.net (205.171.233.38) 48 msec 44 msec
snj-edge-01.inet.qwest.net (205.171.233.34) 44 msec
8 67.128.102.202 48 msec 44 msec 44 msec
9 * * *</code></pre>
I'm pretty sure 50% of the people on this forum have ran nmap against wikileaks, just to see. Anyhow: ssh and ftp are open but they terminate the connection after a delay when you try to connect, probably source ip restrictions. Same for ssh. They are hosted on EC2. I am assuming they are using the Amazon AMI, which doesn't take ssh root logins, and the user name will be ec2-user@[host].<p>The connection is open for the period of the delay. This might a viable attack vector for a DDOS? (If you cannot connect to FTP or ssh, you cannot upload files).<p>Note: Wikileaks is hosted on Amazon AWS Ireland. You're telling me the US government doesn't have the ability to pull an AWS server in Ireland with a phone call? Oh please. Wikileaks is a poor attempt by the US government to unleash an attack a group that funds its political opponents - this will occur in the near future.
This seems to be counter to the goals of the attackers, no?<p>Problem: Site is disseminating information that you view as confidential at a slow rate.<p>Solution: DDoS / otherwise stop the site.<p>Catch: The entire archive of unfiltered content is already widely disseminated via a non-DDoSable channel and in the event that you ever actually manage to succeed at your stated goal there is almost certainly a dead man's switch to trigger distribution of the cryptographic key to unlock said information.<p>It seems to me that by pushing this option you just bring the "enemy" closer to the nuclear option of simultaneous, mass, unfiltered release. Unless you think they're bluffing with the insurance file, I suppose? Doesn't sound like a good risk to take.