Categories
General

Problemas de TCP/IP

Con este apunte vamos a poner en práctica la técnica de aprendizaje denominada “Caza del tesoro”. Vamos a recopilar información sobre un tema, en concreto sobre la seguridad de TCP/IP, y a comentar las propuestas que vamos encontrando.

Todos sabemos que TCP/IP con IPv4 presenta diversos problemas de seguridad. La idea es que cada uno aporte un comentario referente a cada uno de los problemas que presenta TCP/IP para con IPV4.

EL comentario debe consistir en: Nombre del problema, Implementación en la que se produce (o todas), Descripción de la posible solución, dónde reside la ventaja y cómo se consigue.  Cada comentario debe incluir una referencia a la fuente de información consultada (URL, libro, …)

Por supuesto, también debatiremos los problemas que aportemos, sobre todo sin presentan más problemas de los comentados …

By airc

Blog de la asignatura de Administración e Instalación de Redes de Computadores.
Se ha creado con la finalidad de convertirse en una herramienta útil para, en particular, todos los alumnos de la asignatura y, en general, para todos los interesados en temas de gestión y administración de redes de computadores

36 replies on “Problemas de TCP/IP”

Jack C. Louis y Robert E. Lee de la empresa de seguridad Outpost24 informaron el dia 2 de este mes de un problema genérico del protocolo TCP.

El problema fue encontrado de casualidad cuando realizaban un test de vulnerabilidad a unas maquinas.

Por error, al programar su propia pila TCP/IP, y una vez habian establecido una conexión TCP “atacante” y “victima” (Despues de SYN, ACK y SYN/ACK), el atacante le mandaba un falso error de “Buffers llenos” asi que la victima espera a que el atacante libere sus buffers (cosa que no hará).

De esta manera es posible crear un ataque DoS sin apenas usar recursos creando muchas sesiones y manteniendo a la victima en espera, sin consumir recursos ya que realmente el error de buffer lleno es falso, para colapsar a la victima.

Por ahora este problema no tiene solución, salvo bloquear conexiones de una máquina atacante, pero aun así sigue siendo vulnerable a un ataque DDoS.

Enlace de referencia:
http://seguridaddescifrada.blogspot.com/2008/10/sockstress-dos-encontrado-en-la-pila-de.html

Enlaces de interes:
Ataque DoS: http://es.wikipedia.org/wiki/Ataque_de_denegaci%C3%B3n_de_servicio

Ataque DDoS: http://es.wikipedia.org/wiki/DDoS

Nombre: Sockstress

Implementacion:
Jack C. Louis y Robert E. Lee de la empresa de seguridad Outpost24 informaron el dia 2 de este mes de un problema genérico del protocolo TCP.

El problema fue encontrado de casualidad cuando realizaban un test de vulnerabilidad a unas maquinas.

Por error, al programar su propia pila TCP/IP, y una vez habian establecido una conexión TCP “atacante” y “victima” (Despues de SYN, ACK y SYN/ACK), el atacante le mandaba un falso error de “Buffers llenos” asi que la victima espera a que el atacante libere sus buffers (cosa que no hará).

De esta manera es posible crear un ataque DoS sin apenas usar recursos creando muchas sesiones y manteniendo a la victima en espera, sin consumir recursos ya que realmente el error de buffer lleno es falso, para colapsar a la victima.

Solución:
Por ahora este problema no tiene solución, salvo bloquear conexiones de una máquina atacante, pero aun así sigue siendo vulnerable a un ataque DDoS.

Enlace de referencia:
http://seguridaddescifrada.blogspot.com/2008/10/sockstress-dos-encontrado-en-la-pila-de.html

Enlaces de interes:
Ataque DoS: http://es.wikipedia.org/wiki/Ataque_de_denegaci%C3%B3n_de_servicio

Ataque DDoS: http://es.wikipedia.org/wiki/DDoS

AGOTAMIENTO DE DIRECCIONES IP PUBLICAS
Un problema típico que tiene IPv4 es que se están agotando las direcciones
IP públicas.

IMPLEMENTACION EN LA QUE SE PRODUCE
Al existir tantas máquinas conectadas a la red, se produce un agotamiento de
direcciones. Ordenadores de sobremesa, teléfonos móviles, dispositivos integrados, host virtuales…
Las direcciones IPv4 solamente disponen de 32 bits.

SOLUCIONES
Una solución es que varios ordenadores de una red de área local (LAN) puedan
compartir una única dirección IP pública en Internet (NAT)
Otra de las alternativas, aunque se está implantando muy lentamente, es el
IPv6.

VENTAJAS Y COMO SE CONSIGUEN
IPv6 está previsto que sea la solución a largo plazo para la escasez de direcciones IPv4.
IPv4 utiliza 32 bits, mientras que IPv6 utiliza para las direcciones 128 bits, lo cual
aumenta considerablemente las combinaciones.

http://es.wikipedia.org/wiki/Agotamiento_de_las_direcciones_IPv4

Nombre (dado por los autores): “TCP sockstress vulnerability” and “TCP state table manipulation vulnerability”. Se trata de un ataque del tipo DDoS (Distributed Denial of Service), que básicamente persigue “tumbar” equipos conectados a la red

La vulnerabilidad se produce en todas las implementaciones de la pila TCP/IP, aunque bajo unas circunstancias concretas (no es fácilmente reproducible y algunos equipos responden mejor que otros a este fallo). Los investigadores (la compañia finlandesa outpost24) han conocido este problema desde 2005. Según dicen, no han podido encontrar por el momento una solución válida, pero tampoco quieren difundir los detalles por el peligro que supondría el conocimiento público. (Se iban a dar más detalles en una conferencia a mediados de octubre en Finlandia, pero finalmente no se han hecho públicos como medida de seguridad y se colabora con empresas como cisco para intentar arreglar estos fallos en los equipos)

El problema, es el siguiente (directamente del enlace más fiable en inglés, aunque se trata de una ligera especulación cogiendo la información que se ha ido filtrando): A TCP stack tries to figure out the maximum speed of your connection, in order to slow down data transmission so that packets won’t be dropped. One technique they describe is to behave as if their connection were getting slower and slower to the point that the TCP stack is tricked into believing it will take years to complete the transmission of data. This forces the TCP stack to keep trying for years to send just a few bytes.

Enlaces:
http://www.hispasec.com/unaaldia/3631/supuesta-vulnerabilidad-protocolo-pone-nuevo (donde conocí la noticia vía meneame.net)
http://www.heise-online.co.uk/security/Speculation-surrounds-DoS-vulnerability-in-the-TCP-protocol–/news/111651
http://blog.robertlee.name/ (blog de uno de los investigadores)

Cuando hablamos de vulnerabilidades del protocolo TCP/IPv4 debemos hablar de unas de las primeras conocidas (ya por la década de los 80 era discutida aunque solo de forma teórica): el IP Spoofing.
El IP Spoofing consiste en un atacante haciendo pasar por otra maquina que no es la suya realmente. Esto se consigue porque el protocolo TCP/IPv4 asume que la dirección IP recibida en el paquete, es la misma que la IP de la maquina que lo envía, no se realiza ningún tipo de autenticación, y por lo tanto el atacante puede falsear esa la IP de origen fácilmente. El error es más grave aún si tenemos en cuenta que muchos protocolos o aplicaciones de capas superiores hacen la misma suposición.
Por otra parte debemos tener en cuenta que este ataque por si solo únicamente conseguiría establecer una conexión unidireccional con el receptor, ya que éste enviaría la información a la dirección IP que ha sido falseada y no a la real del atacante, por lo tanto este ataque debe combinarse con otro si el objetivo del atacante es establecer comunicación completa con el host remoto.
Otro uso de este ataque muy extendido es el de denegación de servicio, ya que al utilizar las IP falseadas (las de los equipos de la red remota) se consigue complicar un poco más la defensa ante este tipo de ataques.
En Ipv4 no hay una solución nativa para este tipo de problema. La solución pasa por realizar la autenticación que el protocolo TCP/IPv4 no realiza y, afortunadamente, en el nuevo protocolo TCP/IPv6 si se ofrecerá una forma de autenticación estandarizada.

Referencias:
http://www.governmentsecurity.org/archive/t1753.html
http://www.linuxsecurity.com/resource_files/documentation/tcpip-security.html
http://www.securityfocus.com/infocus/1674
http://articles.techrepublic.com.com/5100-10878_11-1059598.html

Vaya, acabo de fijarme que Carles Cerezo publicó la misma vulnerabilidad que yo (y antes). Qué extraño, cuando entré al blog me ponía que no había comentarios, así que lo siento por el enlace duplicado, aunque al menos los enlaces sean distintos y completemos un poco más la información.

Uno de los agujeros de seguridad más fascinantes fue el que por primera vez describió R.T. Morris de los Laboratorios AT&T Bell en el año 1985. Es conocido como “TCP Sequence Number Prediction”. Él usó una predicción del número de secuencia TCP para construir una secuencia de paquetes TCP sin nunca recibir respuestas por parte del servidor. Esto le permitió atacar a una máquina segura en una red local.

La secuencia de establecimiento de conexión TCP normal necesita de un saludo de 3 pasos. El cliente selecciona y transmite un número de secuencia inicial ISNc, después el servidor lo reconoce y envía su propio número de secuencia ISNs, y entonces el cliente lo reconoce. Después de estos 3 mensajes, la transmisión de datos puede tomar lugar. Supongamos que hubiera un intruso que predijera ISNs. En ese caso podría enviar una secuencia que le permitiera hacerse pasar por un determinado host. De esta manera el servidor envía los datos al intruso cuando en realidad piensa que los está enviando al host original. Si el intruso realiza este ataque en una conexión que permite ejecutar comandos, éste entonces puede enviar comandos maliciosos al servidor.

Morris describe formas de predecir el número aleatorio ISN dependiendo de la implementación de cada sistema, en especial de los sistemas Berkeley.

Defensas.

Obiamente, la clave de este ataque es el relativamente tosco ritmo de cambio del número de secuencia inicial en los sistemas Berkeley. La especificación TCP requiere que esta variable sea incrementada aproximadamente 250.000 veces por segundo, Berkeley está usando un ritmo mucho más lento. De todas maneras, el factor crítico es la granularidad, no el ritmo medio….
Una solución a los ataques clásicos de número se secuencia está descrito en la RFC 1948. Usa una función hash cryptográfica para crear un espacio de secuencias separadas para cada “conexión”, una conexión como está definida por RFC 791, una única 4-tupla .

Extraido de: R. T. Morris. A weakness in the 4.2BSD unix TCP/IP software.
Computing Science Technical Report 117, AT&T
Bell Laboratories, Murray Hill, NJ, February 1985.

El abuso de los mecanismos de encaminamiento es probablemente el ataque más simple basado en protocolos disponible. Hay una variedad de vías para hacerlo, dependiendo del método de encaminamiento usado.

El mecanismo más fácil para abusar es el IP source routing. Asumiendo que el host objetivo usa el inverso de la fuente de ruta siempre que se produce una petición de apertura TCP para retornar el tráfico. Este comportamiento es completamente razonable; si el creador de la conexión desea especificar un camino particular por alguna razón- ej. la ruta automática ha caido- las respuestas podrían no alcanzar al creador si un camino diferente es seguido. El atacante puede entonces escoger cualquier dirección fuente IP que desee, incluyendo la de una máquina segura en la red local objetivo. Cualquier servicio disponible para la máquina objetivo puede ser alcanzado por el atacante.

Defensas.

Es bastante difícil la defensa contra esta clase de ataque. La mejor idea sería que los gateways de una red local rechazaran los paquetes del exterior que dijeran que provienen de la red local.Esta es la menos práctica pues algunos adaptadores Ethernet reciben sus propias transmisiones, y de esta característica dependen algunos protocolos de alto nivel. Más allá, esta solución falla si una organización tiene 2 redes seguras conectadas con un backbone.
Un método más simple podría ser rechazar conexiones autorizadas si información “source routing” estuviera presente. Una variación de esta defensa es analizar la “source route” y aceptar solo si gateways que sabemos seguros están en la lista.
La opción más común hoy en día es rechazar paquetes con información de fuente de ruta en los routers fronterizos. Source routing se permite en el backbone, los ISPs la usan para ver los caminos desde diferentes posiciones ventajosas.

Fuente: http://www.cs.columbia.edu/~smb/papers/

Ip spoofing
Despues de escribir todo esto, me he dado cuenta que ya se ha hablado un post anterior, de todas manestas, la solucion propuesta k pongo es diferente, y sin necesisdad de utilizar el protocolo tcp/ipv6

El spoofing consiste en que los atacantes falsean el origne de los paquete engañando a la victima, haciendole creer que es un equipo de confianza o autorizado. Con ello se consigue saltarse los firewall, y total libertad para acceder recursos de la victima.

Como medida estandar de seguiradad, para evitar el spoofing es obligar a que todo el trafico de la red sea encriptado y /o autentificado.. Mediante el protocolo IPsec se puede evitar eso, para ello deberemos habiliar los servicios de IPSec a los equipos afectados. Con ello conseguiremos que ningun atacante consiga los numeros ISN y por consiguiente no podrá usurpar la identidad de la victima.

IPSec: http://www.bujarra.com/ProcedimientoIPSec.html
Spoofing: http://www.lcu.com.ar/spoofing/
http://es.wikipedia.org/wiki/Spoofing

Iñaki, a veces, según determinadas circunstancias, los comentarios se quedan pendientes hasta que los apruebo y, cuando esto ocurre, se publican con la fecha y hora en la que fueron escritos. No es extraño 😉
No hace falta poner los problemas nuevos (como el que comenta Iñaki y Carles) también podéis poner de los clásicos.
David: El problema del agotamiento de direcciones, no es un problema de seguridad. Busca otro.

Nombre: Ping of Death

Descripción: Conocido como ping de la muerte, este ataque se basa en enviar un paquete de ping (ICMP echo request) de un tamaño muy grande. Teniendo en cuenta que el tamaño máximo de paquete en TCP/IP es de 64 Kbytes (65535 bytes), la implementación de la pila TCP/IP asigna un buffer en memoria de este tamaño. En el caso de que la información sea mayor, el buffer puede desbordarse. El resultado obtenido en muchas ocasiones es que el sistema destino deja de proveer servicio al bloquearse, ya sea rearrancándose (reboot) o incluso apagándose (shutdown). Lo que sucede realmente es que el paquete emitido es fragmentado, a nivel IP, en las redes intermedias, los fragmentos van siendo encolados en el sistema destino hasta que se reciben los ultimos pedazos (un paquete de 65536 bytes es suficiente), que son los que desbordan el buffer, provocando un comportamiento anómalo. Hay que tener en cuenta que los SS.OO. actuales no permiten al cliente de ping enviarlo, obteniéndose respuestas como “ping:illegal packet size”. Para realizar éste ataque es necesario disponer de una herramienta que lo implemenmte o modificar el límite impuesto en el código fuente del cliente de ping, por ejemplo en Linux.

Solución: La solución generada por los fabricantes de las implementaciones se basó en la generación de modificaciones en la pila TCP/IP. En el caso de no disponer de un parche asociado al S.O., el ataque puede evitarse filtrando los paquetes ICMP en el firewall de entrada. Una solución aún más detallada es filtrar únicamente los paquetes ICMP fragmentados y no todos, ya que otros protocolos pueden emplear paquetes ICMP para otros propósitos.

Referencia:
http://www.rediris.es/cert/doc/segtcpip/Seguridad_en_TCP-IP_Ed1.pdf

Ataques por validación de entradas

Os puedo asegurar que no es nada difícil modificar las tramas a voluntad del
cibercriminal.
Los ataques por validación de entradas intentan enviar datos que la aplicación no espera recibir. Normalmente, una aplicación realizará algún tipo de comprobación para comprobar la entrada de usuario. Esta comprobación intenta asegurar que los datos de usuario son útiles.
Cada solicitud GET Y POST es un claro objetivo para ataques por validación de entradas.
Un claro ejemplo de este tipo de ataques es la inyección SQL.

Defensa: El cliente está bajo el control total del usuario. Todos los datos que recibe y que envía el explorador Web se pueden modificar. Por tanto, en el servidor se debe efectuar una validación de entradas apropiada, fuera del control del usuario.

A pesar de todo, el máximo problema de seguridad de hoy día es sin duda la INGENIERIA SOCIAL. Un cibercriminal no utiliza con rigor todas estas técnicas, sino su astucia.
Investiga con paciencia a su víctima, recoge información meticulosamente, “engaña” al personal de la empresa utilizando su inteligencia, y se aprovecha de los errores de los pobres informáticos para llevar a cabo sus
objetivos.

Referencia: “Hackers de sitios web” McGraw-Hill

Nombre: Sniffing.
Descripcion: Un ataque realmente efectivo, ya que permite la obtención de gran cantidad de información sensible enviada sin encriptar, como por ejemplo usuarios, direcciones de e-mail, claves, números de tarjetas de crédito…, es emplear sniffers u olfateadores en entornos de red basados en difusión, como por ejemplo ethernet (mediante el uso de concentradores o hubs). El análisis de la información trasmitida permite a su vez extraer relaciones y topologías de las redes y organizaciones.
Los sniffers operan activando una de las interfaces de red del sistema en modo promiscuo. En este modo de configuración, el sniffer almacenará en un log todo el tráfico que circule por la tarjeta de red, ya sea destinado o generado por el propio sistema o desde/hacia cualquiera de los sistemas existentes en el entorno de red compartido (segmento ethernet). Asimismo, pueden ser instalados tanto en sistemas como en dispositivos de red [SI-1] [SI-2].
La efectividad de esta técnica se basa en tener acceso (habitualmente es necesario además disponer de dicho acceso como administrador o root) a un sistema interno de la red; por tanto, no puede ser llevado a cabo desde el exterior. Antes de la instalación de un sniffer, normalmente se instalarán versiones
modificadas (trojanos) de comandos como “ps” o “netstat” (en entornos Unix), para evitar que las tareas ejecutadas con el sniffer sean descubiertas.
Cuando los sniffers se emplean para la obtención de passwords, en ocasiones éstos no son necesarios, ya que los administradores de sistemas descuidan los equipos dejándolos configurados con las passwords que por defecto proporcionan los fabricantes [PA-1].
Aparte de los programas independientes existentes para ésta tarea, los sistemas operativos poseen sniffers en las distribuciones comerciales, típicamente utilizados por el administrador de red para resolver problemas en las comunicaciones:
Software general:
– Network Associates Sniffer
– NetXray
– HP Internet Advisor (dispositivo hardware de escaneo)
Software incluido en múltiples sistemas operativos:
– Unix: ethereal
– HP-UX: nettl
– Solaris: snoop
– Linux: tcpdump
– Windows: Microsoft Network Monitor
– Cisco IOS: comandos debug

http://www.rediris.es/cert/doc/segtcpip/Seguridad_en_TCP-IP_Ed1.pdf

Nombre: Net Flood

Descripcion: El objetivo de este ataque es degradar la capacidad de conexión a la red de un sistema, saturando sus enlaces de comunicaciones. Por ejemplo, si el enlace de una organización dispone de un ancho de banda de 34 Mb. y un atacante dispone de un enlace de 155 Mb., prácticamente la totalidad del tráfico cursado por la organización pertenecerá al atacante, por lo que no podrá enviarse tráfico útil.
Para disponer de altos anchos de banda puede recurrirse a la obtención de múltiples sistemas desde los que efectuar el ataque (ver las vulnerabilidades DDoS) o apoderarse de sistemas mal administrados y protegidos que posean redes de gran capacidad, como por ejemplo, los existentes en las universidades.
Las dos técnicas aplicadas en este tipo de ataques se basan en los protocolos ICMP y UDP, al tratarse de protocolos no orientados a conexión y que permiten el envío de paquetes sin requisitos previos: ICMP Flood y UDP Flood.

Solucion: En casos así el primer paso a realizar es el ponerse en contacto con el Proveedor del servicio para que intente determinar la fuente del ataque y, como medida provisional, filtre el ataque en su extremo de la línea.
El siguiente paso consiste en localizar las fuentes del ataque e informar a sus administradores, ya que seguramente se estarán usando sus recursos sin su conocimiento y consentimiento. Si el atacante emplea IP Spoofing, el rastreo puede ser casi imposible, ya que en muchos casos la fuente del ataque es, a su vez, víctima y el origen último puede ser prácticamente imposible de determinar (Looping).

Referencias:
http://www.rediris.es/cert/doc/segtcpip/Seguridad_en_TCP-IP_Ed1.pdf
http://www.segu-info.com.ar/ataques/ataques_dos.htm

Las redes Ethernet presentan problemas de seguridad.
Entre otros, en el protocolo ICMP.

Imaginemos una red montada en switch.

A este switch tenemos conectado un router y tres ordenadores (A: ordenador confidencial, B y C). Evidentemente tanto A,B,C tienen asignado como puerta de enlace por defecto el router.

Por lo tanto, en principio no deberíamos poder capturar el tráfico que circula por la red desde los otros ordenadores hacia el router.

Nosotros estamos en el ordenador C.

Primero instalamos en el PC C un software especial que haga actuar nuestro ordenador como router.

A continuación, malintencionadamente, contruimos un paquete ICMP de tipo redirect (simulando que lo envía el router) y se lo enviamos al PC A, diciéndole que la ruta que está usando para llegar al router no es óptima, sino que los paquetes deberían pasar por nuestro ordenador (y nosotros los rebotamos al router).

Ahahà! Ya estamos capturando el tráfico saliente del PC A sin que este se entere!!!

No sé muy bien si de igual manera se podría hacer para engañar al router y capturar también el tráfico entrante al PC A.

Referencia: yo mismo

Un posible problema de seguridad que te puedes encontrar al administrar una red tcp-ip es el hecho de que se puedan enviar mensajes a través de dicha red de pc a pc, esto puede tener alguna utilidad en principio pero también algún que otro inconveniente. Estoy hablando del comando “net send” que envía mensajes pc a pc o pc a una red completa, en el caso que se enviara un mensaje particular a un pc en concreto no pasaría relativamente nada, pero… ¿qué pasaría si se enviará a toda una red? ¿y si no sólo fuera un mensaje? ¿y si se programará un bucle infinito de mensajes? para este último caso sería tan fácil como editar un archivo .bat en el cual se generase un bucle con el siguiente texto “net send * hola esto es un bucle infinito” donde “*” es toda la red. En problema quizás no parezca muy grave pero no es agradable.
Solución: Una de las posibles soluciones sería desactivar el servicio de net send en cada uno de los ordenadores conectados a la red (herramientas administrativas -> Servicios -> mensajero).
Esto es una ocurrencia que he tenido espero que sea de alguna utilidad en este apartado.
Referencia:
http://www.hard-h2o.com/vertema/17178.html

#15 Dani: no me vales como referencia y, no es por deslegitimarte ni nada por el estilo (seguro que dominas la materia 😉 ) pero no me es válido ese tipo de referencias y más vale no poner ninguna.
Por otra parte, recordad que cualquier equipo conectado a una red informática puede ser vulnerable a un ataque y, aquí, estamos hablando de los problemas que afectan a los protocolos de comunicaciones a todos sus niveles. Además, una definición de ataque que podemos utilizar es decir que un ataque “consiste en aprovechar una vulnerabilidad de una red con propósitos desconocidos por el administrador pudiendo, o no, causar daño.
Los ataques pueden ejecutarse para:
.- obtener acceso al sistema (acceso no autorizado);
.- robar/recopilar información (la escucha que habéis mencionado);
.- simular las acciones de otro (suplantación de identidad del que también habéis dado algún ejemplo);
.- afectar el funcionamiento normal de un servicio (por ejemplo, Denegación de servicio o DoS);
.- utilizar la red de un usuario como un intermediario para un ataque a un tercero;
.- usar los recursos de la red del usuario, en particular cuando la red en la que está ubicado tiene un ancho de banda considerable.

Faltan más, incluso del mismo tipo de los que enumero (por ejemplo distintas formas de DoS). Buscad que no hace falta inventarlos (aunque también me parece bien que lo hagáis, pero siempre argumentando vuestra opinión)

Aunque TCP/IP se ha visto que es muy fiable, no tiene buenas espectativas de futuro. En particular, TCP/IP no sabe distinguir prioridades de tráfico. Por ejemplo, visitar una página web requiere una respuesta inmediata desde que hacemos clic en un enlace, mientras que el envío de correo electrónico puede esperar un poco más. Esta es la razón de que el usuario perciba a veces que “Internet va lento”: realmente la velocidad es algo muy diferente e intervienen muchos otros factores.

Asi que con el tiempo habrá TCP, el problema es que el cambio de IPv4 a IPv6 es muy complejo, ya que la comunidad de Internet ha probado que es muy difícil de afrontar. Los factores para el lento cambio hacia IPv6 giran en torno al hecho de que no hay una obligación de cambiar. Con el tiempo habrá necesidad de cambio, pero deben unirse ciertos factores, como que exista una necesidad urgente, una comunicación formal para el cambio, el apoyo de los grandes fabricantes y una coexistencia con los sistemas actuales durante un cierto periodo de tiempo.

http://www.acens.com/pressroom/tcp-ip-los-pilares-de-la-tierra.html

#19 Dani: creo que no me has entendido. Una cosa es copiar y pegar y otra ponerte a tí como referencia.
Os indiqué en una entrada anterior como Ricardo Galli explicaba brevemente el arte de argumentar:
La estructura de una argumentación es, básicamente:
Hago esta Afirmación por estas Razones basado en estas Evidencias.
Lo que te quería hacer ver antes es que, las Evidencias que os pido estén justificadas (o, directamente sean) mediante referencias. Y esto no es copiar y pegar, sino construir argumentos basados en el estructura anterior.

Vulnerabilidad: SYN FLOOD
Puede saturar/bloquear un equipo objetivo.
El funcionamiento es el siguiente:
El equipo atacante manda una petición de conexión, es decir,un paquete SYN con una IP modificada que no pertenece a ningun equipo. La victima enviará entonces un paquete SYN/ACK de replica a la dirección IP falsa. La petición de conexión queda en la pila a la espera de que se le responda con un paquete ACK. Como la dirección IP a la que se mando el paquete SYN/ACK no existe, la respuesta no llegará nunca. Si en vez de un paquete comenzamos a mandar miles de ellos por minuto, la victima puede llegar a bloquearse.
Posible solución: Limitar el numero de conexiones para una misma fuente. Se puede implementar una pila TCP/IP que espere menos tiempo a que se le responda tras un paquete SYN/ACK para que sea mas dificil saturarla.

http://en.wikipedia.org/wiki/SYN_flood (entre otras)

Nombre: Ping flood
ATAQUE:
Una inundación ping (ping flood) es un simple ataque del tipo DoS donde el atacante abruma (inunda) a la víctima con paquetes ICMP Echo Request (ping). Este ataque se puede utilizar cuando el ancho de banda del atacante es más grande que el de la victima (por ejemplo un atacante con una linea DSL y una víctima con una linea de tipo dial-up). El atacante espera que la victima responderá con paquetes ICMP Echo Reply, de esta forma consumiendo ancho de banda tanto del atacante como de la víctima, aquí es donde interviene la línea DSL en detrimento de la línea dial-up, que se puede quedar atascada. Este es uno de los ataques más fáciles de llevar a cabo ya que no supone demasiados conocimientos en informática.
DEFENSA:
Para reducir los efectos de dicha “inundación” o por ejemplo si recibimos muchas peticiones en poco tiempo, la victima puede utilizar el firewall para filtrar todos los ICMP Echo Request. Si rechazamos mandar los paquetes ICMP Echo Reply obtenemos dos beneficios:
1. No gastamos ancho de banda.
2. Es mas difícil para el atacante darse cuenta de la efectividad de su ataque.
Pero un filtro como este también impide medir el tiempo de latencia, por parte de los usuarios legítimos. Una solución comprometedora seria filtrar solo los paquetes grandes ICMP Echo Request, o delimitar la frecuencia en la que el firewall deja pasar estas peticiones. Nótese que no podemos fiarnos de que el supuesto origen de los paquetes es realmente el origen verdadero de estos, ya que podemos “spoofearlo” para que aparezca que el origen es otro.
Recursos:
http://en.wikipedia.org/wiki/Ping_flood
http://www.iss.net/security_center/advice/Underground/Exploitz/Floods/Ping_Flood/default.htm

Un posible problema a plantear podría ser el MITM (Man in the Middle). No es un ataque como tal a la red sino que tiene más repercusión sobre temas criptográficos, aunque para realizarlo se deba hacer uso de una serie de subataques. El ataque en si consiste en que el atacante adquiere la capacidad para interceptar y modificar mensajes entre dos elementos, sin que ninguna de las dos partes sepa que el mensaje ha sido modificado. Respecto al conjunto de subataques que contempla esta tecnica, se pueden encontrar :

– Intercepción de la comunicación o eavesdropping, incluyendo análisis de tráfico y posiblemente un ataque a partir de textos planos conocidos.

– Ataques a textos cifrados escogidos, en función de lo que el receptor haga con el mensaje descifrado

– Ataques de sustitución

– Ataques de repetición

– Ataque por denegación de servicio (denial of service). El atacante podría, por ejemplo, bloquear las comunicaciones antes de atacar una de las partes. La defensa en ese caso pasa por el envío de periódico de mensajes de status autenticados.

MitM se emplea típicamente para referirse a manipulaciones activas de los mensajes, más que para denotar intercepción pasiva de la comunicación.

La posibilidad de un ataque de hombre-en-el-medio sigue siendo un problema potencial de seguridad serio, incluso para muchos criptosistemas basados en clave pública. Existen varios tipos de defensa contra estos ataques MitM que emplean técnicas de autenticación basadas en:

– Claves públicas
– Autenticación mutua fuerte
– Claves secretas (secretos con alta entropía)
– Passwords (secretos con baja entropía)
– Otros criterios, como el reconocimiento de voz u otras características biométricas

La integridad de las claves públicas debe asegurarse de alguna manera, pero éstas no exigen ser secretas, mientras que los passwords y las claves de secreto compartido tienen el requerimiento adicional de la confidencialidad. Las claves públicas pueden ser verificadas por una autoridad de certificación (CA), cuya clave pública sea distribuida a través de un canal seguro (por ejemplo, a través del explorador de Web o en la instalación del sistema operativo).

No se hasta que punto esto tiene que ver con la red en si, aunque no deja de ser un problema y creo conveniente apuntarlo. Aun así, con los subataques que incluyo, aunque no sea valido el comentario, si que doy pie a explorar nuevas cosas, jejejeje.

Un saludo

Referencias : http://es.wikipedia.org/wiki/Ataque_Man-in-the-middle

Enrique Barreto Ruiz

Nombre del ataque: Smurf

Descripción: El ataque smurf es una técnica del tipo Net Flood; es un ataque de denegación de servicio que utiliza mensajes de ping al broadcast con spoofing para inundar un objetivo (sistema atacado).

En este tipo de ataque, el atacante envía grandes cantidades de tráfico ICMP (ping) a la dirección de broadcast, todos ellos teniendo la dirección de origen cambiada (spoofing) a la dirección de la víctima. Si el router envía el tráfico a esas direcciones de broadcast lo hace en capa 2 donde está la función de broadcast, y la mayoría de los host tomarán los mensajes ICMP de echo request y lo responderán, multiplicando el tráfico por cada host de la subred. En las redes que ofrecen multiples accessos a broadcast, potencialmente miles de máquinas responderán a cada paquete. Todas esas respuestas vuelven a la IP de origen (la IP de la víctima atacada).

Solución: Para evitarlo se debe restringir el tráfico de broadcast desde fuera de la red hacia dentro; en routers Cisco es tan simple como ejecutar la opción de configuración no ip directed-broadcast. También puede ser controlado en las pilas TCP/IP, configurando que no se responda a estos paquetes: En Linux puede controlarse mediante un parámetro de kernel en /proc/sys/net/ipv4 “icmp_echo_ignore_broadcast”. Los sistemas Windows no son vulnerables a este tipo de ataques, ya que siguen el RFC1122 y por tanto no responden a los ICMP broadcast.

Referencias:
http://www.rediris.es/cert/doc/segtcpip/Seguridad_en_TCP-IP_Ed1.pdf
http://es.wikipedia.org/wiki/Smurf_ataque

En primer lugar voy a nombrar los ataques DNS y de enrutamiento. La mayoría de los protocolos de enrutamiento como RIP (Routing Information Protocol) o BGP (Border Gateway Protocol) carecen de autenticación, o tienen una muy sencilla. Se trata por tanto de un escenario perfecto para que cualquier atacante pueda alterar las rutas correctas y, falsificando su IP origen, crear una condición DoS. Las víctimas de estos ataques verán como su tráfico se dirige por ejemplo hacia un agujero negro: a una red que no existe.

Los ataques DoS sobre servidores de nombres de dominios (DNS) son tan problemáticos como los anteriores. Estos ataques intentan convencer al servidor DNS, por ejemplo, para almacenar direcciones falsas: cuando un servidor DNS realiza una búsqueda el atacante puede redireccionar a su propio servidor o bien a un “agujero negro”. En los últimos años se han sufrido varias veces ataques a alguno de los servidores “root” DNS de Interne,t colapsando media red y con tiempos de normalización superiores a las 48 horas.
Es importante saber que es un ataque de Denegación de Servicio (DoS) es un ataque que trata de impedir a la víctima de ser capaces de utilizar la totalidad o parte de su conexión de red.
Ahora voy a enumerar los distintos ataques de Denegación de Servicio(DoS) más comunes que existen en la actualidad:
1. En primer lugar, el Ataque de Inundación, este fue el primer servicio de ataque de denegación que existió. El ataque simplemente envía más trafico que la víctima podía manejar. Esto requiere que el atacante tiene una conexión de red más rápida que la víctima. Esta es la más baja tecnología de los ataque de denegación de servicio, y también la más difícil de prevenir por completo.
2. En segundo lugar, el Ping de la Muerte este ataque se basó en un error en el Berkeley pila TCP/IP que también existe en la mayoría de los sistemas que copiar el código de la red de Berkeley. El ping de la muerte era simplemente el envío de los paquetes de ping de más de 65535 bytes a la víctima. Este ataque de denegación de servicio es tan simple como :
Ping-1 86600 victim.org
3. En tercer lugar, el ataque SYN. En el protocolo TCP, handshaking de las conexiones de red se hace con SYN y ACK mensajes. El sistema que desea comunicarse SYN envía un mensaje al sistema de destino. El sistema responde con un mensaje ACK. En un ataque SYN, el atacante inunda el objetivo con mensajes SYN falsa para aparentar ser inalcanzable de las direcciones de internet. Esta llena el espacio de amortiguación para SYN mensajes en la máquina objetivo, la prevención de otros sistemas en la red de comunicación con la máquina objetivo.
4. En cuarto lugar, el ataque Teardrop. Este utiliza la fragmentación del paquete, algoritmo para enviar paquetes dañados a la máquina víctima. Esto confunde a la máquina víctima, y que puede bloquearse.
5. En quinto lugar, el ataque Smuft. El atacante envía un ping a la solicitud una dirección de broadcast en una tercera parte de la red. Este ping solicitud es falsa a aparecer venir de las víctimas de direcciones de red. Cada sistema en la emisión de dominio de los de terceros entonces enviar ping respuestas a la víctima.
6. Y por último, Distributed Denial of Service(DDos), es un ataque de denegación de servicio que está montado de un gran número de lugares a través de la red. Son generalmente montados en un gran número de sistemas comprometidos. Estos sistemas pueden haber sido comprometida por un gusano o que podría haber sido comprometida por ser hackeado manualmente. Estos sistemas comprometidos son genralmente controlados con bastantes sofisticada pieza de cliente-servidor, tales como software Trinoo, trubu Flood Netword. Este tipo de ataque puede ser muy difícil de defender.
Referencia: http://www.tech-faq.com/lang/es/dos-denial-of-service-attack.shtml

ATAQUE A TCP
Lo que sigue a continuación es un experimento y aunque no se refiere explícitamente a nuestro tema de debate (más bien es algo derivado) lo considero de mucho interés ya que tiene que ver con la seguridad, implementación y modo de funcionamiento del TCP.
Stephen Savage y su colectivo de trabajo demostraron que no siempre es el servidor el que “manda” digamos, el que “puede hacer daño” en una red que utiliza TCP, a veces lo puede también hacer el cliente. El experimento consiste en lo siguiente:
Cogido un cliente Linux modificaron muy ligeramente la implementación del protocolo TCP/IP (menos de 30 líneas de código) después demostraron como este cliente podía usarlo para extraer datos de varios sitios web muy importantes que por lo tanto no pueden ser sospechados de colaboración, y con esto monopolizar la red en detrimento de los demás usuarios.
La división de las confirmaciones:
En TCP los datos mandados forman un flujo (stream). Cada paquete manda una parte de los datos, e indica su posición en el flujo. Por ejemplo, el primer paquete podría mandar los datos de 0 a 1000, el segundo de 1001 a 2000 etc. Las confirmaciones por otra parte son “cumulativas” por ejemplo una confirmación que dice “3001” significa “he recibido todos los datos de 0 a 3000, espero datos a partir de 3001 en adelante” de este modo si la confirmación para un paquete se pierde las confirmaciones posteriores la pueden sustituir, reduciendo así el trafico innecesario.
El primer ataque es sorprendentemente fácil, cuando el receptor recibe el primer paquete, digamos los datos de 0-1000, este receptor en lugar de mandar una confirmación mandaría 3 confirmaciones la primera ack 333, la segunda ack 667 y la ultima ack 1000.Esta claro el protocolo queda perfectamente respetado. Cuál es el problema?
El problema es el modo en el cual el emisor tiene que reaccionar ante tal mensajes. Si leemos en el RFC 2581 podemos ver lo siguiente:
“…cuando se recibe un paquete de confirmación, el emisor aumenta su ventana con SMSS (Sender Maximum Segment Size)…”
No nos importa demasiado el valor de SMSS (que se establece al establecer la conexión entre emisor y receptor); lo importante es que mandando varios mensajes de confirmación, el receptor puede ampliar la ventana del emisor casi arbitrariamente! Si por ejemplo elegimos confirmar cada octeto, podemos ampliar la ventana del emisor miles de veces con un único paquete mandado! Que pasa después?

Emisor datos Receptor
-> 0-1000 ack 333
ack 667
ack 1000
-> 1000-2000
-> 2000-3000
-> 3000-4000

Eso es que el emisor aumenta su ventana para cada confirmación recibida, mandando una “lluvia de paquetes de datos” inmediatamente después de recibir las confirmaciones.
Entonces nuestro emisor (el servidor) responderá a nuestras confirmaciones mandando una “ráfaga de paquetes de datos”, que prácticamente se mandan uno detrás de otro, de este modo no da la posibilidad a la red, de mandar señales de congestión (la ventana del emisor crece gradualmente hasta lograr un valor de equilibrio que no produce congestión esto es lo que se llama “slow start”). Lo que se consigue con esto sería, “chupar” del emisor documentos gigantescos casi instantáneamente.
SOLUCION: Lo triste de este ejemplo (que por cierto no es único, a quien le interese puede buscar además información relacionada con “confirmaciones anticipadas y/o confirmaciones duplicadas”, lo que decía… a sí, que no hay ninguna solución a este tipo de comportamiento, bueno habría una que sería cambiar toda la infraestructura Internet, pero como os podéis imaginar eso es imposible a grandes escalas.
Esta solución propuesta por el mismo Stephen Savage sería que el emisor pueda verificar cada mensaje de confirmación que recibe, garantizando que se respetan las reglas, por eso en cada paquete pondrá un número distinto generado aleatoriamente, el cual el receptor (el cliente) tendrá que incluir en su confirmación. También el emisor tendrá en cuenta las confirmaciones recibidas y no aumentará la ventana para las confirmaciones divididas.

Referencias: http://www-2.cs.cmu.edu/~mihaib/articole/tcp/tcp-html.html#SECTION00050000000000000000
Post Scriptum: Si no entendéis rumano ni miréis la fuente de referencia.

Vulnirabilidad: Desincronización durante el establecimiento de conexión.

En esta forma de desincronización, el atacante reinicia una conexión durante el “three-way handshake”.Dspues que el host B manda el paquete SYN&ACK al host A, el atacante gnera un paquete desde el host B hasta el host A en la cual la conexión es, primero, terminada mediante el bit RST, y despues un nuevo “three-way handshake” es iniciado con A identico al original, pero con una secuencia de numeros diferente. El host B, ignora a partir de ese momento los mensajes de A, y A ignora los mensajes de B.

El atacante nunca mas responde con nuevos paquetes, con la secuencia de numeros correcta, mientras que A y B intentan comunicarse. Entre tanto, el atacante puede modificar los mensajes o incluso insertar los suyos propios.

Referencia: http://www.linuxsecurity.com/resource_files/documentation/tcpip-security.html

Voy a reforzar el párrafo de la vulnerabilidad del protocolo de enrutamiento BGP, de la capa de red del modelo OSI, iniciado en el comentario #25.

El problema, reside en un “agujero” de la confianza que establecen los routers BGP entre ellos, de forma que no verifican ni validan las rutas.

Para comprender mejor el problema, vamos a describir brevemente cual es el ámbito de aplicación del protocolo BGP.
El protocolo BGP es utilizado para el intercambio de información entre sistemas autónomos ANS, como por ejemplo ISP’s en Internet, por lo que se entiende que forman una red confiable ya que están registradas de forma oficial. De esta forma se garantiza un bucle de información entre servidores ISP de confianza.

Bien, el problema reside en la posibilidad de crear un paquete BGP manipulado a partir del uso de spoofing sobre la IP real de un router BGP, de forma que reenrutemos a una dirección cualquiera, que siendo falsa podría bloquear la red, o bien creando bucles ciclicos que provocarían colapso en la red.

Esta falla tiene una solución obvia, reiniciar el router que crea la ruta inválida.

Para poder atacar la vulnerabilidad de este escenario, es necesario un par de cosas:

a) Tener acceso a un router BGP reconocido dentro de la red IANA
b) Disponer de gran ancho de banda para evitar que el valor del TTL haga que seleccione otra ruta.

Aquí me surge una duda que propongo como pregunta: ¿Para que se necesita un gran ancho de banda si el protocolo BGP al ser un protocolo de Gateway exterior no usa métricas de ancho de banda, número de saltos o retardo?

http://www.volkanrivera.com/esp/?p=590

Siguiendo en la linea de ampliación de comentarios anteriores, voy a extenderme en una falla de vulnerabilidad sobre servidores DNS.

El problema reside en los servidores de DNS de cacheo. Estos pueden ser suplantados aprovechando las caracteristicas del protocolo UDP, con la finalidad de insertar una ruta “enemiga” hacia un ordenador no autorizado.

Los servidores DNS de cacheo son aquellos servidores de nombre de dominio que usamos en nuestra LAN y que preguntan a los servidores de zona para la resolución de una IP a partir de un nombre, y que posteriormente almacenan en memoria durante un tiempo estipulado para favorecer resoluciones más rápidas.

El mecanismo del ataque sigue los siguientes pasos:

1) Enviar la solicitud de resolución al servidor “víctima”.
2) Seguidamente se envían tramas UDP modificadas sobre dicho servidor, suplantando al servidor de zona.
3) Confirmar la respuesta del servidor.
4) El servidor víctima contestará con la IP “enemiga” sobre la resolución del nombre.

El ataque de esta vulnerabilidad se realiza a través del fishing, inyectando registros de actualización.

La solución inicial propuesta es la de randomizar el puerto de solicitud por el que se realiza al servidor dueño del dominio. Aunque esta solución es vulnerable con tiempo y ancho de banda.

Por lo tanto la solución sería la implementación de servidores de cacheo dentro de la LAN, desplazando el ataque a realizarlo dentro de la propia LAN para evitar la infección de un único servidor de cacheo del ISP, teniendo así que atacar a muchos más servidores y por consiguiente la necesidad de un gran ancho de banda.

http://www.volkanrivera.com/esp/?p=558
http://www.doxpara.com/?p=1237

Las redes de ordenadores se encuentran expuestas a ataques informáticos con tanta frecuencia que es necesario imponer una gran cantidad de
requisitos de seguridad para la protección de sus recursos.

Aunque las deficiencias de estos sistemas se pueden comprobar mediante herramientas convencionales, no siempre son corregidas.

En general, estas debilidades pueden provocar un agujero en la seguridad de l ared y facilitar entradas ilegales en el sistema.

La mayoría de las organizaciones disponen actualmente de mecanismos de prevención y de mecanismos de protección de los
datos integrados en sus redes.

Sin embargo ,aunque estos mecanismos se deben considerar imprescindibles, hay que estudiar cómo continuar aumentando la seguridad a sumida por la
organización)no debería ser suficiente. Debemos pensar que no todos los accesos a la red pasan por el cortafuegos, y que no todas las amenazas son
originadas en la zona externa del cortafuegos.

Por otra parte, los sistemas cortafuegos, como el resto de elementos de la red, pueden ser objeto de ataques e intrusiones.

Una buena forma de mejorar la seguridad de la red pasa por la instalación de mecanismos de detección, capaces de avisar al administrador de la
red en el momento en que se produzcan estos ataques a la seguridad de la red.

Una analogía que ayuda a entender la necesidad de incorporar estos elementos podría ser la comparación entre la seguridad de una red informática y
la seguridad de un edificio: las puertas de entrada ejercen un primer nivel de control de acceso…, de igual forma hay que hecer en la red informatica.

En el siguiente enlace servirá de referencia y propone distintas soluciones.

Me gustaría añadir un tipo de ataque que creo que nadie a nombrado en este hilo:

Se trata del llamado SNORK el cuál paso a explicar a continuación:

Se basa en una utilización malintencionada de dos servicios típicos en sistemas Unix: el servicio CHARGEN (CHARacter GENerator, generador de
caracteres) y el servicio ECHO y realiza lo siguiente:

Se envía una petición falsa al servicio CHARGEN, habiendo colocado previamente como dirección de origen la dirección IP de la máquina que hay que atacar (con el puerto del servicio ECHO como puerto de respuesta). De esta forma, se inicia un juego de ping-pong infinito.

Este ataque se puede realizar con distintos pares de equipos de la red obteniendo un consumo masivo de ancho de banda hasta degradar el rendimiento de la misma. También se puede realizar contra una misma máquina (ella misma se envía una petición y su respuesta) consiguiendo consumir los recursos especialmente CPU y memoria) de este equipo.

¡¡¡INTERESANTE!!!

He de decir que este ataque lo he encontrado dentro de un curso de la Universidad Abierta de Cataluña en su sección de OpenCourseWare.

Se tratan todos estos módulos:

Module 1. Attacks against TCP/IP networks
Module 2. Prevention mecanisms
Module 3. Protection mecanisms
Module 4. Secure applications
Module 5. Attack and intrusion detection mecanisms

Muchas páginas, muy ameno, y encima con licencia GNU Free Document License

La URL de esta joyita es esta:

http://ocw.uoc.edu/computer-science-technology-and-multimedia/advanced-aspects-of-network-security/Course_listing

Un saludo.

La versión 4 del protocolo ip, es decir, IPv4 tiene el problema de que utiliza direcciones ip’s de 32 bits esto ha hecho que se vayan agotando dichas direcciones debido a que cada vez hay más elementos en la red, con lo que esto es un problema a corto plazo ya que llegará el momento no muy lejano en que se agotarán las direcciones y no podremos acceder a la red. La solución a este problema es la versión 6 del protocolo ip, el IPv6 el cual trabajará con ip’s de 128 bits por lo que la cantidad de direcciones aumenta considerablemente. La principal ventaja de cara a la comunicación y a lo mejor no tanto en cuanto a seguridad será que al disponer de tantas direcciones ip se podrá acceder desde un pc a cualquier otro pc del mundo ya que no se trabajará con el modelo NAT actual donde todo pc que esté detrás de un dispositivo oculta su dirección. Esto hará la comunicación más rápida aunque quizás tendrán que implantar nuevos métodos de seguridad más fiables ya que de esta manera los pc’s estarán más accesibles a cualquier individuo.

Referencia:

http://blog.hispasec.com/laboratorio/94
http://www.idg.es/comunicaciones/articulo.asp?seccion=servicios&id=131858

No tengo muy claro si lo que voy a poner yo es lo que han puesto en otros comentarios, pero de lo que voy a hablar yo es del envenenamiento de las DNS para conseguir contraseñas y cosas similares.

Este metodo para conseguir engañar a los usuarios y utilizarlos para otro fines, esta haciendo que hoy en dia sea muy sencillo conseguir contraseñas de las redes sociales como tuenti, facebook, msn mesenger etc.

Este ataque consiste basicamente en hacer creer al servidor DNS que ha recibido la informacion correcta, mientras que lo que ha recibido a sido una informacion envenenada, lo que hace que, que durante el tiempo de cacheado, los usuarios puedan hacer uso del servicio pero controlado en ciento modo por el que ha introducido la informacion envenenada, por lo que toda la informacion pasara primero por el “envenenador” y podra asi coger los parametros que necesite, en nuestro caso las contraseñas de acceso. Ya que el servidor real en ese momento sera el “envenenador” y podra dirigir el trafico a su antojo.

FUENTES

http://www.sahw.com/wp/archivos/2006/03/28/envenanamiento-dns-definicion-y-metodos-de-prevencion/

http://www.shellsec.net/articulo/pharming/

http://es.wikipedia.org/wiki/Carding

Voy a comentar la versión 6 del protocolo TCP/IP. Esta nueva y última versión se hizo dando importancia al tema de la seguridad en internet, ya que la versión 4, no la tuvo mucha en cuenta.

Este cambio se produce básicamente debido a que el actual protocolo TCP/IPv4 se ha quedado obsoleto, y el increíble crecimiento del número de conexiones que se efectúan a Internet ha ocasionado que el número de direcciones IP disponibles esté llegando a su fin.
El nuevo protocolo añade un mayor número de direccionamientos IP pero además trae también consigo muchas ventajas de las que todos nos beneficiaremos.

Como todos sabéis cada usuario particular o empresa que se conecta a Internet debe tener una dirección IP pública única. Pues bien esas direcciones IP se están acabando. Esto sin duda supone un gran problema ya que la carencia de este tipo de indentificadores provocaría la falta de combinaciones para poder dar de alta nuevos servidores, cada día resultaría más difícil contratar nuevos accesos a Internet e imposibilitaría que nuevas empresas se incorporasen al mercado de las tecnologías de la información. La brecha digital existente se agrandaría, sobre todo en algunos países desfavorecidos.

El actual protocolo IPv4, por diseño, ofrece un rango de direcciones IP asignables de 4.294.967.296 Una cifra altísima, sobre todo si tenemos en cuenta que se diseñó en su día para dar acceso a una red restringida a unos pocos. El espectacular crecimiento de Internet ha hecho que esta cifra sea completamente insuficiente.

De echo llevamos ya algunos años “parcheando” el problema de la disponibilidad de direcciones IP. Por ejemplo está el, conocido por todos, uso de servicios NAT (Network Address Translator) que permite canalizar múltiples direcciones IP privadas a través de una única dirección IP pública. Este sistema hasta hace relativamente poco era usado sobre todo por empresas que tenían la necesidad de que todos sus ordenadores tuvieran salida a Internet. Pero de unos años a esta parte, con la extensión de los routers y la presencia de varios ordenadores en el entorno doméstico, el uso de esta posibilidad es una realidad de muchos hogares en todo el mundo. Pero esto no deja de ser una solución temporal que no soluciona el problema.

Según los expertos, de no haber implementado soluciones de este tipo las direcciones IP se habrían agotado en el año 2000. Estos parches que hemos ido aplicando han permitido ampliar en 10 años la necesidad de aplicar una solución más o menos definitiva.

Además de este problema de que los direccionamientos IP se estén terminando está el acuciante problema de la seguridad. Como todos sabemos Internet es un hervidero de amenazas y vulnerabilidades explotadas por unos pocos pero que nos afectan, en mayor o menor medida, a todos. Esto en gran parte se debe a que el actual protocolo IPv4 se diseñó sin tener demasiado en cuenta el tema de la seguridad ya que se pensaba en entornos más o menos reducidos.

http://www.rau.edu.uy/ipv6/queesipv6.htm
http://www.es.wikipedia.org/wiki/IPv6

Responder a amep1 Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *