Etiqueta: redes

  • Europa quiere poner fin a los ecosistemas cerrados

    Europa quiere poner fin a los ecosistemas cerrados

    Desde siempre, nos hemos encontrado en el dilema de la elección del ecosistema. Seguro que les suena la eterna batalla: Windows vs. Linux, Mac vs. Windows, etc. Estas decisiones han llegado a los accesorios y aplicaciones que todos usamos y ese dilema de elección ya ha pasado a incluir a prácticamente todo el mundo: IOS, Android, Amazon, Apple, Microsoft, Linux o Google. Está claro que alguien que decide por un ecosistema se va a encontrar con un abanico de ventajas en cuanto a integración con otros componentes (software, plugins, accesorios, dispositivos, etc.) de dicho ecosistema, y también muchos inconvenientes si piensas integrarlo con otros ecosistemas competidores.

    La elección de un ecosistema u otro es decisión de cada uno… lo que no es tanta decisión es escoger la forma de comunicarnos, ya que si todos nuestros conocidos utilizan un sistema de mensajería como Whatsapp, básicamente nos están obligando a que también seamos usuarios de esta plataforma. Por suerte, por el momento ser usuario de una plataforma es algo gratuito, pero no lo es tanto si consideramos que nuestros datos son enviados a una empresa o a otra según la plataforma que escojamos. (estamos pagando el servicio con nuestros datos). Por esta razón, Europa se va a poner seria y está planteando una revolución en el ámbito de las comunicaciones al proponer una interconexión obligatoria de las herramientas de comunicaciones mayoritarias que pertenecen a grandes empresas.

    Europa va a presentar, dentro de su nueva «Ley de Servicios Digitales y Mercado Digital» varias propuestas entre la que se encuentra la obligación de interconexión de las Grandes Herramientas de Comunicaciones y multas de hasta el 10% de beneficios anuales en todo el mundo en caso de incumplimiento.

    Queremos asegurarnos que los usuarios tienen acceso a la libre elección de productos y servicios online y que las empresas compitan libremente.
    Las obligaciones vinculantes a nivel de la UE se aplicarán a todos los servicios digitales que conectan a los consumidores con bienes, servicios o contenido.
    El nuevo marco reequilibrará los derechos y responsabilidades de los usuarios, las plataformas intermediarias y las autoridades públicas.

    Esta propuesta aborda las consecuencias negativas de determinados comportamientos de las plataformas que actúan como guardias digitales del mercado único. Evitará condiciones injustas para las empresas y los consumidores y garantizará la apertura de los servicios digitales.

    ¿Cómo?

    – Definiendo umbrales cuantitativos para identificar a las empresas gestoras de los datos.
    – Prohibiendo una serie de prácticas desleales.
    – Exigiendo a los guardianes que implementen de manera proactiva ciertas medidas.
    – Imponiendo sanciones por incumplimiento
    – Permitiendo investigaciones de mercado específicas

    Esto, dentro de la idea que propone la Comisión Europea es, que un usuario de (por ejemplo) Whatsapp, pueda conectar y enviar mensajes a un usuario de Telegram o de Slack y que nosotros podamos desarrollar una herramienta que se conecte con todas y cada una de las redes y que nuestros propios usuarios puedan contactar con todos los de otras redes y, lo más curioso de todo: los grandes sistemas deben permitir esa interconexión: Lo que viene siendo: «interconectar las redes de comunicaciones«.

    Queremos conocer tu opinión:

    ¿Crees que esta ley (que seguramente no les haga mucha gracias a las grandes empresas) conseguirá lo que propone Europa?

    ¿Se podría extender a otros continentes y países para obligar a una interconexión real de las comunicaciones?

    ¿Crees que permitirá la incorporación de nuevos jugadores que no se atreven a meterse en este mercado debido a la gran ventaja de los jugadores actuales?

    Más información: https://ec.europa.eu/commission/presscorner/detail/en/ip_20_2347

    Imagen de portada Valerio Errani en Pixabay

  • Cómo instalar un servidor VPN para teletrabajar en menos de 10 minutos

    Cómo instalar un servidor VPN para teletrabajar en menos de 10 minutos

    Hace tiempo que quería escribir un artículo como este, pero ahora que el Coronavirus está empezando a obligar a muchas empresas a buscar mecanismos para que la gente pueda seguir trabajando desde sus casas, creo que es un fantástico momento para explicar cómo montar un servidor VPN para unas pocas personas y que puedan acceder desde cualquier lugar a la red interna como si estuvieran físicamente ahí.

    Nota importante: Hay que aclarar que esto abre una puerta (aunque sea cifrada) a que las personas del exterior puedan acceder a la red interna de nuestra oficina, que desde Sinologic no nos hacemos responsables de ningún problema de seguridad que pueda ocurrir por culpa de este tutorial y que, aunque para poder acceder es necesario disponer de un certificado creado específicamente para cada sistema, no se recomienda esto para grandes oficinas, si no para pequeñas oficinas de no más de 5 empleados que necesiten trabajar en remoto de vez en cuando. Si quieres un sistema VPN serio instala en condiciones un servidor IPSEC o un OpenVPN en un servidor de verdad con una conexión en condiciones y aplicando las medidas de seguridad necesarias y contramedidas para evitar ataques.

    El objetivo es muy sencillo de entender. Consiste en montar un pequeño servidor VPN dentro de la red interna, utilizando una Raspberry PI como servidor y así evitamos que el coste de un servidor sea un impedimento a los presupuestos organizados de la empresa. Esa VPN hará que podamos conectarnos desde cualquier lugar de Internet al sistema Raspberry y una vez conectado, tener acceso a todos los dispositivos (ordenadores, impresoras, servidores, etc.) de la red interna, así como salir nuevamente por el router de la empresa (por lo que podremos acceder a los sistemas que tengamos filtrados por IP y que únicamente se puedan acceder desde nuestra conexión).

    Qué es necesario

    Necesitaremos:

    • Nuestra oficina deberá disponer de una conexión a Internet con ancho de banda suficiente y dirección IP fija que tendremos que configurar para poder conectarnos a ella cuando queramos acceder.
    • Acceso al router de la oficina para mapear el puerto del OpenVPN y poder acceder desde el exterior.
    • Una Raspberry PI 3 (aunque mejor 4 ya que tiene más potencia, una tarjeta de red Gigabit).
    • Una tarjeta microSD de, al menos 8Gb con la distribución Raspbian.

    Esquema mental de nuestra infraestructura ideal

    Es importante que, tanto la IP interna de la oficina (192.168.1.X) como la IP interna de nuestro lugar remoto (10.10.0.25), sean subredes diferentes, ya que si son iguales puede haber problemas de enrutado y nuestro ordenador no podrá distinguir qué es «local» y qué es «remoto».

    Una vez conectado a la VPN, nuestro ordenador tendrá una IP interna (10.10.0.25) y una IP VPN interna (10.8.0.4) pero tendrá acceso a los ordenadores y servidores de la red interna (192.168.1.X) porque la Raspberry hará de puente.

    Si estamos conectados y queremos acceder a una página web, lo haremos con la conexión de la oficina (el router introducirá nuestros paquetes, lo enviará a la Raspberry y volverá a salir por el router manteniendo la IP de la oficina).

    Instalación del sistema Raspbian

    En la Raspberry PI tendremos que instalar Raspbian, esto es algo básico y sencillo, así como configurarle una IP fija dentro de la red interna, por ejemplo: 192.168.1.248

    Para ello lo mejor es acceder al router y buscar la opción para asignar una IP fija a la dirección MAC de la raspberry PI. De esta manera, aunque la raspberry PI pida una nueva IP, el router siempre le dará la misma.

    Instalar OpenVPN en la Raspberry PI

    Una vez instalada la distribución Raspbian y configurada la IP interna fija en el router, usaremos PiVPN para instalar OpenVPN, por lo que ejecutaremos en la Raspberry PI el siguiente comando:

    curl -L https://install.pivpn.io | bash

    Este comando instalará OpenVPN y hará varias comprobaciones, además de:

    • Pedirnos confirmación de que tenemos una IP interna y fija.
    • El usuario de la raspberry PI que utilizaremos para ejecutar todos esos comandos (por defecto: ‘pi‘)
    • El puerto del router que utilizaremos para conectarnos desde el exterior. (Por defecto, el puerto de OpenVPN es el 1194/UDP aunque es recomendable poner cualquier otro entre 30000 y 60000).
    • También nos preguntará el nivel de cifrado que deseamos tener entre el ordenador remoto y el servidor
    • Los servidores DNS que queremos utilizar dentro de nuestra conexión.

    Una vez hecho esto, ya tendremos un servidor VPN corriendo en nuestra flamante Raspberry PI. Ahora tendremos que crear las «llaves» para que los usuarios puedan acceder al servidor VPN.

    Crear los certificados para los usuarios

    Para crear las llaves (o los certificados) tendremos que, con el usuario por defecto ‘pi’ ejecutar el siguiente comando:

    sudo pivpn add

    Con este comando generaremos en el directorio /home/pi/ovpns un archivo llave (certificado) ARCHIVO.ovpn con todos los parámetros y certificados necesarios de OpenVPN para que alguien pueda conectarse.

    Cada certificado solo puede ser utilizado por una conexión simultanea, por lo que si quieres poder conectarte desde varios sistemas, necesitarás generar dos certificados distintos.

    Todos los clientes, una vez conectados tendrán, por defecto, una dirección IP interna del rango: 10.8.0.X (diferente al del resto de la red interna) pero todos los usuarios conectados podrán verse entre sí.

    Mapear el puerto seleccionado en el router

    Ahora tenemos que acceder al router y mapear el puerto que hayamos configurado en la raspberry para el servidor OpenVPN, de manera que cuando alguien acceda a dicho puerto, se reenvíe a la Raspberry PI. (es necesario que el puerto del router y el que hemos configurado sean el mismo).

    Configurar el cliente

    Cliente para Windows

    Una vez tenemos el archivo certificado con extensión .ovpn, es el momento de instalar un cliente en nuestro sistema operativo y cargarle dicho certificado para que pueda conectarse.

    Para Windows, OpenVPN tiene su propia aplicación OpenVPN Connect que podéis instalar desde aquí: https://openvpn.net/client-connect-vpn-for-windows/

    Para Mac, yo recomiendo TunnelBlick. Se instala, se selecciona el archivo ARCHIVO.ovpn que se desea utilizar y listo!

    Para Linux, tan solo hay que instalar el paquete ‘openvpn’ y ejecutarlo tal que así:

    openvpn –config ARCHIVO.ovpn

    Extras importantes e interesantes

    • Si en lugar de utilizar el puerto 1194/UDP, utilizásemos uno del tipo 80/TCP, podríamos usar esta conexión en aquellas redes que sólo permiten navegar a una web (como algunos hoteles, convenciones, etc.). De esta manera, este sistema nos ayudará a saltar a la red interna y poder navegar con total seguridad aunque la red en la que estemos no permita otro tipo de accesos.
    • Es importante saber que los archivos generados con los certificados de clientes van asociados a la dirección IP y puerto externo a la que nos vamos a conectar, de manera que si la oficina cambia de dirección IP habría que rehacer los certificados o modificarlos manualmente con un editor (ya que es un archivo de texto plano)
    • Si utilizas VPN para cifrar la VoIP (UDP), si para la VPN usas un protocolo TCP, entonces estarás encapsulando todo el tráfico en paquetes TCP, por lo que en VoIP pueden aparecer micro-cortes en el audio en redes de baja y media calidad, además de que para evitar contagiar de Coronavirus, es mejor no hacer handshaking y seguir usando paquetes UDP siempre. 😉
    • Este sistema es el que utilizo para conectarme a la red interna de mi casa desde hace varios años, por lo que puedo garantizar que no sólo funciona estupendamente si no que además es una de las mejores formas de acceder remotamente a la red interna.
    • Hay muchísimas opciones dentro del servidor OpenVPN, pero desde este artículo intentamos explicar brevemente cómo configurarlo para una oficina pequeña y un comportamiento estándar útil que nos facilite el trabajo en remoto ahora que desde el gobierno se está recomendando a las empresas que opten por el teletrabajo para evitar contagios.

  • Qué son las llamadas fantasmas y cómo evitarlas

    Qué son las llamadas fantasmas y cómo evitarlas

    Seguramente os ha ocurrido alguna vez que vuestro teléfono IP ha empezado a sonar tras recibir una llamada extraña de algún número como «1000» o «101» o similar, en cualquier momento, a horas en las que vuestro servidor SIP está configurado para no dejar pasar más llamadas… Lo primero que uno piensa es que hay algún fallo de seguridad, algo que no debía estar pasando o incluso peor, si tenéis un teléfono IP en casa, es recibir llamadas a las tantas de la madrugada.
    Éstas llamadas se conocen como: «llamadas fantasma» y son totalmente inofensivas, aunque sí que pueden llegar a ser bastante molestas. Vamos a ver qué son, por qué ocurren y cómo se evitan:

    Qué son las llamadas fantasmas

    Antes de empezar: Muchas empresas de telemarketing hacen llamadas utilizando marcadores predictivos, que hacen llamadas a clientes esperando que éste conteste y una vez descuelgue, pasar la llamada al agente correspondiente. Si no hay ningún agente disponible en el momento, la sensación es idéntica a la de una llamada fantasma y ahí poco podríamos hacer salvo poner ese número en la lista negra o esperar un poco antes de colgar para saber quién nos llama, o apuntarnos a la Lista Robinson para evitar que nos molesten con publicidad pero efectivamente, esto no es una llamada fantasma.

    Para entender qué son las llamadas fantasmas, tenemos que saber que, cuando un ordenador establece una comunicación otro, abre un socket que no es más que un puerto que se comunica con otro.

    Vamos a ver un ejemplo básico: Petición HTTP

    Cuando nos conectamos a una página web desde nuestro navegador, un puerto de nuestro sistema se abre para enviar información sobre la página web que queremos visitar y nos conectamos al puerto 80 o 443 del servidor (de ahí que el router del servidor web tenga configurada una opción para enviar todas las peticiones del puerto 80 y 443 al servidor web de la red). Por nuestra parte, el router ve que, desde nuestro ordenador se abre un puerto (uno aleatorio, alto, sin mucha fanfarria) y lo abre durante el tiempo que dure la conexión. Hay que recordar que en HTTP, cada página, cada gráfico, cada archivo JS o CSS son conexiones separadas e independientes, por lo que, por cada página que enlaza a un archivo Javascript, un CSS y una imagen, tendríamos 4 conexiones:

    En este caso, el navegador es quien decide utilizar un puerto «aleatorio» para comenzar la conexión, es lo que se conoce como «puerto local» y como es interesante mantenerlo abierto hasta que se recibe el archivo, se utiliza un puerto local por cada archivo que se desea obtener. (Nota: Esto es así en HTTP1, en HTTP2 funciona diferente).

    En VoIP, al igual el puerto local es seleccionado como aleatorio por el propio navegador, en SIP el puerto local lo controla el teléfono y como es UDP y no tiene que esperar a recibir una petición para enviar otra, ya que todo el tráfico SIP se puede enviar en la misma conexión, únicamente se utiliza el puerto local definido por el teléfono. Por una razón de estándar, cada dispositivo o software SIP debe utilizar el puerto 5060/UDP, de manera que la conexión se pueda hacer directamente conociendo la IP, de manera que si encontramos un dispositivo con el 5060 abierto, debemos entender que entenderá SIP, por lo que si le enviásemos un paquete SIP con un INVITE a ese dispositivo, en teoría, debería empezar a sonar o redirigirla a donde esté configurado para hacerlo.

    Si nuestro teléfono tiene configurada una cuenta en un operador IP o en un servidor SIP remoto es normal que, de vez en cuando, se intercambien paquetes a fin de mantener la conexión (OPTIONS, REGISTER, etc.) y si, por lo que hemos explicado antes, tiene configurado el puerto SIP local con el 5060, nuestro router también abrirá ese puerto para mantener la conexión.

     

    Como podéis ver, en nuestro router también se abre el puerto 5060 para enviar el paquete a nuestro servidor SIP.
    Ahora bien… como también sabréis, existen numerosos bots que escanean Internet completamente buscando sistemas VoIP vulnerables, por lo que en cuestión de minutos pueden tener una lista de todos los ordenadores con el puerto 5060 abierto. Si encuentran una IP externa con ese puerto, intentan enviar un paquete INVITE para comprobar si es vulnerable…

    Por lo que nuestro teléfono recibirá una llamada. Está claro que es completamente inofensiva, ya que nuestro teléfono no puede procesar la llamada más allá del auricular y si descolgamos no escucharemos nada, ya que el bot no envía audio únicamente señalización, pero es bien molesto.

    Cómo evitar las llamadas fantasma

    Para evitarlas, tenemos la forma más sencilla que es entrar en la configuración de nuestro teléfono y modificar el parámetro SIP LOCAL para cambiar el puerto del 5060 a cualquier otro. Esto cambiaría el puerto con el que saldremos (no al que nos vamos a conectar) y de esa manera el bot seguramente no nos detecte y nos ahorraríamos esa molesta llamada.

    Otra posibilidad es activar la opción que tienen algunos teléfonos para evitar recibir INVITES de otros dispositivos que no sean el servidor SIP al que estamos conectados.

    Sea de la forma que sea, las llamadas fantasmas son tan habituales como la propia Voz sobre IP y por lo tanto evitarla está de nuestra mano.

  • Cisco vende Linksys

    WRT54G Linksys Cisco Belkin

    A través de twitter y algunos medios, nos hacemos eco de una de las noticias que seguramente formará parte de los titulares de este nuevo año que acaba de comenzar: Cisco vende Linksys a Belkin.

    Para todo aquellos que sigan Sinologic, sabrán que uno de los teléfonos VoIP más conocidos son los Linksys que, tras la unión con Cisco pasaron estratégicamente a llamarse Cisco SPA xxx , por lo que dejaron a Linksys las gamas de productos relacionadas con la electrónica de red doméstica (routers, switches, wireless, access points, plc, etc…) por lo que la venta de Linksys no afectará a la VoIP en absoluto.

    No obstante, esta compra es muy interesante, ya que Belkin (una compañía bastante conocida por fabricar routers, switches, y demás productos domésticos) ha sido la interesada en adquirir Linksys haciéndose con el 30% del mercado estadounidense compuesto por hogares y pequeñas empresas.

    Aún tras la compra, Belkin ha asegurado que, además de estar muy orgullosa de haber adquirido Linksys, mantendrá el nombre comercial, así que seguiremos viéndola, eso sí, dejará de estar relacionada con Cisco.

    Más información: http://www.belkin.com/us/pressreleases/8798355522620

  • El proyecto Guifi.net ya cuenta con su red de VoIP completa

    Llevo algunos meses siguiendo muy de cerca la evolución de la siguiente fase del proyecto Guifi.net consistente en desarrollar una infraestructura de VoIP capaz de dar servicio a todos los usuarios de este «proveedor ciudadano» a través de nuestro colega Alex Casanova (Bicubik)

    Para el que no conozca este movimiento, Guifi.net es un operador de telecomunicaciones creado por «sus usuarios» y cuando nació el proyecto Guifi.net, una alternativa libre a Fon no dependiente de ninguna empresa, siempre me gustó el proyecto.

    Pues resulta que tras varios meses de desarrollo de su infraestructura, parece ser que por fin ya tienen la primera parte del proyecto de VoIP consistente en 15 servidores Asterisk conectados entre sí por un servidor Kamailio.

    Cada usuario de Guifi.net dispone de un número VoIP con una numeración «geográfica» propia (70XXXXXXX) por lo que, al ser proveedor oficial, pueden ofrecer este servicio.

    Si queréis saber algo más, si os interesa este proyecto, sólo tenéis que entrar en su página web e informaros:
    http://guifi.net/es

  • Adiós IPv4… ahora hay que actualizar

    Llevo unas cuantas semanas poniéndome al día gracias a algunos comentarios en la red en los que llevaban la cuenta al minuto de las direcciones IP que quedaban, visitando tutoriales y preparando todo el sistema para utilizar IPv6.

    Hoy, día 1 de Febrero, salta la noticia: ya no quedan direcciones IPv4: se han agotado (faltan 5 bloques por asignar que son reservados para casos especiales).

    ¿Qué significa eso? Los operadores disponen de una reserva para asignárselo a los nuevos clientes, pero aún así, si el número de usuarios crece, también se agotarán y empezaremos a ver la «profesionalidad» y la «preparación» de estos operadores (proxyes, redes NAT, pseudo-direcciones IP detrás de gateways, y demás chapuzas es muy probable que aparezcan en breve) y es que los operadores españoles si están preparados para IPv6, dudo mucho que lo estén para ofrecerlo a los usuarios, por que son los mismos usuarios los que no están preparados.

    Algunas voces que venían advirtiendo del fin de la red tal y como la vemos hoy día, son consideradas como apocalípticas y por muchas facilidades a la hora de explicar cómo utilizar IPv6, son pocas las personas que se lo han tomado en serio (yo entre ellos) hasta que ha sido demasiado tarde y la amenaza es inminente. ¿Qué ocurrirá ahora? ¿Qué aplicaciones son compatibles con IPv6? Vinton Cerf, uno de los creadores de Internet lo dejaba claro la semana pasada: «Todo es mi culpa, nunca pensamos que las direcciones IP se terminarían agotando». Quizá en mucho tiempo no haya 4.200 millones de sistemas conectados de forma simultanea, pero está claro que las direcciones IP fijas aumentarán su valor por su «falta de oferta», y los operadores intentarán evitar o al menos, rentabilizar el hecho de que un sistema esté encendido 24 horas consumiendo Internet (esto es algo que los operadores ya han empezado a planificar con sus críticas a las tarifas planas y creando «planes de datos» en lugar de ofrecer una conexión para un sistema 24 horas al día 365 días al año.

    No obstante, como comenta Olle Johansson en su blog, lo más crítico no sea que las redes no estén preparadas para IPv6 (porque sí lo están), si no que el verdadero problema está en la preparación del propio usuario acostumbrado a utilizar nombres DNS que apuntan a direcciones IPv4, utilizar aplicaciones antiguas que no son compatibles con IPv6 y aquellos usuarios más técnicos tengan que aprender a utilizar y configurar routers para direccionar IPv6. ¿Cuantas webs de empresas funcionan en IPv6?

    (más…)

  • Neutralidad de la red: «Las redes son nuestras…»

    Neutralidad de la red: «Las redes son nuestras…»

    Este fin de semana, de forma opaca y unilateral, las operadoras que ofrecen internet a los usuarios (Telefónica, Vodafone, Orange, Jazztel, Ono y BT) han vuelto a incumplir la ley europea de defensa de la competencia al acordar eliminar las tarifas planas a Internet del catálogo de ofertas para el consumidor, de forma que cada usuario de Internet pague la conexión en función de la cantidad de tráfico que utilizará y todo tráfico excedido, se pagará a parte. Esta es la noticia que había escuchado este domingo y hoy podía leer en BandaAncha (salvo por la parte de la CMT que parece ser no estar ni a favor, ni en contra).

    Para empezar, el hecho de desaparecer la tarifa plana, representa sin duda un ataque directo ante la neutralidad de la red: un acuerdo mediante el cual se indica que todo tráfico que circule por internet debe ser tratado por igual, independientemente de si es parte de un email, una foto, un vídeo o una conversación de audio. Que desaparezca la tarifa plana es una patada a todo el progreso y avance que se consiguió tras luchar y exigir una tarifa plana real a manos de Telefónica -ahora Movistar– (antigua empresa monopolio cuya infraestructura fue pagada con los impuestos de todos los españoles). Fue entonces cuando se liberó y privatizó por lo que empezaron a aparecer nuevas empresas de telecomunicaciones que ofrecían una competencia suave y nada ofensiva ya que, como he comentado, lainfraestructura de telecomunicaciones pertenecía a Telefónica.

    Viñeta de Manel Fontdevila

    (más…)

  • El Gobierno quiere promover el software libre en la Administración

    El Gobierno quiere aprovechar la nueva ley de acceso electrónico de los ciudadanos a los servicios públicos para impulsar en las administraciones públicas una amplia adopción del software de código abierto (o software libre) frente a soluciones propietarias (de pago por licencias).

    Una iniciativa que perjudica directamente al negocio de Microsoft, cuyos programas cuentan hoy con una destacada presencia en algunas comunidades autónomas españolas –sobre todo, en aquellas regiones consideradas más ricas o industrializadas–.

    La ley, que entrará en vigor en enero de 2010, reconoce el derecho de los ciudadanos a relacionarse con la Administración por medios electrónicos.

    Además, regula los aspectos básicos de la utilización de las tecnologías de la información en la actividad administrativa, en las relaciones entre las distintas administraciones públicas, y en las comunicaciones entre organismos y ciudadanos.

    A efectos prácticos, las instituciones deberán colgar todos sus servicios en la red para que sean accesibles a los ciudadanos. Esto implica que muchos organismos deben acometer una importante labor de modernización tecnológica, que abre la puerta al empleo del software libre.

    Gracias por el aviso a : Manuel Marroyo

  • Vulnerabilidades de base

    Hace un par de meses, leía estupefacto cómo habían descubierto una vulnerabilidad en el mismísimo protocolo DNS que ponía de manifiesto que cuando algo es bueno, nadie lo mira.

    Pues si el DNS fue ámpliamente criticado por dicha vulnerabilidad y poner en peligro toda la infraestructura de nombres en Internet, ahora aparece algo aún más difícil de entender: una vulnerabilidad en el mismísimo protocolo TCP/IP.

    Esta vulnerabilidad permitiría a un atacante desconectar cualquier cosa conectada a la red.

    Se ha especulado bastante sobre lo que se podría hacer, a quién podría afectar y que repercusiones podría tener este descubrimiento, es por eso por lo que la gente de Hispasec han elaborado un FAQ sobre esta vulnerabilidad para aclarar un poco más este desastre.

    Podeis ver el artículo en su web: http://www.hispasec.com/unaaldia/3632

  • Nimbuzz: competencia directa a Fring

    Acabo de leer que Nimbuzz acaba de lanzar una aplicación para móviles que casualmente permite conectarse a las mismas redes que Fring y aunque las comparaciones son odiosas,

    Fring tiene como ventaja en que es el único softphone compatible SIP para el iPhone.
    Nimbuzz tiene como ventaja que dispone de una aplicación para PC y MAC que se conecta a su red.

    Nimbuzz tiene en contra que el cliente para móviles está en Java y aunque bastante compatible (22 marcas de teléfonos), no todos los terminales soportan Java y si lo hacen, la estabilidad y la velocidad dejan mucho que desear.
    Fring está programado en lenguaje nativo para más de 35 marcas y más de 300 modelos de teléfonos móviles y pdas lo que lo hace bastante más rápido y estable.

    Qué quereis que os diga… competencia dura y directa…