Resultado de un ping lanzado a todas las direcciones de Internet

En el post anterior nos planteamos el ejercicio teórico del coste y viabilidad de escanear todas las direcciones IP de Internet y una vez calculado vimos que el coste de hacerlo era muy bajo. Por tanto, decidimos llevar a cabo un pequeño experimento: comprobar si era posible escanear toda Internet, por supuesto sin realizar ninguna acción dañina para nadie en la red.

Si bien la acción puede no ser totalmente inocua (algún IDS puede haberse quejado), hemos tratado de hacer el experimento lo menos dañino o problemático posible. En este sentido, lo más inocuo que se nos ha ocurrido es lanzar un ping (ICMP echo) a todas y cada una de las direcciones de Internet. Aunque sólo hemos enviado un único paquete por IP, hemos desordenado los escaneos para evitar que una red recibiera un alto número de paquetes consecutivos.

Para ello preparamos los dos hilos de ejecución, en cuyo trabajo he contado con la inestimable ayuda de Nacho López, un experimentado programador de C. En cualquier caso las mismas fuentes del ping podrían haber sido una buena fuente de inspiración:

Envia_echo-icmp ()
Recibe_echo_icmp ()

El proceso funciona de manera stateless: uno envía de manera ciega, y el otro simplemente va anotando los paquetes respuesta que le llegan, por lo que no se consume ninguna cantidad de memoria por cada conexión.

La mayor complejidad ha venido por el coste de recursos de almacenar en disco, debido a que era necesario ajustar bien y programar teniendo en cuenta el rendimiento de disco, de manera que cuando llegasen los resultados no perdiésemos paquetes. Tras 10 horas, obtuvimos los siguientes resultados:

Resultado de global de ping contestados: 284.401.158 direcciones IP han contestado al ping, es decir un 7% de equipos. Gráficamente:

Si lo separamos por redes /8 vemos los siguientes porcentajes:

NETWORK /8 pongs answered % pongs answered
0.X.X.X 0 0,00% IANA – Local Identification RESERVED
1.X.X.X 1945822 11,60% APNIC whois.apnic.net ALLOCATED
2.X.X.X 3060724 18,24% RIPE NCC whois.ripe.net ALLOCATED
3.X.X.X 3 0,00% General Electric Company LEGACY
4.X.X.X 47999 0,29% Level 3 Communications, Inc. LEGACY
5.X.X.X 1476715 8,80% RIPE NCC whois.ripe.net ALLOCATED
6.X.X.X 41 0,00% Army Information Systems Center LEGACY
7.X.X.X 0 0,00% Administered by ARIN whois.arin.net LEGACY
8.X.X.X 76429 0,46% Level 3 Communications, Inc. LEGACY
9.X.X.X 0 0,00% IBM LEGACY
10.X.X.X 3 0,00% IANA – Private Use RESERVED
11.X.X.X 0 0,00% DoD Intel Information Systems LEGACY
12.X.X.X 401646 2,39% AT&T Bell Laboratories LEGACY
13.X.X.X 635 0,00% Xerox Corporation LEGACY
14.X.X.X 2066669 12,32% APNIC whois.apnic.net ALLOCATED
15.X.X.X 10312 0,06% Hewlett-Packard Company LEGACY
16.X.X.X 18 0,00% Digital Equipment Corporation LEGACY
17.X.X.X 1897 0,01% Apple Computer Inc. LEGACY
18.X.X.X 25281 0,15% MIT LEGACY
19.X.X.X 0 0,00% Ford Motor Company LEGACY
20.X.X.X 2069 0,01% Computer Sciences Corporation LEGACY
21.X.X.X 0 0,00% DDN-RVN LEGACY
22.X.X.X 0 0,00% Defense Information Systems Agency LEGACY
23.X.X.X 2119841 12,64% ARIN whois.arin.net ALLOCATED
24.X.X.X 2854162 17,01% ARIN whois.arin.net ALLOCATED
25.X.X.X 0 0,00% UK Ministry of Defence whois.ripe.net LEGACY
26.X.X.X 0 0,00% Defense Information Systems Agency LEGACY
27.X.X.X 1846998 11,01% APNIC whois.apnic.net ALLOCATED
28.X.X.X 0 0,00% DSI-North LEGACY
29.X.X.X 2 0,00% Defense Information Systems Agency LEGACY
30.X.X.X 3 0,00% Defense Information Systems Agency LEGACY
31.X.X.X 1444805 8,61% RIPE NCC whois.ripe.net ALLOCATED
32.X.X.X 6791 0,04% AT&T Global Network Services LEGACY
33.X.X.X 0 0,00% DLA Systems Automation Center LEGACY
34.X.X.X 73 0,00% Halliburton Company LEGACY
35.X.X.X 30637 0,18% Administered by ARIN whois.arin.net LEGACY
36.X.X.X 447230 2,67% APNIC whois.apnic.net ALLOCATED
37.X.X.X 1909720 11,38% RIPE NCC whois.ripe.net ALLOCATED
38.X.X.X 176523 1,05% PSINet, Inc. LEGACY
39.X.X.X 393476 2,35% APNIC whois.apnic.net ALLOCATED
40.X.X.X 1165 0,01% Administered by ARIN whois.arin.net LEGACY
41.X.X.X 1785846 10,64% AFRINIC whois.afrinic.net ALLOCATED
42.X.X.X 905039 5,39% APNIC whois.apnic.net ALLOCATED
43.X.X.X 13447 0,08% Administered by APNIC whois.apnic.net LEGACY
44.X.X.X 70 0,00% Amateur Radio Digital Communications LEGACY
45.X.X.X 1 0,00% Administered by ARIN whois.arin.net LEGACY
46.X.X.X 2658072 15,84% RIPE NCC whois.ripe.net ALLOCATED
47.X.X.X 11729 0,07% Administered by ARIN whois.arin.net LEGACY
48.X.X.X 0 0,00% Prudential Securities Inc. LEGACY
49.X.X.X 1643097 9,79% APNIC whois.apnic.net ALLOCATED
50.X.X.X 2086304 12,44% ARIN whois.arin.net ALLOCATED
51.X.X.X 0 0,00% UK Government Department for Work and Pensions whois.ripe.net LEGACY
52.X.X.X 102 0,00% E.I. duPont de Nemours and Co., Inc. LEGACY
53.X.X.X 3 0,00% Cap Debis CCS LEGACY
54.X.X.X 22092 0,13% Merck and Co., Inc. LEGACY
55.X.X.X 0 0,00% DoD Network Information Center LEGACY
56.X.X.X 22 0,00% US Postal Service LEGACY
57.X.X.X 6653 0,04% SITA LEGACY
58.X.X.X 2583602 15,40% APNIC whois.apnic.net ALLOCATED
59.X.X.X 1508086 8,99% APNIC whois.apnic.net ALLOCATED
60.X.X.X 1798876 10,72% APNIC whois.apnic.net ALLOCATED
61.X.X.X 1652124 9,85% APNIC whois.apnic.net ALLOCATED
62.X.X.X 1561085 9,30% RIPE NCC whois.ripe.net ALLOCATED
63.X.X.X 569208 3,39% ARIN whois.arin.net ALLOCATED
64.X.X.X 1372940 8,18% ARIN whois.arin.net ALLOCATED
65.X.X.X 1136397 6,77% ARIN whois.arin.net ALLOCATED
66.X.X.X 1835266 10,94% ARIN whois.arin.net ALLOCATED
67.X.X.X 2623277 15,64% ARIN whois.arin.net ALLOCATED
68.X.X.X 2117113 12,62% ARIN whois.arin.net ALLOCATED
69.X.X.X 2335093 13,92% ARIN whois.arin.net ALLOCATED
70.X.X.X 1841378 10,98% ARIN whois.arin.net ALLOCATED
71.X.X.X 4511701 26,89% ARIN whois.arin.net ALLOCATED
72.X.X.X 3287369 19,59% ARIN whois.arin.net ALLOCATED
73.X.X.X 3589118 21,39% ARIN whois.arin.net ALLOCATED
74.X.X.X 2976565 17,74% ARIN whois.arin.net ALLOCATED
75.X.X.X 3341673 19,92% ARIN whois.arin.net ALLOCATED
76.X.X.X 2727681 16,26% ARIN whois.arin.net ALLOCATED
77.X.X.X 3639746 21,69% RIPE NCC whois.ripe.net ALLOCATED
78.X.X.X 3505048 20,89% RIPE NCC whois.ripe.net ALLOCATED
79.X.X.X 3991921 23,79% RIPE NCC whois.ripe.net ALLOCATED
80.X.X.X 2325444 13,86% RIPE NCC whois.ripe.net ALLOCATED
81.X.X.X 2380619 14,19% RIPE NCC whois.ripe.net ALLOCATED
82.X.X.X 3540108 21,10% RIPE NCC whois.ripe.net ALLOCATED
83.X.X.X 3170669 18,90% RIPE NCC whois.ripe.net ALLOCATED
84.X.X.X 3276645 19,53% RIPE NCC whois.ripe.net ALLOCATED
85.X.X.X 2651705 15,81% RIPE NCC whois.ripe.net ALLOCATED
86.X.X.X 1740467 10,37% RIPE NCC whois.ripe.net ALLOCATED
87.X.X.X 3251776 19,38% RIPE NCC whois.ripe.net ALLOCATED
88.X.X.X 4356116 25,96% RIPE NCC whois.ripe.net ALLOCATED
89.X.X.X 2724476 16,24% RIPE NCC whois.ripe.net ALLOCATED
90.X.X.X 2344320 13,97% RIPE NCC whois.ripe.net ALLOCATED
91.X.X.X 2404688 14,33% RIPE NCC whois.ripe.net ALLOCATED
92.X.X.X 2556074 15,24% RIPE NCC whois.ripe.net ALLOCATED
93.X.X.X 2878139 17,16% RIPE NCC whois.ripe.net ALLOCATED
94.X.X.X 3165218 18,87% RIPE NCC whois.ripe.net ALLOCATED
95.X.X.X 3512883 20,94% RIPE NCC whois.ripe.net ALLOCATED
96.X.X.X 3490340 20,80% ARIN whois.arin.net ALLOCATED
97.X.X.X 970326 5,78% ARIN whois.arin.net ALLOCATED
98.X.X.X 4549209 27,12% ARIN whois.arin.net ALLOCATED
99.X.X.X 1392114 8,30% ARIN whois.arin.net ALLOCATED
100.X.X.X 128763 0,77% ARIN whois.arin.net ALLOCATED
101.X.X.X 1290800 7,69% APNIC whois.apnic.net ALLOCATED
102.X.X.X 0 0,00% AFRINIC whois.afrinic.net ALLOCATED
103.X.X.X 93789 0,56% APNIC whois.apnic.net ALLOCATED
104.X.X.X 0 0,00% ARIN whois.arin.net ALLOCATED
105.X.X.X 462111 2,75% AFRINIC whois.afrinic.net ALLOCATED
106.X.X.X 1197732 7,14% APNIC whois.apnic.net ALLOCATED
107.X.X.X 300499 1,79% ARIN whois.arin.net ALLOCATED
108.X.X.X 2426908 14,47% ARIN whois.arin.net ALLOCATED
109.X.X.X 2469363 14,72% RIPE NCC whois.ripe.net ALLOCATED
110.X.X.X 2454778 14,63% APNIC whois.apnic.net ALLOCATED
111.X.X.X 1903735 11,35% APNIC whois.apnic.net ALLOCATED
112.X.X.X 2968386 17,69% APNIC whois.apnic.net ALLOCATED
113.X.X.X 3079706 18,36% APNIC whois.apnic.net ALLOCATED
114.X.X.X 2800478 16,69% APNIC whois.apnic.net ALLOCATED
115.X.X.X 2837602 16,91% APNIC whois.apnic.net ALLOCATED
116.X.X.X 1915863 11,42% APNIC whois.apnic.net ALLOCATED
117.X.X.X 2128063 12,68% APNIC whois.apnic.net ALLOCATED
118.X.X.X 2896711 17,27% APNIC whois.apnic.net ALLOCATED
119.X.X.X 3060064 18,24% APNIC whois.apnic.net ALLOCATED
120.X.X.X 1199805 7,15% APNIC whois.apnic.net ALLOCATED
121.X.X.X 2665125 15,89% APNIC whois.apnic.net ALLOCATED
122.X.X.X 2168852 12,93% APNIC whois.apnic.net ALLOCATED
123.X.X.X 2687657 16,02% APNIC whois.apnic.net ALLOCATED
124.X.X.X 2493104 14,86% APNIC whois.apnic.net ALLOCATED
125.X.X.X 3002885 17,90% APNIC whois.apnic.net ALLOCATED
126.X.X.X 952186 5,68% APNIC whois.apnic.net ALLOCATED
127.X.X.X 0 0,00% IANA – Loopback RESERVED
128.X.X.X 773669 4,61% Administered by ARIN whois.arin.net LEGACY
129.X.X.X 335098 2,00% Administered by ARIN whois.arin.net LEGACY
130.X.X.X 480277 2,86% Administered by ARIN whois.arin.net LEGACY
131.X.X.X 181065 1,08% Administered by ARIN whois.arin.net LEGACY
132.X.X.X 235630 1,40% Administered by ARIN whois.arin.net LEGACY
133.X.X.X 49242 0,29% Administered by APNIC whois.apnic.net LEGACY
134.X.X.X 288572 1,72% Administered by ARIN whois.arin.net LEGACY
135.X.X.X 23972 0,14% Administered by ARIN whois.arin.net LEGACY
136.X.X.X 116382 0,69% Administered by ARIN whois.arin.net LEGACY
137.X.X.X 178580 1,06% Administered by ARIN whois.arin.net LEGACY
138.X.X.X 81333 0,48% Administered by ARIN whois.arin.net LEGACY
139.X.X.X 167798 1,00% Administered by ARIN whois.arin.net LEGACY
140.X.X.X 293204 1,75% Administered by ARIN whois.arin.net LEGACY
141.X.X.X 288597 1,72% Administered by RIPE NCC whois.ripe.net LEGACY
142.X.X.X 344687 2,05% Administered by ARIN whois.arin.net LEGACY
143.X.X.X 81379 0,49% Administered by ARIN whois.arin.net LEGACY
144.X.X.X 90422 0,54% Administered by ARIN whois.arin.net LEGACY
145.X.X.X 200673 1,20% Administered by RIPE NCC whois.ripe.net LEGACY
146.X.X.X 257674 1,54% Administered by ARIN whois.arin.net LEGACY
147.X.X.X 148189 0,88% Administered by ARIN whois.arin.net LEGACY
148.X.X.X 78053 0,47% Administered by ARIN whois.arin.net LEGACY
149.X.X.X 301946 1,80% Administered by ARIN whois.arin.net LEGACY
150.X.X.X 96794 0,58% Administered by APNIC whois.apnic.net LEGACY
151.X.X.X 954773 5,69% Administered by RIPE NCC whois.ripe.net LEGACY
152.X.X.X 147825 0,88% Administered by ARIN whois.arin.net LEGACY
153.X.X.X 44430 0,26% Administered by APNIC whois.apnic.net LEGACY
154.X.X.X 25662 0,15% Administered by AFRINIC whois.afrinic.net LEGACY
155.X.X.X 64935 0,39% Administered by ARIN whois.arin.net LEGACY
156.X.X.X 53951 0,32% Administered by ARIN whois.arin.net LEGACY
157.X.X.X 78752 0,47% Administered by ARIN whois.arin.net LEGACY
158.X.X.X 106178 0,63% Administered by ARIN whois.arin.net LEGACY
159.X.X.X 159920 0,95% Administered by ARIN whois.arin.net LEGACY
160.X.X.X 120077 0,72% Administered by ARIN whois.arin.net LEGACY
161.X.X.X 83081 0,50% Administered by ARIN whois.arin.net LEGACY
162.X.X.X 43521 0,26% Administered by ARIN whois.arin.net LEGACY
163.X.X.X 161035 0,96% Administered by APNIC whois.apnic.net LEGACY
164.X.X.X 124244 0,74% Administered by ARIN whois.arin.net LEGACY
165.X.X.X 130803 0,78% Administered by ARIN whois.arin.net LEGACY
166.X.X.X 256189 1,53% Administered by ARIN whois.arin.net LEGACY
167.X.X.X 46554 0,28% Administered by ARIN whois.arin.net LEGACY
168.X.X.X 187654 1,12% Administered by ARIN whois.arin.net LEGACY
169.X.X.X 79520 0,47% Administered by ARIN whois.arin.net LEGACY
170.X.X.X 88594 0,53% Administered by ARIN whois.arin.net LEGACY
171.X.X.X 855441 5,10% Administered by APNIC whois.apnic.net LEGACY
172.X.X.X 41571 0,25% Administered by ARIN whois.arin.net LEGACY
173.X.X.X 3501677 20,87% ARIN whois.arin.net ALLOCATED
174.X.X.X 2853025 17,01% ARIN whois.arin.net ALLOCATED
175.X.X.X 2498128 14,89% APNIC whois.apnic.net ALLOCATED
176.X.X.X 2036792 12,14% RIPE NCC whois.ripe.net ALLOCATED
177.X.X.X 3759343 22,41% LACNIC whois.lacnic.net ALLOCATED
178.X.X.X 4004355 23,87% RIPE NCC whois.ripe.net ALLOCATED
179.X.X.X 0 0,00% LACNIC whois.lacnic.net ALLOCATED
180.X.X.X 2598738 15,49% APNIC whois.apnic.net ALLOCATED
181.X.X.X 874733 5,21% LACNIC whois.lacnic.net ALLOCATED
182.X.X.X 2167285 12,92% APNIC whois.apnic.net ALLOCATED
183.X.X.X 3074376 18,32% APNIC whois.apnic.net ALLOCATED
184.X.X.X 3082669 18,37% ARIN whois.arin.net ALLOCATED
185.X.X.X 3806 0,02% RIPE NCC whois.ripe.net ALLOCATED
186.X.X.X 3650599 21,76% LACNIC whois.lacnic.net ALLOCATED
187.X.X.X 4419158 26,34% LACNIC whois.lacnic.net ALLOCATED
188.X.X.X 3966741 23,64% Administered by RIPE NCC whois.ripe.net LEGACY
189.X.X.X 5836526 34,79% LACNIC whois.lacnic.net ALLOCATED
190.X.X.X 3628220 21,63% LACNIC whois.lacnic.net ALLOCATED
191.X.X.X 1 0,00% Administered by LACNIC whois.lacnic.net LEGACY
192.X.X.X 180470 1,08% Administered by ARIN whois.arin.net LEGACY
193.X.X.X 627709 3,74% RIPE NCC whois.ripe.net ALLOCATED
194.X.X.X 526129 3,14% RIPE NCC whois.ripe.net ALLOCATED
195.X.X.X 899577 5,36% RIPE NCC whois.ripe.net ALLOCATED
196.X.X.X 230604 1,37% Administered by AFRINIC whois.afrinic.net LEGACY
197.X.X.X 348981 2,08% AFRINIC whois.afrinic.net ALLOCATED
198.X.X.X 499496 2,98% Administered by ARIN whois.arin.net LEGACY
199.X.X.X 448530 2,67% ARIN whois.arin.net ALLOCATED
200.X.X.X 1238090 7,38% LACNIC whois.lacnic.net ALLOCATED
201.X.X.X 2910652 17,35% LACNIC whois.lacnic.net ALLOCATED
202.X.X.X 850551 5,07% APNIC whois.apnic.net ALLOCATED
203.X.X.X 863842 5,15% APNIC whois.apnic.net ALLOCATED
204.X.X.X 506084 3,02% ARIN whois.arin.net ALLOCATED
205.X.X.X 255758 1,52% ARIN whois.arin.net ALLOCATED
206.X.X.X 436237 2,60% ARIN whois.arin.net ALLOCATED
207.X.X.X 718085 4,28% ARIN whois.arin.net ALLOCATED
208.X.X.X 935239 5,57% ARIN whois.arin.net ALLOCATED
209.X.X.X 941352 5,61% ARIN whois.arin.net ALLOCATED
210.X.X.X 892003 5,32% APNIC whois.apnic.net ALLOCATED
211.X.X.X 1475532 8,79% APNIC whois.apnic.net ALLOCATED
212.X.X.X 1285251 7,66% RIPE NCC whois.ripe.net ALLOCATED
213.X.X.X 1489497 8,88% RIPE NCC whois.ripe.net ALLOCATED
214.X.X.X 15 0,00% US-DOD LEGACY
215.X.X.X 0 0,00% US-DOD LEGACY
216.X.X.X 1391324 8,29% ARIN whois.arin.net ALLOCATED
217.X.X.X 1721029 10,26% RIPE NCC whois.ripe.net ALLOCATED
218.X.X.X 1859314 11,08% APNIC whois.apnic.net ALLOCATED
219.X.X.X 1634348 9,74% APNIC whois.apnic.net ALLOCATED
220.X.X.X 1714546 10,22% APNIC whois.apnic.net ALLOCATED
221.X.X.X 2076679 12,38% APNIC whois.apnic.net ALLOCATED
222.X.X.X 2484533 14,81% APNIC whois.apnic.net ALLOCATED
223.X.X.X 1803849 10,75% APNIC whois.apnic.net ALLOCATED
224.X.X.X 0 0,00% Multicast RESERVED
225.X.X.X 0 0,00% Multicast RESERVED
226.X.X.X 0 0,00% Multicast RESERVED
227.X.X.X 0 0,00% Multicast RESERVED
228.X.X.X 0 0,00% Multicast RESERVED
229.X.X.X 0 0,00% Multicast RESERVED
230.X.X.X 0 0,00% Multicast RESERVED
231.X.X.X 0 0,00% Multicast RESERVED
232.X.X.X 0 0,00% Multicast RESERVED
233.X.X.X 0 0,00% Multicast RESERVED
234.X.X.X 0 0,00% Multicast RESERVED
235.X.X.X 0 0,00% Multicast RESERVED
236.X.X.X 0 0,00% Multicast RESERVED
237.X.X.X 0 0,00% Multicast RESERVED
238.X.X.X 0 0,00% Multicast RESERVED
239.X.X.X 0 0,00% Multicast RESERVED
240.X.X.X 0 0,00% Future use RESERVED
241.X.X.X 0 0,00% Future use RESERVED
242.X.X.X 0 0,00% Future use RESERVED
243.X.X.X 0 0,00% Future use RESERVED
244.X.X.X 0 0,00% Future use RESERVED
245.X.X.X 0 0,00% Future use RESERVED
246.X.X.X 0 0,00% Future use RESERVED
247.X.X.X 0 0,00% Future use RESERVED
248.X.X.X 0 0,00% Future use RESERVED
249.X.X.X 0 0,00% Future use RESERVED
250.X.X.X 0 0,00% Future use RESERVED
251.X.X.X 0 0,00% Future use RESERVED
252.X.X.X 0 0,00% Future use RESERVED
253.X.X.X 0 0,00% Future use RESERVED
254.X.X.X 0 0,00% Future use RESERVED
255.X.X.X 0 0,00% Future use RESERVED

Gráficamente:

Hay que tener en cuenta que hemos escaneado todo el espacio de direccionamiento sin eliminar direccionamiento privado ni redes reservadas. Obviamente vemos que las direcciones reservadas no contestan, lo que encaja con lo que dice IANA sobre las redes reservadas.

También hemos agrupado el numero de pong que nos han contestado las redes /24 (clase C), con lo que podemos ver el nivel de densidad de direcciones IP de estas redes. Por ejemplo, ¿cuántas clases C han contestado 20 pongs?

Number of pongs answered Number of /24 networks
1 238877
2 138291
3 103826
4 84879
5 70612
6 68622
7 63042
8 62594
9 58333
10 55617
11 53531
12 52186
13 49189
14 47076
15 45662
16 44469
17 42722
18 41154
19 40506
20 41286
21 44013
22 39223
23 36442
24 35545
25 34471
26 33956
27 32876
28 32421
29 31634
30 31588
31 30484
32 30885
33 29614
34 29713
35 29065
36 28964
37 28204
38 28012
39 27586
40 27011
41 26751
42 26370
43 25801
44 25580
45 25302
46 25233
47 24642
48 24709
49 24396
50 24408
51 24086
52 24367
53 24158
54 24105
55 23730
56 23858
57 23725
58 23582
59 23626
60 23498
61 23583
62 23277
63 22940
64 22582
65 22202
66 22071
67 21547
68 21415
69 20912
70 20511
71 20155
72 19725
73 19194
74 18860
75 18930
76 18241
77 17725
78 17604
79 17134
80 17140
81 16573
82 16306
83 16177
84 15855
85 15660
86 15476
87 15457
88 15386
89 15039
90 14900
91 14802
92 14500
93 14100
94 14079
95 14019
96 13751
97 13409
98 13443
99 13240
100 13052
101 12727
102 12745
103 12143
104 12175
105 11793
106 11567
107 11502
108 11237
109 11088
110 10677
111 10621
112 10524
113 10353
114 10306
115 10048
116 9987
117 9798
118 9673
119 9747
120 9606
121 9398
122 9441
123 8991
124 9181
125 9095
126 8888
127 8556
128 8522
129 8406
130 8406
131 8267
132 8194
133 8252
134 8023
135 7910
136 7692
137 7643
138 7764
139 7566
140 7431
141 7403
142 7382
143 7512
144 7330
145 7261
146 7044
147 7078
148 7158
149 7210
150 6878
151 6941
152 6921
153 7072
154 6965
155 6919
156 6894
157 6909
158 7043
159 6816
160 6844
161 6892
162 6868
163 6958
164 6836
165 6905
166 6954
167 6917
168 7053
169 7005
170 6867
171 6931
172 6887
173 6849
174 6817
175 6781
176 6635
177 6630
178 6657
179 6514
180 6255
181 6310
182 6330
183 6134
184 5864
185 5680
186 5714
187 5559
188 5445
189 5415
190 5325
191 5211
192 5122
193 5110
194 4984
195 4939
196 4712
197 4549
198 4727
199 4582
200 4517
201 4550
202 4488
203 4442
204 4413
205 4210
206 4228
207 4182
208 4158
209 4137
210 4020
211 4013
212 3982
213 3941
214 3958
215 3978
216 3980
217 3924
218 3670
219 3690
220 3696
221 3620
222 3447
223 3483
224 3406
225 3387
226 3391
227 3193
228 3116
229 3233
230 3157
231 3123
232 3118
233 3278
234 3285
235 3430
236 3714
237 3922
238 4333
239 4594
240 5207
241 5740
242 6262
243 6736
244 7136
245 8169
246 9244
247 10536
248 11591
249 12330
250 12567
251 12092
252 9378
253 6096
254 3192
255 1481
256 467

Gráficamente:

Vemos que muchas redes no contestan nada, principalmente porque son redes reservadas, y vemos que hay bloques en los que contestan muchas.

También hemos realizado el análisis sobre el byte de menos peso de la dirección IP, teniendo en cuenta que hemos tratado las direcciones como si fuesen todas «normales». Se ve claramente que tanto las acabadas en .0 como las acabadas en .255 contestan mucho menos al ping. Por otro lado también podemos observar que la IP acabada en .1 es la que mas contesta al ping, debido a que normalmente es la utilizada para el router, y a partir de ahí suele filtrarse el tráfico. Esto se puede ver claramente en el X% respecto a la media habitual. También se perciben una franjas que nos muestran las subredes /25, /26, /27, etc…

Less significative byte of ip address Count of pongs
x.x.x.0 749789
x.x.x.1 2188704
x.x.x.2 1432608
x.x.x.3 1312164
x.x.x.4 1260519
x.x.x.5 1344259
x.x.x.6 1317523
x.x.x.7 1226345
x.x.x.8 1210025
x.x.x.9 1396354
x.x.x.10 1338214
x.x.x.11 1253251
x.x.x.12 1225913
x.x.x.13 1297186
x.x.x.14 1290901
x.x.x.15 1194033
x.x.x.16 1177008
x.x.x.17 1424293
x.x.x.18 1297307
x.x.x.19 1210971
x.x.x.20 1208820
x.x.x.21 1274382
x.x.x.22 1258630
x.x.x.23 1171451
x.x.x.24 1157615
x.x.x.25 1346065
x.x.x.26 1247689
x.x.x.27 1172728
x.x.x.28 1160244
x.x.x.29 1232213
x.x.x.30 1252088
x.x.x.31 1133193
x.x.x.32 1129206
x.x.x.33 1438811
x.x.x.34 1273545
x.x.x.35 1191265
x.x.x.36 1166209
x.x.x.37 1232786
x.x.x.38 1222823
x.x.x.39 1132063
x.x.x.40 1128406
x.x.x.41 1308812
x.x.x.42 1220378
x.x.x.43 1142863
x.x.x.44 1130136
x.x.x.45 1203766
x.x.x.46 1192938
x.x.x.47 1108922
x.x.x.48 1097390
x.x.x.49 1328159
x.x.x.50 1225132
x.x.x.51 1143527
x.x.x.52 1120597
x.x.x.53 1186295
x.x.x.54 1176274
x.x.x.55 1103437
x.x.x.56 1089146
x.x.x.57 1253521
x.x.x.58 1173048
x.x.x.59 1104981
x.x.x.60 1106008
x.x.x.61 1169959
x.x.x.62 1192879
x.x.x.63 1048740
x.x.x.64 1048258
x.x.x.65 1425598
x.x.x.66 1229128
x.x.x.67 1142903
x.x.x.68 1118736
x.x.x.69 1183038
x.x.x.70 1183928
x.x.x.71 1099966
x.x.x.72 1087771
x.x.x.73 1259314
x.x.x.74 1168810
x.x.x.75 1102380
x.x.x.76 1085211
x.x.x.77 1155721
x.x.x.78 1151672
x.x.x.79 1065110
x.x.x.80 1062766
x.x.x.81 1285575
x.x.x.82 1166756
x.x.x.83 1092135
x.x.x.84 1073821
x.x.x.85 1141621
x.x.x.86 1133532
x.x.x.87 1058285
x.x.x.88 1048255
x.x.x.89 1209209
x.x.x.90 1136792
x.x.x.91 1069963
x.x.x.92 1057058
x.x.x.93 1121637
x.x.x.94 1128962
x.x.x.95 1031653
x.x.x.96 1030381
x.x.x.97 1311889
x.x.x.98 1160407
x.x.x.99 1088350
x.x.x.100 1090587
x.x.x.101 1146524
x.x.x.102 1134417
x.x.x.103 1054936
x.x.x.104 1044601
x.x.x.105 1206107
x.x.x.106 1126080
x.x.x.107 1060212
x.x.x.108 1046358
x.x.x.109 1110790
x.x.x.110 1119034
x.x.x.111 1036203
x.x.x.112 1025151
x.x.x.113 1239712
x.x.x.114 1125907
x.x.x.115 1059326
x.x.x.116 1041760
x.x.x.117 1100008
x.x.x.118 1095607
x.x.x.119 1023199
x.x.x.120 1025290
x.x.x.121 1194711
x.x.x.122 1107546
x.x.x.123 1046629
x.x.x.124 1040910
x.x.x.125 1105172
x.x.x.126 1145872
x.x.x.127 985964
x.x.x.128 986104
x.x.x.129 1442315
x.x.x.130 1204525
x.x.x.131 1115891
x.x.x.132 1086213
x.x.x.133 1148537
x.x.x.134 1135487
x.x.x.135 1061941
x.x.x.136 1047919
x.x.x.137 1210584
x.x.x.138 1130277
x.x.x.139 1064659
x.x.x.140 1059272
x.x.x.141 1120880
x.x.x.142 1117912
x.x.x.143 1033455
x.x.x.144 1024556
x.x.x.145 1245701
x.x.x.146 1129222
x.x.x.147 1058225
x.x.x.148 1042170
x.x.x.149 1102226
x.x.x.150 1108112
x.x.x.151 1033029
x.x.x.152 1018604
x.x.x.153 1175163
x.x.x.154 1097739
x.x.x.155 1038438
x.x.x.156 1023688
x.x.x.157 1086790
x.x.x.158 1095228
x.x.x.159 996251
x.x.x.160 1001094
x.x.x.161 1276329
x.x.x.162 1128019
x.x.x.163 1050767
x.x.x.164 1031524
x.x.x.165 1092194
x.x.x.166 1086726
x.x.x.167 1013206
x.x.x.168 1002480
x.x.x.169 1166589
x.x.x.170 1087625
x.x.x.171 1023086
x.x.x.172 1007972
x.x.x.173 1071052
x.x.x.174 1072040
x.x.x.175 993387
x.x.x.176 983700
x.x.x.177 1193184
x.x.x.178 1081461
x.x.x.179 1014492
x.x.x.180 1007535
x.x.x.181 1063379
x.x.x.182 1056237
x.x.x.183 986611
x.x.x.184 974867
x.x.x.185 1130743
x.x.x.186 1054739
x.x.x.187 993950
x.x.x.188 988367
x.x.x.189 1047415
x.x.x.190 1076031
x.x.x.191 948336
x.x.x.192 946319
x.x.x.193 1293959
x.x.x.194 1108300
x.x.x.195 1036982
x.x.x.196 1012541
x.x.x.197 1070404
x.x.x.198 1062760
x.x.x.199 994345
x.x.x.200 1000985
x.x.x.201 1150214
x.x.x.202 1070547
x.x.x.203 1005395
x.x.x.204 990207
x.x.x.205 1055065
x.x.x.206 1053152
x.x.x.207 973577
x.x.x.208 964460
x.x.x.209 1173406
x.x.x.210 1070650
x.x.x.211 1002023
x.x.x.212 983619
x.x.x.213 1039752
x.x.x.214 1035196
x.x.x.215 969089
x.x.x.216 957765
x.x.x.217 1115906
x.x.x.218 1035071
x.x.x.219 972473
x.x.x.220 971376
x.x.x.221 1027993
x.x.x.222 1039586
x.x.x.223 943255
x.x.x.224 942572
x.x.x.225 1214697
x.x.x.226 1067487
x.x.x.227 995786
x.x.x.228 978545
x.x.x.229 1036333
x.x.x.230 1039868
x.x.x.231 973194
x.x.x.232 962046
x.x.x.233 1112893
x.x.x.234 1036105
x.x.x.235 976903
x.x.x.236 964068
x.x.x.237 1024653
x.x.x.238 1025546
x.x.x.239 948607
x.x.x.240 948034
x.x.x.241 1157102
x.x.x.242 1046467
x.x.x.243 977487
x.x.x.244 962750
x.x.x.245 1017034
x.x.x.246 1011215
x.x.x.247 948181
x.x.x.248 944969
x.x.x.249 1108805
x.x.x.250 1039464
x.x.x.251 995880
x.x.x.252 981302
x.x.x.253 1024893
x.x.x.254 1226421
x.x.x.255 679518

Gráficamente:

Obviamente del hecho de que contesten más o menos direcciones no es posible extraer conclusiones sobre la densidad de población IP, ya que pueden estár filtrados convenientemente.

El % de IPs que contestan al ping parece razonable, teniendo en cuenta que es lógico que para ayudar a la resolución de incidencias los equipamientos externos contesten a este protocolo. También es lógico que muchos otros no contesten, pero en todo caso no parece que el espacio IPv4 este tan saturado como anuncian.

Este experimento es una prueba de concepto de lo sencillo que es realizar una acción global contra toda Internet, con coste casi despreciable, tiempo corto y conocimientos básicos.

Podemos ver cómo sería posible escanear un puerto TCP, o incluso hacer algún ataque de intrusión de manera global (siempre que sea stateless), para lo cual cualquier ataque UDP puede ser muy efectivo (como ya pasó con slammer). En todo caso estas acciones sí que son y serian consideradas como ataques, por lo que como es de esperar no vamos a ir más allá ni evolucionar este proyecto.

Queda claro y demostrado que IPv4 realmente es muy pequeño, un argumento más para responder a la pregunta: ¿Por qué me van a atacar? Con IPv6, el vector de ataque será de muchos órdenes de magnitud superior, impidiendo este tipo de escaneos tan de fuerza «bruta».

Como curiosidad, no tuvimos respuesta de ningún contraataque, ni recibimos actividad hostil en respuesta, pero sí que estuvimos recibiendo tráfico de un servidor que nos estuvo enviando durante horas el pong de manera continua y repetida (paquetes DUP!), pensamos que debido a un error de IP que no hemos podido determinar.

Aunque el experimento ha sido lo más inocuo e inofensivo que se nos ha ocurrido, durante el experimento han llegado algunas quejas de organizaciones quejándose del escaneo. No obstante, tratándose de un «ataque» de escala mundial, las quejas han sido pocas y el proveedor de hosting receptor de los pings actuó en todo caso comunicando la queja tiempo después de haber finalizado el experimento, lo que pone de manifiesto que algo así no da tiempo a pararlo o analizarlo.

Con los datos extraídos se pueden realizar más análisis interesantes que dejamos para posteriores entradas, como por ejemplo el tema de las direcciones de red y broadcast. Espero que les haya gustado el experimento y en todo caso disculpas si les ha molestado que les hagamos un ping.

¿Cuánto cuesta hacer un ping todas las direcciones de Internet?

(Puedes comprobar el resultado de este experimento en la segunda parte de este post: Resultado de un ping lanzado a todas las direcciones de Internet)

Internet, la red de redes; todas las organizaciones modernas del mundo están conectadas a Internet. Un gran número de individuos disponemos de conexión a Internet, en el trabajo, en el domicilio particular y en el dispositivo móvil.

Esto nos puede hacer pensar que estamos hablando de un vasto rango de direcciones, dentro de las cuales los atacantes pueden centrar sus ataques en una organización determinada. Por ahora tomaremos como toda Internet el espacio de direcciones de IPv4. Cuando se despliegue y esté en uso IPv6, está claro que todo esto cambiara y habrá un nivel añadido de complejidad.

Pero, ¿y si quisiéramos realizar una acción contra todas y cada una de las direcciones de Internet? ¿Sería viable? ¿Cuánto nos costaría? ¿Recursos técnicos? ¿Recursos físicos? ¿Tiempo? ¿Dinero?
Todas estas cuestiones nos las podemos plantear de manera teórica y quizás después hacer un pequeño experimento. Para empezar con el ejercicio teórico, vamos a suponer el siguiente escenario:

  • Queremos hacerle un ping (ICMP ECHO) a todas y cada una de las direcciones de Internet.
  • Queremos almacenar el resultado de si han contestado al ping o no (vamos si han hecho pong).

Veamos algunos cálculos:

¿Cuántas direcciones IP hay?

256^4= 4.294.967.296, en números redondos 4 mil millones de direcciones.

¿Cuánto ancho de banda consume un ping?

  • En nuestro caso como vamos a considerar 58 bytes por ping.
  • Veamos el ancho de banda que consumiríamos en hacerle un ping a toda Internet: 256^4 * 58 bytes = 232 GB.

Si queremos almacenar en disco la respuesta con solo un bit por dirección nos ocuparía 512 MB. Si por comodidad de proceso guardamos un byte por cada respuesta tenemos 4GB.

Si consideramos un ancho de banda de 50 Mbits/sec tenemos que en 10 horas podemos tener el escaneo realizado.

Conocimientos técnicos necesarios: Necesitamos hacer un programa que envíe de manera continua y ciega los paquetes, y otro proceso recibirá las respuestas de manera stateless (existe software similar para escaneos TCP llamado scanrand).

Capacidad técnica: Cualquier informático con conocimiento de sockets en C, mirando el ping.c podría realizar este programa.

Potencia necesaria: Con un PC normalito es más que suficiente; en nuestros experimentos hemos podido hacerlo sin problemas con un Dual-Core 2.66Ghz 4GB de RAM y una conexión de 100Mbits a Internet.

Coste del equipo y la conexión: Pues en algún conocido hoster puede costar 30 EUR al mes. En porcentaje de uso del servidor podríamos decir que 0,42 EUR de presupuesto.

Así pues, cualquier persona con conocimientos programación en C con 30 Euros puede realizar una acción masiva y global a todas las direcciones de Internet en menos de 10 horas. Una muestra más que simplemente por estar conectado a Internet es posible recibir un ataque. En la historia de Internet han existido múltiples gusanos que han atacado de manera indiscriminada todas las direcciones de Internet, y las redes de hoy en día y la potencia de los equipos hacen que las incidencias locales se conviertan en globales en pocos minutos. Un famoso ejemplo de esto fue el gusano SQL Slammer que consiguió en poco menos de 10 minutos colapsar Internet, aprovechándose de una vulnerabilidad atacada con un solo paquete UDP de 376 bytes.

Así pues, ha quedado claro que Internet es un lugar muy, muy pequeño, y hay que estar bien protegido, ya que con tan solo estar conectado a Internet te conviertes en (al menos) un objetivo indirecto de ataques globales y automatizados. Y no estar en Internet ya no es una opción.

En el siguiente post veremos el resultado de llevar a la práctica este ejercicio teórico. Para ello, nos decidimos a realizar un simple y benigno ping, contra todas las direcciones IP de Internet. Aunque es cierto que un ping puede ser el primer paso para un ataque más sofisticado posterior, no es esta (evidentemente) la intención de este experimento. Además, el realizar un ping nos puede mostrar además el nivel de filtrado o en nivel poblacional de los rangos IP de Internet lo cual puede tener un cierto interés académico.

No se pierdan el siguiente post en el que pasaremos a describir los resultados del experimento. ¿Qué problemas técnicos nos habremos encontrado? ¿Cuántas habrán hecho un pong? ¿Cuántas quejas habremos recibido? ¿Algún contraataque? ¿Qué redes contestan más?

Números de serie

Cualquiera que viva en el mundo de hoy en día es consciente de que vivimos rodeados de un gran número de números de serie. Éstos posibilitan identificar de manera única un software, dispositivo o elemento, y si esto va asociado a una persona, permite monitorizar, controlar y registrar lo que hace esa persona si estos números pueden ser accedidos. Nótese que a diferencia de los patrones de fingerprinting, estos números no son nada accidental, sino que han sido diseñados para ser únicos.

Tras esta breve introducción, me gustaría repasar algunos de los números de serie que llevamos encima y por los cuales se nos puede identificar y de los que quizás no seamos totalmente conscientes.

Empecemos por cosas que llevamos encima:

[Read more…]

Fingerprinting

En esta entrada me gustaría repasar algunas técnicas de fingerprinting aplicadas a la privacidad/seguridad informática, teniendo en cuenta que la idea es la misma que en la clásica huella dactilar: aunque todas son parecidas, no hay dos iguales, y se puede identificar individuos concretos analizándolas. Además de las huellas dactilares hay muchos otros casos de elementos de serie o estandar, pero que acaban siendo diferentes e identificativos, como una bala que identifica el arma que la disparo, la rueda de un coche, etc.

En estos ejemplos estamos viendo que son elementos que dejan «huella», y por lo tanto suponen un riesgo importante para la privacidad (el riesgo se convierte en ventaja para las fuerzas de seguridad del Estado). Estas mismas técnicas llevadas a las redes informáticas nos permiten hacer cosas similares e identificar tipos de sistemas de manera única. Por nombrar tipos clásicos diferentes de herramientas, me gustaría reseñar una de cada tipo:

  • Nmap active fingerprinting Fue la primera herramienta que conocí de este tipo: dada una dirección IP, le lanza una serie de paquetes y según las respuestas es capaz de saber que sistema operativo hay al otro lado.
  • Passive fingerprinting p0f Esta herramienta obtiene algo parecido a la anterior pero con la gracia de que no necesita enviarle nada, sino que simplemente ve pasar el trafico y con eso ya tiene bastante.

Los dos casos anteriores son clásicos y conocidos, y en el fondo sólo detectan un sistema operativo, pero este proyecto que cito a continuación es bastante mas inquietante:

  • No hay dos navegadores iguales, PANOPTICLICK Este proyecto de la EFF nos muestra como cada navegador es diferente de otro, por la diferencia de plugins, fuentes, configuración, de manera que se puede sacar una «huella» diferente de cada uno e identificarlo de manera unívoca. Es sorprendente cómo funciona incluso en equipos de la misma organización, que en teoría deberían de ser iguales. En todos mis equipos en los que he probado el proyecto, nunca me ha salido repetido, por lo que para ese servidor soy «unicamente» identificable.

La base matemática de cualquier fingerprinting es bastante sencilla; sólo tiene que tener un número de parámetros variables de entrada, y una respuesta. Con eso, simplemente se rellena la tabla, si es capaz de identificar lo que se quiere con las entradas, tenemos la respuesta, si aparece un nuevo patrón, se da de alta. Dicho esto, si combinamos las nuevas tecnologías con las huellas físicas o comportamientos físicos/humanos, da lugar a interesantes e inquietantes nuevas posibilidades. Por ejemplo:

¿Puede identificarse un individuo por la manera en la que teclea? ¿Cadencia de tecleo, letras que teclea más rápido, etc.? Si se escanea una firma, ¿puede identificarse o diferenciarse no por el trazado final, sino por la fuerza, velocidad de los trazos? Seguro que más de una vez han reconocido a una persona desde lejos solo por la manera de caminar; ¿puede automatizarse este rasgo y combinado con otros rasgos identificar individuos? En este caso, la huella que dejaríamos que nos identificaría, no es física, sino virtual, ya que la podrían recoger cámaras, sensores, etc.

Adicionalmente, se pueden realizar técnicas de fingerprinting de manera activa, es decir interaccionando con el individuo u objeto que se quiera perfilar, o de manera pasiva simplemente «viendo» pasar al individuo o sus dispositivos, sin que tenga éste que hacer nada especial, y por supuesto, sin su consentimiento.

Sin duda nuevas posibilidades, cada una de ella con sus ventajas e inconvenientes que los individuos y las organizaciones tendremos que gestionar.

Se dónde estás: tecnologias de posicionamiento en dispositivos de hoy en dia

Dado que aspectos como la movilidad y el geoposicionamiento están poniéndose cada vez más de moda, en este post me gustaría repasar las diferentes tecnologías existentes y las implicaciones de privacidad, que en algunos casos son muy importantes. Veamos pues de qué estamos hablando.

  • Métodos de posicionamiento por parte de «la red»
    • Posicionamiento por célula telefónica: La red de telefonía móvil sabe en cada momento dónde está cada teléfono móvil, con una precisión que varía según las células pero que puede estar entre 1 Km y 35Km. Así pues, la compañía de teléfonos sabe dónde estas, y si eso no fuese suficiente, esta información la almacenan, por lo que si llevas tu móvil encima, saben donde has estado en cada momento de tu vida. ¿Se puede acceder a esta información? Sí. Las Fuerzas de Seguridad del Estado están autorizadas para ello si lo solicitan a las operadoras mediante orden judicial. Por ejemplo, tras el atentado del 11-M, sea accedió a dicha información que fue clave para encontrar a los terroristas, ya que un móvil fue encendido antes del atentado en otra ubicación donde tenían su base.

      [Read more…]

No hay nadie que nos quiera atacar

La respuesta habitual de muchos responsables de informática (de informática sí, pero no demasiado responsables) frente a la seguridad es que no tienen que preocuparse en exceso ya que según ellos, su organización no es objetivo de ataque de nadie y por lo tanto se sienten tranquilos respecto a la seguridad de sus servidores.

Obviamente, si eres un banco está claro que eres un objetivo de ataque, ya que albergas dinero, y si alguien consigue realizar una intrusión, obtiene un beneficio económico directo. Si eres un comercio online, a través de éste se puede llegar a disponer de datos de tarjetas bancarias, lo cual también se traslada en dinero. Este tipo de organizaciones ya tienen en su cabeza que son objetivo directo de ataque, y normalmente están al tanto de la seguridad de sus servidores expuestos a Internet.

Pero, si no soy ninguna de estas cosas, porque me dedico a la fabricación artesana de tornillos, ¿soy objetivo de ataque? Pues sí. Usted puede tener enemigos, empleados o ex-empleados disgustados, la competencia (poco ética), proveedores, o clientes que por alguna razón estén disgustados y tengan un particular sentido de la justicia. Pero en fin, usted puede pensar que no estamos en ninguno de estos casos; no tiene empleados o desempleados descontentos, sus clientes y proveedores (y todos sus empleados) le tienen en alta estima, su competencia juega limpio, y además, se lleva usted bien con todo el mundo.

Entonces, ¿por qué me van a atacar a mi, si no le importamos a nadie y nadie nos tiene manía? ¿Quién puede querer perjudicar a mi organización, que no ha roto un plato?

Pues mucha gente; es lo que tiene Internet. Pero, de nuevo: ¿por qué? Pues dejando aparte que su organización muy probablemente maneja dinero, es muy sencillo. Sus servidores disponen de potencia de calculo, almacenamiento, conexión a Internet, y reciben visitas de clientes o usuarios, recursos todos ellos sumamente interesantes para los atacantes; en su mayor parte, quizá no se enfrente a ataques en los que su organización sea el objetivo final, pero sí será víctima de ataques cuyo objetivo es un pez más grande. Pongamos algunos ejemplos de intrusiones, o explotación de vulnerabilidades habituales en Internet:

  • Servidor de correo: Si su servidor de correo está (incorrectamente) configurado para permitir el reenvío de correos de terceros sin autorización, será cuestión de minutos que algún spammer le utilice para desde tu servidor se envíen correos no deseados a medio mundo. Quizá no lo considere un ataque, cuando se vea incluido en listas negras de servidores de correo y los servidores de sus clientes y proveedores le devuelvan los correos, verá que la cosa no tiene demasiada gracia. Sin mencionar la posibilidad de que su servidor de correo sea saturado o le provoquen un DoS.
  • Uso del ancho de banda: Aunque puede no considerarlo un ataque en el sentido más estricto del término (usted no es el atacado), pueden utilizar sus servidores para provocar una denegación de servicio a un tercero, lo que evidentemente influirá en su conectividad y por ejemplo, la disponibilidad de los servicios que ofrece a través de esa línea de Internet.
  • Uso de sus visitas licitas y reputación para redirigir a sus clientes a páginas maliciosas, con virus y troyanos; existen virus y gusanos cuyo ataque se basa en ese propósito. Asimismo, un problema de Cross Site Scripting, de poca relevancia técnica para sus sistemas, puede tener como objetivo incrustar una página web remota con virus y troyanos en su frontal web, con lo que todos los visitantes de éste no suficientemente protegidos serán infectados con el malware. Imagine las consecuencias reputacionales.
  • Uso de un servidor para albergar una pagina de phising, de modo que un servidor de su organización albergue una copia de la página del banco XYZ.
  • Uso de la CPU de los ordenadores y servidores locales para romper contraseñas por fuerza bruta.
  • Uso de los servidores para colocar Bots de IRC, con el objetivo de poder llevar a cabo comunicaciones de manera anónima y secreta. Es habitual encontrarse este tipo de artefactos, y en mi vida profesional el mayor numero de intrusiones ha sido con este cometido.
  • Uso de los servidores para albergar contenidos ilegales, con los posibles problemas que pueden implicar: desde programas pirata, películas, o música, hasta mucho cosas peores.
  • Uso de tu servidor como anonimizador de otros ataques, con lo que los atacantes evitan que se localice su IP origen. Esto le puede meter en un lío legal de cuidado. Además de ello es habitual que una vez atacado el site remoto que era el objetivo final, para evitar dejar rastros formateen completamente el servidor intermedio.
  • Robo de publicidad: Si su organización dispone de banners publicitarios, un ataque reciente se dedica a cambiar la cuenta de publicidad «oficial» por la del atacante para conseguir llevarse los ingresos.
  • Conseguir enlaces o referencias a otro site (esto es otra especie de spam: webspam) para posicionarse bien en los buscadores (SEO). Este tipo de enlaces hay incluso quien los vende.
  • Uso combinado de un sniffer para obtener cuentas de usuarios de su organización: cuentas ftp, cuentas de shell y cuentas de correo electrónico, capturadas y utilizadas por numerosos robots y malware, sin ser en absoluto ataques dirigidos contra su organización, pero de los que es víctima.

Esta lista de posibles ataques es sólo una pequeña muestra de lo que he visto en alguna ocasión, pero no le quepa duda de que los atacantes tienen otras muchas «ideas» para utilizar sus servidores, sin que se trate un ataque dirigido en especifico a su organización. Así pues, tenga usted cuidado ya que cualquier servidor de Internet es objetivo de ataque; hay muchas razones para que le ataquen, y muy probablemente en estos momentos le estén atacando. Sea prudente y no infravalore a los criminales.

Seguridad en Cloud computing

He decidido poner el término Cloud computing en el titulo del post para tener mas visitas, ya que es un termino de moda, pero si me disculpan la pequeña «trampa», en su lugar voy a hablar de la seguridad en Infraestructuras compartidas, que es un tema tanto o más interesante en seguridad.

Cuando hablamos de Infraestructuras compartidas nos referimos a la serie de infraestructuras TI que en cualquier organización son compartidas por diversos proyectos. Por ejemplo es habitual que se comparta la infraestructura de red, el almacenamiento en una cabina de discos, o los mismos servidores físicos mediante virtualización; si es un proveedor de servicios el que ofrece la infraestructura, estos elementos estarán compartidos además entre diversos clientes que en si mismo son organizaciones diferentes (vamos, el servicio de hosting de toda la vida).

Así pues, vamos a comentar diversas vulnerabilidades que con las medidas adecuadas están contempladas y en teoría resueltas, pero que son en todo caso posibles vulnerabilidades que pueden aparecer cuando se comparten infraestructuras.

Infraestructura de red compartida: No es difícil imaginar un escenario donde tenemos varios servidores conectados a la misma infraestructura de red, donde, si todo se configura bien no deberían haber problemas, pero si se configura mal, pueden pasar entre otras las siguientes cosas: (1)

  • Sniffing: Un equipo puede ver el trafico del equipo de al lado; esto puede pasar si están conectados al mismo switch y no se han tomado las necesarias precauciones (arp posisoning).
  • DOS: Al estar un equipo próximo a otro, puede atacarlo con un gran ancho de banda o un gran numero de conexiones.
  • Interceptar/sustituir: Es posible que un equipo pueda suplantar a otro (p.e. cambiando la IP) para interceptar el trafico o suplantar respuestas.
  • Atacar: Es posible que al compartir una misma infraestructura de red, desde dentro de la misma red (por ejemplo dentro de la misma DMZ) los equipos puedan atacar a los otros, teniendo mas visibilidad de servicios que desde el exterior están cerrados. Una descripción de cómo hacer esto pueden encontrarla aquí.

¿Están las infraestructuras de red compartidas convenientemente independizadas en los servicios de hosting y de Cloud?

Infraestructura de disco compartida: En cualquier infraestructura TI, es habitual que se disponga de una cabina de disco (SAN/NAS) a la que se conectan todos los servidores (desde servidores internos, hasta servidores de la DMZ)(2)

  • Acceso a datos (no autorizados): Técnicamente es posible que un servidor se conecte al disco de otro servidor si comparte cabina, con lo que podría leer o incluso alterar los datos. Las cabinas de disco normalmente limitan qué servidor puede conectar a qué parte de disco, basándose en la direccion «MAC» (se llama WWN) de la tarjeta. ¿Podría un hacker cambiar esa dirección? ¿Tenemos hard-zoning para evitar este ataque? Aun no he visto ninguna instalación en que se configure hard-zoning ya que es bastante mas incómodo. Si piensa que es muy raro que todos los servidores tengan acceso a los mismos discos, piense en todos sus servidores host de virtualizacion que pueden acceder a todos los discos del cluster.
  • DOS/Carga: ¿Qué pasa si un servidor monopoliza todos los recursos?
  • Acceso a datos borrados: ¿Qué pasa si montamos una unidad de disco en el servidor de un cliente y luego la conectamos a otro servidor de otro cliente? ¿Si leemos el disco vemos los datos del otro cliente? Muchos me diréis que es una posibilidad muy extraña ya que las cabinas de discos limpian las LUNs antes de asignarlas, pero esto «se le paso» a Amazon Ec2.

¿Están las infraestructuras de almacenamiento convenientemente independizadas en los servicios de hosting y de Cloud? (3)

  • Virtualización: Cualquier entorno TI de hoy en día dispone de servidores virtualizados, ya que es una de la manera mas efectivas de compartir recursos, garantizar la disponibilidad, ahorrar energía y muchas otras cosas. Numerosos sistemas Cloud (IAAS) están basados fundamentalmente en sistemas virtualizados, con APIs de autoprovisionamiento. Veamos algunos de los ataques que se pueden realizar en este tipo de entornos.
    • Ataques de guest a host: Ya han aparecido vulnerabilidades mediante las cuales un guest ha podido ejecutar código en el espacio del host, y por lo tanto desde un servidor virtual es posible atacar a otras maquinas virtuales. Véase este enlace para más detalles.
    • Consolas remotas compartidas (el «control panel» del cloud): Si tenemos un sistema de virtualización compartido, al cual accedemos desde una consola de gestión remota a través de Internet, ¿qué pasa si esta consola de gestión tiene alguna vulnerabilidad y alguien coge el control? Pueden haber muchos posibles problemas, desde vulnerabilidades de la aplicación de gestión remota (XSS para robo de sesión sería un ataque viable) a posibles pérdidas de credenciales. La autenticación de estos sistemas por ahora es simple y sin dispositivos robustos. Otro vector de ataque pueden ser las APIs de gestión de ofrecidas por los servicios de cloud, ya que mediante estas APIs se pueden crear o destruir servidores; ¿seguro que no hay vulnerabilidades mediante las cuales se puedan crear o destruir servidores de otro cliente?
    • Carga/DOS/QOS: ¿Qué pasa si un cliente monopoliza todos los recursos?
    • Vulnerabilidades del host (desde fuera, o desde los guests): El host es otro sistema que puede ser atacado, bien desde donde sea accesible (consola de gestión p.e.) o bien desde los propios guest que debido a alguna vulnerabilidad son capaces de coger control de host. Dicho de otra forma, aunque uno pueda tener su servidor web y sus aplicativos securizados, quizá el host que los alberga no lo está.
  • Servidores web/servidores de aplicaciones compartidos: Es habitual compartir el mismo servidor de aplicaciones entre diversos proyectos, pero hay que contemplar los problemas que nos podemos encontrar:(4)
    • Tienen acceso al mismo almacenamiento.
    • Son el mismo usuario de maquina/BBDD/memoria.
    • QOS: Puede un usuario degradar el rendimiento de todos los usuarios.

    Un ejemplo de estos servicios en la nube son: Windows azure o Google Application Engine.

¿Están las infraestructuras de virtualización convenientemente independizadas en los servicios de hosting y de Cloud?

Hosting/Aplicaciones SAAS compartidas: Dentro de lo que está tan de moda del cloud, también se incluyen de alguna manera las aplicaciones compartidas modelo cloud (SAAS). En el fondo, éste es el modelo mas antiguo de hosting, en el que las aplicaciones originales eran servidores web, servidores de correo compartidos entre diversos clientes. Hoy en día se ofrecen aplicaciones mas elaboradas que ofrecen más valor a las organizaciones. Veamos qué problemas nos podemos encontrar en estos modelos.

Imagínese que comparte aplicación entre «perfiles» o clientes. Es posible que dos usuarios de la misma aplicación, por algún error de diseño de ésta, tengan acceso a lectura o modificación de otro usuario. Por ejemplo, recordarán que hace poco sucedió que un usuario de facebook podía ver cualquier conversación del chat de otro. Así pues, si usamos de manera compartida una «aplicación» SAAS, nos podemos encontrar con posibles problemas si no ésta no está bien implementada. ¿Podría pasar que en nuestro CRM en SAAS por un error de programación pudiéramos ver los clientes de otra empresa también albergada en este SAAS? Facebook tuvo una vulnerabilidad con la que podías ver los chats de otros usuarios.

¿Están las aplicaciones convenientemente independizadas en los servicios de hosting y de Cloud? (5)

Mira por dónde, sin quererlo, he acabado hablando de Cloud Computing, nada nuevo respecto a lo que ya conocemos en cuanto a infraestructuras compartidas, pero sin duda una novedad en cuanto a que está todo junto, con las ventajas que esto aporta, pero con el añadido que hay que considerarlo todo conjuntamente.

Por repasar los tipos de Cloud existentes:

  • IAAS, Infraestructure as a service: básicamente podríamos decir que tenemos una macroplataforma virtualizada bajo demanda (1)(2)(3).
  • PAAS, Platform as a Service: tenemos una especie de servidor de aplicaciones distribuido y autoescalable (4).
  • SAAS, Software as a Service: tenemos una aplicación general la cual nos da servicio (5).

En este post hemos revisado algunas vulnerabilidades desde un punto de vista técnico que aparecen si compartimos infraestructuras. Desde el punto de vista de control sobre los servicios externalizados y concentrados en datacenters de megacorporaciones también hay mucho que hablar, y por otro lado los proveedores de sistemas virtuales están redefiniendo sus productos haciendo que cada vez se parezcan mas a una nube «privada» en cuanto a que se dispone de unas infraestructuras compartidas autogestionadas. Todas la posibles vulnerabilidades mencionadas sólo son posibles puntos de fallo por donde aparecerán vulnerabilidades, que aunque en principio ya están contempladas y cubiertas, debemos contar que irán apareciendo nuevas vulnerabilidades causadas por compartir infraestructura. Si dicha infraestructura es sólo compartida entre proyectos internos de la organización los riesgos son unos, pero si la infraestructura es compartida con no sabemos quién, y disponible en Internet los riesgos son mayores. Esto es lo que hay que saber valorar.

A pesar de ello, los servicios en Cloud son la evolución lógica de hosting (infraestructuras compartidas de toda la vida). Todo lo que tuviera sentido en ese entorno ahora lo puede tener en la nube; en todo caso los proyectos que necesitan una grandísima escalabilidad normalmente están asociados a accesos desde Internet, en cuyo caso la nube tiene todo el sentido del mundo, ya que nos permite acceder a proveedores con grandes capacidades de almacenamiento, ancho de banda y servidores. Es más, me atrevería a apostar que los proveedores serios de Cloud sí tienen en mente que todos los recursos compartidos deben estar independizados, y probablemente sean más conscientes de estos riesgos que los provedores de hosting más tradicionales, con aproximaciones más «ligeras» al Cloud.

Dicho esto, pasen un buen fin de semana, y ¡¡nos vemos en la nube!!

Medidas de seguridad por Geolocalizacion de dirección IP

Aprovechando que se acerca el periodo estival en el cual es posible que decidamos realizar algún viaje, me gustaría comentar ciertas medidas de protección implantadas en diversos sistemas de login relacionados con la ubicación geográfica del usuario. Para empezar, comentar que existen BBDD de IPs que las relacionan con su posición física, de manera que puedes consultar dónde esta ubicada una dirección IP con bastante precisión, hasta el punto de que en el mejor de los casos es posible acertar con la población en la que te encuentras; en el peor de los casos, el acierto se limita al país.

Esto es aprovechado hoy en día por cada vez mas aplicaciones, como por ejemplo para ofrecer servicios específicos para la población en que te encuentras. Por ejemplo en mi caso Google hace publicidad ofreciéndome comercios y servicios por ejemplo de la ciudad de Valencia. Esta información se viene utilizando también de manera habitual para orientar, limitar y prohibir el acceso a los contenidos en función de la ubicación física de la persona. Un ejemplo de ello son las cadenas de televisión que emiten video por Internet, limitando dichos contenidos al país en el que tienen licencias para emitir ciertos contenidos (por ejemplo, eventos deportivos concretos). En España esto es utilizado por La Sexta o Telecinco en sus emisiones de TV Online, ya que no tienen licencias de emisión universales. Por supuesto, estas técnicas le quitan universalidad a Internet, pero eso un tema para otro día. Siguiendo con las prohibiciones (que es casi el uso más habitual), existen BBDD de direcciones IP para poder limitar por países enteros; en http://ip.ludost.net/ tenemos herramientas que permiten incorporar estos límites de países a las ACLs de Apache o iptables, lo que puede ser util si queremos interaccionar solo con un país. Como aspecto positivo, también se utiliza para mejorar la seguridad, en módulos de login o transacciones de compras, siendo una medida habitual en los módulos anti-fraude.

No obstante, como todas las tecnologías están sujetas a imprecisiones y problemas. Por ejemplo, pueden fallar si estás dentro de una WAN de tu organización y los proxys se encuentran en una ubicación remota, ya que los contenidos a los que podrás tener acceso no son aquellos que por tu geolocalización deberías tener. Esto pasa con proveedores de Internet globales como AOL, o por ejemplo, en multinacionales en las que la salida a Internet pueda estar centralizada en una ubicación, a pesar de disponer de sedes repartidas por todo el globo (por ejemplo, la salida a Internet de Ford Motor Company puede estar en Estados Unidos, aunque disponga de fábricas por todo el mundo). Otro punto de fallo es la navegación por dispositivos móviles, ya que también está sujeta a cómo tu operador gestione el tráfico a Internet, o cuando hagas roaming, si estas en modo WiFi, conexiones por satélite, etc. Por último, los proxys de navegación como el diseñado por Opera para acelerar las conexiones a Internet, sufren este problema que pueden resultar en quebraderos y falsos positivos con las consiguientes inconveniencias para los usuarios.

A pesar de todo, el aspecto más positivo de este tipo de información es su utilización para evitar el fraude, de una manera muy sencilla. Por ejemplo, es posible comparar si la ubicación habitual de nuestro cliente y su ubicación actual son cercanas o han variado en miles de km, podemos ver si existen accesos simultáneos a servicios desde ubicaciones separadas miles de km, o analizar si el histórico de conexiones de nuestro cliente cumple cierto patrón. Esto genera contramedidas que ya han sido aplicadas por algunos proveedores de servicios. Por ejemplo, si Facebook detecta que alguien se está conectando desde una ubicación remota desde el móvil, puede cortar el acceso solicitando una conexión desde el PC habitual, o solicitar una serie de datos adicionales (fecha de nacimiento y otras) para su verificación. Por otra parte, Paypal, uno de los mayores objetivos de fraude, si detecta compras desde ubicaciones no habituales del usuario y con entrega en éstas, puede decidir bloquear la cuenta (a quien le pasó esto aún no se si ha podido restablecer la cuenta).

Todas estas medidas están diseñadas para proteger al usuario ante los problemas de fraude, normalmente cuando hay transacciones bancarias, compras de productos, u otros temas sensibles. Desgraciadamente, como todo, tienen su parte de molestia, ya que es probable que si se encuentra en Shangai de vacaciones, puede resultar que su banco no le quiera, Facebook no se fíe de usted y no pueda realizar compras mediante Paypal. En ese caso, lo mejor es dejar el portátil o Smartphone y disfrutar de las vacaciones. La tecnología seguirá ahí a su vuelta.

False friends

Siguiendo con la entrada sobre la inseguridad de sentirse seguro, me gustaría ahora describirles 3 tecnologías de uso habitual que dan una falsa sensación de seguridad:

Antivirus: Siempre que le explico a algún no especialista que es un antivirus, le explico que no es un «antivirus». Es muy sencillo; un antivirus es la forma abreviada (o comercial) de decir que es un antivirus de virus conocidos. Sí, existen módulos heurísticos y otras historias de ciencia ficción, pero la realidad es que los virus nuevos no son detectados por los antivirus hasta que son conocidos. Esto implica que si tenemos la mala suerte de toparnos con un virus de relativa novedad no conocido por nuestro antivirus, éste será de poca utilidad. Obviamente, aunque el antivirus que utilizamos lo reconozca, si el nuestro no se encuentra actualizado, la consecuencia es la misma, de ahí la importancia de actualizar las firmas del AV.

IDS de red: Los IDS tienen el mismo problema que los antivirus: son «IDSs de patrones conocidos», pero son mucho peores que los AV ya que por lo general no toman medidas inmediatas, sino que se limitan a registrar e informar. Además, existen numerosas ocasiones en las que están «ciegos», como por ejemplo en el tráfico cifrado en el que funcionan todas nuestras web corporativas importantes. Además únicamente registran intrusos en base a patrones «técnicos», pero no a nivel de «negocio», de modo que alguien puede estar haciendo transferencias bancarias de forma masiva, y el IDS sólo vera un usuario utilizando la aplicación de transferencias.

Los auditores de vulnerabilidades (Nessus / OpenVAS / etc): Volvemos a lo mismo. No podemos estar tranquilos con haber pasado un scanner de vulnerabilidades y ver que todo queda corregido, dado que éstos únicamente lo son de vulnerabilidades conocidas y en su gran mayoría de software conocido, por lo que todos los desarrollos adhoc pueden ser completamente vulnerables a ataques de todo tipo y pasar inadvertidos. Es cierto que en este campo las herramientas están evolucionando y cada vez son mas capaces de analizar desarrollos desconocidos, pero cualquier auditoria automática de este tipo debería incluir un disclaimer en el que se indique que la herramienta sólo comprueba vulnerabilidades en versiones y configuraciones de programas conocidos, por lo que no incluye la detección de problemas en desarrollos propios, programas no conocidos o partes no públicas que pueden ser facilmente explotables por usuarios maliciosos. De aquí la necesidad e importancia de que una auditoría de este tipo sea complementada con auditorías manuales, tanto de los desarrollos a nivel de código, como a nivel de interacción con el usuario final.

Dicho esto, ¿cómo actuar en estos casos? El planteamiento es muy sencillo: se debe trabajar con el supuesto de que las herramientas no existen:

Antivirus: Debemos actuar como si no se dispusiera de antivirus. En un entorno de oficina, por ejemplo, no ejecutar programas de los que no se conozca el origen, limitar la ejecución de binarios y código externo, eliminar los ejecutables que llegan por correo electrónico, restringir la descarga de ejecutables a través del proxy web, y deshabilitar el acceso a programas en unidades CD/USB.

Detección de intrusos de red: Al IDS de red le pasan desapercibidas muchas cosas, y potencialmente puede generar un gran número de falsos positivos. No obstante, si conoce su negocio y sus aplicaciones seguro que sabe dónde mirar para detectar cosas extrañas; trate de añadir IDS de host, o integrados dentro de la lógica del negocio, ya que serán mucho más efectivos. Y por supuesto no los utilice como excusa para no tener en perfecto estado de revista la seguridad de sus servidores.

Auditorías de vulnerabilidades: Como se ha comentado, no es suficiente con los análisis que se limitan a los datos de la caja negra. Debemos revisar de manera no exclusivamente automática las actualizaciones de versiones de los programas, su funcionamiento cuando interactúan con el usuario, la configuración de las aplicaciones con respecto a la seguridad (usando guías de buenas practicas, o mediante el análisis de todas sus funcionalidades), y por supuesto controlar el desarrollo desde su orígenes, incluyendo la seguridad en todo el ciclo. La idea es que el hecho de que la herramienta de auditoría que utilizamos no haya encontrado un problema de seguridad no significa que no exista, e incluso puede estar más cerca de lo que pensamos.

Entonces, ¿dejamos de utilizar estas incompletas e imperfectas medidas de seguridad? Repasemos de nuevo los tres puntos:

Antivirus: Hoy en día, en ninguna cabeza cabe el no disponer de antivirus en cualquier entorno Windows, así que además de aplicar las prácticas seguras descritas previamente, hay que asegurarse de su correcta actualización de este, para que al menos esté al día de los virus conocidos. Es decir, que obviamente sí lo debemos de tener.

IDS: Mi opinion sobre los IDS (no compartida por muchos miembros de este blog) es que son bastante inútiles (esta entrada que va un poco en esa línea), y si no tienen funcionalidad automática de IPS sirven para muy poco (aunque eso puede generar otro tipo de problemas diferentes). En todo caso, la mayor utilidad que le veo a un IDS es la de detectar malware interno poco sofisticado, es decir intrusos internos, con lo que sí pueden ser positivos, aunque el objetivo debería ser que no llegaran dentro. También puede ser útil como herramienta de diagnóstico, para buscar algún patrón concreto en difusión amplia de malware. En definitiva, para ciertas finalidades contar con un IDS es sumamente interesante.

Auditor de vulnerabilidades: Aunque sean herramientas imperfectas, por su bajo coste de ejecución (se realiza de manera centralizada) pueden ser un primer paso para auditar una red. Aunque es verdad que cada vez son mas inteligentes y son mas capaces de auditar desarrollos genéricos (sqlmap es una maravilla), siguen siendo potencialmente peligrosas en cuanto a que la visión de auditoria de caja negra dista mucho de ser todo lo completa que la puede realizar un «humano» y puede generar una percepción de seguridad inexistente, además de ser infinitamente mas incompleta que una auditoria de caja blanca.

Como creo que era de esperar, usen todas ellas, pero tengan en cuenta siempre los disclaimers correspondientes y no se queden tranquilos con estos «false friends«. En una entrada posterior veremos qué pasa con las certificaciones: ¿»false friends«, o no?

En mi casa mando yo

En esta entrada me gustaría repasar algunas aproximaciones al respecto del concepto de Trusted Computing, y como lo lógico es empezar con la definición, por Computación Confiable nos solemos referir a sistemas completos e integrados hardware+software, en los que todo lo que se ejecuta se encuentra bajo el control del sistema y hay muy poca flexibilidad para la ejecución de otras cosas; enseguida veremos algunos ejemplos. Así pues, podría decirse que disponemos de una caja «blindada» que no puede en teoría ser manipulada ni por software ni por hardware, de modo que sólo realizará las funciones para las que esta diseñada siguiendo las directrices marcadas por el fabricante, sin que pueda ser manipulada o alterada.

Para evitar dichas manipulaciones el propio fabricante intenta proteger el sistema para que incluso el «propietario» del hardware (en el sentido de dueño del hierro) pueda utilizarlo para lo que guste. Este tipo de protecciones se usan de manera habitual para proporcionar contenidos con restricciones de uso (DRM), aplicar comisiones a los productos software, sistemas incopiables, etc. En algunos casos, los motivos aducidos serán razonables y en mi opinión otras veces abusos, la pregunta es: ¿Obedece el ordenador a su dueño? ¿U obedece a otra organizacion como Microsoft, Apple , Sony, Nokia, etc.? ¿Somos propietarios de nuestro propio hardware? ¿Quién manda en nuestra propia casa?

Algunos de nuestros lectores estarán ya pensando que que no son usuarios de este tipo de sistemas, pero la realidad es que existen muchos dispositivos de uso cotidiano que se han diseñado con esa filosofía. Vamos a ver algunos aparatos que, en muchos casos sin ninguna razón coherente, hacen «lo que ellos quieren» y no lo que quiere el dueño del «aparato»; son nuestros, pero no del todo, ya que obedecen a sus fabricantes (y a menudo en un sentido literal si existe algún tipo de conexión remota a los dispositivos).

Empecemos por las consolas de videojuegos. En todos los casos estos dispositivos están diseñados para poder ejecutar sólo un software determinado firmado digitalmente, lo que les protege de ejecutar copias de juegos, pero también impide la ejecución de software propio como Linux, o juegos sin pagar comisión. Como veremos, Internet es muy amplia y este tipo de protecciones no suelen durar demasiado tiempo, a pesar del tiempo y recursos utilizados por los fabricantes para diseñarlas (también es cierto que las modificaciones no llegan al gran público, por lo que el objetivo que se persigue con la protección se alcanza). Veamos:

  • Xbox: Estos sistemas han sido vulnerados tanto por software mediante el uso de exploits, como por hacks hardware (los famosos modchips).
  • Playstation 2: También reventado por hardware mediante modchips.
  • Playstation 3: Les ha costado pero tras 3 años, parece que ya ha sido vulnerada.
  • Wii: Vulnerado tanto por software como por hardware.
  • PSP: Vulnerado tanto por software como por hardware (pandora battery).

En estos casos podríamos comentar que al desproteger el aparato se puede usar para ejecutar copias de juego, algo de moralidad cuestionable, pero también te permite ejecutar tus propios programas «hechos en casa» (homebrew) lo cual parece razonable en un aparato que has pagado y que no entra en conflicto con los intereses del fabricante que te lo vendió. Al respecto, hay ya varias sentencias que determinan la legalidad de estas modificaciones por hardware [ElPaís.com, sentencia completa en Bufet Almeida]aludiendo precisamente a la posibilidad de ejecutar programas como Linux.

En segundo lugar, están los teléfonos móviles, que cada vez son más inteligentes. En este caso, solo aplicaciones firmadas y que hayan pagado la correspondiente licencia pueden ejecutarse en estos dispositivos. En teoría, ademas se revisa que estas aplicaciones no sean dañinas para la estabilidad del teléfono, o incluso para la estabilidad de las redes de telefonía móvil (seguridad por lo tanto bastante cuestionable, si no es por la propia seguridad del protocolo, sino por el acceso a uno de los extremos). Las principales plataformas han sido manipuladas, como se muestra a continuación.

  • Symbian: Solo el código firmado se puede ejecutar, si bien han aparecido diversos métodos para saltarse esas limitaciones.
  • Iphone: Solo el codigo firmado y descargado de la Apple Store se puede ejecutar, también son ampliamente conocidas los hacks para poder ejecutar cualquier aplicación.
  • Android: Incluso los moviles con Android por defecto no te dejan ser root (hay que hacer algunas triquiñuelas para serlo).

Por último, en la categoría de «Otros» existen multitud de dispositivos que entran dentro de este tipo de hardware. Veamos los ejemplos más relevantes:

  • Ipad: Tal como lo describe la Free Software Fundation es un gran paso atrás en la historia de la computación ya que sólo permite ejecutar el código autorizado por Apple, siendo además difícil incluso acceder a los contenidos archivados en el propio aparato.
  • Subsistema de video de ordenadores HDMI: Los cables HDMI de los equipos informáticos o televisiones disponen de sus protocolos de DRM, con lo que pueden establecer la resolución de la imagen dependiendo de las características del otro lado, o incluso no sacar señal si así lo deciden. Conecten un cable HDMI a su portátil, prueben a reproducir diversos contenidos con DRM y verán la pesadilla.
  • Routers, dispositivos domesticos (NAS): numerosos aparatos domésticos están diseñados para que nadie pueda modificar, mejorar o tener pleno control de los aparatos.
  • SmartCards, tarjetas de crédito EMV (tarjetas chip), DNI digital: Estos dispositivos aprovechan las funcionalidades de un pequeño sistema informático incrustado en la tarjeta, que tiene su procesador y su memoria, y que es muy robusto tanto desde el punto de vista del software como desde el punto de vista del hardware; al respecto, son sistemas muy difícilmente atacables en comparación con el resto de dispositivos comentados, lo que permite que la tarjeta proteja la clave privada con un PIN, y de ninguna manera la extraiga sino que solo opere con ella en su interior. Podríamos decir que se trata de un sistema confiable y que debe de ser así por la propia funcionalidad que el aparato ofrece, que protege al usuario ante un tercero que robe el propio aparato, y en principio no está a las ordenes de ninguna otra organización. En general estos sistemas no son vulnerados, quizá porque aun no están suficientemente extendidos. Debe destacarse que otros sistemas basados en tarjetas inteligentes como las de suscripciones de TV de pago si que han sido vulnerados, por lo que no seria de extrañar que también aparecieran exploits para estos sistemas.
  • Decodificadores de televisión de pago: Normalmente los decodificadores incluyen una tarjeta criptográfica (que en sí mismo es un dispositivo de Computación confiable), que es el que se encarga de recibir las claves de los contenidos desde el proveedor y decodificar o no los contenidos. Al ser tarjetas criptográficas, no son fácilmente atacables debido a que además protegen un activo muy valorado economicamente. A pesar de ello, estos sistemas han sido vulnerados en repetidas ocasiones, pero en la actualidad los sistemas actuales de TV de pago están protegidos por un sistema denominado Nagra3 que parece que es resistente a los ataques.
  • Trusted Platform Modules: Los equipos TPM son equipos PC que han sido adaptados para que funcionen de manera «Trusted» (Confiable/Controlada), integran procesadores criptográficos y dan una solución global (cifrado de disco, hardware, etc.). Con estos equipos se pueden diseñar sistemas que sólo ejecuten tu versión de Linux y los paquetes determinados, así como otros sistemas operativos. La solución en principio se ha diseñado para que sea robusta, sin embargo ha sido recientemente vulnerada. En torno a estos sistemas TPM y sobre todo para módulos criptográficos, en los que se quiere certificar su robustez desde el punto de vista lógico pero también desde el punto de vista fisico, existen certificaciones como FIPS que se centran en ello, como por ejemplo este pendrive.

Por último, y como precursor de todos estos artilugios, me gustaría comentar el artilugio de la edad media (popular tras la pelicula del código Davinci) Criptex, un aparato capaz de almacenar un pergamino, pero con vinagre de manera que si no introduces el código correcto destruye el pergamino. Para que vean que la idea de tener una máquina que tome sus propias decisiones en contra de quien la posee viene de muy lejos.

Todos los sistemas comentado se encuentran con los siguientes problemas:

  • El software es atacable: Mediante todos los métodos que se os ocurran (exploits, overflows, etc.).
  • El hardware es atacable: Se puede modificar el hardware añadiendo circuiteria (los famosos modchips que les comentaba). En el caso de las tarjetas las cosas se complican, aunque existen diversos ataques basados en modificar el voltaje, medir consumos para realizar ingeniería inversa, técnicas con microscopios electrónicos, limpiar con ácido los circuitos y otros muchos métodos de los cuales no soy ningún experto.

Como hemos podido ver, todos los intentos por parte de la industria de disponer de sistemas que no obedezcan al usuario en algún momento han fracasado, por lo que hemos de plantearnos varias cosas (aspectos que también y con mayor interés deberían plantearse los fabricantes de estos dispositivos),

  • Primero, desde el punto de vista de la ingeniería, ingeniería del software y evolución técnica de la sociedad no debemos permitir que se impongan limitaciones artificiales sobre el software que se puede ejecutar en cada aparato. Sin duda alguna si el software y el hardware no hubieran funcionado como sistemas interoperables, la sociedad no habría avanzado todo lo que ha avanzado; es necesario por tanto impedir que los sistemas en su conjunto estén controlados por corporaciones.
  • Desde el punto de vista de los usuarios, a nivel empresarial debemos de estar atentos a las limitaciones impuestas a nuestros aparatos/sistemas, cuáles son razonables y cuáles son excesivas.
  • Desde el punto de vista de los desarrolladores de soluciones tecnológicas de este tipo, visto lo visto, hay que tener en cuenta que tarde o temprano si hay suficiente interés este tipo de sistemas serán vulnerados, y se debe de estar preparado para ese momento.

Este post me gustaría dedicarlo a Alan Turing (23 Junio 1912 – 7 Junio 1954) por inventar una máquina de propósito general, y al mismo tiempo no dedicarlo al resto de la industria por desear hacer todo lo contrario.