Tabla de contenidos
Por un tema de unidad, se usará la misma distribución en todo el curso. OpenSuSE tiene la ventaja de ser bastante amigable. Además es la distribución instalada en los laboratorios.
Sin embargo, OpenSuSE no es la distribución recomendada para un servidor de red, un cortafuegos o una VPN en una empresa. En general tampoco es una distribución adecuada para usar en empresas, sino que es más bien para uso personal: lo mismo puede decirse de distribuciones como Fedora, Mandriva o las versiones normales de Ubuntu.
El motivo es que no es una distribución de ciclo largo, que tenga actualizaciones de seguridad durante años. Esto se traduce en que al cabo de unos meses de instalarla tendremos que actualizar a la siguiente versión de OpenSuSE y repetir este proceso con sucesiones versiones. 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 por máquina una subscripción anual. 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 Dapper o un derivado de Red Hat Enterprise como 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 en estos momentos está en fase de transición, pues la actual versión (2.0) está un poco anticuada, con un kernel 2.4, mientras que la versión en desarrollo (3.0) están aún en fase alpha. Está mantenido por una empresa, que comercializa una versión coorporativa y extensiones. Algunas de las extensiones de pago de Smoothwall, como la gestión del ancho de banda, son características que están disponibles libremente en Ipcop. 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.
Mi recomendación personal es IPCop. La documentación de la página web también está muy trabajada y hay una relación de añadidos para IPCop sorprendentemente completa, además de incluir de serie un IDS (detector de intrusiones). Por ejemplo puede agregarse un filtro de contenidos (SquidGuard, DansGuardian), o un módulo para iptables para ajustar el ancho de banda en las conexiones peer-to-peer (Emule, Bittorrent...)
IPCop es una solución para un cortafuegos. No es buena idea poner un gran número de servicios sobre un cortafuegos, incluso alguno de los que trae sería buena idea desactivarlos y ponerlos en otra máquina. Hay otras distribuciones orientadas a servidores de empresa. Destacaremos dos:
SMEServer (www.smeserver.org/). 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.
ClarkConnect: (http://www.clarkconnect.com/). Servidor de correo, impresión, ficheros, backup... Hay distintas ediciones, una libre y otras de pago.
Para evitar la dependencia de SuSE, no se usará la herramienta de administración Yast, sino o bien herramientas genéricas o configuración manual.
Para entender los conceptos avanzados de redes, es muy útil tener presente el modelo en capas de las redes. Cada capa presta servicio a la capa superior encargándose de implementar una funcionalidad. La capa superior pasa a la que está debajo los datos que quiere enviar y cada capa hace lo propio con la capa inmediatamente inferior, tras añadir a lo que recibió de la capa superior cabeceras específicas de su capa.
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.
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, 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). La capa 2 es la más baja que ven los bridges, switchs y hubs.
Layer 3: capa de red. La capa IP. Es la capa más baja 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).
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.
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.
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. Lo mismo ocurre con mecanismos que utilizan posibilidad de broadcast de las redes ethernet.
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, cada fabricante tiene asignado un rango de direcciones MAC para evitar que se repitan). 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 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 por medio 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.
Sobre la capa física 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 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 192.168.. 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 192.168.120.7, 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 saber
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 echo 1 > /proc/sys/net/ipv4/ip_forward. 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 fordwarding para unas interfaces de red sí y para otras no, por ejemplo para eth0 sería /proc/sys/net/ipv4/conf/eth0/forwarding.
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.
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, 192.168.120.19/24 indica que la máscara de bits es de 255.255.255.0. 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.
Hay protocolos de frontera interior como RIP, OSPF, IS-IS y protocolos de frontera exterior, como BGP. 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: http://www.linux-magazine.com/issue/31/Zebra.pdf
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.
Una característica interesante de Linux es que un dispositivo de red Ethernet puede tener más de una IP, puede tener cuantas Ips queramos. Virtualmente es como si tuviéramos varias Ips con una única tarjeta.
Así, si tenemos la interfaz eth0 con la IP 192.168.1.1 y queremos tener otra interfaz con la 192.168.1.2, simplemente creamos:
ifconfig eth0:1 192.168.1.2
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.
Esta funcionalidad se llama ipalias.
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 VPNs).
Hay más tipos de contenidos que UDP y TCP: así, los ICMP son paquetes de control, 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 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.
Otros tipos de paquetes de los que no vamos a hablar pero que van directamente sobre la capa IP son distintos protocolos de encaminamiento (para pasarse entre los routers información dinámicamente sobre las rutas que deben seguir los paquetes).
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:
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.
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.
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 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.
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.
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 swtich se supone que cada nodo sólo recibe los paquetes que van destinados a él. Lamentablemente no es así, existen sniffers como http://ettercap.sourceforge.net/ que funcionan también con switchs. Así mismo hay sniffers especializados como oreka.sf.net, que sirven para grabar VoIP, generando un fichero de audio.
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: http://en.wikipedia.org/wiki/ARP_spoofing
Si necesitamos un sniffer para hacer comprobaciones de red o aprender sobre protocolos, el sniffer recomendado es Ehtereal, que ha cambiado de nombre recientemente a whireshark.
Hay más herramientas útiles para depurar problemas en las redes, además de los sniffers. Por ejemplo iftop (http://www.ex-parrot.com/pdw/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 9037. Para enviar tráfico a el puerto 9037 desde otra máquina: netcat -u 83.59.36.220 9037
Se recomienda usar tambíen un IDS (sistema detector de intrusiones). El más conocido es snort (http://www.snort.org/), 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.
Para redes wireless hay programas como kissmet (http://kismetwireless.net/) que actúa de forma pasiva y no es detectable, airsnort (http://airsnort.shmoo.com/) y swscanner (http://www.swscanner.org/)
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 DHCPDISCOVER (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.
Software DHCP:
Clientes: dhcpd, dhcp-client (dhcp3-client), udhcp (cliente muy pequeño)
Servidores: dhcp3-server, udhcp-server (servidor muy ligero)
Relays: dhcp3-relay, dhcp-helper
Otros: dnsmasq: servidor caché DNS y servidor DHCP, los nodos añadidos aparecen en el DNS; ltsp-server: sistema de clientes ligeros, usan DHCP para obtener la configuración y arrancar vía red.
Zeroconf (www.zeroconf.org) 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: 169.254.0.0/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.
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.
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 PTR @ ; b = browse domain
lb._dns-sd._udp IN PTR @ ; lb = legacy browse domain
En GNU/Linux la implementación de mDNS y DNS_SD recomendada es Avahi (http://avahi.org/). 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: http://linux-igd.sourceforge.net/; 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. 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...
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 centralizado, utilizando broadcast/multicast.
Múltiples redes IP en una misma tarjeta: ipalias.
Supongamos la red local de una empresa, dónde hay un enrutador que tiene que comunicar estas redes entre sí:
red local con los equipos de los usuarios y servidores de impresión. Están todos en la red 192.168.120.0/24
red local de otra empresa del parque tecnológico con la que colaboran un grupo de usuarios. Esta red es 10.2.0.0/16. La otra empresa ha pedido que los equipos de la red local no vean directamente su router, sino que haya un enlace punto a punto entre los servidores de las dos redes. Las Ips serán visibles en ambas redes, es decir, desde 192.168.120.* se verán las Ips de 10.2.*.* y viceversa.
acceso a Internet con router ADSL. Hay una única dirección IP, luego habrá que hacer NAT con configuración multipuesto, aunque también podríamos ponerlo en multipuesto y que el NAT lo haga la máquina Linux que actúa de router.
Para esta configuración necesitamos tres tarjetas de red para la máquina Linux que hará de router: una será para la red local (192.168.120.0/24), otra para conectarse con la red de la empresa y una tercera para el router ADSL para la conexión a Internet. ¿Nos las podíamos haber apañado con una sola tarjeta utilizando ipalias? pues realmente sí. El problema es que no es la configuración más adecuada, pues lo deseable es que desde la red local no accedan directamente a Internet ni a la red de la otra empresa y desde luego separar también Internet y la red de la otra empresa y poder poner cortafuegos en medio. Si se usa una única red física no hay tal separación y cualquier nodo podría tratar de espiar la red.
Tanto para conectarnos con la red de la otra empresa como con el router ADSL, utilizamos sendas redes con máscara de 30 bits, es decir de dos nodos. Por ejemplo con la red 192.168.200.84/30 nuestro nodo tendrá la IP 192.168.200.85 y el otro router la 192.168.200.86.
Los enrutadores tienen más de una dirección IP, dado que tienen una IP en cada interfaz de red que enrutan. Ahora bien, cuando una máquina que tiene varias direcciones IP se comunica con otra máquina ¿qué IP origen figura en los paquetes? la IP de la interfaz de red por la que saldrá el paquete.
Esto puede ser problemático en algunos casos. Por ejemplo en nuestra configuración, en la interfaz eth1 que conecta nuestra red con la red de otra empresa. Resulta que los equipos de la red de la otra empresa no saben cómo llegar a 192.168.200.86: los equipos de ambas redes conocen las Ips 192.168.120.0 y 10.0.0.0, pero no conocen la red 192.168.200.84/30, que es un artificio para comunicar los dos enrutadores. Así pues, cualquier paquete que proceda de nuestro enrutador y vaya a una dirección de la red 10.0.0.0 llevará como IP origen 192.168.200.86, por lo que podrá llegar a destino pero luego no llegarán los paquetes respuesta. Podemos hacer una prueba muy sencilla: un simple ping a una máquina de la red 10.0.0.0 y veremos que la IP origen es 192.168.20.86 y no nos llega la respuesta, mientras que desde otra IP de la red sí.
La solución pasa por utilizar como IP origen 192.168.120.19 también cuando los paquetes vayan a la red 10.0.0.0 y no sólo cuando vayan a la red local. Ante esto caben dos enfoques:
Configurar cada programa que necesita contactar con la red 10 para que use la IP 192.168.120.19. Cada programa se configura de forma distinta. Por ejemplo con un ping basta indicar la IP con la opción -I, con SSH se indica mediante la opción BindAddress...
Hacer NAT: mediante iptables ponemos una regla para que todo paquete con la dirección origen 192.168.200.86 que vaya a salir por la interfaz eth1 cambie su IP a 192.168.120.19. Esta regla sería:
iptables -t nat -A POSTROUTING --source 192.168.200.86 -o eth1 -j SNAT --to-source 192.168.120.19
¿Qué solución es más apropiada? Depende. La segunda obviamente es más directa, pues no hay que cambiar programa a programa. Ahora bien, por seguridad desde el enrutador no se debería acceder a más equipos de la otra red que los imprescindibles, por ejemplo los servidores DNS. Obligarse a reconfigurar cada programa que hay lo necesita es obligarse a mantener controlado a qué servicios de la otra red estamos accediendo desde el router.
Para conectarse desde casa o desde otra ubicación a la red del trabajo, hay distintas alternativas:
Usar una VPN, de modo que nuestro ordenador de casa virtualmente esté en la red de la empresa, pero a través de una conexión cifrada vía Internet. Esta es la opción más potente, pero también la más compleja. Una empresa que tenga una política estricta de seguridad sobre las máquinas instaladas en la red, con el filtrado de red, se encontrará con que cada vez que se conecte el usuario se añade a su red local un nodo que puede estar en una red insegura (aunque esto depende también de la configuración, un equipo puede conectarse a la red remota y desconectarse del resto). Es una opción especialmente interesante cuando el usuario usa un portátil tanto cuanto está en la empresa como en su casa.
Conectarnos remotamente a nuestro escritorio del PC del trabajo, usando un túnel con SSH (también se puede hacer con SSL), con lo que sólo habría que abrir un puerto en el cortafuegos de la empresa. Es una solución más conservadora, pues virtualmente el usuario está usando su monitor, teclado y ratón para acceder a la máquina del trabajo, pero por ejemplo no puede ni transferir ficheros entre su equipo local y el de la oficina (aunque algunas soluciones de escritorio remoto sí lo permiten) o conectarse desde su equipo de casa a ningún servicio. Para el usuario también es una solución sencilla, pues está usando su equipo de la oficina en el que ya está todo el software instalado y configurado. Sin embargo no es una solución idónea si por ejemplo el usuario tiene que escribir un documento y luego enviarlo: para eso sería más razonable que lo pueda editar en su equipo y conectarse a la intranet de la empresa. Además esta posibilidad no está disponible cuando el trabajador que se conecta remotamente no tiene un PC de sobremesa en la oficina sino que usa un portátil que se lleva a casa.
Técnicamente usando SSH se pueden abrir más túneles para por ejemplo acceder a la web interna o transferir ficheros, pero eso ya supone mayor conocimiento por parte de los usuarios y es así mismo posible limitar estas posibilidades. De todos modos en el momento que se permite al usuario crear un túnel encriptado potencialmente se le está dando acceso total a la red local de la empresa, pues el usuario puede utilizar el túnel para encapsular lo que quiera, incluyendo por ejemplo una sesión PPP para implementar así una VPN completa.
Usar lo que se ha dado en llamar, no con demasiada propiedad, SSL VPN. Es el caso del programa SSLExplorer Community Edition. Este tipo de solución es intermedia entre las dos anteriores. Ofrece una interfaz web, que completada con código Java permite navegar por el disco duro de la máquina remota, transferir ficheros entre las dos máquinas, navegar por la intranet de la empresa... Se implementa también con un túnel SSL y permite crear túneles para distintas aplicaciones y lanzar la aplicación en cuestión, por ejemplo rdesktop para conectarse a un escritorio remoto de Windows.
Un detalle de nomenclatura, es que OpenVPN se define también como una SSL VPN pero no tiene nada que ver con esto, puesto que es una VPN real, que permite todo lo que ofrece cualquier otra VPN, mientras que las aplicaciones como SSLExplorer no son realmente VPNs. Se define como SSL VPN porque la VPN se encapsula en un túnel SSL y sólo hay que abrir un puerto
Supongamos que queremos conectarnos desde casa con el puerto 8080 en la máquina 192.168.1.100 de la red local de nuestra empresa. Para ello contamos con una máquina SSH que está dentro de la red local de la empresa y a la que llegamos a través de un DNAT que hemos hecho en el cortafuegos. En este caso hemos abierto el puerto 34321 del cortafuegos, que tiene la IP pública 87.15.10.120: los paquetes con este destino cambiarán de 87.15.10.120 a 192.168.1.1:22. Así pues, cuando nos conectemos vía ssh a 87.15.10.120:34321, llegamos en realidad al puerto SSH de 192.168.1.1.
La solución está en utilizar la posibilidad que ofrece SSH de crear túneles. SSH es un protocolo que no sólo encripta y garantiza la integridad de los datos, sino que es capaz de encapsular cuantas conexiones necesitemos en una sola. Así, nuestro propósito es que SSH cree un servidor local en nuestra máquina, por ejemplo con el puerto 8081, recoga todo lo que escribamos en él, lo envíe encriptado hasta la máquina 192.168.1.1 (la máquina remota a la que nos hemos conectado vía SSH) y desde allí los desencripte y los envíe al puerto 8080 de la máquina 192.168.1.100; los paquetes de respuesta seguirán el proceso inverso, hasta llegar al puerto 8081 local de nuestra máquina. Observesé que en el caso del túnel los paquetes pasan por la capa de aplicación, mientras que en el NAT simplemente se modifican las cabeceras a nivel IP y TCP para hacer el NAT. La máquina 192.168.1.100 no verá como IP origen de los paquetes a la IP de nuestra casa, sino a 192.168.1.1, la máquina SSH que ha retransmitido el paquete.
En la práctica, hacer el túnel es tan sencillo como:
ssh -N 801020.13 -p 34231 -o ServerAliveInterval 1200 -L8081:192.168.1.100:8080
La opción -N es para crear el túnel pero no iniciar una shell. La opción ServerAliveInterval es para enviar cada 2 minutos un paquete en caso de que la conexión esté inactiva, para evitar que el cortafuegos asuma que la conexión esté muerta y olvide la asociación NAT. Es posible añadir más opciones interesantes. Por ejemplo por defecto el puerto 8081 que ha creado ssh es sólo accesible dentro de nuestra máquina, si quisiéramos que pudieran conectarse a él otras máquinas de nuestra red local, añadiremos la opción -g.
Es posible también crear túneles en los que el puerto servidor se abre en la IP a la que nos conectamos remotamente (en este caso 192.168.1.1) y que se enviara a una IP y puerto de nuestra red local. Esto nos permite crear servidores en la red local de nuestra empresa (para que el puerto sea accesible desde todas las Ips de la red local de la empresa y no sólo desde 192.168.1.1, habrá que usar la opción -g).
Así, si queremos crear el puerto 8087 en 192.168.1.1 y que todo lo que se reciba allí vaya al puerto 9000 de la IP 192.168.7.3 (en nuestra red local de casa) usaríamos:
ssh -N 801020.13 -p 34231 -o ServerAliveInterval 1200 -g -R192.168.1.1:8087:192.168.7.3:9000
Como puede verse, los túneles SSH son muy potentes y un tanto inquietantes desde el punto de vista de la seguridad para un administrador: podemos hacer un túnel para usar el escritorio remoto, para conectarnos a la web de la empresa, para enviar correos desde casa utilizando el servidor SMTP de la empresa, e incluso para ejecutar una aplicación en local que usa una BB.DD. de la red, cambiando la configuración para que use un puerto en nuestra máquina local y usando un túnel. Es más, es posible crear toda una VPN como veremos más adelante, con sólo la posibilidad de crear túneles de SSH.
Por este motivo el administrador de SSH puede desactivar el uso de túneles o especificar exactamente qué túneles se pueden usar, así como permitir o denegar obtener una shell o permitir ejecutar sólo un comando en concreto. Puede así mismo no permitir el acceso al sistema no dándole una contraseña y autenticando por clave pública: el propio fichero de clave pública almacenado en el servidor tendrá las restricciones que se aplican cuando se accede con esa clave, pudiéndose tener distintas claves para un mismo usuario según se le permita ejecutar una tarea u otra.
La funcionalidad de SSH no acaba aquí. Es posible que un usuario se conecte a una máquina y desde ahí a otras. Si utiliza claves públicas para autenticarse, SSH incorpora un sistema, el ssh-agent, que permite autenticar al usuario estando conectado en otra máquina y sin que nuestra clave privada salga de nuestra máquina.
Para usuarios con Windows, en lugar de utilizar el cliente en línea de comandos pueden recurrir a Putty, un programa con interfaz de usuario basada en ventanas y que en realidad también se puede ejecutar en GNU/Linux.
VPN es el acrónimo en inglés de red privada virtual. El objetivo es lograr, mediante la creación de un túnel IP encriptado sobre una red pública como Internet, que los nodos a conectar por la VPN virtualmente estén en una misma red local. Es posible establecer una VPN directamente entre dos nodos, pero lo más habitual es o bien una VPN entre un nodo remoto y la red local de la empresa (esta configuración en inglés se llama con frecuencia road warrior, guerrero de la carretera, hace mención a que un usuario móvil se conecta a la empresa con su portátil y una conexión a Internet desde allí dónde está desplazado) o una VPN que une dos redes, por ejemplo dos filiales de una empresa o una filial con la central.
Hay distintas tecnologías y productos para crear una VPN con implementaciones libres para GNU/LInux:
IPsec: el estándar por excelencia, será obligatorio en IPv6 y está implementado en muchas pilas TCP/IP también para la actual generación IPv4, incluyendo el kernel Linux. Se implementa directamente sobre la capa 3 (IP) mientras que el resto de soluciones suelen implementarse a nivel de capa de aplicación. A diferencia de otras soluciones permite tanto túneles como directamente encriptar la capa de transporte, lo que es útil cuando sólo se quiere seguridad entre dos máquinas o ya se implementa el túnel sobre una capa posterior (típicamente la de aplicación, utilizando paquetes UDP).
PPTP: protocolo impulsado por Microsoft. Su implementación original tenía varios fallos graves y además existe el problema de que no está tan probado como IPSec siendo también relativamente compleja. No es un estándar, aunque se publicó un RFC informativo describiendo el protocolo. El nombre completo es Point to Point Tunneling Protocol. Hay clientes de PPTP en Windows desde Windows 95, aunque Microsoft trata ahora de substituir PPTP por LLTP e IPsec, si bien PPTP ha tenido cierto éxito por su sencillez de configurar: no se usan claves públicas, sino las propias cuentas de Windows para autenticar el acceso.
Hay implementaciones para GNU/Linux interoperables con la implementación de Microsoft tanto del cliente (http://pptpclient.sourceforge.net/) como del servidor (http://pptpclient.sourceforge.net/) . A destacar que los desarrolladores de estas implementaciones recomiendan no usar PPTP más que si no queda otro remedio: en su lugar recomienda OpenVPN o IPsec.
L2TP: Layer 2 Tunnel Protocol: promovido por Microsoft y CISCO, sigue la vía de estandarización del IETF. Es un protocolo que hace túneles a nivel de la capa de aplicación (mediante paquetes UDP), como lo que encapsula es PPP, encapsula tráfico layer2. En realidad L2TP no implementa por sí sólo una VPN, dado que no encripta la información, por lo que o bien usa PPTP o lo recomendado, usa un túnel IPsec.
¿Qué sentido tiene usar L2TP sobre IPsec, pudiendo usar directamente IPsec? el primer matiz es que se podrían encapsular varios túneles L2TP y cada uno puede autenticarse conforme a L2TP (lo que no evita que también haya que usar el mecanismo IKE en el túnel IPsec). L2TP crea túneles a nivel 2, por lo que puede ir todo tipo de tráfico, no necesariamente IP, por ejemplo puede ir tráfico IPX o incluso se puede transportar directamente paquetes de nivel 2 como ATM. L2TP en gran medida es más interesante para proveedores de Internet que tengan que encapsular información, que para VPNs entre oficinas (por ejemplo para revender acceso a Internet), pero en cualquier caso se agradece que haya implementaciones para GNU/Linux pues habrá servidores que no permitan conectarse directamente usando IPSec (quizás por desear usar la autenticación PPP) y requieran L2TP. En el artículo de la Wikipedia hay enlaces a las implementaciones existentes así como a un tutorial: http://en.wikipedia.org/wiki/L2TP
OpenVPN: es la solución recomendada, por su sencillez: hace un túnel TLS sobre el que se encapsulan paquetes layer 3 (IP) o layer 2 (Ethernet), pero usando UDP en lugar de TCP, aunque también se puede usar sobre TCP e incluso pasar a través de proxies HTTP. En realidad TLS no se puede implementar directamente sobre UDP, porque requiere un protocolo fiable como TCP y con UDP se tiene que permitir la pérdida de paquetes. Por ello en realidad TLS se usa para la funcionalidad de control, como negociar la sesión TLS o renegociarla en un momento dado (implementando sobre UDP un sistema para pedir de nuevo los paquetes que se puedan perder y son importantes por ser de control), sustituyendo a los protocolos PKI de IPSec. Pero además se han imitado los mecanismos presentes en las cabeceras ESP de IPSec para dar seguridad a nivel de paquete y con independencia de si se pierde el paquete anterior: para ello hay que añadir una secuencia a los paquetes, así como un HMAC y contemplar varios mecanismos. Una idea similar es la que se sigue en la implementación del estándar DTLS (Datagram TLS: http://es.wikipedia.org/wiki/Datagram_Transport_Layer_Security) que se define en el RFC4347 y cuya única implementación actual conocida es la que hace el proyecto OpenSSL. En http://unix.freshmeat.net/projects/dtls_example/ hay código de ejemplo. Es posible que en un futuro se modifique OpenVPN para usar DTLS en lugar de su propio protocolo.
Montar una VPN sobre la marcha con OpenSSH y pppd. Es una solución de compromiso ante una necesidad puntual. Si hemos instalado SSH y dejamos que pase el cortafuegos por si necesitamos conectarnos o lo usamos para encriptar un tunel con la conexión el acceso a escritorio remoto, en un momento dado podemos instalar una VPN. La idea es utilizar el software de PPP (pppd) para crear los dispositivos de red en cada extremo y comunicarlos por un túnel SSH: el software PPP escribe por salida estándar lo que lee del dispositivo de red e igualmente lo que lee por salida estándar lo pone en el dispositivo de red. Con SSH se pueden comunicar las entradas salidas de dos programas, formando un túnel. Si lo preferimos, podemos hacer el túnel utilizando Stunnel en lugar de OpenSSL.
Hay implementaciones de IPSec para cualquier sistema Unix, MacOS X, Windows XP/2000... Una implementación de IPSec consta de dos partes: la implementación sobre la pila de protocolos TCP/IP, en el kérnel y el demonio y herramientas que se ejecutan en el espacio de usuario para establecer las claves (esto es la parte IKE: Internet Key Exchange). En principio es posible utilizar la parte IKE de una implementación sobre la pila de protocolos de otra. Así, la implementación integrada en el kernel Linux (llamada NETKEY) no incluye herramientas IKE, por lo que hay que usar las de otra implementación: habitualmente se usa la implementación del proyecto Kame (surgido de un consorcio de empresas japonesas como Fujitsu y Toshiba para hacer una implementacion de Ipv6 e Ipsec), que es la implementación usada en Free/NetBSD y en MacOS X; el demonio IKE de Kame se llama Racoon y el conjunto de utilidades portadas para Linux que además de Racoon incluye otras como setkey es ipsec-tools (http://ipsec-tools.sf.net); en Ubuntu Dapper se incluyen los paquetes ipsec-tools y Racoon (se ha sacado en un paquete aparte el demonio porque es posible también usar IPSec sin demonio, utilizando claves precompartidas).
También se puede usar por ejemplo como demonio IKE isakmpd (de la implementación de OpenBSD) o Pluto. Pluto es el demonio IKE de la antigua implementación de IPsec para Linux, FreeSWAN, que nunca llegó a formar parte del kernel; FreeSWAN dejó de desarrollarse pero tomaron el relevo dos proyectos: OpenSWAN (www.openswan.org) y StrongSWAN (www.strongswan.org). Mientras que OpenSWAN sigue desarrollando la pila de protocolos KLIPS como alternativa a la integrada en el kernel, NETKEY, en StrongSWAN no. StrongSWAN es compatible no sólo con IKE1 sino con IKE2: de la compatibilidad con IKE1 se encarga el viejo demonio Pluto, mientras que para IKE2 hay un nuevo demonio llamado Charon. La flexibilidad de programas como StrongSWAN o OpenSWAN son inmensas: incluyendo toda una infraestructura de clave pública basada en certificados X.509, con la posibilidad de utilizar dispositivos como smartcards y teniendo en cuenta aspectos como que los certificados pueden revocarse y ya no ser válidos, que pueden obtenerse de servidores LDAP...
Para usar IPSec hay que abrir en los cortafuegos el puerto 200 UDP, pues lo usa IKE. También hay que tener en cuenta que los paquetes tienen un número de protocolo distinto al IP, por lo que también podría haber problemas en el cortafuegos.
El lado negativo de IPSec es que es una solución muy compleja. Al margen que esa complejidad podrá afectar más o menos al usuario según los asistentes para configurar una VPN (el problema está en que todo se complica más si los sistemas operativos de los nodos a conectar son distintos, frente a la sencillez de usar una implementación de VPN más simple que tenga versión para distintos sistemas operativos) desde el punto de vista de la seguridad son preferibles las soluciones sencillas. Hay gente que no le gusta tampoco de IPsec frente a otras soluciones que se ejecute mucho código en el espacio del kernel (por ejemplo la parte de encriptación, que en el caso de OpenVPN se ejecuta en el espacio de usuario) dado que un error de seguridad ahí es fatal al comprometer todo el sistema, si bien tiene un impacto positivo en el rendimiento. Esta objeción es opinable: es cierto, pero también la información sensible está más protegida a nivel del kernel.
¿Qué inconvenientes tiene usar OpenSSH + PPPD? el principal inconveniente es que no es buena idea implementar el túnel de una VPN sobre TCP, es mejor utilizar UDP. El motivo es porque TPC tiene mecanismos de control de congestión que no funcionan de la mejor forma cuando una conexión TCP a su vez se encapsula sobre una conexión TCP: se produce un efecto multiplicativo que hace que ante una congestión se reduzca la velocidad enormemente y que tarde mucho en coger de nuevo velocidad. Hay una explicación de este fenómeno en http://sites.inka.de/sites/bigred/devel/tcp-tcp.html. Otro argumento para usar UDP es que podemos tener aplicaciones UDP que usan este protocolo por la necesidad de que los paquetes lleguen siempre a tiempo, sin importar si se pierde alguno: como se usa TCP, los paquetes nunca se descartan y se gasta tiempo en retransmisiones.
Paradójicamente, hay casos en los que usar un túnel TCP sí puede tener alguna ventaja sobre un túnel UDP. Si un protocolo UDP está mal diseñado frente a un ataque que selectivamente hace que determinados paquetes se pierdan, el que vaya sobre TCP sería una ventaja puesto que entonces TCP nos garantiza que ningún paquete se pierda ni llegue fuera de orden.
Otro inconveniente es que PPPD requiere privilegios de superusuario, aunque se pueden hacer cambios en la configuración para que no sea necesario, atendiendo a que el programa se ejecuta con el bit setuid. Crear un dispositivo TUN/TAP también requiere privilegios, pero es distinto, porque una vez creado con un programa, se puede hacer que esté disponible para otros programas lanzados sin privilegios.
Supongamos que la IP pública dónde escucha el servidor SSH es 157.88.66.102 y el puerto es 8088 . Vamos a crear una conexión punto a punto, en el que la IP local del enlace punto a punto (esta IP será la que tendrán como origen los paquetes lleguen a la red remota a través del túnel y tengan como origen la máquina local) será 172.16.16.15 y el remoto 172.16.16.16. Realmente podemos escoger el par de Ips que queramos, con tal que la IP remota no esté en uso en la propia red, teniendo en cuenta que en el otro extremo la IP local será la remota y por lo tanto la que no tiene que estar presente; no pasa nada porque la IP local sea la IP asignada a otra interfaz de red de la máquina. Ejecutamos:
pppd updetach nobsdcomp nodeflate usepeerdns noauth connect-delay 10000 pty "ssh root@81.33.18.197 -o ServerAliveInterval=120 -p 9436 -t -t pppd noauth 172.16.16.16:172.16.16.15"
La opción updetach es para que el programa pase a segundo plano tras lograr ejecutar la conexión (es decir, se ejecuta como si fuera un demonio, liberando el terminal). Las opciones nobsdcomp y nodeflate son para evitar que se use compresión, que no se llevaría bien con el usar un túnel SSH. Basta ponerlas en el lado cliente, pues se negocian para los dos lados de la comunicación. La opción "usepeerdns" es para que se actualice nuestro /etc/resolv.conf con los datos del servidor DNS del extremo con el que conectamos; a fin de usar su DNS en lugar del nuestro. Sin embargo es posible que esta opción no nos funcione, pues requiere que haga su trabajo el script local /etc/ppp/if-up, que no siempre tiene en cuenta estos datos, por lo que es posible que tengamos que modificarlo manualmente. La opción noauth se usa para que no use la autenticación PPP: no hace falta, dado que ya usamos la de SSH. La opción connect-delay en este caso indica que no intente establecer la conexión PPP hasta transcurridos 10 segundos; el motivo es que el pppd en el otro extremo se ejecuta al lograr autenticarnos con el servidor SSH, para lo que tendremos que introducir la contraseña antes; es decir, nos damos 10 segundos de margen para lograr ejecutar en el otro extremo pppd vía ssh. Finalmente la opción pty es para usar como script de conexión, con el se comunicará usando un pseudo-tty, lo que va entrecomillado, que no es otra cosa que lanzar pppd en la máquina remota. Entre las opciones de SSH, a destacar ServerAliveInterval: le estamos indicando en este ejemplo que envíe un paquete cada 2 minutos si no se transmiten datos, a fin de garantizar que el posible NAT que haga algún enrutador no se pierda por considerar que la conexión ya no está activa.
En realidad es posible simplificar la instrucción anterior, así como mejorar la seguridad, usando para autenticarse con el servidor un certificado y configurando en el servidor que al conectarse con ese certificado en lugar de poder ejecutar cualquier programa ejecute una orden determinada, que en nuestro caso sería la invocación a pppd.
Tras ejecutar esta operación, tendremos un nuevo dispositivo ppp0, con IP local 172.16.16.15 e IP remota 172.16.16.16. Para llegar a las máquinas remotas caben dos opciones: una es que perdamos la conectividad local, usando como ruta por defecto 172.16.16.16; esto lo podemos hacer con "route del default && route add default gw 172.16.16.16", aunque también podíamos haber pasado directamente la opción "defaultroute" a pppd para que hubiera aplicado este cambio automáticamente. Sin embargo, al ejecutar esta operación nos encontramos con un problema: no funciona, porque hasta el servidor SSH tenemos que llegar usando nuestra antigua ruta por defecto (la de nuestro router que nos permite salir a Internet). Así pues, añadimos una ruta:
La otra opción es que sólo añadamos una ruta específica para llegar a las Ips de la red remota y que para la ruta por defecto sigamos usando la ruta que tenemos. Así, si la red remota es 192.168.10.0, ejecutaremos:
route add -net 192.168.10.0 -netmask 255.255.255.0 gw 172.16.16.16
Esta segunda alternativa encierra más riesgo de seguridad, pues si hay agujeros en nuestra máquina y estamos conectados a Internet, estaremos arriesgando la red remota, pues los paquetes que vienen de nuestra máquina no pasan por el cortafuegos de la red remota.
Con la IP que hemos escogido como dirección local, los paquetes que enviemos llevarán como IP origen 172.16.16.15 (la IP local en el enlace punto a punto); posiblemente en la red destino no sepan cómo llegar a esta IP desde otro nodo que el del servidor SSH, por lo que sería una conexión host a host, salvo que precisamente la máquina del servidor SSH sea el enrutador por defecto. Aún así, si por ejemplo este router a su vez pasa al testigo a otro para llegar a Internet o determinadas redes, con esa IP no llegaremos porque no se esperan que la IP 172.16.16.15 esté en ese router.
Hay dos formas de solucionarlo. Una es utilizar como IP local una IP de la red destino que no se esté usando y pasar al servidor la opción proxyarp. En ese caso cuando desde un nodo de la red local se pregunte por la IP, responderá la máquina donde está el servidor SSH con su propia dirección ARP y hará una redirección. La otra solución es hacer NAT; supongamos que la IP en la red remota del nodo que es servidor SSH es 192.168.10.7; entonces habría que ejecutar en la máquina remota (para lo cual podemos usar nuestro ssh) la orden para añadir la regla NAT:
ssh 81.33.18.197 -p 9436 iptables -t nat -A POSTROUTING --source 172.16.16.15 -j SNAT --to-source 192.168.120.19
Esta solución tal como está es sólo para los paquetes procedentes del equipo local: si lo que hemos hecho es usar el túnel VPN para unir a la red remota toda la red local ya es más complicado, pues la IP origen será la de la máquina de procedencia.
En realidad, si se tiene acceso a una máquina de la red local remota vía SSH, hay un método más sencillo para que nuestras aplicaciones de red accedan a los nodos de la red remota como si nuestra máquina estuviera allí. Se trata del servidor de SOCKS5 que integra OpenSSH. Este servidor se arranca en nuestra máquina local en el puerto que le indiquemos con la opción -D. Cualquier cliente que utilice ese proxy SOCKS accederá a la red remota, pues el proxy hace las peticiones en la máquina remota: todas las peticiones y respuestas van tuneladas y encriptadas en la conexión SSH. De este modo, es como si las aplicaciones pudieran crear túneles SSH a petición, pero utilizando un protocolo estándar, SOCKS.
Una característica interesante de SOCKS5 es que para establecer una conexión se puede pasar al proxy en lugar de la IP directamente el nombre de la máquina. Esta posibilidad es interesante, porque así usamos el DNS de la red remota, en lugar de el nuestro local, algo muy deseable si es un DNS privado.
Hay aplicaciones que se pueden configurar para usar SOCKS, como Firefox. No obstante Firefox por defecto no usa el DNS remoto. Para que sí lo haga, bastará con teclear about:config y cambiar la opción network.proxy.socks_remote_dns.
Muchas aplicaciones no soportan SOCKS. La buena noticia es que se pueden "sockificar": la idea es reemplazar en tiempo de ejecución la librería estándar de C para que ante un connect o un bind llame en su lugar al proxy SOCKS. La única pega es que esto no sirve para usar el servidor DNS remoto, aunque la alternativa es abrir un túnel con SSH al servidor remoto y usarlo en lugar del local. En algunos casos parece que también resuelve el caso del DNS, alterando la llamada para hacer la consulta para hacerla a través del servidor SOCKS. Ejemplo (sólo para TCP) http://proxychains.sourceforge.net/. Más programas en http://en.wikipedia.org/wiki/SOCKS.
"Sockificar" una aplicación es muy sencillo en cualquier programa que no tenga bit setuid: basta con usar LD_PRELOAD.
El hecho de usar protocolos conocidos y una librería muy probada como OpenSSL da mucha fiabilidad a este programa: es relativamente fácil fallar estrepitosamente a la hora de tratar de crear un nuevo sistema de VPN, como revela este interesante escrito de Peter Gutmann (el autor de cryptolib y la impresionante presentación/tutorial de criptografía de más de 800 transparencias)
que habla de CIPE, VTUN y TINC: http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt. Del mismo autor, un artículo más elaborado sobre el tema: http://www.linux-magazine.com/issue/39/VPN_Insecurity.pdf
OpenVPN consta de un único ejecutable (para ambos extremos es el mismo) y un fichero opcional de configuración, además de los ficheros de claves.
Uno de los puntos fuertes es que es multiplataforma: el poder usar exactamente el mismo programa en GNU/Linux, cualquier BSD, Solaris, Mac OS X o Windows XP/2000 supone hacer una VPN en la que intervengan equipos con cualquier sistema operativo sin problemas de interoperabilidad.
OpenVPN permite hacer túneles a nivel de la capa 3 (la opción por defecto y la recomendada, se usa un dispositivo TUN) o a nivel de la capa 2 (usando un dispositivo TAP). Si usamos la capa 2, podemos utilizar un puente. Sólo tiene sentido usar la capa 2 para transferir tráfico no IP o cuando necesitemos la funcionalidad de un puente.
Una funcionalidad interesante de OpenVPN desde su versión 2.0 es crear un único servidor al que pueden conectarse distintos clientes, para crear cada uno su propia red privada virtual con la red local en la que está el servidor.
Supongamos que queremos conectarnos las máquinas con IP públicas 83.59.36.220 y 81.33.18.197. La primera tiene abierto en el cortafuegos el puerto UDP 9037, mientras que la segunda tiene el 1198. Vamos a crear una red privada virtual, en el que el primer nodo tendrá la IP 10.4.0.2 y el segundo el 10.4.0.1.
La configuración más sencilla de manejo de una clave común es utilizar una clave compartida. Para ello en primer lugar la generamos en uno de los nodos:
openvpn --genkey --secret static.key
A continuación la subiremos al otro nodo utilizando algún procedimiento seguro. Por ejemplo con scp (parte de SSH). Hecho esto ya podemos crear la VPN:
En el nodo 81.33.18.197, ejecutamos:
openvpn --remote 83.59.36.220 --rport 9037 --lport 1198 --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 -secret static.key
En el nodo 83.59.36.220 ejecutamos:
openvpn --remote 81.33.18.197 --rport 1198 --lport 9037 --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --secret static.key
En ambos nodos ejecutamos:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -I FORWARD -i tun+ -j ACCEPT
La primera línea es para activar el forwarding entre interfaces de red, o lo que es lo mismo, la posibilidad de enrutado. La segunda línea es para evitar que rechace el cortafuegos el tráfico procedente de la interfaz tun. En esta línea hemos puesto I (Insert) en lugar de A (append) como viene en la documentación. Realmente es más apropiado append, puesto que así si hay reglas específicas para filtrar no nos las saltaremos, pero para probar primero que podemos establecer conexión puede ser buena idea poner la regla la primera.
Una vez que veamos que todo funciona, podemos invocar estos programas con la opción --daemon.
Si no hemos logrado conectar, posiblemente haya un problema con el cortafuegos. Podemos probar con la herramienta netcat a enviar/escuchar paquetes en estos puertos UDP.
Así, en 83.59.36.220 ejecutamos:
netcat -u -l -p 9037
81.33.18.197 ejecutamos:
netcat -u 83.59.36.220 9037
A continuación escribimos algo: deberá aparecer en 83.59.36.220 y lo que escribamos allí aparecer en 81.33.18.197.
El uso de una clave compartida no es el método más seguro. Por ejemplo si se compromete la clave se comprometen todas las conversaciones pasadas. No es un sistema de "perfect forward security". Aclaremos que hay sistemas basados en PSK (Preshared keys) que sí lo son, pero no así el de OpenVPN. La diferencia es que en algunos sistemas las PSK hacen las mismas funciones que los certificados en TLS: sirven para autentificar a la otra parte, no para obtener la clave de sesión, que se determina utilizando Diffie-Hellman. En cambio con OpenVPN sirven para establecer la clave de sesión.
Es posible usar proxyarp también con OpenVPN, lo que ocurre es que la forma de activarlo sí que es dependiente del sistema operativo y habrá sistemas que ni siquiera lo soporten. En el caso de Linux sería con:
echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
Por supuesto también es posible activar proxy_arp a nivel de cada dispositivo de red, igual que en el caso del fordwarding.
El sistema X-Window desde sus orígenes se diseñó con vistas a la transparencia de red: una aplicación se visualiza y maneja desde un terminal, pero puede estar ejecutándose en cualquier máquina de la red con la que haya conexión TCP/IP. En la terminología X-Window, el PC del usuario ejecuta el servidor X, mientras que las aplicaciones son los clientes: la idea es que las aplicaciones hacen peticiones al servidor del tipo dibuja este mapa de bits o notificamé determinados eventos. El servidor notifica a los clientes eventos como pulsaciones de teclas o eventos del ratón.
Para ejecutar una aplicación desde una máquina remota a la que nos hemos conectado por ejemplo a través de un telnet o un ssh, lo primero que hace falta es que esté definida la variable DISPLAY, que indica el servidor a utilizar. Así, un valor :0 indica usar el servidor local (si hubiera más de uno, se incrementaría el número); con el valor 192.168.7.10:0, indicaríamos que conecte con el servidor X de la máquina 192.168.7.10.
El siguiente requisito, es que si la conexión es vía red, tiene que estar abierto en el cortafuegos el puerto TCP del servidor X. Este puerto por defecto es 6000 para el primer servidor (:0) y se va incrementando conforme se ejecutan más servidores sobre una misma máquina.
Finalmente, el servidor X tiene que permitir que el cliente se conecte. Hay dos formas:
método poco sutil, xhost. Ejecutando xhost desde nuestro servidor X damos permiso para que desde las Ips que indiquemos se puedan conectar a nuestro servidor. Así, con xhost +192.168.7.1 permitiríamos conectar desde esa IP. Con xhost + permitiríamos conectar desde cualquier IP. Ojo, no conceder este permiso con ligereza: un cliente puede espiar eventos de teclado, enviar eventos de teclado (nada divertido si tenemos una terminal abierta y envían un comando destructivo seguido de l evento de la tecla enter) o cuanto menos molestar bastante. A esto hay que añadir que al abrir una IP se abren a todos los posibles usuarios de la máquina si es multiusuario o al posible malware que tuviera instalado; así mismo no hay que olvidar la posibilidad del IP Spoofing.
método más adecuado, xauth. Para que el cliente pueda conectarse, salvo que se haya permitido explícitamente utilizando xhost como se describe en el método anterior, tiene que utilizar una "cookie" que está almacenada en la cuenta de usuario del servidor que ejecuta el servidor X-Window, en el fichero que indique la variable de entorno XAUTHORITY. Este es el motivo por el que en algunas distribuciones al cambiar de usuario, incluso al cambiar a root, no permite ejecutar aplicaciones X: la variable de entorno ya no apunta a este fichero, por lo que no se envía la cookie. Hay distribuciones en las que sí funciona al pasar a root, porque sudo, su o la orden que hayamos ejecutado para cambiar de usuario usa un módulo PAM para que al establecer una nueva sesión de usuario se copie la cookie. Como comentario adicional, con xhost es posible dar permiso para que abra conexiones cualquier cliente local con independencia de su usuario, pero no clientes remotos, mediante xhost +local:. Este mecanismo se apoya en que cuando cliente (aplicación) y servidor (terminal X) están en la misma máquina, no usan el socket TCP sino un socket Unix, que es sólo accesible localmente. De hecho si sólo vamos a permitir conexiones locales, es buena idea ejecutar el servidor X con la opción -nolisten tcp; es lo que hacen por defecto distribuciones como Ubuntu.
Mediante la herramienta xauth, podemos leer la cookie en el servidor X; luego también mediante la herramienta xauth, en la máquina remota, podemos añadir la cookie.
En realidad, el método recomendado para ejecutar aplicaciones remotas es conectarnos con ssh con la opción -X (si no añadimos además la opción -Y estamos sujetos a algunas restricciones de seguridad, a decir verdad no totalmente efectivas). Al ejecutar aplicaciones a través de SSH se usa para cada conexión un túnel encapsulado dentro de la conexión SSH, con todas las ventajas que implica: seguridad, al estar encriptado y protegido contra modificación y versatibilidad, pues no hay que abrir ningún puerto en el cortafuegos ni hay problema si nuestra máquina está tras una ADSL con NAT. La idea en que se basa es utilizar un proxy: crea un servidor X en la máquina remota y redirige todo lo que recibe por medio del túnel SSH al servidor X real que tenemos en nuestra máquina local. Gracias a este sistema funciona incluso aunque el servidor X se ejecute con la opción -nolisten tcp, pues la comunicación es local gracias al túnel.
Muchas veces la forma de ejecutar las aplicaciones remotas no es ejecutando aplicaciones sueltas, en nuestro escritorio local, sino ejecutando entero el escritorio remoto. Es decir, nos sale la pantalla de GDM o KDM que nos pide nuestro usuario y contraseña y a continuación entramos en un escritorio Gnome o KDE, pero que en realidad no es el de nuestra máquina, sino el de una máquina remota. Esta funcionalidad se apoya en el protocolo XDMCP, que por razones de seguridad suele estar desactivado (lo implementa el propio GDM/KDM). El protocolo usa el puerto UDP 177, pero sólo inicialmente; para mostrar la propia pantalla de Login ya recurre a la habitual conexión TCP con el puerto 6000, si bien automáticamente configura todo, incluyendo el fichero con la cookie, para que el usuario no tenga que hacer nada especial.
Hay servidores X libres disponibles también para Windows: recomendamos http://x.cygwin.com/.
VNC es un sistema que permite conectarse a un escritorio remoto. El servidor se ejecuta en el ordenador remoto a cuyo escritorio nos queremos conectar y el cliente en nuestra máquina. Toda la pantalla del escritorio se maneja dentro de una ventana, no es posible como con X-Window ejecutar cada aplicación en su ventana, como si fueran aplicaciones locales. Así mismo es un sistema mucho menos avanzado que X-Window, basado simplemente en un framebuffer, retransmitiendo los cuadros que cambian (en cambio en X-Window se almacena información en el servidor, de modo que no hay que retransmitirla cada vez que se muestra por pantalla: como muestra un botón: el protocolo baso X-Window, sin extensiones, tiene 160 tipos de peticiones, respuestas y eventos).
Si VNC es menos avanzado que X-Window, ¿por qué hay gente que usa VNC en lugar de X-Window?
conectividad: VNC funciona sobre cualquier escritorio, incluyendo Windows: las aplicaciones Windows no son clientes X-Window, por lo que no podemos esperar usarlas remotamente utilizando este sistema.
conexión sin estado: cuando iniciamos una sesión remota con X-Window, no podemos en un momento dado decir, vale, me voy a casa, apago el monitor y me conecto luego desde casa y tengo todo como lo dejé, con el OpenOffice abierto editando un fichero y el visor de PDF por la página 85. El motivo es que los clientes están ligados a esa conexión con el servidor y en el servidor hay información de estado: si cerramos el servidor mueren las aplicaciones. En cambio con VNC realmente funciona la analogía monitor, teclado y ratón remoto.
rendimiento aceptable en una conexión vía Internet. Este punto es desconcertante, porque por diseño X-Window es mucho más eficiente que VNC y debería ofrecer mejores resultados con menos ancho de banda. De hecho usando una red local con X-Window realmente las aplicaciones parecen locales. ¿Entonces que es lo que ocurre? El motivo es el round-trip. Conforme pasaban los años, los desarrolladores se despreocuparon más de la posibilidad de ejecutar las aplicaciones remotamente vía Internet, sobre todo en un punto: las aplicaciones e incluso los propios toolkits hacen muchas consultas al servidor X y esperan una respuesta, pese a que en general X-Window funciona asíncronamente. Estas peticiones-respuestas tardan en procesarse cuanto menos el tiempo de latencia de la red multiplicado por dos (uno para enviar, otro para recibir). En una aplicación que se ejecuta en local, la latencia es de 0,1 ms, por lo que aunque haya miles de round-trips el efecto es inapreciable. En una red local la latencia es de 1ms, todavía asumible. Pero si usamos por ejemplo una ADSL, ya encontraremos latencias de 50ms, en una línea serie 200ms y estos valores subirán aún más en conexiones GSM o por satélite. Afortunadamente hay una tecnología que trata de soluciones estos problemas, NX, de la que también hablaremos.
VNC se ejecuta sobre una única conexión TCP, por lo que es muy fácil de securizar utilizando un túnel SSH, que es así mismo una solución interesante para permitir que los traajadores de una empresa puedan manejar en caso de necesidad su equipo de la oficina desde casa.
Muchas distribuciones incluyen una opción de permitir administrar remotamente el equipo (por ejemplo SuSE 10.2). Esta opción se implementa con VNC. También se implementa con VNC el "Apple Remote Desktop".
A veces en lugar de VNC leeremos RFB. Es el nombre del protocolo: Remote Frame Buffer.
Relación de software que implementa VNC: http://en.wikipedia.org/wiki/Vnc
Microsoft añadió soporte a su sistema operativo para poder ejecutar aplicaciones remotamente. En concreto lo implementó para Windows 2000 Server en el componente Windows Terminal Services, un sistema que permite al estilo Unix que varios usuarios estén conectados a la misma máquina. Evidemente para ello hay que pagar licencias, las de Windows 200x Server y la de Windows Terminal Services, esta última en función del número de clientes (una licencia por cliente que potencialemente se pueda conectar; fórmula menos ventajosa que licenciar por usuarios concurrentes y además propensa a abusos, pues la licencia cliente está incluida con algunas versiones de Windows, pero no con otros sistemas potencialmente clientes como GNU/Linux o Mac OSX). Como excepción, hay una licencia especial para usuarios que se conectan a través de Internet, que es la que se usa tienen en Hacienda para permitir que los usuarios de Linux y Windows hagan la declaración de la renta con el programa PADRE: la conexión es utilizando un cliente Cytrix (por Cytrix también se paga) pero a su vez Cytrix requiere Windows Terminal Services.
De todos modos por lo que es más conocido RDP es porque Windows XP Professional (no así Windows XP Home) incluye un servidor RDP limitado a una sola conexión y permitiendo una única sesión (es decir la máquina es monousario: o se usa en local o en remoto, pero no se puede tener a la vez una sesión local y otra remota). Lo mismo ocurre con las versiones más caras de Windows Vista (lo incluye a partir de Ultimate); también se incluye en Windows Media Center, Windows 2003 Server y Tablet Edition 2005. Es el famoso escritorio remoto, para el que existe un cliente libre también para GNU/Linux, rdesktop. con una interfaz gráfica muy intuitiva, tsclient. Teóricamente Microsoft podría cobrar también licencias por clientes
RDP ofrece mejor rendimiento que VNC. Sigue por detrás de X-Window, pero recordemos que X-Window tiene un problema práctico con el round-trip, que RDP. Hasta RDP 6, novedad en Windows Vista (también disponible al parecer para XP SP2) tenía la limitación de VNC: sólo permitía manejar el escritorio entero en una ventana, no una ventana por aplicación. El soporte para ejecutar aplicaciones cada una en su ventana (SeamlessRDP) lo permite excepcionalmente rdesktop con versiones más viejas de RDP utilizando un componente que se ejecuta en el servidor.
Otra ventaja común con VNC es que permite desconectar la sesión e iniciarla desde otra máquina dejando todo como estaba.
Añade alguna innovación como poder utilizar remotamente más dispositivos que el ratón, teclado y pantalla: por ejemplo la tarjeta de sonido o la impresora. Esto en Unix ha sido también siempre posible, a través del demonio de sonido y de impresión, la diferencia aquí es que todo se hace con un solo producto y en RDP 6 se han ido añadiendo más posibilidades.
RDP se ejecuta también sobre una conexión TCP, por lo que al igual que VNC es fácil de entular usando openssh o stunnel. En las últimas versiones permite encriptación usando TLS, mientras que el sistema de encriptación de las versiones viejas basado en usar RC4 no es seguro.
NX ( http://en.wikipedia.org/wiki/NX_technology ) es una tecnología de escritorio remoto desarrollada por una empresa Italiana, NoMachine. NoMachine comercializa su implementación propietaria de esta tecnología. Los clientes son freeware y hay también un servidor freeware, NX Free Edition, para GNU/Linux y Solaris, mientras que el servidor para Windows y MacOSX es de pago.
Lo más interesante es que Nomachine además publica el código fuente necesario para implementar esta tecnlogía bajo licencia GPL. Hay un proyecto que ha desarrollado un servidor a partir de este código fuente, el proyecto FreeNX (http://freenx.berlios.de). El código de FreeNX es bastante complicado de compilar: recomiendan usar la implementación que venga con la distribución. Es el caso de Open SuSE 10.2 y Ubuntu Dapper, pero versiones nuevas de Ubuntu se plantean no incluir FreeNX por lo difícil de manejar el código, auque quizás con las nuevas versiones lo reconsideren. FreeNX incluye el servidor, pero no un cliente. Como cliente mucha gente utiliza el freeware (pero privativo) de Nomachine. Otras opciones son ThinStation (http://thinstation.sourceforge.net/wiki/index.php/ThIndex), knx y sobre todo QtNX (http://blog.gwright.org.uk/articles/search?q=QtNX). QtNX actualmente requiere que para la parte del cliente estén instalados la versión 1.5 del componente (la versión vieja, con menos opciones que la nueva, por ejemplo poder ejecutar aplicaciones cada una en su ventana, modo rootless), pero funciona perfectamente con un servidor de la versión 2.0. Otra implementación completa de NX bajo GPL, al parecer obtenida tras comprar una licencia a NX: http://code.2x.com/linuxterminalserver/downloads. Esta solución es para NX 1.5, no para NX 2.0.
NX se implementa sobre X-Window para acelerarlo sensiblemente y eliminar round-trips. Así, gracias al uso de caché o el utilizar formatos tipo PNG en lugar de bitmaps se logran ratios de compresión del orden de 10:1 a 100:1. Gracias a estas compresiones es utilizable un escritorio remoto incluso a través de un modem.
En una serie de artículos sobre NX publicados en Linux Journal, se muestra como el inicio de sesión en KDE la primera vez supone transferencias de 4,1MB, pero gracias a NX y su caché las siguientes veces se queda en tan solo 35Kb.
NX aplica a X-Window mejoras que ofrece RDP, como el poder desconectar la sesión y conectarse desde otra máquina con todo como estaba (lo logra haciendo que el servidor X se ejecute en la máquina remota, mediante el agente nxagent, a la que se conecta el cliente NX) o el permitir transferencias de ficheros o utilizar por las aplicaciones remotas nuestra impresora o tarjeta de sonido local.
En realidad NX también se puede utilizar sobre RDP o VNC para acelerar también estos protocolos, pero los resultados que se obtienen son inferiores respecto a X-Window: como hemos comentado la tecnología de X-Window es superior a RDP, sólo que había problemas como los round-trips que en la práctica lo hacían poco utilizable sobre redes no locales.
Hay paquetes nxserver, nxnode y nxclient. El servidor necesita los tres, mientras que el cliente necesita nxnode y nxclient; la mayoría de los programas están dentro del paquete nxnode. Uno de los programas más importantes que incluye el paquete nxnode es precisamente el ejecutable nxnode, que un proxy que se ejecuta tanto en el lado local como en el remoto y que crea el túnel entre los dos lados. En el lado de la aplicación remota, nxnode ejecuta un agente que es el intermediario con la aplicación: para aplicaciones X-Window es nxagent, para RDP es nxdesktop y para VNC nxviewer. Nxagent funciona en la máquina remota como un servidor X-Window local.
Un tema que desconcierta a un nuevo usuario de NX, es que el servidor nxserver no es un demonio que tenga que lanzar el usuario y permanezca en ejecución a la espera que se conecten clientes. En realidad nxserver es un programa que lo ejecuta el cliente (nxclient) vía SSH, bajo la cuenta de usuario nx: la idea es similar al servidor de sftp que viene con OpenSSH. Otro dato desconcertante es que a priori cualquiera puede ejecutar nxserver, pues se ejecuta accediendo con una clave SSH que la clave privada es conocida por todo el mundo, pues viene con el cliente NX. Esto no debería ser un problema de seguridad, pues nxserver autentica al cliente antes de hacer nada (que es invocar nxnode), pero es mejor si cambiamos la clave por otra, aunque entonces habrá que cambiarla también en todos los clientes. Por defecto nxserver para autenticar al cliente usa su usuario y contraseña en el sistema, pero se puede mantener una lista de usuarios y contraseñas propia para no tener que usar la del sistema. Con nxserver --help podemos ver las ordenes disponibles para entre otras cosas administrar usuarios.
Si usamos el cliente oficial, es muy recomendable en configure/advanced la opción "enable SSL encryption of all the traffic". Esta opción tiene un nombre confuso, porque realmente no se usa SSL: lo que hace es utilizar la conexión SSH para entular todas las conexiones entre el nxnode local del cliente y el del servidor; estas conexiones irán encriptadas, pero no con SSL sino con el protcolo de SSH, que es similar pero no es SSL. El interés de esta opción no está sólo en que se encripte sino en pasar los cortafuegos: sin ella habría que abrir varios puertos, que además van cambiando conforme se abren nuevas conexiones.
Algunas ideas para probar por qué no funciona la conexión:
probar primero con el cliente oficial, con la opción "enable SSL encryption of all the traffic". El problema más frecuente es de cortafuegos.
probar a conectar al servidor con ssh -i /usr/NX/share/keys/server.id_dsa.key nx@ip_servidor ; ejecutar login ; si no autentifica probar a añadir el usuario manualmente. Si no ha sido posible conectar, comprobar si es problema de SSH; podemos por ejemplo conectarnos a la máquina y ejecutar su -- nx; si al entrar en la cuenta del usuario "nx" no se abre una shell en la que podemos ejecutar login, es que no está correctamente instalado.
Más información sobre NX: http://en.wikipedia.org/wiki/NX_technology
Usado para los menores, para gente que le molesta que le salga pornografía y para los puestos de trabajo. Es típico el uso de listas negras (blacklisted) pero en algunos casos se usa lo contrario, listas blancas: el usuario sólo puede navegar por esas webs.
Para los puestos de trabajo, es importante que los sistemas permitan relajar las normas a determinadas horas: por ejemplo si un trabajador llega antes de la hora no debería haber ningún problema en que lea el periódico, o que a la hora de descanso o en determinados momentos del día se permitan hacer gestiones personales por Internet. También permiten reglas distintas según la IP de origen.
Una funcionalidad importante de este tipo de software no es sólo filtrar sino registrar los accesos. En cierto modo su efectividad está más en el efecto disuasorio de pensar que si se está navegando por dónde no se debe quizás el jefe se entere que por la habilidad del programa para filtrar.
Las implementaciones existentes de software de filtrado para GNU/Linux se implementan sobre el proxy Squid. SQUID se puede configurar para usarlo de modo transparente (y por lo tanto obligatorio) utilizando DNAT, por lo que no es posible saltarse el proxy salvo que se pueda usar un túnel y salir por un puerto que no esté redirigido al proxy transparente.
Un software basado en filtrado por listas negras es Squidguard (http://www.squidguard.org/). Hay varios sitios dónde es posible conseguir listas negras, pero hay que tener en cuenta que en muchos casos para obtener listas actualizadas hay que subscribirse y cuesta dinero. Una lista gratuita es http://www.squidguard.org/shallalist.html; se actualiza regularmente, con un millón de entradas. Una lista de pago es http://urlblacklist.com/; la primera vez deja descargar gratuitamente y realmente no hace demasiado control para asegurarse que no descargamos más veces sin subscribirnos, confiando en la honradez del usuario. Tiene unas dos millones de entradas.
http://www.censornet.com/ Distribución de GNU/Linux que integra DansGuardian, administrable vía web. Comercializan subscripción a lista negra (como curiosidad el precio depende del país, más pagan los países desarrollados, los países subdesarrollados es gratis) y a un filtro de imágenes.
Puede no ser buena idea utlizar un proxy para todo. Sobre el papel usar SQUID para la web y SOCKS para otros protocolos obligaría a un uso responsable de la red, al estar autenticadas las conexiones. En la práctica la realidad puede ser más compleja y funcionar mejor soluciones más adaptativas, que simplemente tratan de ajustar el ancho de banda para que los usuarios que más consumen tengan menos prioridad. Pero si se usa un proxy SOCKS estas soluciones no funcionan, pues todos los paquetes proceden de la misma IP (si ya se ha pasado el proxy) o van a la misma IP (si es antes del proxy).
El filtado en Linux lo hace un componente del kernel llamado netfilter. La utilidad para configurarlo es iptables, aunque es muy habitual no crear las reglas de un cortafuegos a mano sino utlizando una herramienta con interfaz gráfica.
Netfilter maneja distintas tablas: hay una tabla para filtrado (filter), es decir para el cortafuegos, que es la tabla que iptables entiende que quremos utilizar si no le indicamos otra cosa con la opción -t. Otra tabla que se usa mucho es nat, para hacer SNAT (sobre todo para salir a Internet con una sola IP todas las máquinas de una red local) o DNAT (para abrir puertos en un cortafuegos, para hacer proxies transparentes, para hacer balanceo de carga entre varias máquinas...). Hay más tablas que no veremos, como mangle, que permite alterar los paquetes.
Cada tabla contiene cadenas. Los paquetes pasarán por unas tablas u otras. Así, en la tabla filter existen estas cadenas:
INPUT: por aquí pasan los paquetes que van destinados a la máquina
OUTPUT: por aquí pasan los paquetes que proceden de esta máquina, pero van destinados a otra
FORWARD: por aquí pasan los paquetes que ni proceden ni se dirigen a nuestra máquina, es decir, los paquetes que estamos enrutando.
En cuanto a la tabla nat, también tiene tres cadenas, aunque mientras que en filter cada paquete iba a una y sólo una de esas tres reglas básicas, aquí un paquete puede pasar por dos reglas:
PREROUTING: esta regla es para hacer DNAT de paquetes antes de enrutarlos, tan pronto como llegan a la máquina desde otra máquina.
OUTPUT: esta regla es para hacer DNAT de paquetes generados por la máquina con destino a otra máquina, antes de enrutarlos, para hacer DNAT
POSTROUTING: esta regla es para hacer SNAT de los paquetes justo después de determinar su ruta de salida.
Con iptables se añaden reglas a las cadenas (las reglas se pueden añadir al final, con -A o insertar al principio, con -I). Cada regla tiene unas condiciones de aplicación; por ejemplo una condición puede ser que la IP destino sea la 192.168.7.10 y el puerto destino sea el puerto TCP 8080. Así mismo cada regla tiene un target (objetivo) que es qué hacer con el paquete en caso de que se den las condiciones de aplicación de la regla: se establece con la opción -j, por ejemplo -j ACCEPT. Cuando se determina que a un paquete le es aplicable una cadena (por ejemplo llega un paquete con destino a un servidor de la máquina, luego le corresponde la regla INPUT) se va recorriendo la cadena secuencialmente hasta alcanzar una regla que tenga unas condiciones de aplicación que se ajusten al paquete. En ese caso se aplica el target de la regla.
El target puede ser un destino final: se ha decidido qué hacer con el paquete y ya no se miran más reglas. Por ejemplo ACCEPT para dejar pasar el paquete, REJECT para rechazarlo o DROP para no dejarlo pasar pero sin retornar un error ICMP, una práctica recomendable para no dar pistas a las aplicaciones que hacen escaneos de puertos, aunque para el caso TCP es más recomentable el target TARPIT (ver man iptables para ver cómo se usa). Otro target final es QUEUE, que permite pasar a una aplicación el paquete para que haga con él lo que quiera.
El target puede ser también un destino no final. Por ejemplo LOG registra el paquete; tras ejecutar esta target se siguen recorriendo las reglas.
El target puede ser otra cadena. El usuario pude crear sus propias cadenas, a las que añadirá sus reglas. En caso de poner como target una cadena, el resultado es que se salta a esa regla. Si se termina de recorrer la regla sin alcanzar ningún target final, se continuará en la regla siguiente al punto dónde se produjo el salto. También se puede retornar antes de llegar al final, con el target RETURN.
Las cadenas predefinidas (INPUT, OUTPUT, FORWARD... pero no las definidas por el usuario) pueden tener un target por defecto (que deberá ser un target final como ACCEPT o DROP, no un salto a otra cadena). El target por defecto es el que se aplica sobre los paquetes que han llegado al final de la cadena sin que les fuera aplicable ninguna regla con un target final.
Este target por defecto se establece con la opción -P. Esta opción habla de "policy" (política) pues permite establecer una política por defecto: rechazar todo salvo lo que explícitamente se permita (si el target por defecto es DROP) o aceptar todo salvo lo que explícitamente se prohiba (si el target por defecto es ACCEPT). Obviamente la política más segura es rechazar por defecto, pero es más difícil de llevar, sobre todo en una red grande: si hay poca comunicación entre los usuarios y los administradores y los usuarios ven cómo las políticas de seguridad de la empresa son un obstáculo para su trabajo buscarán formas de saltarse el cortafuegos, por ejemplo mediante el uso de túneles, por lo que a veces una política muy estricta si es también rígida puede ser contraproducente.
Ejemplos:
Permitir el tráfico saliente de la propia máquina y el enrutado, con destino al puerto 80 TCP
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A FORWARDING -p tcp --dport 80 -j ACCEPT
La opción -p indica el protocolo (tcp, udp) y la opción --dport (sólo puede aparecer dport si aparece -t) el puerto destino; para indicar el puerto origen sería con sport).
No permitir conectarse a ningún servidor de la máquina, excepto al servidor SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
Otras opciones interesantes:
-s: ip de origen
-d: ip destino
-i: interfaz de entrada
-o: interfaz de salida
-p icmp -icmp-type: para filtrar por tipo de mensaje ICMP. Ver con -p icmp -h la lista de tipos.
Recomendamos leer man iptables para conocer las impresionantes posibilidades de este programa. Por ejemplo hay una opción para limitar el número de conexiones a un puerto por IP de origen (o incluso por red de origen, mediante una máscara de bits). Otra opción permite poner como selector de reglas para paquetes generados localmente el usuario o el proceso que lo generó. Hay opciones para detectar escaneos de puertos, para ejecutar o dejar de ejecutar cuando la regla se ha dado una serie de veces. El módulo connbytes es perfecto para localizar conexiones que consumen mucho ancho de banda.
Supongamos que la IP pública de nuestro proveedor es 81.10.20.15; que la salida a Internet es por eth2 y que queremos que todas las conexiones salgan a Internet con esta IP. En este caso ejecutaríamos:
iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 81.10.20.15
Si nuestra IP no es fija, en lugar de SNAT utilizamos MASQUERADE y no incluimos el parámetro --to-source.
Observesé que SNAT no se usa sólo para hacer NAT con la IP de la conexión a Internet. Otro caso típico es si tenemos una VPN: establecemos una red privada entre nuestra máquina y la de la empresa; para acceder al resto de máquinas de la empresa una posible solución es hacer en la máquina en la red de la empresa SNAT a su propia IP de los paquetes procedentes de la red virtual, de modo que los paquetes procedentes de nuestra casa parecerán que salen de la IP a la que nos hemos conectado en la red local.
La regla se añade a PREROUTING si el paquete procede de fuera, OUTPUT si el paquete se ha generado localmente.
Un uso típico de DNAT es abrir puertos en un cortafuegos y redirigirlos a Ips y puertos de la red local.
Otro uso típico es reemplazar un servidor por otro temporalmente, o incluso balancear entre varias Ips. En este último caso en lugar de DNAT usamos BALANCE y especificamos un rango de Ips.
El tercer uso corriente es hacer un proxy transparente. Ahora bien, mientras que hay protocolos en los que en la petición aparece de nuevo la IP o hostname más puerto (por ejemplo en HTTP aparece en la cabecera Host) esto no tiene por que ser así, de modo que el proxy no sabría nada sobre la IP y puerto destino. Por este motivo este caso de DNAT se hace con un target especial (REDIRECT) que sólo funciona sobre la propia máquina, porque así netfilter le pasa la IP y puerto destino a la aplicación a través del sistema operativo.
SQUID es un proxy que puede funcionar como proxy transparente. Es posible ejecutar SQUID en una máquina distinta que el enrutador, utilizando la tabla mangle de iptables para marcar los paquetes con destino a SQUID y utilizar la herramienta ip (del paquete iproute; este programa es necesario para realizar operaciones avanzadas que no se pueden hacer con otras herramientas como route, por ejemplo enrutar por IP de origen o por políticas. En este caso se usa una política que es que el paquete haya sido marcado desde netfilter, de modo que lo que hacemos es enrutar a la máquina de SQUID el tráfico que queremos que procese.
Hay diversas herramientas para monitorizar redes y dar información sobre el ancho de banda consumido. Estas aplicaciones normalmente funcionan como sniffers, poniendo la tarjeta en modo promiscuo y recompilando información a través de libpcap. La aplicación sin duda más recomendable es iptraf (http://iptraf.seul.org/). Tiene interfaz de consola, con ncurses. Una relación extensa de herramientas para monitorizar el consumo de ancho de banda está en http://www.ubuntugeek.com/bandwidth-monitoring-tools-for-linux.html.
La otra posibilidad es utilizar el propio netfilter. Cara al rendimiento tenemos la ventaja que se ejecuta en el espacio del kernel.
Si ejecutamos iptables -L -v (se puede especificar una regla en concreto si no queremos ver todas) aparece junto con cada regla el número de paquetes que se han ajustado a esa regla y el total de bytes. Así, podemos escribir un script que cree una nueva cadena; en esa cadena añadimos una regla por cada IP de la red local, precisamente con su IP como selector (origen o destino, según lo que queramos monitorizar) y como target, RETURN. De este modo los contadores reflejarán los paquetes y bytes enviados/recibidos por/para cada una de esas Ips. Esta información es útil por ejemplo para detectar virus que tratan de hacer escaneos de puertos y que a veces provocan que la tabla NAT del router ADSL se sature. En este caso apreciaremos que desde esa IP se envían muchos paquetes, aunque probablemente con pocos bytes.
Para poner los contadores de una cadena a cero se usa la opción -Z.
Ejemplo de script para crear y borrar reglas para tener contadores:
#!/bin/sh
ipmasalta=198
start() {
iptables -N contadores
contador=1
while [ ${contador} -le $ipmasalta ]
do
iptables -A contadores --source 192.168.15.$contador -o eth2 -j ACCEPT
contador=`expr $contador + 1`
done
iptables -A FORWARD -j contadores
}
stop() {
iptables -D FORWARD -j contadores
contador=1
while [ ${contador} -le $ipmasalta ]
do
iptables -D contadores --source 192.168.15.$contador -o eth2 -j ACCEPT
contador=`expr $contador + 1`
done
iptables -X contadores
}
Existe un proyecto (http://ipac-ng.sourceforge.net/) que crea las reglas, recopila la información y la guarda, para finalmente visualizarla.
Otro sistema basado en netfilter es el módulo de webmin para monitorizar el ancho de banda.
Además con el módulo account es posible añadir una sola regla para registrar la información de toda una red y que desglose el resultado a nivel de tcp, udp, icmp y resto. Para más información ver http://www.svn.barbara.eu.org/ipt_account/wiki/Usage
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.
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" activos 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. 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 en 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.
Tener un servidor DNS público exige unos requisitos. Por lo pronto no basta con un servidor, como mínimo hay que tener dos, que deberían estar en localizaciones diferentes. La mayoría de las empresas optan por recurrir a una empresa que preste servicios de DNS, al menos para que les mantenga el servidor secundario, que periódicamente se actualiza del servidor maestro haciendo una transferencia de zona.
En nuestra red necesitamos un servidor DNS pero no para dar servicio a nuestro dominio, sino para que puedan resolver las direcciones DNS los usuarios de nuestra red, tanto las peticiones que van dirigidas a los servidores internos de la empresa con la que estamos conectados (dominio interno .acme), como los de la salida a Internet. Aclaremos que los servidores DNS de la empresa con la que estamos conectados no sólo sirven el dominio .acme sino también los de Internet, pues son los servidores DNS que usan todos los equipos de su red, por lo que podríamos configurar también nuestros equipos para que usen su DNS.
Es más práctico tener un servidor propio, que envíe las peticiones para resolver las direcciones de Internet al DNS de nuestro ISP y las de máquinas del dominio .acme a sus servidores DNS. La primera razón es porque no es lógico que cada vez que un usuario acceda a Internet usemos los servidores de la otra empresa: por privacidad, por buen uso de nuestras propias instalaciones y porque no deberíamos depender de si funciona bien la conexión con la otra empresa para poder usar Internet. Además si un día se añade conectividad con otra empresa más es evidente que habrá que consultar a cada empresa por su DNS.
Ejemplo de fichero de configuración:
// Ips que tienen acceso al servidor: sólo la red local
acl redinterna {
192.168.120.0/24;
};
options {
directory "/var/named";
forward first;
// Para resolver direcciones, usamos los servidores de nombres de
// nuestro ISP
forwarders {
80.58.0.33;
80.58.32.97;
};
// Esta línea es para usar la IP de la red local, en lugar de la IP de la
// interfaz de salida (la de la conexión con la red con la otra empresa o
// la de Internet
query-source address 192.168.120.19 port *;
};
// Servidores raíz
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
include "/etc/rndc.key";
// aquí ponemos los servidores DNS de la red de la otra empresa
zone "acme" {
type forward;
forwarders {
10.15.8.16;
};
forward only;
};
// Resolución inversa, también para la red de la otra empresa
zone "10.in-addr.arpa" {
type forward;
forwarders {
10.15.8.16
};
forward only;
};
// resolución inversa de nuestra zona
zone "15.168.192.in-addr.arpa" {
type master;
file "/var/named/192.168.120.rev";
};
Hay muchas web y sistemas para que un equipo con IP dinámica pueda dar de alta su IP en un DNS cada vez que se conecta o cambia. Básicamente lo que se hace es conectarse a un servidor, que analiza la IP de origen: esa será la IP que registrará, tras comprobar que el usuario aporta unas credenciales que le autorizan para cambiar su entrada DNS.
No hay un único sistema, por lo que hay unos programas que sirven para unos sitios y otros para otros, habiendo programas que soportan varios protocolos, como ez-ipupdate.
El paquete http://gnudip2.sourceforge.net/ sirve para implementar nuestro propio servidor de DNS dinámico, junto con el cliente y la descripción del protocolo.
En general no es buena idea tener un servidor propio de correo, si se trata de una empresa pequeña con un ADSL. Hay muchas empresas que ofrecen redirecciones de correo (en unos casos limitadas a 100 o 200 redirecciones distintas, en otros ilimitadas) por un precio razonable. Es posible usar como destino de las redirecciones por ejemplo cuentas de gmail, que nos permiten usar la dirección que queramos para el correo saliente. Así mismo la propia Google ofrece paquetes para empresas tipo Gmail pero con dominio propio.
Si no obstante nos decidimos, el servidor de correo de un dominio se fija con un registro MX en el DNS; es posible tener varios registros para que si está caído un servidor, se acuda a otro. Las empresas que venden servicio DNS como EasyDNS suelen ofrecer también servidor de correo de respaldo, es decir, añadir uno de sus servidores de correo para que reciban el correo en el supuesto que nuestro servidor esté caído.
Usar como servidor de correo saliente uno propio en lugar de el del proveedor teóricamente permite más control como saber si un mensaje ha sido recibido por el servidor destino; así mismo permite que si la conexión a Internet esté caída el servidor siga aceptando mensajes y los envíe en cuanto se restablezca la conexión, aunque no todo el mundo ve esto como una ventaja. Un inconveniente es que las Ips asignadas a las líneas ADSL a veces están en listas negras para evitar correo basura, por lo que no son las ideales para situar un servidor de correo. En concreto, las Ips de ADSL de Telefónica están en SPAMHAUS PBL http://www.spamhaus.org/pbl
a destacar que sitios como easydns.com bloquean el correo procedente de esas direcciones.
A priori una buena razón para montar un servidor de correo propio es evitar que los mensajes internos salgan a Internet. Sin embargo, recomendamos reemplazar los correos internos por mensajería instantánea utilizando un servidor con Jabber.
Si pese a todo insistimos en tener un servidor de correo propio, recomendamos usar PostFix como software y administrarlo a través de Webmin (www.webmin.com).
Tanto si instalamos nuestro propio servidor de correo como si usamos un proveedor, si tenemos un dominio propio es importante que usemos SPF, Sender Policy Framework (http://www.openspf.org/). Se trata de una medida antispam, consistente en añadir al DNS unos registros indicando qué servidores están autorizados para enviar correo en el que el remitente sea una dirección de nuestro dominio.
softlibre.net INT TXT "v=spf1 mx a:chemahome.softlibre.net include:gmail.com include:easydns.com -all"
En este caso hemos incluido con include las direcciones autorizadas para enviar con gmail.com, puesto que lo uso para enviar correos con @softlibre.net, y easydns.com, pues es quien se encarga de mis redirecciones. Además incluyo todo servidor de nombres del dominio (registros MX) y explíticamente a la máquina chemahome.softlibre.net. Observesé que para simplemente incluir todas las máquinas con registros de nombre A en el dominio bastaría con poner sólo "a". Al final con "-all" se indica que se deben rechazar todos los mensajes que no procedan de ninguno de los sitios indicados. Mientras estamos probando es mejor utilizar "~all", que en lugar de rechazar implica que el servidor añada una cabecera para que lo puedan detectar en los filtros de los programas de correo.
Es importante así mismo que pongamos una regla en el cortafuegos para prohibir conexiones al puerto 25 de otra máquina que el servidor de correo de la empresa (si es externo) o si es interno que sólo se pueda conectar al puerto 25 desde la IP del servidor de correo.
El servidor deberá aceptar correo destinado a su propio dominio y filtrar (o al menos clasificar) el correo que conforme a SPF es falso. Para enviar correo sólo deberá aceptar en el que el from sea el propio dominio y hacerlo autenticado.
Como información complementaria, este artículo explica como añadir a un servidor de correo un fitro ANTISPAM y un antivirus: http://www.howtoforge.com/amavisd_postfix_debian_ubuntu
Un recurso muy útil para empresas es montar un wiki, una herramienta colaborativa en el que las personas pueden crear páginas de contenidos accesibles vía web, desde el propio navegador, de forma muy sencilla. Estas páginas las podrán modificar el resto de usuarios: en todo momento se podrá revisar el histórico de las páginas, ver quién ha hecho cada cambio... Un wiki además integra un buscador. En definitiva, es una herramienta muy útil para mantener información de uso interno entre un grupo de personas.
Hay distinto software para implementar un wiki. Aunque a la hora de editar editar las páginas de un wiki todas las soluciones son muy parecidas, lo cierto es que son distintos por lo que la gente cuando se acostumbra a uno le cuesta pasar a otro; así mismo no es trivial migrar de un wiki a otro. Vamos a mencionar cuatro soluciones:
Mediawiki (www.mediawiki.org). Licencia GPL. Es el software de la wikipedia, pero se usa en muchos otros proyectos, como Mozilla. Realmente no es la opción más flexible para empresas, por ejemplo de las propuestas analizadas es la más floja en el control de acceso para quien edita o ve las páginas; sólo resulta adecuada para un control básico, por ejemplo para que sólo puedan ver las páginas y editarlas los usuarios que están dados de alta en el wiki. Sus puntos fuertes son el atractivo visual de las páginas (además con versión imprimible) y que a muchos usuarios les resulta más familiar por usarse en muchos wikis y en la wikipedia. Otro punto fuerte es que es fácil de editar y muy flexible: se pueden editar fórmulas matemáticas y mediante GraphViz es sencillo crear diagramas. Incluye funcionalidades como página de discusión, posibilidad de notificar al usuario cuando la página cambia, control de páginas huérfanas, posibilidad de subir ficheros... Para instalar mediawiki hace falta Apache, PHP y MySQL.
Twiki (http://twiki.org/). Licencia GPL. Este software lo usan muchas empresas, como Michelin, Disney, SAP, Yahoo... Tiene plugins muy interesantes, como ActionTracker (para hacer TO-DO list, que pueden compartirse con otros usuarios), Calendar (calendario, con eventos resaltados) o un editor de gráficos en Java. Para instalar Twiki hace falta Apache y Perl (no hace falta un gestor de base de datos).
MoinMoin: (http://moinmoin.wikiwikiweb.de/. Licencia GPL. Lo usan proyectos como Ubuntu, Debian, Apache, Hispalinux... Entre sus puntos fuertes que es fácil de instalar: está escrito en Python y no requiere más que un servidor web, por ejemplo Apache. No guarda las páginas en BB.DD.
TikiWiki: (http://tikiwiki.org/) . Licencia LGPL. Destaca por no ser sólo un wiki: también integra funciones de CMS (gestor de contenidos) y solución groupware, por lo que es muy interesante para empresas. Integra webmail, foros, blogs, encuestas, calendario, agenda de direcciones, hoja de cálculo... Para instalarlo requiere PHP y un gestor de BB.DD.: MySQL es el único sistema totalmente soportado, pero otros lo están parcialmente.
XMPP es el protocolo de mensajería instantánea estandarizado por el IETF, el organismo que establece los protocolos de Internet. Es más conocido como Jabber, el nombre con el que se creó en 1998.
XMPP significa eXtensible Message Presence Protocol. Lo de "extensible" es muy importante: Jabber usa XML y gracias a ello se le han añadido todo tipo de extensiones, como invocar llamadas RPC entre dos clientes. Esto permite todo tipo de aplicaciones; recuerda la revolución que ha supuesto las aplicaciones web, sólo que aquí con más posibilidades: la comunicación no está limitada a cliente servidor sino entre dos clientes, que pueden variar su IP y ubicación. Además la comunicación es totalmente bidireccional, mientras que en la web es petición-respuesta: el navegador efectúa una petición y el servidor web responde, de modo que si es el servidor el que quiere notificar algo al navegador no puede salvo que se haga polling: el navegador envía una petición tipo "respondemé cuando tengas algo que decirme".
De igual modo que con el correo, una organización puede tener su propio servidor Jabber interno o elegir entre distintos proveedores. También como ocurre con los servidores de correo, las comunicaciones entre usuarios del mismo servidor no salen del servidor y por lo tanto de la red local de la organización, mientras que si se contacta con un usuario no local se localiza su servidor a partir de su dirección, que son iguales de las de correo, los servidores se comunican entre sí.
Esta es una gran diferencia respecto a soluciones propietarias como MSN Messenger, AOL o Yahoo, dónde hay un único servidor para todos los usuarios, lo que lo hace muy poco adecuado para empresas: incluso el correo interno pasa por Internet, por el mismo servidor que el de su competencia. Sería como si para tener correo electrónico una empresa sólo pudiera abrir cuentas en Hotmail o en Gmail y al escoger uno de estos dos sitios no pudiéramos enviar ni recibir mensajes del otro.
Otro problema de las soluciones propietarias es que se está en manos del proveedor incluso para elegir el programa de mensajería. En algunos casos se pueden usar distintos programas pero el proveedor tiene la sartén por el mango y puede en un momento dado no dejar que se conecte nadie con otro programa que el oficial. Es el caso de AOL, que durante un tiempo para evitar conexiones de otros clientes preguntaba al programa fragmentos de su propio código, que al estar bajo copyright no podían replicar los otros programas.
De hecho la propia Microsoft tiene una solución de mensajería instantánea para empresas que no usa el mismo protocolo que MSN sino en un software servidor; otro producto muy conocido de mensajería para empresas es Lotus SameTime. En realidad estas soluciones rivales de Jabber se basan en un protocolo que también está siendo estandarizado por el IETF, SIMPLE, pero a pesar de comenzar el proceso antes que con XMPP está más atrasado y hay aspectos básicos sin estandarizar que por lo tanto no son interoperables. De hecho mientras que hay miles de servidores que se comunican a través de Internet al estilo de los servidores de correo, de modo que puede contactar con cualquier usuario a través de su dirección, no ocurre así con los servidores de SIMPLE.
El paralelismo entre correo y Jabber es tan grande que el formato de direcciones es el mismo: en Google Gmail de hecho cada cuenta es una dirección de correo y de Jabber
Ventajas de tener un servidor de mensajería propio:
Los mensajes no salen de la organización. Mayor confidencialidad y seguridad. Mejor aprovechamiento de la conexión a Internet, pues es absurdo que para enviar un mensaje local éste salga a un servidor de Estados Unidos y vuelva.
Posbilidad de controlar el flujo de la información y con quien pueden contactar los usuarios.
Posibilidad de registrar las conversaciones.
Opción de añadir automáticamente contactos a todos los usuarios de un grupo.
Posibilidad de usar control de acceso coorporativo: todo el mundo accede con su usuario y contraseña que usa para acceder al resto de aplicaciones de la empresa o mediante tarjeta de acceso.
Posibilidad de directorio de usuarios (usar uno en Internet hace más difícil las búsquedas y problema de no poder incluir información confidencial.
Posibilidad de enviar mensajes a todos los usuarios o poner mensajes del día
Posiblidad de añadir funcionalidad al servidor o de integrar otros servicios como VoIP.
Uso de un dominio propio. Mejor imagen coorporativa. No se pierde disponibilidad si cae conexión a Internet o servidor del proveedor.
Hay varios servidores Jabber bajo licencia libre. Uno que viene con muchas distribuciones es jabberd, escrito en C. Uno de los más usados y fáciles de instalar (hay un vídeo de cómo instalar y empezar a usar este servidor en 180 segundos) es ejabberd (http://ejabberd.jabber.ru/). La única pega de ejabberd es que está escrito en Erlang, por lo que para quien no esté familiarizado con este lenguaje requiere cierto aprendizaje para escribir nuevos módulos. Otra opción es un servidor escrito en Java: OpenFire (anteriormente se llamaba WildFire): http://www.igniterealtime.org/projects/openfire/index.jsp.