En esta habitación exploramos diferentes formas de proteger un servidor Ubuntu 18.04. Se cubrirá un amplio rango de temas de hardening (blindado) con desafíos para probar nuestro conocimiento.

La habitación proporciona un Ubuntu 18.04 semiconfigurado para las diferentes tareas. Se puede acceder con las credenciales spooky:tryhackme que permiten hacer todo lo que necesitamos.

El objetivo es que, al final de esta habitación, seamos capaces de explicar los temas que se muestran y aplicarlos en nuestro día a día.

Aunque estemos usando un Ubuntu 18.04, casi la totalidad de conceptos se aplican a un 20.04 o incluso otros sabores de Linux.

1. Asegurando cuentas de usuario

El principio básico es el de conceder el privilegio mínimo necesario para que cada usuario tenga acceso suficiente para realizar sus tareas diarias y nada más.

Eso significa que Recursos Humanos no debería tener acceso a los registros del sistema, por ejemplo.

Los peligros de Root

El usuario root es el de mayores privilegios en un sistema Linux. Es capaz de hacer cualquier cosa, así que no es lo ideal en la mayoría de casos.

Hay una herramienta en Linux que permite a cuentas estándar el acceso a programas y binarios como si fueran administradores y usando sus propias contraseñas: esa herramienta es sudo.

Sudo - Parte 1

Sudo significa «Super user do» y permite a cualquier usuario ejecutar aplicaciones como si fuera administrador.

Es importante porque puede permitir a los usuarios hacer ciertas tareas de administración sin recurrir todo el rato al administrador.

Algunas de sus ventajas son:

  • Retrasar a los hackers si hemos deshabilitado la identificación como root. Así, el atacante no sabrá a por qué cuenta ir y eso le enlentecerá.
  • Permitir a ciertos usuarios tareas que requieren un privilegio superior.
  • Se alinea con el principio del menor privilegio posible.

Añadiendo usuarios a un grupo predeterminado de administración

Método 1. Es el más fácil que permite a los usuarios utilizar el comando sudo.

Para añadir a Nick al grupo sudo, podemos hacer:

usermod -aG sudo nick

Usar la opción -a ayuda a Nick a retener cualquier membresía en grupos existentes.

También se puede añadir al grupo sudo durante la creación con este comando.

useradd -G sudo nick

¿Qué significa añadir un usuario al grupo sudo? Permite a los usuarios ejecutar cualquier programa como root usando sus contraseñas. Para comprobar esos privilegios podemos hacer:

sudo -l

Comprobando privilegios con sudo -l

En la imagen, las últimas líneas son las importantes y nos dicen que Nick (como parte del grupo sudo), puede ejecutar todos los comandos como cualquier usuario en cualquier máquina.

Hay otra forma de ver esta información.

visudo

Esto abre el archivo de políticas sudo almacenado en /etc/sudoers. Lo podemos hacer como Nick en este caso, pero necesitamos usar sudo si es que queremos editarlo, ya que solo lo puede hacer el administrador.

Comprobando privilegios con visudo

Esto da la misma información que sudo -l pero con una diferencia, %sudo indica que es para el grupo, sudo. Hay otros grupos en este archivo como «admin». Aquí es donde los administradores pueden configurar qué programas puede ejecutar un usuario de un cierto grupo y si necesita una contraseña o no.

A veces vemos:

%sudo ALL=(ALL,ALL) ALL NOPASSWD: ALL

Esa parte de NOPASSWD significa que el usuario del grupo sudo no necesita introducir su contraseña para usar privilegios sudo.

Normalmente, esto no se recomienda, ni siquiera para uso en el hogar.

Método 2. Usa el archivo de políticas de sudo que hemos visto.

Está muy bien poder modificar qué puede hacer un grupo entero, pero eso es solo para Ubuntu. Si manejamos una red de sabores de Linux, donde el grupo sudo se puede llamar de forma diferente, este método puede ser preferible.

Lo que podemos hacer es añadir un Alias de Usuario al archivo de políticas y añadir esos usuarios a ese alias, o añadir líneas para cada usuario individual.

La primera imagen crea el Alias de Usuario ADMIN y le asigna 3 usuarios, para luego establecer que este Alias tiene poderes sudo.

Archivo de políticas y Alias

Archivo de políticas y Alias

La segunda opción de alias individuales por usuario no es recomendable. En una gran red, esto se descontrola rápidamente.

La primera opción es la mejor apuesta y podremos añadir usuarios a este alias controlando fácilmente a qué comandos tienen acceso con sudo.

Sudo (parte 2)

Asignando alias de comandos.

Este método asegura que los usuarios son asignados a los grupos que solamente tienen acceso a las aplicaciones necesarias para completar sus tareas diarias.

Se hace permitiendo al usuario root definir lo que se llaman alias de comandos en el archivo de políticas sudo. Igual que establecimos un alias de usuario en este archivo en la anterior tarea, pondremos un alias de comando en el mismo archivo.

Se va a crear otro Alias de usuario llamado SYSTEMADMINS y asignar unos cuantos usuarios a ello.

Usando:

sudo visudo

Editamos la línea bajo el comentario:

# Cmnd alias specification

Añadiremos simplemente unos pocos comandos a la lista. Estos no significan nada en el contexto actual de lo que necesitaría un Administrador de Sistema. En realidad, un sysadmin tendrá acceso sudo a casi todas las cosas, pero por brevedad, vamos a incluir solo algunos.

Archivo de políticas y Alias

Archivo de políticas y Alias

El alias de comando SYSTEM permite al usuario ejecutar:

systemctl restart
systemctl restart ssh
chmod

¿Qué pasa si alguien en SYSTEMADMINS trata de ejecutar systemctl restart apache2?

Fallaría porque el servicio específico no ha sido definido por el alias. Sin embargo, sí podrá hacerlo con el servicio ssh y por último usar chmod con todas las opciones.

Si quisiéramos que pudiera reiniciar todos los servicios, podemos usar el carácter comodín al final del nuevo alias, así:

/usr/bin/systemctl restart *

Maneras diferentes de asignar comandos

También podemos asignar Alias de Comandos a usuarios individuales, comandos específicos a usuarios individuales y alias de comandos a grupos:

Archivo de políticas y Alias

Así, dark es asignado específicamente al alias de comando WEBDEV, al usuario paradox se asigna solamente el comando cd y el Alias de usuario HR puede realizar solamente tareas especificadas en el Alias de comando HR.

Una mención a alias de host

Existen. Son una manera de instaurar políticas sudo a través de la red y de diferentes servidores.

Por ejemplo, puedes tener el Alias de Host MAILSERVERS, conteniendo a los servidores mail1 o mail2. Estos Alias de Host tienen ciertos usuarios o grupos asignados a él, como hemos demostrado en estas dos últimas tareas y ese Alias de Host tiene un Alias de Comando asignado, que establece qué comandos pueden ejecutar esos usuarios.

Cuando esos usuarios ejecuten un comando en mail1 o mail2, el servidor comprobará el archivo de políticas sudo para cada servidor en la red.

En un entorno de hogar o pequeña y mediana empresa, suele ser más fácil copiar el archivo de políticas en cada servidor de la red. Esto se aplica a grandes redes empresariales e incluso en esos casos usarán un Ansible centralizado o cualquier otra automatización para eso.

Deshabilitando el acceso root

Normalmente, es una buena idea restringir el acceso a root. Se puede hacer por varios métodos:

  • Deshabilitando que se pueda uno identificar como root en la shell.
  • Deshabilitando la autenticación root en ssh.
  • Deshabilitando root mediante el uso de PAM (Password Authetication Module).

Deshabilitar la autenticación como root en la shell

Una tarea muy simple, necesitamos editar el archivo /etc/password para que ponga lo siguiente:

root❌0:0:root:/root:/usr/sbin/nologin

Normalmente, la última parte está configurada como /bin/bash, pero cambiando a /usr/sbin/nologin nos denegará educadamente la autenticación como root. Hacer esto previene a los usuario de ejecutar sudo -s.

Deshabilitar la autenticación como root en ssh

Otra tarea sencilla con un cambio de configuración en /etc/ssh/sshd_config.conf

Deshabilitando root de ssh

Es simplemente cambiar #PermitRootLogin a no.

Deshabilitar root usando PAM

PAM (Password Authetication Module) es una suite de librerías compartidas usada para autenticar dinámicamente un usuario en aplicaciones o servicios de un sistema Linux.

La configuración de PAM está controlada por el archivo conf en /etc/pam.d o /etc/pam.conf.

El archivo pam.conf nos advierte:

Deshabilitando root en PAM

CUIDADO: Editar /etc/pam.d o /etc/pam.conf nos puede dejar fuera del sistema sin posibilidad de entrar.

Vamos con un ejemplo, porque hay bastante tela que cortar. Vamos a ver cómo deshabilitar la autenticación de root SSHD porque parece un tema habitual.

Podemos configurar nuestro /etc/pam.d/sshd de la siguiente manera.

Configurando pam.d

Y por último, en /etc/ssh creamos un archivo llamado deniedusers y usamos Vim para añadir root en la parte superior, guardar y cerrar.

Para la configuración de arriba, esto es lo que hace cada parte:

  • auth: el tipo de módulo.
  • required: una opción que establece si se usa el módulo de arriba debe pasar y, si no, fallar.
  • pam_listfile.so: un módulo que provee de una manera de denegar o permitir servicios basado en un archivo arbitrario.
  • onerr=succeed: argumento del módulo.
  • item=user: argumento del módulo que especifica qué está listado en el archivo y qué deberíamos chequear.
  • sense=deny: argumento del módulo que especifica qué acción realizar si el nombre es encontrado en el archivo. Si no lo encuentra, se pide la acción contraria.
  • file=/etc/ssh/deniedusers: argumento de módulo que especifica el archivo, el cual contiene una línea por argumento (en este caso, los usuarios a los que negamos acceso).

Deshabilitando escapes a la shell

Si hemos visitado GTFObins, sabremos que existen maneras en las que los usuarios sin privilegios escalan a administradores usando escapes a shell desde editores de texto.

Por ejemplo, estos son los escapes desde Vim.

Escapes a shell desde Vim

  • El primer escape se hace añadiendo la opción -c que ejecutará el comando /bin/sh en este caso.
  • El segundo escape configura la variable «shell» a /bin/sh y luego la llama.

Si en cualquiera de esos ejemplos eres capaz de ejecutar Vim con privilegios de root, puedes escapar a una shell de administración.

Escapando a shell de root desde Vim

A fin de evitar esto, usamos sudoedit en el archivo de políticas en lugar de cualquier editor, ya que sudoedit no tiene escapes a shell. Se puede hacer de la siguiente manera:

Usando sudoedit

Blindando y cerrando directorios home

Por defecto, Ubuntu configura un nuevo directorio de usuario con los permisos 755 (UMASK de 022). Esto significa que cualquier otro usuario y grupo puede leer y escribir en ese directorio de usuario.

Esta no es una buena práctica y se deja al administrador del sistema cambiar esto.

La UMASK se configura en /etc/login.defs, así que echemos un vistazo rápido al archivo.

Archivo /etc/login.defs

Observemos la UMASK destacada en la imagen, pero atentos a la nota de Ubuntu. Nos dice que 077 sería más seguro. Cambiando eso aquí haría cualquier nuevo directorio de usuario más seguro.

Nota: Los permisos resultantes que se ponen son 777, así que en UMASK, en este caso:

777 - 022 = 755

Como 777 es el equivalente numérico de rwxrwxrwx en Linux, restar eso de UMASK nos da los permisos resultantes que serán configurados en el directorio home del usuario y sus archivos.

Por eso, 077 es más seguro, ya que es 777 - 077 = 700, es decir que usuarios y grupos no pueden hacer nada en el directorio si no son dueños de él.

Configurar la complejidad de la contraseña

Pwquality es un módulo PAM que permite configurar requisitos de complejidad de contraseña para tus usuarios. Es bastante fácil de instalar en Ubuntu.

sudo apt install libpam-pwquality

Una vez instalado, añade automáticamente una entrada en /etc/pam.d/common-password. El directorio pam.d es solamente otra ubicación donde PAM añade archivos para servicios básicos como ssh, autenticación básica, etc.

Modificación del common-password por pwquality

Veamos algunas diferencias de lectura respecto a lo que hemos visto ya:

  • password: módulo.
  • requisite: módulo; establece que si el módulo falla, la operación termina inmediatamente con un fallo sin invocar otros módulos.
  • pam_pwquality.so: chequea el archivo pwquality.conf en cuanto a requerimientos.
  • retry=3: permite al usuario reintentar la contraseña 3 veces antes de devolver error.

Si miramos a las pocas líneas del archivo pwquality.conf que podemos encontrar en /etc/security, podemos ver que hay muchas opciones que el administrador puede establecer para la calidad de la contraseña. Las líneas simplemente necesitan quitar el signo de comentario y modificarlas.

pwquality.conf

Configurando otros requisitos de contraseña

4 conceptos importantes de la contraseña:

  • Complejidad.
  • Extensión.
  • Expiración.
  • Historia.

Ya hemos cubierto las 2 primeras, vamos a por las 2 últimas.

Expiración de la contraseña

Cuando abrimos /etc/login.defsy vamos hacia abajo, hasta la sección «Password aging controls», podemos configurar la expiración de la contraseña ahí.

Hay unas pocas opciones.

Expiración de contraseña

  • PASS_MAX_DAYS: Por defecto, 99999; Establece el número máximo de días que se puede usar una contraseña.
  • PASS_MIN_DAYS: Por defecto 0; Establece el número mínimo de días que un usuario puede mantener su contraseña antes de cambiarla.
  • PASS_WARN_AGE: Por defecto 7; Establece el número de días antes de la expiración en los que el sistema avisará al usuario de la misma.

Suele considerarse buenas prácticas que la contraseña de usuario expira después de 90 días con una edad mínima de al menos 1.

Historia de la contraseña

Normalmente, se considera buena práctica recordar las 10 contraseñas previas. Esto asegurará que dichas contraseñas sean diferentes y no se reutilicen.

Poner una edad mínima de 1 y una historia de 10 significa que alguien deberá esperar, al menos 11 días, antes de volver a usar su contraseña original.

Normalmente, esto basta para disuadir a cualquiera.

Para configurar la historia de contraseñas en Ubuntu, nos vamos de nuevo a /etc/pam.d/common-password. Echemos un vistazo a esta imagen para ver una configuración de ejemplo.

Historia de contraseña

La línea de pwquality se ha quitado para simplificar. Veamos la línea superior. De nuevo, iremos viendo la configuración PAM, que no es fácil de entender, la verdad, con lo que siempre es útil su documentación.

  • password: tipo de módulo que estamos referenciando.
  • required: módulo donde el fallo devuelve un fallo a la PAM-API.
  • pam_pwhistory.so: módulo que configura los requisitos de la historia de la contraseña.
  • remember=2: opción para que el módulo pam_pwhistory.so recuerde las últimas n contraseñas (aquí, n=2). Estas contraseñas están guardadas en /etc/security/opasswd
  • retry=3: opción para que el módulo pam_pwhistory.so haga 3 peticiones al usuario antes de devolver fallo.

Puede ver un cambio en la línea pam_unix.so bajo la superior. Aquí hacemos uso de use_authtok y le decimos al módulo que utilice shadow, lo que creará contraseñas shadow cuando actualice una contraseña de usuario.

Los peligros del grupo lxd

Ubuntu, por la razón que sea y a menos que se especifique de otra manera, coloca a los usuarios en el grupo lxd. Un grupo conocido por ser punto para la escalada de privilgios.

Deberíamos quitar a los usuarios del mismo.

Es tan prevalente que incluso Linux-Smart-Enumeration chequea esto. Usando adduser no se añade al usuario a ningún grupo predefinido y probablemente debería utilizarse cuando se añadan nuevos usuarios.

Test de lo visto hasta ahora

¿A qué grupo se añade automáticamente los usuarios en Ubuntu?

sudo

¿Qué comando usamos para añadir al usuario existente nick al grupo sudo?

usermod -aG sudo nick

¿Qué comando puede introducir un usuario para saber si puede ejecutar sudo?

sudo -l

¿En qué archivo se almacena la política sudo?

/etc/sudoers

Cuando estamos en visudo y vemos %___, ¿qué significa el signo %?

group

Este alias permite al usuario asignar un nombre, como «ADMINS» a un grupo de personas.

User

¿Qué alias te permite crear un grupo de comandos que puedes asignar al usuario Alias? (En visudo está abreviado a Cmnd, pero debemos poner completo).

Command

Emacs tiene un escape a shell (Yey/Ney)

Yey

¿Cuál es la longitud mínima recomendada por NIST para una contraseña?

8

Cuando usamos el módulo pwhistory, ¿qué archivo contiene las contraseñas previas del usuario?

opasswd

¿Qué principio establece que cada usuario debe tener solamente acceso suficiente para sus tareas diarias y nada más?

Principle of least privilege

Lo básico sobre firewalls

Un cortafuegos es: «Un dispositivo de seguridad de red que supervisa el tráfico de red entrante y saliente y decide si permite o bloquea un tráfico específico en función de un conjunto definido de reglas de seguridad».

El firewall puede ser de dos clases:

  • Basado en red.
  • Basado en host.

Firewall basado en host

Como suena. Se instalan en máquinas host y monitorizan su tráfico. Por ejemplo, el Windows Firewall.

Se pueden configurar reglas y normalmente se instala en un servidor Windows, que puede actuar entonces como cortafuegos de toda la red.

Firewall basado en red

Es una pieza de hardware que puede tener dos o más tarjetas de interfaz de red.

Se coloca en la frontera entre la red interna e Internet y todo el tráfico pasa a través del Firewall antes de entrar desde Internet o de salir hacia ella.

Una nota sobre cortafuegos de aplicación web

Los Web Application Firewall (WAF) se suelen colocar en la zona demilitarizada (DMZ) de una red y ayudan a proteger el servidor web de amenazas internas y externas.

Sin embargo, no deberíamos confiar en un cortafuegos de aplicación web para proteger una red entera. En su lugar, habría que añadir un cortafuegos basado en red en la frontera de la misma para añadir una capa de seguridad.

Iptables

Iptables no es un cortafuegos, es solo una manera de interactuar con netfilter que viene en toda distribución Linux.

Ubuntu viene, de hecho, con Ufw (Uncomplicated Firewall), que es un frontend (interfaz) que hace fácil usar iptables.

Los 4 componentes de iptables

Juntos le otorgan la funcionalidad que tiene:

  • Filter table. Tabla de filtro, que ofrece la protección básica que esperas de un cortafuegos.
  • Network Address Translation table. Tabla de traducción de direcciones de red, que conecta las redes pública de Internet a las redes privadas.
  • Mangle table. La tabla de destripado, para destripar y abrir en canal los paquetes conforme pasan a través del cortafuegos.
  • Security table. Tabla de seguridad, usada solamente por SELinux.

Familiarizándose con los comandos iptables

Para eso, ejecutamos:

sudo iptables -L

iptables

En la imagen de arriba se puede ver que no hay reglas. Eso significa que se permite todo el tráfico entrante y saliente del sistema.

Expliquemos brevemente las cadenas que tenemos aquí.

  • INPUT - paquetes que llegan al cortafuegos.
  • FORWARD - paquetes enrutados a otro NIC de la red, para paquetes en la red local que son reenviados (forwarded).
  • OUTPUT - paquetes que salen del cortafuegos.

Configuración de iptables

Ahora que sabemos las cadenas, podemos configurar nuestra tabla vacía y añadir algunas reglas.

A estas reglas se les llama Access Control List (ACL) o Listas de Control de Acceso.

Estas reglas determinan el tráfico que está permitido que entre y salga de la red. En nuestro caso, nuestra ACL definirá solo las reglas para un único host.

En una red real, se usaría un firewall mucho más robusto (posiblemente, basado en red) a fin de defender la red. Sin embargo, una utilidad como Ansible podría usarse para distribuir fácilmente reglas de cortafuegos basadas en host a otras máquinas, de una manera sencilla y rápida.

Nota: Las ACL’s son leídas por el sistema de arriba hasta abajo. Tengamos esto en mente mientras leamos las reglas que añadiremos.

Añadiendo reglas básicas

Vamos a añadir una que aceptará paquetes de máquinas que hayan iniciado conexiones con nuestro host.

Hay unas cuantas opciones para llevar la cuenta cuando estemos configurando nuestra tabla de filtrado. Puedes verlas todas en la documentación de iptables.

Empecemos por la primera regla:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
  • -A INPUT: Añade a la cadena INPUT.
  • -m conntrack: Llama a un módulo de iptable. En este caso , conntrack, que lleva la cuenta de las conexiones. Esta opción permite el uso de la siguiente.
  • –ctstate ESTABLISHED,RELATED: Disponible gracias a la opción anterior, llevará cuenta de las conexiones que ya están establecidas (ESTABLISHED) y relacionadas (RELATED). RELATED significa simplemente que es nueva, pero parte de otra conexión ya establecida.
  • -j ACCEPT: La j es de jump (a saber por qué). Esta opción simplemente acepta el paquete y detiene el proceso de otras reglas.

Permitiendo el tráfico a través de puertos específicos

Tenemos varias maneras de hacer esto.

  1. sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT
  2. sudo iptables -A INPUT -p tcp --dport 21 -j ACCEPT
  3. sudo iptables -A INPUT -p udp --dport 4380 -j ACCEPT

Todas tienen las mismas opciones, la diferencia está en lo que aceptan que entre y en cómo está escrito.

Hemos visto ya la opción -A INPUT, veamos las otras:

  • -p (opción). Qué protocolo de conexión usar. Solo podemos poner tcp o udp.
  • –dport. Controla el puerto de destino en el que queremos que opere la regla.

En el primero ejemplo hemos puesto el –dport a «ssh». Esta es una sintaxis válida, pero podríamos haber puesto 22. Del mismo modo, en la segunda podríamos haber puesto ftp en lugar de 21.

El último ejemplo es solo para que veamos que podemos poner en -p otra cosa que no sea tcp.

Bloqueando tráfico entrante

Veremos 2 cosas:

  1. Cómo configurar iptable para bloquear tráfico.
  2. Cómo configurar una regla de denegación implícita.

Digamos que tenemos un servidor SMB que se usa internamente para compartir archivos en la red THM. No se desea que nadie externo sea capaz de acceder o incluso intentar acceder. En ese caso, se podría añadir una regla como:

sudo iptables -A INPUT -p tcp --dport smb -j DROP

Esta instrucción deja caer todos los paquetes entrantes de conexiones tcp al puerto en el que smb está configurado.

Regla de denegación implícita

Después de que hayas configurado todas tus reglas y pienses que has terminado con iptables, piensa de nuevo.

Hay una regla más que todo administrador de sistemas debería aplicar a su cortafuegos antes de considerarlo completo. Se llama la regla de denegación implícita que establece que: «si no he permitido explícitamente algo a través del Firewall, entonces DENIÉGALO implícitamente, sin dudarlo».

Es una regla catch-all que podemos aplicar con.

sudo iptables -A INPUT -j DROP

Este comando añadirá la siguiente línea a iptable.

Regla de denegación implícita

Puedes ver que todos los protocolos de cualquier lugar, que vayan a cualquier lugar de la red interna serán dejados caer.

Breve nota sobre tráfico saliente

Para eso, debes cambiar la opción -A.

Guardando la configuración

Desafortunadamente, iptables no se guarda en memoria y necesita ser configurado cada vez que reinicies la máquina. Es algo poco habitual, pero sucede. A fin de guardar la configuración, debemos ejecutar:

sudo iptables-save

UFW, Uncomplicated Firewall para Ubuntu

UFW tiene la función de crear reglas de cortafuegos menos complicadas. Por defecto, UFW está inactivo y puedes ver su estado con.

sudo ufw status

Para habilitar.

sudo ufw enable

Para deshabilitar.

sudo ufw disable

Permitiendo y denegando puertos

El formato básico es:

sudo ufw <allow/deny> <puerto>/<opcional:protocolo>

Así, para permitir conexiones TCP en el puerto 9000 haríamos:

sudo ufw allow 9000/tcp 

Denegar algo es igual de fácil, por ejemplo, tráfico telnet en el puerto 23.

sudo ufw deny 23

Permitiendo y denegando puertos

Se pueden introducir servicios en lugar de puertos con:

sudo ufw <allow/deny> <nombre del servicio>

Por ejemplo, permitir ssh es:

sudo ufw allow ssh

Denegar se hace de manera análoga.

sudo ufw deny ftp

Sintaxis avanzada

Con ella se puede denegar un rango de IP’s o subredes, por ejemplo. Se puede saber más en la documentación de UFW.

Vamos con las preguntas:

Este tipo de firewall tiene dos tarjetas NIC.

network-based

Este tipo de firewall se instala en una máquina host y sus reglas se aplican solo a ella.

host-based

Los cortafuegos de aplicación web añaden una capa extra de seguridad a los servidores web. ¿Dónde deberían ser instalados?

demilitarized zone

Iptables no es lo mismo que cortafuegos Linux. ¿Cuál es el framework con el que iptables nos permite interactuar?

netfilter

Este acrónimo de 3 letras es un conjunto de reglas que define lo que el firewall debería permitir y denegar (Abreviatura de Access Control List)

ACL

¿Qué opción de iptables nos permite llevar la cuenta del estado de la conexión?

–ctstate

¿Qué cadena de iptable es responsable de paquetes de la red local que se llevan adelante?

FORWARD

¿Qué tabla desmenuza los paquetes conforme atraviesan el cortafuegos?

mangle

¿Cuál es la última regla que debería añadirse a la lista de control de acceso (ACL)?

Implicit deny