Cómo configurar el filtro de paquetes (PF) en FreeBSD 12.1

El autor seleccionó el Fondo de Ayuda COVID-19 para recibir una donación como parte del programa Write for DOnations.

Introducción

Se podría decir que el firewall es una de las líneas de defensa más importantes contra los ataques cibernéticos. La capacidad de configurar un firewall desde cero es una habilidad que permite al administrador tomar el control de sus redes.

Packet Filter (PF) es una conocida aplicación de firewall que es mantenida por el proyecto OpenBSD, orientado a la seguridad. Se expresa con más precisión como una herramienta de filtrado de paquetes, de ahí su nombre, y es conocida por su sintaxis simple, facilidad de uso y amplias funciones. PF es un firewall con estado por defecto, que almacena información sobre las conexiones en una tabla de estado a la que se puede acceder con fines analíticos. PF es parte del sistema base de FreeBSD y cuenta con el apoyo de una sólida comunidad de desarrolladores. Aunque existen diferencias entre las versiones de PF para FreeBSD y OpenBSD relacionadas con las arquitecturas del núcleo, en general su sintaxis es similar. Dependiendo de su complejidad, los conjuntos de reglas comunes se pueden modificar para que funcionen en cualquiera de las distribuciones con relativamente poco esfuerzo.

En este tutorial, creará un cortafuegos desde cero en un servidor FreeBSD 12.1 con PF. Diseñará un conjunto de reglas base que se puede utilizar como plantilla para proyectos futuros. También explorará algunas de las funciones avanzadas de PF, como la higiene de paquetes, la prevención de ataques por fuerza bruta, la supervisión y el registro, y otras herramientas de terceros.

Nota: a partir del 1 de julio de 2022, DigitalOcean ya no admite la creación de nuevos Droplets de FreeBSD a través del Panel de control o la API. Sin embargo, aún puede crear Droplets de FreeBSD utilizando una imagen personalizada. Aprenda a importar una imagen personalizada a DigitalOcean siguiendo nuestra documentación del producto.

Prerrequisitos

Antes de comenzar este tutorial, necesitarás lo siguiente:

• Un servidor FreeBSD 12.1 de 1 GB (ya sea ZFS o UFS). Puede utilizar nuestro tutorial Cómo empezar a usar FreeBSD para configurar su servidor según su configuración preferida.
• FreeBSD no tiene un firewall habilitado de manera predeterminada; la personalización es un sello distintivo de la filosofía de FreeBSD. Por lo tanto, cuando inicia su servidor por primera vez, necesita protección temporal mientras se configura PF. Consulte a su proveedor de nube para determinar la ruta más rápida hacia la protección inmediata antes de comenzar. Cualquiera sea el método que elija, su firewall temporal debe permitir solo el tráfico SSH entrante y puede permitir todo tipo de tráfico saliente.

Paso 1: creación de un conjunto de reglas preliminar

Comenzará este tutorial redactando un conjunto de reglas preliminares que proporcionen protección básica y acceso a servicios críticos desde Internet. En este punto, tendrá un servidor FreeBSD 12.1 en ejecución con un firewall en la nube activo.

Existen dos enfoques para crear un firewall: denegación predeterminada y permiso predeterminado. El enfoque de denegación predeterminada bloquea todo el tráfico y solo permite lo que se especifica en una regla. El enfoque de permiso predeterminado hace exactamente lo contrario: deja pasar todo el tráfico y solo bloquea lo que se especifica en una regla. Usarás el enfoque de denegación predeterminada.

Los conjuntos de reglas de PF se escriben en un archivo de configuración llamado /etc/pf.conf, que también es su ubicación predeterminada. Es correcto almacenar este archivo en otro lugar siempre que se especifique en el /etc/rc.confarchivo de configuración. En este tutorial, utilizará la ubicación predeterminada.

Inicie sesión en su servidor con su usuario no root:

ssh freebsd@your_server_ip

A continuación crea tu /etc/pf.confarchivo:

sudo vi /etc/pf.conf

Nota: Si desea ver el conjunto de reglas base completo en cualquier momento del tutorial, puede consultar los ejemplos en el Paso 4 o el Paso 8.

PF filtra los paquetes según tres acciones principales: block, pass, y match. Cuando se combinan con otras opciones, forman reglas. Se realiza una acción cuando un paquete cumple con los criterios especificados en una regla. Como es de esperar, las reglas passy blocktambién lo harán passcon blockel tráfico. Una matchregla realiza una acción en un paquete cuando encuentra un criterio coincidente, pero no lo pasa ni lo bloquea. Por ejemplo, puede realizar una traducción de direcciones de red (NAT) en un paquete coincidente sin pasarlo ni bloquearlo, y permanecerá allí hasta que le indique que haga algo en otra regla, como enrutarlo a otra máquina o puerta de enlace.

A continuación, agregue la primera regla a su /etc/pf.confarchivo:

/etc/pf.conf

block all

Esta regla bloquea todas las formas de tráfico en todas las direcciones. Como no especifica una dirección, se utilizan de forma predeterminada tanto incomo out. Esta regla es válida para una estación de trabajo local que necesita estar aislada del mundo, pero es poco práctica y no funcionará en un servidor remoto porque no permite el tráfico SSH. De hecho, si hubiera habilitado PF, se habría bloqueado a sí mismo y no podría acceder al servidor.

Revise su /etc/pf.confarchivo para permitir el tráfico SSH con la siguiente línea resaltada:

/etc/pf.conf

block allpass in proto tcp to port 22

Nota: Alternativamente, puede utilizar el nombre del protocolo:

/etc/pf.conf

block allpass in proto tcp to port ssh

Para mantener la coherencia, utilizaremos números de puerto, a menos que exista una razón válida para no hacerlo. En el /etc/servicesarchivo se incluye una lista detallada de protocolos y sus respectivos números de puerto, que le recomendamos consultar.

PF procesa las reglas secuencialmente de arriba hacia abajo, por lo tanto, su conjunto de reglas actual inicialmente bloquea todo el tráfico, pero luego lo pasa si coincide con los criterios de la siguiente línea, que en este caso es el tráfico SSH.

Ahora puedes acceder a tu servidor mediante SSH, pero sigues bloqueando todas las formas de tráfico saliente. Esto es problemático porque no puedes acceder a servicios críticos desde Internet para instalar paquetes, actualizar tu configuración horaria, etc.

Para solucionar esto, agregue la siguiente regla resaltada al final de su /etc/pf.confarchivo:

/etc/pf.conf

block allpass in proto tcp to port { 22 }pass out proto { tcp udp } to port { 22 53 80 123 443 }

Ahora, su conjunto de reglas permite el tráfico saliente SSH, DNS, HTTP, NTP y HTTPS, además de bloquear todo el tráfico entrante (con excepción de SSH). Coloque los números de puerto y los protocolos entre llaves, lo que forma una lista en sintaxis PF, lo que le permite agregar más números de puerto si es necesario. También agrega una regla de paso para el protocolo UDP en los puertos 53y 123porque DNS y NTP a menudo alternan entre los protocolos TCP y UDP. Ya casi ha terminado con el conjunto de reglas preliminar y solo necesita agregar un par de reglas para lograr la funcionalidad básica.

Completa el reglamento preliminar con las reglas resaltadas:

Conjunto de reglas preliminares /etc/pf.conf

set skip on lo0block allpass in proto tcp to port { 22 }pass out proto { tcp udp } to port { 22 53 80 123 443 }pass out inet proto icmp icmp-type { echoreq }

Guardar y salir del archivo.

Crea una set skipregla para el dispositivo de bucle invertido porque no necesita filtrar el tráfico y probablemente haría que el servidor funcionara a toda velocidad. Agrega una pass out inetregla para el protocolo ICMP, que le permite usar la utilidad ping(8) para la resolución de problemas. La inetopción representa la familia de direcciones IPv4.

ICMP es un protocolo de mensajería multipropósito que utilizan los dispositivos de red para distintos tipos de comunicación. La utilidad ping, por ejemplo, utiliza un tipo de mensaje conocido como solicitud de eco, que ha añadido a su icmp_typelista. Como precaución, solo permite los tipos de mensajes que necesita para evitar que dispositivos no deseados se pongan en contacto con su servidor. A medida que aumenten sus necesidades, puede añadir más tipos de mensajes a su lista.

Ahora tiene un conjunto de reglas que funciona y que proporciona funciones básicas a la mayoría de las máquinas. En la siguiente sección, confirmemos que todo funciona correctamente habilitando PF y probando su conjunto de reglas preliminar.

Paso 2: Prueba del conjunto de reglas preliminar

En este paso, probará su conjunto de reglas preliminar y realizará la transición desde su firewall en la nube a su firewall PF, lo que permitirá que PF tome el control por completo. Activará su conjunto de reglas con la pfctlutilidad, que es la herramienta de línea de comandos integrada de PF y el método principal de interacción con PF.

Los conjuntos de reglas de PF no son más que archivos de texto, lo que significa que no hay procedimientos delicados involucrados en la carga de nuevos conjuntos de reglas. Puede cargar un nuevo conjunto de reglas y el anterior desaparecerá. Rara vez, o nunca, es necesario vaciar un conjunto de reglas existente.

FreeBSD utiliza una red de scripts de shell conocidos como el rcsistema para gestionar cómo se inician los servicios en el momento del arranque; especificamos esos servicios en varios rcarchivos de configuración. Para servicios globales como PF, se utiliza el /etc/rc.confarchivo . Dado que rclos archivos son fundamentales para el buen funcionamiento de un sistema FreeBSD, no se deben editar directamente. En su lugar, FreeBSD proporciona una utilidad de línea de comandos conocida como sysrcdiseñada para ayudarle a editar estos archivos de forma segura.

Habilitemos PF usando la sysrcutilidad de línea de comandos:

sudo sysrc pf_enable="YES"
sudo sysrc pflog_enable="YES"

Verifique estos cambios imprimiendo el contenido de su /etc/rc.confarchivo:

sudo cat /etc/rc.conf

Verá el siguiente resultado:

Outputpf_enable="YES"pflog_enable="YES"

También habilita el pflogservicio, que a su vez habilita el pflogddemonio para iniciar sesión en PF. (Trabajarás con el inicio de sesión en un paso posterior).

Especifica dos servicios globales en tu /etc/rc.confarchivo, pero no se inicializarán hasta que reinicies el servidor o los inicies manualmente. Reinicia el servidor para que también puedas probar tu acceso SSH.

Inicie PF reiniciando el servidor:

sudo reboot

La conexión se interrumpirá. Espere unos minutos para que se actualice.

Ahora vuelva a conectarse al servidor mediante SSH:

ssh freebsd@your_server_ip

Aunque ha inicializado sus servicios PF, en realidad no ha cargado su /etc/pf.confconjunto de reglas, lo que significa que su firewall aún no está activo.

Cargue el conjunto de reglas con pfctl:

sudo pfctl -f /etc/pf.conf

Si no hay errores ni mensajes, significa que su conjunto de reglas no tiene errores y el firewall está activo.

Ahora que PF está en ejecución, puede desconectar su servidor de su firewall en la nube. Consulte con su proveedor de nube para asegurarse de que lo que esté usando para protección temporal esté deshabilitado. Es casi seguro que ejecutar dos firewalls diferentes en un servidor causará problemas.

Por si acaso, reinicie su servidor nuevamente:

sudo reboot

Después de unos minutos, vuelva a conectarse mediante SSH a su servidor:

ssh freebsd@your_server_ip

PF es ahora su firewall en funciones. Puede asegurarse de que esté funcionando accediendo a algunos datos con la utilidad pfctl.

Veamos algunas estadísticas y contadores con pfctl -si:

sudo pfctl -si

Pasa los -siindicadores, que representan la información que se muestra. Esta es una de las muchas combinaciones de parámetros de filtro que puedes usar con pfctl para analizar datos sobre la actividad de tu firewall.

Verá los siguientes datos tabulares (los valores variarán de una máquina a otra):

OutputStatus: Enabled for 0 days 00:01:53           Debug: UrgentState Table                          Total             Rate  current entries                        5  searches                             144            1.3/s  inserts                               11            0.1/s  removals                               6            0.1/sCounters  match                                 23            0.2/s  bad-offset                             0            0.0/s  fragment                               0            0.0/s  short                                  0            0.0/s  normalize                              0            0.0/s  memory                                 0            0.0/s  bad-timestamp                          0            0.0/s  congestion                             0            0.0/s  ip-option                              0            0.0/s  proto-cksum                            0            0.0/s  state-insert                           0            0.0/s  state-limit                            0            0.0/s  src-limit                              0            0.0/s  synproxy                               0            0.0/s  map-failed                             0            0.0/s

Dado que acaba de activar su conjunto de reglas, aún no verá mucha información. Sin embargo, este resultado muestra que PF ya registró 23 reglas coincidentes, lo que significa que los criterios de su conjunto de reglas se cumplieron 23 veces. El resultado también confirma que su firewall está funcionando.

Su conjunto de reglas también permite que el tráfico saliente acceda a algunos servicios críticos de Internet, incluida la utilidad ping.

Verifiquemos la conectividad a Internet y el servicio DNS con ping contra google.com:

ping -c 3 google.com

Dado que ejecutaste el indicador count -c 3, verás tres respuestas de conexión exitosas:

OutputPING google.com (172.217.0.46): 56 data bytes64 bytes from 172.217.0.46: icmp_seq=0 ttl=56 time=2.088 ms64 bytes from 172.217.0.46: icmp_seq=1 ttl=56 time=1.469 ms64 bytes from 172.217.0.46: icmp_seq=2 ttl=56 time=1.466 ms--- google.com ping statistics ---3 packets transmitted, 3 packets received, 0.0% packet lossround-trip min/avg/max/stddev = 1.466/1.674/2.088/0.293 ms

Asegúrese de poder acceder al repositorio pkgs con el siguiente comando:

sudo pkg upgrade

Si hay algún paquete para actualizar, siga adelante y actualícelo.

Si ambos servicios funcionan, significa que el firewall está funcionando y que ya puede continuar. Aunque el conjunto de reglas preliminar proporciona protección y funcionalidad, sigue siendo un conjunto de reglas elemental y podría mejorarse con algunas mejoras. En las secciones restantes, completará el conjunto de reglas básico y utilizará algunas de las funciones avanzadas de PF.

Paso 3: Completar el conjunto de reglas básicas

En este paso, trabajarás a partir del conjunto de reglas preliminar para completar el conjunto de reglas básico. Reorganizarás algunas de tus reglas y trabajarás con conceptos más avanzados.

Incorporación de macros y tablas

En el conjunto de reglas preliminar, incorporó todos los parámetros en cada regla, es decir, los números de puerto que conforman las listas. Esto puede volverse inmanejable en el futuro, según la naturaleza de sus redes. Para fines organizativos, PF incluye macros, listas y tablas. Ya incluyó listas directamente en sus reglas, pero también puede separarlas de ellas y asignarlas a una variable mediante macros.

Abra su archivo para transferir algunos de sus parámetros a macros:

sudo vi /etc/pf.conf

Ahora agregue el siguiente contenido en la parte superior del conjunto de reglas:

/etc/pf.conf

vtnet0 = "vtnet0"icmp_types = "{ echoreq }". . .

Modifique sus reglas SSH e ICMP anteriores con sus nuevas variables:

/etc/pf.conf

. . .pass in on $vtnet0 proto tcp to port { 22 }. . .pass inet proto icmp icmp-type $icmp_types. . .

Las reglas anteriores de SSH e ICMP ahora utilizan macros. Los nombres de las variables se indican mediante la sintaxis del signo de dólar de PF. Asigna tu vtnet0interfaz a una variable con el mismo nombre solo como una formalidad, lo que te da la opción de cambiarle el nombre en el futuro si es necesario. Otros nombres de variables comunes para interfaces públicas incluyen $pub_ifo $ext_if.

A continuación, implementará una tabla, que es similar a una macro, pero diseñada para contener grupos de direcciones IP. Vamos a crear una tabla para direcciones IP no enrutables, que a menudo desempeñan un papel en los ataques de denegación de servicio (DOS). Puede utilizar las direcciones IP especificadas en RFC6890, que define registros de direcciones IP de propósito especial. Su servidor no debe enviar ni recibir paquetes hacia o desde estas direcciones a través de la interfaz pública.

Cree esta tabla agregando el siguiente contenido directamente debajo de la icmp_typesmacro:

/etc/pf.conf

. . .table rfc6890 { 0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16                            172.16.0.0/12 192.0.0.0/24 192.0.0.0/29 192.0.2.0/24 192.88.99.0/24                      192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24                              240.0.0.0/4 255.255.255.255/32 }. . .

Ahora agregue sus reglas para la rfc6890tabla debajo de la set skip on lo0regla:

/etc/pf.conf

. . .set skip on lo0block in quick on egress from rfc6890block return out quick on egress to rfc6890. . .

Aquí se introduce la returnopción que complementa la block outregla. Esto descartará los paquetes y también enviará un mensaje RST al host que intentó realizar esas conexiones, lo que resulta útil para analizar la actividad del host. Luego, se agrega la egresspalabra clave, que encuentra automáticamente las rutas predeterminadas en cualquier interfaz dada. Este suele ser un método más claro para encontrar rutas predeterminadas, especialmente con redes complejas. La quickpalabra clave ejecuta las reglas inmediatamente sin tener en cuenta el resto del conjunto de reglas. Por ejemplo, si un paquete con una dirección IP ilógica intenta conectarse al servidor, se desea descartar la conexión inmediatamente y no hay motivo para ejecutar ese paquete a través del resto del conjunto de reglas.

Cómo proteger sus puertos SSH

Dado que su puerto SSH está abierto al público, está sujeto a explotación. Una de las señales de advertencia más obvias de un atacante es una gran cantidad de intentos de inicio de sesión. Por ejemplo, si la misma dirección IP intenta iniciar sesión en su servidor diez veces en un segundo, puede asumir que no fue una acción humana, sino un software informático que intentaba descifrar su contraseña de inicio de sesión. Este tipo de ataques sistemáticos suelen denominarse ataques de fuerza bruta y suelen tener éxito si el servidor tiene contraseñas débiles.

Advertencia: recomendamos encarecidamente utilizar la autenticación con clave pública en todos los servidores. Consulte el tutorial de DigitalOcean sobre autenticación basada en clave.

PF tiene funciones integradas para manejar ataques de fuerza bruta y otros ataques similares. Con PF puedes limitar la cantidad de intentos de conexión simultáneos permitidos por un solo host. Si un host excede esos límites, se interrumpirá la conexión y se le prohibirá el acceso al servidor. Para lograr esto, utilizarás el mecanismo de sobrecarga de PF, que mantiene una tabla de direcciones IP prohibidas.

Modifique su regla SSH anterior para limitar la cantidad de conexiones simultáneas desde un solo host según lo siguiente:

/etc/pf.conf

. . .pass in on $vtnet0 proto tcp to port { 22 }     keep state (max-src-conn 15, max-src-conn-rate 3/1,         overload bruteforce flush global). . .

Agrega la keep stateopción que te permite definir los criterios de estado para la tabla de sobrecarga. Pasas el max-src-connparámetro para especificar la cantidad de conexiones simultáneas permitidas desde un solo host por segundo y el max-src-conn-rateparámetro para especificar la cantidad de conexiones nuevas permitidas desde un solo host por segundo. Especificas 15conexiones para max-src-conny 3conexiones para max-src-conn-rate. Si un host excede estos límites, el overloadmecanismo agrega la IP de origen a la bruteforcetabla, lo que lo prohíbe en el servidor. Finalmente, la flush globalopción descarta inmediatamente la conexión.

Ha definido una tabla de sobrecarga en su regla SSH, pero no ha declarado esa tabla en su conjunto de reglas.

Añade la bruteforcetabla debajo de la icmp_typesmacro:

/etc/pf.conf

. . .icmp_types = "{ echoreq }"table bruteforce persist. . .

La persistpalabra clave permite que exista una tabla vacía en el conjunto de reglas. Sin ella, PF se quejará de que no hay direcciones IP en la tabla.

Estas medidas garantizan que su puerto SSH esté protegido por un poderoso mecanismo de seguridad. PF le permite configurar soluciones rápidas para protegerse de formas desastrosas de explotación. En las siguientes secciones, tomará medidas para limpiar los paquetes a medida que llegan a su servidor.

Desinfectando su tráfico

Nota: Las siguientes secciones describen los conceptos básicos del conjunto de protocolos TCP/IP. Si planea crear aplicaciones o redes web, le conviene dominar estos conceptos. Eche un vistazo al tutorial Introducción a la terminología, las interfaces y los protocolos de redes de DigitalOcean.

Debido a la complejidad del conjunto de protocolos TCP/IP y a la perseverancia de actores maliciosos, los paquetes suelen llegar con discrepancias y ambigüedades, como fragmentos de IP superpuestos, direcciones IP falsas y más. Es imperativo que desinfecte el tráfico antes de que ingrese al sistema. El término técnico para este proceso es normalización.

Cuando los datos viajan a través de Internet, normalmente se dividen en fragmentos más pequeños en su origen para adaptarse a los parámetros de transmisión del host de destino, donde se vuelven a ensamblar en paquetes completos. Desafortunadamente, un intruso puede secuestrar este proceso de varias maneras que van más allá del alcance de este tutorial. Sin embargo, con PF puede administrar la fragmentación con una regla. PF incluye una scrubpalabra clave que normaliza los paquetes.

Añade la scrubpalabra clave que precede directamente a tu block allregla:

/etc/pf.conf

. . .set skip on lo0scrub in all fragment reassemble max-mss 1440block all. . .

Esta regla aplica la depuración a todo el tráfico entrante. Incluye la fragment reassembleopción que evita que los fragmentos entren al sistema. En su lugar, se almacenan en caché en la memoria hasta que se vuelven a ensamblar en paquetes completos, lo que significa que las reglas de filtrado solo tendrán que lidiar con paquetes uniformes. También incluye la max-mss 1440opción que representa el tamaño máximo de segmento de los paquetes TCP reensamblados, también conocido como carga útil. Especifica un valor de 1440 bytes, que logra un equilibrio entre tamaño y rendimiento, dejando mucho espacio para los encabezados.

Otro aspecto importante de la fragmentación es un término conocido como unidad máxima de transmisión (MTU). Los protocolos TCP/IP permiten que los dispositivos negocien tamaños de paquetes para realizar conexiones. El host de destino utiliza mensajes ICMP para informar a la IP de origen de su MTU, un proceso conocido como descubrimiento de ruta de MTU. El tipo de mensaje ICMP específico es el destino inalcanzable. Habilitará el descubrimiento de ruta de MTU agregando el unreachtipo de mensaje a su icmp_typeslista.

Utilizará la MTU predeterminada de su servidor de 1500 bytes, que se puede determinar con el ifconfigcomando:

ifconfig

Verá el siguiente resultado que incluye su MTU actual:

Outputvtnet0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=6c07bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6. . .

Actualice la icmp_typeslista para incluir el tipo de mensaje de destino inalcanzable:

/etc/pf.conf

vtnet0 = "vtnet0"icmp_types = "{ echoreq unreach}". . .

Ahora que tiene políticas implementadas para manejar la fragmentación, los paquetes que ingresan a su sistema serán uniformes y consistentes. Esto es deseable porque hay muchos dispositivos que intercambian datos a través de Internet.

Ahora trabajará para evitar otro problema de seguridad conocido como suplantación de IP. Los atacantes suelen cambiar sus IP de origen para que parezca que residen en un nodo de confianza dentro de una organización. PF incluye una directiva antispoofing para gestionar las IP de origen suplantadas. Cuando se aplica a una o más interfaces específicas, la antispoofing bloquea todo el tráfico de la red de esa interfaz (a menos que se origine en esa interfaz). Por ejemplo, si aplica la antispoofing a una o más interfaces que residen en 5.5.5.1/24, todo el tráfico de la 5.5.5.0/24red no puede comunicarse con el sistema a menos que se origine en esa o esas interfaces.

Agregue el siguiente contenido resaltado para aplicar antispoofing a su vtnet0interfaz:

/etc/pf.conf

. . .set skip on lo0scrub inantispoof quick for $vtnet0block all. . .

Guardar y salir del archivo.

Esta regla antispoofing dice que todo el tráfico de vtnet0las redes de solo puede pasar a través de la vtnet0interfaz, o se descartará inmediatamente con la quickpalabra clave. Los actores maliciosos no podrán ocultarse en vtnet0la red de y comunicarse con otros nodos.

Para demostrar su regla antispoofing, deberá imprimir su conjunto de reglas en la pantalla en su forma detallada. Las reglas en PF suelen escribirse en forma abreviada, pero también pueden escribirse en forma detallada. Generalmente no es práctico escribir reglas de esta manera, pero para fines de prueba puede ser útil.

Imprima el contenido del /etc/pf.confuso pfctlcon el siguiente comando:

sudo pfctl -nvf /etc/pf.conf

Este pfctlcomando toma las -nvfbanderas, que imprimen el conjunto de reglas y lo prueban sin cargar nada, también conocido como ejecución en seco. Ahora verás todo el contenido en /etc/pf.confsu forma detallada.

Verá algo similar al siguiente resultado dentro de la parte antispoofing:

Output. . .block drop in quick on ! vtnet0 inet from your_server_ip/20 to anyblock drop in quick on ! vtnet0 inet from network_address/16 to anyblock drop in quick inet from your_server_ip to anyblock drop in quick inet from network_address to anyblock drop in quick on vtnet0 inet6 from your_IPv6_address to any. . .

La regla antispoofing descubrió que es parte de la your_server_ip/20red. También detectó que (para el ejemplo de este tutorial) el servidor es parte de una network_address/16red y tiene una dirección IPv6 adicional. La regla antispoofing impide que todas estas redes se comuniquen con el sistema, a menos que su tráfico pase por la vtnet0interfaz.

La regla antispoofing es la última incorporación a su conjunto de reglas base. En el siguiente paso, iniciará estos cambios y realizará algunas pruebas.

Paso 4: Prueba del conjunto de reglas base

En este paso, revisará y probará su conjunto de reglas base para asegurarse de que todo funcione correctamente. Es mejor evitar implementar demasiadas reglas a la vez sin probarlas. La mejor práctica es comenzar con lo esencial, expandirlo de manera incremental y hacer copias de seguridad mientras realiza cambios de configuración.

Aquí está el conjunto completo de reglas básicas:

Conjunto de reglas base /etc/pf.conf

vtnet0 = "vtnet0"icmp_types = "{ echoreq unreach }"table bruteforce persisttable rfc6890 { 0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16                            172.16.0.0/12 192.0.0.0/24 192.0.0.0/29 192.0.2.0/24 192.88.99.0/24                      192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24                              240.0.0.0/4 255.255.255.255/32 }set skip on lo0scrub in all fragment reassemble max-mss 1440antispoof quick for $vtnet0block in quick on $vtnet0 from rfc6890block return out quick on egress to rfc6890block allpass in on $vtnet0 proto tcp to port { 22 }     keep state (max-src-conn 15, max-src-conn-rate 3/1,         overload bruteforce flush global)pass out proto { tcp udp } to port { 22 53 80 123 443 }pass inet proto icmp icmp-type $icmp_types

Asegúrese de que su /etc/pf.confarchivo sea idéntico al conjunto de reglas base completo antes de continuar. Luego guarde y salga del archivo.

Su conjunto de reglas básicas completo le proporciona:

• Una colección de macros que pueden definir servicios y dispositivos clave.
• Políticas de higiene de red para abordar la fragmentación de paquetes y las direcciones IP ilógicas.
• Una estructura de filtrado de denegación predeterminada que bloquea todo y permite solo lo que usted especifica.
• Acceso SSH entrante con límites en la cantidad de conexiones simultáneas que puede realizar un host.
• Políticas de tráfico saliente que le brindan acceso a algunos servicios críticos de Internet.
• Políticas ICMP que proporcionan acceso a la utilidad ping y al descubrimiento de ruta MTU.

Ejecute el siguiente pfctlcomando para realizar una ejecución en seco:

					

												


							
															

									SUSCRÍBETE A NUESTRO BOLETÍN 								
							
															

									No te pierdas de nuestro contenido ni de ninguna de nuestras guías para que puedas avanzar en los juegos que más te gustan.								
							
						
						
						
					
				
			

		

			Correo Electronico
			

		
			

		
			

		
							

					Al suscribirte, aceptas nuestra política de privacidad y nuestros términos de servicio.				
						

			
			


Tal vez te puede interesar:

Cómo agregar efectos de sonido a tus aplicaciones React
Cómo utilizar el modo independiente de Certbot para recuperar certificados SSL de Let's Encrypt en Debian 10
Cómo instalar el servidor web Apache en Debian 10
Obtención de datos de ubicación con Ionic 4 y Capacitor