GNU/Linux, software libre para la comunidad universitaria. Redes privadas virtuales en GNU/Linux

Transcripción

1 I GNU/Linux, software libre para la Redes privadas virtuales en GNU/Linux

2 II Copyright (C) 2009 José María Peribáñez Redondo Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

3 III COLABORADORES TÍTULO : GNU/Linux, software libre para la comunidad universitaria ACCIÓN NOMBRE FECHA FIRMA ESCRITO POR José María Peribáñez Redondo 19 de octubre de 2009 HISTORIAL DE REVISIONES NÚMERO FECHA MODIFICACIONES NOMBRE José María Peribáñez Redondo José María Peribáñez Redondo

4 IV Índice general 1. Distribuciones GNU/Linux para servidores de red 1 2. Paquetes de red. Modelo en Capas Capa enlace de datos (Layer2) WDS IEEE802.1X WEP/WPA/WPA2/IEEE802.11i/ Wakeonlan Capa de red: capa IP (Layer3) Máscaras de red. Notación CIDR Enrutamiento dinámico Paquetes ICMP, IGMP Vinculación entre capa de red y enlace de datos ipalias NAT trasversal Capa de transporte (Layer4) Capa de aplicación (Layer5; Layer7 en OSI) Autoconfiguración: DHCP, PXE, Zeroconf Servidores DHCP Software DHCP DHCP vs ZeroConf y UPnP PXE Servidores de red para empresas DNS DNS dinámico Servidor de correo Servidor Wiki Servidor Jabber Qué servidor instalar

5 V 5. Acceso remoto seguro Distintas soluciones de acceso remoto Una solución práctica: crear un túnel con openssh Redes Privadas Virtuales (VPN) Soluciones VPN para GNU/Linux IPsec Caso práctico: IPsec en modo transporte, usando preshared keys SSH + PPPD / SSH + TUN Caso práctico: SSH + PPPD Más sencillo: servidor SOCKS de SSHD SSH con TUN OpenVPN Caso práctico: OpenVPN Escritorio remoto Escritorio remoto: X-Window Escritorio remoto: RFB (VNC) RDP. Escritorio remoto de Windows NX. Nueva tecnología de escritorio remoto Cómo funciona NX NX y software libre Proxies, cortafuegos, software de filtrado Proxies y software de filtrado Netfilter/IPtables. Solución para crear cortafuegos, auditar red y hacer NAT Cómo hacer SNAT Cómo hacer DNAT Cortafuegos a nivel capa de enlace de datos Contadores con netfilter Caso práctico: router red local, red otra empresa, Internet El problema de la IP de origen en máquinas multihome (con más de una IP) Soluciones de virtualización/redes con virtualizadores Virtualización Virtualización para aprender sobre redes VMWare y la red Qemu/UML y TUN/TAP Ejemplos Instalar QEMU Crear una imagen con Qemu Listados de ejemplos de TUN/TAP A. GNU Free Documentation License 56

6 1 / 60 Capítulo 1 Distribuciones GNU/Linux para servidores de red A lo largo del curso, la distribución elegida ha sido OpenSuSE. Esta distribución, al igual que otras populares como Ubuntu, Mandriva o Fedora son interesantes para uso personal, pero no son la mejor elección para un servidor de red, un cortafuegos o una VPN en una empresa. En general para empresas son más adecuadas las distribuciones de ciclo largo, que tengan actualizaciones durante años y no es preciso actualizar a otra versión al cabo de unos meses. Las distribuciones de ciclo largo no tratan de ofrecer al usuario el tener siempre el software más reciente, sino estabilidad. Para quien desee una distribución de ciclo largo, Novell tiene su propia versión de SuSE adecuada para estos menesteres, pero es software privativo por el que hay que pagar una subscripción anual por cada máquina. Algo parecido (aunque técnicamente no sea software privativo sino libre, gracias a lo cual existen clónicos gratuitos como CentOS) ocurre con Red Hat y su versión Enterprise. La alternativa a estas distribuciones de pago es usar Ubuntu LTS o un derivado de Red Hat Enterprise gratuito, siendo la alternativa más conocida CentOS. Para instalar un cortafuegos, servidor DHCP etc también está la opción de usar una distribución de propósito específico como IPCop o Smoothwall. Ambas tienen una intuitiva interfaz web. No sólo incluyen el cortafuegos, también gestión del ancho de banda, servidor DHCP, DNS dinámico, servidor de tiempo (NTP), servidor SSH y VPN (con IPsec) admitiendo la VPN tanto unir dos redes como configuración road-warrior (conexión de un usuario remoto a la red local de la empresa). Smoothwall Express está financiado por una empresa, que comercializa software de seguridad relacionado, incluyendo también cortafuegos y filtros de contenidos; periódicamente smoothwall contribuye código de sus productos privativos a esta versión enteramente libre (por ejemplo el código para mostrar el uso de ancho de banda de forma gráfica). En el caso de IPCop no hay una empresa detrás del producto, pero en su web hay una relación de empresas que venden soporte técnico. Tanto IPCop como Smoothwall soportan características avanzadas como gestión del ancho de banda de las conexiones peer-to-peer (Emule, Bittorrent...) e integran un IDS (detector de intrusiones). IPCop y Smoothwall son soluciones para un cortafuegos; no están diseñadas para ejecutar todo tipo de servidores, por ejemplo el correo o los servicios de ficheros e impresión. No es buena idea poner un gran número de servicios sobre un cortafuegos y aprovechar una máquina como servidor para todo. Cuantos más servicios críticos corran sobre una máquina, mayor riesgo es que exista alguna vulnerabilidad en uno de ellos que al comprometer la máquina afecte a la seguridad de todos los demás. Probablemente la distribución especializada en redes y con administración web más interesante sea Zeroshell, con características muy avanzadas por ejemplo a la hora de construir un Acess Point: Hay otras distribuciones orientadas a servidores de empresa (sobre todo a PYMES). Destacaremos tres: 1. Ebox ( Software libre de una empresa española, con toda una arquitectura para desarrollar los nuevos componentes. En realidad no es una distribución, sino una plataforma que se instala sobre una distribución: por ejemplo está disponible en los repositorios para Ubuntu. De todos modos se puede descargar una distribución basada en Ubuntu 8.04 LTS con todo ya instalado. 2. SMEServer ( GPL, basado en CentOS 4. Servidor de correo, con filtro de SPAM y virtus, conversión de correos en formato TNEF, webmail. Servidor de ficheros, con sistema de administración de usuarios, cuotas. Servidor web. Compartición de la conexión a Internet. I-Bays: Un sistema para compartir información entre un grupo de usuarios. Servidor de impresión.

7 2 / ClarkConnect: ( Servidor de correo, impresión, ficheros, backup, VPN... Lamentablemente no parece ser software libre al 100 %, porque hay distintas ediciones. La edición gratuita además de tener limitaciones no es de ciclo largo. Es muy recomendable acudir a las páginas de estos proyectos en la Wikipedia, porque además veremos referencias a proyectos similares y a herramientas de administración web que se pueden integrar en las distribuciones habituales También cabe reseñar algunas soluciones basadas en Linux que corren en routers de precio asequible, como el SoC (System On Chip) ADM5120, un hardware que cuesta menos de 50EUR, tienen un consumo de energía mínimo y el tamaño de un switch barato para el hogar. Sobre estos sistemas corren distribuciones Linux específicas como OpenWRT ( Se puede adquirir un router basado en una placa ADM5120 con 5 interfaces de red, 16MB de RAM y la opción de usar discos externos por USB (lamentablemente limitados a la velocidad de USB 1.0) en Si lo que necesitamos es un servidor y no necesitamos tener varias interfaces de red, hay otros dispositivos como o Soluciones más caras son las placas de Soekris. Para evitar la dependencia de OpenSuSE y facilitar al lector elegir la distribución que más le convenga para sus servidores, en los capítulos sobre redes no se usará la herramienta de administración Yast, sino que se indicará como hacer la configuración manualmente o bien se comentarán herramientas genéricas disponibles en cualquier distribución.

8 3 / 60 Capítulo 2 Paquetes de red. Modelo en Capas Para entender los conceptos avanzados de redes, es muy útil tener presente el modelo en capas de las redes. Cada capa da servicio a la capa superior implementando una funcionalidad. A la hora de enviar un paquete, la capa superior pasa a la que está debajo los datos que quiere enviar, quien hará lo propio con la capa inmediatamente inferior, tras añadir sus propias cabeceras. Al recibir un paquete los pasos son los inversos, cada capa tras interpretar y eliminar sus cabeceras pasará el resto de datos a la capa inmediatamente superior. 1. Layer 1: capa física. Nos basta saber que existe: se implementa enteramente en hardware. No nos detendremos más en ella. Es a partir de la capa 2 dónde podemos ver los paquetes con un sniffer. 2. Layer 2: capa de enlace de datos/acceso de red: Depende del tipo de red local o comunicación punto a punto que utilicemos: por ejemplo si es una Ethernet, una FDDI (red metropolitana de fibra óptica, muy usada para unir los centros de las facultades o los edificios en un parque tecnológico), una conexión PPP sobre una línea telefónica... En la actualidad un administrador de red raramente maneja otro enlace de datos distinto de Ethernet, pues aunque se trate de un router que conecta con otros routers vía FDDI, normalmente se usa un transceptor de fibra al que la conexión es vía Ethernet y la comunicación es realmente a nivel Layer3. Lo mismo ocurre con el enlace punto a punto utilizado para el ADSL, podrá usar PPPoA o PPPoE (un poco más eficiente usar PPPoA), pero lo normal es que eso sea en el router ADSL y la comunicación hasta el router ADSL es vía ethernet y de nuevo a nivel IP (layer3), aunque cuando el router ADSL está en modo monopuesto sí se suele utilizar un cliente PPPoE. A nivel usuario, esta capa puede presentar la dificultad de configurar un acceso Wifi o una conexión Bluetooth. La capa 2 es la más alta que ven los bridges, switchs y hubs. 3. Layer 3: capa de red. La capa IP. Es la capa más alta que ven los routers. Sobre una red Ethernet puede haber más de una red IP, si los rangos de direcciones no se solapan o incluso pueden mezclarse distintos tipos de redes, por ejemplo una red IP con una AppleTalk o IPX (Netware). 4. Layer 4: capa de trasporte: TCP,UDP... En esta capa y en la 5, sólo suelen intervenir el nodo origen y destino, aunque se puede ver afectado por ejemplo por un router que haga NAT. Es la capa con la que suelen trabajar los aplicaciones, a través de sockets. En Unix los sockets se manejan como ficheros. 5. Layer 5: capa de aplicación: HTTP, MAIL, JABBER... En ocasiones esta capa se menciona como l7 (layer7) porque en el modelo de referencia OSI hay otras dos capas entre la capa de transporte y la de aplicación: sesión y presentación. La mayoría de las aplicaciones utilizan protocolos IP y para ellos las capas 1 y 2 son transparentes, como si no existieran. Sin embargo hay protocolos que se implementan directamente sobre la capa2. A veces sobre la capa de red, la de transporte o incluso sobre la capa de aplicación se encapsula otro paquete desde la capa de red o incluso desde la física. El motivo es hacer túneles y se usa mucho en las redes privadas virtuales: se hace que dos nodos que no están en la misma red local se comporten como si lo estuvieran, gracias a que hemos cargado los paquetes sobre otros paquetes que van por Internet y en destino los reconstruimos.

9 4 / Capa enlace de datos (Layer2) Aunque la mayoría de las aplicaciones son independientes de esta capa al utilizar protocolos IP, hay excepciones, por ejemplo muchos juegos operan sobre layer2. Tanto en una red Ethernet como en una Wifi, cada tarjeta tiene una dirección que es única, la dirección MAC (es como un número de serie que no se repite, para ello cada fabricante tiene asignado un rango de direcciones, aunque también existen rangos para uso privado). Son 48 bits, o lo que es lo mismo, 12 caracteres hexadecimales. Suelen representarse así: 00:09:6C:EF:E4:69. Las direcciones MAC al ser únicas en principio se pueden usar para filtrar paquetes en un cortafuegos o para restringir el acceso en un Access Point Wifi. Error. Lo más probable es que nuestra tarjeta nos permita cambiar la dirección ARP con un simple ifconfig eth0 hw ether 00:09:6c:EF:e4:69. Este cambio es temporal, dura hasta que lo volvamos a cambiar o reiniciemos la máquina. Además en muchas tarjetas se puede hacer el cambio permanente, pues la dirección MAC se escribe en una memoria flash dentro de la tarjeta. En este caso la herramienta a utilizar se llama ethertool y la opción que cambia la MAC es phyad. El hardware de las tarjetas de red y de los hubs no sabe nada de direcciones IP, lo único que entiende es el formato de los paquetes ethernet, con sus direcciones MAC. Es un error pensar que las tramas Ethernet se generan en el hardware o en el sistema operativo sin posibilidad de manipulación. En GNU/Linux mediante los sockets RAW (ver man 7 packet) es posible escribir tramas Ethernet. Así mismo mediante TUN/TAP tanto en GNU/Linux como en la mayoría de los sistemas operativos es posible leer/escribir a través de un dispositivo tanto tramas ethernet como paquetes IP. Si en nuestra red existe un túnel (por ejemplo para hacer una VPN) es posible generar paquetes Ethernet en un equipo remoto, enviarlos vía Internet y que un nodo en la red local los emita como si hubieran sido generados localmente. En una red Ethernet para unir los distintos equipos se usa un hub o un switch. Un hub opera a nivel físico y es muy primitivo: no deja de ser el equivalente en conectores de red a un "ladrón" en clavijas para enchufes. También se le compara con un repetidor. El problema de los hubs es que este modelo es poco escalable cuando existen muchos equipos en una red (especialmente si se enlazan varias redes locales físicamente para no usar enrutadores, simplificando la configuración de la red y que funcionen servicios que usan broadcast a nivel Ethernet como DHCPD (en realidad también se puede tener un único servidor para varias subredes no conectadas a nivel de enlace de datos si se usa un bootp/dhcpd agent relay), o esté disponible funcionalidad como wake-on-lan o servicios de autoconfiguración PnP). Un hub es poco escalable porque lo que se hace es transmitir para cada nodo todos los paquetes. La alternativa a los hub son los switchs. La diferencia entre un hub y un swtich es que el segundo analiza las tramas ethernet que pasan por él; si ve que un paquete ha entrado por un puerto (cada conector para un cable de red es un puerto) registra la dirección MAC de origen junto con el puerto en una tabla llamada CAM, de modo que si llega un paquete para esa dirección no lo envía por todos los puertos sino sólo por ese. Hoy en día si vamos a una tienda a comprar un hub, lo normal es que ya no lo tengan y sólo vendan switchs. En una red local Ethernet pueden coexistir paquetes de distintos protocolos, por ejemplo tráfico IP y tráfico AppleTalk. También es posible que sobre una misma red Ethernet haya más de una subred IP: si los rangos no se solapan tampoco habrá problemas. En redes de capa2 existe la posibilidad de crear varias VLAN (virtual LAN: 802.Q), que consiste en añadir a los paquetes Ethernet una cabecera adicional que indica la LAN virtual que se aplica: un switch que soporte VLAN (los baratos no lo hacen, pero sí lo soporta por ejemplo los switchs de los AP que usan OpenWRT; en cualquier caso tiene que ser un switch administrable de alguna forma) sólo transmitirá por un puerto los paquetes que vayan a esa VLAN (esta asociación la hace y deshace el administrador). Se puede configurar un puerto para recibir paquetes destinados a más de una VLAN (trunk port). La VLAN marcada como "nativa" para un puerto implica que los paquetes que van para esa VLAN se les quita el "tag" que indica la VLAN, por lo que serían paquetes Ethernet normales. Mediante una VLAN los paquetes broadcast sólo son a nivel de esa VLAN y sería posible que hubiera dos redes usando el mismo cableado con rangos de Ips solapadas, si usan distintas VLANs. Podemos ver las VLANs como una forma de tener más de una red de capa2 sobre una única infraestructura de cableado (es decir, multiplexar varias redes de nivel 2 sobre una). Las VLANs funcionan no sólo sobre una red local "física", sino sobre toda una infraestructura de redes unidas por swtichs en un campus, por ejemplo. Típicamente se hacen coincidir las VLANs con las subredes IP de capa 3. De este modo se fuerza a usar enrutamiento para comunicarse entre nodos de distinta subred. Un ejemplo de uso de VLANs es la infraestructura de red de una empresa, dónde es necesario aislar las redes de distintos proyectos, pero sin que haga falta relocalizar los ordenadores de los programadores y de los servidores

10 5 / 60 Hay un identificador reservado para paquetes que no pertenecen a ninguna VLAN, el cero. El uno también está reservado, para gestión En GNU/Linux el comando para crear redes VLAN es vconfig WDS A la hora de tratar de hacer un bridge entre una tarjeta Ethernet y una tarjeta Wireless nos podemos encontrar con que no funciona. El motivo es que para que funcione un bridge los paquetes Wifi tienen que incluir hasta 4 direcciones: la dirección MAC origen, la dirección MAC de la tarjeta Wifi, la dirección MAC del Access Point, la dirección MAC destino. Si la tarjeta (más que su hardware el driver no tiene en cuenta estas 4 direcciones sino 3 (todas menos la origen, al suponer que la origen es la de la tarjeta) no funcionará. Lo mismo ocurrirá si el AP no reconoce las 4 direcciones. Con un bridge que sólo afecta a tarjetas Ethernet no hay este problema: sólo hay dirección origen y destino, las tarjetas del bridge se ponen en modo promiscuo para recibir todos los paquetes y no sólo los de su MAC, por lo que la dirección de las tarjetas que forman el bridge no van en el paquete al no hacer falta. Para que una conexión Wifi pueda participar en un bridge, la tarjeta por lo tanto tiene que soportarlo y el AP también: los AP que soportan WDS son aptos. WDS (Wireless Distribution System) permite implementar un bridge entre dos AP ampliando la cobertura al alcance de los dos IEEE802.1X Es un sistema para autenticar un puerto (físico) en un dispositivo de red, por ejemplo lo ofrecen algunos switch avanzados y los Access Point Wifi. La idea es que el cliente (por ejemplo un PC) que se conoce es el supplicant y el dispositivo de red es el authenticator que tiene que autorizarle. Típicamente el authenticator contacta con un servidor Radius 1. Para autenticar se utiliza AEP. Windows incluye software supplicant y en el caso de Linux hay dos programas: Xsupplicant, que sirve para todo tipo de hardware y wpa-supplicant, que es específico para Wifi. Autenticarse mediante IEEE802.1X no evita todos los ataques posteriores derivados de insertar un hub entre la máquina y el switch, pues la autenticación sólo es al principio: sería conveniente usar además IPsec (en el caso del Wifi la conexión tras autenticarse va cifrada luego ya sería segura) WEP/WPA/WPA2/IEEE802.11i/ En las redes Wifi sobre la capa 2 se implementó cifrado mediante WEP. Sin embargo este método se ha demostrado muy inseguro. 2. La solución de compromiso utilizando el mismo hardware (cifrado de flujo con RC4) es WPA, que cambia dinámicamente la clave (TKIP) e introduce varios mecanismos de seguridad. WPA2 (IEEE802.11i) usa AES para cifrar en lugar de RC4 (no es compatible pues con el hardware viejo) e introduce algunas otras mejoras. Tanto WPA como WPA2 admiten dos configuraciones: personal y enterprise. En personal (WPA/PSK) se usa una clave compartida, que será la misma en todos los nodos, por lo que es una solución válida para protegerse de intrusos externos, pero no frente a ataques de personas con un nodo en la red. La versión empresarial en cambio utiliza para autenticarse (y para obtener la clave de sesión) IEEE802.1X. Tanto si se usa la configuración personal como la empresarial, el programa a utilizar es wpa_supplicant (para depurar posibles errores cabe conectarse a ese demonio con wpa_cli así como observar con dmesg los mensajes del kernel, 3 por ejemplo podemos deducir que es necesario 1 Radius es un protocolo definido para hacer AAA (Authentitacion, Authorization and Accounting) usado sobre todo para los ISP. Se utiliza usuario y contraseña, protegida con MD5 y un secreto compartido entre el servidor Radius y el NAS (Network Access Server, en este caso el authenticator, por ejemplo el Access Point, pero en el escenario más clásico es el servidor PPP del ISP), que es el cliente Radius. De todos modos hoy en día los servidores Radius soportan sistemas de autenticación distintos de usuario y contraseña para autenticar, en concreto AEP con métodos como AEP-TLS que implica certificados cliente y que la comunicación entre el supplicant y el servidor Radius se haga sin que el authenticator tenga que soportar cada uno de estos métodos AEP. La secuencia clásica de Radius es que el usuario se autentique con su ISP usando PPP y el servidor PPP contacte con el servidor Radius pasándole las credenciales que ha recibido del usuario vía PPP. El servidor puede asignar datos como una IP o rango de IPs, así como parámetros L2TP o QoS (en realidad cualquier tipo de información, pues como los servidores DHCP permite extensiones de vendedor). Las funciones de Accounting básicamente consisten en el que el NAS pasa información a registrar como duración de la sesión o tráfico transferido. 2 Existen varias aplicaciones para automatizar el conseguir una clave WEP, como el ya antiguo airsnort, si bien hoy en día hay programas más avanzados como aircrack-ng. 3 En algunos casos puede resistirse una configuración WPA. Una página que muestra gran cantidad de opciones posibles es Sobre WPA Enterprise y el uso de EAP, algunas referencias interesantes son

11 6 / 60 ejecutar iwpriv eht1 host_roaming 1). En Ubuntu utilizar WPA es tan sencillo como incluir en /etc/network/interfaces unas líneas como estas: iface eth0 inet dhcp wpa-ssid MIWLAN wpa-key-mgmt WPA-PSK wpa-passphrase mipassphrase_1asfpasfd WPA a día de hoy previene los ataques más problemáticos que existen sobre RC4, aunque ya existen ataques que lo hacen no seguro y probablemente se descubran nuevas vulnerabilidades en el futuro, que haga que si alguien almacena hoy tráfico WPA pueda descifrarlo dentro de a lo sumo unos años. WPA/PSK no es sólido cuando las claves de los usuarios son débiles o están en un diccionario; no facilita la prevención de este tipo de ataques. Las vulnerabilidades existentes actualmente de WPA no permiten robar ancho de banda, pero sí provocar problemas inyectando paquetes Wakeonlan Una característica interesante que permiten la mayoría de las tarjetas de red actuales es encender el equipo remotamente: wake on lan. Es útil para tareas de mantenimiento y también para poder conectarse al equipo desde casa en caso de necesidad, por ejemplo mientras se está de soporte. Esta funcionalidad se implementa mediante un paquete a nivel de enlace de datos. Para que funcione esta funcionalidad, normalmente hay que activarla en la BIOS. En algunas tarjetas de red, también hay que unir un pequeño cable que sale de la tarjeta a un conector en la placa base que pone "wake on lan". Dependiendo del caso, también es posible que tengamos que activar la funcionalidad en la tarjeta, para eso utilizamos la herramienta ethtool. Con ethtool <nombre_interfaz> (por ejemplo ethtool eth0) veremos los distintos modos wake-on-lan que soporta la tarjeta, si es que soporta alguno. Con ethtool eth0 -set wol g activamos el modo wake-on-lan basado en "magic packet", el modo más habitual. Se trata de un paquete que en alguna parte debe contener un patrón consistente en primero 6 bytes con todos sus bits a 1, seguido por la dirección MAC de la tarjeta repetida 16 veces. Opcionalmente continua con una password, que también se fija con ethtool pero que sólo admiten algunas tarjetas. El paquete normalmente se construye usando UDP al puerto 9 (discard) y enviando el paquete por broadcast, aunque puede ir encapsulado en cualquier tipo de paquete, ni siquiera tiene que ser IP. Es posible despertar a un equipo mediante un "magic packet", enviándolo desde fuera de la red local? normalmente no, salvo que tengamos una infraestructura de VPN. El problema es cómo hacer llegar el paquete hasta la máquina; si está conectada a un switch sólo recibirá los paquetes que van destinadas a su MAC o paquetes broadcast/multicast. Es bastante frecuente que los enrutadores no dejen pasar los paquetes broadcast. Pero si intentamos la otra opción, enviar el paquete a su IP, al llegar al enrutador posiblemente ya no tenga la entrada ARP, pues caducan tras un tiempo; cuando haga la petición ARP no obtendrá respuesta, pues la máquina está apagada. Una forma de evitarlo es insertar estáticamente la entrada en la tabla ARP. Los dos programas más recomendables son wakeonlan y etherwake. Etherwake genera directamente un paquete Ethernet, por lo que requiere privilegios de root y sólo sirve para ejecutarlo en la propia red local Capa de red: capa IP (Layer3) Sobre la capa de enlace de datos va la capa IP; en realidad pueden ir otro tipo de capas de protocolos distintos a IP, como IPX, el protocolo de Netware, pero nos centraremos sólo en los paquetes IP que son los que se usan en la casi totalidad de las redes locales de hoy en día además de por supuesto en Internet. Un paquete IP se llama datagrama. La información más importante que incluye un datagrama es la IP de origen y la IP destino. Las direcciones IP a diferencia de las MAC están pensadas para ser enrutables, es decir, hay unos nodos enrutadores que examinan la dirección destino y deciden por qué camino siguen los paquetes. Gracias a que las direcciones IP se asignan por grupos a las distintas organizaciones y proveedores de Internet es factible establecer rutas. Esto con las direcciones MAC sería imposible: como vienen a equivaler a números de serie del hardware son inútiles para enrutar: puedo tener dos equipos juntos con MACs 4 El antes citado aircrack-np no se usa sólo para WEP, pues también se usa con redes en las que se conoce la clave WPA/PSK o se trata de atacar si está en un diccionario. No sólo utiliza el modo monitor de las tarjetas sino que "inyecta" paquetes para facilitar la tarea de romper la seguridad. Aunque en general aircrack es un programa que parece dedicado a la gente que desea colarse en las redes ajenas, su utilidad airtun-ng sí es aprovechable en redes con WPA/PSK para usar un IDS. La web es interesante por la documentación sobre seguridad en redes Wifi.

12 7 / 60 que no tienen nada que ver porque son de fabricantes distintos o uno tiene años más que el otro: quizás el nodo con la siguiente MAC a la nuestra se vendió en una ciudad de Japón. Hay rangos de direcciones IP que están reservados para uso privado dentro de una organización. Por ejemplo todas las direcciones que empiezan por En las empresas, o en los hogares cuando se tienen varios ordenadores en casa y se quiere compartir la ADSL, lo habitual es usar direcciones de este tipo (privadas) en lugar de direcciones IP públicas. Las direcciones privadas no son enrutables fuera del ámbito en que se usan, por lo que no son utilizables para conectarse fuera de la red local. Por ejemplo no podemos conectarnos vía mensajería instantánea a un usuario de Internet utilizando la IP , porque los paquetes de respuesta no nos llegarían, dado que esa IP no es pública y no es pública porque puede haber mucha gente que la está usando en su red local. La solución está en el uso del NAT (Network Address Translator). El enrutador de salida a Internet de nuestra red modifica el paquete IP para que use como dirección IP origen la IP pública que tiene asignada la empresa y guarda en una tabla información para hacer la modificación inversa en los paquetes de respuesta entrantes. Siempre que hay enrutado y esto incluye casos especiales como tener una VPN en un nodo, hay que activar el forwarding. Para ello hay que ejecutar sysctl net.ipv4.ip_forward=1. El forwarding consiste simplemente en que si un paquete viene por una interfaz de red (por ejemplo eth0) y se ve por la tabla de rutas que está destinado a la red de otra interfaz (por ejemplo la eth1) se traspasa a esa otra interfaz. También es posible activar el forwarding para unas interfaces de red sí y para otras no, por ejemplo para eth0 sería sysctl net.ipv4.conf.eth0.forwarding=1. Hay una parte de la dirección que indica el nodo dentro de la red pero otra indica la red. Los enrutadores tienen rutas para saber por dónde tienen que encaminar los paquetes según la parte de red destino, con una ruta por defecto para los paquetes que no encajan en ninguna de las otras rutas. Los enrutadores sólo suelen tener en cuenta la dirección destino, no la dirección origen, pero en GNU/Linux hay herramientas avanzadas que permiten considerar también la dirección origen Máscaras de red. Notación CIDR Es importante conocer no sólo la IP de un equipo, sino su red. Para determinar la red a la que pertenece un equipo a partir de su IP, se usa la máscara de red, que al aplicar a nivel de bits un AND sobre la IP nos da la red. Una notación más concisa que utilizar el par IP y máscara de red es la notación CIDR: tras la dirección IP, separado por / se indica el número de bits a uno de la máscara de red. Por ejemplo, /24 indica que la máscara de bits es de Esta notación además de más concisa tiene la ventaja que es más rápido de ver cuantos nodos tiene una red, pues es 2ˆ(32-x)-2; en nuestro caso sería 2ˆ(32-24) = 2ˆ8-2= 254. La máscara de red más grande (es decir, la red con menos nodos) es 30, con lo que tendría 2ˆ2-2=2. El motivo de restar 2 unidades es que el primer valor (con todos los bits a cero) es la propia red y el último (con todos los bits a 1) es la dirección de broadcast, es decir, la utilizada para enviar un paquete a todos los nodos de una red. Así pues, una red de este tipo es útil para definir una red para una conexión punto a punto, por ejemplo para una conexión que se usa únicamente para enlazar dos redes Enrutamiento dinámico Hay protocolos de frontera interior como RIP, OSPF, IS-IS y protocolos de frontera exterior, como BGP 6. El programa recomendado es o bien Zebra o Quagga (este último es un fork surgido de Zebra). Hay otros programas, como Routed (parte de netkit), que sólo es adecuado si no vamos a utilizar más que RIP, Gated (que no es libre) o Bird, con desarrollo menos activo. Un artículo algo antiguo, pero que puede servir de introducción a los protocolos de enrutamiento, se publicó en Linux Magazine: Paquetes ICMP, IGMP Los paquetes ICMP (Internet Control Message Protocol) son paquetes de control, que van sobre la capa IP pero siguen siendo parte de la capa de red. Por ejemplo son los paquetes que se reciben cuando se recibe un error de que no se ha podido establecer una conexión a un puerto o que no hay ruta para llegar a una red. Son también los paquetes que se envían y reciben al hacer un 5 En concreto, las redes reservadas para uso privado están fijadas por el RFC 1918 y son /8, /12 (es decir, de a y /16. Hay más rangos reservados para usos especiales, por ejemplo /16 para link-local o /4 para Ipv4 multicast. 6 Protocolos de frontera interior son los que se usa para enrutar el tráfico dentro de la organización que tiene asignado un rango de Ips y es responsable cara a Internet de su enrutamiento (típicamente un proveedor de Internet, o por ejemplo RedIris), que es lo que se conoce como un AS (Autonomus System) mientras que los protocolos de frontera exterior son para enrutar entre AS.

13 8 / 60 ping para comprobar si llegamos a una red. De los paquetes ICMP sólo nos interesa saber que llevan un campo con el tipo de mensaje, que será el campo por el que filtraremos o dejaremos pasar este tipo de mensajes en nuestro cortafuegos. Con iptables -p icmp -h se ven los tipos de paquetes ICMP. Los paquetes IGMP son paquetes de control para multicast (multidifusión). El origen del modo multicast es que hay comunicaciones en las que los mismos paquetes son de interés de varios nodos destino en lugar de uno solo; el ejemplo más socorrido es una emisión de vídeo. Si se transmite una película usando unicast (el modo normal de comunicación IP) entonces se transmitirá un paquete por cada destinatario, mientras que con multicast en los tramos comunes a todos los destinatarios irá un solo paquete. El multicast se basa en rangos de Ips reservados para este fin, pero no hablaremos más de él porque se usa muy raramente. No hay que confudir multicast con broadcast: este último es enviar a todos los nodos de la red, el multicast es más restringido Vinculación entre capa de red y enlace de datos A nivel de red se utilizan direcciones Ips, pero las redes locales a nivel físico utilizan Ethernet, por lo que en último término para enviar un paquete a una máquina de la red local no basta con utilizar su IP, además en la parte de cabeceras Ethernet habrá que poner su dirección MAC. El protocolo que permite averiguar la dirección MAC de una máquina a partir de su IP es ARP. El funcionamiento de ARP se basa en utilizar una dirección de broadcast Ethernet para preguntar a todos los nodos de la red local quién tiene una determinada IP: la respuesta se cachea en cada host para evitar preguntarla cada vez. Con el comando arp de Unix se puede ver y manipular la tabla que convierte de IP a dirección MAC en una máquina. Existe un protocolo llamada RARP (reverse ARP) que hace lo contrario que ARP: a partir de la MAC un servidor responde qué Ip tenemos. Se usa para hacer los nodos de la red autoconfigurables, pero se considera preferible usar un protocolo más avanzado como BOOTP o DHCP. GNU/Linux incluye soporte de ProxyARP. Un proxy ARP es una máquina que responde peticiones ARP en nombre de otras máquinas que estando en la misma red IP que el nodo que hace la petición, no están en la misma red física (ni están unidas por un hub, switch o bridge). El uso más típico es para poner equipos detrás de un cortafuegos, pero usando Ips de la misma red que el resto de equipos. El host que actúa de proxyarp ante una petición ARP a una IP de la que hace de proxy responde con su propia dirección MAC; luego cuando le lleguen paquetes los redirigirá a la máquina. Otro uso importante es para que un nodo que accede a través de una VPN a la red local pueda tener una IP local, sin necesidad de usar un bridge. Otro uso es para el caso de una red Wifi que no soporta WDS y tenemos un nodo que enlaza a varios equipos Ethernet con la red Wifi y los equipos quieren usar direcciones IP válidas en la red Wifi en lugar de NAT para ser accesibles sin tener que hacer mapeos de puertos. Típicamente esto se hace dando la misma IP a la interfaz Wifi y la Ethernet, pero poniendo el enrutado de toda la red por la Wifi salvo los nodos concretos (a los que se accederá en la red Wifi gracias a proxyarp) que se pondrá una ruta concreta usando "dev" a la interfaz ethernet. En general podemos ver a proxyarp como una alternativa a tener un bridge, para usarlo con tráfico IP y hacerlo con una única IP o unas pocas ipalias Una característica interesante de Linux es que un dispositivo de red Ethernet puede tener más de una IP, puede tener cuantas direcciones queramos. De este modo con una única tarjeta es posible tener varios servidores en el mismo puerto y máquina (por ejemplo varios servidores de correo, que obligatoriamente usan el puerto 25), usando cada uno una IP distinta, sin necesidad de comprar más tarjetas. Así, si tenemos la interfaz eth0 con la IP y queremos tener otra interfaz con la , simplemente creamos:ifconfig eth0: Esta funcionalidad se llama ipalias. No hay restricciones sobre si las Ips tienen que estar en la misma red o en redes distintas: la única restricción es que seguimos teniendo sólo una dirección ARP, pues esto ya es una limitación del hardware de la tarjeta, para que la tarjeta pudiera tener más de una MAC, tendría que ponerse en modo promiscuo, con la consiguiente pérdida de eficiencia: el hardware de la tarjeta está optimizado para filtrar los paquetes que no van a su MAC ni a ninguna de las de difusión. Técnicamente una interfaz ipalias aunque con ifconfig aparezca como un dispositivo más, no es un dispositivo reconocido por el sistema operativo al mismo nivel que los reales ni los virtuales creados con TUN/TAP. Por ejemplo no tiene entrada específica en /proc/sys/net/ipv4/conf. Esto provoca que no funcione tratar de obtener una dirección de un servidor DHCP con dhcpclient:

14 9 / 60 falla cuando intenta abrir un socket raw sobre este dispositivo. Técnicamente nada impide que una tarjeta de red obtenga más de una IP, pues como dhcp-client-identifier no tiene por qué usar su dirección MAC, por lo que usa solución sería un programa que obtenga una segunda dirección, utilizando eth0. Una solución que ofrece dhcpclient es usar "interface" para obtener la IP de eth0 y para la de eth0:1 usar la directiva "pseudo", teniendo que proporcionar además un script para configurar eth0:1 con la IP obtenida. Para más información, ver man dhclient.conf. Ojo, no usar como alias "eth0:0", pues el alias acabado en ":0" lo reserva precisamente dhclient para la opción "alias", que es para asignar otra IP estática a una interfaz mediante ipalias, para posibles usos en entornos de movilidad donde se requiera también una IP que no cambie con la ubicación. De todos modos la mejor opción es usar otro cliente de DHCP, en concreto udhcp, que sí pemite trabajar con interfaces creadas con ipalias NAT trasversal El NAT provoca sobre todo dos tipos de problemas: 1. Que la IP y puerto vayan dentro del payload del paquete, por lo que no concordará con el de las cabeceras IP que se modifican en el NAT. Este problema se da por ejemplo con SIP. 2. Que haya NAT en los dos lados, por lo que ninguna de las dos partes puede ser la parte que acepta la conexión entrante. Para el primer problema una posible solución es que en la máquina que hace NAT exista un módulo que reconoce ese protocolo y modifica también esos contenidos dentro del payload del paquete. Es lo que se conoce como un ALG (Application Layer Gateway). Un problema de los ALG es que en protocolos complejos como SIP limitan el protocolo y que funcionen posibles extensiones. Otro problema es que un ALG está funcionando como un "man in middle" que manipula el paquete, por lo tanto no funcionará si por ejemplo la aplicación está usando TLS para evitar manipulaciones. Otro tipo de solución es utilizar un servidor STUN (creado para UDP, aunque hay alguna extensión para TCP). El cliente detrás del NAT conecta con el servidor STUN para conecer la IP y puerto por el que sale. Esto puede resolver además el segundo problema con un tipo de dispositivos NAT, en los que el mapeo al puerto es el mismo dependiendo del puerto destino y no de la IP destino. Linux no hace este tipo de NAT, pero sí facilita las cosas utilizando el mismo puerto de origen si está libre. Otro tipo de servidores son los TURN, que hacen relay y por lo tanto son como redirectores. El problema es que mientras que un servidor STUN sólo se usa para establecer la conexión, un servidor TURN se utiliza durante toda la conexión para enviar todo el tráfico a través suyo. ICE es un mecanismo, originalmente creado para SIP, que consiste en probar distintas vías y métodos de conexión (conexión directa por cada interfaz, conexión vía STUN, conexión vía TURN) y entre los "candidatos" que tengan éxito se escoge al que se haya dado la mayor prioridad (normalmente a TURN es la que menos, luego STUN). Jingle, en Jabber (es tanto una especificación como una librería), utiliza también ICE 7. Otras soluciones pasan por modificaciones en la máquina que hace NAT (el middlebox), que permita por ejemplo a un programa pedir que se abran puertos o que le asigne un rango de puertos dentro de una IP pública, pero ninguna de estas soluciones son universales (una buena referencia es la página sobre NAT trasversal de la wikipedia, la versión en inglés). Algunas de ellas se mencionan en el apartado sobre Zeroconf y UPnP de este manual. Cabe esperar que algún día salgo algo más estándar de un grupo de trabajo del IETF como midcomm. Otra posibilidad interesante y antigua es SOCKS, que también permite abrir puertos. El atractivo de todas estas soluciones frente a STUN/TURN/ICE es que se basan en la colaboración con la política de seguridad de la empresa, no en tratar de abrir un agujero en el cortafuegos. Para IPsec una solución específica es NAT-T, pero por ejemplo en Windows XP SP2 hay que activarla editando el registro 8. 7 Maemo usa también libjingle y cuenta con un documento introductorio sobre NAT-T interesante: x/how_to_use_stun_in_applications.html 8 En este SP Microsoft desactivó NAT-T por defecto, por considerar un caso que podría ser un riesgo de seguridad. Esta decisión es muy discutida, pues no todo el mundo ve ese supuesto y consideran más inseguras las alternativas que ofrece a IPsec la propia Microsoft.

15 10 / Capa de transporte (Layer4) Sobre los datagramas IP va la capa de transporte. Aquí hay distintos tipos de protocolos, los más famosos son los TCP (que usan casi todas las aplicaciones) los UDP (que se usan para el DNS y para aplicaciones como streaming de vídeo o para construir los túneles de las VPNs). Hay más tipos de protocolos de transporte que UDP y TCP: DDCP, SCTP... También están implementados en GNU/Linux pero no lo están en todos los sistemas operativos. Hay que señalar así mismo que protocolos como ICMP e IGMP, así como distintos protocolos de enrutamiento, aunque sean posibles protocolos dentro de un paquete IP como TCP y UDP no son protocolos de transporte sino de red. Nos centraremos pues en la distinción entre UDP y TCP. TCP es un protocolo orientado a la conexión. Esto quiere decir que con TCP todos los paquetes que pertenecen a una conexión se numeran (el número de secuencia inicial se genera aleatoriamente para dificultar ataques de seguridad de falsificar una conexión) y se garantiza que llegan todos a destino y en el orden en que se enviaron. Al comienzo de la conexión, el primer paquete TCP lleva un flaq indicando que se quiere establecer una conexión. El protocolo TCP incluye mecanismos para confirmar la recepción de los paquetes (los paquetes que no se confirmen que se han recibido hay que volverlos a enviar) así como mecanismos de control de congestión (detectar que se están enviando más paquetes de los que permite el ancho de banda de la conexión y en ese caso bajar el ritmo). UDP en cambio es un protocolo sin conexión. Cada paquete es independiente de los demás. No hay ninguna garantía de que el programa llegue a su destino, ya sea porque hay errores o porque la red está saturada: si estamos saturando la red y por eso no llegan los paquetes nos tendremos que dar cuenta nosotros y tomar las medidas oportunas (bajar el ritmo de envío). Así mismo no hay garantía que los paquetes que lleguen lo hagan en el mismo orden en que se enviaron, dado que los paquetes IP pueden ir por rutas distintas. Qué aporta entonces la capa de transporte UDP sobre lo que proporciona la capa de red IP? por qué no enviar los datos directamente como datagramas IP en lugar de como paquetes UDP? El gran aporte de UDP, que también forma parte de TCP, es que además de incluir IP de origen y destino, incluye puerto origen y destino. El puerto destino es útil para poder ejecutar varios servicios en la misma máquina: por ejemplo en el puerto 80 puede estar el servidor web y en el 25 el servidor de correo. Podemos ver al puerto destino como una extensión y a la IP como un teléfono. El puerto origen también es muy útil: cuando el cliente envía un paquete elige un puerto origen libre y gracias a este puerto el servidor puede distinguir, a la hora de responder, entre dos conexiones procedentes de la misma IP. Por lo que hemos visto, TCP garantiza fiabilidad en la conexión mientras que con UDP si se quiere enviar una secuencia de paquetes todo se complica todo y además no hay garantía de que no se pierdan los paquetes. Qué sentido tiene usar entonces UDP? Para la mayoría de los protocolos de aplicación, ninguno: la mayoría requieren un canal de transporte orientado a la comunicación (que dicho sea de paso, podría ser TCP o cualquier otro actual como sockets UNIX o que se cree en el futuro, el API de programación de Unix es independiente del protocolo concreto que esté por debajo). Hay casos, sin embargo, en que UDP es útil: 1. Cuando se trata de un envío simple, de un único paquete y se espera otro paquete de respuesta. Aquí no es problema que el paquete se pierda: si el servidor no responde, se vuelve a enviar la petición. Con UDP sólo se envía dos paquetes (el de petición y el de respuesta), mientras que con TCP se envían varios paquetes para primero establecer la conexión y luego para cerrarla, además de implicar reservar/liberar recursos para el control de la conexión. Un ejemplo son las consultas DNS, o el uso de BOOTP/DHCP (en el caso de DHCP cuenta además que UDP es más fácil de implementar que TCP y puede que la petición BOOTP se haga desde un gestor de arranque o la ROM de arranque de una tarjeta de red, por lo que aún no hay sistema operativo. 2. Cuando no pasa nada porque se pierdan paquetes, pero lo fundamental es que los paquetes que lleguen lo hagan a tiempo, no perdiendo el tiempo en retransmisiones, confirmaciones y control de congestión. Es el caso de streaming de vídeo o la VoIP (voz sobre IP). Otro caso son protocolos de sincronización. 3. Cuando se usa el protocolo de transporte para hacer de túnel transportando otros paquetes, por ejemplo para implementar una VPN. Por un lado está que si transporta paquetes de vídeo con UDP porque lo fundamental es que lleguen muchos paquetes a tiempo aunque algunos se pierdan, si usamos TCP por debajo UDP ya no tiene ninguna ventaja: llegarán todos los paquetes, pero algunos demasiado tarde, más tarde de lo que hubieran llegado si no hubiera TCP por debajo. Con los paquetes TCP estaríamos innecesariamente aplicando dos veces el control de errores, de congestión, de que llegan los paquetes ordenados... TCP está diseñado para ir sobre IP, no sobre TCP; sobre UDP también está bien porque sólo añade unas cabeceras, principalmente para los puertos. Es más, los algoritmos de control de congestión de TCP tienen un

16 11 / 60 indeseable efecto multiplicador cuando se aplican sobre una conexión que ya va sobre TCP, que se traduce en que tarda más en coger velocidad. Ocurre sobre todo sobre medios físicos propensos a errores, como Wifi. El motivo es que cuando por culpa de un error se pierde un paquete, los algoritmos de congestión lo atribuyen a que se está transmitiendo a demasiada velocidad, por lo que reducen el ritmo de envío de paquetes, con lo que la aplicación que crea los paquetes TCP percibe que hay congestión, pero además una severa, pues suele disminuirse la velocidad a la mitad. 4. Cuando la existencia de NAT en los dos extremos es un problema (conexión cliente a cliente). Con UDP, el enrutador que hace NAT sabe que los paquetes que reciba con destino al puerto origen son paquetes de respuesta y debe dejarlos pasar, no hay propiamente un cliente y un servidor: con TCP esto es más complicado al entrar en juego el flag syn y los números de secuencia, por lo que en la práctica es mucho más difícil lograr que dos máquinas tras NAT logren una conexión TCP que UDP. El protocolo de transporte DCCP ofrece como TCP control de congestión, pero al igual que UDP no garantiza que todos los paquetes se entreguen ni que lleguen en orden. Básicamente es útil para los mismos casos que UDP, pero con la ventaja de no tener que implementar en la capa de la aplicación el control de congestión. Al estar poco extendido no obstante hoy en día no encontraremos ningún programa conocido que use este protocolo. El protocolo de transporte SCTP ofrece las mismas características que TCP, pero además ofrece algunas ventajas (con todo apenas se usa, en Windows no está implementado por Microsoft y hace falta instalar software de terceros, pero es especialmente útil para usar con SIP, por ejemplo 1. Multistreaming: permite transportar sobre un único canal varios streams, que se tratarán independientemente en temas como garantizar el orden de recepción de los paquetes (incluso a nivel de stream se puede desactivar el tema del orden si no es necesario). Esta característica es muy útil para trasmitir la señalización de la VoIP de varias llamadas, de hecho SCTP se creó para transmitir SS7 (señalización número 7). 2. Multihoming: en los extremos puede haber más de una interfaz, esto permite por ejemplo usar a la vez dos Ethernet o pasar de una Ethernet a una Wifi sin interrumpir la conexión. 3. Mantiene límites de los mensajes: con SCTP si se escribe un mensaje de 100 bytes al leer en el otro extremo se leen 100 bytes; con TCP esto no está garantizado. 4. mecanismos para evitar ataques syn flood; también elimina problemas en cierres de conexiones que presenta TCP Capa de aplicación (Layer5; Layer7 en OSI) Finalmente la última capa es el protocolo de aplicación, por ejemplo HTTP (web), SMTP (correo) o XMPP (Jabber). En Unix estos protocolos se escriben utilizando sockets, que se utilizan (sobre todo cuando la capa de transporte es TCP) prácticamente igual que los ficheros. Existe una especificación de un framework llamado BEEP (RFC , 3620), con implementaciones libres, que permite crear protocolos de aplicación olvidando temas como la autenticación y negociación de un canal seguro (para lo que usa SASL y TLS respectivamente) así como el modo de multiplexar varios canales sobre una conexión o manejar mensajes asíncronos (en cambio el formato de los mensajes en sí es libre). También estandariza la creación de túneles (proxies). Dado que con los sniffers es posible espiar el tráfico de red, un mecanismo de seguridad muy utilizado en las aplicaciones es añadir una capa intermedia en la capa de aplicación sobre la que realmente va el protocolo: esta subcapa lo que hace es cifrar los paquetes y añadirles información de control para detectar si alguien los intenta manipular. El protocolo más estándar par implementar esta funcionalidad es TLS (anteriormente conocido como SSL). Ojo, puede parecer que un switchs elimina la posibilidad de que un nodo en una red local espíe las comunicaciones entre otros nodos, utilizando un sniffer. Al fin y al cabo con un hub todo el tráfico se reenviaba a todos los nodos y el nodo en escucha realiza una actividad totalmente pasiva e indetectable, pero con un switch se supone que cada nodo sólo recibe los paquetes que van destinados a él. Lamentablemente no es así, existen sniffers como que funcionan también con switchs 9. Así mismo hay sniffers especializados como oreka.sf.net, que sirven para grabar VoIP, generando un fichero de audio. 9 Otro sniffer, o conjunto de sniffer revelador de que los switch no son suficientes para evitar que se espíe el tráfico de red es dsniff ( Este paquete por un lado incluye sniffers pasivos, algunos especializados para tareas como capturas contraseñas, correos, URLs (hay otro programa al margen de dsniff especializado para grabar VoIP en ficheros de audio, oreka.sf.net) y por otro programas para atacar los switchs. Así mismo incluye programas para hacer ataques "man in middle" para servidores SSL y SSH cuando se usan certificados autofirmados o sin comprobar, presentando uno falso sobre la marcha.

17 12 / 60 El problema es el ARP Spoofing/Port Stealing y ARP Poisoning. El ARP poisoning consiste en enviar al nodo que queremos engañar una respuesta ARP en el que indicamos que nuestra dirección MAC es la correspondiente a la dirección IP del nodo que queremos suplantar. La mayoría de los sistemas operativos no ven nada extraño en que les llegue este paquete aunque no lo hayan solicitado y lo almacenan en su caché ARP y en los que no se puede trucar con un ping. El ARP posioning actúa falsificando la IP no la dirección ARP, por lo que es difícil de detectar y evitar por parte del switch. Otras técnicas (Port Stealing) explotan engañar al switch haciéndole creer que tenemos la dirección ARP de la máquina a suplantar (los swtich que no soporten Safe Port, es decir, que permitan que cambie el puerto asociado a una dirección MAC). Así mismo hay ataques que buscan saturar con entradas falsas la tabla CAM del switch, pues necesariamente esta tabla tiene capacidad limitada. La buena noticia es que estos ataques ya no son pasivos sino activos y son detectables con herramientas apropiadas como arpwatch (que hace escucha pasiva) o el propio ettercap. Más información: Si necesitamos un sniffer para hacer comprobaciones de red o aprender sobre protocolos, el sniffer recomendado es Wireshark. Hay más herramientas útiles para depurar problemas en las redes, además de los sniffers. Por ejemplo iftop ( ): muestra consumo de ancho de banda, al estilo de top, mostrando origen y destino de la conexión. Utiliza libpcap (como sniffer) por lo que al ponerlo en la máquina que hace de router podemos ver quién está consumiendo en ese momento más ancho de banda. Una herramienta extremadamente útil para depurar problemas de red y aprender sobre redes es Netcat. Esta utilidad permite conectarse a cualquier socket TCP/UDP y enviar/recibir datos como si estuviéramos escribiendo en un terminal. De igual modo puede escuchar en un puerto TCP/UDP. Es muy útil por ejemplo para probar antes de montar una VPN si hay visibilidad entre las Ips y puertos: escuchamos con netcat en un lado y desde el otro enviamos. Así, para escuchar tráfico UDP en el puerto 9037 (opcionalmente con -s se podría indicar una IP, en el caso de ser un puesto multihome, con más de una interfaz de red): netcat -u -l -p Para enviar tráfico a el puerto 9037 desde otra máquina: netcat -u Otra herramienta aún más versátil que netcat, pero mucho menos conocida, es socat ( Permite usar todo tipo de conexiones, incluso sockets RAW, sockets Unix, ficheros, crear dispositivos TUN/TAP, usar SSL, abrir un PTY, usar un socket HTTP o SOCKS... Se recomienda usar también un NIDS (sistema detector de intrusiones de red, también suele usarse el acrónimo IDS, pues la mayoría de los IDS son NIDS, pero los hay específicos para una aplicación o para un sistema, que analizan llamadas al sistema). El más conocido es snort ( aunque es programa es polémico debido a que las nuevas reglas para detectar intrusiones ya no son libres, aunque sí gratuitas pero distribuidas con varios días de retraso para los clientes no de pago: un sitio dónde hay reglas que sí son libres es Snort es un NIDS reactivo; permite tomar medidas para neutralizar el peligro, frente a los NIDS pasivos que sólo lo detectan. Los sistemas de este tipo se conocen como IPS (Intrusion Prevention System; sistemas de prevención de intrusiones). También es útil disponer de un sistema de detección de vulnerabilidades como Nessus (lamentablemente desde la versión 3 no es software libre, pero hay un fork que sí lo es el problema de todos modos es tener una base de datos de vulnerabilidades que sea de libre uso); ojo con utilizar esta herramienta en una red que no administremos, entre los cometidos de un NIDS como snort es detectar este tipo de monitorizaciones. No confundir un detector de vulnerabilidades o security scanner con un escaneador de puertos (port scanner), como nmap, aunque el escaneo de puertos forme parte del proceso de búsqueda de vulnerabilidades. Nmap no detecta vulnerabilidades, sino localiza qué máquinas hay en la red, qué puertos tienen abiertos, qué sistemas operativos usan y qué versiones de los servidores de red utilizan. Un NIDS también detectará escaneos con Nmap, por lo que sólo deberían usar esta herramienta administradores de redes que tratan de encontrar vulnerabilidades en su propia red, principalmente debidas a máquinas "incontroladas" que no siguen la política de seguridad fijada para la red. Para redes wireless hay programas como kissmet ( que actúa de forma pasiva y no es detectable, permitiendo detectar de hecho ataques de programas no pasivos como netstumbler, además de poder usarse con snort y con otros sniffers (para lo cual deberemos conocer la clave). Un programa de "wardriving" (localización de redes Wifi desplazándose con un vehículo y un portátil con la tarjeta en modo monitor) es swscanner ( un uso lícito de este tipo de programas es detectar redes no autorizadas o que no siguen la política de seguridad de la empresa u organización, otro es comprobar temas de cobertura y un tercero depurar problemas de conexión.

18 13 / 60 Capítulo 3 Autoconfiguración: DHCP, PXE, Zeroconf 3.1. Servidores DHCP Un servidor DHCP sirve para que los equipos presentes en una red obtengan su configuración de red automáticamente. Así, el servidor asigna a cada equipo su IP y lo comunica su máscara de red, las rutas, el DNS, servidor de impresión, servidor de hora, zona horaria etc. Opcionalmente permite hacer un arranque vía red. Además es posible definir nuevos parámetro de configuración si se extienden también los clientes DHCP para que reconozcan y apliquen estos parámetros. DHCP es un protocolo surgido con posterioridad a BOOTP; en realidad es una extensión compatible con él, es decir, un cliente BOOTP también puede operar con servidores DHCP. El servidor DHCP permite al administrador asignar una IP manualmente a un cliente (manual allocation); permite asignarlas automáticamente sin que caduque nunca la asignación (automatic allocation) o permite asignarlas automáticamente por un tiempo limitado (dynamic allocation), de tal modo que si el cliente no vuelve a pedirlas antes que finalice ese tiempo se marcará la IP como libre. El servidor DHCPD guarda en una tabla las asociaciones entre clientes e IPs. El servidor identifica al cliente a través de su identificador de cliente, si es que lo proporciona, en otro caso usa su dirección MAC. En un segmento Ethernet puede haber más de un servidor DHCPD; el cliente envía usando broadcast un mensaje DHCPDISCO- VER (puede indicar en él la IP que le gustaría tener y durante cuánto tiempo) al que responden con un mensaje DHCPOFFER los servidores presentes; en ese mensaje ya va la IP que le ofrecen y los datos de configuración. El cliente escoge el servidor que quiere utilizar enviando una petición DHCPREQUEST que incluye el identificador del servidor; esta petición también es broadcast, para que sepan el resto de servidores que su ofrecimiento se ha rechazado. En la petición además se pueden solicitar datos de configuración adicionales. Si el servidor acepta la petición del cliente responde con DHCPPACK (dónde irá configuración adicional si la solicitó el cliente), o DHCPNAK si la rechaza, debido por ejemplo a que la IP ya está asignada; a priori no tiene mucho sentido que un servidor rechace la petición del cliente cuando son los datos que le acaba de ofrecer, pero en realidad un cliente puede hacer una petición DHCPREQUEST sin acabar de recibir un DHCPOFFER; por ejemplo una vez que ya se tiene una IP para renovar el "alquiler" se pide directamente la IP al servidor DHCPD que nos la dio sin necesidad de hacer DHCPDISCOVER. Finalmente, el cliente tiene la opción de rechazar el mensaje DHCPPACK. Así mismo el cliente también tiene la opción de liberar la IP que se le ha asignado, con DHCPRELEASE. En las peticiones DHCP es muy importante el uso del broadcast. Para permitir que funcione el DHCP sin necesidad de poner un servidor en cada subred se usan BOOTP/DHCP relay agents, que se encargan de reencaminar estas peticiones. Para casos como una VPN, en la que el nodo que se conecta lo queremos asignar una IP de la red local, posiblemente no nos funcione usar un cliente dhcp normal, ni siquiera acompañado de un relay. Una posible solución es ejecutar un cliente dhcp con la interfaz de la red en la que está el servidor DHCP (no pasa nada porque ya haya otro si se usan identificadores de cliente distintos y distinto fichero para guardar la ip asignada (lease), pero con un script que en lugar de configurar esa interfaz con la IP asignada se encarga de configurar la VPN para que use esa IP.

19 14 / Software DHCP 1. Clientes: dhcpcd, dhcp-client (dhcp3-client), pump, udhcp (cliente muy pequeño) 2. Servidores: dhcp3-server, udhcp-server (servidor muy ligero) 3. Relays: dhcp3-relay, dhcp-helper. Es más ligero y más fácil de utilizar dhcp-helper. 4. Otros: dnsmasq: servidor caché DNS y servidor DHCP muy básico, útil para sistemas empotrados o para casos en que se necesita una implementación mínima y no un servidor para utilizar por muchos clientes. Ltsp-server: sistema de clientes ligeros, usan DHCP para obtener la configuración y arrancar vía red DHCP vs ZeroConf y UPnP Zeroconf ( es un sistema de autoconfiguración de dispositivos, que pretende que los dispositivos funcionen con sólo conectarlos a la red, sin necesidad de que para ello existan servidores en la red local (servidores DHCP, DNS o directorio). Hay otras alternativas a Zeroconf como UPnP de Microsoft. El componente más extendido de zeroconf es Ipv4 Link local Addresses (IPV4LL), que se define en el RFC1397. El propósito de IPV4LL es que un equipo obtenga automáticamente una IP sin necesidad de que exista un servidor DHCP, RARP ni de ningún otro tipo. El modo de lograrlo es elegir al azar una IP dentro del rango reservado para este sistema: /16; se comprueba que la IP no está en uso, si lo estuviera se escoge otra hasta encontrar una libre. La utilidad de este sistema frente a DHCP está en redes "ad-hoc" (sobre la marcha), por ejemplo para comunicar dos equipos a través de un cable cruzado o conectándolos a una red local pero sin afectar al resto de equipos. También puede ser útil en una red pequeña aislada en una oficina o en una casa, dónde no se quiera tener encendido un servidor para hacer de DHCPD. Sin embargo lo normal en una red de empresa o de casa es que haya un acceso a Internet utilizando un router ADSL, que ya integra un servidor DHCP. Otro tipo de redes "ad-hoc" interesantes son las MANET (Mobile Ad-hoc NETwork) como las wireless mech network que usan OLSR, pero quedan fuera del alcance de este manual. En GNU/Linux existe el proyecto zeroconf.sf.net, que ha creado el programa zcip que implementa Ipv4LL. UPNP también usa IPV4LL, tras intentar usar un servidor DHCP. En Windows podemos comprobar que cuando configuramos la red para obtener la IP automáticamente, primero intenta usar un servidor DHCP y si no lo logra obtiene una IP aleatoria: eso es porque implementa Ipv4LL. Otro componente interesante que aporta Zeroconf es mdns (multicast DNS). Este sistema sirve para reemplazar al DNS. Así mismo zeroconf aporta DNS Service Discovery (DNS-SD) que permite utilizar el DNS para localizar servicios, por ejemplo el servidor Jabber. DNS-SD se puede implementar sobre mdns o sobre un servidor DNS convencional. La idea de mdns es que cada nodo incluye su propio servidor que responde con su IP cuando alguien pregunta por su nombre o hace una búsqueda inversa (el nombre a partir de la IP). En el caso de usar mdns para implementar DNS-SD, el servidor proporciona información sobre los servicios que ofrece la propia máquina. La consulta se hace utilizando broadcast: la idea es la misma que para obtener el nombre NetBIOS de un equipo de Windows cuando no hay DNS ni servidor Wins. El utilizar el servidor DNS para localizar servicios no es una idea nueva: el servidor de correo correspondiente a un dominio siempre se ha localizado así (aunque no el servidor de correo saliente). Así mismo el RFC 2782 (Service Types) describe el registro SRV para los servidores DNS que extiende lo que se hacía con el correo a todo tipo de servicios: por ejemplo Jabber usa este tipo de registros. Zeroconf usa también otro tipo de registros DNS: los TXT. La utilidad de estos registros sobre los SRV, es que los SRV están pensados para que se ofrezca una máquina por tipo de servicio o en todo caso varias, pero a efectos de balanceo de carga o redundancia. Los registros TXT son útiles para servicios como impresoras: en una red puede haber varias impresoras pero normalmente no interesa usar una cualquiera sino que se puede preferir una u otra en función de por ejemplo si imprime o no en color o determinado tamaño o si está en la misma planta que el usuario. En los registros TXT además del nombre del servicio aparece una etiqueta, la instancia (instance) que admite caracteres UTF-8. Cualquier etiqueta DNS está limitada a 63 bytes; ojo, que en UTF-8 caracteres como la eñe o los acentos ocupan dos bytes. Los registros TXT permiten más flexibilidad: por ejemplo se puede poner un servicio para ver una página personal y entre la información no sólo estará el nombre del servidor y el puerto sino la ruta. La funcionalidad de DNS-SD es utilizable en más casos que Ipv4LL. Por ejemplo en las empresas para descubrir impresoras, servidores de ficheros.. Incluso hay aplicaciones como sistemas para compartir archivos. En el escritorio se integra en el panel de control y permite navegar por los servicios disponibles en la red.

20 15 / 60 DNS-SD añade además unos nombres de host específicos al DNS para indicar que es navegable para descubrir servicios: b._dns-sd._udp IN ; b = browse domain lb._dns-sd._udp IN ; lb = legacy browse domain En GNU/Linux la implementación de mdns y DNS_SD recomendada es Avahi ( Proporciona un demonio y una librería para las aplicaciones. En Apple la implementación de Zeroconf primero se llamó Rendezvous y luego Bonjour. Lo implementan como software libre y está portado también a Windows. Mucha gente conoce más estas marcas de Apple que Zeroconf, debido a que esta iniciativa ha sido impulsada por Apple, al migrar de AppleTalk a TCP/IP y querer conservar el carácter autoconfigurable propio de AppleTalk. UPnP trata de ofrecer funcionalidades similares a mdns y DNS_SD, pero no son compatibles y la implementación es más compleja. Va más allá e incluye posibilidad de hacer llamadas SOAP, o abrir puertos en un firewall para traspasar el NAT. Esto último lo hace IGD (Internet Gateway Device) y hay una implementación para GNU/Linux: sin embargo conviene saber que IGD es una característica insegura y que potencialmente un nodo podría hacer que se abran agujeros que suponga acceder desde el exterior a otras Ips si se hace IP Spoofing. Apple también tiene su alternativa a IGD, que es NAT-PMP (NAT Port Mapping Protocol), que implementan también proyectos libres como Stallone. La parte que más éxito ha tenido ha sido UPnP AV, que trata sobre dispositivos de audio y vídeo con conexión a red. Hay varios proyectos multimedia que pueden hacer streaming para dispositivos UPnP o ser los reproductores: por ejemplo Myth, VideoLan, Geexbox, MediaTomb... UPnP AV distingue entre servidores de contenido (MediaServers, que opcionalmente pueden encargarse también de convertir entre formatos, MediaAdaptor), reproductores (MediaRenders), controladores y mando a distancia. Un servidor libre multiplataforma escrito en C++ es FUPPES; también libre en ese lenguaje es Mediatomb, mientras ushare está escrito en C. Todos ellos funcionan también sobre dispositivos empotrados ARM como el NSLU2. Por supuesto estos protocolos no son los únicos para implementar servidores de streaming: por ejemplo está también icecast o el estándar del IEFT RTSP (recibe comandos como PLAY, luego el vídeo se envía con RTP 1, usándose RTCP como protocolo compañero de RTP para controlar estadísticas sobre la calidad del servicio). Así mismo hay tecnologías "peercasting" basado en uso de peer-to-peer como alternativa al alto coste de usar unicast o la poca flexibilidad de multicast. SLP: sistema de descubrimiento, a diferencia del de UPnP y el de Zeroconf sí es estándar IETF. No muy extendido, excepto para localizar las impresoras de red. Hay una implementación libre que es OpenSLP. Funciona con un servidor, pero también puede estar más descentralizado, utilizando broadcast/multicast PXE Una opción interesante en una red para ahorrar costes en los equipos y coste de mantenimiento es utilizar un sistema de clientes ligeros (como TCOS [ LTSP, PXES o ThinStation), con arranque vía red (el arranque vía red también es típico para montar clusters). Para ello se utiliza una tarjeta con una ROM de arranque, que vía DHCP y TFPT descarga el kernel (o más frecuentemente un cargador más potente que es quien descarga el kernel) y luego monta el sistema de ficheros vía algún sistema como NFS o SMB (entornos NAS: Network Area Server) o menos frecuentemente, con un servidor SAN (Storage Area Network, se utiliza un disco externo vía red, directamente). Hoy en día normalmente ya no hay que sobreescribir una EEPROM para añadir arranque de red, sino que viene integrado en la BIOS de cualquier placa la solución estandarizada por Intel: PXE, que es el acrónimo de Preboot Execution Environment, estandariza cómo descargar un software para descargar un cargador de red (Network BootStrap Program, NBP) que se encargará del arranque (así pues es un sistema de carga en cadena, pues lo que carga es el cargador a utilizar). Un cargador de red hecho para cargarse vía red desde un equipo con una BIOS o tarjeta de red que soporte PXE es LinuxPXE. Existe un proyecto para crear un cargador de red, Etherboot, que puede grabarse en muchas tarjetas de red del mercado, lo que es útil tanto para sistemas muy antiguos que no soporten PXE, como si se desea instalar directamente un sistema más simple. Con el proyecto gpxe, Etherboot se ha reorientado a crear una versión que extiende PXE, con funcionalidades como isci o la posibilidad de descargar un kernel de un servidor web. gpxe no tiene por qué grabarse en la ROM de una tarjeta o en la BIOS de un equipo: también puede usarse en cualquier dispositivo de arranque (CD, disquete, llave USB) o simplemente ser el cargador 1 RealTime Transport Protocol: se suele encapsular sobre UDP (aunque no tiene un rango de puertos fijos asignados, el hecho de usar un rango dinámico complica su uso con NAT) y puede usarse en multicast además de unicat. Además de para streaming es habitual para videoconferencia, en ese caso para la señalización se usa SIP, H.323 o Jingle en lugar de RTSP. Aunque RTP es el protocolo más usado para transmitir voz y vídeo, otra opción es IAX (Inter-Asterisk Exchange) que tiene la peculiaridad de encapsular en la misma conexión la señalización y los datos y poder multiplexar varios flujos en uno. Esto sobre todo lo hace mucho más adecuado frente a NAT y cortafuegos que RTP, además de más eficiente en consumo de ancho de banda.