+ Arquitectura y configuración de cortafueg corta fuegos: os:
Shorewall
Técnico en Administración de Redes y Sistemas S istemas TCP/IP Juan José Mostazo
[email protected] Administración de servidores seguros en Internet
+
¿Que es una puerta de enlace (gateway)?
Una puerta de enlace es un dispositivo que permite pe rmite interconectar dos redes con pr protoco otocolos los y arquitectura arquitecturass diferentes dif erentes a todos los niveles de comunicación. comunicación .
Un router router (o enrutador) no tiene por po r qué hacer de puerta de enlace.
+
¿Que es una puerta de enlace (gateway)?
Una puerta de enlace es un dispositivo que permite pe rmite interconectar dos redes con pr protoco otocolos los y arquitectura arquitecturass diferentes dif erentes a todos los niveles de comunicación. comunicación .
Un router router (o enrutador) no tiene por po r qué hacer de puerta de enlace.
+
¿Que es un cortafuegos?
Un cortafuegos cortafuegos (firewall) (firewall) es una parte de un sistema o una red que está e stá diseñado para para bloquear el acceso no autorizado, permitiendo al mismo tiempo comunicaciones co municaciones autorizadas.
+
iptables
Es una herra h erramienta mienta que permite configur conf igurar ar la manera en que q ue son tratados tratados los lo s paquetes de red al momento de entrar y salir del subsitema subsitema de red del núcleo n úcleo de Linux.
El núcleo cuenta con tres listas de reglas: INPUT OUTPUT FORWARD
+
iptables - Target
ACCEPT: Acepta la conexión.
DROP: Ignora el intento de conexión. No informa al origen de este hecho.
REJECT: No permite la conexión e informa de ello al origen.
+
iptables - Listas de reglas
+
iptables – Ejemplos (1)
Enviamos un ping a localhost:
ping
c 1 127.0.0.1
–
Añadimos una regla a la lista INPUT, que descarta todos los paquetes ICMP prodecentes de localhost:
sudo iptables -A INPUT
s 127.0.0.1
–
Comprobamos el estado de la lista INPUT:
sudo iptables -L INPUT
Volvemos a enviar un ping a localhost:
ping
c 1 127.0.0.1
–
p icmp
–
j DROP
–
+
iptables – Ejemplos (2)
Dos formas de eliminar una regla:
sudo iptables
–
sudo iptables
–
D INPUT 1 D INPUT
s 127.0.0.1
–
p icmp
–
Volvemos a enviar un paquete ICMP a localhost:
ping
c 1 127.0.0.1
–
j DROP
–
+
iptables – Ejemplos (3)
Enviamos un ping a nuestro compañero de la derecha:
ping
c 1 192.168.150.2XX
–
Añadimos una regla a la lista INPUT, que descarta todos los paquetes ICMP procedentes de la subred a que pertenecemos:
sudo iptables icmp j DROP
A INPUT
–
s 192.168.128.0/17
–
–
Comprobamos el estado de la lista INPUT:
sudo iptables -L INPUT
Volvemos a enviar un ping al mismo compañero:
ping
c 1 192.168.150.2XX
–
p
–
+
Shorewall
Shorewall es una herramienta para configurar puertas de enlace (gateways)/corta fuegos (firewall) para GNU/Linux.
Sin embargo, nosotros nos vamos a centrar en utilizar shorewall como corta fuegos.
Basado en iptables.
+
Instalamos shorewall
apt-getinstall shorewall-perl
shorewall viene por defecto sin configurar:
En /usr/share/doc/shorewall-common/examples/oneinterface están los ficheros de ejemplo para una configuración con una sola interfaz de red (nuestro caso).
Copiamos los ficheros en /etc/shorewall.
sudo cp /usr/share/doc/shorewallcommon/examples/one-interface/* /etc/shorewall/
Hay que activarlo editando el fichero /etc/default/shorewall y configurando la variable “startup” para que valga 1.
sudo vim /etc/default/shorewall
+
Estructura de la configuración
/etc/shorewall: shorewall. interfaces: Configura las interfaces de red que van a participar. zones: Define las zonas en las que se va a dividir la red. policy: Define las políticas por defecto que se van a seguir. rules: Define las excepciones de las políticas definidas.
shorewall.conf : Configuración general de
Hay más ficheros, pero son opcionales.
+
Fichero
(I)
Configuración general de shorewall: Opciones sobre los registros (logs): paths, formatos, etc... Opciones asociadas al comportamiento de pasarela (router). Opciones globales del firewall.
STARTUP_ENABLED = Yes | No. Indica si se desea o no que autoarranque shorewall al iniciar el equipo.
LOG_MARTIANS = Yes | No. Activa/desactiva el filtrado de paquetes con direcciones imposibles (paquetes “marcianos”).
La configuración por defecto nos vale por ahora, sólo cambiaremos STARTUP_ENABLED=Yes.
+
Probando Shorewall
Enviamos un ping a nuestro compañero de la derecha:
ping
c 1 192.168.150.2XX
–
Iniciamos Shorewall:
sudo /etc/init.d/shorewall start
Volvemos a enviar un ping al mismo compañero:
ping
c 1 192.168.150.2XX
–
Hacemos la misma prueba parando Shorewall.
+
Tablas en los ficheros de configuración
El resto de ficheros de configuración siguen una estructura en forma de tabla.
Por ejemplo: # ZONE | INTERFACE | BROADCAST net1 eth0 192.168.168.63 net2 ppp0 -
|
OPTIONS dhcp
En este caso tenemos 4 columnas. A la hora de añadir filas, toda sucesión de espacios y/o tabuladores contigua se consideran un separador de columnas. En este caso las columnas BROADCAST y OPTIONS son opcionales. En caso de no asignar valor a una columna y querer asignar valor a una que va después, hay que usar “ -”.
+
Fichero
Define las zonas en las que se va a dividir la red.
Las zonas nos permitirán organizar las reglas dependiendo de su origen/destino.
Formato: ZONE | TYPE | OPTIONS | |
| IN | OUT | OPTIONS | OPTIONS
Zone: nombre de la zona Type: ipv4: indica que la zona usa ipv4. firewall: indica que la zona define al firewall. Solo puede haber una zona de tipo firewall. El resto de opciones no nos conciernen.
+
Zonas especiales
Independientemente del contenido del fichero , existen varias zonas predefinidas, entre las que destacan:
“all”: Se puede usar para indicar cualquier zona.
“$FW”: Se puede usar para referirse a la zona del firewall.
+
Fichero (1)
Formato: ZONE | INTERFACE | BROADCAST | OPTIONS
: Zona a la que se asignará el interfaz de red. Tiene que estar previamente definida en el fichero .
ZONE
: Nombre del interfaz de red.
INTERFACE
: Indica las direcciones de red usadas para la difusión de paquetes en este interfaz.
BROADCAST
Se puede proporcionar una lista de IPs separadas por comas: 192.168.128.255,192.168.255.255
Se puede usar “detect” para que shorewall detecte
automáticamente estas direcciones.
+
Fichero (2) :
OPTIONS
dhcp: Indica que se va a permitir el tráfico dhcp en este interfaz.
routefilter: Activa los filtros anti-escucha/usurpación en este
interfaz.
logmartians: Activa el registro de los paquetes “marcianos”.
blacklist: Activa el filtrado
mediante listas negras de direcciones
IP.
maclist: Activa el filtrado
nosmurfs: Filtra los paquetes “pitufos” (provenientes de una
dirección de difusión).
mediante listas de direcciones MAC.
+
Fichero (1)
Formato:
SOURCE
DEST
SOURCE: Zona
POLICY
LOG LEVEL
…
…
origen. Se puede usar “all” para indicar que la
política se aplicará para cualquier zona de origen. DEST: Zona
destino. Se puede usar “all” para indicar que la
política se aplicará para cualquier zona de destino. POLICY: Política que se va a aplicar. ACCEPT: Acepta la conexión. DROP: Ignora el intento de conexión. No informa al origen de este hecho. REJECT: No permite la conexión e informa de ello al origen. LOG_LEVEL: Nivel en el que se registrarán las conexiones.
+
Fichero (2)
El orden de las entradas es importante. Si una conexión casa con varias reglas, se aplicará la regla que esté antes en el fichero policy.
Es recomendable añadir una regla
all all REJECT
al final del fichero para evitar sustos.
+
Niveles de registro (syslog)
debug (mensajes de depuración)
info (mensajes de información)
notice (mensaje indicando)
warning (Aviso)
err (errores)
crit (errores críticos)
alert (errores que requieren una atención inmediata)
emerg (errores indicando que sistema es inestable)
none (no registrar)
+
Fichero (1)
Permite añadir las excepciones pertinentes a las políticas establecidas en el fichero
Una vez más, el orden de las reglas es importante, dado que se van evaluando en orden.
Columnas básicas: ACTION: Acción a realizar en caso que se cumplan las condiciones. SOURCE: Origen de la conexión. DEST: Destino de la conexión. PROTO: Protocolo usado en la conexión. DEST PORT: Puerto de destino. SOURCE PORT: Puerto de origen.
+
Fichero (2)
Acciones básicas:
ACCEPT, DROP y REJECT
SOURCE y DEST: Se indican mediante zonas: $FW, all, ... Se puede limitar a ciertas direcciones: Una IP:
Una subred: o
Un rango: Una dirección de nivel físico (MAC):
Cualquier combinación hecha mediante comas:
+
Fichero (3)
SOURCE y DEST (Continuación):
También se puede especificar una interfaz de red:
O exclusiones: : Una IP de la zona net excepto 192.168.1.5. : Una IP de la zona net y dentro de la red 155.186.235.0/24 excepto la IP 155.186.235.1
+
Fichero (4)
PROTO:
Protocolos normales, como pueden ser: tcp, udp, icmp.
Se pueden mezclar usando comas: “tcp,udp”.
También se puede indicar “all” para indicar todos los protocolos
DEST PORT y SOURCE PORT:
Es una lista de puertos (separada por comas): Puede ser un numero de puerto Un puerto especificado mediante un nombre de servicio (ver /etc/services) Un rango: 6000:6003
+
Ejemplo básico (1)
Ejemplo de fichero :
# SOURCE | DEST | POLICY # $FW net ACCEPT net $FW DROP all all REJECT
| LOG | ... LEVEL | info info
Ejemplo de fichero :
# ACTION | ORIGIN | # ACCEPT net ACCEPT net ACCEPT net:192.168.1.1
DEST | PROTO | DEST PORT $FW icmp $FW tcp 80 $FW tcp 22
+
Macros (1)
Permiten simplificar las reglas (no hace falta indicar los parámetros obvios, por ejemplo, el protocolo y los puertos)
Existen plantillas predefinidas para los servicios básicos: SSH HTTP, HTTPS DNS Ping
…
+
Macros (2)
Se usan en la columna ACTION, pero dado que no implican la acción que se va a realizar, hay que combinar la plantilla con la acción a realizar. Se pueden usar dos sintaxis:
/. Ejemplo:
HTTP/ACCEPT
net
$FW
(). Ejemplo:
Ping(DROP)
net
$FW
+
Macros (3)
Las macros están definidas en el directorio /usr/share/shorewall
#ACTION # PARAM
SOURCE
PROTO
-
-
DEST PORT icmp
SOURCE RATE USER/ PORT(S) LIMIT GROUP 8
+
Registrando los sucesos
Además, podemos configurar para que al aplicarse una regla, esta se almacene en los registros del sistema.
Para ello basta con añadir “:” en la
columna de ACTION.
Por ejemplo: REJECT:info
net $FW
icmp
También se puede aplicar cuando se usan macros: Ping(DROP):info
net $FW
+
Ejemplo básico (2)
Ejemplo de fichero usando plantillas:
# ACTION HTTP/ACCEPT SSH/ACCEPT Ping(ACCEPT)
| ORIGIN net net:192.168.1.1 net
| DEST | PROTO $FW $FW $FW
+
Fichero hosts (1)
Formato: ZONE |
HOST(S) | OPTIONS
nombre de la zona a la que se van a asociar las direcciones IP. Tiene que estar definida en el fichero .
ZONE:
HOSTS
: Direcciones IP que formarán parte de la zona.
Formato: : La lista de IPs es una combinación (usando comas) de los siguientes elementos: Una dirección IP. Un rango de direcciones IP. Una red.
También se pueden usar las exclusiones (usando “!”)
+
Fichero hosts (2) OPTIONS:
blacklist
maclist
tcpflags
nosmurfs
+
Ejemplo de fichero
Ejemplo:
#ZONE subred1
HOST(S) OPTIONS eth1:192.168.128.0/17
En este ejemplo, estamos creando una zona que contiene a las IP de la subred 192.168.128.0/17
Si consideramos que a través de eth1 salimos a internet, este mecanismo nos permite simplificar las reglas del fichero rules en caso de que tengamos alguna afinidad con esta subred.
+
Restringir por usuario/grupo
Solo funciona cuando se estar restringiendo paquetes con origen en el firewall.
Formato [!][nombre de usuario][:nombre de grupo]
Ejemplo:
ACCEPT
$FW
net
tcp
-
80
-
-
www-data
El usuario www-data es el que normalmente ejecuta los servidores web en linux (apache2, lighttpd, etc...)
+
Acciones avanzadas: Limit (1)
Permite limitar el número de accesos de un cliente (identificado por IP) a un puerto.
Formato: Limit::,,
Ejemplo: Limit:none:SSHA,3,60
net
$FW
tcp
22
En este caso, un cliente solo podría iniciar tres conexiones al puerto 22 en una franja de tiempo de 60 segundos. No se registrarán los intentos fallidos de conexión
+
Acciones avanzadas: Limit (2)
La acción Limit etiqueta las IP con la etiqueta indicada para poder controlar el numero de conexiones. Esta se podría usar para realizar reglas más complejas.
Sin embargo, para su uso normal, es importante usar una etiqueta diferente para cada una de las reglas Limit que usemos.
+
Utilizando listas negras (1)
shorewall.conf: BLACKLISTNEWONLY=No – Se comprueban las listas negras cada vez que se recibe una paquete de red. BLACKLISTNEWONLY=Yes – Solo se comprueban las listas negras cuando se establece una conexión. BLACKLIST_DISPOSITION=DROP | REJECT BLACKLIST_LOGLEVEL= Nivel en el que se registrarán los paquetes filtrados por las listas negras.
+
Utilizando listas negras (2)
Hay que activar la opción blacklist en los interfaces de red en los que queramos que se filtre mediante las listas negras.
El fichero /etc/shorewall/blacklist contiene una lista negra estática.
Si se modifica el fichero /etc/shorewall/blacklist se puede recargar sin parar shorewall mediante el comando “shorewall refresh”
También se puede añadir elementos a la lista negra de forma dinámica: shorewall [drop|reject] : Fuerza que se ignoren o rechacen (dependiendo de si se usa drop o reject) todos los paquetes provenientes de . shorewall allow : Borra a de la lista negra.
+
Ejemplo de uso de listas negras
Crear un script que descargue y procese las listas de IPs de: http://www.spamhaus.org/drop/drop.lasso
Ejecutar: shorewall refresh
+
fail2ban
Programa que revisa los registros de ciertas aplicaciones (ssh, smtp, ...) y avisa a shorewall para bloquee las conexiones de las IPs que generen un determinado número de fallos de autenticación.
Instalación:
apt-get install fail2ban cd /etc/fail2ban
modificar jail.conf: En nuestro caso, lo importante es modificar banaction para que notifique a shorewall.
Es bastante recomendado añadir “BLACKLISTNEWONLY=No” al fichero shorewall.conf
Con “invoke-rc.d fail2ban start ” arrancamos el
servicio.
+
Extendiendo shorewall
Shorewall permite añadir nuevas funcionalidades haciendo uso de scripts en Perl.
Ejemplo:
Descargamos los ficheros:
wget http://antares.ls.fi.upm.es/shorewallknock.tar.bz2
Descomprimimos los ficheros en /etc/shorewall
sudo tar -xjvf shorewall-knock.tar.bz2 /etc/shorewall
Ahora disponemos de tres nuevas acciones: Knock KnockTrap KnockDoor
+
Llamando a la puerta
Con las nuevas acciones podemos configurar el corta fuegos de una forma interesante: ¡Podemos dejar entrar solo a la gente que llame a la puerta de forma correcta!
La acción Knock añade una etiqueta a la IP que case con la regla.
La acción KnockTrap elimina una etiqueta en caso de que se cumplan las condiciones de la regla.
La acción KnockDoor fuerza que se ignore el paquete en caso de que la IP de origen no tenga una etiqueta dada. Además comprueba que esta etiqueta la haya obtenido en un periodo de tiempo determinado.
+
Ejemplos usando KnockDoor (1)
Fichero
Knock:none:EnableSSH net KnockDoor:none:EnableSSH,10 net
$FW $FW
tcp tcp
1234 22
Por defecto, el puerto ssh va a estar cerrado.
En caso de que alguien acceda al puerto 1234, la acción Knock le asignará la etiqueta EnableSSH. Este control de etiquetas se lleva a cabo relativo a la dirección IP de origen.
La acción KnockDoor comprueba si la dirección origen esta marcada con la etiqueta EnableSSH y esta ha sido obtenida como mucho hace 10 segundos, en cuyo caso permite la conexión. En caso contrario la ignora.
+
Ejemplos usando KnockDoor (2)
El problema de la implementación anterior es con los escaneados de puertos.
Por ejemplo, si se hace un escaneo de puertos que vaya comprobando los puertos de forma descendente, pasaría primero por el puerto 1234 y luego por el puerto 22. En ese caso el puerto sería visible para el escaneador de puertos.
Podemos mejorar la eficiencia del mecanismo si usamos las siguientes reglas en el fichero : KnockTrap:none:EnableSSH net $FW Knock:none:EnableSSH net $FW KnockDoor:none:EnableSSH,10 net $FW
tcp 1233,1235 tcp 1234 tcp 22
+
Aspectos de un firewall no vistos en clase
Shorewall no permite controlar las conexiones en base a las aplicaciones. No puedes decir que solo apache2 puede escuchar en el puerto 80. Tampoco puedes indicar que Firefox solo pueda acceder al puerto 80.
En Unix, el único control de este tipo es que solo las aplicaciones ejecutadas por root pueden usar los puertos en el rango 1-1000.
En Linux existe la posibilidad de controlar este comportamiento con otras herramientas, por ejemplo con SELinux o appArmor.
+
Cosas a tener en cuenta (1)
Administrar un cortafuegos en remoto (por ejemplo, mediante ssh) no es muy recomendable ya que se puede perder la conexión al modificar inadecuadamente las reglas del firewall.
En caso de hacerlo, hay que tomar precauciones. Por ejemplo, utilizar “shorewall safe -restart” para actualizar las reglas del firewall. Este comando reiniciará shorewall y nos preguntará si todo a ido bien, en caso de no contestar (cosa que pasaría si perdemos la conexión), pararía el firewall.
La función de un firewall es controlar las conexiones que se pueden realizar. En ningún caso se puede esperar que un firewall elimine los fallos de seguridad de los servicios a los que deje acceder, en el mejor de los casos ayudará a evitarlos, pero seguramente no los elimine completamente.
