Un pequeño lugar donde compartir, aprender y divertirse.

Cuando las cosas no van demasiado bien para Apple hay que renovar alguna de sus gamas. Si hace unos meses expresaba mi tremenda disconformidad con la política de renovación de Apple, esta vez no es menos. Y es que el problema es el mismo, Apple hace constantes renovaciones usando casi siempre una arquitectura antigua. Solo hay que ver que sus MacBook aun los vende con Core 2 Duo, cuando dentro de un mes o dos aparecerá la arquitectura SandyBridge, es decir, una tecnología 4 años superior. Estamos a punto de sufrir otro cambio de arquitectura y los MacBook no han pasado aun por la arquitectura actual Nehalem.

En el caso de los iMac es prácticamente lo mismo. A finales de 2009 Apple anunciaba la actualización de sus iMac, y aun cuando la arquitectura Nehalem ya estaba más que consolidada, tan solo permitió el uso de esta a los modelos de más alta gama, vendiendo entonces Core 2 Duo como opción preferente, cuando la arquitectura Core tenía por aquel entonces más de 3 años. Ahora, cuando la arquitectura Nehalem está a punto de ser sustituida por Sandy-Bridge, que debería de aparecer en un par de meses, Apple dice que actualiza sus iMac a arquitectura Nehalem. Esto es simple muy simple de comprender: Hay que sacar el máximo margen de beneficio de los fanboys. Cuando un usuario compraba hace una semana un iMac con Core 2 Duo (el 90% de ellos), estaba comprando tecnología de hace ya 4 años a precio de tecnología de dentro de otros 4.

Pero como he hecho otras veces, hay que poner sobre el papel cual es la supuesta gran oferta de Apple para sus iMac. Y esto es lo que nos dice:

iMac de 21,5” (Básico):

Pantalla: 21,5”
Procesador: Core i3 540
RAM: 4GB DDR3 1333 (2×2, en Doble canal)
Video: ATI Radeon 4670 256MB
HDD: 500GB
Raton+Teclado+MAC OS
——————————————

¿Precio? -> 1199€!!

iMac de 21,5” /27” (Mejorado):

Pantalla: 21,5′ /27”’
Procesador: Core i3 550
RAM: 4GB DDR3 1333 (2×2, en Doble canal)
Video: ATI Radeon 5670 512MB
HDD: 1TB
Raton+Teclado+MAC OS
——————————————

¿Precio? -> 1499€!! Para el modelo de 21.5”
¿Precio? -> 1699€!! Para el modelo de 27.5”

iMac de 27” (Mejorado):

Pantalla: 27”
Procesador: Core i5 760
RAM: 4GB DDR3 1333 (2×2, en Doble canal)
Video: ATI Radeon 5670 1GB
HDD: 1TB
Raton+Teclado+MAC OS
——————————————

¿Precio? -> 1999€!!

iMac de 27” (Re-Mejorado):

Pantalla: 27”
Procesador: Core i7 870
RAM: 16GB DDR3 1333 (4×4, en Doble canal) /Para comparar, lo ajustamos a 12GB, lo cual es un módulo de 4GB menos, lo cual son -270€, que es lo que cobra Apple por un módulo de 4GB
Video: ATI Radeon 5770 1GB
HDD: 1TB
Raton+Teclado+MAC OS
——————————————

¿Precio? -> 3214€!!(-270€) = 2944€

Un equipo mío (Con 1 año de antigüedad):

Pantalla: Sistema Multimonitor, 2 pantallas de 21”
Procesador: Core i7 920
Placa: Asus P6T V2 Deluxe
RAM: 12GB (6x2GB, en Triple canal)
Video: nVidia Geforce 460 (Adquisición reciente)
HDD: 2x 500GB RAID0 + 2x 200GB RAID0
Raton+Teclado+Windows 7 x64 Ultimate +WebCam+BT…

—————————————-

¿Precio? -> 1300€ aproximadamente.

———————————————————————————————————————————

Vamos a comentar algunos puntos, tanto positivos como negativos. He puesto en la lista también un PC que básicamente es ahora mismo el equipo del que dispongo para todo. Por qué? Más que nada para mostrar realmente lo que es un equipo que podemos llamar más o menos de última generación a uno que te cobran infinitamente más y te lo venden como lo último de lo último. Y recordemos que el mío tiene ya un año.

Por un lado hay que agradecer a Apple que por fin quiera vender RAM DDR3 a 1333, le ha costado lo suyo, dado que para cualquier otro MAC aun lleva DDR3 1066, que para el caso es mejor usar DDR2. Por otro lado hay que “agradecer” a Apple que por fin haya decidido deshacerse de la arquitectura Core… eso sí, un par de mese antes de que la arquitectura actual Nehalem vaya a ser sustituida. Fin de los puntos positivos.

Vamos a ver cada una de las características por separado, a analizar el hardware de los nuevos iMac:

Procesador

Quizás sea el punto más cambiante de todos, el resto dl hardware es muy similar. Tenemos 2 Core i3, un Core i5, un Core i7 y comparándotolo todo ello con mi Core i7 920. Primero hay que tener en cuenta que anteriormente podíamos comparar Core 2 Duo Vs Core i porque Apple quería seguir exprimiendo el uso de Core 2 Duo. Ahora que solo tenemos Core i, hay que comparar estos entre ellos. Esto quiere decir que no digo que un Core i3 sea en absoluto malo, sino que a lo mejor no podrá ser comparable a un Core i7, que es diferente. Dicho esto continuamos.

Sinceramente me parece ridículo que Apple emplee por defecto una configuración con Core i3 en vez de Core i5. La única explicación que tiene es aparentar que tiene un precio “competitivo”. Lo cierto es que los Core i3 son los procesadores Nehalem de gama baja. Es decir, por defecto cualquier iMac de 21” actual podeos decir que es un PC de gama baja atendiendo simplemente a su procesador. Pero aun así hay más trampa. Apple te ofrece actualizar un Core i3 a Core i5, pero el paso que da, de un Core i3 540 a un Core i5 680, la única diferencia apreciable que hay es que el reloj en el Core i5 es ligeramente superior y que soporta instrucciones AES. Es decir, que Apple te quiere cobrar en caso de querer ampliarlo 180€ por algo que no vas a notar.

Pero la cosa se pone aun mejor. Apple tan solo permite el acceso a un Core i5 decente en la gama alta, con un precio mínimo de 1999€!! Lo gracioso aquí no es la diferencia entre ambos procesadores, sino lo que tienes que pagar por ello. El problema que tiene el Core i5, ese que viene con el iMac de 2000€ es que es cierto que es un procesador de 4 nucleos, pero NO TIENE Hyperthreading (HT)!! Esta tecnolgoía permite insertar dos hilos por procesador físico, haciendo con ello que el procesador pueda ganar incluso más de un 50% de rendimiento en algunas circunstancias. Lo sangrante del caso es que en el mercado, la diferencia de precio de uno a otro en realidad no es mucha, tan solo 70€, que si tengo que construir un PC con uno u otro procesador (de los dos especificados) evidentemente pongo el Core i7. Pero para Apple no, para Apple la modificación del procesador no son 70€, sino 180€

No obstante también he añadido el procesador mío, un Core i7 920. Pues bien, este procesador es actualmente Más barato que el Core i7 montado por Apple, el Core i7 870. Si bien es cierto que este último tiene un reloj ligeramente superior, 2.93 frente a 2.66, actualmente los Core i7 serie 900 continúan siendo la joya de la corana de Intel por dos razones. La primera se llama Interfaz de Memoria de triple canal, y la segunda Bus de sistema QPI. Esto se explica muy fácilmente. Disponer la memoria en doble canal o triple canal ya lo comentamos en otro artículo, pero resumiendo mucho, la diferencia es que el ancho de memoria que puede manejar mi procesador es cuanto menos brutal en comparación al que puede manejar el Core i7 serie 800. Esto se resume en que aplicaciones que requieran acceso a grandes cantidades de RAM, la diferencia es abismal. Esto puede verse en cualquier test que se quiera por internet, misteriosamente se comprobará que arriba del todo está toda la serie de Intel Core i7 900. Y que es eso del bus de sistema QPI? El procesador tiene que acceder a la memoria para tomar de ella los datos y/o instrucciones. Como se envía la información de un lado a otro? Por un Bus de datos, en este caso por el BUS de datos entre el procesador y la memoria principal, el cual se llama Bus del sistema. Intel actualmente usa dos Bus distintos. Uno llamado DMI y otro llamado QPI. Pues bien, QPI en su versión más simple dobla en velocidad al Bus DMI. ¿Como es esto de importante? Volvemos a lo mismo, si se requiere mover grandes cantidades de datos de un lado a otro, un Bus rápido es indispensable. Anteriormente a Nehalem, Intel usaba el conocido FrontSideBus que era sensiblemente más lento que DMI.

Pues bien, estas dos cosillas hacen que aplicaciones que requieren mover normalmente una cantidad considerable de datos, sean muchísimo más rápidas. Algunos puristas dicen que QPI como el triple canal tan solo sería aprovechado en servidores y otros sistemas que requieran de accesos muy continuos a bases de datos y demás, pero desde mi experiencia puedo asegurar que es bastante notable la sensación de ligereza a la hora de usar la RAM del sistema, sobre todo aplicaciones que la requieren como sistemas virtuales tipo vmware, aplicaciones de diseño como 3d Studio, Photoshop, Maya, Premiere…

Evidentemente actualmente los Core i7 920 no son ni mucho menos lo mejor que hay en procesadores, tenemos por ejemplo el Core i7 970 con 6 nucleos físicos y HT, lo que hace que tenga 12 procesadores lógicos. También es cierto que el precio es algo más alto, aunque os aseguro que por el precio del iMAC anterior, por los casi 3000€ que cuesta, puedes permitirte perfectamente dicho procesador, y aun te estarías ahorrando bastante dinero.

RAM

Volvemos al tema polémico. Actualmente lo mejor que tenemos es DDR3 y triple canal. Ya hemos hablado del triple canal y de DDR3. Actualmente tan solo los procesadores de Intel Core i7 900 permiten triple canal, cosa que ningún procesador de AMD siquiera posee. Bueno, el tema de la memoria es el de siempre. Cantidad y velocidad. La cantidad tan solo debe de asociarse con la necesidad, no por tener más RAM el equipo es más rápido o puede ejecutar más cosas, solo depende del uso de nuestro equipo. Para algunos, tener 4GB es un derroche, para otros tener menos de 12GB sería no poder trabajar. Lo ideal? Tener tan solo la que se necesita. Para un uso doméstico os puedo asegurar que cualquier equipo con 4GB tiene más que sobrado. No obstante, hay ocasiones en las que se requiere más. El caso de la RAM y Apple es algo que ya hemos hablado de largo. Apple te cobra por las ampliaciones de RAM el doble o el triple de lo que realmente cuesta esta. Por otro lado, no permita ninguna configuración en triple canal.

En mi caso concreto, tengo dispuesta la ram en módulos de 2GB DDR3, colocados en 6 slots, 2 agrupaciones de 3 (triple canal). 2GB por 6 unidades = 12GB DDR3 en triple canal. Son 12GB algo exajerado? volvemos a lo mismo, depende. Es cierto que gran parte del tiempo no estoy haciendo uso de esos 12GB de RAM, pero es igualmente cierto que cuando estoy trabajando tampoco es raro hacer uso de la gran mayoría de ellos. Por ejemplo, el ejemplo más clásico es el uso de entornos virtuales. Puedo tener operativos y funcionar simultáneamente con 3 sistemas operativos, mi Windows 7 como local, un Linux como invitado y un Windows XP por otro lado. Ahora bien, cada uno de esos sistemas operativos tiene su propio espacio de memoria RAM, si le asigno simplemente 2GB a cada uno de ellos, ya tengo 4GB invertidos solo en hacer andar las dos máquinas virtuales. Con al menos otros 2GB que esté empleando en ese momento mi OS local, ya serían mínimo 6GB. Si ahora requiero estar trabajando simultaneamente con programas de diseño, de gestión o lo que sea, quizás no llegue nunca a usar los 12, pero perfectamente puedo estar haciendo uso de 10GB de RAM. Cuando hablamos de estas cantidades, la velocidad a la que la RAM se lee y escribe  es crucial, no quiero tener 12GB de RAM y tener que esperar 2 días para poder mover datos de un lado a otro (en RAM). Es decir, para mi es necesario disponer de 12GB de RAM, de lo contrario alguna tarea no podría realizarla de manera simultanea.

Es por ello que es inaceptable completamente los precios tan absurdos que pone Apple a la RAM, completamente absurdo. Esta vez no he realizado el sobreprecio qeu introduce Apple por ella, pero vamos… más o menos el triple de lo que cuesta en realidad.

Video

Esto es algo que me ha llamado mucho la atención. Primero, ha sido el cambio de nVidiya hacia ATI, primer craso error por parte de Apple. El segundo es sustituir las anteriores por otras más o menos equivalentes. Vamos a ver, cambia una gráfica nVidia 9400 integrada por una ATI 4670, un adaptador gráfico que tiene casi 3 años de antiguedad. Esto, fuera de ser algo extraño es habitual por parte de Apple. ¿Por qué este cambio? Simplemente porque el adaptador de video ATI 4670 ya era usado por Apple en la gama “alta” de los iMac. Es decir, con este cambio Apple no tiene que gastarse ni un solo centavo más, las viejas las usa para los modelos de gama baja (los Core i3). El rendimiento de una ATI 4670 es en realidad muy similar al de nVidia 9400, lo que sucede es que creo que la RAM de la ATI no es compartida con el sistema, mientras que el adaptador nVidia 9400 es totalmente integrada. Es decir, haces un cambio que no afecta en rendimiento y SI en prestaciones, dado que si no es nVidia pierdes automáticamente una gran cantidad de funciones que de otro modo podrías tener, por ejemplo CUDA y Physics.

En los otros modelos el panorama no es mucho mejor. El adaptador ATI 4670 es una tarjeta de video de gama muy muy baja, en cambio la siguiente en la lista, ATI 5670 es algo ya más decente. Yo la equiparo a una nVidia 250 más o menos. Problema? De nuevo es ATI, no es nVidia. Para MAC OS, las tarjetas de video a fin de cuenta no se usan para nada prácticamente, el soporte gráfico que tiene es de pena. Pero si encima le quitas la posibilidad remota de poder usar CUDA, te quedas con algo que mejor lo formatees y le pongas Windows.

La mejor parte viene con la que añade a su gama más alta, la 5770. La tarjeta de video 5770 es básicamente la misma que la 5670 pero con el doble de memoria. El rendimiento es virtualmente el mismo. Eso sí, hay que dejar bien claro que se están usando tarjetas diferentes. Al menos si es cierto que en esta ocasión, si hay un cambio en cuanto a rendimiento notable en comparación con la “generación” anterior de iMac.

Si tenemos que compararla también con mi reciente adquisición… bueno, no es comparable, ni en rendimiento ni en precio. Actualmente FERMI (las tarjetas de video de nVidia de la serie 400) no tienen rival. Aun así repito lo mismo, lo interesante de nVidia no es ya que las tarjetas sean más rapidas o lo sean menos, que a fin de cuenta es tan facil como comprar la de gama alta o la de gama media. La diferencia son las prestacionese que nos brindan. Por ejemplo, con Fermi tenemos soporte completo para DX11, OpenGL 4.0, OpenCL, CUDA, Physic… por no hablar de la tecnología de nVidia 3D (para esos aficionados) que permite ver cualquier película, juego, aplicación en 3D si disponemos aunque sea de unas simples gafas bicolo (rojo/cian). Para mi el adaptador de video cada día que pasa se combierte más en un apoyo al resto del sistema, no solo para aplicaciones 3D puras. Por ejemplo, en Firefox 4.0 tenemos (tendremos, aun estamos en fase beta 3) soporte hardware tanto para videos como para imágenes, gráficos vectoriales, renderización de las propias Web… cuestiones por cierto que aun están a años luz en MAC OS.

HDD

Hay una interesante cuestión que nunca he terminado de comprender. La gran mayoría de las personas se empeñan siempre en comprar los mejores procesadores, los mejores adaptadores de video, cantidades innecesarias de RAM… y en el mismo afán se gastan millonadas en HDDs tipo Velociraptor que cuestan dos o tres veces más que un HDD “normal”. Señores, voy a hacer una revelación a aquellos que no lo sepan. El dispositivo más lento infinitamente en comparación con el resto del sistema es a día de hoy el HDD, el Disco duro, La memoria Secundaria… o como lo querais llamar. El HDD es lo que menos ha cambiado a lo largo de los años. Es efectivo? Muchísimo, en un pequeño disco tenemos cantidades de información tan ingentes como 1TB. Es lento? No sabéis hasta que punto. Y siendo el aspecto más lento de un sistema es además el aspecto que más se descuida. Quiere decir esto que es conveniente comprar esos HDD Velociraptor (o marca/modelo que sean)? Ni muchísimo menos. Quiere decir entonces que es factible hacer el uso de los nuevos discos de estado sólido llamados SSD? Ni muchísimo menos.

Actualmente tenemos dos dispositivos fundamentales de almacenamiento masivo de datos: Discos magnéticos (aka Discos Duros convencionales) y Memorias Flash (aka SSD). Sí, los SSD no son más que un compendio inteligente de chips de memoria Flash interconectados unos a otros y con accesos en paralelo formando desde el punto de vista lógico una memoria secundaria que ya no podemos llamar Hard Disk (Hard Disk Drive), sino que se le pone el nombre de Solid State Drive (O Unidad de estado Sólido). Palabrejas a un lado ¿Es mejor un SSD o un HDD? Aquí hay que especificar más. En teoría, un SSD es superior a un HDD, puesto que tiene unas características muy superiores: Fiabilidad (No son magnéticos), Tiempos de accesos (No se accede por medio de un cabezal y un motor que gira un dico, sino por señales eléctricas). Pero los SSD sufren de dos problemas fundamentales que hacen que a día de hoy no sean factibles a nivel de consumo: Durabilidad (Las memorias Flash tienen un ciclo de vida de lecturas/escrituras, tras ese ciclo de vida estas se degradan hasta que dejan de funcionar) y precio por GB de información. A día de hoy manejamos cantidades ingentes de información, un SSD no cumpliría las exigencias mínimas para la gran mayoría de usuarios. A todo esto se añade un problema adicional, y es que los tiempos de accesos a los SSD son mucho mejores siempre y cuando el SSD sea de calidad, sino, la velocidad de lectura/escritura puede ser peor que la de un HDD convencional.

Hecha esta pequeña comparación, queda más o menos claro que el uso de SSD actualmente no es viable. Quizás dentro de unos años todos usemos SSD, pero a día de hoy NO. Eso hace que nos tengamos que conformar con los buenos HDD de siempre. Ahora mismo prácticamente el 100% de todos los HDD tienen más o menos el mismo rendimiento dentro de sus categorías. Tenemos los HDD de 5400 rpm (suelen estar presente en los portátiles) los HDD de 7200rpm (suelen ser los estándares) y los velociraptors y otros que llegan hasta los 10400 rpm. En velocidad? Pues no lo se, unos 100MB/s mal contados, 150MB/s los HDD especiales de 10400rpm más o menos. Esto que puede parecer batante rapido es muy muy  lento. Para que nos hagamos una idea, mi sistema con DDR3 a 1333MHz en triple canal tendría una velocidad máxima de transferencia de 32GB/s, y no, no es una errata. Por un lado un HDD que tan solo puede leer a 100MB/s, mientras que la RAM podría leerse unas 320 veces más veloz. Por qué tarda un PC en encenderse? Por el HDD fundamentalmente, prácticamente el 100% de las esperas que tenemos que aguantar son por el HDD. No es todo evidentemente, en tareas que requieren de un proceso intensivo es la CPU la que trabaja, pero en el 90% del uso cotidiano de un PC, las esperas son por el HDD.

Como podemos mejorar esto? Estamos condenados? Hombre, por ahora si es cierto que estamos más o menos condenados, pero podemos hacer algunas cosas. En vez de tirar el dinero en coprar HDD sumamente caros de 10400rpm, es más efectivo, barato y rápido usar sistemas RAID0. No voy a entrar en detalle, eso quizás otro día. Digamos que dos HDD de 500GB en RAID0 equivalen a 1HDD de 1B que trabaja el doble de rapido tanto en lecturas como escrituras. El doble es un buen aumento de velocidad, y en los sistemas actuales creerme… un sistema RAID a día de hoy se nota en TODO.

Pues bien, Apple no debe de conocer este sistema, y ni siquiera brinda la opción de crearlo. Creo que tan solo para los servidores oferta la posibilidad. A nivel de usuario es tan facil como comprar dos HDD a poder ser iguales, instalarlos en el equipo en la interfaz adecuada, configurar la Bios y listo, a partir de ahí a todos los efectos el equipo no tiene dos HDD, tiene tan solo uno del doble de capacidad y el doble de rápido. Por la misma regla de trers, si se quiere se puede añadir a RAID0 más de dos discos, cada vez que se añade uno se multiplica por una unidad más. 2 HDD? x2 3 HDD? Velocidad y tamaño x3 y suma y sigue.

En mi caso tengo en uso 2 HDD antiguos la verdad, que por cierto será lo próximo que modifique con casi total seguridad. Son 2 HDD gemelos de 200GB cada uno, con más de 7 años de antiguedad, y creerme si os digo que el simple echo de que aun estén en funcionamiento dice mucho a favor de Seagate, con el uso tan intenso que han tenido y aun no me han fallado un solo día… aunque es cierto la velocidad de acceso a ellos es ya de prácticamente la mitad. Estos 2 HDD gemelos agrupados en RAID0 son los que actualmente uso para el OS principal y sin datos “importantes” mientras que los sustituyo, dejando los otros dos HDD gemelos de 500GB más actuales para el resto del sistema, tambien de nuevo en una agrupación RAID0. Simplemente por comprar dos HDD de la mitad de tamaño hacen que el sistema vuele en comparación con el sistema anterior. Una pena para los equipos de Apple, muy bonito todo pero muy poco práctico, con un rendimiento nefasto.

Conclusión

En serio, hay que estar mal de la cabeza para gastarse en un PC hoy en día más de 1000€, a menos que se necesite algo concreto. Es decir, para el 90% de la población mundial, gastarse más de 1000€ es innecesario, os lo puedo asegurar. Por otro lado, para ese 10% restante, no hay ni un solo motivo por el cual podríamos decir que Apple merece la pena. Una vez más, ya no estamos entrando en si un OS es mejor que otro, hablamos de Hardware puro y duro, que es lo mismo que encontramos en cualquier lugar, sea de la marca que sea. Que si son solo una pantalla con todo, que si son de cristal y aluminio, que si… todo lo que tu quieras, y si quieres un equipo similar al mío (bastante inferior en algunos aspectos) tienes que pagar por él más del doble. En serio, me parece una broma de mal gusto que el precio resultante a la confniguración escogida sean casi 3000€. Pero más chiste me parece que un PC de 21” core i3 con las prestaciones que tiene cueste para Apple 1200€, es un chiste, de verda!! por la mitad de precio tengo un portátil bastante superior, eso sí, de 17” y no de 21, pero es un portatil. Con los 600€ que me ahorro tengo sobrado para comprarme si quiero un monitor que me guste.

De todos modos era de esperar que Apple renovase la gama de iMac, como he dicho dentro de un par de meses Sandy-Bridge estará con nosotros, y de no haber realizado este lanzamiento se daría el absurdo de que Apple estaría vendiendo productos 2 generacionese inferiores, es decir, 4-6 años de antiguedad. Lo que nos hace recordar que los Macbook aun usan Core 2 Duo. Esto lo dije en su día, y queda aun por ver que sucede. Fue en mayo si no recuerdo mal la última actualización (por decirlo de algún modo) de estos… o mucho me equivoco que antes de que acabe agosto Apple anuncia por todo lo alto que mejora los MacBook que ya supuestamente mejoró en Mayo para incluir los Core i, claro que entonces alegó en defensa que el uso de Core i repercutiría en la batería (cuando ya demostré que efectivamente, repercutiría pero para mejor). Espero no tener que venir dentro de un mes y poner un enlace estas palabras diciendo: Os lo dije!!

Un saludo y hasta la próxima, porque lo bueno que tiene Apple a fin de cuenta es que siempre hay una próxima que hacen aun peor que la anterior.

No es la primera vez que aparece en este blog los amigos de Secunia. Para quien no lo sepa, Secunia es una de las empresas más importantes (si no es la más) dedicadas por así decirlo a consultoría y/o auditoria en seguridad de software. Posiblemente posee la base de datos pública más extensa sobre vulnerabilidades de software. Cuando hablamos de vulnerabilidades de software (normalmente exploits), hay que tener en cuenta que son datos relativos, es decir, los datos que se tienen son siempre de las vulnerabilidades conocidas, no significa que no existan más, y esto es algo a tener muy en cuenta, ya que un buen software (en relación a la seguridad) no se puede medir únicamente por el número de vulnerabilidades, sino la penetración de él a nivel mundial. Esto es algo que este año Secunia a comenzado a tener en cuenta, a fin de cuenta encontrar un error en un programa que usan 10 personas es más fácil que encontrarlo en uno que tan solo usa una persona.

Para quien quiera el informe completo puede descargarlo desde el siguiente enlace:

Secunia Half Year Report 2010

Cuando hablas con un experto sobre seguridad informática, puede darte razones o explicarte por qué un sistema es más seguro que otro o que tecnologías son superiores. En cambio, y aquí lo hemos vivido alguna vez, el usuario medio no entiende de exploits, de ASLR, DEP, núcleos… ellos tan solo le dan a un botón para encender su equipo y viven en la creencia de que este es seguro. Y no es que no lo sean, algunos lo son de echo, otros lo son menos y otros… bueno, tiene que existir de todo. Lo que quiero decir, es que ese grupo de usuarios (que es el mayoritario) les vale más una tabla con resultados que todas las explicaciones del mundo. Y aquí es donde entra Secunia. Hoy no vamos a volver a explicar las diferentes medidas de seguridad o que software es mejor que otro y por qué. Simplemente quiero comentar los datos de Secunia.

Pues bien, nada más comenzar el informe, lo primero que nos enseña Secunia es el Top 10 de las empresas de software con más vulnerabilidades. Ya lo he dicho antes, pero lo voy a repetir, tener siempre en la cabeza presente cuales de esas empresas tienen mayor penetración en el mercado. Si se tiene esto en mente, los datos se interpretan de otro modo más realista, y si lo tenemos en cuenta, algunos datos que nos presenta Secunia son escalofriantes, ya que la siguiente imagen tan solo entiende de número de fallos de seguridad, no de uso:

Si los colores no se distinguen bien no importa, en la leyenda de la derecha están ordenadas las empresas por orden de ranking. Los resultados son cuanto menos interesantes. Apple no solo ostenta el peor puesto, sino que va de mal en peor. A esto hay que sumarle el echo irrefutable que de todas las compañías de software del top 10, Apple es además con mucha diferencia la que tiene menor penetración en el mercado!! Ojo!! En esta gráfica no se recogen sistemas operativos o software concreto, sino TODO el software de la compañía. De todos modos los nombres de las empresas del top 10 son de todo menos desconocidos, y de echo, quitando Adobe y Mozilla, el resto de empresas tienen su propio Sistema Operativo: Windows, MAC OS, Android/Chrome, Cisco IOS, VMware ESX…

Hace unos meses era un servidor quien hacía una comparativa similar, simplemente con carácter informativo basándome en los datos de Secunia. Pues bien, el informe de ellos básicamente destaca lo mismo.

1º. El puesto de honor como no podía ser de otro modo es para… Apple, y lo es en realidad desde más allá de año 2000 (no aparece en la gráfica) según Secunia. Y digo desde el 2000, porque como se puede ver en el informe original, en los datos de Oracle se sumaron también los datos de sus recientes adquisiciones: Sun y BEA, si las separamos, Apple reside en el puesto de honor desde el año 2000, superada tan solo por Microsoft como se puede apreciar en 2006. Entre el software de Apple encontramos sobre todo MAC OS, iPhone OS, iTunes y Safari como software más “importante” de ellos, que es en los cuales reside el grueso de las vulnerabilidades. El primer puesto es por tanto para la empresa con menos presencia de software de todas las que aparecen en la lista. (Aun saldrá Jobs diciendo que MAC OS es el OS más seguro, y le echará las culpas de nuevo a Adobe, como ya hizo tiempo atrás)

2º. En el segundo puesto tenemos a Oracle, un peso pesado. Si bien es cierto tenemos que ser un poco consecuentes con ellos, y se les ha sumado las vulnerabilidades no solo de estos, sino de sus recientes adquisiciones como por ejemplo Sun. Oracle es una de las empresas más fuertes de Software también, con una presencia enorme en el mercado, posiblemente, de las que más presencia tiene. No es por tanto demasiado incoherente verla en el puesto número dos. Software de Oracle? Pues quizás el que ha tenido mayor repercusión ha sido su software para bases de datos, entornos de programación como JDeveloper, entornos de ofimática como OpenOffice… y recientemente con la compra de Sun pues la lista se engrosa con MySQL por ejemplo o por supuesto JAVA. Es decir, no estamos hablando de una empresa que no sabe que es un software. El puesto número 2 es justificado? Bueno, no es “justo” si tenemos en cuenta el gran elenco de software que aporta Oracle y la penetración de este, pero los datos son los datos, y es la segunda peor empresa en cuanto a seguridad se refiere.

3º. Por increible que parezca a más de uno, Microsoft no solo no está en el puesto número uno, sino que se encuentra en el número tres. Bueno, posiblemente a día de hoy sea la empresa de software más fuerte del mundo, no por su variedad quizás, sino por su penetración en el mercado, lo que hace aun más impresionante su posición. Por penetración, Microsoft debería de estar con muchísima diferencia en el puesto número uno, en cambio no es así. Este echo constata el gran esfuerzo de la compañía de Redmond en cuestiones de seguridad. Esto es algo que he dicho muchas veces, pero parece que si no son con datos nadie te cree. No hace falta nombrar el Software de Microsoft, pero por si tenemos algún despistado podemos resumirlo fundamentalmente a: Windows, Office, Internet Explorer, SQL Server e Internet Informations Server (IIS). Recordemos que Windows tiene una penetración de más de un 90%, Office posiblemente de más de un 40%, IE un 40-60 según los últimos datos… y sobre SQL Server e IIS no tengo datos ahora mismo, pero son usados de manera bastante extensa. Y aun con todo ello tan solo ostenta un tercer puesto. Si separásemos Oracle, tendría un puesto aun inferior. y Apple aun quedaría la primera. De echo, a datos de 2005 se puede observar que MS ostentaba el puesto número cinco.

4º. Y quien no conoce HP? En realidad desde mi punto de vista los datos para HP son malos… si no tenemos en cuenta la reciente compra de Palms, softaware que ya se encuentra incluido bajo HP en dicha gráfica. HP se dedica principalmente a Software, pese que la gran mayoría los conoce más como OEM. Esto es debido a que las soluciones de HP son más empresariales que domésticas. Es por ello que los datos de HP son malos para mi, dado que no posee una penetración tan amplia como pueda tener Oracle o Microsoft, y en cambio está en el puesto número cuatro. De todos modos, el top 10 coincide más o menos con el top 10 de los mayores fabricantes de software, y por tanto estar en el puesto cuatro tampoco es una noticia demasiado mala. Software de HP? Bueno, quizás menos conocido para el usuario doméstico, pero tenemos desde el software de centros de datos (data centers), sofware de seguridad, de gestión, de control… y recientemente además se le debe de sumar al igual que a Oracle su última adquisición: Palm, lo cual explica un cuarto puesto, y entre su software sobr todo destacar Palm OS/WebOS

5º. Adobe System, otra de esas empresas dedicadas por completo al mundo del software. Posiblemente uno de los puestos más equilibrados de todo el top 10, el que menos sorprende ni por bien ni por mal, y no porque esté en el ecuador de la lista. Pese las críticas y el intento por parte de Apple de boicotear Flash, el software de Adobe es por regla general bastante más seguro que el de Apple. Esto contrasta enormemente con las palabras de Jobs, al afirmar con toda la cara del mundo que “Cuando MAC OS falla es por culpa de Flash”, excusa que daba entre otras para justificar el motivo por el cual iPhone no tenía Flash. No obstante todo no es positivo para Adobe. Aunque es cierto que Adobe se centra tan solo en software, es cierto también que de todo su software el más “problemático” es aquel que interactua desde la red (como lo es siempre), y básicamente se encuentra en el puesto número cinco por su tecnología Flash o Acrobat. Esto tampoco podemos decir que sea malo del todo, si tenemos en cuenta que Flash tiene una penetración de un 99%!! Es decir, que le guste al señor Jobs o no, un quinto puesto para Adobe son más que buenas noticias para ellos (para adobe), puesto como se verá despúes, solo Safari es bastante más vulnerable e inseguro que Flash.

6º. IBM tenía que aparecer tarde o temprano, y lo hace en un buen puesto. IBM es otro de esos grandes pesos pesados, junto con Oracle y Microsoft conforman seguramente los 3 fabricantes de software más importantes del mundo. Enumerar el software de IBM es algo absurdo, es enorme. Desde sistemas operavicos como OS/2, pasando por software de gestión de todo tipo, software de ofimática, de administración, data centers… aunque es cierto que prácticamente el grueso es orientado a empresas. Es cierto que si podemos decir algo a favor de IBM es que siempre se han tomado en serio la seguridad, y un sexto puesto es todo un logro. Evidentemente no tiene la penetración como pueda tener Microsoft u Oracle, pero sinceramente no sale demasiado mal parada.

7º. Interesante puesto en la séptima posición, VMWare. En realidad, aun en séptima posición, ostenta un resultado nefasto. VMware es una empresa de software especializada en software de virtualización, el cual por cierto tiene una aceptación y versatilidad enorme!! En los últimos años la virtualización se ha convertido en algo incluso necesario y tremendamente útil. Hasta aquí bien, el problema es que carece de sentido que una empresa con software tan especializado y con una cartera “pequeña” de este, aparezca en el top 10. Evidentemente vmware posee una gran aceptación y penetración en el mundo de los servidores, pero aun así me parece un puesto bastante alto. Sinceramente me ha sorprendido, no sabía que poseía unos resultados tan “malos” en referencia a la seguridad. Entre su software posiblemente los más conocidos sean VMware Workstation o VMware EXS

8º. Como no podía ser de otra forma, antes o después tenía que aparecer Cisco. Este es un puesto esperado y que se comprenderá en la medida que lo explique. Cisco, para quien no lo sepa, es la empresa más importante a nivel mundial en infraestructuras de red. En realidad esto podría aparecer no tener una relación demasiado importante con el software, no obstante si la tiene y por partida doble. De todas las empresas que tenemos en el top 10, Cisco es la empresa más “lógica” que intentaría atacar un hacker. Esto puede no tener aun mucho sentido, pero si incluimos que el 90% de toda la infraestructura principal de Internet se apoya en hardware Cisco, esto cobra mayor sentido, y rematamos la cuestión si recordamos que los routers y otros dispositivos de hoy en día son prácticamente todos a fin de cuenta gobernados por un OS o una firmware… software a fin de cuentas. Es decir, la penetración de mercado de CISCO no se puede medir en “personas”, como pueda ocurrir con Windows por ejemplo, sino en dispositivos de red. Cisco tiene una presencia increíble a nivel mundial. Y por otro lado, aunque el software de CISCO sea super específico, es evidente que por su gran importancia un porcentaje enorme de esfuerzos recaen en asaltar Cisco IOS, el software de control de la mayoría de sus routers. Encontrar un fallo de seguridad en Cisco IOS puede implicar tambalear todo Internet. No hay que irse muy lejos, hace un año aproximadamente se detectó un fallo de seguridad en este, y la respuesta de Cisco no se hizo de esperar, lanzó una actualización masiva para solucioanr dicho error, y fue enviada con carácter urgente a todos los ISP y otros. Cisco como tal se dedica sobre todo a grandes corporaciones/empresas, no al usuario doméstico, para ello posee la conocida Linksys, propiedad de Cisco. Es por ello que en la lista, CISCO antes o después debía de aparecer, al igual que es evidente que por seguro que pueda ser Windows, siempre aparecerá en la lista.

9º. Google!! También era un candidato esperado en la lista, aunque un noveno puesto es un resultado excelente. Google se dedica a día de hoy a prácticamente TODO, y por supuesto al software. Es normal que haya subido algún puesto si tenemos en cuenta la aparición del navegador Chrome o Android, pero tampoco podemos olvidar sus servidores gws (Google Web Servers). Con el éxito de Google es evidente que también ha sido un caldo de cultivo para hackers, y ello implica también que se descubran más vulnerabilidades. Es decir, Google en noveno puesto es una buena noticia para todos, ya que podemos decir que hacen un buen trabajo.

10º. Para terminar, el último en el Top 10, y con último me refiero a la “empresa” más segura del top 10, Mozilla (Mozilla es una organización, ojo, no una empresa). Es evidente que como empresa de software más cercano al usuario (navegadores, gestores de correo…) tenía que aparecer en la lista, dado también la penetración y el éxito que ha tenido Firefox (Thunterbird ha tenido menos éxito, pero por la sencilla razón de que el usuario medio no suele usar gestores de correo). ¿Que podemos decir de Mozilla? Bueno, Firefox posee un ratio de vulnerabilidades algo superior a Safari e inferior a IE. Si ahora atendemos a que IE tiene una cuota de mercado de un 40-60, Firefox un 20-40 y Safari un 3-4%, podemos decir sin lugar a dudas que el trabajo realizado por Mozilla es excelente, y de nuevo Apple se lleva una manzana roja, no se comprende como un navegador con tan poca penetración y se le encuentren tantos fallos de seguridad. Es un poco lo que sucede con Windows Vs MAC OS, teniendo el primero una penetración infinitamente superior, y en cambio a efectos globales MAC OS tiene más vulnerabilidades!! esto desde mi punto de vista es cuanto menos sorprendente

No obstante, del informe de Secunia se pueden extraer más cuestiones interesantes, como es e echo de que la gran mayoría de las vulnerabilidades, esas que hacen que el equipo se vuelva más inseguro, no residen en el propio OS. Por ejemplo, en Windows, el 65% de los fallos de seguridad no residen en Windows en sí, sino en el software que los usuarios instalan sobre él, que es el que debe de ser debidamente parcheado. Esto es lógico. Vivimos una época en la que el software se renueva cada día para ofrecernos desde características más avanzadas a simplemente software más eficiente o adaptado al hardware moderno. Pero quizás el echo más trascendente es la Red. A día de hot prácticamente la totalidad del software permite conexiones a internet para actualizarse, verificar licencias, trabajar sobre la red… esto dota a los programas con una nueva ventana de posibilidades, el problema es en cambio que un fallo de seguridad en el programa puede dejar expuesto al equipo que lo está ejecutando. Es por ello que la principal fuente de ataque en un sistema operativo es el navegador web, dado que es el software directo con el que interacciona cualquier usuario para Internet:

Esta otra tabla refleja el mismo top 10, pero sobre software concreto de terceros, es decir no incluyen sistemas operativos. Tengo que decir que no estoy de acuerdo con los datos de esta tabla. Según esta, Firefox actualmente se encontraría instalado en un 56% de equipos, Chrome un 30% y Safari en un 15%. Bien, actualmente aunque Firefox tiene una cuota más que aceptable y Chrome también, Firefox no tiene una penetración de un 56%, Chrome ni de lejos llega al 30% y Safari más quisiera tener un 15%, al igual que iTunes no lo tiene instalado un 43% de equipos. Los datos de la penetración de Adobe son más reales la verdad, aunque Adobe AIR no llega al 41% ni en sueños. Hay que decir que estos datos proceden de una fuente específica de Secunia, lo cual si explica las tasas de share tan altas. Quitando eso, lo que si es una realidad es el número de boletines de seguridad de cada uno de ellos. En este caso, el que se lleva la peor parte es Firefox y despues Safari a muy poca distancia. De nuevo se debería de repetir lo mismo que en la tabla anterior, el software más usado debería de ser el que más vulnerabilidades presentase, y en cambio vemos de nuevo a Apple casi en cabeza de la lista, siendo Safari el navegador menos usado con mucha diferencia en el mercado.

Si es interesante destacar el tercer puesto y el séptimo. El tercer puesto lo ostenta el runtime de JAVA, que con un 89% de share es aceptable su tercera posición. El séptimo puesto es para Flash, y es destacable porque choca de nuevo de bruces con las palabras de Steve Jobs, cuando este decía que el problema de MAC OS era casi siempre Flash. Pues bien, quitando el echo del share de uno u otro, lo que es cierto es que Safari es en cuanto a seguridad se refiere infinitamente peor que Flash, y eso que Flash tiene una penetración casi dele 100%. Es evidente que una vulnerabilidad no es sinónimo a un mal funcionamiento, pero si pudiésemos medir esto, el resultado sería similar a todas las tablas mostradas. Por cierto, otra posición interesante es la de iTunes, y creo que es la más preocupante del top 10.

Los 10 programas de esta lista, tienen TODOS una interacción directa con internet. En la lista encontramos evidentemente y en los puestos superiores 3 navegadores, y en la cola un gestor de correo. Con esto son ya 4 piezas de software en los que su uso es casi exclusivo para Internet. Pero ademeás de estos 4 programas tenemso JRE y Flash, los dos complementos (addons) para los navegadores más importantes. Si bien estos pueden ser usados para otras aplicaciones, el 99% de su uso es directo con internet. Ya tenemos cubiertos 6 de 10. Por otor lado tenemso Adobe AIR y Acrobat/reader, que en realidad es el mismo software básicamente (una versión lite de la otra). Y por qué está Acrobat en la lista? Porque la lectura de PDF online se ha convertido en algo habitual, y los complementos para los navegadores para ello son igualmente comunes en estos. De las 10 piezas de software mostradas, iTunes es la única que no tiene una razón de ser directa con internet. Sí, iTunes lo usamos para comprar música o aplicaciones… pero no tiene una interacción directa con Internet, tan solo es un programa que requiere una conexión para poder conectar a los servidores de Apple. 48 boletines de seguridad para iTunes es simplemente algo sorprendente, cuando Internet Explorer que posee una penetración de un 99& tan solo tubo 49, y es un explorador web. De nuevo, la seguridad de Apple es cuanto menos inexistente.

Como muchos habrán visto, en dicha tabla NO aparece ningún producto de MS. No es que no estén, es que se han puesto en otra tabla. De todos modos, el tan criticado IE se situaría en dicha tabla en la posición 9.

Todo esto no significa que el software que usamos sea deficiente ni mucho menos. Es igual de importante la política de actualización de estos. De echo, algunos software como Firefox o Chrome, pese a tener un numero relativamente elevado de vulnerabilidades, las actualizaciones de estos son casi inmediatas, no se suele esperar a tener 10 vulnerabilidades para corregirlas. Esto quiere decir que cualquier usuario de Firefox o Chrome puede tener una seguridad bastante alta de que su navegador es seguro siempre. Microsoft con IE no es tan inmediato como los dos mencionados. Para MS a menos que sea un fallo crítico suele esperar a los boletines de seguridad que suelen poner en Windows Update cada dos jueves, aunque si es cierto que cuando la vulnerabilidad es grave al día siguiente tenemos el parche disponible en el Update. La peor parte de nuevo es para el software de Apple, la política que tiene de actualizaciones es nefasta. Apple tan solo suele parchear problemas de seguridad cada bastante tiempo. Es decir, si se descubre mañana un exploit que afecta a Safari y que permite un control total del equipo, Apple puede tardar perfectamente meses antes de parchear la vulnerabilidad, mientras que Firefox o Chrome lo tendrían parcheado el día después. Esto parece que no tiene importancia, pero cuando un fallo de seguridad se descubre y se hace público, es muy común que aparezcan exploits inmediatamente que los aprovechen. Existen numerosas bases de datos de estos que se actualizan continuamente, y si tu equipo no está actualizado, eres vulnerable.

Adobe por otro lado es cierto que tampoco se da toda la prisa del mundo, se toma las cosas con algo de calma, sin llegar a la inactuación de Apple. Adobe suele estudiar el caso, probarlo, reprobarlo… y entonces saca la actualización. Ante un fallo crítico Adobe respondería aproximadamente en unos 3-5 días. Sun (ahora Oracle) tendría una respuesta similar. De todos modos ambos tienen un excelente soporte de actualizaciones periódicas, y no está de más actualizar el software dele equipo cada mes o dos meses.

Conclusión? Bueno, los datos de Secunia son los datos de Secunia, con sus matizaciones, interpretaciones… pero están ahí. Que Apple disponga del software más vulnerable no es nuevo, para un hacker asaltar un MAC OS es infinitamente más sencillo que una plataforma Windows, o atacar a Safari mucho más simple que hacerlo contra Firefox o IE. Es por ello que aquí se demuestra que los mitos son mitos por algo. Que por mucho que muchos usuarios se empeñen en decir que MAC OS es más seguro, la realidad es bien distinta, no solo son más seguro, sino que son colistas en cuanto a seguridad se refiere.

Un hacker listillo ha logrado hackear el AppStore de Apple, realizando cambios en este y obteniendo posiblemente información de cientos/miles de usuarios. El efecto inmediato no se ha hecho de esperar, y misteriosamente los rankings de aplicaciones de este se han visto completamente modificados. Así por ejemplo, 40 de las 50 aplicaciones más valoradas eran todas referentes a libros y otros. Este fue el primer aviso de que algo no andaba bien en el AppStore, pero parece ser que era solo la punta del iceberg.

Si lo primero no es algo que a muchos pueda preocuparle, hay que decir que la información a la que dicho hacker (o grupo de ellos) ha tenido acceso tiene un valor incalculable, pero por si fuese poco, también se ha detectado un ataque masivo a cuentas de usuarios de iTunes, en las que se han detectado compras masivas de aplicaciones, canciones y todo tipo de contenidos desde estas. Muchos usuarios al abrir itunes se han llevado la “graciosa” sorpresa de ver como tenían cientos de descargas en cola y 2000€ descontados de su tarjeta de crédito (evidentemente, sin ser ellos los que habían realizado dichas compras).

Desde un punto de vista técnico, tiene más mérito el realizar el Hack a la AppStore que el robo de cientos/miles de cuentas, ya que al parecer el acceso a estas (al menos por ahora) parece venir de un SCAM. Esto lo hemos explicado tanto teóricamente como prácticamente que es, así que no voy a detallarlo ahora. Si es así, el hacker se habría aprovechado simplemente del desconocimiento o descuido de los usuarios para poder robarle dichas cuentas, lo cual no es un problema de seguridad directamente relacionado con Apple (aunque todas las medidas de seguridad son mejorables, sin llegar a ser un neurótico).

Lo interesante aquí sería el hack que han usado para colarse en el AppStore. Quizás un exploit sobre la misma plataforma habría sido el sistema más “fácil” para lograr hacerse con el control (total o parcial) del AppStore. Ataques más sofisticados podría haber sido un acceso directo a las bases de datos de Apple, lo cual evidenciaría aun más la seguridad por parte de Apple.

La realidad no obstante es que un número indeterminado de cuentas de iTunes han sido accedidas y se han realizado cuantiosas compras en este, y que por el otro lado el AppStore ha sido accedido sin autorización y se ha logrado (que se sepa) modificar algunos detalles de este (se desconoce el alcance del acceso).

Apple por supuesto aun no se ha pronunciado, y conociendo como los conocemos, posiblemente intente minimizar el problema, quizás que tan solo fueron unas cuantas de cuentas hackeadas y que el problema fue del usuario por hacer clic donde no debían (igual que el problema del iPhone 4 es del usuario por sostenerlo con la mano izquierda), o que el problema del AppStore ha sido un problema técnico de ellos. Me encanta la transparencia con la que Apple suele tratar sus cuestiones.

El problema no obstante es mayor. Cuando una empresa tiene un ataque de estas características e información de sus clientes queda expuesta, las empresas tienen que enfrentarse a organismos generalmente estatales de protección de datos para realizar una investigación para esclarecer el responsable del acceso de dichos datos, y generalmente siempre se acaba sancionando a la empresa. Lo cual por cierto me parece completamente necesario, sobre todo cualquier empresa que conserve datos sensibles (tarjetas de crédito, cuentas bancarias…) y haga uso además de nuestros datos con fines comerciales.

Como ya he dicho, la manzana podrida aun no se ha pronunciado, aunque posiblemente no vaya muy desencaminado con lo que he predicho. Ya veremos como queda la cosa.

Este tipo de sucesos por suerte para algunos y desgracia para otros están a la orden del día. Los que suelan leerme, comprenderán a lo mejor un poco más la importancia de las prácticas del usuario, de tomarse la seguridad informática como algo serio, los pros y los contras a la hora de seleccionar un OS o un navegador en cuanto a la seguridad. Son cuestiones en las que no sirve un mero: “Firefox es mejor porque sí”. No hay que ser neurótico, pero siempre tomar precauciones a la hora de navegar, de dar nuestros datos, de generar contraseñas, de proteger nuestras redes… y como he dicho, hace falta un OS y aplicaciones en este que sean seguras, lo uno no puede existir sin lo otro.

Lo primero tiene solución: La educación. Generalmente tan solo es tener una buena práctica. Una vez que se tiene una educación mínima en dicha materia

Lo segundo tiene solución: Actualmente el OS más seguro del mercado posiblemente sean algunas distros de Linux (aunque a la mayoría de las personas no les suele entusiasmar linux) y en segundo puesto muy de cerca Windows 7. MAC OS se queda en la cola. Pero al igual que el OS es importante, cualquier aplicación que se comunique en una red es igualmente importante: Navegadores, gestores de correo, programas de mensajería instantánea… aunque posiblemente por excelencia los programas más atacados son evidentemente los más usados -> Los navegadores. Y en este campo, una buena elección es igualmente importante. Actualmente por orden de seguridad: Firefox, Opera, Chrome, IE y Safari, aunque podría poner en un momento dado a Opera por delante de Firefox en cuanto a seguridad se refiere.

Esto que parece una tontería, si se combinan ambos aspectos, se podrá decir que nuestro sistema es seguro, que no impenetrable (no hay nada impenetrable en informática). Pero con esto, tener por seguro que el 99% de todo el malware que existe, el 99% de los exploits, el 99% de ataques de Pishing/SCAM… se pueden evitar. Y evitar el 99% es evitar mucho.

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

Protocolos ARP, IP, DNS y TCP/UDP

Internet como estructura básica está muy bien, pero es necesario así mismo una serie de protocolos que haga posible la comunicación entre distintos dispositivos interconectados por todo el mundo. Imaginemos dos personas, una en España y otra en Francia, una habla español y la otra francés. Para comunicarse hacen uso del teléfono ordinario, lo cual hace que puedan hablar de forma simultánea, en tiempo real y de forma eficaz. Pero si habla cada uno en un idioma diferente será imposible que se entiendan. Es decir, es necesario una serie de protocolos, de normas, de… para que todos entiendan correctamente todo. Vamos a tratar quizás los más importantes de ellos de cara a nosotros, no significa que no existan otros protocolos igualmente importantes o imprescindibles, pero estos son los que para nuestra tarea es importante conocer bien:

• IP
• DNS
• TCP/UDP
• Ethernet/ARP

Hay que tener presente que estos protocolos no nacen de la nada, nacen de la necesidad de crear comunicaciones fiables, que perduren en el tiempo, que sean eficaces y simples en la medida que sea posible. Comencemos entonces.

Protocolo IP

Las siglas IP provienen de “Internet Protocol” (Protocolo de Internet), no obstante esto puede ser confuso, dado que el término IP puede hacer referencia a la suite de protocolos IP que hacen posible el modelo TCP/IP, o incluso podemos referirnos muchas veces a IP para designar una “Dirección IP”. Pero detrás de todo ello, IP en sí no es más que un protocolo más que hace posible el modelo TCP/IP, aunque por supuesto pueda ser uno de los más importantes en todos ellos.

El objetivo del protocolo IP es poder entregar/recibir paquetes (recordemos que en el nivel 3 del modelo OSI, nivel de red, la unidad de información se denominaba paquete) a/desde diferentes orígenes y destinos, de modo que cada paquete tenga un origen y un destino claro. Dicho de otro modo, es el protocolo que indica el host al que se debe de enviar el paquete o el host que lo está enviando. Aunque la referencia más inmediata que solemos tener del protocolo IP es el aspecto de una dirección IP, no podemos olvidar como se hace esto posible o que significa eso que se conoce como dirección IP. Actualmente, existen dos especificaciones diferentes para el protocolo IP, aunque sería más correcto hablar de versiones diferentes. Una es la que aún se encuentra como uso mayoritario, posiblemente copando el 98% de todo Internet a día de hoy y conocida como IPv4. La segunda aun en expansión y de implantación muy lenta desde hace ya muchos años su sucesora, IPv6.

IPv4

Quizás la diferencia más señalada de estas dos versiones tiene relación directa con el espacio de direcciones que soporta cada una de estas. De este modo, el protocolo IPv4 permite tan solo direcciones IP de 32 bits, lo que quiere decir que aun si se pudiese asignar una a una todas las direcciones de forma independiente (aunque esto no funciona así), “tan solo” se tendrían disponibles un total de 4.294.967.296 direcciones diferentes. 4 Mil millones de direcciones pueden parecer suficientes si tenemos en cuenta que el planeta cuenta con una población aproximada de unos 6 mil millones de habitantes. No obstante el crecimiento de los dispositivos a la red ha tenido en los últimos años un aumento exponencial. Ni siquiera las tecnologías de traducción de direcciones como NAT, el uso por parte de los ISP de direcciones IP dinámicas o los espacios IP reservados para redes privadas son suficientes para evitar el agotamiento de direcciones IPv4, lo que ha producido que a día de hoy el espacio de direcciones IPv4 esté literalmente agotado. Si los datos son ciertos, y parece que lo son, a día de hoy la ICANN habría ya entregado el último paquete de direcciones IPv4, estando por tanto disponibles tan solo los paquetes de direcciones IP gestionados por los propios gobiernos regionales. Estamos en el año 2010, y parece que con toda seguridad en uno o dos años todo el espacio de direcciones esté completamente agotado.

¿Qué es una dirección IPv4?

Casi con toda seguridad, cualquier lector que pueda estar leyendo estas letras habrá visto alguna vez una dirección IPv4, la cual no es otra que un número dividido en 4 octetos. En realidad, la división de ese número de 32 bits en 4 octetos es meramente una cuestión de comodidad a la hora de poder trabajar con ellos, es por ello que no se suele usar la notación hexadecimal siquiera, la cual tendría más sentido dado que acortaría la dirección a la hora de recordarla y/o escribirla:

La representación clásica de estas direcciones es por tanto la separación de cada octeto con un punto: 192.168.0.1

Hemos dicho anteriormente que no era cierto que en un espacio de direcciones IP de 32 bits se pudiesen tener otorgar 2^32 direcciones diferentes. El sistema de dirección IPv4 reduce considerablemente este número debido a su propio funcionamiento, como por ejemplo direcciones reservadas, subredes, direcciones broadcast…

En realidad, una dirección IP no identifica tan solo el host origen/destino, sino también la subred a la que pertenece. Históricamente se utilizó la misma división de los octetos como divisiones entre redes y host, de este modo se podía usar el primer, segundo y tercer octeto para la identificación de las redes, y el segundo, tercero y cuarto octeto para la identificación de los host. De este modo por ejemplo, si pudiésemos disponer de todo el espacio IPv4 para nosotros podíamos utilizar tan solo el primer octeto para identificar una red concreta y el resto de los 3 octetos para identificar los host. Es decir, podríamos constituir un máximo de 256 redes diferentes, cada una de ella con 2^24 hosts. Recordemos que un octeto son 8 bits, 256 valores diferentes. Pero si lo que necesitásemos sería tener muchas redes y pocos host podríamos del mismo modo hacerlo al revés, tener 2^24 redes diferentes y cada una de ella con 256 hosts.

A día de hoy esta práctica es normal encontrarla en redes simples, pero esto no es en modo alguno una norma, y es posible usar el número de bits que se desee tanto para el número de las redes como el número de los hosts, es decir… podemos poner un punto de separación virtual en cualquier lugar de los 32 bits de una dirección IPv4. Es por ello que se requiere de un sistema o de algún identificador que diga que parte será la usada para una tarea y para la otra. Y es cuando aparece la “Máscara de subred”. Se llama máscara porque realmente lo que hace es enmascarar los bits que se usarán para cada tarea. Básicamente se realiza una operación AND lógica entre la dirección IP origen/destino y la máscara de subred. Aquellos bits que son cero serán los que identifican el host, y el resto estará indicando exactamente la subred. La única restricción es que los bits usados para una cosa o la otra deben ser consecutivos, no se pueden intercalar bits para ser usados como subred/host. Visto esto, supongamos que tenemos la misma IP ejemplo anterior:

11000000 10101000 00000000 00000001 -> Dirección IP binaria del host, correspondiente a su notación decimal: 192.168.0.1
11111111 11111111 11111111 00000000 -> Máscara de Subred, correspondiente a su notación decimal: 255.255.255.0
—————————————————- -> Operación Lógica AND
11000000 10101000 00000000 00000000 -> Red: 192.168.0 Host: .1 (192.168.0.1)

Otra forma común de expresar la máscara de subred es utilizando una barra inclinada después de la dirección IP especificando el número de bits que se han otorgado para la identificación de la subred. Por ejemplo, continuando con el ejemplo anterior:

IP: 192.168.0.1
Máscara: 255.255.255.0

Podríamos expresarlo como:

192.168.0.1/24 dado que en realidad son 24 bits los que han sido usados para la subred. En este caso el esquema coincidirá con la separación de la subred/host por los octetos, pero como hemos dicho, la máscara podría haber sido perfectamente 255.255.255.240.0 -> 192.168.0.1/20 lo que significaría que la parte de la red es identificada por 20 bits.

¿Por qué es tan importante tener configurado correctamente esta máscara? Los nodos de red como los routers necesitan conocer a quien enviar cada paquete. Para hacer esto el router tiene que mirar en sus tablas de rutado, de este modo puede identificar la subred al que pertenece el destino y enviárselo. Si la máscara de subred no es correcta, el router no dispondrá en sus tablas de rutado dicha red, y no podrá entregar el paquete.

Aunque cualquier sistema interno podría hacer uso cualesquiera del protocolo IP y de sus direcciones, este no es empleado de forma arbitraria. En teoría se podría usar cualquier máscara de subred para cualquier IP, pero la ICANN ya desde el principio (como máximo organismo que mantiene u otorga las IP) tiene perfectamente definido diferentes clases de IP y su finalidad. Podemos decir que todo el espacio de direcciones IP se encuentra perfectamente organizado en 5 diferentes clases:

Antes de explicar algunas peculiaridades de este sistema, se hace necesario hablar ya de IP Privada Vs IP Pública

Del esquema anterior se podría inferir que la ICANN podría asignar cualquier IP o rango de estas a cualquier entidad/organización/persona que desease, pero esto no es así. No solo ya de por sí podemos ver que algunos de los rangos mostrados ya de por sí se encuentran reservados para propósitos específicos (los cuales hablaremos más adelante) y que podemos llamar como IPs Reservadas. Pero aún hay más. Con el fin de poder expandir enormemente el número de dispositivos que pudiesen conectarse a la Red de Redes y con el fin de poder crear Redes sin necesidad de estar conectadas a Internet, surgió la necesidad de usar rangos IP reservados exclusivamente para el uso privado. A estas IPs son las que conocemos como IPs Privadas. Es evidente que por el otro lado tendríamos lo que llamamos IPs Públicas. Al contrario de los rangos IP públicas, las IPs privadas y reservadas son usadas de forma simultánea en todas partes del mundo sin constituir esto un problema, ya que dichas IPs se usan tan solo dentro del marco de una Red Privada. Dicho de otro modo, cada usuario puede si desea hacer uso de los rangos de IP Privada para crear la red que mejor se ajuste a sus necesidades. El caso de las IPs reservadas es un poco más peculiar, dado que su uso generalmente no está orientado a identificar un host concreto, sino más bien son usadas por otros servicios, los cuales como ya hemos dicho se tratará más adelante.

El uso de IPs privadas para la creación de una Red Privada es muy ventajoso, pero si se desea usar conectar dicha red privada a Internet es necesario un dispositivo (generalmente hardware) que pueda convertir de algún modo nuestras direcciones IP privadas en públicas. Y esto lo conocemos como Network Address Traslation (NAT) o traductor de direcciones de red.

Se estableció así los 3 rangos diferentes de IPs privadas dentro de todo el espacio IPv4. Es evidente que al estar reservadas estas para dicho fin, no podrán ser usados para otro. Cada rango cae dentro precisamente de cada una de las 3 clases de IP principales, de este modo cada usuario/empresa/organización puede usar aquellas que más se ajuste a sus necesidades.

Es muy común por tanto hablar tanto de IP privada como IP pública. Al contrario de lo que pueda pensarse, la IP privada es la que menos importancia podría tener nuestro sistema de puertas para fuera, dado que lo que realmente identifica nuestra red desde el exterior es nuestra IP pública. Son los dispositivos de red como los routers los que hacen posible el intercambio de información entre las redes privadas e Internet.

Vamos a explicar algunas cuestiones de las clasificaciones anterior a la par que vamos a aprovechar para añadir algunos términos más:

• IP Privada: Ya hemos hablado de ella, son rangos específicos dentro del espacio de direcciones, de uso exclusivamente propio, no tiene valor más allá de nuestra red.
• IP 0.0.0.0: Este será la primera IP reservada que nos encontremos. La IP 0.0.0.0 es digamos la IP comodín, es decir, hace referencia a cualquier IP, ya que es necesario en multitud de tareas poder usar una IP que signifique “Todas”. Pensar en cuando se desea aplicar una regla en un firewall para permitir todas las IPs, o denegar todas. La dirección 0.0.0.0 es ese “Todas”.
• IP 127.0.0.0: También se conoce como IP de retroalimentación, de Loopback, IP del propio host. Si la IP 0.0.0.0 hace referencia a Todas, la IP de Loopback hace referencia siempre a sí mismo. Es decir, para un equipo, sea cual sea la IP que tenga asignada él se podrá siempre identificar a sí mismo para tareas locales como 127.0.0.1. Esto es tremendamente útil, dado que no depende de la IP que pueda tener asignada para poder hacer uso de sus propios recursos de red.
• Enlace Local: Rango de IP usado tan solo en ámbitos locales por ciertos servicios, por ejemplo por APIPA, un sistema usado para configuración automática de IP cuando otros sistemas como DHCP no están disponibles.
• Test-NET-X: Son rangos reservados para ser usados en documentación y/o ejemplos didácticos, así como en código fuente ejemplo.
• 6TO4: Con la inminente salida de IPv6, se ha reservado un espacio por el cual podrá circular contenido IPv6 hacia direcciones IPv4 y viceversa. Esto es necesario dado que no se puede implementar un sistema que sea diferente de la noche a la mañana, y durante un tiempo (posiblemente largo) ambos estándares deberán de convivir uno con el otro, ya que el soporte hardware de los dispositivos personales, así como dispositivos de red, es completamente necesario. Este rango será usado para facilitar esta tarea.
• ID de Red: Si uno es cuidadoso y realiza las multiplicaciones por sí mismo, se dará cuenta que siempre desaparecen dos posibles direcciones que podrían usarse para hosts. Es decir, por ejemplo para el rango de clase C 192.168.10.0, decimos que tenemos disponibles un total de 254 hosts para dicha red. ¿De dónde sale este número? Dado que la máscara de Red es 255.255.255.0, tan solo podríamos tener un total de 256 hosts, el último octeto es el que estaría reservado para ello. Lo que sucede es que dos de ellas podemos decir que se encuentran reservadas. En el ejemplo puesto, la dirección IP 192.168.10.0 no podría ser usada jamás para identificar un hosts, dado que dicha dirección en dicho ejemplo sería la red misma, es decir el ID de red.
• Dirección de Broadcast: Continuando con el punto anterior, para la red 192.168.10.0 y la máscara de subred 255.255.255.0, existe otra dirección reservada conocida como dirección de broadcast. Esta dirección es muy importante, dado que es por así decirlo el canal de comunicación común de toda nuestra red. Esta dirección es siempre el último host de la red, en este caso sería 192.168.10.255. Pero que es ¿Broadcast?

  Existen diferentes modos de comunicación entre diferentes dispositivos. Quizás el método más simple sería aquel en el que un host mantiene una comunicación directa con otro hosts. En este caso hablaríamos de Unicast. Pero es posible que el hosts con el que queremos entablar una comunicación no sea siempre el mismo, sea tan solo uno pero dependiendo de ciertas circunstancias pueda ser uno u otro, por ejemplo en función de la distancia entre ambos. La comunicación sería de nuevo tan solo entre dos hosts, aunque el destino no tendría que estar específicamente tipificado. En este caso estaríamos hablando de Anycast. Unicast y Anycast es posiblemente los dos sistemas de comunicación más usados, pero muchas veces se puede tener la necesidad de tener que enviar un mensaje a más de un hosts. Así, por Multicast entendemos un sistema de comunicación de uno a muchos, en el que esos muchos forman entre ellos un colectivo propio dentro de la misma red por supuesto. Por último, podemos desear poder enviar o comunicarnos con todos los hosts de nuestra red, en un esquema de “Uno a Todos”, y es lo que llamamos Broadcast. Un ejemplo sencillo de broadcast es la televisión, sale de un emisor pero el receptor somos todos, no va dirigida a nadie en particular, y el ejemplo más común de multicast podría ser los servicios de televisión por internet.
  

  Visto esto, comprendemos el significado de la dirección broadcast de nuestra red, dado que muchos mensajes son necesarios emitirlos a todos los miembros de nuestra red, ya sean informativos o con simples fines distributivos. Podemos decir por tanto que el último host de una red, queda también reservado y no puede ser usado como un host concreto.
  

• Subred: En realidad el término “Máscara de Red” sería tan solo aplicable a la máscara por defecto de una IP según su clase. Por ejemplo, la máscara de red para una IP de clase C será 255.255.255.0. Esto es importante, dado que no se debe de confundir con una Subred o una Máscara de Subred. Según la clasificación anterior, se podría pensar que no hay necesidad de subredes, dado que el espacio ya está dividido en diferentes clases que se amoldan a la gran mayoría de todos los interesados. Es cierto que la ICANN jamás otorgaría una IP de clase A a un particular, dado que sería una pérdida absurda de direcciones IP, ningún usuario particular tendría la necesidad de crear una red de 16777214 dispositivos. Al contrario, la ICANN tiene (solía asignar, dado el agotamiento de estas) asignado tan solo IPs de clase A a los propios gobiernos de cada país o a grandes empresas/organizaciones, la mayoría de ellas por razones históricas, como Intel, MIT… Hay que tener en cuenta que la ICANN tan solo disponía de 126 paquetes de direcciones de clase A. Por el contrario la ICANN asignaba IPs de clase B a grandes empresas y organizaciones de forma común, pensar que en este caso ya no disponía de tan solo 126 paquetes, sino 16380. Y por último los paquetes de clase C que serían los que podrían ser otorgados a particulares.

  Aunque este reparto pueda parecer suficiente, lo cierto es que no lo es. Según esto, si un particular recibiese por parte de la ICANN un red de clase C con sus 256 IPs, por ejemplo la red 193.125.222.0, el usuario tan solo podría tener una red con 256 hosts. Pero qué pasa si el usuario quiere tener 2 redes diferentes en vez de tan solo una? No podría. En cambio, podría tener un router en la entrada de su red, con una máscara de subred de 255.255.255.192, lo cual me daría la posibilidad de tener 4 subredes distintas, cada una de ella con 62 (64 menos el ID de red y la dirección de broadcast). Así, la dirección IP 193.125.222.2 pertenecería a la subred 1, mientras que la IP 193.125.222.130 pertenecería a un host en la subred 3.
  

  De este modo, la creación de subredes es el método más eficiente para la gestión de las propias IPs. Es evidente que nunca podremos trabajar con máscaras más pequeñas que la máscara por defecto que tenemos, pero si podemos trabajar con máscaras más grandes para seccionar y optimizar la red.
  

• Clase D: Las direcciones de clase D están reservadas para usarse de manera interna para propósitos de multicast. Ya hemos explicado esta técnica, pero como saben los dispositivos que dirección multicast escuchar? Lo normal es que antes de que esto sea posible, un host tiene que realizar una petición de unión a un grupo multicast, petición que realizará a través de una dirección multicast. Después de esto, el dispositivo de red (generalmente un router) reenviará el mensaje de él o para él al resto, dado que el conoce quienes son todos los miembros del grupo multicast.
• Clase E: Tan solo se puede decir que es un rango de IP reservado para poder hacer pruebas, experimentos…. o simplemente para futuros usos.
• IP 255.255.255.255: Esta IP sería algo así como la dirección de Broadcast para redes no constituidas. Si comprendemos que la dirección 0.0.0.0 es la dirección IP que hace referencia a cualquier hosts, la dirección IP 255.255.255.255 sería su IP de broadcast, siempre por supuesto hablando dentro de una red local, una red privada.

A pesar del uso de direcciones IP privadas con dispositivos NAT y al excelente trabajo de gestión de la ICANN para aprovechar al máximo las direcciones IPv4, ha sido muy normal el uso de direcciones IP dinámicas. Esto no es más que una práctica de los ISP para asignarnos IPs que podríamos llamar de “sesión”. Es evidente que jamás todos los clientes de un mismo ISP estarán conectados a la red de manera simultánea, luego sería un desperdicio de IPs. Imaginar que un ISP tiene arrendado un paquete de un millón de IPs y tiene un millón de clientes, luego asigna una a cada uno de ellos y problema resuelto. Pero como hemos dicho es evidente que esto no será jamás así, y a lo mejor las estadísticas dicen que en el mejor de los casos se forman picos de 700.000 usuarios conectados. Dicho ISP podría por lo tanto tener un paquete IPs de tan solo 700.000 direcciones, lo que le costaría sensiblemente menos. Como se gestionan estas IPs? En realidad igual que las IPs estáticas. Cuando conectamos a nuestro ISP este nos asigna una IP temporal. Dicho tiempo puede venir dado en función de la sesión o de un tiempo concreto. Una vez se da dicha circunstancia, la IP es liberada y la próxima conexión/sesión usará otra IP. De este modo si apagamos por las noches el router por ejemplo, nuestro ISP podrá reasignar dicha IP a otro cliente que quiera establecer una conexión. Por tanto, consideramos una IP dinámica aquella que varía de forma habitual con el tiempo o por conexión, e IP estática aquella que persiste. Por supuesto, el concepto aplicado a un ISP es exactamente igual que aplicado a una red local (LAN), donde la IP puede ser asignada de forma estática (por ejemplo estableciéndola en el mismo adaptador) o dinámica (por ejemplo usando servidores DHCP).

El uso de una IP dinámica o estática tiene pros y contras. Por un lado el uso de IPs dinámicas por parte de los ISP les ahorra dinero en cuanto a número de IPs necesarias, así como aumenta la seguridad y privacidad de cara al usuario, dado que su IP nunca será fija y por ende un difícil objetivo de amenazas externas. Pero por otro lado el uso de IP estáticas permite tener acceso a una serie de servicios mayores, como cualquier servicio que sea IP dirigido. Al ser la IP estática nuestro equipo/red estará siempre identificada desde el exterior, haciendo muy sencillo el uso de servidores Web/eMail o cualquier otro que nos imaginemos.

Para terminar completamente con IPv4, y dado que a estas alturas deberíamos de conocer a menos a groso modo el funcionamiento del modelo OSI/TCPIP, es interesante conocer como es un paquete IP. Recordemos que en cada nivel se encapsulará el contenido de nivel superior con el contenido añadido del nivel propio. En el caso del protocolo IP, es un protocolo de nivel 3, el cual tomará el mensaje del nivel de transporte como SDU, y le añadirá una cabecera propia, para poder así conformar el PDU del nivel 3, es decir, un paquete IP, tal y como lo encontramos en las especificaciones de 1981.

• Versión (4 bits): Contendrá la versión del protocolo. Para la versión IPv4 el valor de dichos bits será 0100 (4).
• IHL (4 bits): Es la longitud de la cabecera expresada en grupos de 32 bits. Es decir, si la cabecera tiene un total de 160 bits, 160/32 => IHL = 5.
• DiffServ (8 bits): Originalmente usado para TOS (Type Of Service), fue sustituido en un RFC de 1998 para su uso como “Differenced Services” (Servicios Diferenciados), un sistema para QoS
• Longitud (16 bits): Especifica el tamaño en Bytes del paquete IP completo. Al tener un campo de 16 bits podemos inferior directamente que el tamaño del paquete IP mayor que podemos tener es de 65535 Bytes (64KB)
• Flag (3 bits): El bit de mayor peso se fuerza a cero y no es usado. El segundo bit especifica si el paquete se podrá o no fragmentar, de estar marcado como no fragmentar y es necesaria su fragmentación para enviarlo, este paquete se descartará. El bit de menor peso especifica si hay más fragmentos o no los hay.
• Desplazamiento de Fragmentos (13 bits): A groso modo especifica el byte al que pertenece dicho fragmento. si es el primer fragmento tendrá un offset (desplazamiento) de 0, si fuese el segundo pues dependiendo ya de la fragmentación necesaria. ¿Por qué es la fragmentación necesaria? Podemos asimilarlo a la segmentación en el modelo OSI. Cada red tiene una unidad máxima de transmisión llamada MTU que precisamente especifica el tamaño máximo de un paquete. Esta es una limitación de la red, no del protocolo, esto es importante. La longitud máxima de un paquete IP es de 64KB, en cambio los enlaces Ethernet estándar suelen ser de 1500 Bytes, luego la fragmentación se puede convertir en algo “normal”. Esto significa que si se desea enviar por ejemplo una cantidad de datos de 5000 Bytes y tenemos una conexión ADSL con un MTU de 1492 bytes (cosa habitual), dicha información se deberá de fragmentar en paquetes IP más pequeños, cada paquete con un tamaño máximo (cabecera IP + datos) de 1492.

  Si atendemos a la cabecera IP expuesta arriba, cada fila corresponde a un total de 32 bits. Por tanto, la cabecera IP más corta que podríamos tener sería aquella que no se tiene el campo “Opciones”, lo que sería por tanto: 32 bits * 5 (filas) = 160 bits / 8 = 20 Bytes. La cabecera IP más larga que se puede estipular por otro lado serían 60 Bytes. Supongamos que disponemos por tanto de una Cabecera IP de un tamaño de 20 Bytes (la cabecera más simple). Si nuestra conexión ADSL tan solo puede manejar paquetes IP de 1492 Bytes significa que la cantidad de datos que pueden añadirse a nuestro paquete IP sería de 1492 – 20 = 1472 Bytes. Si deseamos enviar esos 5000 Bytes, será necesario crear paquetes IP más pequeños, en este caso un total de 4 paquetes:

  Cabecera IP 1 (20 Bytes)

  1º Cuarto SDU (Offset 0, tamaño = 1472 Bytes

  Cabecera IP 2 (20 Bytes)

  2º Cuarto SDU (Offset 1472, tamaño = 1472 Bytes

  Cabecera IP 3 (20 Bytes)

  3º Cuarto SDU (Offset 2944, tamaño = 1472 Bytes

  Cabecera IP 4 (20 Bytes)

  4º Cuarto SDU (Offset 4416, tamaño = 583 Bytes

• TTL (8 bits): Tiempo de vida, es un contador que se establece a un número dado. Cada salto que de nuestro paquete, el dispositivo de red pertinente que procese el paquete decrecerá en uno su valor. Si el TTL llega a Cero, el paquete será descartado por la red (por cualquier dispositivo de red que lo esté procesando en ese momento). Esto es una medida de seguridad para evitar que paquetes perdidos puedan circular de forma indefinida por la red.
• Protocolo (8 Bits): Estos 8 bytes representan un número que identifica el protocolo de nivel superior que está contenido en los datos que porta el paquete IP. El protocolo IP trabaja en el nivel 3 (nivel de red), pero los datos que maneja proceden del nivel superior 4, nivel de transporte. No obstante un paquete IP puede enviar como datos un protocolo de nivel 3 adjunto como datos, como es el caso de ICMP por ejemplo. Poner la lista completa es un poco absurdo, dado que casi con toda seguridad la mayoría de ellos jamás lleguemos a verlos en la vida. Quien lo desee puede acudir al RCF 790 para conocer la lista completa. Pero si cabe destacar los protocolos más usados:

  Protocolo = 1 -> ICMP; Protocolo = 6 -> TCP; Protocolo = 17 -> UDP;
  

• CheckSum (16 bits): El protocolo IPv4 realiza una operación de checksum en la cabecera para garantizar la integridad NO EL PAQUETE COMPLETO, sino de la cabecera IP. Para ello se van sumando en complemento a uno cada 16 bits de la cabecera. Una vez terminada la suma se le realiza el complemento a uno al resultado y es este el que se inscribe en este campo. A la hora de verificarlo es igual, si el resultado obtenido (omitiendo el campo checksum) es el mismo que el que está en el cabecera, el paquete es válido.
• IP Origen/IP Destino (32 bits cada campo) : Pues no es más que eso, la IP del sistema que envía el paquete y la IP del destino. Cabe decir que en teoría es posible modificar este dato a voluntad, lo cual deja ver lo relativamente vulnerable que es el protocolo ante el IP Spoofing (al menos en teoría)
• Opciones y Padding (Variable, de 0 a 40 bytes): Este campo es de obligada implementación en el stack TCP/IP, pero dependerá de cada protocolo y cada paquete que sea necesario su uso o no. Es por ello la importancia del campo IHL. Si este campo tiene un valor de 5 significará que el campo Opciones no estará presente, y la cabecera tendrá una longitud fija de 20 Bytes. En cambio, el IHL pude tener un valor de entre 6-13, lo que implicará que el campo de opciones se está usando y tiene una longitud también conocida, entre 0-40 Bytes, gracias al padding final que se le añade.

  Este campo se utiliza en algunas redes por temas de seguridad por ejemplo, en el que en estos campos se indica que el contenido es considerado desde sensible a alta seguridad, o también se puede usar para indicar la fecha del paquete mismo o especifique una ruta concreta que deba de seguir el paquete.
  

  El Padding es simplemente un relleno que se le añade al campo de opciones para que este concluya en múltiplo de 32 bits, luego puede tener un tamaño de entre 1-31 bits, de esta forma no se rompe la estructura de la cabecera y simplemente conociendo el IHL es posible conocer exactamente el tamaño de la cabecera.
  

IPv6

Como se ha dicho, posiblemente la causa más urgente a solucionar es el agotamiento del espacio de direcciones IPv4. Esto es algo que era previsible no ahora, sino hace ya unos años. En 1998 se terminaron las especificaciones IPv6, y evidentemente como característica más marcada fue ampliar a 128 bits los 32 bits de las direcciones IPv4, lo que permitiría un número virtualmente infinito de direcciones. En realidad no es que sea infinito, pero de unos 4 mil millones pasaríamos a unos 3.4 x 10^38, es decir, 34 con 37 ceros a su derecha. Dicho de otro modo, se podría entregar a cada persona del mundo un espacio de direcciones miles millones… de veces superior que todo el espacio de direcciones IPv4, y eso solo para cada habitante!! Es evidente que esta será la diferencia más significativa entre IPv4, pero como veremos tampoco es la única.

Hay que tener en cuenta el por qué se clasificaron las direcciones IPv4 del modo que se hizo, y no fue otro que el de la buena gestión del espacio de este. Pero en IPv6 este problema desaparece, ya que podemos disfrutar prácticamente de un espacio ilimitado de direcciones, luego el esquema que conocemos a día de hoy se parte completamente y muchos de los conceptos y tecnologías usadas a día de hoy desaparecen… y desaparecerán en los próximos años. Como organizaríamos el espacio de direcciones IP si pudiésemos disponer de forma ilimitada de estas?

En realidad la única complejidad que tiene IPv6 frente a IPv4 es que posee unas reglas mucho más específicas de direcciones, de este modo también es más fácil tener un reparto de direcciones de forma mucho más lógico y ordenado. La idea básica que se tendrá siempre presente es que si una interfaz de red tiene asignada de fábrica un ID único llamado comúnmente dirección MAC (de 48 bits), se podría usar dicha MAC como extremo último de una dirección IPv6.

¿Qué es una dirección IPv6?

Si bien a día de hoy la penetración de IPv6 es mínima, estas direcciones comenzarán a formar parte de nuestra vida de forma bastante habitual dentro de muy pocos años. En este caso hablamos de un espacio de direcciones inicial de 128 bits, es decir, 2¹²⁸ direcciones posibles. Con IPv4 la forma más habitual de representarla era por medio de 4 octetos: 4*8= 32bits en notación decimal. El problema es que si se usase el mismo esquema para las direcciones IPv6 se necesitarían 16 octetos, lo que resultaría en una dirección realmente grande de expresar:

125.223.0.25.158.231.45.0.0.0.0.0.98.250.115.23

Es evidente que no es una forma eficiente de representación. En lugar de la representación clásica IPv4, se usan 8 agrupaciones de dos octetos y en formato hexadecimal, no decimal. De este modo la dirección antes expresada podría simplificarse como:

7DDF:0019:9EE7:2D00:0000:0000:62FA:7317

A priori puede parecer que se tiene la misma complejidad, pero no es así. Para empezar 1 byte en decimal tiene una representación de hasta 3 dígitos, mientras que en hexadecimal jamás pasará de 2 valores. Además, es más cómodo la agrupación en bloques de 16 bits que de 8. Aun así, las reglas de notación se expanden precisamente para evitar la complejidad de representación, permitiendo la simplificación de estas direcciones. Por ejemplo, cuando un grupo de 16 bits posee tan solo ceros, es posible acotar los 4 en uno solo. Por otro lado, se puede si se desea omitir incluso todas las palabras (16 bits) siempre y cuando estas tengan un valor de “cero” y se encuentren contiguas entre sí. Dicho esto, de la dirección anterior podríamos simplificarla como:

7DDF:0019:9EE7:2D00:0:0:62FA:7317

Pero también podríamos representarla como:

7DDF:0019:9EE7:2D00::62FA:7317 (nótese los :: contiguos)

De este forma es posible acotar bastante la representación de estas. Pero en realidad esto tan solo es un efecto secundario de tener que manejar bloques de direcciones tan enormes. Y del mismo modo que el espacio de direcciones IPv4 se encuentra clasificado, con IPv6 sucede exactamente lo mismo, salvo con matices, dado que aquí desaparece la necesidad y los conceptos de Clases de IP, y prácticamente todas las IPs IPv6 pueden clasificarse como reservadas, de enlace local y Unicast. Pero veamos que sucede con la máscara de red/subred.

A pesar de tener un número de IPs virtualmente ilimitado, la necesidad de constituir redes independientes es evidente. El concepto de máscara de red/subred será usado prácticamente del mismo modo, aunque es cierto que de forma un tanto diferente. IPv6 pretende ser completamente jerárquico, lo que hará que sea también más eficiente a la hora de conocer el destino de un paquete (de cara a los router). Esta es la clasificación actual del espacio IPv6 según la IANA:

• Reservada por la IETF:

  La IETF es un organismo que gestiona el funcionamiento de todo esto. Son rangos de IPs que simplemente no están asignados a ninguna tarea.
  

• Unicast Global:

  Aquí encontraríamos el espacio IPv6 que sería usado de manera global para especificar cualquier dispositivo de red, lo que en IPv4 podríamos conocer como IPs Públicas. Estas IPs tienen una estructura en común:

  Prefijo de Red	Subred	ID de interface
  n bits	m bits	128-n-m bits

El prefijo de red tiene la función del rutado principal dentro de todo Internet, podemos ver este como los bloques principales de IPs que se entregarían a los ISP o las grandes multinacionales por parte de los administradores de zona como RIPE, ARIN y otros.

La Subred sería administrada de manera local por los administradores de dichos bloques con la finalidad de configurar sus propias redes.

El ID de interface sería la punta de la flecha que señalaría cada host en concreto, de forma única dentro de cada subred y a su vez dentro de cada red principal. Este ID de interface vendrá a ser de forma similar a lo que hoy en día entendemos como dirección MAC de un dispositivo de red. Dicho de otro modo, cada IPv6 señalará directamente a cada adaptador de red en Internet.

Aun así, el mismo rango de direcciones posibles dentro de las direcciones Unicast Globales, se encuentra dividido y asignado de forma diferente:

Una vez se vaya agotando cada bloque asignado a cada RIR, se le reasignaría un nuevo bloque.

• Unicast Única Local:

  Este rango sería el equivalente al usado para las direcciones privadas en la actual IPv4. Su estructura no obstante sería exactamente igual que las direcciones IPv6 Unicast globales. Al igual que las direcciones privadas IPv4, las direcciones Unicast Únicas Locales tan solo tienen un ámbito de uso interno, y no serán (no deberían al menos) ser enrutadas fuera de la red local. De todos modos y por seguridad, el prefijo de red en este caso se establece en 40 bits, el cual será generado de forma aleatoria con el objetivo de que si en algún momento un paquete IPv6 con IPv6 única Local fuese enrutado al exterior y del exterior inyectado a otra red local, tener la garantía de que no correspondería a ningún hosts de esta. Dicho de otro modo, la probabilidad de que el host externo existiese sería a todos los efectos prácticamente nula, dado que teóricamente la IP generada para uso local sería única en toda Internet. Todo el resto del rango pasaría a ser administrado por la persona a cargo de la red a voluntad, del mismo modo que configuramos nuestras redes privadas. De este modo tendremos la posibilidad si así lo deseamos de conectar nuestra red directamente a Internet o aislarla de esta. Si fuese este último caso, es evidente que sería necesario hacer uso de dispositivos NAT para traducir las direcciones locales a una dirección IPv6 Unicast Global en caso de querer conectar dicha red al exterior, del mismo modo que se realiza a día de hoy con IPv4
  

• Unicast de Enlace Local:

  A diferencia de Unicast única local, en este caso la IPv6 no solo no tendría un ámbito local, sino que esta no sería única. Es decir… esa misma IP podría ser encontrada en otros puntos del planeta, todo lo contrario que lo que sucede con el apartado anterior, que pese a ser de ámbito local pueden considerarse IPs únicas. Estas IPs corresponderían a las que en IPv4 podríamos llamarlas IPs APIPA, es decir, IPs de autoconfiguración propia sin necesidad siquiera de un enlace a un nodo de red:

  
  

  Prefijo de Red (10 bits)	Subred (54 bits)	ID de interface (64 bits)
  1111111011	0	Host

• Multicast:

  En IPv6 el término IP Broadcast desaparece, y tan solo permanece el de Multicast. A fin de cuenta para enviar un paquete a toda una misma red no hace falta una dirección específica, ya que todos estos hosts pueden formar parte de un mismo grupo Multicast. Es decir, en IPv6 las direcciones de punto final :FF señalarían a hosts concretos.
  

  Por ello se reserva un rango específico para direcciones Multicast. Estas, si poseen una estructura algo diferente a las direcciones Unicast vistas hasta el momento, y tiene su lógica. Estas direcciones Multicast pueden tener tanto un ámbito local como global, por lo tanto se requerirán de ciertos bits específicos para esta diferenciación:

  
  

  Prefijo de Red (8 bits)	Flag (4 bits)	Ámbito ( 4 bits)	ID de grupo (112 bits)
  11111111	0 | R | P | T	Ver tabla	ID

Flag: Especifican algunas opciones de la IP multicast, como por ejemplo si la IP es permanente (T) o si es una IP que pertenece al propio prefijo de red (P).
Ámbito: Según el valor que tome, especificará el alcance de la dirección Multicast. Así por ejemplo, para un ámbito 1110 la IP multicast sería escuchada de manera global, mientras que si es 0010 el ámbito sería local. Las especificaciones completas las podemos encontrar si lo deseamos en el RFC 4291.

En adición de esto, existen ya preestablecidos grupos estándares, así como especificaciones mucho más amplias de cómo usar estas IPsv6 Multicast, pero tampoco es demasiado importante para nosotros.

• IP no especificada e IP de Loopback:

  Del mismo modo que en IPv4 existen las IPs especiales 0.0.0.0 como IP comodín e IP 127.0.0.1 conocida como IP de retroalimentación o Loopback, en IPv6 existe exactamente lo mismo. Así la IP no especificada será la correspondiente a ::/128, mientras que la IP de Loopback corresponderá a ::1/128.
  

Además del ingente espacio de direcciones IP, IPv6 posee principalmente tres grandes mejoras frente a IPv4. La primera es que IPv6 está creado de base para ser usado con IPSec, protocolo punto a punto para el cifrado de las conexiones. Esto no significa que IPSec será usado en todo internet, sino que su implementación es obligada y cualquier sistema preparado para ello. La segunda característica es que los propios hosts y nodos extremos podrán auto negociar su propia IP, sin necesidad de un servidor DHCP. El proceso se realiza gracias al nuevo protocolo ICMPv6. El host enviará así un paquete ICMPv6 de descubrimiento a la dirección multicast de enlace local y si existe un router configurado para ello en un extremo, este le responderá directamente con los ajustes de configuración de este, según la estructura actual de su red. La tercera mejora son los conocidos como los paquetes Jumbo. Estos no son desconocidos, ya que actualmente son usados en redes GigaEthernet para mejorar la transmisión de los datos, ya que es posible exceder el MTU de la red, enviando paquetes con un mayor tamaño.

De cara a como es en sí un paquete IPv6 (su cabecera) hay que destacar la simplificación que se ha realizado de la actual IPv4:



• Versión (4 bits): Corresponde exactamente igual al valor de IPv4, es decir, específica la versión del protocolo. Para IPv6 tomará por tanto un valor de 0110
• Clase de Tráfico (8 bits): Similar a al campo DiffServ de IPv4. Su objetivo es proveer al protocolo capacidades QoS, es decir, capacidades para priorización del tráfico, dado que por desgracia el ancho de banda siempre será limitado.
• Etiqueta de Flujo (20 bits): Aun se encuentra en experimentación. La idea original consistía en la posibilidad de poder etiquetar los paquetes de forma que fuese adecuado para aplicaciones en tiempo real como VoIP, o para sistemas QoS no estándares. No es un requerimiento actual, y puede establecerse todo a ceros si no es usado. Recordemos que IPv6 es aún un protocolo experimental que está en sus primeras fases. Hasta que no pase X tiempo en el entorno real y a gran escala, no se podrá con casi toda seguridad retocarlo para obtener las mejores prestaciones.
• Longitud (16 bits): Especifica ni más ni menos la longitud en bytes de los datos que serán enviados por el paquete sin contar la propia cabecera. Es decir, si el SDU de la capa superior ocupa 60KB, la longitud será 60KB. A esto hay que añadir que IPv6 permite extensiones de la cabecera para añadir funcionalidades opcionales. Estas extensiones de la cabecera NO forman parte de la cabecera en sí, e irían justo antes del SDU. Esto quiere decir que el tamaño de las extensiones de la cabecera sí será contabilizado en este campo. Al ser un campo de 16 bits permitirá de nuevo un tamaño máximo de paquete de unos 64KB.
• Cabecera Siguiente (8 Bits): Tiene la misma funcionalidad que el campo “protocolo” de IPv4. Especifica la cabecera que se encontrará después de la cabecera actual. En IPv4 hacía referencia prácticamente tan solo al protocolo usado en el SDU superior, pero aquí puede especificar también las extensiones de cabecera, como por ejemplo extensión de cabecera para fragmentos.
• Límite de Saltos (8 bits): Es el campo TTL (Time To Live) de IPv4. Cada salto que dé el paquete, este contador será decrementado en 1. Si llegase a cero, el paquete se descarta de la red.
• IP Origen/Destino (128 bits cada campo): Cada dirección IPv6 de 128 bits, primero la IP de origen y después la IP destino.

Es interesante ver como por ejemplo se ha eliminado de la cabecera IPv6 el checksum, dejando la comprobación de integridad directamente sobre los niveles superiores e inferiores. Aunque las ideas en papel son buenas, hay que tener en cuenta que las estadísticas y la realidad son otras. A lo mejor en un principio se estimó que la comprobación de la integridad de una cabecera IP era adecuado a principios de Internet dado la poca fiabilidad de las redes antiguas. A día de hoy se ha demostrado que la comprobación de la cabecera en IPv4 quizás tan solo era útil (es decir, existía un error y este era detectado) en un porcentaje tan ínfimo que su uso ha dejado de ser necesario, máxime cuando niveles superior e inferiores ya poseen controles de integridad adecuados (los cuales antes también existían)

Las extensiones de cabecera son igualmente parte imprescindible de IPv6. Si bien es cierto que la cabecera base ha sido completamente reducida, parte de las opciones que existían en IPv4 ahora las podremos encontrar como extensiones. Estas extensiones serán indicadas en el campo “cabecera siguiente” antes descrito, que nos dirá que cabecera será la que encontraremos justo después de la cabecera base, es decir, antes de los datos superiores. Estas cabeceras no obstante jamás serán procesadas por un nodo de red, esto quiere decir que todos los nodos de los saltos intermedios que de un paquete desde el origen al destino, tan solo se procesará la cabecera base. Las extensiones de cabecera serán por tanto tan solo procesadas cuando el paquete alcance su destino final. La única excepción se dará cuando exista la extensión de cabecera Hop-By-Hop. La cual será siempre añadida como primera extensión de cabecera e identificada por “Cabecera siguiente” como un cero.

Las extensiones especificadas actualmente en IPv6, así como su orden (en caso de que exista más de una extensión de cabecera) es el siguiente:

Cabecera IPv6 Base
Cabecera Hop-By-Hop
Cabecera de Opciones de destino (Para ser procesada tan solo por el primer destino/salto)
Cabecera de Rutado
Cabecera de Fragmentos
Cabecera de encapsulación de seguridad de los datos
Cabecera de Opciones del destino (Para ser procesada tan solo por el destino final)
Cabecera de nivel superior

Cada cabecera tiene sus campos y opciones concretos, que podríamos especificar pero sería rizar más el rizo. De todos modos se puede acudir a las especificaciones para obtener las especificaciones detalladas en el RFC 2460. Lo que es evidente es que cada cabecera de extensión tendrá un campo que será también “Siguiente Cabecera”, puesto que en IPv6 puede existir más de una extensión de cabecera. No obstante, el tamaño de estas extensiones será siempre un número múltiplo de 64 bits, con la idea de que en ningún momento se pierda la alineación de los 64 bits (La cabecera completa de un paquete IPv6 será por tanto siempre múltiple de 64)

Para terminar con IPv6, hay que tener en cuenta que algunos protocolos asociados a IPv4 son modificados ligeramente para poder soportar IPv6, como es el caso por ejemplo de ICMPv6 o DCHPv6. Es evidente que por ello IPv4 e IPv6 son completamente incompatibles entre ellos. No obstante, durante algunos años viviremos posiblemente una utilización de ambos. Esto será posible no porque ambos protocolos sean compatibles, sino porque se usarán técnicas de túneles para poder lograr esta interoperabilidad. Es decir, cuando un router obtenga una petición IPv6 y quiera enviarla por una red IPv4 tendrá que encapsular el paquete IPv6 como un paquete IPv4 estándar. El paquete podrá viajar así a través de toda la red IPv4 hasta el nodo destino, en el cual el paquete IPv4 se abriría para dar origen al paquete IPv6 que sería rutado a través de la red IPv6. Este mismo concepto puede ser usado a la inversa. El problema principal al que uno se encuentra es el soporte hardware de IPv6, así como de técnicas de túneles descrita.

Para que un usuario a día de hoy pueda realizar una conexión a redes IPv6 de forma directa, necesitará primero que su ISP tenga una infraestructura IPv6 ya creada (cosa que actualmente es muy raro que tengan), por no hablar de que el router de cada particular sea compatible con IPv6. De cara a los PCs de los usuarios esto no es problema en Windows ni en Linux desde hace tiempo. El soporte para IPv6 existe desde hace tiempo y los equipos estarían perfectamente preparados para recibir direcciones IPv6 y conectarse a las redes pertinentes. Microsoft implementó además del soporte nativo IPv6 técnicas de túneles como Teredo para permitir la interoperabilidad, aunque como he dicho actualmente la penetración de IPv6 es mínima. Poco a poco las pruebas van terminándose, y además urge un nuevo espacio de Direcciones, IPv6 como hemos dicho está acabado. El principal problema por tanto recae tan solo en los routers y otros dispositivos de red, si no tenemos soporte en ellos, así como en las redes de nuestro ISP, no podremos hacer mucho. Veamos un ejemplo de conexión a una red IPv6:

Interfaz en Windows 7 para IPv6:

Adaptador de Ethernet Local Area Connection:
Sufijo DNS específico para la conexión. . :
Descripción . . . . . . . . . . . . . . . : Marvell Yukon PCI-E

Gigabit Ethernet Controller #2
Dirección física. . . . . . . . . . . . . : xx-xx-x-xx-xx-xx
DHCP habilitado . . . . . . . . . . . . . : sí
Configuración automática habilitada . . . : sí
Dirección IPv6 . . . . . . . . . . . . . :2002:xxxx:xxxx:x:xxxx:xxxx:xxxx:xxxx(Preferido)
Dirección IPv6 temporal. . . . . :2002:xxxx:xxxx:x:xxxx:xxxx:xxxx:xxxx(Preferido)
Vínculo: dirección IPv6 local. . . : xxxx::xxxx:xxxx:xxxx:xxxx%12 (Preferido)
Dirección IPv4. . . . . . . . . . . . . . : 192.168.x.x(Preferido)
Máscara de subred . . . . . . . . . . . . : 255.255.255.0
Concesión obtenida. . . . . . . . . . . . : sábado, 05 de junio de 2010 21:05:12
La concesión expira . . . . . . . . . . . : miércoles, 13 de julio de 2146 3:39:47
Puerta de enlace predeterminada . . . . . : xxxx::xxx:xxxx:xxxx:xxxx%12
192.168.x.x
Servidor DHCP . . . . . . . . . . . . . . : 192.168.x.x
Servidores DNS. . . . . . . . . . . . . . : 192.168.x.x
NetBIOS sobre TCP/IP. . . . . . . . . . . : habilitado

Petición DNS IPv6:

ipv6.l.google.com: type AAAA, class IN, addr 2a00:1450:8002::68
Name: ipv6.l.google.com
Type: AAAA (IPv6 address)
Class: IN (0×0001)
Time to Live: 5 minutes
Data length: 16
Addr: 2a00:1450:8002::6a

Paquete TCP/IPv6:

Protocolo DNS

Domain Name System (o Sistema de Nombres de Dominio en español) es la segunda piedra angular en la que se sustenta no solo Internet, sino todas las rede en general. Al igual que IP, DNS no es más que un espacio de direcciones por así decirlo, aunque sería más correcto usar el término de espacio de nombres. Es curioso el hecho de que incluso los menos instruidos en la materia en algún momento ha escuchado o ha tenido que tratar con IPs, pero en cambio los términos DNS parecen mucho más difusos y raramente tenidos en cuenta, quizás tan solo cuando el ISP nos da la configuración de nuestra línea. No obstante, gracias al sistema DNS conocemos internet como la conocemos. ¿Es realmente necesario el sistema DNS? No, su existencia no nace de una “necesidad” propiamente dicha, sino de ser un recurso de increíble valor para cualquier persona, dada las limitaciones mentales que todo el mundo tenemos: Siempre conoceremos el nombre de una persona, pero solo algunos de sus números de teléfono.

El sistema DNS puede verse por tanto como un sistema de mapeo de direcciones IP a nombres. Es simple, cualquier persona del mundo será capaz de recordar nombres como google.es, microsoft.com, intel.com o theliel.es con infinita más facilidad que recordar (en el mismo orden): 216.239.59.104, 207.46.197.32, 198.175.96.33, 188.121.46.128. Y eso por supuesto si tenemos en cuenta el sistema actual IPv4, si tenemos en cuenta la proximidad de IPv6 el problema sería infinitamente mayor. Es evidente por tanto que aun cuando técnicamente no es imprescindible, de cara a las capacidades limitadas del ser humano podemos decir que sí lo es.

Cada vez que hacemos mención en alguna red (ya sea local o externa) de un nombre de domino, el sistema DNS hace posible la comunicación con dicho host, lo que sucede es que este sistema trabaja aparentemente siempre de forma transparente para nosotros, del mismo modo que para un usuario que navega por internet no entiende de IPs ni las necesita, lo cual no significa que sin saberlo las esté empleando de forma continuada.

Hay que tener presente como se vio en el capítulo anterior, que al igual que se gestiona el espacio de direcciones IP, se gestiona el espacio de nombres. Esto quiere decir que no existirán dos nombres iguales para el mismo dominio. ¿Dominio? Esto es algo que también se explicó. El sistema DNS es jerárquico, dividido por así decirlo en dominios, de forma que cada dominio superior gestiona sus dominios secundarios, y estos secundarios los dominios terciarios y así sucesivamente. Ya vimos el papel de la ICANN a la hora de gestionar los dominios de primer nivel y como se delegan los dominios de segundo o tercer nivel a cada autoridad. También se habló de los servidores raíces y de función, pero aquí veremos realmente la importancia de estos, así como el funcionamiento real del sistema DNS. En esta ocasión vamos a suponer un ejemplo, y de este todo el funcionamiento DNS, comenzando por el ejemplo más simple y aumentando su complejidad:

• Caso 1: No necesaria resolución DNS, especificación de IP de forma directa

  El caso más sencillo que podemos ver es cuando realizamos una solicitud directamente sobre una IP. Por ejemplo si deseamos obtener acceso a un recurso de red interna y conocemos de antemano la IP de dicho servidor. Si en el explorador de archivos de Windows tecleamos la ruta \\192.168.5.23 (por supuesto damos por hecho una correcta configuración de puerta de enlace, máscara de subred e IP), el PC se comunicará directamente con el host especificado, en este caso sin siquiera necesidad de acceder a la puerta de enlace del router, ya que la tabla ARP del sistema ya contiene la dirección de este (más adelante se verá el protocolo ARP), con lo que se hace la petición sobre la propia dirección MAC:
  

  Interfaz: 192.168.5.2 — 0xc
  Dirección de Internet Dirección física Tipo
  192.168.5.1 00-xx-xx-xx-xx-xx dinámico
  192.168.5.23 00-xx-xx-xx-xx-xx dinámico
  

  En el caso que la petición sea realizada en el navegador, por ejemplo especificando de forma directa la IP del servidor de google en España: “216.239.59.104″, el proceso será exactamente igual, la petición saldrá por nuestro router e irá directamente hacia dicha IP (nuestro paquete irá saltando de router en router hasta alcanzar el host indicado, pero sin ninguna necesidad de uso del sistema DNS:
  

  tracert 216.239.59.104
  

  1 <1 ms <1 ms <1 ms Alpha5 [192.168.x.1]
  2 35 ms 35 ms 36 ms 192.168.153.1
  3 35 ms 35 ms 32 ms 209.Red-81-46-42.staticIP.rima-tde.net [81.46.42.209]
  4 80 ms 42 ms 42 ms So6-0-0-0-grtmadno1.red.telefonica-wholesale.net.10.16.84.in-addr.arpa [84.16.10.65]
  5 43 ms 64 ms 64 ms Xe9-1-0-0-grtpartv2.red.telefonica-wholesale.net [84.16.15.174]
  6 65 ms 65 ms 63 ms Xe0-3-0-0-grtpartv1.red.telefonica-wholesale.net [84.16.12.213]
  7 * * * Tiempo de espera agotado para esta solicitud.
  8 77 ms 72 ms 104 ms 209.85.251.40
  9 76 ms 74 ms 72 ms 209.85.248.95
  10 75 ms 78 ms 75 ms gv-in-f104.1e100.net [216.239.59.104]
  

   

• Caso 2: Resolución DNS en archivo local

  En este caso no se hace uso del sistema DNS como tal, sino de archivos de texto existentes en cada equipo que contienen precisamente este mapeo de nombres-IPs. Históricamente era el sistema usado para esta tarea, y aun cuando a día de hoy el sistema DNS es usado de forma global, este sistema se continúa usando de forma relativamente extendida, aunque generalmente por propósitos un tanto diferentes. Ya hemos hablado alguna vez de ello: El archivo “Hosts”. Este archivo presente en la gran mayoría de todos los sistemas operativos es el que mantiene esta lista, puesto que no es más que una lista. En Windows por ejemplo podemos encontrarlo en “C:\Windows\System32\Drivers\etc\Hosts”, mientras que en Linux lo encontramos en “/etc/hosts”. Veamos un ejemplo de este fichero:
  

  192.168.x.52 alpha
  192.168.x.52 beta.com
  209.85.229.104 google.es
  127.0.0.1 webpeligrosa.com
  

  Dado este fichero LOCAL de nuestro sistema, nuestro sistema estaría en condiciones de aceptar los primeros nombres en lugar de las direcciones IPs. Así, para acceder al hosts con la IP 192.168.x.52 se puede realizar conociendo su IP o su nombre de dominio, en este caso “alpha”. El segundo caso, beta.com es exactamente igual, solo recordar que el sistema jerárquico actual de dominios de primer nivel, segundo nivel… es una cuestión de eficiencia, organización y acuerdos, para una resolución local no es necesario tener el hombre de host asociado a un dominio TLD (de primer nivel).
  

  Más interesante es el tercer caso. Los dos primeros hacen referencia a direcciones locales, mientras que la tercera es una dirección global. Pero el proceso es el mismo. Sin la existencia de un sistema DNS como el actual, el archivo hosts de cada PC debería de tener dicha entrada si se quisiese poder acceder al servidor de google.es sin necesidad de conocer la IP de este. En este caso la IP mostrada es la IP real de google.es, esto es muy importante saberlo, puesto ¿qué sucedería si la IP que hemos añadido a dicho archivo realmente no perteneciese al servidor de google.es? El archivo hosts es un archivo de mapeo, sean las direcciones mapeadas legítimas o no. Esto quiere decir que si sustituimos dicha entrada del archivo hosts por ejemplo esta otra:
  

  217.146.186.221 google.es
  

  tendríamos algo tan gracioso como acceder a la web de Yahoo cuando en el navegador introducimos google.es. El mapeo del archivo hosts prevalece sobre cualquier resolución de nombres externa. ¿Qué utilidad puede tener esto? A día de hoy muchos tipos de malware modifican el archivo de hosts para enviar a los afectados a sitios donde realizar pishing o webs con código maligno para lanzar exploits o ataques XSS (entre otros) contra el usuario.
  

  El último caso, y posiblemente el más usado a día de hoy, es la redirección de ciertas páginas a la dirección IP de Loopback. Esta simple práctica abre la posibilidad a un sin fin de posibilidades, como por ejemplo el filtrado de hosts, ya que cualquier hosts redirigido a la dirección de Loopback será anulado por así decirlo (siempre que en el equipo local no tenga levantado ningún servidor web, claro está. Así por ejemplo en el caso mostrado, si redirigimos la URL webpeligrosa.com, que por ejemplo conocemos es altamente dañina, a nuestra dirección de Loopback, en cualquier momento que el PC intente una conexión a dicho host, ya sea premeditado o por la intervención de un malware, nuestro equipo la enviará a la dirección de Loopback, y con ello la web no será válida.
  

  Estos archivos hosts, este sistema tiene una gran serie de ventajas, pero tienen tres características que lo hacen completamente inviable de cara a una red extensa: La primera de ella es que un archivo local de estas características es fácil de administrar cuando los hosts a filtrar son pocos, en cambio si el número es elevado tendríamos desde problemas de rendimientos (cientos de miles de direcciones supondría tamaños de archivos considerables) hasta entradas duplicadas. El segundo problema es aún peor. Si poseemos un archivo de hosts con la resolución de 10 equipos, y uno de ellos cambia de IP es fácil localizarlo y cambiarlo. Si manejamos archivos de hosts de cientos o miles de equipos, se hace imposible la actualización de estos archivos. La tercera es que no dispone de ningún sistema centralizado, esto significa que cada archivo hosts debería de ser almacenado en principio de forma local, y cualquier actualización de cualquier hosts tendría que ser modificada en todos los equipos.
  

• Caso 3: Resolución DNS en caché local

  Sin un archivo de hosts ni especificación de la dirección IP de forma directa, el equipo necesita de un sistema “superior” que permita darle a conocer dicha IP, y es por ello que el sistema DNS es necesario. Pero si se realizase una petición DNS por cada nombre de dominio introducido, sería una práctica enormemente ineficiente. Es cierto que la actualización en el caso 2 de la IP de un hosts es algo más que inviable en grandes magnitudes, pero igualmente es cierto que tampoco es algo que suceda constantemente. Si la IP de un hosts se mantiene relativamente “estable” con el tiempo, sería una tontería estar realizando peticiones DNS constantemente para resolver la dirección del hosts. Más aun, cada petición DNS que se realiza, tiene un coste en el ancho de banda y en la sobrecarga de los servidores de resolución DNS (estos los veremos más adelante)
  

  Por todo ello, no es rara la existencia de una caché a nivel local que almacene las peticiones más realizadas o más recientes. Imaginar por ejemplo que se desea acceder a la web de google.es y que 5 segundos más tarde deseamos realizar otro acceso a la misma web. Esto implicaría dos peticiones DNS. Con una caché de DNS local, con un tiempo de vida limitado evidentemente, sería el equipo local quien respondería la petición DNS de nuestro navegador, sin necesidad de enviar una petición DNS a nuestra puerta de enlace o directamente a nuestros servidores DNS:
  

  C:\Users\Theliel>ipconfig /displaydns >> dns.txt
  zxlinks.com
  —————————————-
  Nombre de registro . : zxlinks.com
  Tipo de registro . . : 1
  Período de vida . . . : 86400
  Longitud de datos . . : 4
  Sección . . . . . . . : respuesta
  Un registro (host). . : 127.0.0.1
  

  zxlinks.com
  —————————————-
  No hay registros de tipo AAAA
  

  arstechnica.com
  —————————————-
  Nombre de registro . : arstechnica.com
  Tipo de registro . . : 1
  Período de vida . . . : 2091
  Longitud de datos . . : 4
  Sección . . . . . . . : respuesta
  Un registro (host). . : 75.102.3.15
  

  Con ipconfig /displaydns mostramos el contenido de la caché DNS de Windows. En este caso vemos dos entradas en ella, una de ellas apunta a la dirección de Loopback, la otra la IP de dicho hosts. Esto es debido a que Windows introduce los host del archivo hosts en su caché DNS, con un tiempo de vida de 24 horas (86400 seg). Por otro lado registrará cualquier petición DNS reciente que sea realizada, de este modo si el sistema requiere la resolución de otro host en un tiempo en el que la caché aun tenga dicho registro, será esta quien devuelva el resultado en vez de realizar una petición. El lado negativo en cambio es que si un host modifica su IP en el tiempo que nuestro sistema está cacheando la IP, la IP no será actualizada para nuestro sistema, y posiblemente nos toparemos con una URL no disponible. Es decir, el uso de caché aumenta el rendimiento considerablemente, pero de cuando en cuando puede existir un problema de coherencia. Es por ello que casi cualquier sistema permite el vaciado de la caché DNS, en Linux suele ir asociado simplemente a reiniciar el servicio (dependiendo del servicio usado), en Windows se realiza mediante: “ipconfig /flushdns”
  

  Por encima de esta caché local, podríamos situar un caché aún más cercana al usuario que se resolvería antes que enviar la petición al sistema. Algunos navegadores como Firefox poseen una pequeña caché interna de resolución de DNS que realiza una función igual. Esta caché suele ser más pequeña y suele ser mucho más eficiente, dado que esta caché tan solo es usada para peticiones realizadas mediante el navegador. Esto quiere decir que cualquier otro tipo de peticiones producidas por gestores de correo, clientes FTP, conexiones de juegos/aplicaciones… ninguna de estas estarán registradas en dicha caché. En Firefox, para poder acceder a las opciones de caché de DNS es necesario acceder a la página de configuración avanzada mediante la dirección en la barra de direcciones: about:config, y dentro de esta buscar la clave “network.dnsCacheEntries” y “network.dnsCacheExpiration”, siendo ambos nombres bastante descriptivos sobre su función.
  

• Caso 4: Resolución DNS en caché de nuestro router

  Del mismo modo que nuestro sistema cuenta con una pequeña caché para almacenar las peticiones DNS más recientes o más comunes, no es extraño pensar en que un sistema similar podría ser incluido por ejemplo a nivel de nuestro propio router, de modo que el router serviría a todos sus clientes conectados como servidor de DNS. Sería por tanto este quien resolvería por los clientes las peticiones pertinentes y devolvería a estos el resultado. Pero por el mismo motivo, podría mantener una caché interna de DNS con las peticiones no de un solo cliente, sino de todos los clientes conectados. Es decir, si el cliente 1 necesita acceder por vez primera al servidor google.es y segundos más tardes el cliente 2 quiere acceder al mismo servidor, es más que probable que el router no vuelva a realizar una petición DNS para conocer la IP del servidor google.es, sino que ya tendrá almacenada dicha entrada debido a la petición anterior del cliente 1, con lo que todo el sistema se agiliza de forma considerable, optimizando además el ancho de banda. De lo contrario el router tendría que esperar la contestación de los servidores DNS configurados en él, estos a su vez o devolver la petición o realizarla a un servidor superior… y tan solo cuando se obtiene la IP destino devolverla al hosts que la pidió, y una vez el hosts tiene la IP dele servidor poder realizar ahora sí la petición http (por ejemplo) pertinente. Esta función no obstante depende del router en cuestión, y al igual que la resolución de DNS en caché local, posee de pros y contras (en el 90% de las situaciones es una práctica que merece bastante la pena)
  

  Hay que tener en cuenta y no hay que confundir una caché DNS con un servidor DNS, el cual evidentemente mantiene una caché DNS. Existen routers en la actualidad que poseen funciones de servidor DNS y por tanto cachea las peticiones DNS. Por ejemplo podemos ver esto en las firmware del equipo de DD-WRT.
  

Resolución DNS por medio de los servidores DNS (caso 5)

Aunque sería el caso 5, vamos a verlo independientemente de los otros 4 casos, dado que es aquí donde se pone en marcha en realidad el sistema DNS. Todos los casos anteriores lo que impiden de un modo u otro es tener que hacer uso de este sistema, no porque sea ineficaz, sino para evitar la sobrecarga en este. Además, es evidente que cualquier petición realizada al exterior consumirá un tiempo superior a cualquier petición respondida de forma local. Veamos algunos tiempos de resolución gracias a la herramienta de resolución DNS Dig, disponible tanto para Linux (suele venir incluida) como para Windows (se debe de descargar):

theliel@Anarchy:~$ dig theliel.es
; <<>> DiG 9.7.0-P1 <<>> theliel.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58146
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;theliel.es. IN A

;; ANSWER SECTION:
theliel.es. 2362 IN A 188.121.46.128

;; Query time: 2 msec
;; SERVER: 192.168.3.1#53(192.168.3.1)
;; WHEN: Fri Jun 11 17:34:21 2010
;; MSG SIZE rcvd: 44

theliel@Anarchy:~$ dig @80.58.61.250 theliel.es

; <<>> DiG 9.7.0-P1 <<>> @80.58.61.250 theliel.es
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3856
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;theliel.es. IN A

;; ANSWER SECTION:
theliel.es. 2361 IN A 188.121.46.128

;; Query time: 66 msec
;; SERVER: 80.58.61.250#53(80.58.61.250)
;; WHEN: Fri Jun 11 17:34:22 2010
;; MSG SIZE rcvd: 44

Como podemos ver, la resolución DNS realizada por mi router en este momento es de tan solo 2 msec, es más que probable que tenga en su caché la resolución ya realizada. En cambio, si especifico que la resolución se lleve a cabo por medio de mi ISP, el tiempo se eleva a 66 msec, en este caso es el servidor DNS primario de telefónica España. Esta utilidad puede ser usada también para comprobar que servidores DNS son más óptimos para nuestra red. Por ejemplo, podemos ver el tiempo que tardaría los servidores de DNS de google, y si son mejores que los de nuestro ISP:

theliel@Anarchy:~$ dig @8.8.8.8 theliel.es
; <<>> DiG 9.7.0-P1 <<>> @8.8.8.8 theliel.es
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49868
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;theliel.es. IN A

;; ANSWER SECTION:
theliel.es. 3594 IN A 188.121.46.128

;; Query time: 97 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jun 11 17:43:00 2010
;; MSG SIZE rcvd: 44

En este caso, el servidor de DNS de Google (8.8.8.8) tiene unos tiempos de resolución peores a los servidores de mi ISP. Esto también tiene su explicación. Por un lado la cercanía de los servidores, por otro lado la necesidad de dichos servidores de recurrir a servidores DNS superiores.

Cuando ningún sistema “local” puede resolvernos un nombre de dominio, es necesario realizar una petición DNS a un servidor DNS para que este nos devuelva la IP del host al que deseamos acceder. Cuanto antes sea respondida dicha petición, antes será alcanzado el hosts. La mejor forma de ilustrar esto es poner dos ejemplos: El mejor de los casos y el peor de los casos. De este modo se puede ver perfectamente el funcionamiento jerárquico de DNS y la importancia última de los servidores DNS raíces.

En el mejor de los casos, el servidor DNS de nuestro ISP tiene directamente la respuesta de nuestra petición. Es decir, imaginar que deseamos conocer la IP del servidor donde está alojado el dominio theliel.es. Si nuestro ISP posee esta entrada directamente en su servidor DNS, este no tendrá que acudir a un servidor de DNS superior y de forma inmediata devolverá la IP de este host. Pero si dicha entrada no se encuentra presente en el servidor de DNS de nuestro ISP, este a su vez debe de realizar una petición DNS a un servidor DNS superior a él, De este modo se realiza lo que se conoce como peticiones DNS recursivas, en la que nuestra petición DNS va saltando entre los diferentes servidores DNS hasta que alguno de estos servidores devuelve la IP deseada. Veamos el peor de los casos de este ejemplo cuando se desea conocer la IP del host earth.google.es:

theliel@Anarchy:~$ dig +trace @80.58.61.250 earth.google.es

; <<>> DiG 9.7.0-P1 <<>> +trace @80.58.61.250 earth.google.es
; (1 server found)
;; global options: +cmd
. 472319 IN NS f.root-servers.net.
. 472319 IN NS g.root-servers.net.
. 472319 IN NS h.root-servers.net.
. 472319 IN NS i.root-servers.net.
. 472319 IN NS j.root-servers.net.
. 472319 IN NS k.root-servers.net.
. 472319 IN NS l.root-servers.net.
. 472319 IN NS m.root-servers.net.
. 472319 IN NS a.root-servers.net.
. 472319 IN NS b.root-servers.net.
. 472319 IN NS c.root-servers.net.
. 472319 IN NS d.root-servers.net.
. 472319 IN NS e.root-servers.net.
;; Received 228 bytes from 80.58.61.250#53(80.58.61.250) in 400 ms

es. 172800 IN NS ns1.crn.nic.es.
es. 172800 IN NS ns1.nic.es.
es. 172800 IN NS ns1.cesca.es.
es. 172800 IN NS ns3.nic.fr.
es. 172800 IN NS sun.rediris.es.
es. 172800 IN NS ns-ext.nic.cl.
es. 172800 IN NS sns-pb.isc.org.
;; Received 376 bytes from 202.12.27.33#53(m.root-servers.net) in 99 ms

google.es. 7200 IN NS ns2.google.com.
google.es. 7200 IN NS ns1.google.com.
;; Received 79 bytes from 130.206.1.2#53(sun.rediris.es) in 66 ms

earth.google.es. 345600 IN CNAME earth.google.com.
earth.google.com. 86400 IN CNAME www3.l.google.com.
www3.l.google.com. 300 IN A 209.85.229.102
www3.l.google.com. 300 IN A 209.85.229.100
www3.l.google.com. 300 IN A 209.85.229.101

;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 116 ms

En este caso, el servidor DNS de nuestro ISP (80.58.61.250) es incapaz de resolver la IP del host earth.google.es. Dado que no es capaz de resolver dicha dirección, no tiene otro remedio que realizar una petición DNS a un servidor que pueda conocer algo más de ese host. Aquí es donde cobra gran importancia la jerarquía de los dominios. En el host earth.google.es, el dominio de primer nivel es “es”. El servidor de DNS de telefónica no conoce cuales son los servidores de resolución DNS para los ccTLD .es, pero sí conoce la dirección de los servidores DNS raíces. El servidor DNS de telefónica consulta la lista de los servidores raíces y opta por enviar la petición al servidor raíz m (m.root-servers.net). El servidor raíz m recibe por parte del servidor DNS de telefónica una petición de resolución para el servidor DNS .es. El servidor raíz m SI CONOCE y si tiene en su base de datos la dirección de los servidores DNS que gestionan las direcciones ccTLD .es, y de entre todas ellas escoge el servidor sun.rediris.es, con lo que envía esta IP al servidor DNS de telefónica. Este conoce ya la IP del servidor de DNS que le podrá resolver la IP del dominio google.es, con lo que envía al servidor DNS anteriormente devuelto por el servidor raíz una petición de resolución para el dominio de segundo nivel google.es. El servidor sun.rediris.es recibe la petición por parte del servidor raíz M para resolver la dirección del host google.es (ya dentro del dominio de primer nivel .es). Esta consta en su base de datos, con lo que le responde de nuevo con la IP de la de la resolución del host del servidor de DNS de google, concretamente ns2.google.com. Dado que este es el último servidor de DNS que necesita, el servidor de telefónica que está realizando la recursividad solicita la resolución de earth.google.es a dicho hosts, dicho servidor recibe la petición de resolución para earth (ya dentro del dominio google.es), y dado que la posee envía la contestación al ISP y este a nosotros.

Lo normal es que todo este proceso se realice de forma completamente transparente por parte de nuestro ISP, y nuestro sistema tan solo realice una petición DNS, mientras que nuestro ISP puede realizar la petición recursiva DNS (es quien va enviando las diferentes peticiones según las respuestas que va recibiendo por parte de los servidores DNS) y es él quien al final nos envía a nosotros la dirección IP final. Aquí podemos ver la gran importancia de los servidores raíces, podemos decir que estos son los que poseen acceso directo a los servidores de DNS TLD. Si estos servidores raíces fallan, Internet falla, de ahí a ser objetivo de hackers desde que Internet nació y de ahí a que estén repartidos por todo el mundo y con numerosas réplicas en él.

Esta es la mejor imagen que he encontrado que ilustra todo el proceso: caché del navegador, caché del PC, caché del ISP y de cómo este envía la petición recursiva:

Tipo de Registros DNS:

Hasta ahora hemos hablado sobre cómo funciona el sistema DNS, pero está incompleto. Hasta ahora podríamos hacernos la idea de que un servidor DNS es a groso modo un sistema que procesa las peticiones DNS recibidas con una gran base de datos en la que asocia una IP a un nombre de dominio. Pero esto no es cierto. Esta base de datos no está constituida por una asociación IP -> Nombre de dominio, sino por un conjunto de registros asociados a cada dominio. Esto otorga al sistema DNS de funcionalidades mucho más extendidas, que no simplemente el mero hecho de conocer la IP de un host. Estos registros almacenan cierta información sobre el dominio en cuestión, por ejemplo el registro A lo que contiene es precisamente la IP de dicho dominio.

Aun cuando en la actualidad la lista de posibles registros DNS es mucho mayor, la inmensa mayoría de toda la red continúa usando tan solo algunos de los registros DNS que se crearon originalmente, aquellos especificados en el RFC 1035. De este primer abanico de registros, algunos son experimentales como los registros MB o MR, mientras que otros como MD y MF fueron sustituidos por otros más usados y con la misma finalidad. Veamos los registros DNS que podríamos considerar “útiles” de esta primera especificación:

• A: Almacena la IPv4 del host, es decir, el mapeo de nombre de dominio – dirección IP de host.
• NS: Especifica un servidor DNS para dicho dominio, es decir, el servidor DNS autorizado para dicho host.
• CNAME: Más comúnmente conocido quizás como un alias. Es decir, especifica el nombre de otro nombre. Podría verse quizás como una redirección a nivel de DNS de un dominio a otro. Por ejemplo una entrada de este tipo: “correo.theliel.es CNAME gl2.gmail.com” significa que cada vez que se debe de resolver la IP para “correo.theliel.es”, se devolverá en su lugar la IP de gl2.gmail.com. En este caso, decimos que correo.theliel.es (o solamente correo, si damos por hecho que estamos en el dominio theliel.es) es un alias del host de google dado. Esto es usado constantemente. Hay que tener en cuenta que por su propia definición no es posible solicitar a un servidor DNS que nos respondan los alias de dicho dominio, pero sí podemos saber si un dominio/subdominio… dado es un alias de otro simplemente haciendo un ping. Veamos la diferencia entre hacer un ping a un alias o hacer ping a un host directamente:

  Ping a un alias:
  

  C:\Users\Theliel>ping earth.google.com
  Haciendo ping a www3.l.google.com [209.85.227.100] con 32 bytes de datos:
  
  Ping al host real anterior:
  

  C:\Users\Theliel>ping www3.l.google.com
  Haciendo ping a www3.l.google.com [209.85.227.139] con 32 bytes de datos:
  

  Al hacer un ping a un alias, este automáticamente nos “redirige” al host al que apunta el alias. Es decir, en los servidores de nombres de Google en algún lugar existirá una entrada de este tipo: earth.google.com CNAME www3.l.google.com. Para terminar indicar que aunque se puede hacer, no es recomendable anidar alias, es decir, un alias que apunta a otro alias que apunta al host.
  

• SOA: Marca el comienzo de una zona DNS, entendiendo por zona DNS algo así como el ámbito de acción de dicha red. Es decir, los servidores DNS de google forman una zona DNS que casi con toda seguridad englobaría todos los servicios de google, todas sus redes, etc… pero es evidente que los servidores DNS de google casi con toda seguridad no poseen registros de otras zonas DNS como las de Yahoo, Microsoft…

  El registro SOA por tanto contiene en primer lugar el servidor DNS principal de la zona, así como datos administrativos: correo del administrador, número de serie, temporizadores de refresco… datos concretos sobre la propia zona DNS.
  

• PTR: Puntero a un nombre de dominio. Su función principal es hacer resoluciones DNS inversas, es decir, en vez de obtener la IP por el host obtener el host por la IP. Un ejemplo de esto:

  C:\Users\Theliel>dig -x 74.125.77.104
  ; <<>> DiG 9.7.1rc1 <<>> -x 74.125.77.104
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1981
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
  

  ;; QUESTION SECTION:
  ;104.77.125.74.in-addr.arpa. IN PTR
  

  ;; ANSWER SECTION:
  104.77.125.74.in-addr.arpa. 86400 IN PTR ew-in-f104.1e100.net.
  

  Es decir si realizamos una resolución inversa de la IP 74.125.77.104 nos devuelve que es el host ew-in-f104.1e100.net, host de google.es
  

• MX: Registro de intercambio de correo. Este registro es fundamental para el uso del correo electrónico, mapea un dominio a un servidor de correo (o una lista de posibles candidatos). Cada vez que enviamos un correo electrónico a una dirección, es necesario conocer el servidor de correo de dicho dominio. ¿Cómo? A través de la consulta de sus registros MX. Una vez obtenemos el host de dicho servidor podemos conectarnos a él para entregar el correo. En realidad el funcionamiento del correo electrónico es muy simple. Si enviamos desde Gmail por ejemplo (interfaz web) un correo a una dirección @live.com, aunque no sea nuestro navegador quien haga la consulta, el servidor de google por nosotros para poder entregar dicho mensaje primero tiene que conocer la IP o el destino de dicho realm (el realm es el @live.com). Por ciencia infusa Google no puede conocer la IP del host al que debe de entregar el correo. Realizaría algo similar a lo siguiente:

  theliel@Anarchy:~$ dig live.com MX
  .
  …
  ;; QUESTION SECTION:
  ;live.com. IN MX
  

  ;; ANSWER SECTION:
  live.com. 2426 IN MX 5 mx1.hotmail.com.
  live.com. 2426 IN MX 5 mx2.hotmail.com.
  live.com. 2426 IN MX 5 mx3.hotmail.com.
  live.com. 2426 IN MX 5 mx4.hotmail.com.
  

  theliel@Anarchy:~$ ncat -C mx1.hotmail.com 25
  Connected to mx1.hotmail.com.
  Escape character is ‘^]’.
  220 col0-mc2-f34.Col0.hotmail.com Sending unsolicited commercial or bulk e-mail (bla bla bla)
  ehlo test
  250-col0-mc2-f34.Col0.hotmail.com (3.10.0.73) Hello [81.34.161.58]
  250-SIZE 29696000
  250-PIPELINING
  250-8bitmime
  250-BINARYMIME
  250-CHUNKING
  250-AUTH LOGIN
  250-AUTH=LOGIN
  250 OK
  mail from: <test@gmail.com>
  550 DY-001 Mail rejected by Windows Live Hotmail for policy reasons. We generally do not accept email from dynamic IP’s as they are not typically used to deliver unauthenticated SMTP e-mail to an Internet mail server. http://www.spamhaus.org maintains lists of dynamic and residential IP addresses. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. Email/network admins, please visit http://postmaster.live.com for email delivery information and support
  Connection closed by foreign host.
  

  Es decir, primero hay que conocer el servidor de correo, que es posible gracias a una consulta DNS de su registro MX. Este servidor nos responde con una lista de hosts disponibles, TODAS en esta ocasión con la misma prioridad (el número 5 que las precede, a menor número mayor prioridad a la hora de conectarse a uno u otro). Una vez que disponemos ya del host (mx1.hotmail.com en este caso) podemos conectarnos a él. OJO!! aunque se da ya por sabido en realidad cuando intentamos conectarnos al host citado, nuestro sistema deberá realizar otra petición DNS para conocer la IP del host mx1.hotmail.com, consultando el registro A de dicho dominio. Una vez que se realiza la conexión (en mi caso de ejemplo con ncat) el servidor de Gmail intentaría algo como lo expresado, mail from: <test@gmail.com>. En este caso el servidor de correos de live.com no nos permite continuar dado que detecta que la IP origen es dinámica (cuestiones de seguridad de los servidores de correo). En el caso de Gmail permitiría la conexión. Evidentemente es solo un ejemplo.
  

• TXT: Es un registro reservado para cualquier tipo de información que se quiera añadir. A día de hoy se usa para una gran multitud de propósitos, ninguno específico.

No obstante, con el paso de los años se han ido haciendo necesario algunos registros adicionales, y a esta lista inicial deberíamos de añadir algunos más para poder dar la lista como “completa”, aunque evidentemente existan muchos otros registros, aunque también mucho menos usados:

• AAA: Si el registro A mapeaba hosts a direcciones IPv4, es necesario disponer de un registro DNS que permite devolver del mismo modo direcciones IPv6. Su función es exactamente la misma, salvo que en vez devolver los 32bits de una IPv4 nos devolverá los 128 bits de la dirección IPv6.
• SRV: Registro de servicios, otorga información sobre ciertos servicios. A día de hoy su uso es fundamental en aplicaciones tipo VoIP o muchos otros servicios modernos que dependen de una forma u otra de servidores más o menos específicos.

Paquete DNS:

Las peticiones DNS a fin de cuentas son datos que se envían, y al igual que una petición HTTP, este tiene su estructura por así decirlo. No obstante, DNS opera en el nivel de aplicación, por tanto hace uso de otros protocolos inferiores como UDP o IP para transmitirse. DNS usa el protocolo UDP para enviarse, usando el puerto 53 para tal efecto:

1 0.000000000 192.168.x.124 192.168.x.1 DNS Standard query A theliel.es
2 0.117633000 192.168.x.1 192.168.x.124 DNS Standard query response A 188.121.46.128

Problemas y soluciones a DNS:

Existen ciertas limitaciones en cuanto al sistema DNS. En realidad no son limitaciones en sí, sino problemas que surgen con los años. Para empezar y el más importante quizás es que DNS como tantos otros protocolos no se crearon para ser seguros, sino eficientes. Pensar por ejemplo que cualquiera podría construir un servidor DNS e intentar suplantar unas peticiones por otras malignas. O realizar ataques de envenenamiento DNS (que se verá en otro momento).

A todo esto se añade el problema de los actuales hosting virtuales, que permiten albergar en el mismo host diferentes servidores web funcionando al mismo tiempo. Con esto nos topamos cada día y nadie se pregunta en realidad cómo es posible, dado que un registro A tan solo devolverá la IP de un host, no la web que se quiere acceder a él. Es decir imaginar que deseamos acceder a una web http://ejemplo.com. Para poder realizarse la conexión es necesaria conocer la IP e imaginemos que la IP es 2.2.2.2. Ahora bien, en teoría solo bastaría una conexión a dicha IP por el puerto 80 y mediante el protocolo http para recibir dicha web. El problema aparece cuando en dicho host hay múltiples servidores web funcionando todos en el mismo puerto y al mismo tiempo. Es por eso que si en el navegador intentamos acceder a estos servidores por IP no podremos. Como saben estor servidores que web devolver? Gracias a las cabeceras HTTP que sirven de referencia al servidor para conocer la web que debe de devolver.

Por último y no menos importante son los conocidos como DDNS, o DNS dinámicos. Ya hemos visto la importancia de un dominio, y que los servidores DNS se van actualizando con el tiempo para tener siempre actualizada la IP a la que apuntan dichos nombres de dominio. No obstante la IP de un host no debería de variar demasiado, pero que sucede si tenemos un dominio que queremos que apunte a un host que posee una IP dinámica? Pues bien, existen servicios tanto gratuitos o de pago para sofocar esto. El sistema funciona de forma muy simple:

1. Se nos otorga un dominio, normalmente un subdominio de segundo nivel, tipo “pepito.dyndns.org”
2. Dado que nuestra IP puede variar incluso con cada conexión a la red, se crea una aplicación cliente que envía los datos de la nueva conexión cada vez que la conexión se debe de actualizar, y estos datos los envía precisamente a este proveedor de servicios, en este caso dyndns. Esta aplicación cliente enviaría nuestra IP actual, nombre de usuario y contraseña y con esos datos ellos actualizarían sus servidores DNS para actualizar así la IP asociada a dicho dominio.
3. Nuestro host, aun teniendo una IP dinámica siempre sería accesible por medio del servicio de DDNS proporcionado por dyndns.

Para que esto sea posible SIEMPRE debe de existir una aplicación cliente que sea la que se encargue siempre de enviar los datos de la nueva conexión al servidor del proveedor. Lo que se hace a día de hoy para facilitar esto es añadir soporte en los propios routers para esto, es decir, muchos routers poseen internamente clientes DDNS, de modo que en realidad todo el proceso queda completamente transparente al usuario, este tan solo tiene que configurar el router y una vez realizado, cada vez que la IP cambia el router conecta con el servidor del servicio y actualiza la IP. Como digo es un servicio muy importante a día de hoy, sobre todo para aquellos que necesitan acceder a servicios de su red de forma remota sin importar la IP de esta.

Protocolos TCP y UDP

En conjunto con el protocolo IP conforman el núcleo principal de prácticamente todas las redes existentes a día de hoy, recordemos que estamos usando el modelo TCP/IP, luego el protocolo TCP seguro que jugará un papel importante.

Estos dos protocolos serán básicamente los dos únicos protocolos a nivel de transporte que vamos a tener. Podríamos añadir en todo caso SCTP usado para streaming, pero vamos… el 99% de todo el tráfico se gestiona por uno de estos dos protocolos. Recordemos que el nivel de transporte será quien establezca una comunicación entre aplicación origen- aplicación destino (en los niveles inferiores en realidad las comunicaciones son entre nodos). La idea es proveer a la comunicación con ciertos mecanismos como el control de flujo, detección de errores y otras cuestiones que iremos viendo.

Como hemos dicho veremos dos protocolos tan solo:

• UDP (User Datagram Protocol)
• TCP (Transmission Control Protocol)

Vamos a ver primero UDP por su gran sencillez, sería prácticamente la mínima expresión. A partir de este no obstante es mucho más simple comprender un protocolo bastante más complejo como TCP. Pero antes de entrar en los protocolos en sí hay que hablar de los puntos de accesos a estos, dado que será algo primordial para estos: Los puertos.

Puertos:

De cara al modelo TCP/IP o modelo OSI, los puertos serían los SAP del nivel de transporte, los puntos de acceso. Visto de forma más práctica los puertos permiten conexiones múltiples simultáneas entre distintos o iguales hosts sin que ninguna conexión interfiera en la otra. Visto de un modo más simple aun, los puertos serían las diferentes entradas/salidas en las comunicaciones.

Cuando un host desea enviar un mensaje a otro por medio de TCP o UDP primero debe de solicitar al OS un puerto de salida por el cual poder realizar la comunicación. Del mismo modo que necesita de un puerto de salida, dicho mensaje deberá de especificar ya no solo el destino (la IP o el nombre de host), sino el puerto al que quiere acceder en dicho host e informar al destino de puerto de salida que está usando para la comunicación, a fin de que el destino pueda contactar del mismo modo con el emisor. La necesidad del puerto de salida es clara, por algún lado tiene que salir el mensaje. ¿Pero y el puerto de entrada? En realidad es igualmente importante, ya que tanto puertos de entrada/salida se asocian generalmente a servicios/aplicaciones concretas. Es decir, gracias a estos puertos ya no solo debemos de especificar un host destino, sino que dentro de este, a que servicio o aplicación deseamos enviarle el mensaje.

Estos puertos se identifican como un número entero sin signo de 16 bits, es decir, un número comprendido entre el 0 y el 65535. Estos números hacen de ID de puerto por así decirlo. Estos puertos no son compartidos es decir, existirán por tanto 65536 puertos para TCP enumerados de 0 a 65535 y otros tantos para UDP enumerados exactamente igual, es por ello que el número del puerto no especifica si es UDP o TCP, esto es importante.

Como he dicho el 99% de todas las comunicaciones que hacemos se basan en este concepto, aun cuando no lo sepamos porque el proceso sea transparente a nosotros. El mejor ejemplo de esto es por ejemplo la navegación web. Hemos hablado de la necesidad de la IP o de las DNS, pero nadie ha visto en ningún momento nada parecido a un puerto o a un número que no sea la IP y que podamos imaginar que es un puerto. Pero esto es porque los navegadores lo hacen de forma implícita. Cuando en un navegador especificas por ejemplo “http://” estás especificando el protocolo http que por defecto (no significa que no pueda ser otro) se le asocia el puerto 80. Es decir, si en el navegador accedemos a la web http://www.google.es se realizará una petición al host www.google.es por el puerto 80 TCP, y con puerto no me refiero al puerto de salida de nuestro host, sino el puerto destino del host remoto.

Esto de que el puerto 80 esté asociado a los servidores web es así porque la IANA estableció que el puerto 80 sería el puerto “conocido” para el servicio web. En realidad la IANA mantiene un extenso listado con todos los puertos “conocidos”, así como los puertos registrados. Pero esto no quiere decir que los servicios de dicha lista se deban de asociar a dichos puertos, dado que un administrador de sistemas tiene siempre la última palabra sobre qué puerto asociar a que servicio. De todos modos esto tiene su lógica. Si se establece que el puerto para web será el 80, cualquier aplicación estará configurada para ello y no será necesario conocer en cada ocasión el puerto, lo mismo sucede con infinidad de puertos. Otras veces en cambio lo deseable puede ser exactamente lo contrario, y por motivos de seguridad no queremos asociar un servicio a su puerto preestablecido.

Se podría decir que generalmente tan solo los puertos de destino suelen tener un servicio asociado, pero esto sería incorrecto dado que un puerto de entrada se convierte en puerto de salida cuando tiene que enviar un mensaje. Así que podríamos matizar diciendo que generalmente los puertos de salida al iniciar la comunicación no suelen estar asociados. Por ejemplo, si realizamos una petición http al servidor web de google, sabemos que debemos de enviarla al puerto 80 TCP, ¿pero por qué puerto saldrá el mensaje de nuestro equipo? podríamos pensar en primer lugar que por el mismo puerto, que por el 80, pero esto no es así, el puerto 80 lo usaríamos para enviar datos (lo normal claro) tan solo de tener instalado un servidor web. Luego… ¿qué puerto se usará de salida? En este caso lo normal es que el navegador solicite una conexión de salida al OS, y sea el propio sistema quien le asigne un puerto que en ese momento no esté en uso para realizar dicha conexión, posiblemente entre un rango de puertos ya preestablecidos. Es decir, cada comunicación que hagamos incluso para navegar, el puerto de salida de nuestro mensaje será diferente casi el 100% de las veces. Es más, ahora mismo por ejemplo mi navegador Firefox mantienen de forma simultanea 5 conexiones activas, usando los puertos de salida 44384, 44385, 44387, 44388 y 44389, pero esto es en este mismo instante!! en cuanto la conexión TCP finalice y se abra una conexión TCP nueva, se le asignará un nuevo puerto de salida, y así el navegador quedará mientras dure la conexión “a la escucha” de dicho puerto preparado para recibir cualquier información que entre por él, que es de suponer que el mismo navegador estará esperando. Evidentemente los puertos que ya no están en uso se reutilizan sin problema alguno.

Podemos decir también que un puerto tiene 2 estados fundamentales, Abierto y Cerrado. Para que un puerto pueda enviar/recibir información, debe de estar abierto, es decir, algún servicio o programa asociado a él. Cuando en el ejemplo anterior nuestro navegador tiene que comunicarse con el puerto 80 TCP de un servidor web, antes de poder realizar la conexión el OS asocia a dicha aplicación (Firefox) el puerto temporal para la comunicación, digamos que el puerto queda abierto. Al otro lado en cambio, el puerto 80 del servidor web estará permanentemente abierto a la espera de cualquier comunicación externa entrante, el puerto 80 en este caso estará asociado a por ejemplo un servidor web Apache o IIS. En cambio, el puerto temporal abierto por el OS para Firefox para dicha conexión estará abierto tan solo el tiempo que dure la comunicación, cuando esta finalice, el puerto se cerrará. Esto es muy importante de cara a la seguridad como se verá en otro momento.



UDP:

Es un protocolo no orientado a la conexión, es decir, no provee ningún mecanismo de control de flujo, ni tampoco implementa ningún sistema propio de detección de errores o de pérdida de mensajes/datagramas (en nivel 4 no se puede hablar ya de paquetes, que es propio del nivel 3). Aunque en realidad el término “orientado a conexión” hace referencia a que no es necesario una negociación previa entre los dos dispositivos para comenzar la comunicación. Cuando tratamos con UDP debemos de tener claro por tanto que a este protocolo no le importa si se pierden datos en el camino, es más, el destino puede incluso estar saturado o colgado y UDP no tendrá constancia de ello, como si el puerto de comunicación está abierto o simplemente no es válido.

Esto parece tener muchos inconvenientes, pero en cambio todo depende de la aplicación que necesite enviar los datos o qué tipo de datos sean. Por ejemplo, la corrección de errores o el control de flujo puede implementarse a nivel de aplicación, o simplemente la pérdida de datagramas podría no ser importante, cosa muy habitual por ejemplo en aplicaciones en tiempo real como juegos online, Streaming, VoIP… ¿Pasa algo si 1 de cada 1000 datagramas se pierde en una videoconferencia? Pues la verdad es que prácticamente no afecta absolutamente en nada, a lo mejor vemos en ese momento un punto de otro color en la imagen recibida de la webcam del otro usuario, o puede que la conversación tenga un poco de más ruido de fondo, pero para nosotros es mucho más importante la fluidez de la conversación a la calidad de esta. Puede que UDP tenga muchos puntos negativos, pero no hay que verlo como negativos, sino como características, que dependiendo de la situación son mucho más deseables que otras. ¿Cuál es el objetivo por tanto de UDP? es fácil, la transmisión rápida de datos, la sencillez de la comunicación, en que prácticamente no hay que ocuparse de nada.

Hay que tener en cuenta que cuanto más complejo es un protocolo más sobrecargado está, y esto tiene un impacto notable en el uso de las redes. Imaginar que solo quiero enviar la palabra “Casa” a otro host. Con UDP me vasta dos datos y medio y lo envío. En TCP como ya veremos tendríamos que negociar la conexión, enviar los datos, cerrar la conexión… y todo ello además con cabeceras mucho más grandes en fin.. que a lo mejor en vez de enviar 20 bytes tendríamos que enviar 200 bytes para la misma tarea.

Como hemos dicho UDP no requiere del establecimiento de una conexión previa, de ningún sistema de acuerdo entre los dos hosts. Si un host quiere enviar un mensaje UDP a otro, tan solo tiene que (a nivel de transporte claro está) rellenar la cabecera UDP y adjuntar los datos que quiera:

• Puerto de Origen/Puerto de Destino (16 bits cada uno): Especifica el puerto de origen y el puerto de destino del mensaje UDP. Al ser un número de 16 bits se infiere que tendremos un máximo de 65536 puertos posibles
• Longitud (16 bits): Es un registro ya típico, en este caso especifica la longitud en bytes de todo el mensaje UDP, incluyendo tanto cabecera como el SDU del nivel superior, es decir, los datos realmente. Hay que recordar que cada nivel normalmente añade/elimina su propia cabecera a los datos recibidos y los envía hacia abajo o hacia arriba en el modelo TCP/IP. Dado que la cabecera tiene un tamaño fijo de 64 bits, la longitud mínima para un mensaje UDP sería 8 Bytes, es decir, un mensaje UDP vacío. Por la misma razón, la máxima cantidad de datos que se pueden enviar por un mensaje UDP sería 64K menos 8 Bytes.
• CheckSum (16 bits): La detección de errores en este caso es un poco peculiar, y además, en IPv4 es opcional (obligatoria en IPv6, recordemos que IPv6 NO tenía comprobación de checksum a nivel de protocolo IP). El algoritmo que usa es exactamente el mismo que el que se realiza en IP, se realiza el complemento a uno a la suma en complemento a uno resultante de cada palabra, pero en este caso no se hace sobre la cabecera de UDP, sino sobre la llamada pseudo cabecera UDP. Esta cabecera en realidad no existe, tan solo es una composición que se crea para crear el checksum. Esta cabecera está compuesta por la IP de origen, la IP destino, un byte de ceros, un registro que especifica el protocolo y otro registro que especifica la longitud del mensaje UDP, es decir, esta cabecera virtual toma algunos elementos de la cabecera IP. Pero repito, tan solo se “construye” esta cabecera para calcular el checksum, esta cabecera como tal no existe, no se transmite.

Eso es todo. Es la mínima expresión, una cabecera con lo mínimo, en que lo más “complejo” puede ser el checksum y que ni siquiera es obligado en IPv4. Después de la cabecera evidentemente se adjuntarían los datos del nivel superior, el SDU, que junto a la cabecera conformarían el 4PDU, el mensaje UDP completo que pasaría al nivel de red (en caso de que se esté enviando).

¿Cuál es el mejor ejemplo de mensaje UDP? Los mensajes DNS, DNS se transmite por medio de mensajes UDP. Qué pasa si se pierde un mensaje DNS? Pues posiblemente que si el navegador o el host tenga un tiempo de espera predeterminado para la petición DNS, si no recibe la respuesta casi de inmediato, enviará casi seguro una segunda o una tercera petición. Pero no es algo que requiera una integridad especial o una complejidad enorme. Además, son mensajes que se están retransmitiendo constantemente. Usar TCP para mensajes tan cortos sería hacer un uso enorme de la red tan solo para las peticiones DNS. Con UDP funcionan el 99% perfectamente, y hacen un uso muchísimo más optimizado de la red. Además, cuanto más pequeños sean los mensajes, menor probabilidad de errores existirá en su retransmisión.

TCP:

Es todo lo contrario a UDP. Para empezar, es un protocolo orientado a conexión, es decir, requiere del establecimiento previo de una conexión antes de poder comenzar a retransmitir datos. Es infinitamente más complejo que UDP, pero por otro lado TCP hace posible comunicaciones fiables, tolerantes a fallos, con una buena gestión del control de flujo… aunque todo ello requiere por ende un protocolo más complejo, una cabecera más grande y una menor cadencia a la hora de transmitir datos en definitiva.

Al igual que le pasara a UDP, no se puede ver esto como algo negativo, sino como algo necesario para poder tener una comunicación fiable para aplicaciones que así lo requieren. Posiblemente el caso más ilustrativo sería la navegación web por ejemplo. Una web puede pesar considerablemente, desde unos KBs a MBs de datos. Que importa en este caso gastar unos KBs de más si nos garantizamos que el navegador recogerá correctamente la información del servidor opuesto. Pensar cuando enviamos un formulario (al margen de que se pueda enviar o no por protocolos seguros como TLS/SSL), no podemos permitirnos en modo alguno que al servidor no le llegue un mensaje TCP correcto, dado que ese mensaje podría ser desde un número diferente en el DNI, en el nombre o en cualquier otro lugar. Recordar que protocolos como UDP no tienen siquiera ningún mecanismo para saber si los datos han llegado o no, mucho menos si lo hicieron correctamente. En la mayoría de las comunicaciones necesitamos saber que los datos se han enviado correctamente o se han recibido sin errores.

Existen pues muchas aplicaciones que hacen uso de ambos protocolos, por ejemplo la mayoría de programas P2P o juegos online. ¿Por qué? Habilitan por ejemplo un puerto UDP para maximizar el envío/recepción de datos, y se usa la misma aplicación para controlar que estos lleguen en buen estado. Pero a la par se usa un puerto TCP para aquellas cuestiones que si requieran precisión, normalmente pequeños mensajes, pero que sí necesitamos conocer que han llegado y en buen estado:

• Puerto de Origen/Destino (16 Bits cada uno): Tiene exactamente el mismo uso que el citado en el protocolo UDP, especifica mediante un entero sin signo el puerto de origen que usará el mensaje TCP, así como el puerto destino al que va dirigido.
  
• Número de Secuencia (32 bits): Recordemos que TCP posee funciones de control de flujo, esto significa que de algún modo cada mensaje enviado tiene que ser claramente identificable de otro. Esto quiere decir que si dos mensajes TCP llegan al destino de forma desordenada, el host receptor podría ordenarlos perfectamente dado el número de secuencia. Del mismo modo si se recibe un mensaje cuyo número de secuencia no concuerda con el esperado, el mensaje podría descartarse por interpretar que dicho mensaje es ajeno a la comunicación actual entre los dos hosts, por ejemplo un mensaje inyectado desde un tercer host que intentase manipular la conversación entre ambos. Si el flag Syn (S) no está especificado, será el número de secuencia del primer octeto (byte) de datos adjuntos en dicho mensaje (después de toda la cabecera). En cambio, si el flag Syn está habilitado, el primer octeto adjunto en dicho mensaje será el número de secuencia + 1.
  
• Número de ACK (32 bits): La gran mayoría de las veces, para nosotros un ACK será un mensaje o paquete de confirmación. Este tipo de mensajes son muy comunes en gran multitud de protocolos, son como pequeñas señales de respuesta para indicar que se ha recibido la información. Gracias a estos mensajes también solucionamos el problema de conocer si un mensaje llega correctamente o no a su destino, dado que si llega, el destinatario nos responderá con un ACK (ACK proviene de Acknowledgment). Por ello, si el flag ACK (A) está activado, el número de ACK corresponderá al próximo número de secuencia del mensaje que espera recibir por parte del emisor. Es decir, en el caso de que la comunicación sea correcta, si un host envía un ACK con número de ACK “200″, significará que está esperando que el otro host le envíe un mensaje (del tipo que sea) con un número de secuencia de 200.
  
• Offset (4 bits): El número de bloques de 32 bits que ocupará la cabecera, por tanto indica cuando empiezan los datos (el SDU). Como ya se viese en el protocolo IP, para que este tipo de registros sean posible es necesario que la cabecera siempre sea múltiplo de 32 bits, lo cual se hace con un padding, puesto que existen campos en la cabecera de longitud variable.
  
• Reservado (6 bits): bits reservados, se deben de establecer a cero.
  
• Flags (1 bit cada una): Los flag o banderas son bits que básicamente dicen cuando un flag está activado o no. Cada uno de esos bits especifican algo concreto:

  URG (U): Usado conjuntamente con el campo “Puntero Urgente” para especificar que existe un dato en el mensaje que debe de ser procesado con anterioridad.
  ACK (A): Usado conjuntamente con el número de ACK para indicar una contestación, como ya se ha explicado.
  PSH (P): Esta señal está relacionada directamente con la ventana del protocolo TCP que se verá a continuación. Si el flag PSH es especificado, el mensaje por pequeño que sea será enviado.
  RST (R): Básicamente es una bandera que de habilitarse indica al otro host que reinicie la comunicación, algo así como un reset de la sesión.
  Syn (S): Formalmente realiza la sincronización del número de secuencia. El primer mensaje enviado por cada una de las partes al otro tendrá activada el flag Syn, es decir, al inicio de la comunicación.
  FIN (F): Se usa para comenzar o forzar el cierre de la sesión. Técnica significa que no serán enviados más datos por parte del emisor.

  
  

• Ventana (16 bits): Especifica en Bytes el tamaño de la ventana de recepción. Es decir, el tamaño máximo (comenzando desde el número de secuencia de ACK) de datos que puede recibirse en una comunicación TCP, antes de contestar con un ACK. En realidad esta ventana no es más que un buffer, cuyo tamaño queda especificado por este campo. Cuanto mayor sea el tamaño de ventana se obtendrá una mayor cadencia en los datos (el término exacto es throughput, pero creo que no existe un equivalente exacto en español). En contra partida, una ventana grande es perjudicial cuando la calidad de la red no es demasiado buena, puesto que en caso de error (por pequeño que sea), se requerirá enviar de nuevo toda la ventana completa, repercutiendo negativamente en el rendimiento. No es lo mismo a fin de cuenta enviar un mensaje de 1 byte en un byte, teniendo en cuenta que entre byte y byte hay que responder con un ACK, que enviar un mensaje en bloques de hasta 64KB, lo cual es muchísimo más eficiente… aunque menos seguro y menos fiable.

  A día de hoy cada vez se está optando por incrementar casi al máximo las ventanas de recepción, o en caso de Windows por ejemplo permitir al propio OS establecer de forma dinámica el tamaño de esta en función de la calidad de la comunicación y otros factores.

  
  

• CheckSum (16 bits): El sistema de comprobación de errores de TCP es el mismo que el que se explicó en UDP.
  
• Puntero Urgente (16 bits): Especifica un desplazamiento de Bytes (comenzando desde el número de secuencia) en el que se encuentra el primer byte que se ha tipificado como “mensaje urgente”
  
• Opciones y Padding (Variable): Especifica una serie de opciones que pueden añadirse antes del SDU. Dado que se debe de conservar la divisibilidad entre 32 Bits, se usará un padding rellenando de ceros para cubrir siempre cualquier pico que pudiese existir en dichas opciones.
  

Es evidente que la complejidad aquí es mucho mayor que en UDP. Describir el funcionamiento de todo el protocolo sería algo inviable, y para eso están las especificaciones oficiales en el RFC 793. No obstante, aunque no se explique cada uno delos posibles casos pueden darse en una comunicación TCP, si es interesante ver a groso modo como se llevaría a cabo una comunicación modelo, sin entrar en demasiados detalles, en lo que sería el establecimiento y cierre de la comunicación. Como digo esto es tan solo una pequeña parte de todo el protocolo TCP, se pueden presentar un millón de posibilidades y de comportamientos anómalos en la conexión y la respuesta de cada host a dicho comportamiento está en algunos casos especificados y en otros no. De todos modos, esto se podrá ver en otros temas, como por ejemplo en los escáneres de puertos, donde es muy importante conocer el funcionamiento de estos protocolos:

Sabiendo los registros de la cabecera, se puede más o menos inferir las características de TCP. Por ejemplo, la fiabilidad en los datos enviados/recibidos queda asegurada gracias a los números de secuencia, por los cuales es posible conocer el orden incluso en el que deben de llegar los mensajes, o en caso de que un mensaje no sea recibido el host emisor puede ser informado sobre ello para reenviar de nuevo el mensaje perdido. El número de secuencia de ACK tiene un cometido similar, dado que si el emisor no recibe el ACK de un mensaje que ha enviado, puede interpretar que el mensaje no ha sido recibido y podría enviarlo de forma automática de nuevo, mientras que de cara al receptor si le llegan dos mensajes con el mismo número de secuencia (por ejemplo porque el emisor ha reenviado el mensaje y el primero no llegó por una latencia excesiva de la red) ignoraría simplemente el segundo, siempre y cuando el número de secuencia fuese correcto, si recibe un número de secuencia erroneo simplemente descartaría el mensaje.

Por otro lado, el uso de una ventana (buffer) también garantiza un correcto control de flujo, mientras que técnicas como los algoritmos de congestión de red hacen posible que la comunicación sea todo lo fluida que se pueda cuando la intensidad del tráfico amenaza la comunicaicón. Estos algoritmos se basan simplemente en los mismos flags de las conexiones TCP para ajustar ciertos parámetros como la ventana de recepción, el tamaño máximo del mensaje (especificado en las extensiones de la cabecera TCP) o la gestión de ACKs. Por ejemplo, el algoritmo de congestión que puede usar Windows Vista/7 se llama Compound TCP. Este algoritmo posee dos ventanas, las cuales aumentan en tamaño o disminuyen en función del retraso en las comunicaciones. De forma similar actáa por ejemplo el protocolo de congestión por defecto de Linux: TCP Cubic. A la par que las comunicaciones son más rápidas y fiables, es normal que los algortimos de congestión usados vayan cambiando con el tiempo, dado que el que es bueno ahora no lo será mañana.

Protocolo Ethernet y ARP

Llegados a este punto sería conveniente hablar de Ethernet, aunque sin entrar en mucho detalle sobre este. Ethernet es un protocolo… una tecnología para redes locales. Al ser un protocolo de nivel 1 y 2, tiene más componentes físicas que informáticas. Por ejemplo, Ethernet tiene sus propios estándares para cables que pueden usarse, conectores, hardware… cuestiones que podrían ser interesantes ver, pero que se escapan al alcance de este capítulo. Ahora veremos Ethernet como el protocolo de nivel más bajo que tendremos dentro del modelo TCP/IP o modelo OSI, y será la misma tecnología Ethernet y sus protocolos los que convertirán al final los datos en meras señales eléctricas que serán transmitidas por un cable.

Desde el punto de vista físico, para nosotros tan solo nos interesa conocer cuestiones como la velocidad, modo de funcionamiento y tipo de medio. Desde el punto de vista lógico nos interesa no obstante conocer la estructura de un frame ethernet.

Físicamente para nosotros podemos diferenciar 3 estándares atendiendo a la velocidad de enlace de Ethernet: Ethernet, Fast Ethernet y Gigabit Ethernet, La diferencia de ellos es por tanto el ancho de banda posible. ASí, Ethernet tiene una capacidad máxima de transmisión de datos de 10Mb/sec (ojo!! Megabits, no MegaBytes), Fast Ethernet 100Mb/s y GigaEthernet una capacidad de 1000Mb/s. Actualmente existen estándares menos usados domésticamente como 10 GigaEthernet o 100 GigaEthernet, cuyos nombres son completamente descriptivos.

De cara al medio, estamos acostumbrados a ver Ethernet siempre usado sobre el famoso cable “Categoría 5e” y conectores RJ45. Este cables son a groso modo 4 parejas de hilos trenzados. Pero esto es solo una de las especificaciones de Ethernet, ya que en realidad Ethernet puede ser usado no solo sobre estas parejas de hilos trenzadas, sino por ejemplo sobre fibra óptica también. Lo que sucede es que los cables de hilos trenzados son infinitamente más baratos que otras infraestructuras como pueda ser la de fibra óptica, por no hablar de la facilidad de crimpar (añadir un conector a un extremo de un cable) a un cable de hilos trenzados a uno de fibra, o la flexibilidad de uno y de otro. Actualmente sobre hilos de cobre trenzados es posible llegar hasta 10GigaEthernet, mientras que sobre fibra hasta los 100GigaEthernet. De todos modos, lo más común, barato y cómodo para un usuario doméstico son los estándares 100BaseT y 1000BaseT, es decir, Fast Ethernet y Giga Ethernet sobre cables de cobre trenzados. En el caso de 100BaseT se usarán 4 hilos en total de un cable de pares trenzados Categoría 5 como mínimo, mientras que en redes GigaEthernet requeriremos de los 4 pares de hilos de un cable Categoría 5e o Categoria 6. En ambos casos, el estándar asegura una longitud máxima de cable entre nodos de 100 metros, a partir de los cuales sería necesario regenerar la señal. Como nota personal, en entornos especialmente ruidosos o cuando dichos cables serán usados externamente, recomendaría que los cables fuesen apantallados para aislar mejor las interferencias, aunque esto es tan solo opcional.

Desde el punto de vista del modo de funcionamiento, tan solo decir que Ethernet puede funcionar tanto en Half-Duplex como en Full-Duplex. Esto se verá más en detalle en otro capítulo cuando se vean Hubs y Switchs.

Desde un punto de vista lógico tenemos que ver como es un frame Ethernet, y teniendo en cuenta los diferentes protocolos que hemos visto hasta ahora, Ethernet no supondrá mayor problema. Un frame Ethernet II (los frames usados a día de hoy) no poseen otra cosa que la dirección MAC origen y destino, el protocolo superior que lo usará, los datos que portará y un checksum:

Cuando se trató el protocolo IP se mencionó MTU como unidad máxima de transmisión, que es una limitación de la red y no del mismo protocolo IP, ya que el protocolo IP podía incluir paquetes de hasta 64KB. Pues bien, ese MTU proviene de los niveles inferiores, en caso de usar redes Ethernet dicha limitación procede de aquí. ¿Por qué dijimos que lo normal para conexiones ADSL es un MTU de 1492 Bytes? El 99% de las redes locales domésticas son redes Ethernet. Como podemos apreciar perfectament en la imagen superior, los frame Ethernet tienen un tamaño mínimo de 64 bytes y un tamaño máximo de 1512 Bytes. De esos 1512 Bytes, 1500 son los reservados para los datos adjuntos. Dado que nuestros equipos se comunican principalmente por cable a nuestros routers, estos enlaces son Ethernet con un MTU de 1500. Pero por otro lado, la mayoría de nuestras conexiones ADSL están apoyadas por el protocolo PPPoE (Punto a Punto sobre Ethernet), el cual (el protocolo) tiene una cabecera de 8 Bytes. Es decir, el tamaño máximo de los datos que pueden enviarse por medio de una conexión ADSL mediante PPPoE debería de ser exactamente 1492, dado que PPPoE usa frames Ethernet. Ahora bien, esto no quiere decir que un MTU de 1942 para conexiones ADSL PPPoE sea el óptimo, pero explicar esto implicaría de nuevo salirnos del ámbito de este capítulo.

Hay que tener bien presente que estos frames existen tan solo para nosotros, para nuestra red local Ethernet, y en el caso específico de las conexiones ADSL PPPoE. Siempre que usemos un Sniffer para ver que tipos de frames nos están llegando hay que comprender bien esto, dado que podemos ver solo lo que llega a nuestros equipos, no como dichos datos son transportados desde un punto del planeta a otro, hablamos por tanto en este caso de un protocolo de puertas para dentro.

De la cabecera Ethernet II anterior, EtherType especifica el protocolo inmediato contenido en los datos adjuntos. Así por ejemplo, para un paquete IPv4, EtherType tendrá un valor de 0×0800, 0x86DD para IPv6, 0×8863 y 0×8864 para PPPoE, o un valor de 0×0806 si es el protocolo ARP. Para quien quiera una lista completa puede verla en el estándar de la IEEE de los tipos de redes Ethernet

Una dirección IP es una dirección lógica asociada a un host, mientras que una dirección MAC es una dirección “física”. Quizás el término dirección física no sea realmente correcto, pero sí podemos decir que una dirección MAC especifica inequívocamente una interfaz NIC (o al menos debería). Tal y como se plantea toda la red de Internet, así como los protocolos TCP/IP y DNS, parecerá innecesario un protocolo como ARP, pero sin embargo es un protocolo crucial, sobre todo dentro de redes locales como las redes Ethernet (casi todas las redes locales).

Gracias al protocolo IP podemos encontrar en el globo un host simplemente conociendo su dirección IP. Pero esta dirección no es más que una dirección lógica. En IPv6 esto es diferente dado que la asociación IP-NIC es casi estructural, pero en IPv4 esto no es así ni mucho menos. Volviendo al tema principal, puede que una dirección IP especifique un host en internet, pero… ¿Como saben los equipos o los routers a que interfaz de red enviar dichos paquetes? Es importante conocer siempre lo que pueda ser la parte física de una comunicación a la parte lógica. Podemos pensar en la parte física aquello que podemos tocar o ver: Cables, Routers, Switchs, Bridges, Interfaces de Red (NIC)… hardware a fin de cuenta. En cambio, en la parte “lógica” tendríamos fundamentalmente los protocolos de comunicación que funcionan sobre esa parte física, y en última instancia bits de datos que circulan de un lado a otro. Pues bien, en algún punto por tanto es necesario unir esa parte física con esa parte lógica, y el protocolo ARP se encarga de ello, al menos en cuanto a conocer el origen/destino de un paquete IP.

El protocolo ARP será el encargado por tanto de conocer el host físico emisor/receptor de un paquete por medio de su IP, dicho de otro modo, el protocolo ARP se encargará de saber las direcciones MAC de las NIC. El protocolo IP trabaja en el nivel 3 del modelo OSI (nivel de red), TCP/UDP son protocolos del nivel 4 (de transporte), mientras el protocolo DNS es un mensaje concreto UDP (luego es un protocolo a nivel de aplicación). ¿A que nivel pertenece por tanto ARP?

El problema del ámbito de ARP no es nuevo. En teoría es un protocolo a nivel de enlace de datos (nivel 2), pero no obstante para que ARP pueda trabajar correctamente necesita tener acceso al nivel 3 para conocer la IP. Si vemos esto desde un modelo OSI estricto, ARP quedaría fuera de este, dado que requeriría acceder a ambos niveles, lo cual violaría los principios del modelo OSI. Pero por un lado el modelo usado actualmente es TCP/IP, y por otro podríamos ver el modelo OSI como algo más flexible. Otros expertos concluyen que aun cuando el modelo OSI fuese completamente fijo e inflexible, ARP no violaría el modelo, dado que su función es meramente de nivel de red, con la única salvedad de que porta datos pertenecientes a IP, y que por tanto ARP es un protocolo de nivel 2. Personalmente creo que las dos opciones son correctas. No se puede ver el modelo TCP/IP u OSI como algo completamente rígido, y tampoco podemos pensar en que un frame solo puede contener datos propios. Quizás el ejemplo más significativo estaría en el protocolo ICMP. Sin entrar en detalle a explicar este protocolo, ICMP depende y se apoya sobre IP, con lo que debería de ser un protocolo superior a IP, pero en realidad no presta ningún servicio de transporte o de nivel superior. ICMP es un protocolo puramente de nivel 3, aunque necesite o se apoye en IP. Bueno, de forma similar podríamos ver ARP. Para mi por tanto ARP es un protocolo de nivel de enlace de datos (nivel 2), pero quizás sería correcto decir que es un protocolo tanto de nivel 2 como de nivel 3.

¿El problema?

La finalidad de ARP queda clara. Un protocolo que permita extraer de algún modo de la dirección física MAC de un host. ¿Por qué es esto estrictamente necesario? La mejor forma de ver esto es intentar componer la red TCP/IP más sencilla que pueda existir, para evitar pensar en routers, hubs u otros elementos de red: Dos hosts conectados uno a otro por un cable Ethernet. Imaginar por tanto que disponemos de dos host configurados manualmente y conectados por un cable de red, formando entre ambos equipos una red muy simple. El host A se configura para tener una dirección IP 192.168.0.1 y el host B para tener la dirección 192.168.0.2. Si lo vemos de una forma completamente lógica, decimos simplemente que el host A se comunica con el host B enviando los paquetes IP a la dirección 192.168.0.2. ¿Pero como sabe el host A quien es el host B? Visto desde un punto de vista completamente físico, la tarjeta de red del host A tan solo sabe que ella tiene una dirección física por ejemplo de 00:00:00:00:00:01, a la cual hay conectada un cable por el cual enviar o recibir datos, y lo mismo para el host B, 00:00:00:00:00:02. Los adaptadores de red no tienen por qué entender de IP, recordemos que Ethernet es un protocolo de nivel 2. En última instancia, el adaptador de red simplemente pone los datos que sean en las lineas de transmisión del cable y listo. En este caso es simple, dado que tan solo hay un equipo conectado al otro extremo, los datos enviados por A llegarán siempre al equipo B. El host B cuando recibe lo que sea por su interfaz de red podría simplemente tomarlo por bueno y tomar cualquier dato que llegue por él como válido y procesarlo. En este caso no haría falta siquiera conocer direcciones físicas. Pero que sucede si creamos una red en vez de dos equipos de tres?

Imaginar que a los dos equipos antes mencionados incluimos un Host C con dirección física 00:00:00:00:00:03. ¿Como? En el caso más simple de todos esto se haría con un dispositivo de red conocido como Hub. Básicamente los Hub conectan todos los diferentes hosts conectados a él entre sí de una forma muy simple. Un cable/interfaz Ethernet o Fast-Ethernet tiene dos lineas para transmitir datos y dos para recibir, pues el hub lo que hace es conectar internamente las dos líneas de transmisión de datos de cada cable con las dos de recepción de los otros. Es decir, cuando el host A envíe un paquete, este será recibido tanto en B como en C, y exactamente lo mismo para cualquier paquete enviado por B o por C. El problema es evidente, ante esta situación ya no basta simplemente con poner el dato en el cable y dejar que los hosts tomen por bueno y procesen el dato. Por otro lado cada host puede tener una IP diferente sí, pero como hemos dicho los adaptadores de red no tiene por qué saber nada de IP, y por otro lado las aplicaciones no entienden de direcciones MAC, solo de paquetes IP.

¿La solución?

Si al enviar el dato que sea desde A especificamos la dirección MAC destino (es decir, el adaptador de red a quien está destinado dicho frame), esta dirección o ID si puede ser comprobada/verificada por el adaptador de red. En este caso del Hub, tanto B y C recibirán un frame de A, pero el frame de A especificará que el destino será 00:00:00:00:00:02, con lo que el host C simplemente ignorará el frame, puesto que la dirección MAC no es la suya. Con esto podría parecer que el uso de IP es innecesario, pero recordemos que la función de un protocolo de nivel de red es completamente diferente a un protocolo de nivel de enlace de datos. IP hablará con todos los protocolos superiores, mientras que Ethernet es un protocolo de bajo nivel. Visto esto vemos la necesidad de las direcciones MAC, pero no del protocolo ARP. Pues bien, se ha dado por echo que el host A conoce la dirección MAC del host B, lo cual puede ser que la conozca o puede ser que no la conozca. Si arrancamos en frió todos los dispositivos, la única forma que el host A conozca la dirección MAC de los otros host y viceversa es manteniendo un archivo local en cada equipo que especifique dichas direcciones. Esto ya vimos en DNS que no aceptable en ningún modo, hace falta un protocolo que se encargue de dicha tarea.

Cuando un host no posea la dirección mac de otro, necesitará realizar una petición ARP para conocer dicha dirección. ARP tiene tan solo dos métodos de funcionamiento: Enviar peticiones y Enviar respuestas. El procedimiento base es muy simple, si necesita conocer la MAC del host B (del cual evidentemente conoce la IP, dado que el mismo paquete IP especifica dicha IP), enviará una petición a la dirección física de broadcast de la red con la solicitud. Todos los host recibirán Y ATENDERÁN la petición puesto que la dirección física a la cual está destinado el frame son TODOS los host, pero tan solo el host B contestará a ella, dado que dicha petición especifica la IP del host B. La respuesta de B por otro lado será dirigida directamente a A, dado que en la misma solicitud se incluye la dirección MAC del host A. La respuesta llegará a todos los host (estamos usando un hub), pero estos no la procesaran porque la dirección MAC especificada en el frame será la de A. A recibirá la contestación por parte de B con un frame que contendrá la dirección física de B, y el host A podrá actualizar su caché ARP, donde almacenará la asociación IP host B -> MAC host B.

Lo primero será por tanto conocer la estructura de este frame un tanto especial, ya se ha dicho que aun siendo (a mi juicio) un protocolo de nivel 2, lleva consigo una IP:

Hay que tener en cuenta que ARP depende de dos protocolos, el superior y el inferior. Para nosotros, ARP será usado extensamente en redes IPv4 sobre Ethernet, pero esto no quiere decir que son los únicos protocolos con los que podría funcionar ARP.

• Tipo de Hardware (16 bits): Especifica el hardware del nivel inferior que será usado. En caso de redes Ethernet, el valor de dicho campo será un 0×0001
• Tipo de Protocolo (16 bits): Especifica el protocolo superior al que referenciará, en caso del protocolo IP el valor de dicho campo será de 0×0800
• Long. Dirección Hardware (8 bits): Especifica el tamaño en bytes que ocupará una dirección del tipo hardware especificado en el campo “Tipo Hardware”. En caso de redes Ethernet, las direcciones MAC tienen un tamaño de 48 bits, luego este campo estará fijo en 48/8 = 6 Bytes -> 0×06
• Long. Dirección del Protocolo (8 bits): Especifica el tamaño de la Dirección del protocolo de nivel superior, en nuestro caso una dirección IPv4 tiene una longitud de 32 bits -> 32/8 = 4 Bytes -> 0×04
• Operación (16 bits): Especifica el modo de operación del protocolo ARP. Ya se dijo que ARP actúa o realizando una petición (Request, un valor de 1 en dicho campo) o respondiendo a una (Reply, con un valor de 2 en dicho campo)
• Dirección Hardware/Protocolo Origen/Destino (variable): Dado que el hardware y el protocolo sobre los cuales ARP va a funcionar puede ser diferente, estos campos no tienen una longitud fija, de echo estos campos son fijados en los registros anteriores. En estos campos se almacenará la dirección MAC de origen y la dirección MAC destino en caso de los registros Dirección Hardware y la dirección IP de origen y destino en el caso de los campos de Dirección del Protocolo.

En realidad es un frame muy simple, no lleva mayores complicaciones ni sobrecargas en el protocolo. Vamos a ver un ejemplo de frame tipo ARP IP sobre Ethernet capturado por un Sniffer:

+Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
-Ethernet II, Src: Cisco-Li_xx:xx:xx (00:xx:xx:xx:xx:xx), Dst: AsustekC_xx:xx:x (00:xx:xx:xx:xx:xx)
Destination: AsustekC_xx:xx:x (00:xx:xx:xx:xx:xx)
Source: Cisco-Li_xx:xx:xx (00:xx:xx:xx:xx:xx)
Type: ARP (0×0806)
Trailer: 00000000000000000000000000004fe127ba
-Address Resolution Protocol (request)
Hardware type: Ethernet (0×0001)
Protocol type: IP (0×0800)
Hardware size: 6
Protocol size: 4
Opcode: request (0×0001)
Is gratuitous: False
Sender MAC address: Cisco-Li_4c:fc:8a (00:25:9c:4c:fc:8a)
Sender IP address: 192.168.x.1 (192.168.x.1)
Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
Target IP address: 192.168.X.2 (192.168.x.2)

El primer bloque pertenecería al protocolo Ethernet. Tan solo se especifica como ya se dijo la dirección MAC origen y destino, el tipo de protocolo (en este caso ARP) y el trailer. El trailer es el fin de la trama (frame), lo cual hay que explicarlo. Como hemos visto un frame Ethernet termina con una secuencia de 4 Bytes que es el checksum. No obstante por regla general no será posible acceder a estos datos del frame por un sniffe, dado que el checksum se calcula de forma automática en el propio adaptador, y para tener acceso a ello sería necesario drivers específicos que realmente no merece la pena molestarse por ello.Es decir, el trailer NO ES el checksum en modo alguno, sino un padding necesario. ¿Por qué? Un frame Ethernet debe de tener un tamaño mínimo de 64 bytes. En este caso podemos comprobar que el Frame capturado tiene curiosamente 64 Bytes (60 Bytes + 4 Bytes del Checksum que se omiten), pero se obtiene un valor exacto de 64 Bytes gracias al trailer, sin este el frame ethernet tendría un tamaño inferior. Es por ello que la propia interfaz de red añade un padding después de los datos para rellenar ese tamaño mínimo de 64 bytes (60 si no contamos el checksum), o lo que es lomismo, un tamaño mínimo de datos de 46 Bytes.

El segundo bloque corresponde al protocolo ARP. La captura muestra exactamente cada uno de los campos de este protoclo, el tipo de Hardware (Ethernet), el tipo de protocolo de red (IP), el tamaño en Bytes de las direcciones, el modo de operación y las direcciones MAC e IP. Aparece no obstante un campo llamado “Is gratuitous”. En el protocolo ARP se denomina un frame gratuito a un auto anunciamiento. Es decir, imaginar que el frame anterior ARP en vez de tener como emisor la MAC y la IP del router tuviese la MAC e IP de él mismo, pero el destino fuese igualmente la dirección indeterminada: 00:00:00:00:00:00. En este caso, es evidente que nadie contestaría al frame ARP, pero este mensaje SI actualizaría probablemente las tablas ARP locales de cada equipo.

El frame completo ARP del ejemplo lo que realmente significa es que pregunta a toda la red por la dirección MAC de la IP 192.168.x.2. ¿Como es posible? porque el frame no está siendo enviado a una dirección MAC concreta, sino a la dirección indefinida 00:00:00:00:00:00, dado que no se conoce cual es. Esto hace que todos los host en la red escuchen tal frame. Cabe esperar que inmediatamente de lanzar el route dicha peticion ARP, el host del cual se desea conocer la dirección MAC responda con un frame ARP reply a dicha petición.

¿Que sucede cuando una petición ARP se contesta?

Al igual que las caché DNS, todos los equipos poseen una caché generalmente dinámica ARP que almacena las asociaciones MAC/IP, lo que evita el uso continuo de realizar peticiones ARP para conocer dichas direcciones MAC. Estas tablas se actualizarán a medida que sean necesaria, pero al contrario de lo qeu se piense, generalmente son actualizadas al recibir cualquier ARP reply de la red, sea legítimo o no, y esto será tratado en profundidad en otro capítulo de este tema. Dado que existe esta tabla/caché ARP, es posible tanto eliminar entradas de esta como añadir entradas manualmente, como listar la tabla ARP.

En windows:

C:\Users\Theliel>arp -a

Interfaz: 192.168.x.3
Dirección de Internet Dirección física Tipo
192.168.x.1 00-xx-xx-xx-xx-xx dinámico
192.168.x.255 ff-ff-ff-ff-ff-ff estático
224.0.0.22 01-00-5e-00-00-16 estático
224.0.0.252 01-00-5e-00-00-fc estático
239.255.255.250 01-00-5e-7f-ff-fa estático
255.255.255.255 ff-ff-ff-ff-ff-ff estático

Interfaz: 192.168.x.2
Dirección de Internet Dirección física Tipo
192.168.x.1 00-xx-xx-xx-xx-xx dinámico
192.168.x.6 00-xx-xx-xx-xx-xx dinámico
192.168.x.8 00-xx-xx-xx-xx-xx dinámico
192.168.x.13 00-xx-xx-xx-xx-xx dinámico
192.168.x.255 ff-ff-ff-ff-ff-ff estático
224.0.0.22 01-00-5e-00-00-16 estático
224.0.0.252 01-00-5e-00-00-fc estático
239.255.255.250 01-00-5e-7f-ff-fa estático
255.255.255.255 ff-ff-ff-ff-ff-ff estático

En Linux:

Anarchy:/# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.x.1 ether 00:xx:xx:xx:xx:xx C eth0
192.168.x.2 ether 00:xx:xx:xx:xx:xx C eth0
192.168x.25 ether 00:xx:xx:xx:xx:xx C eth0

El protocolo ARP es simple y altamente efectivo, no obstante no está libre de problemas de seguridad. Cuanto más simples es un protocolo más efectivo es, pero también es intrínsecamente más inseguro la mayoría de las veces. Recordar que Internet no se pensó como una fortaleza en la que todo estuviese medido, sino todo lo contrario, un sistema lo más simple posible y efectivo. Y viendo los protocolos que la hacen posible, tengo que decir que lo lograron, y a día de hoy es sin duda alguna la red de redes.

Como gran seguidor del proyecto Firefox, no puedo sino ir dejando unas palabras de cuando en cuando en la medida que creo que van sucediendo cosas “interesantes”.

La última versión estable lanzada actualmente de Firefox es la versión 3.6.4, en cambio, desde hace ya tiempo se está perfilando la que iba a ser la versión 3.7, que al final casi con toda seguridad pase a ser la versión Firefox 4.0. Pues bien, a día de hoy, Minefield (Nombre en clave de la versión alpha 3.7) ha alcanzado la fase Alpha 5, y se está terminando con Alpha 6. En un principio la idea era lanzar una versión Firefox 3.7 y a posteriori una versión Firefox 4.0, pero como he dicho todo indica al lanzamiento directo de la versión 4.0, lo que ha “demorado” muchas de las grandes novedades que vamos a tener.

En realidad, si tan solo fuesen dos mejoras aquí y una allí, personalmente no me molestaría para indicarlo, pero para mi sorpresa, estos dos últimos meses de desarrollo han sido completamente desbocados a la hora de implementar nuevas funcionalidades. Lo interesante aquí, es que no solo se han centrado en mejorar la velocidad del motor JS que es lo que parece que ahora está de moda y que es lo que prácticamente parece que hacen los navegadores, Safari/Opera y en menor medida Chrome (en menor medida no me refiero a que aumente menos la velocidad, sino que no solo se esfuerzan en ello).

Pues bien, ahora mismo en la build diaria más reciente (Alpha 6), ya contamos con grandes mejoras, y es lo que vamos a ver:

• Aceleración Hardware para casi todas las partes del navegador: Soporte Direct2D y DirectWrite para todo el layout, lo que implica renderizado de fuentes, de temas, de imágenes… mejorando en mucho la carga de las páginas y aumentando el rendimiento de manera exponencial en aplicaciones y/o contenido visual/gráfico. WebGL para renderizado de objetos 3D. Para poder usar todo ello se requiere mínimo una tarjeta de video DX9, y mejor DX10. Es cierto que aun quedan algunos bug y problemas que arreglar, y es por ello que actualmente no es una opción habilitada por defecto. Para habilitar soporte D2D y DD, es necesario realizar los siguientes cambios en la configuración avanzada de Firefox (Se accede escribiendo en la dirección about:config):

  gfx.font_rendering.directwrite.enabled -> Establecerlo en true
  mozilla.widget.render-mode -> Establecerlo en 6

  Algunas web de Ejemplo para quien quiera probar esto con y sin aceleración hardware, aunque algunas de estas web pueden prácticamente dejar colgado el navegador si no se usa la aceleración:

  http://mrdoob.com/projects/chromeexperiments/ball_pool/
  http://www.tapper-ware.net/stable/web.dom.stresstest.transform/

  http://url3.tk/canvas/

• Nuevo diseño de la interfaz y soporte Glass para Windows, ahora podemos poner la barra de pestañas en la parte superior si así lo deseamos, y se ha añadido un botón de menú que sustituirá la barra de menús. Actualmente se parece más a una pestaña que a un botón, pero pronto se integrará de forma definitiva en la parte superior izquierda, con un look más agradable.

  Por otro lado la interfaz se ha redefinido de tal modo que será posible de forma simple modificar prácticamente cualquier aspecto visual de Firefox, tanto por temas, como por “Personas”, como por “Style”. Por ejemplo en mi caso, actualmente he optado por un diseño minimalista, semejante un poco a la interfaz de Chrome, pero con mis complementos a primera mano, maximizando además el área de la web.

  El soporte Glass por otro lado permite una mejor integración con los temas de Windows que tengamos puestos.

• Nuevo diseño de la interfaz de Addons, que podríamos incluir quizás en el apartado anterior. Ahora, el gestor de complementos y temas no será una pantalla flotante de firefox, sino será abierta como una pestaña más del navegador en el que podremos encontrar de forma sencilla nuestros complementos instalados. Tiene un toque más sofisticado y estético, a la par de una mayor organización

• Soporte nativo para 64bits, parecía que no llegaría nunca, pero en cambio ya se ha incluido en el repositorio principal de Firefox las compilaciones para 64 Bits para Windows (para Linux ya existían). Esto quiere decir que ahora mismo es posible descargar e instalar Firefox 3.7pre6a en 64bits, y en 64 bits no me refiero a que se pueda instalar en un OS de 64 bits, sino que la aplicación es nativa en 64bits, lo que nos dará un bonito 10-20% de rendimiento (en el mejor de los casos) más una mejora en la seguridad del navegador. Las extensiones funcionarán casi todas perfectamente, en cambio los addons NO. Es decir: Para contenido JAVA, será necesario instalar la versión x64 de JAVA JRE, para Flash habrá que esperar un poco más, dado que también se está terminando el desarrollo de Flash Player para x64. Personalmente, esto es algo que esperaba desde hacía tiempo, y con Firefox en 64 bits puedo decir que por fin prácticamente todo el software principal que uso está en 64bits.

• Sync, nombre del proyecto WEAVE, el cual permite la sincronización entre diferentes navegadores Firefox de contraseñas, historial, pestañas abiertas, preferencias y marcadores. Es decir, que si usas más de un dispositivo con Firefox, ya no existirán problemas de tener dos configuraciones diferentes. Para ello es necesario o tener un servidor propio de sincronización o usar el de Mozilla, el cual es completamente gratuito, y es tan fácil como acceder a las opciones de Sync, decir que se es usuario nuevo y especificar un nombre de usuario y una contraseña. Tan fácil como eso. En segundo plano cada X segundos/horas se sincronizará automáticamente con el servidor para mantener la copia de este siempre actualizada. Si accedemos desde otra ubicación, del mismo modo simplemente podemos obtener los datos de él.

  Actualmente Sync no obstante no ha sido integrado en el repositorio de Firefox, en el árbol principal, pero se espera que sea en muy breve, con lo que ahora mismo para usar Sync se debe de instalar como extensión. Repito, esto es solo temporal. El único problema que he encontrado es la dificultad actual de montar un servidor Sync propio, el rato que lo he intentado no he sido capaz de hacerlo ,pero espero tener mi propio servidor Sync listo en breve (aun así el servidor de Mozilla funciona perfectamente bien, rápido y eficaz).

• Comienzo del proyecto Electrolysis, que dará soporte multihilo a Firefox, lo que lo hará aproximadamente un 400% más rápido, tanto en el motor JS como en rendimiento general. El problema de Electrolysis es que se requiere mucho tiempo y muchos recursos, requiere cambiar gran parte de todo el código, dado que afecta al núcleo principal de Firefox. Es decir… aun quedará tiempo para poder ver esto implementado de forma completa. Actualmente lo que ya se tiene es la separación de los Addons en otros procesos, es decir, que cualquier addons como Flash o JAVA serán ejecutado en otro proceso, aumentando su velocidad de proceso y haciéndolo mucho más tolerante a fallos, dado que si el addon es el que falla, en el peor de los casos tan solo tendremos que recargar la web, y no reiniciar el navegador entero. La integración completa con este proyecto no obstante no será en Firefox 4.0. Recordar que tanto Chrome, Opera o Safari son todos multihilos, lo que quiere decir que el gran rendimiento de Firefox es admirable si tenemos en cuenta que no tiene dicha ventaja.

• Soporte para WebM, la nueva propuesta de Google para HTML5 <video>. De esto ya hemos hablado largo y tendido. Es muy probable que WebM sea escogido como estandar en HTML5, descartando el uso de H264 y AAC. Los mayores sitios de Video en internet ya están migrando a webM, mientras que aun funcionan con flash perfectamente (ambos convivirán juntos). Esto incluye evidentemente a YouTube. Esto implica más cosas, dado que con la guerra declarara de Apple contra el resto del mundo, Apple puede ver en cualquier momento como sus iPhone, iPad, iPod Touch dejan de poder acceder a videos en Youtube y de otros muchos sitios, dado que la única forma que tienen estos dispositivos de poder ver videos es a través de h264 sobre HTML5, y con casi toda seguridad este no sea tomado como estandar. Si declaras la guerra al mundo, te quedas solo y te dan por culo.

  Podemos ver WebM en funcionamiento perfectamente si disponemos de las ultimas build de firefox y acudimos por ejemplo a YT, al portal en pruebas de HTML5:

  http://www.youtube.com/html5

• Inclusión de múltiples funciones HTML5 y CSS, que como ya se ha dicho en muchas ocasiones HTML5 es tan solo un borrador en continuo cambio, es decir, que cualquier función añadida ahora, mañana puede desaparecer o cambiar o… las palabras absurdas de Apple sobre todo lo que es o no es HTML5 es cuanto menos increíble. HTML5 no será una realidad mínimo hasta 2012 en el que las especificaciones sean más o menos concretas. Pero es que a partir de 2012, no será sino en 2020 cuando sean publicadas las especificaciones completas. Es interesante HTML5? Desde luego. Es el sustituto de Flash? Ni mucho menos.

  Si nos fiamos de la web http://beta.html5test.com/ para medir las características HTML5 del navegador, obtenemos que Firefox 3.7pre6a ya obtiene un bonito 196 199 sobre 315 con 9 puntos de bonificación. Pues bien, Firefox 3.6.4 creo que actualmente obtiene una puntuación de 140 sobre 315 aproximadamente. Aquí hay que citar pro tanto a Apple y toda la demagogia barata que ha realizado sobre sus iPhone, iPad e iPod Touch sobre HTML5. La verdad es que el recién salido del Horno Safari 5, tan “solo” alcanza una nota de 208 sobre 313. Sí, es más que Firefox actualmente, pero es lógico, esta versión ha salido hace unos días, tendremos que esperar que sucede con Firefox 4 cuando sea oficial. También hay que tener en cuenta los test que realiza dicha web, los cuales algunos desde mi punto de vista son cuestionables, dado que muchas especificaciones han cambiado y ya no son especificaciones HTML5. Por ejemplo, Safari 5 soporta bases de datos Web SQL, que era una especificación HTML5. En cambio, esta especificación ya no existe en HTML5 y ha sido sustituida por IndexedDB. Pues bien, dicha web puntúa positivamente tanto la especificación antigua como la nueva. Aun así, un 208 sobre 313 no está nada mal. Pero.. que sucede si comprobamos la puntuación obtenida por los navegadores de iPhone/iPad/iPod Touch? Que obtenemos un mísero 125 sobre 313. Y segúñn Apple estos dispositivos son compatibles con las últimas tecnologías y en especial con HTML5.

  En realidad mi queja es con las palabras de Apple, es completamente normal que ningún navegador obtenga puntuaciones mayores, HTML5 cambia constantemente y es un desperdicio enorme de recursos estar añadiendo funciones HTML5 que dos días después desaparecerán. Lo que si me sorprende es la demagogia barata que se hace para hacer publicidad de algo (o mejor dicho crícita sobre Flash).

  Dicha web mencionada es interesante, pero como he dicho desde mi punto de vista no es del todo fiable. Eso sí, es actualizada de forma asidua, los resultados de hoy no serán válidos para dentro de X días. Primero porque es posible que cambie el sistema de puntuación y por otro lado porque las builds de Firefox hasta el lanzamiento de Firefox 4.0 son continuas. Hace unos días, por ejemplo tan solo teníamos un 186 sobre 313 para Firefox, pero las últimas modificaciones han añadido algunos flecos pendientes. Dentro de unos días o semanas casi con toda seguridad el PRE soporte HTML5 de Firefox será aun mejor, estoy seguro de ello.

  CSS por otro lado es igualmente importante a día de hoy, y se están incluyendo muchas funcionalidades nuevas. Listarlas sería imposible, pero un buen ejemplo para ir testando estas sería la siguiente web:

  http://tools.css3.info/selectors-test/test.html

  Obteniendo 576 test superados de 578 disponibles. Aunque si se desea ver esto en profundidad la web buscada sería esta otra:

  http://samples.msdn.microsoft.com/ietestcenter/

  En dicha web se pueden ir comprobando una a una diferentes estándares y capas CSS. Los amigos de MS no han querido incluir ni Firefox 3.6.4 ni tampoco Firefox 3.7pre6a. Si tengo tiempo incluiré dichos resultados a las tablas de MS, posiblemente veamos como Firefox obtiene las mejores puntuaciones. Como hacer esto? Es muy facil, MS ha realizado un gran trabajo en dicha web, y es posible ir comprobando uno a uno cada test. Es decir, que se puede realizar la misma prueba con el navegador que se desee.

• Actualizaciones no Intrusivas, aunque es una funcionalidad que aun no se ha incorporado al arbol principal del repositorio. El objetivo es obvio, el poder realizar actualizaciones tanto de extensiones como de software sin siquiera reiniciar en la medida que sea posible y sin molestarnos en ello, todo casi de forma automática.

• Nuevo motor JS, lo que permitirá una mayor velocidad en el uso de código JavaScript. Mozilla revolucionó la era JB con el lanzamiento de su motor SpiderMonkey. Desde ese día, parece que los navegadores de la competencia tan solo se dedican a mejorar sus motores JS, usando la técnica de Mozilla (compiladores JIT). ¿Que ha sucedido? Que en cualquier lugar te miden ahora el rendimiento del navegador por su motor JS, así tenemos benchmark como SunSpider de Apple o V8 de Google. En realidad es un error medir el rendimiento de un navegador por esto. Sí, el motor JS es muy importante a día de hoy, puesto que casi cualquier web tiene código JS por debajo, y su procesamiento es vital para una navegación rápida y fluida. No obstante se usa demagogia para esto. Actualmente se dice que Chrome es el navegador más rápido que existe, y sea esto cierto o no, el 99% llega a esta conclusión por los test que existen que simplemente miden el rendimiento del motor JS.

  Aun así esto es importante. Actualmente Firefox en las últimas builds tiene un puntuaje de 550 aproximadamente en SunSpider, lo que le hace estar por debajo tanto de Chrome como de Safari 5 en cuanto a JS. OJO!! Y es muy importante a tener en cuenta de nuevo que Firefox NO ES multihilo, los otros navegadores sí. Aun así, se están haciendo buenos progresos en mejorar el motor actual. a SpiderMonkey se le añadió TraceMonkey, una serie de extensiones y mejoras para aumentar considerablemente su rendimiento. Pero eso fue hace ya tiempo. Actualmente se está trabajando para mejorar el rendimiento en general, y es cierto, dado que en las diferentes build de este último mes, usando SunSpider, he podido comprobar una disminución de casi 100 puntos (Cuanto menos mejor). Es decir, que por ver el resultado final (recordemos que aun estamos en fase Alpha)

• Otros, es evidente que existen más cambios que se están realizando y que ya se han realizado, pero son a niveles más bajos, en los cuales el usuario normal posiblemente no le interese ni le importe de forma directa. Por ejemplo APIs para los programadores, fallos de seguridad, mejoras en rendimiento general, sockets para el acceso directo a servidores..

Ya sé que tan solo disponemos actualmente de versiones Alpha, pero son muy prometedoras. La versión Beta 1 ya no debería de tardar, y casi con toda posibilidad, la beta 1 sea renombrada ya oficialmente como Firefox 4.0b1. Desde mi punto de vista esto sí es realmente una versión nueva, y no una mezcla más para sonar en la prensa. El usuario medio notará grandes mejorías con estos cambios, tanto en rendimiento como en personalización y funcionalidades, así como las adaptaciones propias de las más nuevas tecnologías que van emergiendo.

Veremos que sucede dentro de unas semanas…

Un saludo.

Nota: Todo fue realizado con el consentimiento expreso del dueño. Al principio fue una cuestión de investigación, los cambios no obstante solo fueron aplicados con el conocimiento del dueño.

Cansado de la vida en la ciudad que mejor forma que descansar debajo del sol y escuchar las olas del mar.

Honestamente, no es que no pueda vivir sin la tecnología, pero sí me divierto mucho con ella… y también aprendo. Así que entre el bañador, la toalla y protector solar he tenido que dejar espacio para el equipo informático. Una de las primeras cosas que aprendí fue a no dar nada por supuesto, así que ¿por qué no voy a pensar que algún vecino bueno y amigable iba a olvidarse a proteger a conciencia su conexión WIFI? Así que para no tener que cargar con más equipo del necesario simplemente tomé mi viejo router Linlsys wrt54GL (resucitado recientemente), el cual tuve la precaución de dejarlo preparado para destripar cualquier red WIFI que se pusiese a su alcance.

Dicho y hecho, después de dar un paseo agradable por la orilla y desempacar a montar mi pequeño puesto de trabajo fuera del ruido y el estrés de la ciudad. ¿Y cual es mi sorpresa? Un vecino amigable tiene su red WIFI expuesta (llamemos a su router/modem a partir de ahora “Destiny”). Bueno… robar está mal, así que después de comprobar la seguridad de esta no estaría de más contactar con el usuario y charlar animadamente con él. Pero lo primero es lo primero, tan solo tengo que conectarlo todo, configurar mi viejo router (llamado a partir de ahora como “Chaos”) y romper la pobre seguridad de Destiny, una clave WEP de 64bits. Una vez realizado esto (cosa fácil), tan solo es cuestión de configurar el router como cliente WIFI. Podría configurarlo como repetidor para aumentar la cobertura también de la red, pero siempre que no me es completamente necesario evito el uso de WIFI, así que opté mejor por el modo Cliente. En este modo Chaos actúa como si fuese un cliente más conectado a Destiny, a la par que actúa como router para mi propia red local. Es decir, la IP externa de Chaos será una IP asignada por defecto por el servidor DHCP de Destiny, mientras que la IP de mi red será aquella que yo desee dentro de mi propia red, y de tal modo que cualquier equipo conectado a mi red es completamente invisible de cara a Destiny, y la existencia de Chaos tan solo podría ser detectada accediendo a Destiny y comprobando los clientes conectados.

Una vez que todo se ha completado y la red comienza a funcionar el segundo paso es apuntalarlo todo. Esto implica primero a intentar configurar Destiny para mejorar en lo posible la cobertura WIFI (dado que esta será la que marque el rendimiento global de toda mi conexión a Internet y su estabilidad), mejorar la seguridad y de paso impedir que el vecino se arrepienta de permitirme el acceso a su red… al menos antes de que pueda pedirle permiso formalmente. Su red permite perfectamente pasar mis peticiones desde mi red local 192.168.3.0 a su red local 192.168.1.x lo que quiere decir que en teoría podría alcanzar desde mi equipo la configuración de Destiny, comenzando por la interfaz web y su puerta de enlace. ¿Cual es su puerta de enlace? Tan solo tengo que verlo en Chaos, o en el peor de os casos realizar un escaner de Pings y ver los hosts despiertos en la red:

C:\Users\Theliel>nmap -sn 192.168.1.0/24

Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-06-12 18:03 Hora de verano romance
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
Nmap scan report for 192.168.1.64
Host is up (0.011s latency).
Nmap scan report for 192.168.1.65
Host is up (0.58s latency).
Nmap scan report for 192.168.1.254
Host is up (0.0043s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 31.80 seconds

C:\Users\Theliel>

Vaya, no soy el único que está conectado, si mi cliente es el .64, el .65 debe de ser algún inquilino y Destiny debe de ser .254. Bueno, veamos que podemos obtener de Destiny sin intentar siquiera acudir al sentido común, así que vamos a ver si podemos ver sus puertos abiertos:

Nmap scan report for 192.168.1.254
Host is up (0.016s latency).
Not shown: 995 filtered ports
PORT     STATE  SERVICE
21/tcp   open   ftp
23/tcp   open   telnet
80/tcp   open   http
443/tcp  open   https
8080/tcp closed http-proxy

Vaya!! Destiny brilla por su escasa o nula seguridad, puertos http, telnet y ftp abiertos. ¿Y si solicito información sobre la versión de sus servicios y el OS de este?:

Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-06-12 18:17 Hora de verano romance
Nmap scan report for 192.168.1.254
Host is up (0.013s latency).
Not shown: 996 filtered ports
PORT    STATE SERVICE  VERSION
21/tcp  open  ftp      Alcatel Speedtouch aDSL router ftpd
23/tcp  open  telnet   Alcatel/Thomson SpeedTouch DSL router admin interface
80/tcp  open  http     Alcatel/Thomson SpeedTouch aDSL http config 1.0
|_html-title: HTTP/1.0 401 Authorization Required
|_http-favicon: Thomson/Speedtouch Device
443/tcp open  ssl/http Alcatel/Thomson SpeedTouch aDSL http config 1.0
|_html-title: HTTP/1.0 401 Authorization Required
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
|_http-favicon: Thomson/Speedtouch Device
| http-auth: HTTP Service requires authentication
|   Auth type: Digest, realm = Thomson Gateway
|_  Auth type: Basic, realm = Thomson Gateway
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port

Esto continua dando sus frutos, ahora puedo afirmar casi con toda seguridad sin siquiera ponerle los dedos encima aun, que Destiny es un router/modem thomson SpeedTouch, lo que me dice que el vecino amigo posee una linea ADSL y que el usuario por defecto de este router será “Administrator” y la contraseña “admin”, y si el usuario no modificó siquiera la seguridad WIFI, no hay nada que me diga que cambiaron su configuración de fábrica. Y efectivamente, si intento alcanzar la interfaz web por medio de su puerta de enlace y con las credenciales por defectos, tengo acceso con nivel “administrador” a su router/modem para configurarlo a mi gusto.

A este punto, lo primero será crear un nuevo usuario en Destiny como administrador (es el mayor permiso que me permite especificar… por ahora) y poner una contraseña. También puedo eliminar la cuenta por defecto “Administrator”. Una vez que el acceso a Destiny está más o menos terminado (por ahora) hay que ver que seguridad tiene y sobre todo la configuración WIFI. No hay que estropear nada a sus dueños, tan solo podré modificar aquello que crea que no afectará a nadie. Curiosamente Destiny tiene un Firewall relativamente decente (deshabilitado por defecto o a conciencia, y yo no fui) y un sistema de detección de intrusos para filtrar escaners y otras técnicas, que está habilitado por defecto. Lo gracioso del tema es que registró mi escaner de puertos, pero no me impidió realizarlo, luego de nuevo podemos suspenderle en cuanto a seguridad se refiere. Por seguridad lo mejor es habilitar el Firewall a su nivel estandar (bloque de todas las conexiones entrantes), el IDS no podemos modificar su estado (por ahora).

Una vez realiza todo esto me tomo con una sección de gestión remota para un supuesto usuario denominado “tech”, aunque en los usuarios listados en el administrador de usuarios no aparece… interesante. Lo apunto por si las moscas. Los ajustes WIFI no permiten gran cosa, deshabilito los modos 802.11b, fuerzo el canal a 1 y eso es todo lo que me permite la interfaz web.

Visto lo visto, lo mejor será realizar un acceso por telnet y ver si puedo tener un control algo más extendido de Destiny, ya sé que tiene el puerto abierto, y si nada ha cambiado no tendría que ser complicado. Al menos ya he logrado obtener una calidad de señal de un 20% (nada despreciable, teniendo en cuenta que Destiny debe de estar en un bloque de pisos enfrente del mío a unos 30 metros terraza con terraza). El acceso por telnet es igualmente sencillo en este router, mis credenciales nuevas tienen completa validez y en principio tengo acceso completo al sistema. Lo primero que haré será realizar un volcado completo de toda la configuración de este, así podré hacerme una idea de las posibilidades que tengo. Por suerte este router nos deja jugar bastante con él:

 

Username : Theliel
Password :
————————————————————————

Thomson XXXXX
Copyright (c) 1999-2007, THOMSON
————————————————————————
{Theliel}=>config dump
[ sntpc.ini ]
config poll=60 pollpresync=5
config state=disabled

[ xdsl.ini ]
debug traceconfig level=0
config adslmultimode=adsl2plus detect-lop=enabled syslog=disabled
debug multimode config=default
…
…… -> Unas cienos de lineas más

Lo mejor de todo es que gracias a este volcado puedo analizar de forma simple todo lo que desee. Veamos que tenemos sobre WIFI:

[ wireless.ini ]
ifconfig interop=802.11g locale=Europe
ifconfig channel=1 ssid=xxxxxx any=enabled rts=2347 protection=never protmode=rtscts prottrigger=local&overlap shortslot=always frameburst=disabled dtim=3
macacl config control=unlock
secmode wep encryptionkey=XXXXXXXX
secmode wpa-psk presharedkey=XXXXXXX rekeysec=0 version=WPA
secmode config mode=WPA-PSK
wds config state=enabled

Lo interesante es lo que está en negrita, evidentemente. Parece ser que al forzar a usar tan solo el estandar 802.11g, protection se pone a never, con lo que ello explica a que no pueda setear el parámetro protmode a off. Dicho de forma simple, la protección CTS RTS/CTS es un sistema para que las redes B y G puedan coexistir juntas. En realidad CTS y RTS no son más que señales necesarias para el sistema CSMA/CA. Cuando todos los dispositivos funcionan en el mismo modo no hay problema dado que todos ellos están sincronizados (por así decirlo). En cambio si no lo están se produce lo que se llama estaciones ocultas. Es decir, pensar en dos clientes y un AP. Los dos clientes están dentro de la cobertura del AP, pero no entre ellos. Al no estar sincronizados ninguno sabe de la existencia del otro y podrían enviar de forma simultanea información al AP. Y esto es lo que evita la protección CTS y CTS/RTS.

shortslot es una mejora de rendimiento y está activada, pero por lo que se puede contemplar no sucede lo mismo con frameburst. Frameburst es una tecnología que permite ENVIAR (no recibir) datos en el tiempo de espera entre cada frame, es decir… a fin de cuenta enviar más datos en menos tiempo. Si una red G tiene una salida máxima de unso 3,1 MB más o menos, gracias a frame burst puede tener una salida máxima de a lo mejor 4-5MB, un buen incremento sin duda alguna. Pero esto solo ayuda en la subida, si queremos que se vea en la recepción de datos entre dos clientes WIFI, los dos deben de soportar dicha tecnologías, a sí uno puede enviar datos a esa velocidad y el otro contestarle con la misma tecnología. El lado negativo es que Frameburt tiene un impacto negativo cuando en la red existen clientes que no soportan dicha función, aunque a día de hoy casi todos los adaptadores G la soportan. Muchos routers y adaptadores permiten establecer esto en sus interfaces web o en las opciones del controlador. En mi caso es tan simple como:

{Theliel}=>wireless ifconfig config frameburst=true

Una vez que creo que todo está en orden queda tan solo saber que pasa con ese usuario tech, quiero asegurarme de que “Theliel” es el único usuario con acceso a Destiny. Bueno, a ver que encontramos en el volcado de la configuración:

[ mlpuser.ini ]
add name=tech password=_CYP_XXXXXXXXXXaa9a0f9d4dad275559194f role=TechnicalSupport hash2=XXXXXXXXXX7cd799135924d299fcc55d defremadmin=enabled
add name=Theliel password=_CYP_AE2B1FCA515949E5D54FB22B8ED95575 role=Administrator hash2=XXXXXXXXXX… defuser=enabled

Con un poco de imaginación puedo suponer que la contraseña está en algún tipo de Hash para protegerla, dado que son 32 caracteres numéricos y alfabéticos, lo más normal es que sea un Hash MD5, y por su formato no parece que tenga ninguna Salt. Pero es fácil saberlo, mi contraseña la conozco “testing”, tan solo tengo que calcular algunos hash para ella y ver si alguno coincide, y efectivamente coincide. El hash MD5 de “testing” es AE2B1FCA515949E5D54FB22B8ED95575. El hash 2 debe de ser posiblemente un hash de protección, pero no es importante. el Hash de la cuenta tech lo tengo (lo he protegido por XXX por razones de seguridad). Si pudiese romper el hash y obtener la contraseña por él, tendré la contraseña del usuario tech. Esto es útil? Bueno… aun no lo sé, pero toda información siempre es buena. Así que me puse manos a la obra.

Como romper un Hash MD5? esto lo publiqué en uno de los artículos de seguridad. Pero lo mejor es siempre que sea posible pensarlo. Esta contraseña la pondrá el ISP, luego es posible que pueda encajar con algún diccionario. Primer intento? Un ataque por diccionario. He de decir que esto no me dio ningún exito. Bueno la segunda opción es por medio de tablas rainbow, es el método más efectivo, además sé perfectamente que no es un hash con salt. ¿Problema? Estoy en la playa, no tengo aquí los GBs y GBs de las tablas rainbow, ergo esto lo tenemos que descartar también. Tan solo queda un ataque de fuerza bruta. Cuando se realiza un ataque de fuerza bruta hay que ser realista, de nada sirve lanzar un ataque que puede durar años y años. Si puedo tener éxito me vale si es para dentro de como mucho una hora, más tiempo no voy a entretenerme con ello. Por ello lo máximo que me voy a permitir es un juego de caracteres de:

1-8 caracteres en minúsulas -> Sin éxito, hash no encontrado
1-14 carácteres solo numéricos -> Éxito!!

C:\Users\Theliel\>MDCrack-sse.exe –charset=%N xxxxxxxxxxaa9a0f9d4dad275559194f

System / Starting MDCrack v1.8(3)
System / Running as MDCrack-sse.exe –charset=%N xxxxxxxxxxaa9a0f9d4dad275559194f s
System / Filtering custom charset… done
System / Charset is: 0123456789
System / Detected processor(s): 8 x INTEL Itanium | MMX | SSE | SSE2 | SSE3
System / Detected hash format: MD5
Info   / Other possible matche(s): MD2, MD4, PHP, MD4MD4, MD5MD5
System / Target hash: xxxxxxxxxxaa9a0f9d4dad275559194f
System / >> Using MD5 cores: maximal candidate/user salt size: 16/54 bytes
Info   / Press ESC for available runtime shortcuts (Ctrl-c to quit)
Warning/ Thread number has been reduced in order to match charset size
Info   / Thread #0: >> Using Core 1
Info   / Thread #1: >> Using Core 1
…
……..
Info   / Thread #4: Candidate size: 10 ( + user salt: 0 )
Info   / Thread #2: Candidate size: 10 ( + user salt: 0 )
———————————————————-/ Thread #3 (Success) \—-
System / Thread #3: Collision found: 1122334455
Info   / Thread #3: Candidate/Hash pairs tested: 463 062 646 ( 4.63e+008 ) in 59s 131ms
Info   / Thread #3: Allocated key space: 2.22e+015 candidates, 0.00% done
Info   / Thread #3: Average speed: ~ 7 831 081 ( 7.83e+006 ) h/s

Bueno, he tenido suerte, era una contraseña numérica de 10 dígitos: 1122334455 (No era esa, pero por razones de seguridad será esa la que usemos). Solo tengo que intentar un acceso por telnet y ver si es la contraseña realmente. Bueno, telnet me responde con un error, pero no me dice que la contraseña sea errónea, sino que dicho usuario tan solo tiene acceso remoto, no local. Si pruebo con otra contraseña me responde directamente contraseña/usuario incorrecto, ergo ya tengo la contraseña del usuario tech.

Indagando un poco en Destiny pude comprender que este router tiene una serie de jerarquía de niveles de acceso bastante seria. Por ejemplo existe siempre un usuario por omisión root con acceso completo. Mi usuario Theliel con permisos administradores posee permisos para modificación de todos los servicios, pero no tiene acceso desde remoto. El usuario tech le pasa lo contrario, tiene permisos casi totales pero no de forma local. Puedo modificar los permisos de Theliel como desee, pero no puedo realizar ninguna tarea sobre tech, labor que tan solo puede el usuario por omisión root:

{Theliel}=>mlp config addpriv name Administrator anyaccess anyservice

Con eso Theliel obtendrá permisos de acceso remoto, y tech no es en principio un problema, dado que Destiny no permite por defecto ningún tipo de acceso externo, tan solo cuando premeditadamente se permite dicho acceso. No obstante, ya que poseo la contraseña de acceso del usuario tech sería buena idea intentar el acceso como root con dicha contraseña. Y de nuevo éxito!! Y con acceso de root ahora sí puedo eliminar si así lo deseo el usuario tech de forma permanente:

{root}=>mlpuser config delete name tech

Con esto podría dar por concluido la diversión. Esto es algo que no se debería de hacer nunca, dado que podríamos producir un bloque completo del dispositivo y hacerlo irrecuperable por parte incluso de su dueño o el ISP. Primero cambiando la contraseña de root garantizaríamos que nadie pudiese acceder al router. Pero queda otra cuestión. El dueño de Destiny ante cualquier tipo de sospecha o incluso vita de un técnico o recomendación de un amigo o… le bastaría con pulsar el botón de reset en la parte de atrás del router para que todos los ajustes volviesen. ¿Que se puede hacer ante esta situación? Anular el reset. NOTA!! Anular el reset de un router (no todos se pueden) es una práctica poco aconsejable, y tan solo se debería de hacer en circunstancias muy concretas. En este caso sí es posible deshabilitar el reset:

{root}=>system config resetbutton=false
{root}=>saveall
{root}=>system reboot

Terminamos guardando todos los cambios y reiniciando Destiny, una vez reiniciado completamente bajo mi control. Si algo fallase al tener el botón de reset deshabilitado y sin ningún otro usuario autorizado para acceder, el router se quedaría completamente inservible, recuperable tan solo a través de un cable de consola o un JTAG para poder eliminar la nvram.

¿Que se gana? Bueno, esto es solo un resumen. Una vez concluí todo, incluyendo una instrucción para aumentar la potencia del adaptador WIFI, pasé de tener un 19% de señal a un 29%, haciendo posible disfrutar de una navegación completamente fluida y sin ningún tipo de corte, sin necesidad de tener e Chaos orientado a ninguna parte.  Por otro lado, podía estar seguro ya no solo del firewall de mi propio router, sino tb del de Destiny.

¿Moraleja?

Las personas siguen sin darse cuenta del peligro que entraña la seguridad y la privacidad. Ambas deben de ser un deber para cualquier usuario. Quien no pueda porque no lo sepa, existen profesionales para auditar la seguridad de una empresa o incluso de un usuario!! el peligro no es algo tan banal como robar un poco de conexión por dios, eso es lo de menos. El peligro es el acceso a toda la red del usuario, el poder usar técnicas de sniffing (me queda poco para terminar el siguiente artículo) o simplemente el molestar por molestar al que se tiene al lado. No implica que todos sepan o que cualquier persona puede jugar con tus infraestructuras, pero tampoco puedes dar por echo de que tu sistema es realmente seguro. Que hubiese pasado si en vez de la casa de un vecino es el negocio de una empresa? Que sucede si soy un cabrón y no solo no hablo con el dueño sino que uso su red de forma indiscriminada e incluso ilegal!! por ejemplo descargando pornografía infantil o cualquier otra historia. Una vez más… ¿soy un paranoico o tengo algo de razón en ello?

Un saludo.

PD: La crónica de la playa segunda parte no creo que sea escrita. Posiblemente conecte el modem 3G directamente a mi router ASUS-NT16 o realice un puente de red en el PC para enviar la conexión al viejo WRT54GL y usar este para WIFI u otros equipos. Aunque nunca se sabe… en cualquier momento tengo acceso a otra red y repetimos esta misma crónica pero con otro modem/router diferente.

Mientras que termino el siguiente capítulo sobre Sniffing – Protocolos IP, TCP, DNS… (ya sé que voy retrasado en los plazos), voy a aprovechar para meter una pequeña cuña y criticar lo que me parece algo completamente despreciable y simplemente comentar otro par de cosas.

Por un lado, llevamos unas semanas en las que no paramos de ver en todos los medios de comunicación, ya sea prensa escrita, radio o televisión noticias sobre Apple, sobre iPad y sobre los cada vez más aburridos comentarios de Jobs que empiezan a ser cansinos y repetitivos.

La última batalla a campo abierto ha sido cuando el CEO de Apple, Steve Jobs ha atacado entre otras cosas el modelo actual de los PC, diciendo sin problema alguno que la era del PC ha terminado y que parece que eso incomoda a muchas personas. De nuevo, el CEO de Apple no puede contener su ego y su prepotencia.

Lo único que sucede es que esta vez le ha respondido directamente el señor Steven Ballmer, presidente de Microsoft. Hay que dejar claro que ninguno de estos dos señores son hermanitas de la caridad, y que con toda seguridad comen mejor que todos nosotros juntos… de echo si no recuerdo mal Steven Ballmer es la primera/segunda persona más rica del mundo actualmente según Forbes. Pero entre estas dos personas hay una gran diferencia ética y de estar. El señor Jobs usa el dinero para comprar medios de comunicación en todos los lugares del mundo y aparecer cada vez que le es posible para criticar e intentar comerle la cabeza a cada persona de planeta. El señor Ballmer se dedica en cambio a dirigir una empresa. Rara vez vemos a Ballmer realizar un comunicado o aparecer en los medios para intentar convencer a unos cuantos.

Pero a mi me gusta siempre hablar con echos, no con palabras que podría escribir un niño pequeño y dejarlas como tal. En los últimos meses, ¿cuantas veces ha aparecido el señor Jobs en la prensa o haciendo comunicados crispantes? Cuando no es para arremeter contra Windows, lo hace para arremeter contra HTC, contra Nokia, contra Android, contra Flash… y ahora contra los PCs en general. Alguno de mis lectores recuerda cuando fue la última vez que escuchó a Ballmer decir algo sobre la competencia o criticar la actuación de alguien? Que ahora mismo recuerde (aunque es posible que haya realizado alguna otra aparición popular) en el lanzamiento de Windows 7 hace ya pues 8 meses poco más o menos.

Volvemos a lo mismo de siempre, Jobs necesita que se hable de él y de su empresa, necesita gastarse ingentes cantidades de dinero en publicidad y en comprar noticias. Ahora bien, vamos a pensar que este redactor no es nada objetivo y se invente la mayoría de las cosas. Es posible que no tenga acceso a las cuentas de Apple, pero el caso que les cuento a continuación es cuanto menos curioso.

El Pais, el periódico con mayor tirada aquí en españa lleva dando noticias sobre Apple desde hace ya bastante tiempo. Raro es el día o la semana que no tenemos algún artículo por su parte. Pues bien, tengo que decir que desde mi punto de vista es el periódico más imparcial a la hora de dar las noticias y por eso es el que leo. Ojo!! no digo que sea perfecto, y esto es una crítica en toda regla a ellos. Continuando con el tema que nos atañe, me di cuenta desde hace ya meses que absolutamente TODOS los artículos que se hacían mencion a Apple para decir sobre el iPad y sus virtudes, sobre MAC OS, sobre Jobs, Sobre Flash… TODOS tenían los comentarios deshabilitados. Cuanto acudes a la prensa internacional o local de otras casas, te das cuenta que el 80% de todos los comentarios siempre son contrarios a Apple.

Misteriosamente, hoy/ayer se hace eco de la contestación de Ballmer a Jobs. Pues bien, ese artículo como tantos otros permiten perfectamente los comentarios del lector. ¿Casualidad?

La mayoria de todos los artículos que he tenido el gusto de entretenerme a leer de cuestiones sobre las que nos atañen son claramente subjetivos y llenos de errores no solo técnicos, sino también llenos de parcialidades, de falta de profesionalidad y de conocimiento de lo que se está escribiendo. Particularmente no conozco la política de dichos diarios, diarios que todos abogan por la necesidad de las comunicaciones y de la calidad de la información. ¿Quereis hacerme creer que la información es de calidad cuanto tan solo se aprecian faltas de todo tipo? Señores, si quereis escribir un artículo sobre Flash y lo que dice el señor Jobs, primero tienes que saber que es Flash, que es HTML5, y después si quieres haz tu artículo. En vez de eso simplemente les basta con plasmar en sus diarios de P a PA lo que ha dicho el señor Jobs (en este caso). Eso en mi pueblo no se llama un artículo o una noticia, se trata de hacer publicidad gratuita (aunque eso de gratuita lo dudo enormemente).

Lo único que ha logrado el señor Jobs es que las personas sean cada vez más extremistas en sus pensamientos. Los fanboys de Apple comprarían hasta cristales de colores, mientras que los que ven lo que es Apple cada vez lo aguantan menos, incluso son muchos lso fanboys de Apple que comienzan a estar un poco cansados de las palabras de este señor.

Señor Jobs, el PC perdurará durante años y años por una sencilla razón: Es irremplazable. Un tablet es un PC, un portatil es un PC, un Netbook es un PC. Su iPad no es un tablet, su iPhone no es un smartphone. Su iPad es un sistema completamente cerrado con unas aplicaciones instaladas de fábrica y al que se le puede añadir algunas mas, dle mismo modo que la Nintendo DS por medio de cartuchos que compras le puedes poner juegos. Es exactamente lo mismo.

Este tipo de dispositivos es imposible que sustituyan al PC por un millón de razones. El iPad es un dispositivo tremendamente absurdo y falto de prestaciones y funcionalidades. El iPad jamás podrá sustituir un PC, a menos que el usuario de ese PC lo único que haga en él sea escuchar música, música por cierto que posiblemente querrá transferir desde SU PC. Pues bien, para Apple, el tener una pantalla grande y poder comprar aplicaciones que deben de pasar un estricto control NO DE CALIDAD sino de censura, un navegador que no puede visionar el 80% de las web y tres cosas más vale 500€. Si quieres reirte de algunos usuarios que sean capaces de pagar 500€ por esa basura tu mismo, pero eso es una cosa y otra decir que el PC tiene los días contados precisamente gracias a esos dispositivos. De verdad crees que tus dispositivos elimianan la necesidad de un PC? Precisamente tus dispositivos así como tu OS (iPhone OS , MAC OS) son los OS menos versátiles y restrictivos que hay para todo. Intenta crear una presentación en un dispositivo así, o escribir una carta, o enviar un correo complejo, o poder tener la libertad de hacer con tu dispositivo LO QUE QUIERAS, que para algo es tuyo.

Es cierto que el señor Ballmer no es que sea un experto en las masas y que podría aprender un poco de como dar un buen meeting, se le podrá criticar por la cantidad tan absurda de dinero que tiene, se le podrá criticar porque haga las cosas mejor o peor… pero jamás se le podrá criticar de tarjiversar de criticar de forma gratuita o de comer el coco a las personas. De echo, me ha sorprendido que se decidiese salir a la palestra con todo esto, pero tb hay que comprenderlo… son muchos los que están ya muy hartos y quemados por las tonterías de Apple y Jobs.

Eso sí señores, según Jobs son todos, el 95% de la población, los que se sienten incomodos porque el PC esté tocando su fin o porque Flash vaya a morir mañana. Y por eso Apple al final tuvo que comerse el orgullo y poner USB en vez de Firefire y por eso ya ha comenzado a aceptar HDMI en vez de DisplayPort. Eso sí, no hay ninguna noticia que diga: Jobs da marcha atrás, se da cuenta del error y cambia su displayport que no usa ningun monitor por HDMI. Claro… pero los que estamos equivocados somos el 95%, el posee la verdad absoluta de todo. O estás con él, o es que eres un inutil que no tienes ni idea de nada, es su forma de ver las cosas.

Para acabar, criticar también no solo a estas dos personas, sino a la comunidad en general. Lees artículos en los diarios, en los blog, en los foros, en los comentarios de las personas… y lo gracioso es que la gran mayoría de todo lo que lees (sea pro o contra Apple) son informaciones que son completamente FALSAS. Confuden UNIX con Linux, son incapaces de dar un solo dato que pueda verificarse, repiten al dedillo las coletillas de otros… critican sin saber a fin de cuenta. No digo que no se pueda dar una opinión, para eso vivimos en un pais libre… pero al menos preocupate por saber si lo que estás diciendo es real o no lo es. Hay cosas por supuesto que son subjetivas y depende del punto de vista de cada persona, ES EVIDENTE, pero con la tecnología el 99% son cuantificables.

Un caso que me ha hecho bastante gracia ha sido sobre UNIX/Linux. Un usuario respondía a un artículo sobre las palabras de Ballmer diciendo que Windows es un infierno y lo único decente eran los sistemas UNIX como MAC OS y Linux y añadia alguans cosillas que hacía pensar que el era un usuario consagrado de ambos OS (MAC OS y Linux). Pues bien señor mío… tanto dices que conoces MAC OS o Linux ¿y me mezclas manzanas con pescados? Si en algún momento escucho decir a alguien que Linux o MAC OS comparten la misma base UNIX no sucede nada, le corrijo y le explico la historia de Linux y UNIX. Si alguien deleante mía se jacta de usuario MAC OS o Linux y me dice lo mismo, me tengo que enfadar o reirme, y paso a explicárselo de un modo más jocoso. Señor mío… LINUX no es UNIX. MAC OS sí está basado en UNIX, concretamente si la memoria no me falla a BSD. Linux NO, Linux fue una alternativa que nació de crear un UNIX libre, pero no comparte con él nada, el Kernel de Linux fue creado desde cero. De hecho el nombre de Linux proviene más de su creador que de UNIX, del maestro Linus Torvarls Linus + X = Linux. Por supuesto que Linux es un sistema tipo UNIX, eso nadie lo duda, es evidente, pero es que se creó como ese fin. Pero Linux no es Unix ni mucho menos.

Son este tipo de cuestiones que las puedes explicar y te diviertes ademas charlando amigablemente con cualquier usuario. El problema es cuando aparecen personas que dicen saberlo todo y cometen errores de base como esos.

En fin…

El problema de ir contra todo el mundo e intentar imponer tus ideas a base de repetirlas y de la crítica rápida, es que puede darse el caso de que todos comiencen a luchar por objetivos en común, y tú te quedas fuera. Pero antes de entrar en materia vamos a recordar un poco esta historia:

En estos días es raro encontrar algún lugar donde no se hable de Flash, HTML5 o H264. Ya hemos hablado de todo ello bastante en profundidad, pero es que estos días se ha vuelto a dar otra vuelta de tuerca más. Si bien hace unos días Steve Jobs publicaba una carta abierta y algunos días despues Adobe hacia lo propio, hoy es Google el que ha decidido tomar cartas en el asunto. Es cierto que no afecta directamente a Flash, pero sí indirectamente.

Recordemos como Apple no hacía otra cosa que defender de forma férrea el codec estandar H264 para la característica que tendrá la especificacion HTML5 para reproducir video sin necesidad de plugins como Flash. Igualmente recordamos Adobe diciendo o recordando la necesidad de Flash.

Si volvemos un poco más en el tiempo, recordemos que dijimos que actualmente los navegadores Firefox, Opera, Safari Y Chrome ya habían adaptado sus navegadores para poder hacer uso de la característica <video> de HTML5, pero que el problema que aparecía eran los Codec. Si, HTML5 permitirá reproducir videos, pero si HTML5 es un esntadar se tendrá que acordar también un estandar para el audio y otro para el video a reproducir. Y es aquí donde comenzaba la tragicomedia., puesto que no todos tienen intenciones meramente altruistas, y algunos de los afectados tiene intereses económicos.

Recordemos que por parte de Firefox, tenemos actualmente soporte HTML5 <video> (recordemos que todo lo que sea referente a HTML5 NO ES DEFINITIVO). En el caso de Mozilla optó por usar como codec de Video Theora y como codec de Audio Ogg Vorbis. Ambos codec son de código abierto y sin ningún tipo de licencias. Cuando se habló sobre implementar también H264 como codec de Video por ser el estandar actual de HD y por tener además mucha más calidad en todos los aspectos, Mozilla respondió que sería ideal, pero que H264 está fuertemente patentado, lo cual hace que esté constantemente sujeto a posibles royalties o compras de licencias, ya sea para la propia organización Mozilla por incluirlo en el navegador, como para los creadores de contenidos que quieren publicar sus videos en la Red.

Por otro lado tenemos la MPEG LA que administra las licencias de H264 (recordemos que H264 es otro nombre de MPEG4 AVC Part 10, que es como se llama formalmente el Codec). Desde el punto de vista de la MPEG LA le interesaría que el codec fuese usado extensamente, aun cuando su utilización web quedase completamente libre de cargos o royalties. Es así que ya anunció que a priori y hasta 2015 esto será así. No obstante, hay que tener en cuenta que en cualquier momento la MPEG LA podría comenzar a cobrar por su uso… y es evidente que esto no es del agrado de nadie. H264 posee muchas tecnologías fuertemente patentadas por diversas entidades que evidentemente dudo mucho que TODOS liberasen H264, con lo que H264 pese a ser el mejor codec q actualmente disponemos, no es una opción viable de cara a una Internet “libre”.

En el lado del Ring de Firefox, aparece también Opera, el cual piensa prácticamente lo mismo que este, por el tema del navegador. Hay que tener en cuenta que de no afirmar la MPEG LA el libre pago hasta 2015, Firefox u Opera tendría que pagar 1 Millón de dolares en conceptos de uso… lo que no es calderilla para organizaciones sin ánimo de lucro. Pero al lado de estos no solo está Opera, sino muchos otros que H264 les cuesta el dinero, lo que sucede es que ahora mismo no hay ninguna alternativa viable… ¿o sí?

Pero la MPEG LA no está sola. Cuenta por supuesto con el apoyo incondicional de Apple, Intel o Microsoft por una razón muy muy simple: Ellos han contribuido en mayor y menor grado al desarrollo de H264, es en parte “su codec”. Ellos no tendría que pagar por el uso de dicho codec, y dado que H264 es actualmente el codec más superior en el mercado… En cuanto navegadores Apple con safari y Microsoft con IE lo tienen claro, sus navegadores SOLO podrán usar H264 como codec de Video. IE9 aun está en fase Alpha, pero MS ya ha anunciado que así será. Safari ya dispone de soporte preliminar para HTML5 <video> con h264. Pensar que esto es un problema enorme!! Firefox y Opera no soportarán a priori H264 (y dudo q lo hagan despues de las últimas noticias), y por el otro lado, Safari y IE tampoco soportan Theora y solo H264. Recordemos que HTML5 ES UN BORRADOR!! actualmente no se ha optado por usar uno u otro. Si en un futuro se optase por H264 está claro que todos antes o después migrarían a él, y lo mismo con Theora. Pero el problema no es que sucederá cuando uno se estandarice, sino qeu hacen los creadores de contenido antes de ello. Si quieres ir adaptándote a HTML5, ¿como creas tus videos? Si los dejas en HTML5 actualmente solo Safari y Chrome pueden visualizarlos, lo que hace que sea un 15% aproximadamente de usuarios. Si por el contrario lo haces en Theora, entre Firefox,  Opera y Chrome tienes un 30-40% de usuarios que lo disfrutarían.

Pero no todos están en un lado u otro, en medio tenemos a un pesos pesados, Google. Google ha dado soporte en Chrome tanto para Theora como H264. Recordemos que Google uno de sus principales negocios es el video. Para google una tecnología de compresión superior (igual calidad y menos espacio) implica ahorros millonarios en ancho de banda y almacenamiento. Para Google esto es serio, y es por eso que actualmente prácticamente la totalidad de videos de YT están en h264. Google siempre ha sido más de la opinión de H264, pero hace unos meses, entre la compra de ON2 (una reconocida empresa de codec de videos, como el famoso VP6/7 y actualmente VP8) y las broncas qeu han tenido todos contra Apple le han echo dar el paso q se esperaba. Google en Enero compró como hemos dicho ON2, lo que hace automáticamente propietario de VP8. VP8 es un codec de video actual, que tiene unas capacidades de compresión interesantes. Desde mi punto de vista y de algunos expertos, H264 es superior. Por parte de Google y los interesados por supuesto VP8 es superior. Pero lo que está claro es que VP8 si es un codec más que decente, supera por bastante a Theora y puede al menos pelear contra H264, lo cual no es poco. VP8 era propiedad de ON2, un codec fuertemente licenciado, pero en manos de Google todo parecía que iba a quedar libre… y así ha sido. La filosofía de Google ha sido la más radical en estos tiempos en cuanto a hacer negocios. Mientras que empresas como Apple intentan exprimir sin aportar demasiado, Google ha estado constantemente innovando y haciendo todo (prácticamente) público y libre de cargos. Google obligó a Microsoft a actualizar Hotmail, y a día de hoy Gmail se ha convertido en la mejor plataforma de servicios de correo/calendario/contactos… A los amigos de Google les gusta el dinero como el que más, pero saben que a la larga aportando ganan más. Todo esto se traduce como? Con la publicación del código de VP8 y licenciando este bajo licencia similar a BSD, es decir, que cualquiera podrá usarlo para crear codec o contenidos con estos codec sin tener que pagar nada.

Pero Google ha ido aun más lejos!! No solo ha liberado VP8, sino que ha creado un consorcio entre algunas de las compañías de tecnología más importantes del mundo, como puedan ser la poderosa nVidia o ATI (por parte de AMD),  Adobe, Mozilla, Opera, Google (evidentemente), ARM, MIPS, Logitech, Marvell… y es evidente que se espera que muchas otras  se unan a esta iniciativa, que no es otra que trabajar en conjuntos para la creación de un estandar para el video en internet, basado en VP8 como video, Ogg Vorbis para el audio y un contenedor para ambos basado en Matroska. Google por otro lado ha comenzado la conversión de los videos de YT a VP8 también.

Pero como afecta todo esto a HTML5 o a H264?

Para Firefox u Opera es una salida más que satisfactoria. Ambos no tendrán problemas en adaptar sus navegadores para incluir VP8 en caso de que la iniciativa prospere. Estas tecnologías estarán totalmente libre de cargos, lo cual es bueno para ellos y bueno para nosotros.

EDITO: Los programadores de Mozilla Firefox han hecho los deberes y ya tienen las primeras compilaciones (en versión preview) con soporte para Webm (el proyecto comentado). Quien quiera puede probar en este enlace: http://download.mozilla.org/?product=devpreview-1.9.3a4webm&os=win&lang=en-US. Una vez más se demuestra la eficiencia y capacidad de trabajo de estos chicos. Es muy posible que Google haga lo mismo con Chrome

Para Apple y Microsoft es, y perdón por el lenguaje, una putada enorme. Apple lo tiene aun más crudo de los dos. Para empezar ambos son beneficiarios directos de h264, lo cual implica que se está optando por una tecnología de la cual no obtienen beneficios. ¿Por qué Apple lo tiene peor? Primero por sus dispositivos portátiles iPod Touch, iPhone e iPad. Recordemos que no tienen soporte flash!! lo que haría posible actualmente ver el 80% de webs, ya  que usan esta tecnología, pero tampoco pueden ver videos que usen Flash como contenedor. Estos dispositivos se limitan tan solo a poder ver videos de las web que estén creados con el borrador HTML5 y h264 bajo condiciones muy específicas. Si VP8 llega a estandarizarse para HTML5 realmente, los usuarios de iPhone, iPad e ipod Touch se quedarían completmaente a ciegas, dado que tampoco tienen Flash. A microsoft esto le importaría menos, dado que IE9 aun no ha visto siquiera la luz (y aun tardará). Además, los tiempos modernos nos dicen que Microsoft ha aprendido las lecciones del pasado, y si ve que VP8 empieza a ganar la batalla implementará VP8 si es necesario… pero honestamente dudo que Apple de su brazo a torcer tan fácilmente, más teniendo en cuenta que todo lo que ha hablado y criticado estos meses, TODO, se volverá contra él si H264 no aparece en HTML5

EDITO: Microsoft ha confirmado hace unos minutos que implementará soporte para VP8 en IE9, aunque el usuario tendrá que tener instalado el Codec en el Sistema. Esto deja a solas a Apple, y convierte VP8 en una opción cada vez más real. Como he dicho justo antes, Microsoft ha aprendido bien las lecciones de pasado.

¿Para Intel? No suelo hablar mucho de Intel por una razón muy simple. Como he dicho siempre Intel juega siempre en una liga aparte. Existen grandes empresas y por otro lado existe Intel. Intel estaba metido en el desarrollo de pleno de H264, pero es que es muy raro encontrar un proyecto que pueda tener futuro en el que Intel no esté incluido!!. No puedo asegurarlo, pero posiblemente la cartera de patentes de Intel sea la mayor que existe. Dicho de otro modo, posiblemente Intel (personalmente claro) sea una de las compañías con más poder en el mundo (sino la más). Esto es simple… podemos hablar de nVidia, AMD, IBM, Apple, el gobierno de Estados Unidos, la NASA… pensar en lo que queráis, pero Intel lo hace posible. Por poner un ejemplo sencillo, AMD puede fabricar procesadores porque Intel se lo permite. Podemos hablar del poder o importancia de Google por supuesto, o de Microsoft!! pero es un poder… “diferente”. El poder de Intel llega a prácticamente cualquier rincon del mundo, no solo Internet. Todo esto que quiere decir? Que Intel prefiere H264, pero ni tiene un navegador ni creo sinceramente que se preocupe mucho por si VP8 o H264. De echo no me extrañaría lo más mínimo que Intel accediese unirse a la iniciativa de Google.

¿Y para nosotros? Para nosotros usuarios depende de que herramientas usemos, es evidente. Si somos tan solo navegantes con Firefox, Chrome u Opera, no tendremos que preocuparnos de mucho. Si somos usuarios de iPhone/iPod/iPad o Safari tendremos un gran problema si VP8 es aceptado como estandar para HTML5, dado que está por ver el soporte que pueda tener. Si somos creadores de contenido Web tampoco nos importará una vez el estandar está claro y vemos la tendencia, ya que lo que deseamos como creadores es que nuestras creaciones puedan llegar a TODOS. Si somos creadores de contenidos Web Y nos dedicamos a la codificacion de Video por aficción, trabajo y otros, puede ser un poco engorroso, ya que lo ideal sería estandarizar una tecnología para TODO, y así para contenidos HD en el PC o en casa tendremos H264 y para Web VP8

¿Personalmente que opino?
Bueno… mi corazón está dividido. Sin duda alguna soy defensor de H264 por su gran calidad, pero igualmente defensor de los estándares abiertos y accesibles para todos, si es código abierto mejor que mejor. Pero visto todo, creo que prefiero sin duda que la iniciativa de Google prospere, HTML5 incluya VP8 como codec y en casa continuaré usando H264 sin duda. Existiría la posibilidad de que el consorcio que estudia y crea HTML5 considere la inclusión de H264 y VP8 indistintamente? Sería una posibilidad, pero sería un problema más que una virtud, ya que quien quiera meter en el navegador H264 tendrá que pagar posiblemente a la MPEG LA, y en cambio VP8 estará en todos los navegadores de manera segura, lo que hará a los creadores de contenido crear los videos en VP8 y así asegurarse su visionado.

El tiempo nos dirá que sucederá. Recordemos que hasta 2012 no se esperan las especificaciones más o menos fijas de HTML5, y hasta 2020 aproximadamente su publicación final.

Esto tiene gracia… mucha mucha gracia.

El 14 de Abril, hace aproximadamente 1 Mes, Apple renovaba su gama de MacBook, recordemos el artículo anterior, desde mi punto de vista bastante interesante:

Apple renueva la gama de sus MacBook

Dicho pequeño artículo terminaba diciendo que Apple hacia de nuevo lo de siempre, cambiarle el collar al perro, aunque esa vez dejó hasta el mismo collar. También aseguraba que no era más que un lavado de cara para intentar atraer a algún ingenuo nuevo a sus redes intentando convencer de que su rendimiento era muy superior a todo lo conocido.

Pues bien., hoy vengo aquí, un mes después (unos 33 días) con exactamente la misma historia. En realidad esta vez Apple me ha sorprendido. Pensé ingenuamente que la próxima actualización por fín implementarían Core i3/Core i5 en sus MacBook, pero lo más gracioso es que no solo no los ha implementado sino que ha “renovado” la gama de Macbook en tan solo un mes!! Es decir, en 30 días Apple cambia la gama de portátiles!! esto tiene que sentarle de maravilla a aquellos que hace un mes al ver la noticia dijeron: “Esta es mi ocasión”

Pues bien, El único cambio que ha realizado esta vez ha sido actualizar la tarjeta de video, cambiando la nVidia 9400 integrada por una nVidia 320M. ¿Esto es malo? Para nada, nada más lejos, la 320M es mucho mejor que la 9400 antigua que tenía. Pero vamos a escuchar mejor toda la historia. Para empezar, recordemos que no hace ni un mes que renovó la gama, y que la 320M lleva en el mercado ya bastante tiempo. Es decir… os aseguro que Apple sabía de antemano que un mes después renovaría la gama.

Por otro lado es muy gracioso un dato. Ahora, los nuevos modelos (los más nuevos) podrán utilizar algún conversor DisplayPort-HDMI. Recordemos que Apple en su empeño de putear al cliente no incorpora HDMI. Sí, el estandar que se usa en el 99% de todos los televisores/pantallas del mercado, mientras que tan solo implementaba DisplayPort. De esto en concreto estoy hablando desde hace ya más de un año, diciendo que a ver el tiempo que tardaría Apple en dar su brazo a torcer y cambioar DisplayPort por HDMI. Recordemos que esto no es nuevo, tan solo hay que mirar atrás y la cabezonería de Apple de usar Firewire en vez de USB, y por tanto sus portátiles no tenían USB. Pues bien, después de un año y medio ha accedido al menos a permitir usar un adaptador para convertir ese DisplayPort en HDMI. OJO!! esto tiene trampa!! DisplayPort no es compatible con HDMI, es posible que los conversores den problema, es más, la misma Apple no los vende. Pero al menos algo es algo. De nuevo el culo apretado de Apple lo único que hace es perjudicar al usuario, cosa que realmente no le suele importar demasiado, dado que este suele ser ya un fanboy y haga lo que haga y diga lo que diga Apple bien estará.

En su Web leemos exactamente esto:

“Disfruta de mayor rendimiento gráfico para todo, desde los juegos hasta la navegación en Internet.”

Lo más gracioso es que el soporte para gráficos de MAC OS es prácticamente nulo. ¿Juegos? o son en OGL o te puedes despedir de ellos, y por mucho que me guste OpenGL, cada día más se impone en todo DirectX para gráficos. Por otro lado Safari no dispone de aceleración hardware!! Es decir, que la frase anterior es cuanto menos engañosa y falsa. ¿Mayor rendimiento gráfico? Si, si la usara, prácticamente tan solo aplicaciones OGL. ¿navegación web? Flash para MAC OS no tiene soporte de aceleración hardware, Safari no posee tecnologías D2D de aceleración hardware como las que está implementando actualmente Firefox (tan solo para Windows). Claro que todo lo que sea para mejorar es positivo, pero habría sido mucho más significativo cambiar el procesador, que a fin de cuenta es mucho más usado.

Supuestamente la otra novedad es la batería… pero va pareja al adaptador de video. Tecnología de fabricación menor + tecnologías más moderna = Menor consumo. Aun así como ya dijimos en la comparativa de precios, 10 horas de batería no es para nada sorprendente, ahí tenemos portátiles como el ASUS UL30jt (jt o vt, no recuerdo de memoria) en el que la batería llega a las 12 horas y es un Core i5.

Pero lo mejor de todo lo reservo para el final. Estamos llegando a final de Mayo, el quinto mes del año. Quereis escuchar una cosa graciosa? Los procesadores Core iX de Intel están creados con la Arquitectura Nehalem de este. Intel cada dos años cambia la Arquitectura y cada dos años también reduce la capacidad de integración. Pues bien, Nehalem cumplirá en el cuarto trimestre dele año sus dos años. He dicho que cada dos años aproximadamente intel cambia de arquitectura y de tecnología de integración, pero lo hace intercalado. Es decir, un año cambia la arquitectura, al siguiente la integración, al siguiente la arquitectura, al siguiente la integración. Es decir, cada Arquetectura creada por Intel actualmente vive dos tecnologías de integración diferentes. Actualmente, con arquitectura Nehalem (Core iX) tenemos los procesadores de 45nm y los de 32nm. A Nehalem solo le queda de vida unos 4-5 meses antes de que la nueva arquitectura salga a la luz.

Ya dijimos en el artículo anterior de “Apple renueva su gama” que la arquitectura es algo muy importante. Pues bien, la sustituta de Nehalem se llama Sandy Bridge y se espera su lanzamiento (primero en portátiles) para el octubre aproximadamente. Para el sector de sobremesa llegará en enero/febrero del año siguiente. Que implica una arquitectura nueva? Pues si vamos a lo simple para el de a pie, digamos que un incremento en igualdad de condiciones de reloj de un 20-50%. Sandy Bridge no obstante no será una remodelación total de Nehalem, sino que será más bien un Nehalem II, lo cual no quiere decir que los cambios no sean significativos, como por ejemplo un interesante esfuerzo increible por parte de Intel para reducir el consumo al mínimo, recordemos que los Core i5 de bajo consumo consumen 10W MENOS que sus homólogos Core 2 Duo.

Que tiene que ver todo esto? Pues es simple. Como a mediados/finales de Mayo Apple ha renovado la gama de sus portátiles, los cuales usan tecnología de hace 3-4 años (Arquitectura Core), se pueden dar unas de las siguientes hipótesis:

• Apple renovará los MacBook a Core i ANTES de que Intel lance Sandy Bridge. Esta es la hipótesis con más papeletas, dudo mucho que Apple sea capaz de vender portátiles con dos arquitecturas inferiores, aunque es Apple, y esas cosas pasan con ellos.
• Apple se saltará la arquitectura Nehalem (que dentro de nada cumple dos años nada más y nada menos) y pasará directamente a Sandy Bridge. Esta hipótesis no creo que sea capaz, aunque volvemos a lo mismo… nunca se sabe.
• Apple abandonará su romance con Intel e intentará casarse con AMD. Muchos han especulado sobre esto, pero personalmente lo dudo mucho. Intel es de lejos más eficiente en todos los términos que AMD, aunque estos últimos son una tecnología más barata. Si Apple se pasase a usar procesadores de AMD, acabaría perdiendo bastante más que ganando.

Sea como sea, el usuario ya ha perdido. Cualquier usuario de MacBook está actualmente comprando tecnología de 3-4 años. Tan solo los Macbook Pro se han actualizado algunso RECIENTEMENTE a arquitectura Nehalem (que por cierto llegan un año y medio tarde). Es decir, tecnológicamente, Apple va muy por detrás que el resto, cuanto menos en portátiles. En sobremesa no es tan así, va algo más al día, yo diría que un año atrasado tan solo. En el mundo en el que nos movemos y exigencias energéticas y de cómputo, para quien realmente lo necesite para trabajar de forma intensiva con el ordenador, Apple no es una opción, ya no solo por precio o por sistema operativo, sino por que va siempre a remolque de otros. Los primeros portátiles Core i aparecieron más de año y medio, y los MacBook aun no saben que es un Core i5, ni siquiera si llegarán alguna vez a implementarlo, aunque conociendo a Apple mientras que muchos estemos usando Sandy Bridge, estos estarán comenzando a usar Nehalem.

Que pasará con Sandy Bridge? Sandy Bridge entrará usando procesadores de 32nm y terminará su vida con los procesadores de 22nm. No obstante, escribir 22nm es rápido, tener concepción de que tamaño estamos hablando es otra cosa. Se pensó que era posible que no se pudiese cumplir el calendario para esto, pero parece que Intel estaría preparado para lanzar los primeros procesadores en 22nm para finales del 2011. Pensar más allá es complicado… los 16nm no serán fácilmente alcanbles, y de estos ha la nanotecnología, los 11nm, tan solo es un paso.

Conclusion? Apple le vuelve a cambiar el collar al perro, y no se muy bien como podrá digerir la arquitectura nueva que se acerca cada vez más. Vergonzoso renovar la gama en tan solo 30 días!! y mucho más sin realizar cambios profundos en esta, como implementar Nehalem, que tendría q haber sido impuesto hace ya muchos muchos meses. En vez de eso tan solo le cambia un adaptador gráfico que lleva más que tiempo suficiente en el mercado como para que lo hubiesen implementado hace 30 días, sin necesidad de otra renovación. Y más vergonzoso aun más es no disponer de Nehalem en la actualidad, sin saber siquiera si aparecerán este año. Es como las actualizaciones de firmware del iPhone OS, o del hardware de los iPhone!! siempre intentando renovar sus productos en el menor tiempo posible, aun cuando los cambios no son siquiera significativos, y tan solo para aparecer en las noticias o engañar con las etiquetas de “nuevo”.

Hace 2 días le entregué un portátil a un cliente por 520€. Un Core i3 que posee un rendimiento mayor en cuanto procesador al procesador Core 2 Duo del Macbook y con el mismo adaptador gráfico, nVidia 320M. Claro que tan solo costaba la mitad.

AMD? No lo creo, se especuló sobre ello porque Apple lleva queriendo mucho tiempo que Intel les cree procesadores específicos para estos, e Intel siempre ha sido claro: “No te lo crees ni tu”. Intentar hacer hablar sobre AMD puede servirle de presión a Intel, pero dudo mucho que estos cambien de parecer, y dudo aun más que Apple se vaya a AMD.

Un saludos amigos, espero que no aburra demasiado leer la misma historia que hace 30 días.

Hace unos días, el CEO de Apple hacía unas durísimas críticas contra Adobe y concretamente Flash en una carta abierta que pasé a explicar un poco según por supuesto mi punto de vista. Hoy, ha sido “presentada” formalmente la respuesta de Adobe, bajo una carta abierta en la que se defiende no solo su tecnología Flash, sino los estándares de la web. Curiosamente, muchos puntos esgrimidos por Adobe fueron los que yo mismo usé para criticar a Apple. No quiere decir que me robasen las palabras, sino que mi opinión no iba demasiado desencaminada de lo que son muchos lo que lo piensan.

El texto original publicado por Adobe se llama “The truth about flash” y podemos encontrarlo en este enlace:

http://www.adobe.com/choice/flash.html

Como ya dije en su momento, podemos de nuevo ver claramente que a la hora de criticar y hablar, Apple es el único que siempre intenta desprestigiar o sacar los colores. El resto de las empresas simplemente defienden lo que es su negocio, cosa por cierto completamente lógica. La respuesta de Adobe no es un ataque, como sí lo fue la carta de Steve Jobs, sino tan solo unos echos claros, rotundos, y sin mucho margen para la imaginación.

Antes de comenzar le texto, lo primero que podemos apreciar es la penetración de Flash en la actualidad:

• El 85% del top 100 de Alexa (empresa más que conocida), son webs que usan Flash
• El 75% de los vídeos vistos por internet se hacen a treavés de Flash según Comscore (Empresa de investigación de mercados tecnológicos)
• El 98% de todos los PCs del mundo tienen instalado Flash (se incluye por supuesto los MAC)
• El 98% de las empresas de todo el mundo confían en Flash según Forrester (Empresa de investigación de mercados tecnológicos)
• El 70% de los juegos Online usan Flash Según Evans Data Corps
• 19 de los 20 fabricantes de dispositivos más importantes del mundo han afirmado que usan/usarán Flash en ellos (Es decir, la 1 de 20 que no está presente es Apple)

Estos son los datos escalofriantes que bastarían para tapar la boca de cualquiera, pero pasado esto la misiva pasa a deshacer una a una las críticas de Apple.

Sobre la interfaz Touch:

Adobe asegura que Flash se originó en un principio precisamente para dispositivos táctiles, luego carece de sentido decir que Flash carece de sentido en dispositivos portátiles. Más aun, asegura que la versión 10.1 (la cual está en fase beta y puede ser descargada desde hace tiempo) soporta toda una serie de APIs nuevas pensada en los nuevos dispositivos. Adobe explica que simplemente se transforman las pulsaciones en clic de ratón,lo que hace que prácticamente cualquier aplicación Flash creada para escritorio funciona perfectamente bien en dispositivos portátiles.

Sobre Video:

Adobe asegura que el 75% de todos los vídeos de internet usan Flash para reproducirse, incluidos los videos en H264 o VP6. Añade que son muchos los que aseguran que H264 será el asesino de Flash, pero recuerda que H264 es sólo un Codec, el cual necesita un reproductor, mientras que Flash no es un codec, sino más bien una plataforma que puede reproducir videos tanto en H264 como toros codec, así como optimizar la transmisión dependiendo de la carga de la línea, latencia, adaptación del bitrate y otras tecnologías.

Está de acuerdo que reproducir cualquier contenido de calidad (no específicamente en Flash) es una tarea con un costo extenso para una CPU, sobre todo para los dispositivos portátiles, y recuerda que es por ello que desde hace tiempo existe la aceleración por hardware para contenido Flash y Flash vídeo, tanto en equipos de escritorio como existirá igualmente en la versión 10.1 para dispositivos portátiles. Es más, asegura que actualmente en MAC no hay soporte hardware para Flash pq hasta la fecha Apple no había hecho público una API para poder tener acceso a esta.

Sobre Rendimiento:

Adobe recuerda que cualquier contenido dinámico y/o visual en la web siempre requerirá un uso más extensivo de recursos que páginas HTML estáticas. Pero ello no quiere decir que Flash sea una tecnología lenta. Por el contrario aseguran que Flash es una tecnología tan eficiente o más como las que puedan existir actualmente para contenidos dinámicos o visuales. Así deja claro que el rendimiento Flash Vs HTML5 en la medida que sea comparable, será más o menso similar. Lo gracioso es que actualmente el rendimiento de Flash es bastante mejor que el de HTML5.

Asegura que la versión 10.1 se hace cargo de todo ello, que mayor rendimiento implica mayor batería en los dispositivos portátiles y q se han logrado grandes mejoras en cuanto a uso de memoria, CPU, inclusión de aceleración hardware… y que cualquier cambio realizado, no solo afectará las versiones para dispositivos portátiles, sino para PDAs, portátiles, sobremesas… ya que Flash es una tecnología multiplataforma.

Sobre la seguridad:

Adobe recuerda que la información que dio a conocer Apple sobre la seguridad de este no era del todo correcta. Adobe asegura que Symantec publicó un reporte en el que aseguraba que Flash era el segundo software con menor número de vulnerabilidades de todas las tecnologías de Internet. Si se tiene en cuenta que Flash también es y con diferencia la tecnología más extendida, hace realmente un logro estos números. Esta hipótesis es la que personalmente he esgrimido siempre a favor de Windows. Se ha criticado que Windows tenga más vulnerabilidades que MAC OS, pero si tenemso en cuenta que Windows está presente en más de un 93% de los ordenadores y MAC OS en menos de un 5%, decir que Windows tiene por ejemplo 30 vulnerabilidades al año y Apple tan solo 20 no es decir que Apple es más seguro que Windows, sino todo lo contrario!! las diferencia es mínima para la diferencia tan extensa de uso de cada uno de los dos sistemas operativo. Es decir, si ambos sistemas fuesen usados por igual, el número de vulnerabilidades que se tendrían de MAC OS serían infinitamente superior, siendo muy inferior las de Windows.

Adobe hace una puntualización interesante al final al hablar sobre la seguridad. Recuerda que Adobe, siempre que es informada o se descubre algún fallo nuevo de seguridad rápidamente lo corrige y lanza una versión nueva. No lo dice, pero lanza un dardo afilado contra Apple, quienes no son precisamente los que más prisa se dan nunca para nada. Recordemos el caso del exploit de los SMS del iPhone, que advertida de ello, fue necesario una ponencia publica de como piratear un iphone por SMS para que Apple tomase carte en el asunto. Es decir, Apple no asume nada, no reconoce nada. Y eso al final se paga.

Sobre sistema abierto:

Adobe está de acuerdo con que Flash es un conjunto enorme de especificaciones y tecnologías que no todas son de libre dominio. Pero asegura en cambio que la mayoría de todas ellas si lo son, como pueda ser para empezar el nucleo de Flash (AVM+) que fue donado a la organización Mozilla y que actualmente se encuentra en continuo desarrollo. Recuerda que el contenedor de video FLV, usado para los videos “flash”, es igualmente una especificación completamente abierta, asi como los protocolos de transmisión de datos en Straming RTMP ´ó AMF.

Adobe asegura que otras empresasn si lo desean (y algunas lo hacen) pueden crear alternativas basadas en esto, pero aun mucho más importante!! Cualquier desarrollador puede si así lo desea crear la aplicación o contenido Flash que desee sin necesidad de pedir permiso a Adobe. Evidentemente es otro dardo envenenado que lanza Adobe contra Apple. Y realmente es cierto, recordemos que Apple es altamente restrictiva con las aplicaciones que permite en el AppStore, y esto por cierto le ha costado una demanda que posiblemente pierda. Esto para mi es un punto muy importante. Una empresa pone la tecnología necesaria y es el cliente quien hace con ella lo que desee, ya sea un juego X, ya sea un video personal o ya sea lo que quiera. Nadie excepto Apple te dice que puedes o no puedes hacer.

Pero no es solo eso, cualquiera puede crear sus propios reproductores SWF o FLV si así lo desea sin necesidad de pasar por Adobe, lo cual es cierto. Tan solo tenemos que ver muchas web los reproductores modificados que encontramos.

Personalmente hubiese sido mucho más critico, pero se ve que Adobe se muerde la lengua. En realidad es normal, como he dicho Apple es la única que le gusta encender el fuego, mientras que el resto simplemente replica. A todo esto tan solo hay que añadir que ya se ha probado Android 2.2 con soporte completo Flash por parte de la versión 10.1 con unos resultados francamente sorprendentes, por parte de Flash y de Android 2.2. Se ha confirmado que Android 2.2 (muy cerca de ver la luz) tiene un rendimiento de un 450% sobre Android 2.1, algo realmente sorprendente!! y no es que anteriormente fuese lento precisamente.

A esto se le suma que han aparecido datos en los que se asegura que Android ya ha superado a iPhone en el mercado. Personalmente creo que aun hay que ver dichos datos con cierto recelo, dado que son muchas las preguntas que podríamos hacernos sobre la veracidad o no de esos datos. Pero lo que si es cierto es que de no superar aun a iPhone está a las puertas, y que en antes de que finalice el año, android posiblemente sea con gran diferencia la plataforma predilecta para todos y por todos.