shorewall
49
+ Arquitectura y configuración de cortafuegos: Shorewall Técnico en Administración de Redes y Sistemas TCP/IP Administración de servidores seguros en Internet Juan José Mostazo [email protected]
-
Upload
xavier-tirado -
Category
Documents
-
view
429 -
download
3
Transcript of shorewall
+
Arquitectura y configuración
de cortafuegos:
Shorewall
Técnico en Administración de
Redes y Sistemas TCP/IP
Administración de servidores seguros en Internet
Juan José Mostazo
+
09/11/10
¿Que es una puerta de enlace
(gateway)?
Una puerta de enlace es un dispositivo que permite interco-
nectar dos redes con protocolos y arquitecturas diferentes a
todos los niveles de comunicación.
Un router (o enrutador) no tiene por qué hacer de puerta de
enlace.
+
09/11/10
¿Que es un cortafuegos?
Un cortafuegos (firewall) es una parte de un sistema o una
red que está diseñado para bloquear el acceso no
autorizado, permitiendo al mismo tiempo comunicaciones
autorizadas.
+
09/11/10
iptables
Es una herramienta que permite configurar la manera en que
son tratados los paquetes de red al momento de entrar y salir
del subsitema de red del núcleo de Linux.
El núcleo cuenta con tres listas de reglas:
INPUT
OUTPUT
FORWARD
+
09/11/10
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.
+
09/11/10
iptables - Listas de reglas
+
09/11/10
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 –p icmp –j DROP
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
+
09/11/10
iptables – Ejemplos (2)
Dos formas de eliminar una regla:sudo iptables –D INPUT 1
sudo iptables –D INPUT –s 127.0.0.1 –p icmp –j DROP
Volvemos a enviar un paquete ICMP a localhost:ping –c 1 127.0.0.1
+
09/11/10
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 –A INPUT –s 192.168.128.0/17 –p
icmp –j DROP
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
+
09/11/10
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.
+
09/11/10
Instalamos shorewall
apt-get install shorewall-perl
shorewall viene por defecto sin configurar:
En /usr/share/doc/shorewall-common/examples/one-
interface 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/shorewall-
common/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
+
09/11/10
Estructura de la configuración
/etc/shorewall:
shorewall.conf: Configuración general de 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.
Hay más ficheros, pero son opcionales.
+
09/11/10
Fichero <shorewall.conf> (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.
+
09/11/10
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.
+
09/11/10
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 | OPTIONS
net1 eth0 192.168.168.63
net2 ppp0 - 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 “-”.
+
09/11/10
Fichero <zones>
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.
+
09/11/10
Zonas especiales
Independientemente del contenido del fichero <zones>,
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.
+
09/11/10
Fichero <interfaces> (1)
Formato:ZONE | INTERFACE | BROADCAST | OPTIONS
ZONE: Zona a la que se asignará el interfaz de red. Tiene
que estar previamente definida en el fichero <zones>.
INTERFACE: Nombre del interfaz de red.
BROADCAST: Indica las direcciones de red usadas para la
difusión de paquetes en este interfaz.
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.
+
09/11/10
Fichero <interfaces> (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 mediante listas de direcciones MAC.
nosmurfs: Filtra los paquetes “pitufos” (provenientes de una
dirección de difusión).
+
09/11/10
Fichero <policy> (1)
Formato:SOURCE DEST POLICY LOG … …
LEVEL
SOURCE: Zona 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.
+
09/11/10
Fichero <policy> (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 reglaall all REJECT
al final del fichero para evitar sustos.
+
09/11/10
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)
+
09/11/10
Fichero <rules> (1)
Permite añadir las excepciones pertinentes a las políticas
establecidas en el fichero <policy>
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.
+
09/11/10
Fichero <rules> (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: <net:155.186.235.1>
Una subred: <net:155.186.235.0/255.255.255.0> o
<net:155.186.235.0/24>
Un rango: <net:192.168.2.11-192.168.2.17>
Una dirección de nivel físico (MAC):
<loc:~00-A0-C9-15-39-78>
Cualquier combinación hecha mediante comas:
<net:192.168.2.11-192.168.2.17,192.168.2.200>
+
09/11/10
Fichero <rules> (3)
SOURCE y DEST (Continuación):
También se puede especificar una interfaz de red:
<net:eth0:192.168.1.5>
O exclusiones:
<net:!192.168.1.5>: Una IP de la zona net excepto
192.168.1.5.
<net:155.186.235.0/24!155.186.235.1>: Una IP de
la zona net y dentro de la red 155.186.235.0/24 excepto la IP
155.186.235.1
+
09/11/10
Fichero <rules> (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
+
09/11/10
Ejemplo básico (1)
Ejemplo de fichero <policy>:# SOURCE | DEST | POLICY | LOG | ...
# LEVEL |
$FW net ACCEPT
net $FW DROP info
all all REJECT info
Ejemplo de fichero <rules>:# ACTION | ORIGIN | DEST | PROTO | DEST
# PORT
ACCEPT net $FW icmp
ACCEPT net $FW tcp 80
ACCEPT net:192.168.1.1 $FW tcp 22
+
09/11/10
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
…
+
09/11/10
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:
<Plantilla>/<ACTION>. Ejemplo:
HTTP/ACCEPT net $FW
<Plantilla>(<ACTION>). Ejemplo:
Ping(DROP) net $FW
+
09/11/10
Macros (3)
Las macros están definidas en el directorio
/usr/share/shorewall
#ACTION SOURCE PROTO DEST SOURCE RATE USER/
# PORT PORT(S) LIMIT GROUP
PARAM - - icmp 8
+
09/11/10
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 “:<nivel de registro>” 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
+
09/11/10
Ejemplo básico (2)
Ejemplo de fichero <rules> usando plantillas:# ACTION | ORIGIN | DEST | PROTO
HTTP/ACCEPT net $FW
SSH/ACCEPT net:192.168.1.1 $FW
Ping(ACCEPT) net $FW
+
09/11/10
Fichero hosts (1)
Formato:ZONE | HOST(S) | OPTIONS
ZONE: nombre de la zona a la que se van a asociar las
direcciones IP. Tiene que estar definida en el fichero
<zones>.
HOSTS: Direcciones IP que formarán parte de la zona.
Formato: <interfaz de red>:<lista de Ips>
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 “!”)
+
09/11/10
Fichero hosts (2)
OPTIONS:
blacklist
maclist
tcpflags
nosmurfs
+
09/11/10
Ejemplo de fichero <hosts>
Ejemplo:#ZONE HOST(S) OPTIONS
subred1 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.
+
09/11/10
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...)
+
09/11/10
Acciones avanzadas: Limit (1)
Permite limitar el número de accesos de un cliente
(identificado por IP) a un puerto.
Formato:Limit:<nivellog>:<etiqueta>,<nconexiones>,<seg
undos>
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
+
09/11/10
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.
+
09/11/10
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.
+
09/11/10
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] <IP>: Fuerza que se ignoren o rechacen
(dependiendo de si se usa drop o reject) todos los paquetes
provenientes de <IP>.
shorewall allow <IP>: Borra a <IP> de la lista negra.
+
09/11/10
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
+
09/11/10
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.
+
09/11/10
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/shorewall-
knock.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
+
09/11/10
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.
+
09/11/10
Ejemplos usando KnockDoor (1)
Fichero <rules>Knock:none:EnableSSH net $FW tcp 1234
KnockDoor:none:EnableSSH,10 net $FW tcp 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.
+
09/11/10
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 <rules>:KnockTrap:none:EnableSSH net $FW tcp 1233,1235
Knock:none:EnableSSH net $FW tcp 1234
KnockDoor:none:EnableSSH,10 net $FW tcp 22
+
09/11/10
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.
+
09/11/10
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.
+
09/11/10
Cosas a tener en cuenta (2)
Antiguamente las direcciones MAC estaban grabadas a
fuego en el hardware de red. Últimamente es muy fácil
cambiar la dirección MAC por software (sobre todo en las
tarjetas de red inalámbricas), lo que hace que no sean muy
fiables (por lo menos no son una panacea) a la hora de filtrar.
