SEGURIDAD EN LA RED

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 [email protected]
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