SEGURIDAD EN LA RED
Anuncio
Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux S EGURIDAD EN LA RED 7.1 SSH Sus siglas abrevian Secure Shell, y es un protocolo cliente/servidor que sirve para acceder a interfaces de comando en máquinas remotas a través de una red IP. Es similar a Telnet, sólo que toda la conexión está encriptada, para evitar que el tráfico entre los extremos (incluyendo autenticación) circule en texto simple por la red. Hay una implementación gratuita para Linux llamada OpenSSH, y viene con las fuentes de SuSE. Si durante la instalación se marcaron las opciones de Red – Servidor, seguramente estará instalado y en funcionamiento. SSH opera sobre TCP típicamente en el puerto 22 del servidor, y en su modo más simple, el cliente se conecta con el servidor, quien se identifica y entre ambos negocian una clave para encriptar la comunicación. OpenSSH provee de las siguientes utilidades, entre otras: o ssh: cliente SSH, que reemplaza a rlogin y telnet. o scp: que hace las veces de rcp y permite copiar archivos entre 2 máquinas. o sftp: un cliente de FTP seguro. o sshd: servidor SSH. o sftp-server: servidor FTP seguro. 7.1.1 Clientes Veremos la sintaxis básica y de uso más frecuente de los clientes SSH. Para iniciar una sesión de shell en una máquina remota debemos usar ssh: ssh [-l login_name] hostname | user@hostname Esto indica que podemos iniciar sesión en un host remoto escribiendo, por ejemplo: usuario@tierra:~ > ssh 12.168.0.122 Módulo VII: Seguridad en la red 1 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux En caso de querer especificar el nombre de usuario, podemos anteponerlo al nombre de host o IP en el parámetro –l o bien utilizar la sintaxis con @: usuario@tierra:~ > ssh remoto@12.168.0.122 Si deseamos copiar un archivo a través de la red, lo indicado sería scp: scp [-r] [[user@]host1:]file1 [...] [[user@]host2:]file2 El parámetro –r permite copiar el contenido de los subdirectorios. Veremos un ejemplo más adelante. Por último, muchas veces (cuando no se conocen los nombres de los archivos a copiar, por ejemplo) es conveniente una transferencia FTP. Para ello, SSH dispone de sftp: sftp [user@]host Una vez conectados, el comando help muestra una lista de los comandos disponibles, similares a los de cualquier cliente FTP. La configuración del cliente ssh se encuentra en /etc/ssh/ssh_config, se recomienda utilizar los valores por defecto, y de ser necesario modificarlos al invocar el ejecutable en el shell. Los comandos vistos tienen muchas funciones más que las tratadas en este documento, como ser compresión y ejecución por lotes (batch), por lo que es recomendable buscar más información sobre su uso en las páginas de manual correspondientes. 7.1.2 Servidor El demonio sshd controla el funcionamiento de ssh, scp y sftp, este último al iniciar sftpserver cuando es necesario. Se controla por medio del script rcsshd, y la configuración se encuentra en /etc/ssh/sshd_config. Los parámetros por defecto son suficientes para el funcionamiento normal y seguro del servidor. Destacaremos sin embargo el parámetro PermitRootLogin que posibilita el control sobre la admisión del usuario root a través de este protocolo. 7.1.3 Funcionamiento Para que una conexión SSH sea posible, debe estar en la máquina destino el demonio o servidor SSH ejecutandose. En SuSE este demonio ejecuta por defecto al iniciar el sistema en los niveles 3 y 5. Al iniciar por primera vez, el demonio genera dos pares de claves (keys). Cada par está compuesto por una clave privada y una pública, que permite afirmar que este protocolo está basado en clave pública. Para garantizar la seguridad de la comunicación via SSH, sólo el administrador del sistema Módulo VII: Seguridad en la red 2 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux puede ver los archivos que contienen las claves privadas. Estas son necesarias exclusivamente para el demonio local, y nunca deben ser reveladas. Por otro lado, están las claves públicas, con la extensión .pub, que son enviadas al cliente y que son legibles por cualquier usuario. La conexión es iniciada por el cliente. Luego intercambian identificación, comparan el protocolo, versión de software y evitan la conexión a un puerto del cliente incorrecto. Esto último es necesario debido a que es un hijo del proceso original del demonio el que responde a la petición y puede haber de este modo muchas conexiones simultáneas. Paso siguiente el servidor manda sus claves públicas: una que lo identifica (host key), y una llamada “de sesión” (session key) que cambia cada hora. El cliente genera una clave simétrica, la encripta con ambas claves públicas del servidor y la envía (SSHv1) para que ambas partes utilicen esta clave para encriptar el resto de la comunicación. Una vez finalizada esta fase de negociación comienza el inicio de sesión en el host remoto, típicamente hará falta un nombre de usuario y password. La versión 2 de SSH, entre otras cosas, requiere que la clave simétrica sea generada entre las dos puntas de la conexión, para evitar ataques de replay (cuando el tráfico de red es capturado, aún encriptado, guardado y posteriormente enviado de vuelta). Luego del primer contacto con un servidor, el cliente conserva la clave pública del servidor (host key) en el archivo ~/.ssh/known_hosts junto con su dirección IP para evitar ataques del tipo “hombre en el medio” (man in the middle) que tratan de impostar un servidor para engañar al cliente. El servidor impostor no podrá contar con la clave pública almacenada en known_hosts y en caso de hacerlo, a menos que posea la clave privada del servidor verdadero estará impedido de entender la comunicación. Es recomendable entonces guardar las claves públicas y privadas del servidor almacenadas en /etc/ssh externamente con un doble propósito: detectar alteraciones y para utilizarlas luego de una nueva instalación. 7.1.4 Autenticación por clave pública El método de nombre de usuario y password tiene algunos inconvenientes. Por ejemplo, un password tiene que ser largo, lo más aleatorio posible y contener caracteres alfanuméricos y algún símbolo especial para ser más seguro; pero un password así es difícil de recordar. Por otro lado, un password que transita la red aún encriptado puede ser capturado si el host destino (donde se ejecuta el servidor SSH) se encuentra comprometido. Finalmente, este método presenta dificultades cuando una contraseña (la de root, por ejemplo) tiene que ser compartida entre varias personas, puesto que hay que avisar a todos de los cambios y es difícil auditar el uso de la cuenta, dado que el sistema no permite distinguir entre los usuarios de la cuenta. Módulo VII: Seguridad en la red 3 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux A raíz de esto, SSH soporta autenticación por clave pública: en lugar de depender del mecanismo de autenticación del servidor, SSH puede usar claves criptográficas, que son más seguras que las contraseñas, y solucionan todos los problemas mencionados. Estas claves criptográficas son cadenas de bits generadas de forma tal que sean únicas, y que por esta propiedad, pueden considerarse como prueba de identidad. El esquema sigue siendo de clave asimétrica, por lo que al generar una identidad en SSH se obtiene una clave pública y una privada, y esta última está en general encriptada y protegida por una contraseña larga o passphrase. Para utilizar este sistema, en primer lugar, hay que generar las claves: usuario@tierra:~ > ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/usuario/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/usuario/.ssh/id_dsa. Your public key has been saved in /home/usuario/.ssh/id_dsa.pub. The key fingerprint is: 74:b5:62:1f:a2:de:a3:ab:15:b5:30:7b:89:49:03:ce usuario@tierra Luego hay que colocar la clave pública en la cuenta remota. Supongamos que usuario tiene en la máquina sol una cuenta llamada remoto. Hay que poner la clave pública de usuario en tierra dentro de ~/.ssh/authorized_keys en sol. Este archivo contiene todas las claves públicas de las identidades autorizadas para iniciar sesión en la cuenta de remoto@sol. Es un buen momento para ejemplificar el uso de scp, con el que copiaremos la clave pública recientemente generada. usuario@tierra:~ > scp ~/.ssh/id_dsa.pub remoto@sol:~/usuario.pub The authenticity of host 'hermano (12.168.0.122)' can't be established. RSA key fingerprint is 6c:cd:cf:e6:73:93:ee:d7:4c:ce:e5:bf:ec:c0:17:c4. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'sol,12.168.0.122' (RSA) to the list of known hosts. remoto@sol's password: id_dsa.pub 100% 605 0.0KB/s 00:00 usuario@tierra:~ > ssh -l remoto sol remoto@sol's password: Last login: Tue Jun 21 10:21:38 2004 from 12.148.10.123 -*- If Linux doesn't have the solution, you have the wrong problem -*remoto@sol:~ > cat usuario.pub >> .ssh/authorized_keys remoto@sol:~ > rm usuario.pub remoto@sol:~ > logout Módulo VII: Seguridad en la red 4 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux La próxima vez que se utilice ssh para ingresar a remoto@sol desde usuario@tierra, se pedirá la passphrase de la clave privada en primer lugar, y de fallar, el password. La clave pública de una identidad del lado del cliente, además de estar en id_dsa.pub, puede estar en identity, siempre dentro del directorio ~/.ssh. Este esquema de autenticación es más seguro que el de usuario/contraseña porque: 1. Tiene 2 componentes secretos: la clave privada y la passphrase. 2. Ninguno de estos componentes viaja por la red. Es posible probar la posesión de ellos sin revelarlos, y esto es lo que el protocolo hace. 3. Las claves criptográficas generadas son extremadamente difíciles de adivinar. En caso de poder obtener la clave privada encriptada, hay que adivinar la passphrase, que por ser (supuestamente) larga y compleja es también un gran obstáculo. Ahora que tenemos este nuevo mecanismo, caemos en cuenta de que cada vez que necesitamos utilizar ssh o scp hay que escribir una frase bastante más larga que la contraseña. Para asistirnos en este paso, está la utilidad ssh-agent, que mantiene la clave privada de una identidad (añadida previamente con ssh-add) en memoria mientras dure la ejecución de este agente. Por ejemplo, para el caso visto anteriormente: usuario@tierra:~ > ssh-agent bash usuario@tierra:~ > ssh-add usuario Enter passphrase for /home/usuario/.ssh/id_dsa: Identity added: /home/usuario/.ssh/id_dsa (/home/usuario/.ssh/id_dsa) usuario@tierra:~ > ssh remoto@sol Last login: Tue Jun 21 11:16:53 2004 from 12.148.10.123 -*- If Linux doesn't have the solution, you have the wrong problem -*remoto@sol:~ > logout El primer comando inicia una sesión de bash bajo el agente ssh. Luego se pueden agregar las claves con ssh-add, y el agente las registra mientras dure la sesión (o subshell) abierta. Como consecuencia del registro, no necesitamos escribir la passphrase más que una vez para cualquier host que requiera la identidad cuya clave privada se encuentra en ~/.ssh/id_dsa. Esto incluye los clientes ssh, scp y sftp. Si tuvieramos más de una identidad, bastaría con agregarla del mismo modo. Se recomienda la lectura de las páginas de manual de ssh-keygen, ssh-agent y ssh-add para abarcar el resto de las opciones de estas utilidades. Módulo VII: Seguridad en la red 5 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux 7.2 KERBEROS Durante 1983 en el M.I.T. (Massachussetts Institute of Technology) comenzó el proyecto Athena con el objetivo de crear un entorno de trabajo educacional compuesto por estaciones gráficas, redes de alta velocidad y servidores; el sistema operativo para implementar este entorno era Unix 4.3BSD, y el sistema de autenticación utilizado en el proyecto se denominó Kerberos en honor al perro de tres cabezas que en la mitología griega vigila la puerta de entrada a Hades, el infierno. Hasta que se diseñó Kerberos, la autenticación en redes de computadores se realizaba principalmente de dos formas: o bien se aplicaba la autenticación por declaración (Authentication by assertion), en la que el usuario es libre de indicar el servicio al que desea acceder (por ejemplo, mediante el uso de un cliente determinado), o bien se utilizaban contraseñas para cada servicio de red. Evidentemente el primer modelo proporciona un nivel de seguridad muy bajo, ya que se le otorga demasiado poder al cliente sobre el servidor; el segundo modelo tampoco es muy bueno: por un lado se obliga al usuario a ir tecleando contínuamente su clave, de forma que se pierde demasiado tiempo y además la contraseña está viajando contínuamente por la red. Kerberos trata de mejorar estos esquemas intentando por un lado que un cliente necesite autorización para comunicar con un servidor (y que esa autorización provenga de una máquina confiable), y por otro eliminando la necesidad de demostrar el conocimiento de información privada (la contraseña del usuario) divulgando dicha información. Kerberos se ha convertido desde entonces en un referente obligatorio a la hora de hablar de seguridad en redes. Se encuentra disponible para la mayoría de sistemas Unix, y está especialmente recomendado para sistemas operativos distribuidos, en los que la autenticación es una pieza fundamental para su funcionamiento: si conseguimos que un servidor logre conocer la identidad de un cliente puede decidir sobre la concesión de un servicio o la asignación de privilegios especiales. Muchos otros esquemas de autenticación diseñados posteriormente, como KryptoKnight, SESAME o Charon se basan en mayor o menor medida en Kerberos. El uso de Kerberos se produce principalmente en el login, en el acceso a otros servidores (por ejemplo, mediante rlogin) y en el acceso a sistemas de ficheros en red como NFS. 7.2.1 Arquitectura de Kerberos Un servidor Kerberos se denomina KDC (Kerberos Distribution Center), y provee de dos servicios fundamentales: el de autenticación (AS, Authentication Service) y el de tickets (TGS, Ticket Granting Service). El primero tiene como función autenticar inicialmente a los clientes y proporcionarles un ticket para comunicarse con el segundo, el servidor de tickets, que proporcionará a los clientes las credenciales necesarias para comunicarse con un servidor final que es quien realmente ofrece un servicio. Además, el servidor posee una base de datos de sus clientes Módulo VII: Seguridad en la red 6 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux (usuarios o programas) con sus respectivas claves privadas, conocidas únicamente por dicho servidor y por el cliente al que pertenece. La arquitectura de Kerberos está basada en tres objetos de seguridad: Clave de Sesión, Ticket y Autenticador. La clave de sesión es una clave secreta generada por Kerberos y expedida a un cliente para uso con un servidor durante una sesión; no es obligatorio utilizarla en toda la comunicación con el servidor, sólo si el servidor lo requiere (para encriptar los datos) o si el servidor es un servidor de autenticación. Las claves de sesión se utilizan para minimizar el uso de las claves secretas de los diferentes agentes: éstas últimas son válidas durante mucho tiempo, por lo que es conveniente para minimizar ataques utilizarlas lo menos posible. El ticket es un testigo expedido a un cliente del servicio de tickets de Kerberos para solicitar los servicios de un servidor; garantiza que el cliente ha sido autenticado recientemente. Este ticket incluye el nombre del cliente, para evitar su posible uso por impostores, un periodo de validez y una clave de sesión asociada para uso de cliente y servidor. Kerberos siempre proporciona el ticket ya cifrado con la clave secreta del servidor al que se le entrega. El autenticador es un testigo construido por el cliente y enviado a un servidor para probar su identidad y la actualidad de la comunicación; sólo puede ser utilizado una vez. Este autenticador contiene, cifrado con la clave de la sesión, el nombre del cliente y un timestamp. Estos últimos se usan como pruebas de frescura, con dos propósitos: evitar reenvíos de viejos mensajes capturados en la red o la reutilización de viejos tickets obtenidos de zonas de memoria del usuario autorizado, y a la vez poder revocar a los usuarios los derechos al cabo de un tiempo. Módulo VII: Seguridad en la red 7 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux 7.2.2 Problemas de Kerberos A la vista de todo lo comentado en los puntos anteriores puede darnos la impresión de que Kerberos es la panacea de los sistemas de autenticación. Sin embargo, y aunque se trate de un sistema robusto, no está exento de ciertos problemas, tanto de seguridad como de implementación, que han hecho que este sistema no esté todo lo extendido que podría. Uno de los principales problemas de Kerberos es que cualquier programa que lo utilice ha de ser modificado para poder funcionar correctamente, siguiendo un proceso denominado “kerberización”. Esto implica obviamente que se ha de disponer del código fuente de cada aplicación que se desee kerberizar, y también supone una inversión de tiempo considerable para algunas aplicaciones más o menos complejas que no todas las organizaciones se pueden permitir. El problema anterior es simplemente de implementación; no afecta para nada a la seguridad -o inseguridad- del protocolo. Un problema que sí está relacionado con la seguridad de Kerberos es la gran centralización que presenta el sistema. Para un correcto funcionamiento se ha de disponer en todo momento del servidor Kerberos, de forma que si la máquina que lo alberga falla, la red se convierte en inutilizable; obviamente esto es una contradicción con lo que nos dice la teoría de sistemas distribuidos, donde se recalca el uso de la distribución para mantener la disponibilidad del sistema, intentado que si un equipo falla el resto pueda seguir funcionando, si no a pleno rendimiento, al menos correctamente. Por si esto no fuera suficiente, otro ejemplo de la centralización de Módulo VII: Seguridad en la red 8 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux Kerberos reside en el hecho de que casi toda la seguridad reside en el servidor que mantiene la base de datos de claves, de forma que si éste se ve comprometido, la red entera está amenazada. Otro potencial problema de seguridad es el uso de timestamps como pruebas de frescura en Kerberos. Esto obliga a que todas las máquinas que ejecutan servicios autenticados mantengan sus relojes mínimamente sincronizados (con desfases máximos de pocos minutos), con todo lo que esto implica. Además ese tiempo global ha de ser accesible a todas las estaciones; aunque en el diseño no se asume que todas mantengan la hora exacta, sí que se les obliga a mantenerse dentro de los márgenes si desean solicitar tickets, para lo que se necesitan servidores de tiempo con los que los clientes puedan sincronizar periódicamente sus relojes, por ejemplo cada vez que arrancan. Todos estos problemas, y algunos más que se han ido solucionando en diferentes versiones del sistema, han propiciado que el uso de Kerberos no esté muy extendido; en la mayoría de redes es suficiente con un protocolo de comunicación cifrado para mantener una mínima seguridad, de forma que el complejo modelo de Kerberos se ve sustituido a ese efecto por programas tan simples y transparentes como SSH. 7.2.3 Cliente Kerberos en SuSE En SuSE, la configuración de un cliente Kerberos es sencilla de realizar desde YaST2, bajo la categoría de Servicios de Red. Módulo VII: Seguridad en la red 9 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux Una vez configurado correctamente, todas las aplicaciones que utilicen PAM para autenticación podrán hacer uso de Kerberos, como por ejemplo, telnet, ftp, login, y otros. 7.3 FIREWALL Un firewall o cortafuegos es un sistema o grupo de sistemas que hace cumplir una política de control de acceso entre dos redes. De una forma más clara, podemos definir un cortafuegos como cualquier sistema (desde un simple router hasta varias redes en serie) utilizado para separar –en cuanto a seguridad se refiere– una máquina o subred del resto, protegiéndola así de servicios y protocolos que desde el exterior puedan suponer una amenaza a la seguridad. El espacio protegido, denominado perímetro de seguridad, suele ser propiedad de la misma organización, y la protección se realiza contra una red externa, no confiable, llamada zona de riesgo. Evidentemente la forma de aislamiento más efectiva para cualquier política de seguridad consiste en el aislamiento físico, es decir, no tener conectada la máquina o la subred a otros equipos o a Internet (figura 7.1 (a)). Sin embargo, en la mayoría de organizaciones los usuarios necesitan compartir Módulo VII: Seguridad en la red 10 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux información con otras personas situadas en muchas ocasiones a miles de kilómetros de distancia, con lo que no es posible un aislamiento total. El punto opuesto consistiría en una conectividad completa con la red (figura 7.1 (b)), lo que desde el punto de vista de la seguridad es muy problemático: cualquiera, desde cualquier parte del mundo, puede potencialmente tener acceso a nuestros recursos. Un término medio entre ambas aproximaciones consiste en implementar cierta separación lógica mediante un cortafuegos (figura 7.1 (c)). Figura 7.1: (a) Aislamiento. (b) Conexión total. (c) Firewall entre la zona de riesgo y el perímetro de seguridad. Antes de hablar de cortafuegos es casi obligatorio dar una serie de definiciones de partes o características de funcionamiento de un firewall; por máquina o host bastión (también se denominan gates) se conoce a un sistema especialmente asegurado, pero en principio vulnerable a todo tipo de ataques por estar abierto a Internet, que tiene como función ser el punto de contacto de los usuarios de la red interna de una organización con otro tipo de redes. El host bastión filtra tráfico de entrada y salida, y también esconde la configuración de la red hacia fuera. Por filtrado de paquetes entendemos la acción de denegar o permitir el flujo de tramas entre dos redes (por ejemplo la interna, protegida con el firewall, y el resto de Internet) de acuerdo a unas normas predefinidas. El filtrado también se conoce como screening, y a los dispositivos que lo implementan se les denomina chokes; el choke puede ser la máquina bastión o un elemento diferente. Físicamente, en casi todos los cortafuegos existen al menos un choke y una máquina bastión, aunque también se considera firewall a un simple router filtrando paquetes, es decir, actuando como Módulo VII: Seguridad en la red 11 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux choke; desde el punto de vista lógico, en el cortafuegos suelen existir servidores proxy para las aplicaciones que han de atravesar el sistema, y que se situan habitualmente en el host bastión. También se implementa en el choke un mecanismo de filtrado de paquetes, y en alguno de los dos elementos se suele situar otro mecanismo para poder registrar y detectar la actividad sospechosa. Los firewalls son cada vez más necesarios en nuestras redes, pero todos los expertos recomiendan que no se usen en lugar de otras herramientas, sino junto a ellas; cualquier cortafuegos, desde el más simple al más avanzado, presenta dos gravísimos problemas de seguridad: por un lado, centralizan todas las medidas en un único sistema, de forma que si éste se ve comprometido y el resto de nuestra red no está lo suficientemente protegido el atacante consigue amenazar a toda la subred simplemente poniendo en jaque a una máquina. El segundo problema, relacionado con éste, es la falsa sensación de seguridad que un cortafuegos proporciona: generalmente un administrador que no disponga de un firewall va a preocuparse de la integridad de todas y cada una de sus máquinas, pero en el momento en que instala el cortafuegos y lo configura asume que toda su red es segura, por lo que se suele descuidar enormemente la seguridad de los equipos de la red interna. Esto, como acabamos de comentar, es un grave error, ya que en el momento que un pirata acceda a nuestro cortafuegos –recordemos que es un sistema muy expuesto a ataques externos– automáticamente va a tener la posibilidad de controlar toda nuestra red. 7.3.1 SuSEFirewall 2 SuSE empaca dos firewalls de filtrado de paquetes con iptables, el Personal-firewall y el SuSEFirewall 2. El primero de ellos está cayendo en desuso, por lo que no nos referiremos a él en este documento. El segundo se configura desde YaST, de una manera muy sencilla que no requiere conocimiento alguno de iptables. Se encuentra bajo la categoría de Seguridad y Usuarios. Módulo VII: Seguridad en la red 12 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux El primer paso es bastante claro, especificar las interfaces internas y externas. Módulo VII: Seguridad en la red 13 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux Luego vienen los servicios que se desean brindar para dejar los puertos abiertos. En el campo de Servicios adicionales se pueden especificar manualmente números de puertos para dejar abiertos. Se destacan el 1863 de MSN Messenger y el 631 de CUPS. Módulo VII: Seguridad en la red 14 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux Este paso contiene decisiones importantes, entre las que destacamos: reenviar tráfico y usar enmascaramiento (es más seguro no usarlo, y poner proxys) y proteger todos los servicios en ejecución, para que una máquina externa sólo pueda acceder a los servicios especificados en el paso anterior. Módulo VII: Seguridad en la red 15 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux Finalmente están las opciones de registro. La configuración es tan sencilla como limitada. Todo esto se traduce en un conjunto de reglas de filtrado con iptables. Por esto veremos a continuación el manejo de las reglas mismas, para poder crear un filtro que se ajuste más a necesidades específicas. 7.3.2 Filtrado de paquetes con iptables El filtrado de paquetes se realiza por medio de la aplicación iptables. Ella nos permite manejar todos los datagramas que pasan por la máquina, según el siguiente esquema: Módulo VII: Seguridad en la red 16 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux La primera decisión de ruteo (routing decision) tendrá en cuenta si el paquete está destinado al host local o si debe ser reenviado. El camino a seguir será el de la izquierda o el de la derecha, respectivamente. Podemos ver que las cadenas PREROUTING de las tablas mangle y nat son recorridas antes de la decisión de encaminamiento, por lo que ésta puede verse alterada dependiendo del manejo que se produzca en las mencionadas cadenas. La tabla mangle está destinada para cambiar o establecer el TTL y TOS de un paquete, y también permite marcar el datagrama de modo tal que pueda ser reconocido por las herramientas de encaminamiento de iproute2. Módulo VII: Seguridad en la red 17 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux La tabla nat se usa para Network Address Translation, que incluye DNAT, SNAT y Masquerading. Finalmente la tabla filter es la que veremos en detalle y su propósito es realizar el filtrado de paquetes. Las acciones en esta tabla serán ACCEPT, REJECT y DROP. Siendo que iptables fue introducido en el capítulo anterior, veremos a continuación las opciones de las acciones de la tabla filter. Cabe destacar que la opción de búsqueda “-i”, que especifica la interfaz de entrada del paquete (eth0, ppp2, etc.), sólo vale para las cadenas FILTER e INPUT, mientras que la opción “-o”, que se compara con la interfaz de salida del paquete (eth1, eth0, ppp0, etc.) sólo tiene significado en FORWARD y OUTPUT. Esto es debido al esquema de encaminamiento. Las acciones ACCEPT y DROP no poseen parámetros. Cuando un paquete satisface una regla cuya acción es ACCEPT, es dejado pasar y no sigue recorriendo las reglas de la cadena ni de la tabla actual. Notese, que sin embargo, en otra tabla se puede descartar un paquete previamente aceptado. Cuando un datagrama cumple con una regla cuya acción es DROP, este es bloqueado. Esto significa que no recorrerá ninguna otra regla en la cadena presente ni en otras de la tabla actual ni las demás. El paquete es descartado en el acto, y para el host es como si no existiese. La acción REJECT tiene una opción, --reject-with, que establece la respuesta a mandar al host que originó el paquete que estamos rechazando. La acción realiza lo mismo que DROP, excepto que previamente enviará la respuesta especificada (por defecto port unreachable - “puerto inalcanzable”). Las respuestas válidas son: icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited, icmphost-prohibited, echo-reply y tcp-reset. Por ejemplo, la siguiente regla rechaza los paquetes destinados al puerto TCP 22 (SSH) de los hosts internos (FORWARD) y envía como respuesta un paquete TCP RST, utilizado para cerrar adecuadamente las conexiones: iptables -A FORWARD -p TCP --dport 22 -j REJECT --reject-with tcp-reset Hay una condición de búsqueda adicional de mucho valor en un firewall: “state". Linux lleva una tabla donde guarda información de cada conexión (connection tracking) TCP, UDP, ICMP, FTP y otros. Son de especial interés los estados ESTABLISHED y RELATED, que indican paquetes de una conexión ya establecida y paquetes de una conexión relacionada con otra ya establecida. Por ejemplo, la siguiente regla permite a nuestro servidor web responder a conexiones ya establecidas y relacionadas. Módulo VII: Seguridad en la red 18 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux iptables -A OUTPUT -p tcp --sport 80 -m state --state RELATED,ESTABLISHED j ACCEPT Para finalizar, iptables nos da la posibilidad de registrar en syslog todo lo que sucede en su ambiente. Esto se realiza por medio de la acción LOG, que tiene los siguientes parámetros posibles: o --log-level, con el que se puede especificar la prioridad para syslog o --log-prefix, que permite anteponer una frase al registro, por ejemplo, “PAQUETES DESCARTADOS”. o --log-tcp-sequence, para registrar el número de secuencia TCP o --log-tcp-options, que muestra los campos del encabezado TCP o --log-ip-options, que muestra los campos del encabezado IP Por ejemplo, la siguiente regla registra todos los paquetes que provengan de un DNS con prioridad info y el prefijo DNS-INPUT. Además registra los campos del encabezado IP. iptables -A INPUT -p udp --sport 53 -j LOG --log-level info --log-prefix "DNS-INPUT " --log-ip-options Iptables no inserta espacio entre el prefijo y el resto del mensaje, por lo que se hace necesario colocarlo manualmente. La totalidad de iptables está cubierto en un excelente tutorial (en inglés) que se puede encontrar en http://iptables-tutorial.frozentux.net/iptables-tutorial.html#LOGTARGET y su lectura está altamente recomendada para aquellos que deseen comenzar a experimentar con filtrado de paquetes. 7.3.3 Ejemplo de reglas de filtrado en un bastión Ya contamos con los conocimientos necesarios para revisar un sencillo script de filtrado de paquetes destinado a proteger sólo una máquina conectada a Internet. #!/bin/sh IPTABLES=”/usr/sbin/iptables” echo -n Aplicando Reglas de Firewall... ## FLUSH de reglas Módulo VII: Seguridad en la red 19 Facultad de Cs. Exactas y Tecnología Depto. de Electricidad, Electrónica y Computación Ing. en Computación Curso: Administración Avanzada de Linux $IPTABLES -F $IPTABLES -X $IPTABLES -Z $IPTABLES -t nat -F ## Establecemos politica por defecto: DROP $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP ## ## Debemos decir de manera explicita qué es lo que queremos abrir # Operar en localhost sin limitaciones IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A OUTPUT -o lo -j ACCEPT # Este es el servicio que ofrece la maquina a internet, por tanto todo paquete entrante se acepta para # ese puerto y los salientes vinculados se aceptan. $IPTABLES -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT $IPTABLES -A OUTPUT -p tcp -m tcp --sport 80 -m state --state RELATED,ESTABLISHED -j ACCEPT # Permitimos que la maquina pueda salir a la web $IPTABLES -A INPUT -p tcp -m tcp --sport 80 -m state --state RELATED,ESTABLISHED -j ACCEPT $IPTABLES -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT # Y tambien a webs seguras $IPTABLES -A INPUT -p tcp -m tcp --sport 443 -m state --state RELATED,ESTABLISHED -j ACCEPT $IPTABLES -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT # Reglas necesarias para FTP pasivo y activo. Se permiten conexiones entrantes YA establecidas $IPTABLES -A INPUT -p tcp -m tcp --sport 20:21 -m state --state RELATED,ESTABLISHED -j ACCEPT $IPTABLES -A OUTPUT -p tcp -m tcp --dport 20:21 -j ACCEPT $IPTABLES -A INPUT -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT $IPTABLES -A OUTPUT -p tcp -m tcp --dport 1024:65535 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT # Permitimos la consulta a un primer DNS $IPTABLES -A INPUT -s 211.95.64.39 -p udp -m udp --sport 53 -j ACCEPT $IPTABLES -A OUTPUT -d 211.95.64.39 -p udp -m udp --dport 53 -j ACCEPT # Permitimos la consulta a un segundo DNS $IPTABLES -A INPUT -s 211.95.79.109 -p udp -m udp --sport 53 -j ACCEPT $IPTABLES -A OUTPUT -d 211.95.79.109 -p udp -m udp --dport 53 -j ACCEPT # Barrera de respaldo por si cambiamos a modo ACCEPT temporalmente # Con esto protegemos los puertos reservados y otros well-known $IPTABLES -A INPUT -p tcp -m tcp --dport 1:1024 -j DROP $IPTABLES -A INPUT -p udp -m udp --dport 1:1024 -j DROP $IPTABLES -A INPUT -p tcp -m tcp --dport 1723 -j DROP $IPTABLES -A INPUT -p tcp -m tcp --dport 3306 -j DROP $IPTABLES -A INPUT -p tcp -m tcp --dport 5432 -j DROP echo " OK . Verificar lo que se aplica con: $IPTABLES -L -n" # Fin del script Módulo VII: Seguridad en la red 20
