Archivo de la categoría ‘Noticias’

HTTPS no añade legitimidad o credibilidad a una Web, brinda seguridad

Share on Google+Share on FacebookTweet about this on Twitter

Llevo ya días que al despertarme me topo con alguna noticia relativa a HTTPS, supongo que los responsables son Mozilla y Google, que desde primeros de años decidieron aplicar algunas medidas coercitivas en sus navegadores, lo que sucede es que como siempre si el usuario medio no entiende lo que quiere decirle un cartel de advertencia, al final da igual.

 

Brevemente, sobre el mensaje “nuevo” que estas dos compañías han instaurado. Es un ejemplo más que muestra el trabajo que cuesta a veces a los usuarios de perfil medio la diferencia entre seguridad y legitimidad de una página. Muchos empezaron a decir incluso que Google iba a advertir con mensajes a los usuarios sobre que una web no era segura… no tiene nada que ver con eso, de echo tanto Firefox como Chrome muestran exactamente lo que tienen que mostrar, la lectura que otros le quieran dar es diferente:

La primera es el mensaje que muestra Firefox, el segundo Chrome, este último también traslada un mensaje en la URL. En esencia dicen exactamente lo mismo. Ambas compañías simplemente muestran en pantalla ese mensaje cuando se dan dos circunstancias: La primera, estamos en un formulario que se reconoce un campo de contraseña donde vamos a introducirla. La segunda es que la Web en cuestión en la que vamos a introducir dicha contraseña no está bajo HTTPS con un certificado válido. Dicho de otro modo, al no estar la web bajo HTTPS, los datos que pongamos tanto en la contraseña como en el nombre de usuario, es posible que sean enviados en “texto plano”, es decir, tal como los introducimos, y por ende podrían ser potencialmente interceptados por alguien que “pinchase” la conexión en cualquier punto de esta.

Hay que entenderlo, no significa que la web sea insegura realmente, o que no sea legítimas. Lo que nos avisa es que si nuestra red no es segura (nos están robando WIFI, tenemos un familiar/amigo travieso conectado a ella, usamos una red pública…), alguien podría potencialmente leer ese tráfico, y claro… a lo mejor no importa tanto saber que visitas una web concreta o incluso el contenido de ella, pero si importa y mucho si lo que capturan es la contraseña de tu correo electrónico, de acceso a un servicio. Pero repito, nada tiene que ver con legitimidad o fiabilidad, y es más, esa advertencia puede no ser importante si sabemos perfectamente desde donde nos conectamos.

 

Volviendo al asunto original del artículo, estoy aburrido de leer “noticias” sobre HTTPS, Certificados TLS/SSL, “seguridad”… y casi todos ellos sesgados. El último ha sido esta tarde… no me gusta tirar tierra a nadie y respeto el trabajo de cualquiera, pero creo que hay que ser más riguroso en lo que se escribe, y por citarlos, hablo de un artículo en Xataka. A veces una coma o el modo de decir las cosas no importa y se sobre entiende, pero otras veces el significado es muy diferente sólo con que falte un acento. En este caso, y cito textualmente encontramos el problema de siempre, algunas frases muy poco afortunadas:

“Esto quiere decir, que una dirección web en la que tengas que empezar escribiendo https:// en vez del clásico http:// será siempre mucho más segura, ya que certifica que la web visitada es legítima…”

“Chrome están empezando a señalar como inseguras todas las páginas que no lo utilicen”

No voy a valorar el resto del artículo, por supuesto dice cosas totalmente ciertas, el problema es que hay otras que no lo son.

Por un lado, sobre el comentario que se hace de Chrome, es falso, siempre he dicho que una media verdad no deja de ser una mentira, intencionada o no. Chrome NO SEÑALA las webs como inseguras cuando no están bajo HTTPS, Chrome, al igual que Firefox, lo que hacen es mostrar un aviso en el campo contraseña (y Chrome también en la URL) cuando existe un campo contraseña, y ese aviso, aunque pueda usar la palabra “insegura”, especifica bien claro a que se refiere, al envío de información cuando se rellena un formulario o cualquier otra cosa. Este aviso no aparece si dicha web carece de cualquier campo de este tipo, esté en HTTPS o no.

Sobre la primera frase, realmente es lo que me llevó a volver al blog, no por Xataka realmente, lo de ellos ha sido una noticia más haciendo alusión a eso de dar legitimidad a una web o no.

 

¿Qué es y qué no es HTTPS?

HTTPS se basa en autentificación y cifrado entre el equipo de origen, y el servidor destino, de forma bilateral (por lo general la autentificación la realiza sólo el cliente, no el servidor). Que un servidor use HTTPS para servir sus webs, poco o nada tiene que ver con que esa Web sea más segura, o que dicha web sea quien dice ser, con la única excepción de que use certificados tipo EV en todo caso (en lo relativo con la identidad, es decir legitimidad).

La necesidad de HTTPS nace precisamente de los cartelitos que ahora muestran Firefox o Chrome. Cada vez más usamos las conexiones inalámbricas, cada vez más hay desconfianza de los ISP (proveedores de internet) e incluso de los propios estados!! Quien no conoce a día de hoy los casos de Wikileaks y tantos otros. El cifrado no es algo nuevo, y creo que todos lo entendemos bien… algo que no esté cifrado no significa que no sea seguro, significa que si alguien lo intercepta lo va a poder leer.

No veamos HTTPS como un ente tan extraño, se puede simplificar enormemente, pensemos en vez de HTTPS y páginas web en una carta, en que quiero hacer llegar una carta a mi amada, y para ello no tengo más opción que dársela a un amigo para que a su vez se la entregue a ella. A nadie se le escapa el problema, incluso si pusiésemos un lacre sellado, mi amigo podría abrirla y leer el contenido, y si el contenido de la carta no usa un código secreto que sólo entendiese ella y yo, pues mi amigo se enteraría de todo. En función de la relevancia de las letras que ponga en esa carta, usar un código secreto entre los dos puede ser simplemente un juego, a ser totalmente necesario.

En Internet, el amigo puede ser tu hermano conectado a tu misma red, puede ser un vecino que te roba WIFI, puede ser un desconocido conectado a la misma red pública (WIFI o cable), puede ser incluso si quisiese tu ISP, por supuesto el gobierno… y eso sin contar absolutamente cualquier punto por el que tus datos son transferidos hasta llegar al servidor final. Al margen de conspiraónicos y que los gobiernos y los ISP nos espíen, el principal problema no son ellos, son las redes en las que nos conectamos. Puede que no me haga gracia que, en caso de hacerlo, un gobierno quiera interceptar mis comunicaciones, pero a fin de cuentas tampoco tengo nada que considere “personal” para ellos, más me preocupa que desconocidos puedan conocer mis datos personales, cuentas y otros.

 Sí, el cifrado puede ser algo positivo, pero desde luego desde mi punto de vista indispensable cuando manejamos información personal o evidentemente confidencial, y HTTPS soluciona esto. Ya hablé en su día largo y tendido sobre ello en uno de mis artículos, y recientemente también en el de Let’s Encrypt, donde por encima explicaba todo esto, aunque en menor medida.

Inicialmente hablaba de legitimidad… HTTPS trata sobre cifrado de datos, no sobre legitimidad. Sí, el servidor se autentifica/identifica de cara al usuario, pero no para certificar que el contenido de la página es legítimo, ni siquiera que la propia web lo sea!! Lo que certifica en todo caso (de tener un certificado digital reconocido y excluyendo los certificados EV que veremos luego) es que dicho certificado fue emitido para dicho dominio específicamente, nada más. Dicho de otro modo, que el certificado que nos llegue a nuestro equipo, poder ser validado para estar seguros que quien nos los mandó es la web que tenemos delante.

Y en ese párrafo está toda la madre del cordero. Xataka dice que certifica que la web que tenemos delante es legítima… no es cierto, la web puede decir que es Paypal, la web puede ser un calco perfecto de cualquier página de un banco, e incluso podrían tener un dominio similar!! y por supuesto, podrían usar perfectamente un certificado digital (y usar HTTPS) validado. Evidentemente a mi modo de ver las cosas, no considero eso como una web legítima. Esto es algo que se está empezando a hacer de forma masiva, por la falsa creencia precisamente del usuario de creer que si ve el candado verde la web es fiable, y es un error de base. Sí, la comunicación con dicha web se hace de forma cifrada y ningún vecino nos intercepta la comunicación, pero los datos que enviamos llegan igualmente al servidor, y si esa web la hace una persona malintencionada, evidentemente tiene acceso a dichos datos, datos que nos acaba de robar por creer nosotros que por tener candadito verde la web era legítima de fiar.

Pero por supuesto, que son unas letras sin una buena imagen. Ni siquiera he tenido que invertir tiempo en hacer una prueba propia sobre esto, simplemente me ha bastado con  mirar en cualquiera de los servidores usados para los registros de transparencia de certificados (por ejemplo https://crt.sh), que registran los certificados emitidos por las diferentes agencias CA que los usan, y mirar los dominios para los cuales se registran. Yo he buscado por Paypal, que contengan los dominios “Paypal”, por ejemplo, y el primer certificado que he encontrado que contenía su nombre ha sido el que pongo ahora en la imagen:

Antes de terminar de escribir este artículo, habré reportado dicha web, con lo que es posible que si alguien intenta acceder Google SafeBrowser la esté ya indicando como página de Phising, pero ahora mismo esta totalmente operativa. Como podemos ver perfectamente, la web está protegida por HTTPS, con su candadito verde, su “Es seguro”, con una URL similar a alguna que pueda tener una página real de Paypal, y por supuesto su contenido un calco. Bien, este es un ejemplo sencillo, poco o nada tiene que ver con que esté bajo HTTPS y el certificado sea válido, el contenido puede ser totalmente fraudulento. Ni que decir tiene que posiblemente de meter ahí los datos, se los enviaríamos a una personal mal intencionada, pero muchos creerían que como la URL parece ser “buena”, y que pone “es seguro”, es de fiar. ERROR!!

 

Let’s Encrypt, el CA del que ya hemos hablado en otra ocasión, está siendo foco de grandes críticas por muchos (no hace falta ser un genio para saber que la mayoría de todas ellas por no decir todas vienen de los otros CA). Se les acusa de emitir certificados fraudulentos. Bien, primero tendríamos que matizar que es un certificado fraudulento, porque el ejemplo que he puesto anterior de Paypal, no es un certificado fraudulento, es un certificado totalmente legítimo, lo que no es legítimo y lo que es fraudulento es el contenido de la web mostrada, así como el uso evidentemente de la propiedad intelectual de Paypal y la suplantación de identidad. El certificado es legítimo siempre y cuando quien lo solicitó demostrase que era el dueño de dicho dominio, y recordemos que el dominio no es Paypal.com, el dominio comprado en este caso es “paypal-secure-info.gq”. Dado que las normativas sobre dominio permiten el registro de dicho dominio (lo cual es normal, no pueden vetar un dominio simplemente porque contenga una palabra que es marca comercial), sería totalmente injusto vetar la emisión de un certificado para dicho dominio. El problema no es el dominio, el problema no es el certificado… el problema es el uso que se haga de ello.

Algunos dicen que Let’s Encrypt en la “poca” vida que llevan, ya ha emitido muchísimos más certificados de este tipo que llaman “fraudulentos” que el resto de CA juntos. No lo dudo, es muy posible, pero por una razón sencilla… con los otros CA tienes que rascarte el bolsillo, 50-100€, pero te los emitirían igualmente por mucho que digan algunos que no permitirían certificados en dichos dominios, a fin de cuentas si el dominio está registrado correctamente, la emisión de un certificado estándar (de tipo DV, validación de Dominio) solo requiere para cumplir con las estrictas normas de seguridad la validación del propio dominio, nada más.

Ante esto Let’s Encrypt ya ha dicho más de una vez lo mismo. Ellos no son la policía ni el organismo competente para censurar el uso que puedan o no dar otros a las web, eso será cuestión de otros, y que por suerte herramientas como Google SafeBrowser o Internet SmartScreen, están para eso. Repito, lo mismo sucede con cualquier otro CA. De echo, para curarse en salud, Let’s Encrypt tan solo emite certificados DV.

Muy diferente es el caso cuando se desea un certificado EV, esos certificados que añaden antes de la URL el nombre de la compañía. Esos certificados emitidos por un CA requieren una serie de verificaciones y burocracia muy superior, que precisamente buscan eso, que se pueda tener cierta confianza de que la web visitada corresponde al contenido que tienen. En el caso de la web de paypal fraudulenta puesta arriba, les sería imposible lograr que pusiese delante de la URL lo que realmente veríamos en una web de Paypal:


El contenido es exactamente el mismo, y al margen de que la URL sean diferentes, evidentemente, en esta vemos el “sello” del certificado EV “Paypal, Inc. US”. La anterior sería imposible que lo lograse, incuso lograr algo similar sería casi imposible, a caso iban a crear una empresa llamada Paypal Secure bla bla bla y lograr todo lo que se requiere?? No, no lo lograría. Pero eso no invalida el certificado DV, ni tampoco le quita la gran importancia/necesidad que estos certificados (DV) tienen. De echo, como explicaba en el artículo de Let’s Encrypt, los certificados EV son muy caros, y la mayoría de entidades no los usan por no ser necesarios, mucho más importante que mirar el sello EV es mirar la URL, que ojo… puede engañar también (otro día hablaré de ello), pero pensar que si tomásemos una empresa no conocida podría tener legítimamente su sello EV y ser igualmente fraudulenta por el contenido que tiene.

 

Hace unos días apareció la noticia de que Google castigaba duramente a los certificados EV de Symantec (uno de los grandes CA) por detectar durante años la emisión de EVs de estos sin las necesarias y más estrictas condiciones. Recordar que un CA es fiable sólo en la medida que los navegadores Web y otros software se fían de ellos y añaden en sus productos los certificados raíces de estos. Dicho de otro modo, en cualquier momento tanto Google, Mozilla, Microsoft… podrían bloquear/anular los certificados raíces del CA que quisieran, dejando los miles o millones de certificados emitidos por ellas totalmente inservibles. Es por eso que son aquellos que crean el software que nos conecta los que deciden que certificados añadir y que normas y condiciones tienen que cumplir para permitirles estar dentro de su software, y si no lo cumplen o detectan irregularidades, no tienen problemas en eliminarlos o castigarlos del modo que estimen. Y sí, han caído empresas grandes cuyo principal volumen de ingresos era la emisión de certificados porque los navegadores los bloquearon por emitir certificados fraudulentos.

Vale, pero he dicho que los certificados fraudulentos no son tales… en que quedamos. Bueno, he dicho que el ejemplo anterior no es un certificado fraudulento, pero claro que se pueden emitir certificados fraudulento. El ejemplo más sencillo, si mañana me pongo en contacto con un CA y les pido que me emitan un certificado para google.es, y me lo mandan, es un certificado fraudulento, y no porque ya exista uno legítimo, eso es indiferente, es fraudulento porque el dominio google.es no es mío, e incluso un certificado DV se debe de emitir sólo si se puede verificar la propiedad de dicho dominio. Peor aun si hablamos de certificados OV o EV.

En el caso de Google y Symantec, según se ha dicho en la nota de prensa, Google detectó irregularidades en la emisión de certificados tipo EVs, y ha optado por medidas bastante serias, y durante un año irá invalidando dependiendo de las fechas de emisión de estos, los certificados EVs de Symantec (si leí bien). Y esto no es poca cosa, eso causa un daño enorme a Symantec. Es en una de esas pocas cosas que vemos el tremendo poder que puede tener una empresa que desarrolla una navegador Web para con otras multinacionales de gran peso e importancia.. bueno, google es un gigante, pero pensemos en Google como desarrollador de Chrome. Por supuesto Symantec les ha respondido, que han exagerado los datos, que les parece un “castigo” desmedido, que en el peor de los casos que Google lo lleve a cabo re-emitirá certificados nuevos para todos los afectos para que no se vean afectos… etc etc etc.

 

Conclusión

Por supuesto la credibilidad y fiabilidad de un sitio es o debería de ser muy importante, el problema es que no existe un sistema para ello. La mejor forma de legitimar una web es conociéndola, mirando siempre muy bien las URL, usar tecnologías como Google SafeBrowser (usada en Firefox o Chrome) o Smart-Screen usada en Internet Explorer. Tener siempre la seguridad, sobre todo cuando vamos a introducir cualquier dato sensible que la web que tenemos delante ES la web que dice ser, y no fiarnos de si usa HTTPS para eso o no. HTTPS nos asegura un cifrado, no la identidad que pueda parecer decir ya sea por el contenido o por la URL. Eso no invalida para nada la necesidad de HTTPS, puesto que incluso aunque una web sea fraudulenta, puestos a escoger, dentro de los males el menos malo sería que usase HTTPS, al menos tendremos la seguridad de que los datos sólo nos lo roba quien hizo la web fraudulenta, y no además otro que nos espíe la conexión por no usar HTTPS.

Con la aparición de Let’s Encrytp la web ha dado un buen giro, y donde antes nadie usaría certificados, ahora el uso se está expandiendo enormemente, ya sea un blog personal (ya, lo sé, no se lo tengo puesto al blog, en casa del herrero cuchillo de palo), ya sean empresas, tiendas online… y eso es bueno, con independencia de que algunos los quieran usar para otros fines.

Pero no nos equivoquemos, la culpa no la tienen esos desalmados, ellos simplemente se aprovechan como siempre del desconocimiento de los usuarios, las empresas de CA se han empeñado durante años a decir que los certificados son necesario para la confianza, para la fiabilidad… y muchas campañas se han hecho acerca de esto, así que el usuario normal ha tomado por válido ciertas cuestiones, como que si la web tiene un certificado seguro, la página es segura = fiable = de_confianza.

HTTPS sí, siempre que sea posible y el certificado sea válido, pero por favor… no dejéis nunca de revisar bien y mucho ante la duda la web que los use.

¿Son realmente necesarios los Antivirus? ¿Causan más mal que bien?

Share on Google+Share on FacebookTweet about this on Twitter

Buenas compañeros.

Es de estas veces que… digamos que estás haciendo alguna cosa sin demasiada importancia y sin necesidad de atención, mientras lees algunas publicaciones aquí o allí. Y de pronto me he topado con un artículo publicado por Robert O’Callahan, persona bien conocida (en el mundillo) y que sigo desde hace tiempo, con un gran talento como ingeniero de software, y un poco siempre controvertido. Robert O’Callahan ha sido Ingeniero de Mozilla durante muchos años, siendo una pieza fundamental de ellos, un gran programador, experto en seguridad y bueno… creerme, es cierto que siempre ha sido políticamente incorrecto, pero sabe de lo que habla.

El artículo no tenía desperdicio, animo a todos a leerlo: “ Disable Your Antivirus Software (Except Microsoft’s)“. Cuando cualquiera escribe sobre temas que conoce (o cree conocer), sus palabras pueden ser más o menos escuchadas y tenidas en cuenta por un grupo de seguidores o lectores, pero cuando personas de cierto y conocidas por su trabajo hacen comentarios tan tajantes, se arma un revuelo… y no es para menos.

Para quien no quiera leerse el artículo o vaya regular en Ingles, se lo resumo de forma sencilla:

En primer lugar, O’Callahan aprovecha para recordar que al no estar de momento en Mozilla (espero sinceramente que vuelva), tiene “libertad” en poder expresarse de forma abierta ya que a fin de cuenta no representa ni la opinión ni palabras de Mozilla y está desvinculado de ellos. Esto nos dice que muy posiblemente Mozilla piensa igual en general, sólo que como es normal no puede hacer afirmaciones tales por las repercusiones que tiene, como veremos luego.

A continuación, hace un pequeño resumen exponiendo que los Antivirus, lejos de hacer nuestros sistemas más seguros, por lo general lo que logran es hacerlo más inseguros, crearle agujeros de seguridad, son invasivos, matan el rendimiento y generalmente por raro que parezca no cumplen las normativas básicas de seguridad de software, con un código mal optimizado y problemático. Y desde el punto de vista de ellos como desarrolladores de software, específicamente navegadores Webs, afirma también que una parte muy importante del tiempo dedicado por los desarrolladores es precisamente tener que lidiar con los fallos de seguridad y otros de los propios antivirus, por supuesto da ejemplos de ello.

Muchos han visto esto como un guiño a Microsoft, por Windows Defender, pero en lo personal no creo que sea así, y en parte lo explica. La gran diferencia entre Windows Defender (En Windows) y cualquier otro AV como pueda ser Symantec, Avira, Avast… (pongo 3, pero en general cualquiera), es que Defender en primer lugar está integrado en el sistema y mucho más optimizado, en segundo lugar Microsoft por política somete a todo su software a estrictos controles de seguridad y estándares que deben de seguir, cosa que la mayoría de empresas de software no hacen, y en tercer lugar porque para lo que sirve un AV, Defender cumple con lo que necesita cualquiera. Dicho de otro modo… Windows ya tiene su propio AV/AntiMalware que funciona bien, para que usar software de terceros que puede provocar todo tipo de problemas.

Bien… cualquier que me conozca, sabrá lo que pienso al respecto: Estoy totalmente de acuerdo con sus palabras.

Es complicado hacer este tipo de afirmaciones y más para ellos, como bien dice. los desarrolladores de Software tienen que trabajar a fin de cuenta codo con codo con los desarrolladores de AV, y es evidente por qué… creéis que a cualquier desarrollador de software le gustaría que un AV salte una advertencia de seguridad o que hagan un comunicado diciendo que el software de X no es seguro?? Es indiferente si dicha afirmación o dicha alarma es cierta o no, el daño lo hacen, porque son compañías que tienen mucho peso. Yo puedo hacer los comentarios que quiera, puedo dar mi opinión y ninguna empresa de AV puede “influenciarme” de ningún modo, pero la mayoría no puede hacer eso.

Las empresas de AV se aprovechan de la historia y del desconocimiento de los usuarios, intentando venderte no su software, sino la idea de que si no usas un AV, tu equipo está desprotegido, y que el suyo es el mejor. Y esto es falso… al menos de un punto de vista global, y he hablado de ello muchas otras veces. Los AV tienen su utilidad, pero es limitada en el mejor de los casos, y por lo general causan un mal mucho peor que la posibilidad de coger algún tipo de malware. El desconocimiento es tal, que por paradójico que sea, la mayoría deshabilita las actualizaciones de Windows para mantener su equipo en buena forma y seguridad, mientras que usan AV para “protegerlo”, cuando es exactamente al contrario!! Lo más importante para la lucha contra CUALQUIER tipo de malware, es TENER ACTUALIZADO EL SOFTWARE empezando evidentemente por el OS.

Pues han pasado unos días desde que el señor O’Callahan escribiese dicho artículo, y al margen de lo polémico que ha sido muchas veces (que no es sinónimo de no tener razón), esta vez se le ha unido incluso algunos Ingenieros de Google, que aunque han sido algo más suaves, han venido a darle la razón, aludiendo que al margen de las estadísticas y otros que sacan las propias empresas de AV, ellos tienen sus propios datos que muestran que tales afirmaciones son ciertas, y que duela a quien duela, Defender es digamos mucho menos problemático que el resto de los AV.

No es normal que expertos de cierto calibre hagan afirmaciones tales: “Deshabilita/Desinstala tu Antivirus”, pero me alegra que por fin algunas voces se atrevan a decirlo. Como queda dicho, hay demasiados intereses económicos, y luchar contra empresas de importante tamaño te puede pasar factura, sobre todo si tu producto puede verse afectado por el producto de otro.

 

Mi opinión personal es bien conocida para todos mis círculos, y alguna vez la he expresado aquí. Cualquier tipo de Malware es introducido en el equipo o por interacción directa del usuario o por algún agujero de seguridad. Lo primero se evita con una educación mínima de como usar Internet y otros, a fin de cuenta repito entra porque el usuario instala o ejecuta algo que no debía. Lo segundo se evita actualizando el Software, sobre todo cualquier programa de cara a Internet, como navegadores Web, Sistema operativo y otros. Y no, en ninguna de esas dos luchas contra el malware aparece un AV. Sí, en algunos momentos específicos puede ser bueno poder disponer de un AV para analizar un archivo del cual no estamos seguro o dudamos… pero para eso tenemos una herramienta mejor a todo ello:

http://virustotal.com/

Tengo que decir que siempre que tengo que recomendar configurar un equipo, software a instalar… o incluso a amigos/familiares que soy quien se encarga de ello, el AV lo tengo vetado. Por lo general, es cierto que les dejo habilitado Defender, aunque en mi círculo más cercano, también lo tengo deshabilitado. Esto no es una recomendación ni lo deja de ser, porque al final como dice también O’Callahan, si recomiendas algo y alguien termina con problemas por ello, se contará siempre la negativa y no la positiva, sólo digo que a todo en lo que tengo o pueda tener mano, los AV de terceros están totalmente vetados, y en mis círculos más cercanos, todos.

Por supuesto… cada cual es libre de creer, hacer 🙂

Google I/O 2016

Share on Google+Share on FacebookTweet about this on Twitter

De nuevo, otro año más, volvemos a la carga, y de nuevo antes de las vacaciones de verano. En esta ocasión parece ser que que el Keynote será retransmitido en 360º, así que ya tenemos la primera novedad de todas. Está claro que este año se va a seguir apostando por la realidad virtual, y casi con toda seguridad veamos un nuevo CardBoard (o la evolución de este). Pero… que más??

Está claro que se van a hablar de muchas cosas, pero creo que al final podemos resumir las novedades en dos grupos:

El primero y quizás más importante son aquellas que van enfocadas directamente a los productos actuales y que afectan o pueden afectar desde hoy. Recordemos el gran éxito que fue Google Photos y sus novedades el año pasado.

El segundo son productos igualmente interesantes o servicios que podremos tener más cerca. Quizás un nuevo Cardboard?? Quizás unas nuevas Google Glass?? Un ChromeCast?? o mejor aun, alguna novedad que ahora mismo no podemos siquiera hacernos idea ¿?

Bien, comienza la cuenta atrás, en unas horas lo sabremos. Lo mejor de todo es que por suerte o desgracia, y aunque suene mal decirlo por el poder que ostenta Google en ello, de lo que salga esta tarde del Keynote tendrá una repercusión directa y enorme en la gran mayoría, a fin de cuenta, quien es capaz de decir a día de hoy que no usa algún servicio de Google 😉

 

Router Mitrastar HGW-2501GN-R2: Shell e Ingeniería inversa (para crear firmwares modificadas, por ejemplo) (Actualizado)

Share on Google+Share on FacebookTweet about this on Twitter

mitrastar
Introducción

La historia es sencilla. Aunque en la medida de lo posible siempre uso mis propios dispositivos, me gusta igualmente exprimir cualquier otro chisme que tenga por casa. Unos fuman… yo cacharreo.

En este caso, este fue el router que me entregó el ISP para mi conexión de Fibra, Mitrastar HGW-2501GN-R2. Duró conectado a la línea el tiempo de irse el instalador, pero lo saqué recientemente del “trastero” al ver por los foros de soporte oficiales (y no oficiales) que estaba dando un sin fin de problemas a los usuarios. Como siempre he dicho, opinar podemos hacerlo todos, pero si queremos dar soluciones que sean lo más acertadas posibles, es mejor comprobar las cosas por uno mismo y poder estudiarlas como dios manda. Así que le saqué el polvo y me puse a desentrañar sus más y sus menos.

Un dispositivo es bueno o malo sencillamente a razón de dos cuestiones sencillas, y es lo bueno o malo que sea su hardware y su software. Si el hardware es “malo” las ataduras de manos siempre son mucho peores, porque salvo modificaciones directamente en el hardware poco podemos hacer. Un hardware bueno tampoco hace del dispositivo algo bueno, es fundamental el Software, y sobre el software podemos decir lo mismo.

En el caso del Mitrastar, tenemos un poco de todo. Respecto al hardware no es ni mucho menos de lo peor que podemos encontrarnos en un router como muchos puedan pensar, pero eso no quiere decir que no se hubiese podido mejorar sustancial, sobre todo lo referente a su interfaz wifi. Eso no podemos cambiarlo, tenemos que aguantarnos con lo que hay. No he conectado aun el router por puerto de serie ni lo he sacado de su carcasa, así que los siguientes datos pueden no ser exactos del todo. Por lo que podemos saber el hardware se compone de una arquitectura MIPS:

CPU1: Ralink RT63368F (En Placa)/RT63365 (En Software)
Switch: Realtek RTL8368MB
Wl0: Ralink RT5392
RAM: 128MB
Flash: 64MB

El Switch debe de contar con unos 7 puertos diferentes, apoyado principalmente por el SOC RT63365. El adaptador inalámbrico dista mucho de ser una maravilla, nos encontramos ante un disposotivo 802.11n de dos streams unibanda. Por otro lado contamos con una cantidad más que suficiente de RAM y Flash para todo, lo cual siempre se agradece el no ir siempre bajo mínimos.

El principal problema que se ha tenido es que el software del router (la firmware) ha estado lejos de ser aceptable, salvaguardando por supuesto las propias limitaciones del hardware. Entre las quejas más frecuentes han sido los enormes problemas de batería causados por el router a dispositivos portátiles, la interfaz web de configuración con constantes problemas… En un mundo ideal, como se trata de Software, en el peor de los casos podríamos decir: “Pues si no quieren hacer ellos su trabajo, al menos voy a ver si puedo yo mejorar o corregir alguno de esos problemas de software”. Pero nunca suele ser tan sencillo, las firmwares y los sistemas se protegen precisamente para impedir cualquier tipo de modificaciones al software, siguen sin entender que cuanto más abierto sea un software más probabilidad hay que funcione mejor y con menos fallos/problemas.

 

Acceso Básico

Manos a la obra, partamos desde cero. Instalamos el router, lo tenemos todo funcionando… ¿ahora que?. Aquí entra en juego el primer escollo, y la culpa de esto la tiene principalmente los ISP, nada que ver con los fabricantes del hardware o el software que se instala (por lo general). Los dispositivos que nos entregan actualmente (No solo Movistar) vienen precargados con una configuración básica por defecto con los ajustes básicos de la compaña, como puedan ser los SSID, ajustes de WAN… ahora debido a los servicios avanzados como VoIP o IPTV suele ser necesario además de todo esto ajustes adicionales específicos para cada cliente, así que el router está preparado para conectar a los servidores de ellos después de un reset o cada X tiempo para reconfigurarse con los datos de la línea del cliente. Esto es perfecto porque evita configuraciones manuales uno a uno.

Lo primero que quiero o puede querer cualquiera es realizar pequeños ajustes a nuestro router, ya sea abrir un puerto, configurar una IP diferente… eso lo hacemos como toda la vida de dios, lo más básico y sencillo: La interfaz web del Router. El problema aparece porque la mayoría de los ISP se preocupan y hacen TODO LO POSIBLE para que el usuario, el cliente, tenga acceso a cuantas menos funciones posible del router mejor. Esto se hace por lo general con la creación de usuarios con permisos mucho más restrictivos a los usuarios tipo admin/root con acceso completo. Estos usuarios que crean tienen al final acceso para modificar 3 parámetros y medio y no poder consultar muchas otras configuraciones que pueden ser de interés, con lo que nos limita enormemente, incluso a usuarios con un perfil básico. Esto es algo que la mayoría no toma en cuenta cuando contrata un ISP u otro, pero para mí es esencial y marca mucho el tipo de compañía que tienes delante. Muchos de los amigos que me leen saben mi opinión sobre Apple, y se resumen sencillamente en que no permito que una compañía me diga que puedo hacer o no hacer con mi hardware.

Dependiendo del dispositivo que tengamos instalado y dependiendo del ISP, podremos acceder de mejor modo o no la configuración de nuestro router. En el caso concreto del Mitrastar, tengo que decir sinceramente que chapó por Movistar, ha hecho lo que tenía que haber echo hace tiempo y hacer TODOS. El Mitrastar, como viene siendo ya costumbre desde hace tiempo en los dispositivos de Movistar tiene dos interfaces web, una sencilla para usuarios nóveles que quieren cambiar 3 cosas (llamada Movistar Home Station, aka mhs, y una avanzada. El Mitrastar posee 3 usuarios (en realidad son 4, pero el usuario samba lo obviamos), cada uno con permisos diferentes enfocados a necesidades diferentes:

-“admin”: La contraseña de este usuario podemos encontrarla debajo del router en una pegatina. Este usuario y contraseña nos da acceso a las dos interfaces del router. Es el acceso normal a la interfaz mhs, y si accedemos a la avanzada a través de mhs (o a través de la dirección http://IP/cgi-bin/main.html) nos encontraremos con limitaciones en cuanto que podemos modificar. Esta cuenta por otro lado carece de acceso por terminal (SSH/Telnet…)

-“1234”: La contraseña coincide con la contraseña anterior, y en este caso sería lo más similar a un usuario root. Tiene acceso completo a las opciones de configuración de la interfaz, y es la cuenta que usa el portal Alejandra igualmente para configurar de forma remota nuestros dispositivos (si los tenemos asociados al portal).

-“supervisor”: La contraseña en este caso es siempre la misma, zyad1234, y posee permisos similares al usuario 1234, con el añadido de que con este usuario se tiene acceso por la interfaz web a poder modificar los permisos de los otros usuarios y de sus contraseñas igualmente.

mhs
web

Ahora entenderéis porqué digo que en este caso chapó por Movistar. Cualquiera puede tener acceso completo (al menos por web) al Mitrastar, sin hacer cosas extrañas, sin tener que pelearse, sin acudir a… dicho de otro modo, los técnicos de Movistar no tienen un mejor acceso que nosotros. Gracias a estos usuarios podremos no sólo consultar la mayoría de todas las configuraciones del router, sino que también ajustarlas a nuestro antojo.

Por otro lado, lo primero que se le ocurre a cualquiera es ver como son los archivos de configuración (backup) del router, así que como primer paso para entender un poco todo lo que cualquiera haría sería descargar dicho archivo desde mantenimiento, quizás sea legible o haya algo o algún ajuste que pueda ser de interés. El archivo de configuración del Mitrastar, por suerte, no está cifrado y parece ser un xml totalmente legible, pero que algunas opciones curiosamente las enmascara, todas aquellas donde hay contraseñas. Por qué es esto interesante?? Bueno, yo he dicho que la contraseña de admin y 1234 es la misma, pero a veces no es tan sencillo como prueba/error, o mejor dicho… a veces es más sencillo no tener que estar probando… pero como vemos el archivo de configuración no permite ver estos datos. En cualquier caso, vemos que estos campos llamados “encrypted” comienzan todos por: “41455300”, casualidad que 41 45 53 = AES, lo cual nos daría a pensar que el resto es posible que sea el texto codificado en AES.

 

Acceso Limitado por Terminal

El 99% de las veces nos sobra la interfaz web, pero que pasa cuando nos gustaría poder modifica o consultar cualquier cosilla que no esté presente o tengamos acceso por la interfaz web?? A fin de cuenta presuponemos que nuestro router estará corriendo algún tipo de Linux debajo de él. Para eso es indispensable acceso mediante SSH o Telnet. El problema es que como aplican la mayoría de fabricantes, para negarnos la posibilidad de toquetear las tripas, lo que nos dan es acceso es a una shell limitada… muy limitada. Así, en el caso del Mitrastar si intentamos acceder mediante supervisor o 1234, nos encontramos ante un panorama… “triste”:

ssh

Así pues podemos acceder con las credenciales por defecto, pero los únicos comandos que nos muestra la interfaz como válidos son: ?, exit, save, sys, restoredefault, lan, igmp, wlan, nat. La mayoría de todos ellos tienen subcategorías. No hay nada interesante a priori que podamos hacer desde la shell que no podamos hacer desde la interfaz web. Dos comandos “al azar” muestran dos resultados interesante: mtd y sh, ninguno de los dos listados en los comandos disponibles. El primero nos devuelve que el comando está prohibido, el segundo directamente que introduzcamos una contraseña… ¿quizás existe una contraseña para poder acceder a la shell que hay debajo? Por descontado ninguna de las contraseñas que disponemos es aceptada como válida.

Algo relativamente común a las shell limitadas es que permiten realizar copias de la configuración. A priori podríamos pensar que esos “dump” son iguales que los que podemos obtener desde la interfaz web, pero… que pasa si introducimos por shell limitada “sys dumpcfg”?? Sí, nos devuelve en la consola exactamente el archivo de configuración que pudimos descargar con anterioridad… pero con una salvedad, en esta ocasión los campos de contraseña están en texto plano. Bingo!!

username=”supervisor” web_passwd=”zyad1234″ console_passwd=”zyad1234″

La contraseña es la misma, pero en cambio en el archivo de configuración cifrado vemos que el “resultado” es diferente. Asumimos que además de poder estar cifrado con AES usa algún tipo de SALT, y no sólo una key cualquiera. Aun así esto tampoco nos abre la puerta a mucho más, esta contraseña es de hace mucho conocida y compartida en muchos productos.

 

Acceso a la Shell que hay debajo

Lo que nos interesa es acceder detrás de la shell limitada a la que tenemos acceso. Parece que para esto existe directamente un medio para hacerlo, a través del comando “sh” desde la shell limitada, pero esto nos solicita una contraseña que es totalmente desconocida para nosotros. Aquí empieza realmente el trabajo duro, ingeniárselas de algún modo para poder acceder debajo, aunque sólo sea una vez, y poder echar un vistazo desde una shell completa. No voy a detallar, por cuestiones de seguridad, como logré ese primer acceso, pero sí de que se trata.

Presuponemos que tenemos Linux debajo, con lo que realmente lo primero que desearíamos sería echarle un ojo al archivo /etc/passwd y/o /etc/shadow. Estos dos archivos, en linux, son los que contienen las credenciales de los usuarios y sus contraseñas (cifradas claro está). Pero además contienen la shell que será ejecutada a cada usuario. Es posible que el router posea otro usuario/contraseña que desconocemos o a saber…

Pongamos que gracias a la interfaz web logramos ejecutar de algún modo algún comando dentro de la shell y sacar los datos por el navegador. “cat /etc/shadow” cat /etc/passwd” sería sin duda alguna las primeras pruebas, y pongamos que en un momento dado la interfaz web nos devuelve lo deseado, nada para shadow, y para passwd:

1234:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/cmdsh
admin:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/sh
supervisor:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/cmdsh
samba:$1$$xxxxxxxxxxxxxxxxxxxx:500:500:Linux User,,,:/home/samba:/bin/sh

Bingo!! (de nuevo). Parece ser que además de existir un cuarto usuario, samba, el usuario 1234 y el usuario supervisor (que son los dos únicos que tienen acceso por shell) ejecutan una shell extraña llamada “cmdsh”. Sea como sea, si logramos ejecutar con suerte cat, podríamos igualmente intentar sobrescribir el contenido del archivo, igual no existe una protección contra escritura… como dicen, probar no cuesta nada… usando incluso de nuevo cat, se puede enviar el mismo archivo pero modificando la shell a ejecutar, en vez de /bin/cmdsh, /bin/sh. Lanzamos la petición, volvemos a lanzar otra para ver el contenido y… se ha modificado!!. Ejecutemos de nuevo una sesión Telnet/SSH, usuario 1234 (es al usuario que le cambie la Shell), su contraseña… y efectivamente no más shell limitada:

login as: 1234
1234@192.168.1.1’s password:
# ls
bin      boaroot  dev      etc      lib      linuxrc  proc     sbin     sys      tmp      userfs   usr      var
# uname -a
Linux MitraStar 2.6.36 #1 SMP Thu Aug 13 14:04:19 CST 2015 mips unknown
#

 Llegados a este punto ya lo tendríamos todo?? Sí y no. Esto habría que repetirlo siempre, porque si reiniciásemos el router veríamos que el cambio que habíamos realizado al archivo passwd se perdería, teniendo que repetir todo el proceso constantemente. Aun así al menos ya habríamos logrado acceder a la Shell de debajo con plenos permisos administrativos. ¿Podemos mejorar esto? Por supuesto.

Lo primero que viene a la cabeza es: Bien, puedo acceder gracias un exploit, pero parece ser que la shell cmdsh tenía un comando “sh” que solicitaba una contraseña para acceder, y no hay que ser muy listo que lo que permite es acceder precisamente a una shell completa. ¿Donde puede estar esta contraseña? Personalmente el primer lugar donde miraría, teniendo en cuenta que no parece existir otros usuarios en el archivo /etc/passwd, es en el binario de la propia shell, o sino este sabrá de donde obtenerla, dado que es esta shell la que lo solicita. Ya sabemos donde está, así que sólo tenemos que extraerlo. Esto puede hacerse de mil y una forma, dependiendo de las herramientas que tengamos disponibles claro está en la firmware del router:

-ssh/sftp/ftp/scp
-curl/wget
-netcat/nc
-base64
-usb
-…

Cualquier sistema nos vale para enviar donde queramos el archivo en cuestión y poder manipularlo en condiciones, la elección de un sistema u otro dependerá de las utilidades que tenga la firmware y de lo sencillo o no que nos resulte a nosotros mover los archivos. Una vez tengamos el archivo, tan solo tendríamos que decompilarlo y echar un vistazo rápido. Vamos a lo sencillo, si cuando introducimos a través de sh una contraseña cualquiera recibimos: “Password incorrect !” Podemos empezar buscando por ahí, o mirar directamente las posibles funciones… eso nos lleva al siguiente trozo de código:

diss

Curiosamente, justo unas líneas de ahí encontramos una extraña cadena alfanumérica. Bueno, además de que el código en ensamblador es bastante legible, lo que está claro es que compara un string (lo que introducimos por teclado) con el string “c93vu02jp4z04“. Si la comparación es incorrecta, vemos que salta a la posición 0x00402408 (=contraseña incorrecta), mientras que salta a otra posición en caso de que la comparación sea acertada. Dicho y hecho, tan solo tenemos que verificar que ese string es realmente la contraseña para acceder a la shell completa desde la shell limitada. Y no hace falta decir que efectivamente esa es la contraseña de acceso a la Shell.

Llegados a este punto lo tenemos todo, hemos podido acceder gracias a un exploit, hemos podido extraer la contraseña que nos da acceso a la shell completa, con lo que podemos ya hacer con nuestro router lo que deseemos… ¡No tan rápido! ¿Seguro que ya tenemos total libertad?.

 

Acceso (y modificación) a la “nvram” – Autentificarse

Como vimos en la parte del exploit, y si empezamos a jugar con la shell interna, antes o después nos topamos con un problema bastante importante. Sí, podemos usar todas las utilidades de nuestro router, podemos añadir reglas a iptables, ver el estado de todo, controlarlo todo!! ¿Pero como podemos hacer para que los cambios que hagamos sean persistentes?

Vimos que si intentábamos modificar el archivo passwd este volvía de nuevo a su “ser” al reiniciar. Esto nos dice que al menos la raiz de la firmware está protegida contra escritura de algún modo, y de echo no hay que ser demasiado imaginativo para ir entendiendo que el sistema de archivo del router usa SquashFS, un sistema de archivos de sólo lectura que se monta en cada inicio. Ademeás, si miramos realmente la ubicación de la carpeta /etc tenemos esto:

# ls -la /etc
lrwxrwxrwx    1 1234     root            8 Aug 13  2015 etc -> /tmp/etc

La carpeta /etc desde la cual accedemos a /etc/passwd ni siquiera se encuentra en el sistema de archivos SquashFS, sino que el bootloader/kernel genera el archivo de algún modo en cada inicio, por eso pudimos modificarlo con el exploit entre otras cosas, está fuera de la “prisión” de SquashFS. Se genera en cada inicio, con lo que nuestros cambios se pierden. Pero sabemos que todo no es tan negro, porque en realidad debe de existir una zona o partición donde se puedan inscribir datos y estos sean persistente, o algún sistema para poder hacerlo, ya que a fin de cuenta podemos configurar el router a través de la interfaz web, y los datos son persistentes a cada reinicio. Si cambiamos por ejemplo la contraseña del usuario 1234 dicho archivo al iniciar será diferente al original y reflejará el cambio que hicimos por la interfaz Web. Quizás no podamos modificar el sistema de archivo raiz (lo haremos, pero más adelante), pero cuanto menos en teoría deberíamos de ser capaces de realizar cualquier cambio persistente que permita la interfaz web, y eso como mínimo, porque es de suponer que esté donde esté ese “espacio” contendrá quizás otros datos de interés.

Así es realmente como funcionan la mayoría de dispositivos. Los routers suelen tener una zona llamada nvram (RAM no volatil), que contiene parámetros que pueden ser leídos y almacenados con independencia del sistema de archivos. Esto es necesario para poder realizar configuraciones de cualquier tipo, pero incluso el propio router necesita este “espacio” para poder funcionar y configurarse a sí mismo. En muchos dispositivos es bien conocida la herramienta “nvram”, pero si lo intentamos veremos que aquí al menos no disponemos de una herramienta similar. Así que queda hacer un poco de detective y ver si disponemos de alguna utilidad que nos brinde algo similar.

Como podemos acceder a la shell podemos recorrer rápidamente los directorios donde sabemos que es más que posible que se encuentren: /bin, /sbin, /usr/bin… la mayoría de todas las utilidades podemos conocerlas los amantes de linux y muchas otras deducirlas. Otras en cambio podemos ir directamente probando a ver que pasa. Si no damos con la “tecla”, tenemos otro sistema sencillo para hacernos una idea… si la interfaz web cambia los ajustes, la interfaz web debe de saber o tener idea de como realizar esto. Antes o después llegaremos a la conclusión de que hay ciertos binarios que parecen ser los encargados de manejar todo esto, aquellos que empiezan por “tc” que es el acrónimo de TrendChip. Si nos movemos por las carpetas de la interfaz web (/boaroot) veríamos también rápidamente las referencias constantes a tcwebapi, y mira tu por donde tenemos un binario llamado: “tcapi”. Si lo invocamos:

# tcapi
set unset get show commit save read readAll staticGet

 Parece ser que hemos dado con la interfaz que interactúa con la nvram. Con un poco de paciencia y de estudio aprendemos a usar esta interfaz. tcapi funciona de un modo similar a nvram, con show podemos mostrar lo que deseemos (no existe un show all), pero tenemos que especificar que nodo queremos visualizar. Los nodos son precisamente las etiquetas xml que están dentro de nuestros archivos de configuración. Si miramos nuestro archivo de configuración veremos por ejemplo uno de los primeros nodos, “Wan”, así que “tcapi show Wan” nos devuelve efectivamente todo lo almacenado en ese nodo. Podemos pensar que esto no tiene demasiada utilidad ya que a fin de cuenta tenemos el archivo de configuración, pero no hay que ser muy listo para presuponer que el archivo de configuración es sólo una parte de todo. De echo podemos almacenar los valores que queramos en la nvram existan o no existan en el arcivo de configuración, o modificar cualquier otro.

Si alguien ha usado anteriormente nvram (la utilidad) sabrá que para que los cambios se apliquen hace falta realizar un “commit” y seguido de un “save” si se quiere que los cambios se guarden (aplicar no significa guardar, y viceversa). Aquí tenemos lo mismo. “tcapi save” guarda todos los cambios realizados en la nvram, mientras que “tcapi commig nodo” aplica los cambios efectuados al nodo citado. Cuidado!! Estamos modificando la nvram, si guardamos los cambios y estos han sido incorrectos podemos encontrarnos en que sea necesario resetear el router para que vuelva a sus ajustes por defecto.

Quien llegue a este punto se habrá dado cuenta que, de echo, aunque puede usar show, no puede realizar un save y peor aun, un set, devolverá lo mismo que sucedía cuando intentábamos teclear mtd. El acceso por alguna razón a ciertos comandos, incluso teniendo permisos administrativos y a la shell completos, siguen estando restringidos, hace falta algo más para desbloquear esto. Aquí tendríamos de nuevo que empezar a investigar donde buscar y encontrar esto. Podríamos empezar por cmdsh y encontraríamos referencias a un supuesto archivo llamado “/tmp/Authentication”. Antes o después (grep es un gran amigo), daríamos con el binario /usr/bin/syscmd. Si decompilamos y echamos un ojo llegaríamos pronto a una sección bastante interesante:

auth

Vemos demasiada información, pero todo de gran utilidad. Por un lado vemos que aparece de nuevo el archivo nombrado, pero esta vez precedido de un comando completo, y además curiosamente justo encima vemos un “Correct Key imput. Auth…”. Eso ya nos está diciendo que el sistema parece importarle más que el usuario esté “autentificado” ante ciertos comandos que cualquier otra cosa, y que parece que lo verifica seteando el archivo /tmp/Authentification con authenticated. Podríamos hacer la prueba: “echo authenticated > /tmp/Authentication” y veríamos que funcionan mágicamente a partir de este momento tcapi set/save y otros

Antes de irnos a otro lado, podemos ver igualmente en el trozo desensamblado de nuevo la contraseña de acceso a la Shell, y un “EncryptKey” y un “Account_Common”. Quien haya estado ya jugando con la nvram sabrá que en esta se separan los nodos de otros subnodos con guiones, así que por curiosidad si miramos la información del nodo “Account_Common” con tcapi:

# /userfs/bin/tcapi show Account_Common
EncryptKey=MSTC

El resultado es un string: MSTC, que según aparece en la nvram es un “EncryptKey”. Demasiado cerca del código que hace estar autentificado para no tener nada que ver. Si vemos desde la shell que podemos hacer con syscmd, vemos que existe curiosamente un comando que es authKey, y que efectivamente:

# syscmd authKey
Error!
# syscmd authKey MSTC
Correct key input. Authentication done.

Así que en realidad el proceso “real” implicaría autentificarse a través de syscmd con la EncryptKey almacenada en la nvram, MSTC, y eso a su vez produce que el sistema setee el archivo anteriormentes citado. Así que en realidad podríamos realizar la autentificación de cualquiera de las dos maneras: por lo “legal” y a lo “bruto”. Ahora sí, después de esto, podríamos usar algunos de los comandos más particulares (y también peligrosos), como puedan ser: sys memwl, sys memww, sys erase, sys romd, tcapi set, tcapi save…

La nvram permite acceder a todos los parámetros almacenados en nuestra configuración, y además acceder a otros parámetros que podrían ser interesantes, pero eso para otro día. Veamos mejor que más podemos hacer… podemos modificar la nvram, podemos ejecutar cualquier herramienta que tengamos dentro del router, ahora iremos un pasito más, esta vez como poder “modificar” lo que nos queda, el sistema de archivos, e incluso poder instalar/actualizar componentes en ella.

 

Ejecución de comandos desde el archivo de configuración (Nuevo)

Por azares de la vida, me topé días después con que resultaba relativamente sencillo realizar ejecución de código directamente desde el archivo de configuración del router, que no deja de ser gran parte de la nvram. El secreto reside en el nodo “Autoexec”, que si miramos en nuestro archivo tan sólo existe como cierre.

El cfg_manager, por suerte para nosotros, parsea el cfg en cada inicio para cargarlo a la nvram. Al llegar a dicho nodo, si no está vacío, pasa TODO lo que hay en él (sin el nombre de la entrada, sólo los valores de estas) a un archivo llamado autoexec.sh en /etc/, le da permisos de ejecución y acto seguido lo ejecuta. Dicho de otro modo, podemos añadir todo el código que queramos ahí, que será ejecutado al inicio en el Router. Evidentemente de saber esto anteriormente, el proceso de acceso inicial al router hubiese sido mucho más sencillo.

El potencial de esto ya no está realmente en los expertos que sepan modificar la firmware o entrar y salir del Router de forma sencilla, sino que el usuario novel puede de forma sencilla gracias a esto solucionar problemas que pueda tener en el router, o aplica ajustes concretos especiales.

El formato que siguen estas instrucciones es similar al de otros nodos:

<Autoexec>     <Entry
arp_fix=”sysctl -w net.ipv4.neigh.br0.mcast_solicit=0″
dhcp_fix=”echo ‘* * * * * ebtables -D FORWARD -p ipv4 –ip-proto 17 –ip-source-port 67:68 -j DROP’ &gt; /etc/admin; crond -c /etc/” />
</Autoexec>

Ese por ejemplo sería el bloque modificado para realizar dos fixs a la firmware B21, uno el problema de la batería y otro el problema que posee el router que bloquea todo el tráfico DHCP que no sea el suyo propio. Es sólo un ejemplo sencillo, en realidad podríamos realizar casi cualquier cosa. Como vemos la entrada en sí no importa su nombre, es su contenido el que será pasado al archivo autoexec.sh. Tan sólo hay que añadir el bloque que queramos, guardar, cargar la configuración y solucionado.

 

 

Modificando el sistema de archivos raíz

El router usa como hemos dicho SquashFS para montar su raíz. El problema que esto nos origina es que no podemos realizar cambios en él directamente. Para poder hacer esto, en principio, lo que se necesita es modificar directamente la imagen SquashFS con los cambios que deseemos y volver a cargarla. En un sistema más potente o con otras herramientas podríamos incluso pensar hacer el proceso directamente bajo la misma shell, pero aquí estamos limitado tanto en espacio, herramientas y memoria del router, con lo que esta opción no es muy viable. La opción que nos queda es realizar la modificación fuera del router, y volver a escribir el sistema de archivos de vuelta al router.La teoría en realidad es sencilla, la práctica es algo más complicada porque hay que ver como podemos hacer esto.

A priori se me ocurren dos formas. Una, extrayendo en la partición que se encuentre (en caso de ser así) el sistema de archivos, modificarlo, copiarlo de nuevo dentro y volver a copiarlo a su partición con dd/mtd (lo cual puede resultar bastante peligroso si hacemos algo mal y tampoco tengo claro que pueda realizarse sin hacerlo desde el bootloader), o aprovecharnos del propio sistema de actualización de firmware del router, es mucho más seguro pero implica conocer bastante bien como es la imagen de actualización, para poder no solo modificarla, sino también hacer que el router la acepte. Yo he tomado la segunda opción, no quiero tener que llamar a Movistar para decirles que misteriosamente el Mitrastar ha muerto.

Dicho esto, se abren por desgracia una serie de puntos que pueden ser “largos”, pero necesarios. Si queremos modificar la firmware, lo primero que necesitamos es precisamente al firmware, el binario de actualización, y dado que las actualizaciones se realizan por telecarga puede no ser tan sencillo tener una copia de ella, a menos que conozcamos a algún amigo de un amigo que buenamente nos la suministre. Por suerte… hoy tenemos respuestas y medios para todos.

 

Estructura interna de las particiones de memoria

Antes que nada hay que “estudiar” como está organizada la memoria flash del router, hay que ver realmente que particiones hay:

# mount
/dev/mtdblock3 on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00020000 “bootloader”
mtd1: 00020000 00020000 “romfile”
mtd2: 0014e7e3 00020000 “Kernel_main”
mtd3: 01090000 00020000 “Rootfs_main”
mtd4: 00006292 00020000 “Defcfg_main”
mtd5: 01d40000 00020000 “Tclinux_main”
mtd6: 0014e7e3 00020000 “kernel”
mtd7: 010b0000 00020000 “rootfs”
mtd8: 00006292 00020000 “defcfg”
mtd9: 01d40000 00020000 “tclinux”
mtd10: 00020000 00020000 “romd”
mtd11: 00020000 00020000 “second_romfile”

Con eso tenemos una visión más que completa del mapa del router, de como se compone internamente.Efectivamente comprobamos que la partición raiz es SquashFS, las particiones /sys, /proc son las habituales. A parte de ello se monta una partición como “ramfs” que como vimos contenía el archivo /etc/passwd, y por otro lado uan con el extraño nombre “usbfs”… es posible que el router tenga internamente puertos USB después de todo, y de echo la interfaz tiene configuraciones para SAMBA.

Lo que se refiere al particionado de la Flash, vemos hasta 12 particiones, y por suerte para nosotros los nombres son relativamente descriptivos. Vemos además que las particiones mtd2-5 estan duplicadas, o al menos eso parece, lo que nos hace pensar en un sistema de doble imagen, muy usado en los sistemas para evitar una mala actualización. Bootloader, kernel, rootfs y rom/cfg parecen evidentes su contenido, mientras que tenemos otra partición algo más extraña con el nombre de tclinux. El tamaño de las diferentes particiones también nos dan otra idea, siendo tclinux la partición más grande con diferencia, más que la suma de las demás, lo que posiblemente nos indique que tclinux es de algún modo “todo”, y de echo, lo es.

Pero pongamos por caso que tenemos la imagen de actualización, nos será más sencillo para explicar su estructura, y más adelante veremos como poder extraerla si queremos desde el router, que es secundario.

 

Estructura de la imagen de la firmware

Actualmente tan sólo existe una firmware completamente oficial, la B14, aunque la B21 se ha distribuido a muchos usuarios debido a los problemas ocasionados por la B14:

Mitrastar b14 113WJI0b14.bin b79d53bb663cbae480532942cc0e961a
Mitrastar b21 113WJI0b21.bin 770a5a52069066dc87978dba949cb1fd

Tomemos la segunda por caso. En lo personal, me gusta siempre antes de cualquier otra cosa, echarle un vistazo a través de un editor hexadecimal a ver que veo. Haciendo un barrido sin demasiada observación, vemos en primer lugar lo que parece claramente una cabecera al comiendo de la imagen, y curiosamente al final de todo el archivo nos encontramos también que termina con “</ROMFILE>” que es precisamente como termina también nuestro archivo de configuración. Si hacemos una pequeña búsqueda con esto, podemos localizar también el inicio de esta parte, que parece que tiene una pequeña cabecera que lo precede especificando que está comprimido y el tamaño que posee, eso lo vemos en el offset 0x011d27d6.

firmware

Como sabemos también que se supone es una imagen SquashFS, podemos buscar su cabecera y ver si se encuentra alguna correspondencia, buscando por los valores “68737173”, y sí… encontramos también una correspondencia de este en el offset ox0014e7e3, que termina de echo justo cuando comienza el archivo de configuración antes citado. Con esto tenemos prácticamente, y sin necesidad de usar ninguna utilidad, el contenido completo de la firmware (aunque queda ver y analizar aun unas cuantas cosas). Lo único que nos queda es una parte, que se encuentra después de la cabecera y antes de la imagen squashfs. Teniendo en cuenta que tenemos la información anterior de las particiones mtd, la respuesta es evidente: Es el kernel. Recordemos que en las particiones teníamos 3 en concreto que estaban duplicadas con el mismo nombre, con la única diferencia a priori de que las particiones más bajas tenían la coletilla main. Bien, por pura lógica asociamos defcfg al archivo de configuración que hemos encontrado, roofs a la imagen squashfs y el otro pedazo que nos queda es el Kernel. Además, como tenemos el tamaño de las particiones vemos también que efectivamente, si dividimos cada parte independientemente, corresponden sus tamaños a los tamaños de las particiones (ojo que dado que el tamaño de erasesize es de 0x00020000, el espacio de las particiones es múltiplo siempre de este valor, con lo que el tamaño excedente se rellena). Con este pequeño análisis, podríamos ya extraer la imagen squashfs a nuestro equipo, y a priori modificarla como nos diese en gana, volver a crear la imagen squashfs y ver como poder volver a montar la imagen de actualización con todo sin romper nada.

 A partir de aquí, tendríamos el trabajo farragoso. Es necesario comprender las cabeceras, el contenido tan sólo es lo sencillo. Diseccionar las cabeceras es un trabajo más meticuloso y estar haciendo comprobaciones, sumas, cuentas, mirar binarios del router en busca de más información… es tedioso. En mi caso empiezo siempre desde el comienzo, identifico lo que parecen ser los “Magic Number”, cadenas de texto descriptivas que pueden indicar versiones, conjuntos de bytes que indiquen tamaños y desplazamientos, checksums… en definitiva, lo que se puede esperar de cualquier cabecera. Diseccionar totalmente la cabecera (las dos que hay) fue lo que más tiempo me llevó. Os desgloso lo que sería la estructura integral de la firmware, incluyendo por supuesto la estructura de su cabecera. Digamos que la imagen de actualización se compone de tres “partes”. La cabecera, la firmware en sí (compuesta de kernel+rootfs/sistema_archivos) y el archivo de configuración:

0x00000000 Header
    0x0000 Cabecera “Magic Number” 04 D0 FC 9C
    0x0004 chipID = “36 33 33 36 38 00 00 00” = 63368 (8Bytes)
    0x000C Padding (16 Bytes)
    0x001C ModelID = 5A596004 (4Bytes)
    0x0020 Tamaño total archivo .bin, incluído cabeceras (4Bytes)
    0x0024 Offset en Memoria rootfs (0x40000 + offset bin) | 0x40000 = Bootloader 0x20000 + romfile 0x20000
    0x0028 Tamaño Rootfs (4Bytes)
    0x00CC Offset en Memoria Kernel
    0x0030 Tamaño Kernel (4Bytes)
    0x0034 Offset en Memoria cfgfile
    0x0038 Tamaño cfgfile (4Bytes)
    0x003C ¿Magic Number?? 01 00
    0x003E Tipo de imagen | main (0x0003),  esclava (0x0002), bin de actualización (0x0001)
    0x0040 Versión Firmware (32Bytes)
    0x0060 Descripción Firmware (32Bytes)
    0x0080 Checksum Rootfs (4Bytes)
    0x0084 Checksum Kernel (4Bytes)
    0x0088 Checksum cfgfile (4Bytes)
    0x008C Padding

0x00000100 Firmware
    0x00000000 Header
        0x000 Cabecera “Magic Number” 32 52 44 48 (4Bytes)
        0x004 Tamaño de cabecera (4 Bytes)
        0x008 Tamaño de la “Firmware” incluyendo su cabecera
        0x00C checksum SquashFS, las particiones _main no llevan CRC, la firm no lo computa en cualquier caso.
        0x010 versión de 2rdh?? Termina con salto de linea (32Bytes)
        0x030 “Salto de linea”/padding (32Bytes)
        0x050 Offset squashfs/tamaño kernel (4Bytes)
        0x053 Tamaño squashfs (4Bytes)
        0x058 Padding
        
    0x00000100 Kernel, lzma
    0x0014e6e3 rootfs Squashfs 4.0 lzma | Sistema de archivos

0x011d27d6 Configuración romfile
    0x0000 Header
    0x0028 romfile comprimido.  ¿Algoritmo fastlz?

 

 Modificación/Creación de una firmware nueva

Bien, teniendo toda la estructura de la imagen de actualización, debería de ser trivial realizar cualquier cambio (añadir, eliminar, modificar) dentro de la firmware. Con linux tan sólo necesitaremos tener las herramientas para crear y extraer squashfs, teniendo en cuenta que la imagen original fue creada en SquashFS 4.0+, usando la compresión LZMA. Esto significa que si no usaron un SquasFS modificado tuvieron que usar SquasFS 4.1, 4.2 o 4.3, ya que hasta la versión 4.1 no se dio soporte oficial a LZMA. Yo lo he realizado todo con SquasFS 4.3, usando como compresor LMZA el SDK de 7zip. Es necesario eso sí, modificar el makefile para habilitar lzma.

Extraída la imagen en nuestro equipo y modificada a voluntad (o añadido los archivos/paquetes que deseemos…) volvemos a empaquetar nuestra imagen squashFS. De nuevo, recordemos que debemos de usar LZMA y realizar la creación sin el padding a 4K. Llegados a este punto, como tenemos toda la estructura de como tiene que la estructura de la imagen de actualización, tan sólo tenemos que realizar el proceso inverso y corregir todas las cabeceras que sean necesarias. Sería muy sencillo crear una pequeña utilidad que pasándole la imagen modificada, el kernel y el archivo de configuración nos crease el archivo final de actualización con todas las cabeceras corregidas. Pero ni he tenido tiempo ni tengo ganas de hacerlo. Así que sigamos.

Con la imagen SquashFS ya modificada, podemos empezar a empaquetar nuestra nueva imagen de actualización. Por suerte para nosotros, la cabecera de la sección perteneciente al kernel+rootfs no se verifica en ningún momento, y aunque podemos por supuesto calcularla, no es necesario ser muy rigurosos. La parte más tediosa es el cálculo del checksum, así que podemos establecerlo tan ricamente como “00 00 00 00” y no pasa nada.

Añadimos al final de la imagen squashfs el archivo de configuración previamente extraído de la imagen inicial. Añadimos encima de este el kernel, y encima del kernel la cabecera secundaria. No es necesario, pero por tener un mínimo de decencia corregimos en esta el tamaño de la “firmware” (que es el tamaño de la cabecera secundaria+kernel+squashFS), el checksum no nos complicamos y lo dejamos en 00 00 00 00, el offset de squashfs no ha cambiado con lo que lo dejamos igual y modificamos el nuevo tamaño que tiene nuesetra imagen squashfs (ahora sí, tan sólo el tamaño de nuestro squashfs modificado)

Por último queda realmente lo que es más delicado, que es reconstruir realmente la cabecera que va a judgar si nuestra firmware es válida, por no decir que si metemos la pata siempre podemos bloquear e inutilizar el router, así que cuidado aquí. Los valores a modificar en realidad son pocos, si tan sólo hemos tocado el sistema de archivos:

    0x0020 Tamaño total archivo .bin -> Es necesario modificarlo porque el tamaño de nuestro squashFS será diferente
    0x0028 Tamaño Rootfs -> El valor es el mismo que se puso en la cabecera secundaria, y hay que modificarlo por lo mismo que el anterior
    0x0034 Offset en Memoria cfgfile -> Al cambiar el tamaño del rootfs, el offset del archivo de configuración cambia. Recordemos que hay que sumar siempre 0x40000
    0x0080 Checksum Rootfs (4Bytes) -> Que checksum??

Bien, tenemos todo menos el checksum de rootfs, el resto son los mismos porque no hemos realizado ninguna modificación. La pregunta del millón es como diablos calcula Mitrastar este valor, puesto que ha podido usar cualquier técnica conocida o desconocida. La mala noticia es que usa un algoritmo propio para calcularlo, la buena noticia es que ya lo tengo recreado, y la mejor noticia es que incluso nos podemos ahorrar su cálculo si sabemos donde mirar (una pena que descubriese esto último más tarde, pero al menos tengo igualmente el algoritmo.

El checksum usado por Mitrastar es una modificación al conocido CRC32, usando una lockup table para agilizar los cálculos, y podemos encontrarlo en el binario cfg_manager. Se puede buscar la función y decompilarla. Es necesario este valor porque el bootloader y el propio cfg_manager comprobarán dicho valor, y si no corresponde al que ellos calculan, el router rechazará dicha imagen. No sólo se usa este checksumo para verificar la firmware, igualmente se verifican tamaños y otros, pero ya hemos dado por supuesto que la cabecera la hemos calculado bien.

Bien, he dicho que aunque tengo creado el algoritmo para calcular el crc32 modificado no es necesario. Esto es porque por suerte para nosotros ya lo calcula el cfg_manager por nosotros. Cuando actualizamos el router (o lo intentamos), justo antes de que este se reinicie (sea la firmware válida o no) escupe en la consola de registro los cálculos pertinentes, sacando por pantalla los checksum calculados y los que tenemos en nuestra firmware. Dicho de otro modo… si actualizamos aun con la cabecera con los checksum incorrectos, y mientras esta el proceso miramos el registro con dmesg, obtendremos algo como esto:

***** MitraStar Confidential Firmware *****
compressedLen = 25194
pTag->kernelChksum = 11b8cc8b
pTag->rootfsChksum = da3878fa
pTag->defcfgChksum = 35842e0b
cal kernelChksum = 11b8cc8b
cal rootfsChksum = da3878fa
cal defcfgChksum = 35842e0b

pTag->modelId = 5a596004
pTag->chipId = 63368
len = 011d8a68
mrd->modelId = 5a596004
mrd->chipId = 63368

Update slave image version

Ready to flash image…

Si los checksum calculados no se corresponden a los nuestros, el proceso fallará, pero podremos anotar el crc calculado, modificar los nuestros para que correspondan y volver a actualizar. Eso le quita a cualquiera tener que decompilar el código en cfg_manager, extraer el algoritmo de verificación y recrearlo en C o en el lenguaje que le guste. Por supuesto el echo de que se calcule el CRC no hay que verlo sólo como para impedir que se realicen modificaciones, sino para garantizar la integridad de estas y evitar una mala actualización.

Si todo ha ido bien, el cfg_manager copiará la imagen de actualización a 4 particiones esclavas, mtd6-9, cada una con su contenido. Al reiniciar el router, el bootloader realizará comprobaciones similares a las realizadas por cfg_manager, y si todo es correcto procederá a copiar las particiones esclavas mtd6-9 a las principales mtd2-5. Si el router se reiniciase (funcionando) sin aparentemente ningún cambio efectuado, posiblemente el bootloader encontró algún problema en la firmware modificada y anuló la copia a las particiones principales, con lo que habría que ver el problema, solucionarlo y volver a cargarla.

Si todo ha sido correcto, llegados a este punto, tendríamos nuestra propia firmware modificada con lo que necesitásemos, ya fuesen arreglos de los problemas que tiene la firmware oficial o nuestros propios añadidos.

Recordemos que dije que no es necesario tener una imagen de actualización. Podemos extraerla a partir de las particiones mtd5 o mtd9, tan sólo con una apreciación: Las particiones mtd5 y 9 estarán posiblemente padeadas para rellenar el resto del erasesize, con lo que hay que eliminar dicho bloque. Por otro lado hay que modificar un byte en la cabecera que especifica el “tipo de partición”. El archivo de actualización tiene que estar en 01, no en 02 o 03. Quitando estos dos cambios, el resultado será una copia 1:1 (exacta) del archivo de actualización original. No es mal truco después de todo.

 

¿Instalación/Actualización de componentes y otros paquetes?

Ahora mismo no he añadido ningún componente extra, pero es más que factible. Hay que tener en cuenta que el router usa una arquitectura MIPS, y que tendríamos que recompilar cualquier paquete o binario para esta arquitectura. Aquí la idea he de decir que no fue mía y me llegó leyendo a un blogero en algún lado, y es que el router usa uClibc como motor, y el proyecto uClibc posee por suerte para nosotros imágenes listas para iniciar desde linux en las que podremos tener las herramientas necesarias para compilar el códígo y paquetes que deseemos, y una vez realizado sacarlo de ahí y meterlo en nuestra firmware modificada:

http://www.uclibc.org/downloads/binaries/0.9.30/


 

Conclusión

Bien, creo que eso ha sido todo. Sin duda alguna un buen entretenimiento del que siempre se aprende, y yo el primero. Quizás lo más útil en este caso no es instalar paquetes o actualizar otros (al menos en principio), pero puede que sí lo sea el poder realizar pequeños cambios aquí y allá, instalar algunos binarios extras como tcpdump, aplicar configuraciones específicas, filtros… tenemos espacio en memoria de sobra a fin de cuenta, y posiblemente tardemos nosotros mismos menos tiempo en corregir algunos de los problemas de la firmware, que esperar que Mitrastar los arregle por nosotros y que Movistar la distribuya.

Por ejemplo, para corregir el problema de la batería de los ARP en la B21, bastaría en principio con hacer el siguiente cambio permanente:

echo 0 > /proc/sys/net/ipv4/neigh/br0/mcast_solicit

Aunque como digo, tan solo es un ejemplo más…

Fibra Óptica y su implantación en España

Share on Google+Share on FacebookTweet about this on Twitter

fibraoptica

“¿Tienes fibra? ¿Has puesto ya fibra? ¿sabes algo de como va lo de la fibra?

fibra fibra fibra… llevo un año escuchando estas preguntas una y otra y otra y otra… así que, vamos a ver un poco de fibra fibra y fibra.

La tecnología siempre avanza, ya sea en pos de progreso o en pos de la cuenta bancaria de las empresas que las despliegan, pero sea como sea no para. Por suerte para nosotros esto también sucede en las telecomunicaciones, y en mayor o menos medida (y antes o después) nos beneficiamos de ello. A veces es la invención de algo totalmente novedoso y “mágico”, otras veces no es más que poder aplicar de forma práctica y masiva algo bien conocido. Es el caso de la fibra óptica. ¿Por qué hoy? Bueno, quizás porque hace un año era todo el marketing orientado al 4G (que no es 4G sino que es LTE como ya hemos dicho más de una vez), y llevamos ya unos meses en los que el marketing se a ido a la comercialización de la Fibra óptica en los hogares. Para mucho está claro que es y que no es… otros no lo tienen tan claro. De cualquier modo, vamos a ver cosas que posiblemente sepa todo el mundo y cosas que posiblemente sólo sepan un grupo muy reducido. Cosas muy útiles, cosas que no necesitamos y quieren que paguemos, cosas curiosas…

 

¿QUE ES?

Posiblemente la mayoría de las personas sepa que es la fibra óptica a estas alturas, aunque es cierto que la mayoría nunca la ha visto realmente. La fibra óptica en su sentido más amplio es nada más y nada menos que otro sistema de transmisión de información, que en este caso usa para tal transmisión lo que realmente denominamos “fibra óptica”, un filamento muy fino (puede ser más fino que el pelo de un cabello humano), que puede ser de vidrio o de plástico, generalmente muy transparente. Esta fibra hace la función de “cable” en el sentido de conectar dos extremos para compartir información entre ellos, pero a diferencia de los cables ordinarios estos no portan electricidad, tan solo transportan fotones (luz).

Su funcionamiento es “sencillo” de explicar. Usando las propiedades de reflexión (cuando nos miramos en un espejo, la luz se refleja) y de refracción (cuando metemos un boli en un baso de agua y parece que este cambia de dirección y se dobla, la luz se refracta), se usa las fibras ópticas para dirigir y contener el haz de luz que viaja por él. La luz se va reflejando en ángulos muy muy elevados sobre el núcleo de la fibra, haciendo que esta llegue al otro extremo. Pero la luz en sí misma no transmite información útil por así decirlo, en el mundo digital necesitamos a fin de cuenta ‘1’ y ‘0’, ¿cómo se hace para transmitir información por ese medio entonces? La luz no deja de ser una onda electromagnética con la frecuencia que sea. Si emitimos cualquier sonido o cualquier haz de luz a una única frecuencia y de forma constante no podemos extraer nada de ello, y si fuese sonido como mucho escucharíamos un tono constante. Pero si introducimos a esa frecuencia otra frecuencia desplazada tan sólo ligeramente, veríamos como ese sonido (en caso de ondas sonoras) pasaría mágicamente a ser pulsante, y la onda lumínica tendría un comportamiento similar. Ver esto gráficamente es sencillo, pero no deja de ser física y más física… y sería meternos en campos de otros.

Resumiendo lo anterior, gracias al desfase de diferentes frecuencias de la luz dentro de la fibra se logran producir esos “pulsos”, y a fin de cuentas nuestros “unos y ceros”. Cuanto mayor sea el número de frecuencias en las que se puede operar, menor será la longitud del pulso producido (por así decirlo), y por tanto al final una capacidad de transmisión de información mayor. Esto hace de la fibra óptica a día de hoy el sistema de transmisión de información más rápido del que disponemos (que yo conozca al menos).

Este invento dista mucho de ser nuevo, y la fibra óptica viene usándose desde hace décadas. De echo aunque la mayoría a lo mejor no lo sepa, las comunicaciones mundiales a día de hoy se realizan al final en sus tramos troncales por fibra óptica:

Cableado de fibra europeo

A groso modo lo que vemos ahí son las líneas de comunicación troncales (de borde) de Europa, cableado de fibra óptica que conecta básicamente continentes, países… entre sí de forma subacuática. Muchos creen que las comunicaciones se realizan via satélite, pero lo cierto es que el grueso de todo lo enviamos/recibimos por el mundo digital viaja por alguno de las ramas que vemos en este mapa.

No, rotundamente no, no es nuevo. Pero entonces… ¿por qué  ahora tanto bombo con las redes de fibra? Bueno, quizás la fibra sea el modo más eficiente y rápido de transmitir información, pero también tiene muchos inconvenientes. El precio de los equipos necesarios, de la propia fibra, una flexibilidad muy inferior respecto a otros modos de transmisión por cable, una alta fragilidad, complejidad para realizar reparaciones por cortes o fracturas o empalmes… esto ha hecho que la fibra no se haya usado hasta muy recientemente para dar servicio a usuarios domésticos. El abaratamiento de los componentes, la mayor calidad de estos… y por supuesto la cada vez más acuciante necesidad de sustituir nuestro viejo amigo “el par de cobre”, ha hecho posible que las grandes telecos hayan empezado a desplegar de forma masiva sus redes de fibra óptica.

 

¿QUE NOS APORTA? ¿LO NECESITAMOS?

La respuesta rápida y sencilla?? Nos aporta bastante, pero la inmensa mayoría no lo necesita… ni ahora ni en mucho tiempo.

Llevamos meses en los que no paran de bombardearnos con maravillosas ofertas convergentes de fibra que incluyen televisión, móvil… cualquier coas es poco para “picar” y contratar sus súper paquetes de todo incluido. Que si 50mb, que si 100mb, que si mejor que sean 300mb con todos los canales que quieras… pero todo cuesta dinero, y lo primero que tenemos que pensar es si realmente necesitamos o no los nuevos servicios, si estamos dispuestos a pagar por ellos y si técnicamente vamos a poder disfrutarlos.

No me mal interpretéis, lo primero que he dicho es que sí nos aporta bastante, pero realmente la mayor aportación que puede tener para nosotros es realmente la, por fin, independencia del viejo par de hilos de cobre que lleva acompañándonos desde hace muchos muchos muchos años. De echo me parece sorprendente que haya sido capaz de aguantar tanto, y como se fueron creando tecnologías para poder seguir usando nuestro viejo amigo… las conexiones ADSL (la inmensa mayoría al menos en nuestro País) han logrado llegar gracias a ADSL2+ hasta los 24mb/s que no es poco, incluso algún operador ha comercializado en España VDSL con el que es posible alcanzar los 100mb/s en su versión de VDSL2. Pero el cobre tiene dos o tres desventajas enormes con las que hemos tenido que luchar a diario:

a) Distancia: La velocidad máxima alcanzada por ADSL/VDSL está totalmente asociada a la distancia hacia las centralitas, padeciendo de una atenuación enorme en función de esta. Esto ha hecho que aunque todos los operadores nos han ofrecido desde hace ya tiempo conexiones de “hasta 24mb”, sabemos bien que esa velocidad tan sólo podría disponerla quien tuviese la suerte de vivir justo al lado de la centralita. La mayoría de las personas se han tenido que contentar siempre con 6-10Mbs, y eso sin entrar ya en entornos rurales, donde el ADSL era casi una utopía.

ADSL_Line_Rate_Reachb) Redes Viejas: El cobre que prácticamente disponemos todos, sobre todo las redes principales, son viejas, muy viejas. ADSL/VDSL padece enormemente de cualquier interferencia electromagnética, y deterioro de las instalaciones. Esto puede ser tan significante que un cableado nuevo a otro viejo puede marcar una diferencia de varios mb/s.

c) Ancho de banda limitado: Aunque se han logrado alcanzar velocidades muy altas, no son comparables ni pueden acercarse a otras tecnologías de transmisión de información, como pueda ser la fibra óptica. Mientras que el VDSL teóricamente pueda llegar a los 100 megabits por segundos, un sólo hilo de fibra estaría limitada (físicamente, no creo que jamas se alcance dicho límite),en unas decenas o centenas de Terabytes por segundo

Por tanto la ventaja más evidente que tenemos es la sustitución del cobre por un canal totalmente nuevo, moderno, y con unas posibilidades a largo plazo enormes. Las telecos también ganan, mantener la nueva red de fibra es más barato que mantener la red de cobre, aun con las complicaciones que acarrean las reparaciones cuando una fibra se parte. Además pueden ofertar servicios que de otro modo serían imposibles.

Lo curioso es que la mayoría de todas las ofertas con las que nos bombardean poco nada dicen de que estos serán los beneficios más evidentes, ellos prefieren indicar en grande la velocidad que tendrán nuestras conexiones de fibra. Que si fusión 300Mb/s con televisión con Movistar, que si pack ahorro 200Mb de Jazztel, One Fibra de Vodafone/ONO (OJO!! NO ES FIBRA OPTICA, es CABLE)… y se olvidan de indicar algunas cuestiones que son realmente las más importantes:

a) Quitando algunos servidores webs en los que podamos descargar muy rápido archivos pesados y algunos programas P2P, el aumento de velocidad pasará desapercibido para la inmensa mayoría. La navegación web, vídeos, redes sociales, mensajería, correos… lo que es el 95% del tráfico en Internet después de todo, no vamos a notar una mejoría de tener 20Mb/s a tener 300Mb/s. Esto es muy sencillo, si es una web, ya os digo que la mayor parte del tiempo que pasamos mientras que accedemos a la web o no, recae en latencias, el propio navegador web, peticiones HTML… La velocidad la notaremos principalmente cuando realicemos descargas directas, y siempre y cuando los servidores desde los que los descarguemos tengan capacidad para ello.

b) La mayoría de todos los equipos que conectamos a nuestros “routers” a día de hoy es por WIFI, Ya sean televisiones, teléfonos, PCs, portátiles, tablets… Esto no es malo, hemos logrado prescindir de cables… el problema es que me atrevería a decir que ni siquiera un 2% de la población dispone de equipos WIFI cualificados para altas velocidades. En el mejor de los casos dispondrán de dispositivos 802.11n capaces de 150-300Mb/s, pero WIFI no es Ethernet. Si tenemos contratados 300Mb/s por fibra y el router que nos instalan en el mejor de los casos es 802.11n con dos streams haciendo un total de 300Mb/s, eso no significa que podamos disponer de esos 300Mb/s. Primero nuestro equipo tendría que disponer igualmente de una interfaz 802.11n al menos similar (la mayoría que hay ahora mismo son G, y los N mayoritarios son de 150Mb/s). Después, esa es la velocidad máxima hipotética, sólo en un sentido de transmisión (no es full duplex) y sin ningún otro cliente WIFI transmitiendo. Dicho de otro modo, si tienes un cliente y router WIFI de 300Mb/s, en el mejor de los casos, pegado totalmente al router y sin ningún otro dispositivo WIFI, tendrías una velocidad de 10-15MB/s, lejos de los 38MB/s aproximados que puede darte tu línea de fibra de 300Mb/s, (y de ya os digo que lo normal es que se tengan velocidades de 4-7MB/s en instalaciones domésticas normales. Por supuesto este problema no sucede en conexiones Ethernet, donde los routers que nos instalan si son (o deberían de ser todos) GigaEthernet (y a diferencia de WIFI pudiendo trabajar todos los puertos que tiene en Full Duplex simultaneamente), con lo que no tendría que tener problemas en manejar los 120MB/s (ojo, B grande, Bytes, no bits)

Para poder hacer uso de redes de datos de estas velocidades por WIFI a día de hoy es casi imperativo disponer de adaptadores 802.11ac, capaces de transmitir desde los 400Mb/s hasta más de 2000Mb/s, siempre y cuando evidentemente tengamos el equipo adecuado. De lo contrario, o usamos conexiones GigaEthernet o da igual que nos dupliquen la velocidad o la tripliquen, porque por WIFI NO VAIS A PODER disfrutarla en ningún caso.

80211ac_coverage

c) Instalación y cobertura. Nos guste o no es un cable nuevo, y eso requiere una instalación por parte de profesionales. Eso implica primero que nuestro hogar o empresa debe de tener suerte y estar dentro de los municipios por los que en principio se están haciendo los despliegues. Pero el despliegue es lento, llevará años tener cableado como dios manda el País. No podría decir en porcentajes pero no creo que tenga ahora mismo acceso a la fibra óptica (sea cual sea el operador) más de un 10-15% de los habitantes. Por otro lado la instalación es necesaria, y esta puede no ser tan sencilla en muchos hogares. Sí, está claro que muy a las malas puede coserse el cable por la fachada y meterlo hacia el interior por cualquier orificio (o hacer uno), pero esto no suele siempre ser viable o bien visto por muchos. Además depende en gran medida de la pericia del instalador y en los buenos términos que puedas llevarte con él para planificar el mejor modo de instalarla… y ya os digo que a veces es lo más sencillo del mundo, y otras veces es lo más complejo.

d) Recordar que la fibra óptica que se usa aquí en España (y no cuento con la fibra/cable de ONO) prescinde totalmente del cobre, y con ello como habréis imaginado de las redes de teléfono convencional. ¿Esto quiere decir que nos quedamos sin teléfono? No, esto quiere decir que ahora el teléfono pasará a ser sí o sí por VoIP, y esto puede ser muy bueno, bueno, malo o nefasto.

En el escenario ideal, el ONT del operador o el router dispondrá de una toma de teléfono estandar que se podrá conectar a una roseta RJ11 (las de toda la vida) directamente para dar servicio al resto de rosetas de la casa. En escenarios en los que la roseta de teléfono no sea accesible tendremos que conectar directamente el teléfono a dicha toma, con lo que deberemos de dispone de algún juego de teléfonos inalámbricos en la mayoría de los casos.

El teléfono estará alimentado por el propoio router/ONT, si la luz se va en nuestra casa/edificio, perderemos igualmente el teléfono.

Inicialmente la calidad era mala, a día de hoy si la VoIP está bien configurada en los equipos (y debería) la calidad suele ser superior a las que podíamos realizar con anterioridad, además de poder realizar algunos “trucos” de los que hablaremos más adelante, como por ejemplo poder llevar tu número fijo en el móvil.

Aunque duela decirlo, lo cierto es que sea A o sea B, la mayoría de usuarios que disponen de fibra a altas velocidades no disfrutarán a corto plazo sus beneficios. Por supuesto esto no es una norma, y la tecnología funciona realmente. Para aquellos usuarios que dispongan de equipos competentes, conexiones por cable directo, conocimientos competentes… por supuesto podrán beneficiarse de estas altas velocidades. Por ejemplo, para mi en lo personal, el mayor beneficio no viene siquiera de la velocidad de descarga sino de la subida, que ahora mismo rondan desde los 3Mb/s hasta los 30Mb/s (una décima parte de la velocidad de subida en algunos operadores, simétrica en algunos otros). Las mejoras en VoIP o incluso el poder disfrutar de servicios de IPTV (televisión via IP) son puntos importantes a tener en cuenta, pero de nuevo posiblemente no van orientados a una mayoría.

El ADSL morirá posiblemente antes que tarde, pero es probable que sea más por el marketing y la obsesión de la mayoría de querer tener lo mejor que por necesidad. Esto no es malo del todo porque gracias a esto tecnológicamente nos desarrollamos antes, pero es malo porque mata la inteligencia de muchos… hay que tener bien claro que es lo que se necesita, que es lo que van a darnos y como lo vamos a tener. A raíz de eso tomar la decisión que creamos, pero por dios… que no sea para poder fardar a los amigos/compañeros con el: “Es que yo tengo 100Mb/s… pues yo tengo 300Mb/s…” Seamos serios…

 

QUE NOS INSTALAN, COMO ES LA INSTALACIÓN

Vale, a pesar de todo nos decidimos a instalar fibra en casa, después de todo nuestra instalación de cobre es vieja y no nos da más que unos “escasos” 6Mb/s. Además hemos echo los deberes, hemos comprado equipo de altas prestaciones, router 802.11ac que sabemos configurar para nuestro operador, adaptadores wifi ac…  no son necesario porque nuestro operador nos dará el equipo necesario, pero como hemos dicho este equipo es tan solo viable en el mejor de los casos conectado a él por cable. Sabemos que tenemos cobertura y damos el salto… damos el alta, decimos por donde queremos realizar la instalación… y empieza el show.

 

INSTALACION

¿Realmente la fibra optica es un cable dedicado por cliente? ¿Es fibra óptica en todo su recorrido desde las centrales de ellos hasta nuestros hogares?… Bien, a modo particular voy a hablar de como funcionan las instalaciones de Movistar porque las conozco de primera mano, pero casi con seguridad el resto de ISP poseen infraestructuras similares.

En primer lugar, la fibra que se instala se llama FTTH (Fiber To The Home). Este tipo de instalación significa que desde el inicio del recorrido hasta terminar conectado al propio ONT (Terminal de red óptico) todo es fibra. El ONT es lo que en fibra nos hará la función del viejo modem (que no router), y básicamente se encarga de recoger las señales ópticas que recibe, separar los servicios que circula por estas convertirlas a tramas Ethernet, como pueda ser Internet, VoIP o Televisión). Todo ello se pasa directamente al router que nos da servicio. Esto es interesante porque garantiza en realidad la máxima fiabilidad y prestaciones, no son instalaciones en las que la fibra tan solo llega a medio camino y de ahí al usuario va por otro tipo de medios, en este caso el propio cable de fibra óptica muere en el mismo ONT… en realidad muere en la roseta óptica, y de esta sale un pequeño latiguillo al ONT, también de fibra óptica.

No obstante, como era de esperar, el cable de fibra que sale desde la central hasta nuestro hogar no es dedicado. En este caso es comprensible, un sólo cable de fibra por cliente sería desaprovechar mucho ancho de banda, sobre todo para ellos, con lo que este cable sufre en dos ocasiones diferentes dos divisiones. El esquema general sería el siguiente:

FTTH-localizacion-de-los-splitter_3

La instalación se despliega desde las centrales, del que sale todo el cableado de fibra (usando monomodo). En su camino sus primeras paradas son las cajas de registro (CR), que componen la estructura principal de la red de fibra. En estas cajas de registro se efectuaría de ser necesario el primer nivel de división de los cables de fibra, usando splitters de 1×4 o de 1×8 según se requiera. Esto significa que un solo cable de fibra se dividie en 4 u 8 nuevos cables de fibra, y esto es importante, TODOS ELLOS CONTENIENDO LA MISMA INFORMACIÓN. Desde las cajas de registro se distribuye la red en lo que se llama red de distribución precisamente, que acaba por lo general en zonas residenciales en las que se coloca la “Caja Terminal”. Estas cajas son bastante visibles, se colocan por lo general en exteriores comunes a la vista de todos, aunque fuertemente protegidas y resguardadas de los elementos, y totalmente estancas. Aquí se realiza el segundo nivel de división, y en esta ocasión se realiza por medio de spliters de 1×8 o 1×16, es decir, se vuelve a dividir cada fibra en 8 o 16. En cualquier caso, combinados ambos niveles de spliters, cada cable de fibra original al pasar por los dos divisores se convertirán a lo largo de todo su recorrido hasta un máximo de 64 fibras, o dicho de otro modo, Movistar por cada fibra que sale de su central puede alimentar y dar servicio a 64 hogares, Y A TODOS ELLOS LLEGA LA MISMA INFORMACION. Las cajas de registro pueden dar servicio a muchos más hogares de 16, pero son cajas a las que llega más de una fibra. Todo esto es tan solo el camino que recorrería una fibra, no significa que en una CR o una caja de registro sólo pueda ir una fibra.

Por lo general la instalación base de la red termina aquí, y empezaría la instalación propia del cliente. Cuando se requiere la instalación de la fibra, se tira un cable desde el hogar/trabajo del cliente hacia la caja terminal. En la caja Terminal se realiza una fusión del nuevo cable con una de las salidas del splitter que aun quede disponible, y en el hogar/trabajo del cliente se introduce el cable por el modio que sea, y este termina en una roseta óptica, en la que se realiza de nuevo la fusión del cable con un pequeño pigtail que posee la roseta, dando por terminada la instalación. El resto es proceder a la colocación de los equipos y conectar por medio de un latiguillo de fibra la roseta óptica y el ONT.

Cuando hablo de fusión hablo de fusión. La fibra no puede “empalmarse” al modo tradicional al que estamos acostumbrados. Antes queríamos sacar una nueva roseta y tan sólo cortábamos el cable, cogíamos otro par de cables de cobre y uníamos de 1 a 2. Esto es imposible en fibra, de echo para hacer eso sería necesario un spliter. Incluso para la reparación por corte/fractura, no podemos simplemente acercar las puntas y enroscaras, no sólo porque se partiría, sino porque la luz viaja por dentro del núcleo de la fibra, no puede interrumpirse o saltar o… es necesario disponer de equipos especiales que sean capaces de fundir ambos extremos que quieran unirse, formando de nuevo un ininterrumpido filamento de fibra.

Como dato de interés, decir que cada cable que sale de la central hasta los 64 clientes que puede alimentar circula la misma información. Es decir, que al ONT de cada usuario llega igualmente toda la información que se envía y se recibe por los otros 63 ONT que pueden estar en funcionamiento, este simplemente discrimina todo el tráfico que no es el que va dirigido a él. Interesante por qué?? Bueno… imaginad que pasaría si de algún modo se le pusiese decir al ONT que dejase de discriminar el tráfico y que quisiésemos que entrase TODO… lo nuestro y lo del resto de 63 clientes.

 

EQUIPOS

Los equipos necesarios son en realidad muy similares a los que posee cualquier conexión DSL. Muchos ven que con fibra les instalan dos dispositivos diferentes mientras que con sus líneas DSL tan sólo disponían de uno. Esto es sólo una media verdad. La mayoría de particulares DSL poseen tan solo una puerta de enlace residencial para ahorrar espacio y porque es más económico a los ISP, el propio aparato integra un Modem al que se conecta el par de cable, un router que da servicio a la red de casa y un punto de acceso WIFI para… para dar wifi. En el caso de la fibra óptica no hay un modem… al menos no en el significado clásico, pero el ONT podemos verlo como tal, un “modem óptico” que además posee funciones algo más avanzadas.

La pregunta por tanto es, que ¿si antes podíamos tener tan solo un dispositivo, porque ahora dos?. En realidad sí existen dispositivos unificados en los que el propio aparato es ONT, Router y WIFI al estilo clásico de las redes DSL, y posiblemente en un año o dos serán los dispositivos que instalen la mayoría de los ISP porque son baratos. No obstante es mucho mejor tener dos dispositivos totalmente diferenciados con funciones bien diferenciadas. Por un lado el ONT que se encarga de lo que tiene que hacer, y por otro lado un router neutro que podemos configurar o manejar como mejor nos convenga, siendo la configuración necesaria para su correcto funcionamiento con fibra mínimo, y pudiendo usar en teoría prácticamente la mayoría de routers comerciales que hay en el mercado, no tenemos que buscar routers específicos que sean también ONT (o modems DSL como pasaba antes)

Dado que el teléfono va por VoIP, o el ONT o el router que tengamos disponible deberá de disponer de entrada de teléfono RJ11 para poder puentearlo a una roseta o a un teléfono. Esto es importante, porque si el ONT que nos han instalado no realiza las funciones telefónicas y estas las deriva en el router que instalan, si sustituimos el router por uno de nuestra elección tendremos que tener esto en cuenta. En cualquier caso deberíamos de poder decirle a los técnicos que nos instalen un tipo u otro.

¿Son buenos los equipos que nos instalan? Tsss, es como todo, son equipos baratos que más que nada realizan las funciones que tienen que realizar, ni más ni menos. En la medida de lo posible siempre recomiendo cambiar el Router por uno de nuestra elección que sea competente. Si vamos a contratar unos cientos de megas al menos disponer de un router 802.11ac, aunque tan sólo podríamos operar en ac si disponemos también de dispositvos en nuestros equipos que lo sean. Por otro lado routers de gama alta proporcionan además una estabilidad muy superior y un sin fin de configuraciones que de otro modo serían imposible, como por ejemplo la instalación de discos duros en el mismo router por USB3, usarlo de servidor DLNA, VPN, copias de seguridad automatizadas… hay de todo.

Las ONT importan menos porque el trabajo que tienen que realizar lo hacen bien por lo general, y si se funde o nos sale mala la unidad pedimos su reemplazo, pero sus funciones son muy delimitadas. De echo es muy normal que las ONT que nos instalan sean igualmente routers que por no ser WIFI o tener prestaciones más limitadas se configuran de tal modo que se desactivan ciertas funcionalidades, y se quedan tan solo para lo básico.

La desventaja por otro lado de usar tu propio router por ejemplo radica en que no vas a tener ningún tipo de soporte técnico por parte de tu ISP para configurarlo o garantizarte su funcionamiento, tendrás que buscarte tu mismo las castañas del fuego para que funcione Internet, VoIP y televisión en caso de que se tenga contratada. De esto encontramos miles y miles de tutoriales en Internet, y no, no cualquier router sirve, pero sí muchos más de los que encontramos en las guías. Un buen router de gama media/alta debería de ser capaz de configurarse por complicada que fuesen los parámetros de la red… ¿Por qué hay tantos manuales y debates sobre sus configuraciones para fibra? ¿Es que son diferentes los protocolos? Si y no.

Las conexiones ADSL se realizaban por lo general con una conexión PPPoE en la que tan sólo era necesario establecer usuario y contraseña que nos proporcionaba el operador y en todo caso las DNS. Prácticamente lo demás venía solo. Con fibra, tal como se está haciendo aquí, la cosa es algo más complicada. Sí, se usa por lo general una conexión PPPoE, pero a partir de aquí la cosa cambia un poco. Tal como se está haciendo aquí, por el mismo cable de fibra óptica viajan los paquetes de datos que componen tanto internet, voip y iptv. Esto o se envía todo junto o se envía al ONT por diferentes frecuencias, pero en cualquier caso en lgún momento es necesario subdividir estos paquetes, para enviar a fin de cuenta los de voip a los teléfonos, iptv al decodificador de televisión o Internet al router en general y el resto de dispositivos. Este mecanismo de diferenciación se realiza por medio de tags, de marcadores, mediante el protocolo 802.1Q, en el que los frames ethernet están marcados con un ID que determina así a que sección de nuestra red van a parar dichos paquetes. Por lo tanto el router que instalemos debe de ser capaz de crear estas… “etiquetas”, o lo que suele ser lo mismo, crear diferentes VLAN dentro de este para poder discriminar el tráfico y enviar a cada lado lo que le corresponde.

vlanPor ejemplo, en el caso de Movistar, el servicio de IPTV se etiqueta por medio de la vlan2, así que como primer paso deberíamos poder configurar el router para redirigir el tráfico etiquetado para vlan2 a un puerto ethernet del router concreto del que enviaremos el cable al decodificador (ademas de tener que configurar posiblemente rutas y otros). Pero incluso para poder disponer de internet tendremos que poder etiquetar el tráfico que venga como ID 6, para que sea enviado a todos los puertos e interfaces wifi, para poder tener servicio. Con VoIP exactamente igual. Por supuesto cada operador puede variar esto como quiera en función de que sistemas usen o de que servicios doten.

Es normal, sus equipos vienen preconfigurados para sus instalaciones, si queremos hacer uso del nuestro, toca encontrar los ajustes adecuados.

Llegados a este punto, si hemos instalado la fibra, si hemos puesto al día nuestros equipos y nuestros dispositivos, la siguiente pregunta es… ¿y ahora que?

 

Y AHORA QUÉ

La fibra y los servicios que nos dan por ella nos da ciertas funcionalidades que como es natural nunca nos las explicarán.. no les interesa realmente. Pero ello no significa que no puedan usarse ciertos servicios realmente interesantes.

-Sobre los servicios de Internet poco podemos decir sobre ello… tendremos ni más ni menos la velocidad contratada, y lo normal es que con una exactitud casi milimétrica, no importa si estamos a 2 metros de la central o a 10km, y realmente cualquier aumento que podamos desear o que por el motivo que sea se “regale” les basta a ellos con tocar un botón. Aquí solo recomendaría en todo caso cambiar las DNS del router (ya sea uno propio o el del ISP) a algunas que no esten bloqueando servicios y webs en España. Con las nuevas leyes han bloqueado páginas controvertidas como pueda ser thepiratebay a nivel de DNS, con lo que bastaría usar servidores DNS decentes y que estén fuera de restricciones absurdas. OpenDNS es muy usado, aunque en lo personal prefiero los servidores DNS de Google, tienen menos latencia: 8.8.8.8 y 8.8.4.4.

-Sobre los servicios de IPTV la cosa es más interesante (a aquellos que la tengan contratada). El servicio de IPTV se dirige a fin de cuentas al decodificador que está conectado al puerto del router preciso. El decodificador al encender lo único que hace es recibir por DHCP una IP/mascara/puerta de enlace que le dará servicio. Esto podemos hacerlo si queremos nosotros mismos en cualquier equipo, y ver por tanto la televisión contratada en cualquier PC. Dada que la IP es única no sería posible a priori visualizarlo de forma simultanea, aunque no imposible. Simplemente copiando los datos de conexión del decodificador en nuestra interfaz WIFI o cable de nuestro PC sería suficiente para recibir todo lo referente a la televisión. El resto recaería sobre el siempre eterno VLC, al cual tan solo tendríamos que especificar el “canal” que deseamos ver, que no son más que direcciones IP y puertos a los que accedería VLC para el correcto visionado. Y una vez por VLC podríamos grabar, retransmitir o cualquier otra cosa que quisiésemos.

-VoIP es igualmente interesante. Si nuestro ISP lo usa basado en los estándares (y debería), si conocemos las configuraciones de cada ISP podríamos configurar cualquier cliente SIP (ya sea en el móvil o en el PC) con los datos pertinentes, y por ende usarlos para realizar llamadas o recibirlas. Esto implica dicho de otro modo que mientras usemos la red de casa (la que usa la fibra) podemos hacer uso de VoIP como deseemos, no solo estar limitados a los teléfonos fijos/inalámbricos, sino también teléfonos IP, nuestro propio movil, el PC…

A extensión de VoIP, dado que podemos realizar llamadas a través de nuestra línea por VoIP si estamos dentro de nuestra red, nada nos impediría por tanto a través de conexiones VPN a nuestra red usar este servicio desde fuera de ella. ¿Por qué es esto interesante? Bien, cuanto menos tendremos por contratar fibra llamadas a fijos nacionales gratis, y dependiendo del plan contratado también X minutos mensuales a móviles. Dentro de nuestra red por medio de VoIP (usando telefonos, móviles o cualquier dispositivo configurado para usar el servicio de nuestro ISP) podemos llamar como si fuese nuestro fijo normal, la gracia es que si configuramos una red VPN y conectamos nuestro móvil (previamente configurado para poder usar VoIP de nuestro IP), las llamadas se realizarán como si estuviesen desde dentro de nuestra propia red. ¿En definitiva? Usando datos/wifi de nuestro móvil podemos llamar gratis a cualquier fijo nacional y/o consumir minutos gratis que tengamos contratados en el fijo, y la llamada se realizará como si fuese desde nuestro propio teléfono fijo. Ideal para cualquiera que suela tener excedente de datos y gaste más de la cuenta en llamadas.

 

CONCLUSION

Es bien simple. A menos que tengas equipos que realmente sean competentes o tengas unos requerimientos especiales o muy caprichosos… no te compensa pasar por caja, y menos contratar las velocidades altas o los planes de todo incluido, que al final lo que buscan es hacerte rascar la cartera. Es evidente que a lo largo del año en el que estamos y el siguiente, ante una mayor oferta los precios también serán más competitivos, la fibra óptica llegará a más hogares y poco a poco todo estará mejor asentado. Es lógico pensar que en un futuro más cercano que lejos todas nuestras conexiones se realizarán por fibra o de forma inalámbrica, no es un no al progreso ni mucho menos, es siempre más que nada dar un toque de atención a los que se dejan engañar fácilmente con los letreros grandes y las ofertas supuestamente maravillosas.

La fibra óptica es lo que es, funciona muy bien y tiene muchas ventajas. Pero sin equipos realmente adecuados, sin que la mayoría sepa o pueda sacar provecho realmente de lo que ofrece… no hay tampoco ninguna prisa para meterla en casa. En principio sería mucho más adecuada para PYMES o grandes empresas donde sí pueden requerir unos servicios más avanzados para poder dar cobertura además a un gran número de personas, pero para los dispositivos que tenemos en casa y el uso que por lo general la mayoría les da…

Recordar que a los ISP les interesa por los costes de mantenimiento que los que tengan cobre vayan pasándose a la fibra, y de echo ya algunos ISP ofrecen al mismo precio (el servicio más básico al menos) tanto ADSL como fibra en función de si se posee cobertura o no. Esto sí me parece mucho más adecuado y viable como primera toma de contacto, pero como digo siempre que cuando termine el mes no nos de un infarto por uan factura que ha engrosado por servicios que no aprovecharemos queramos o no queramos.

Un saludo.

Volver a arriba

Sobre Mí

Cambiar a la versión para móviles

Creative Commons License
Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Basado en el trabajo de blog.theliel.es.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.