Funcionamiento del Protocolo TCP/IP

Antes de comenzar con la enumeración de servicios, se describirá brevemente el funcionamiento de varios protocolos que serán especialmente útiles a la hora de abordar esta fase del pentesting. Además, trataremos de enmarcar dichos protocolos, tanto en la pila de protocolos TCP/IP como en el modelo de referencia OSI.

Resumiendo mucho, la pila de protocolos TCP/IP es un estándar de facto que agrupa los múltiples protocolos que intervienen en una comunicación en red, en niveles o capas para favorecer la interoperabilidad de estos y facilitar la labor a los desarrolladores de hardware, de servicios y de protocolos. Es una forma de compartimentar los problemas para abordarlos por separado.

Por su parte, el modelo de referencia OSI (Open Systems Interconnection o Modelo Interconexión de Sistemas Abiertos) es un estándar (ISO/IEC 7498-1) creado en 1980 por la ISO que parte del sistema de capas de TCP/IP y trata de formalizarlo. Para ello, define 7 niveles o capas, describiendo de forma exhaustiva cuáles son las funciones de cada una y cómo se relaciona con sus capas adyacentes.

La capa de red
El objetivo de la capa de red o nivel 3 es conseguir mover los datos de las capas superiores a través de la red. Ofrece un conjunto de servicios realizados por distintos protocolos cuyo objetivo es conseguir que los datos lleguen desde un host origen A a un host destino B ubicado en otra red. Estos servicios pueden sintetizarse en los siguientes:

  • Direccionamiento de dispositivos: permite identificar a cada dispositivo en la red con una dirección globalmente única: la dirección IP.
  • Encapsulamiento / desencapsulamiento: empaqueta los datos de niveles superior en una unidad llamada paquete, que contiene una cabecera con información suficiente para encaminarse por la red de forma independiente.
  • Enrutamiento: consiste en seleccionar la mejor ruta en cada momento para un determinado paquete. Es llevado a cabo por routers.

Dos de los principales protocolos de esta capa son IPv4 e IPv6.

IP es un protocolo que define la estructura de un paquete, de las direcciones IP, y de cómo se procesa un paquete para moverse de un host a otro.

Entre sus principales características, tenemos:
  • Orientado al mejor esfuerzo: en términos de redes, esto significa que el protocolo carece de mecanismos que garanticen la entrega de los paquetes.
  • Es un protocolo sin conexión: no se establece una sesión previa entre hosts: los paquetes simplemente se envían.
  • Independiente del medio físico que transporte los datos (transmisión inalámbrica, fibra óptica, cobre...).
Actualmente coexisten dos versiones de IP: IPv4 e IPv6. La versión IPv4 está definida en el RFC 791 y fue puesta en funcionamiento en 1983 con ARPANET. Se trata de un protocolo maduro y robusto. Sin embargo, una serie de limitaciones relacionadas con su capacidad de escalabilidad, y que comentaremos a continuación, ha motivado el desarrollo y la progresiva implantación de su sucesor IPv6.

En primer lugar, veamos las limitaciones de IPv4:
  • IPv4 usa direcciones IP de 32 bits. Esto limita el espacio total de direcciones a unos 4200 millones aproximadamente. Esta cantidad podría parecer suficiente en la década de los 80. Sin embargo, en un mundo cada vez más conectado, con la irrupción de IoT, dispositivos móviles, etc., resultan insuficientes.
  • Como medida para ahorrar direcciones, surge NAT (Network Address Translation), que permite que múltiples dispositivos en una red usen direcciones IP privadas para la comunicación interna y salgan a Internet usando todos la misma IPv4 pública. Hoy en día es muy común en redes locales. Sin embargo, lo que a priori puede parecer una ventaja, puede suponer inconvenientes:
    • Falta de conectividad de extremo a extremo: NAT oculta la IP de los dispositivos finales. Esto, que puede suponer una primera y básica barrera de seguridad (ya que, a priori, no se puede iniciar una conexión desde fuera a un dispositivo interno), puede ser engorroso para dispositivos que requieran una conectividad completa. En estos casos, hay que recurrir a técnicas como Port Forwarding.
    • Complejidad adicional: NAT introduce también cierto overhead que se traduce en mayor complejidad y latencia.
Sin embargo, pese a que IPv6 está en proceso de implantación, se está produciendo lentamente e IPv4 sigue estando aún muy extendido, especialmente en redes locales. Es por eso que resulta básico su conocimiento.

Paquete IPv4
Un paquete IPv4 tiene el siguiente formato:


La cabecera o encabezado tiene un tamaño mínimo de 20 bytes, ya que consta de 2 partes:
  • Una parte fija de 20 bytes.
  • Un conjunto de opciones que pueden o no añadirse.
La carga útil o payload son los datos encapsulados procedentes o dirigidos a la capa superior o
de transporte.

Una cabecera IP tiene los siguientes campos (cada fila tiene una longitud de 32 bits):


Los campos más importantes son:
  • Versión: 4 bits que indican la versión del protocolo IP usada: 4 o 6.
  • Tamaño de la cabecera o IHL: longitud de la cabecera en palabras de 32 bits. Es consecuencia de no tener una cabecera fija. El mínimo es 5 (5 × 32 = 160 bits o 20 bytes)
  • Longitud total: tamaño del encabezado junto con la carga útil, expresada en bytes.
  • Tiempo de vida o TTL (Time-to-Live): 8 bits. Número de saltos entre routers que puede dar un paquete antes de ser descartado. Cada vez que el paquete es enrutado por un router, este disminuye su TTL en una unidad.
  • Suma de control de la cabecera: checksum de los datos de la cabecera para comprobar si hay errores. Se debe recalcular cada vez que se cambia el TTL.
  • Dirección IP de Origen: 32 bits. IP del host origen del paquete.
  • Dirección IP de Destino: 32 bits. IP del host destino del paquete.
  • Relleno: usado para que el tamaño de la cabecera sea múltiplo de 32. Se rellena con 0.
Paquete IPv6
Ante las limitaciones de IPv4 comentadas anteriormente, el IETF comenzó a buscar una solución, cristalizando en 1998 con los RFC 2373 y 2374 y siendo redefinido en 2003 con el RFC 3513. Entre las principales mejoras de IPv6 tenemos:
  • Mayor espacio de direcciones: las direcciones IPv6 tienen 128 bits, lo que supone alrededor de 1 sextillón. Esto permite, además, prescindir de NAT.
  • Encabezado de paquete simplificado: lo que redunda en un procesamiento más eficiente por parte de los routers y, por tanto, mejor rendimiento.
La cabecera de un paquete IPv6, a diferencia de la de IPv4, es de tamaño fijo. Tiene una longitud de 40 bytes pese a reducir el número de campos respecto a IPv4. Esto es debido al espacio requerido para incluir la IP de origen y la de destino, ambas de 128 bits.


Los campos Versión, Dirección IP origen y dirección IP destino conservan el mismo sentido (aunque no la longitud en caso de las direcciones, que en IPv4). El campo Límite de Saltos tiene una utilidad similar al TTL de IPv4: evitar que el paquete circule indefinidamente por la red. La ventaja aquí es que, al no existir una suma de comprobación o checksum de la cabecera, esta no tiene que calcularse en cada router, mejorando así la eficiencia. Se delega la comprobación de errores a capas superiores e inferiores.

La capa de transporte
La capa de transporte o nivel 4 de OSI es la que hace posible el intercambio de datos entre un host de origen y un host destino. Ofrece los siguientes servicios al nivel de aplicación:
  1. Segmentación y reensamblado de los datos: en el host origen, divide los datos de la aplicación en bloques de tamaño adecuado para ser enviados (segmentación), y se encarga de su reensamblado en el host destino para servirlos a la capa de aplicación.
  2. Multiplexación de conversaciones: se encarga de la transmisión de múltiples conversaciones entre aplicaciones en distintos hosts de manera simultánea a través de un único canal. Esto se consigue a través del número de puerto, que describiremos en detalle a continuación.
  3. Seguimiento de las conversaciones individuales: denominamos conversación a cada flujo de datos mantenido entre una aplicación origen y una aplicación destino. Cada una de ellas está identificada por un socket origen y un socket destino, siendo un socket una combinación de IP + puerto. La capa de transporte se encarga del seguimiento de estas

En la figura anterior se muestra dos conversaciones simultáneas establecidas desde un mismo cliente a distintos servidores. Vemos cómo cada una se define por el conjunto ip_origen:puerto_origen - ip_destino:puerto_destino. Los paquetes de datos de ambos servidores llegan al cliente por el mismo canal, y es la capa de transporte la que, mediante el número de puerto de destino, realiza la multiplexación: la entrega de los datos a la aplicación o proceso que corresponda.

Los dos protocolos más importantes de la capa de transporte son TCP y UDP. Ambos ofrecen transporte de datos de aplicaciones de extremo a extremo, pero con diferentes características. Aunque vamos a detallarlos a continuación, podemos adelantar que:
  • TCP se usará cuando se requiera un servicio confiable: es decir, que los datos lleguen sin errores y en el mismo orden en que fueron enviados.
  • UDP se usa cuando se requiere baja latencia en las transferencias (como DNS), y no es un problema excesivo que algunos paquetes no lleguen en orden (VoIP).
Números de puerto
Los números de puerto son un número de 16 bits que identifica a una aplicación en un host en red. La IANA ha dividido estos números en tres grupos:
  • Puertos bien conocidos: del 0 al 1023. Se trata de puertos asignados a servicios comunes como http, ftp… Por ejemplo, ftp (21 TCP), ssh (22 TCP), dns (53 udp/tcp), http (80), https (443)…
  • Puertos registrados: del 1024 al 4951. Usados por aplicaciones servidoras para conectarnos a ellas. Por ejemplo, OpenVPN (1194 UDP), Oracle DB (1521 TCP), Xbox Live (3074 TCP/UDP)…
  • Puertos privados o dinámicos: del 49152 al 65535. Se asignan dinámicamente a clientes según se necesiten.
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

TCP
TCP o Transmission Control Protocol es un protocolo de la capa de transporte que, además de los servicios ya descritos (seguimiento de conversaciones, multiplexación y segmentación / reensamblaje), proporciona, además:
  • Garantiza la entrega confiable de los datos: es capaz de detectar segmentos perdidos o corruptos y volver a reenviarlos. Además, garantiza que los datos llegarán en orden al destinatario.
  • Proporciona control de flujo: tiene capacidad de regular el flujo de datos para que un servidor rápido no sobrecargue la capacidad de procesamiento de un servidor más lento.
  • Control de la congestión: los extremos en una conversación usando TCP son capaces de detectar la existencia de congestión en la red basándose en datos como paquetes perdidos o retrasos en las entregas. En estos casos, realizar retransmisiones de los datos perdidos puede incluso empeorar el problema, así que, ambos extremos pueden acordar bajar la tasa de transferencia.
Todos estos servicios son posibles gracias a un mecanismo de TCP llamado sesión. En TCP, cliente y servidor inician una sesión antes de iniciar la transferencia de datos. Es por esta razón que se dice que TCP es un protocolo orientado a conexión.

Formato de un segmento TCP
La unidad de datos de TCP se llama segmento. Un segmento encapsula los datos procedentes de la aplicación y les añade una cabecera con el siguiente formato:


Entre otros campos, tenemos:
  • Puerto de origen: de 16 bits. Es el número de puerto del proceso que genera el segmento.
  • Puerto de destino: puerto del proceso destino al que va dirigido el segmento.
  • N.º de secuencia: campo de 32 bits con el que el emisor indica el byte por el que va transmitiendo.
  • N.º de reconocimiento: confirmación por parte del proceso receptor de datos recibidos correctamente. Se trata del número de byte + 1 que el receptor ha recibido con éxito.
  • Longitud del encabezado: necesario, ya que el encabezado puede contener opciones. El tamaño mínimo (sin opciones) son 20 bytes o 160 bits.
  • Bits de control: se trata de un campo de 6 bits, donde cada uno de ellos representa un flag que puede valer 0 o 1, y sirve para señalizar distintos momentos de la sesión. Estos bits son, en orden:
    • URG: indica al receptor que algunos datos del segmento son urgentes.
    • ACK: para reconocer la recepción de datos.
    • PSH: ordena enviar todos los datos almacenados en el buffer.
    • RST: para resetear y terminar la conexión.
    • SYN: para iniciar la conexión.
    • FIN: para cerrar la conexión.
  • Ventana: negociado entre el cliente y el servidor para el control de flujo y de la congestión. Básicamente, indica al servidor cuántos bytes puede enviar antes de que el cliente le mande un ACK de confirmación. Si la red presenta congestión o el cliente tiene baja capacidad de procesamiento, tendrá un valor bajo. Si la red va bien y el cliente acepta los datos sin problemas, su valor va incrementando.
  • Suma de comprobación: valor calculado para comprobar la integridad del segmento.
Inicio y fin de sesión
Como se comentó anteriormente, TCP es un protocolo orientado a conexión en el que se establece una sesión entre ambos extremos antes de iniciar la transferencia de datos, y se cierra al terminar. Para establecer la sesión, cliente y servidor intercambian una serie de mensajes llamado three- way-handshake o apretón de manos de tres vías:


En la figura anterior pueden verse los mensajes intercambiados entre cliente y servidor para establecer una sesión TCP. Para cada mensaje se muestran, entre corchetes, los bits de control o flags activos, y, en la siguiente línea, el valor de los campos N.º de secuencia (seq) y N.º de reconocimiento (ack). En el primer segmento del cliente, el de petición de conexión, se activa el flag SYN y se elige un número de secuencia inicial aleatorio x. El servidor acepta esta petición con un segmento con los flags SYN y ACK activos, iniciando su propio número de secuencia y, y confirmando los datos recibidos del cliente enviando el campo N.º de reconocimiento o ack al valor de x + 1. El cliente envía el tercer y último mensaje del algoritmo para terminar de establecer la conexión activando solo el flag ACK, enviando el número de secuencia x, incrementado en uno, y reconociendo (ack) la recepción de y + 1.

Al igual que existe un procedimiento formal para establecer una sesión, existe para cerrarla. Se trata del algoritmo Four-way-handshake de cierre de sesión TCP, y consta de cuatro mensajes intercambiados entre cliente y servidor en los que primero un extremo solicita cerrar la conexión enviando un mensaje con el flag FIN activado, y, tras aceptarlo, el otro extremo hace exactamente lo mismo.


UDP
A diferencia de TCP, que se conoce como orientado a conexión por esa sesión que se establece al inicio y le permite proporcionar servicios como control de errores, de flujo y congestión, UDP es justo lo contrario: busca un transporte más rápido y ligero de los datos de la capa de aplicación.

Pese a que sigue ofreciendo los servicios de multiplexación, seguimiento de conversaciones y segmentación / reensamblaje, sus características específicas son las siguientes:
  • No se establece una sesión previa.
  • El receptor reconstruye los datos en el orden en que se reciben (no en el orden de envío como en TCP).
  • No se reenvían los segmentos perdidos.
  • No hay control de flujo ni congestión.
Como se verá a continuación, esta reducción de servicios redunda en una cabecera más pequeña. Estas características son requeridas por algunas aplicaciones específicas:
  • VoIP y transmisión de vídeo en directo, ya que son aplicaciones en las que el retraso es más crítico que la pérdida de datos puntuales y en los que la retransmisión de errores no procede.
  • Aplicaciones con solicitudes y respuestas simples: como DHCP o DNS.
  • Aplicaciones que no requieren control de errores ni flujo, ya que lo implementan ellas mismas. Por ejemplo, SNMP o TFTP.
UDP encapsula los datos de la capa de aplicación en unidades llamadas datagramas.

Formato de un datagrama UDP
Como se comentó anteriormente, el encabezado de un datagrama es más sencillo que el de TCP, precisamente por esa simplicidad que se busca:


La cabecera tiene ahora un tamaño fijo de 8 bytes. Los campos Puerto de Origen y Puerto de Destino tienen la misma función que en TCP, Longitud almacena el tamaño del datagrama, y Suma de comprobación, usada para que el destinatario compruebe si hay errores en el datagrama recibido.

ARP
Antes de terminar este apartado introductorio, es interesante revisar ARP. ARP o Address Resolution Protocol es un protocolo de nivel de enlace o capa 2 OSI. Respecto a esto, existe controversia: algunos lo enmarcan en la capa 3, dado que los mensajes ARP se encapsulan en una trama de la capa de enlace. Otros hablan incluso de nivel 2,5. Su función principal es la de traducir direcciones IP a direcciones físicas dentro de una red local (un dominio de difusión). Existe por la siguiente razón: el protocolo IP se encarga de encaminar los paquetes a una red de destino (que puede ser la misma a la que pertenece el host origen), y, una vez alcanzada la red, es misión de la capa de enlace hacer llegar la trama de datos al host destino usando su dirección física. Llegados a este punto, hemos alcanzado la red del destinatario, tenemos su IP, pero no conocemos su dirección física, y es aquí donde entra en juego ARP, ya que, dada la IP de un dispositivo, nos permite obtener su dirección física.

Resumiendo mucho su comportamiento, existen dos tipos de operaciones: Peticiones ARP y Respuestas ARP. Supongamos que un host origen con IP 192.168.1.10 y MAC AA:AA:AA:AA:AA:AA desea enviar una trama a un host con IP 192.168.1.20, pero desconoce su MAC. Para ello, se realizan las siguientes acciones:
  • El host origen envía a la red una solicitud ARP a la red. Esta tiene un formato similar al siguiente. En este caso, especifica en el campo MAC Origen, su propia MAC, en IP Origen su propia IP, y en el campo IP Destino, la IP del dispositivo cuya MAC desea conocer. Este mensaje se encapsula en una trama de la capa de enlace (por ejemplo, Ethernet) y se envía a todos los dispositivos de la red. Para ello, se pone como dirección física de destino la dirección física de broadcast. La MAC destino la rellena con ceros.


  • Este mensaje llega al resto de nodos de la red, en nuestro ejemplo, al PC con la IP 192.168.1.20 y a la interfaz 192.168.1.1 del router. Solo el equipo con la IP indicada en el campo IP Destino del mensaje ARP de petición lo procesa, el resto de equipos lo descarta.
  • El host destinatario del mensaje, en nuestro caso, 192.168.1.20, envía un mensaje de respuesta ARP dirigido solo al emisor de la petición. Este mensaje de respuesta es similar al de petición: el tipo de operación ahora es respuesta, MAC Origen pone ahora su propia MAC e IP Origen su propia IP. Esto se encapsula en una trama MAC unicast, enviada directamente al host origen de la petición (en nuestro ejemplo, el de la IP 192.168.1.10).

Caché o Tabla ARP
Es importante destacar que cada host mantiene en memoria una tabla ARP o caché ARP donde almacena los resultados de forma temporal. Así, se evita tener que hacer una petición cada vez que se necesite la dirección física asociada a la IP de alguna máquina de la misma red reduciendo así el tráfico en la misma. Estas entradas de caché tienen una duración limitada.

ARP Poisoning
El ARP Poisoning o envenenamiento ARP es una técnica que permite a un atacante realizar el envío de respuestas ARP no solicitadas indicando en ellas una dirección física que no corresponde a la IP solicitada. Por ejemplo, un atacante podría enviar mensajes de respuesta ARP a una víctima anunciando que su MAC es la del gateway de la red, de modo que todo su tráfico pasaría por el atacante, quien tendría la oportunidad de realizar otros ataques: esnifado del tráfico, DNS Spoofing, filtración de datos sensibles… En la siguiente figura mostraría cómo se haría esto en la red que acabamos de presentar: