MÉTODOS DE AUTENTICACIÓN Y FIREWALL

TIPOS DE FIREWALL

El firewall, en castellano muro de fuego, es un sistema que es utilizado para proteger una computadora en particular o bien una red. Normalmente su objetivo es evitar el ingreso de agentes externos, no autorizados o información.

Existen distintos tipos de firewalls, que pueden ser clasificados de diversas maneras en:

FILTRADO DE PAQUETES, FILTRADO DE PROXYS Y FILTROS DE PAQUETES CON ESTADOS

La acción de filtrar paquetes es bloquear o permitir el paso a los paquetes de datos de forma selectiva, según van llegando a una interfaz de red. Los criterios que usa pf(4) para inspeccionar los paquetes los toma de la información existente en la capa 'Layer 3' (IPv4 and IPv6) y en la capa 'Layer 4' (TCP, UDP, ICMP y ICMPv6) de las cabeceras de los paquetes. Los criterios que más se utilizan son los de la dirección de origen y de destino, el puerto de origen y de destino, y el protocolo.

Las reglas de filtrado especifican los criterios con los que debe concordar un paquete y la acción a seguir, bien sea bloquearlo o permitir que pase, que se toma cuando se encuentra una concordancia. Las reglas de filtrado se evalúan por orden de secuencia, de la primera a la última. A menos que el paquete concuerde con una regla que contenga la clave quick, se evaluará el paquete comparándolo con todas las reglas de filtrado antes de decidir una acción final. La última regla que concuerde será la «ganadora» y la que dictamine qué acción se tomará con el paquete. Al principio del grupo de reglas de filtrado hay un pass all implícito que indica que si algún paquete no concuerda con ninguna de las reglas de filtrado, la acción a seguir será pass, o sea permitirle el paso.

Sintaxis de las reglas

La sintaxis general, muy simplificada, para las reglas de filtrado es:

action [direction] [log] [quick] [on interface] [af] [proto protocol] \[from src_addr [port src_port]] [to dst_addr [port dst_port]] \[flags tcp_flags] [state]

action La acción a seguir para los paquetes que concuerden, ya sea pass o block. La acción pass permitirá el paso al paquete de vuelta hasta el núcleo del sistema, para que éste lo procese, mientras que la acción block actuará

según se indique en la configuración de la opción de la política de bloqueo, block-policy. La acción por omisión se puede anular especificando block drop (bloquear y eliminar el paquete) o block return (bloquear y devolver el paquete).

direction La dirección en la que se mueve el paquete en una interfaz, que será in (entrante) o out (saliente).

log Indica que se debe registrar el paquete por medio de pflogd(8). Si la regla crea un estado, entonces sólo se registrará el paquete que establezca el estado. Para registrar todos los paquetes hay que usar la opción log (all).

quick Si un paquete concuerda con una regla que especifique la opción quick, entonces esa regla se considera como la regla final de concordancia para el paquete, y se tomará la acción que esté especificada en action sin más dilación.

interface El nombre o el grupo de la interfaz de red a través del cual se mueve el paquete. Los interfaces pueden añadirse a grupos arbitrarios por medio de la orden ifconfig(8) Varios grupos también son creados automáticamente por el kernel:

El grupo egress, que contiene la(s) interfaces(s) relativa(s) a la ruta por omisión.

El grupo de la familia de interfaces clonadas: Por ejemplo: ppp o carp.

Esto causaría la concordancia de la regla para todo paquete que atraviesa cualquier interfaz ppp o carp, respectivamente.

af La familia de direcciones del paquete, que será inet para IPv4 ó inet6 para IPv6. Generalmente, PF es capaz de determinar este parámetro basándose en la dirección, o direcciones, de origen y/o de destino.

protocol El protocolo de la capa 'Layer 4' del paquete:

tcp udp icmp icmp6 Un nombre de protocolo válido del fichero /etc/protocols Un número de protocolo entre 0 y 255 Un grupo de protocolos que usen una lista.

src_addr, dst_addr La dirección de origen y/o de destino en la cabecera IP. Las direcciones se pueden especificar como:

Una sola dirección IPv4 o IPv6. Un bloque de red CIDR. Un «Nombre de Dominio Totalmente Cualificado» (FQDN) que se

resolverá por el «Servicio de Nombres de Dominio» cuando se carguen las reglas. Todas las direcciones IP resultantes se sustituirán dentro de la regla.

El nombre de una interfaz de red o grupo. Cualquier dirección IP asignada a la interfaz se sustituirá dentro de la regla.

El nombre de una interfaz de red seguido de la máscara de red como sigue: /netmask (o sea, /24). Cada dirección IP en la interfaz se combina con la máscara de red para formar un bloque de red CIDR, que se sustituye dentro de la regla.

El nombre de una interfaz de red o grupo entre paréntesis ( ). De este modo se instruye a PF para que actualice la reglas si la dirección, o direcciones, IP en dicha interfaz cambia. Es de gran utilidad cuando la interfaz obtiene su dirección IP por medio de DHCP o de una conexión tipo dial-up (por conexión telefónica), ya que no hay que volver a cargar las reglas cada vez que cambie la dirección.

El nombre de la interfaz de red seguido por cualquiera de los siguientes modificadores:

o :network - expande al bloque de red CIDR (por ejemplo: 192.168.0.0/24)

o :broadcast - expande a la dirección de difusión (broadcast) de la red. (por ejemplo: 192.168.0.255)

o :peer - expande a la dirección IP del otro extremo en un enlace punto a punto.

Además, el modificador :0 puede ser añadido tanto a un nombre de interfaz o a cualquiera de los modificadores mencionados arriba para indicar que PF no debe incluir la dirección IP de alias en la expansión. Estos modificadores también puede ser usados cuando la interfaz está entre paréntesis. Ejemplo: fxp0:network:0

Una tabla. La palabra-clave urpf-failed puede usarse en las direcciones origen

para indicar que debe continuar a través de una comprobación uRPF.

Cualquiera de las anteriores en negación, usando el modificador ! ("not").

Un grupo de direcciones que usen una lista. La clave any para indicar todas las direcciones. La clave all, que es una abreviación de from any to any.

src_port, dst_port

El puerto de origen y/o de destino en la capa 'Layer 4' de la cabecera IP. Los puertos se pueden especificar como:

Un número entre el 1 y el 65535 Un nombre de servicio válido del fichero /etc/services Un grupo de puertos que usen una lista Un intervalo:

o != (distinto de) o < (menor que) o > (mayor que) o <= (menor o igual que) o >= (mayor o igual que) o >< (intervalo) o <> (intervalo inverso)

Los dos últimos son operadores binarios (toman dos argumentos) y no incluyen los argumentos en el intervalo.

o : (intervalo inclusivo)

El operador de intervalo inclusivo también es un operador binario e incluye el argumento en el intervalo.

tcp_flags Especifica los indicadores que deben existir en la cabecera TCP cuando se usa proto tcp. Los indicadores se especifican como flags check/mask. Por ejemplo, flags S/SA instruye a PF para que sólo mire los indicadores S y A (SYN y ACK), y que acepte la concordancia si el indicador SYN está activo (y esto se aplica a todas las reglas TCP predeterminadas). flags any instruye a PF para que no verifique los indicadores (flags).

state Especifica si se guarda la información sobre el estado en paquetes que concuerden con esta regla.

no state - funciona con TCP, UDP e ICMP. PF no trazará esta conexión con estado. Para conexiones TCP, flags any suele ser necesario.

keep state - funciona con TCP, UDP e ICMP. Esta es la opción predeterminada en todas las reglas de filtrado.

modulate state - sólo funciona con TCP. PF generará «Números de Secuencia Inicial» (ISNs, Initial Sequence Numbers) seguros para los paquetes que concuerden con esta regla.

synproxy state - hace de proxy para las conexiones TCP entrantes con el fin de ayudar a proteger a los servidores de desbordamientos TCP SYN falsificados. Esta opción incluye las funcionalidades keep state y modulate state.

Denegación predeterminada

La práctica recomendada para configurar un cortafuegos es la de tomar una aproximación de «denegación predeterminada»; o sea, denegar el paso a todo y a partir de ahí ir permitiendo el paso a través del cortafuegos de forma selectiva a cierto tráfico. Esta aproximación es la recomendada ya que los posibles fallos se cometerían a favor de la seguridad, y también porque hace más fácil la creación de grupos de reglas.

Para crear una política de filtrado de denegación predeterminada, las primeras dos reglas deben ser:

block in allblock out all

Con esto se bloquea todo el tráfico en todas las interfaces en cualquier dirección, y desde cualquier origen, hasta cualquier destino.

Paso de tráfico

Ahora hay que permitir de forma explícita y selectiva el paso del tráfico a través del cortafuegos, o de lo contrario será bloqueado por la política de denegación predeterminada. Aquí es donde entran en juego los criterios del paquete, como son el puerto de origen/destino, la dirección de origen/destino, y el protocolo. Siempre que se permita el paso de cierto tráfico a través del cortafuegos hay que escribir las reglas de un modo tan restrictivo como sea posible. Esto es para asegurarse de que sólo pasará el tráfico que se permita, y ningún otro.

Algunos ejemplos:

# Permitir el paso al tráfico entrante en la interfaz dc0 de la red local,# 192.168.0.0/24, hacia la dirección IP 192.168.0.1 de la máquina de OpenBSD.# También permitir el paso al tráfico saliente que es enviado de vuelta en dc0.pass in on dc0 from 192.168.0.0/24 to 192.168.0.1pass out on dc0 from 192.168.0.1 to 192.168.0.0/24

# Permitir el paso al tráfico entrante TCP en la interfaz fxp0 del servidor# de web que se encuentra en la máquina de OpenBSD. El nombre de la# interfaz, fxp0, se usa como la dirección de destino para que los paquetes# sólo concuerden con esta regla si tienen como destino la máquina de OpenBSD.pass in on fxp0 proto tcp from any to fxp0 port www

La palabra-clave quick

Como se ha indicado anteriormente, cada paquete se evalúa con el grupo de reglas de filtrado, desde la primera hasta la última. El resultado predeterminado es el de marcar el paquete para que se le permita el paso; esto puede cambiar con cualquiera de las reglas por las que pasa, y podría cambiar varias veces antes de llegar al final de las reglas de filtrado. La última regla con la que concuerde marcará el resultado. Existe una excepción para esto: la opción quick en una regla de filtrado tiene el efecto de cancelar el procesamiento de cualquier regla consiguiente, y provoca que se ejecute la acción especificada sin más dilación. Veamos un par de ejemplos:

Mal:

block in on fxp0 proto tcp to port sshpass in all

En este caso, la línea block puede ser evaluada, pero nunca tendrá ningún efecto, ya que va seguida por una línea que permite el paso de todo.

Mejor:

block in quick on fxp0 proto tcp to port sshpass in all

Estas reglas se evalúan de una forma algo diferente. Si un paquete concuerda con la línea block, debido a la naturaleza de la opción quick, se bloqueará el paso a dicho paquete y se ignorará el resto del grupo de reglas.

Mantenimiento del estado

Una de las funcionalidades importantes de PF es la del «mantenimiento del estado» (keeping state) o «inspección completa del estado» (stateful inspection). La inspección del estado se refiere a la capacidad de PF de llevar un seguimiento del estado, o del progreso, de una conexión de red. Almacenando información sobre cada conexión en una tabla de estado, PF puede determinar rápidamente si un paquete que está pasando a través del cortafuegos pertenece a una conexión ya establecida. Si es así, se le permite pasar a través del cortafuegos sin tener que pasar a través de la evaluación del grupo de reglas.

El mantenimiento del estado tiene muchas ventajas, entre otras que los grupos de reglas son más simples y se obtiene un rendimiento más alto del filtrado de paquetes. PF puede puede hacer que los paquetes que vayan en cualquier dirección concuerden con entradas en la tabla de estado, lo que quiere decir que no es necesario escribir reglas de filtrado que permitan el paso del tráfico de vuelta. Y, como los paquetes que concuerdan con conexiones stateful no pasan a través de la evaluación del grupo de reglas, el tiempo que tarda PF en procesarlos puede reducirse considerablemente.

Cuando una regla crea el estado, el primer paquete que concuerda con ella crea un estado entre el remitente y el destinatario. A partir de ahí, los paquetes que vayan desde el remitente hacia el destinatario no serán los únicos que concuerden con la entrada de estado y que circunvalen la evaluación de las reglas, sino que también lo harán los paquetes de respuesta desde el destinatario hacia el remitente.

Todas las reglas pass crean automáticamente una entrada en la tabla de estado cuando un paquete concuerda con la regla. Esto puede deshabilitarse de manera explícita mediante la opción no state

pass out on fxp0 proto tcp from any to any

Esto permite el paso de cualquier tráfico TCP saliente en la interfaz fxp0, y también permite que el tráfico de respuesta pase de vuelta a través del cortafuegos. El mantenimiento del estado mejora de forma significativa el rendimiento del cortafuegos, ya que las búsquedas de estados son mucho más rápidas que la evaluación de un paquete a través de todas las reglas de filtrado.

La opción de «modulación del estado» (modulate state), funciona como keep state, con la diferencia que solo es válida para paquetes TCP. Con modulate state, el ISN de las conexiones salientes es aleatorio. Esta opción es útil para proteger conexiones que hayan sido iniciadas por ciertos sistemas operativos que realizan un pobre trabajo al escoger ISNs. Para simplificar las reglas, la opción modulate state puede usarse en reglas que especifican protocolos diferentes de TCP; en estos casos es tratada como keep state.

Mantenimiento del estado en paquetes TCP, UDP e ICMP salientes y ISN TCP modulados:

pass out on fxp0 proto { tcp, udp, icmp } from any \to any modulate state

Otra ventaja del mantenimiento del estado es que el tráfico ICMP correspondiente también pasará por el cortafuegos. Por ejemplo, si una conexión TCP pasa a través del cortafuegos, como se mantiene el estado, y llega una señal de congestión (source quench) ICMP, se buscará su concordancia con la entrada apropiada de la tabla de estado y pasará a través del cortafuegos.

El ámbito de una entrada en la tabla de estados es controlado globalmente por la opción en tiempo de ejecución state-policy y al nivel de cada regla por las palabras-clave de opciones de estado if-bound y floating. Estas palabras-clave usadas en las reglas tienen el mismo efecto que cuando se usan con la opción state-policy. Ejemplo:

pass out on fxp0 proto { tcp, udp, icmp } from any \to any modulate state (if-bound)

Esta regla dictaminaría que para que los paquetes concuerden con la entrada de estado deben transitar por la interfaz fxp0.

Mantenimiento del estado para UDP

Algunos dicen que «no se puede crear estado con UDP, ya que UDP es un protocolo sin estado». Aunque es cierto que una sesión de comunicación de UDP no tiene ningún concepto de estado (un comienzo y un final de las comunicaciones explícito), esto no tiene ningún impacto en la capacidad de PF para crear estado para una sesión de UDP. En el caso de protocolos sin paquetes de «inicio» ni «final», PF se limita a mantener un seguimiento del tiempo transcurrido desde que ha pasado un paquete que concuerde. Los valores del tiempo agotado (timeout) se pueden configurar en la sección de opciones del fichero pf.conf.

Opciones de seguimiento de estado

Las reglas de filtrado que crean una entrada en la tabla de estados pueden especificar varias opciones para controlar el comportamiento de la entrada de estado resultante. Están disponibles las siguientes opciones: max número

Limita el número máximo de entradas de estado que la regla puede crear para número. Si se alcanza el máximo, los paquetes que normalmente crearían un estado son rechazados hasta que el número de estados existentes decrece por debajo del límite.

no state Impide que la regla cree automáticamente una entrada en la tabla de estados.

source-track Esta opción habilita el seguimiento del número de estados creados por dirección IP de origen. Esta opción tiene dos formatos:

source-track rule - El número máximo de estados creados por esta regla está limitado por las opciones max-src-nodes y max-src-states de la regla. Solamente las entradas de estado creadas por esta regla en particular cuenta para los límites de la regla.

source-track global - El número de estados creados por todas las reglas que usan esta opción se limita. Cada regla puede especificar diferentes opciones max-src-nodes y max-src-states, sin embargo las entradas de estado creadas por cualquier regla participante cuenta para los límites individuales de la regla.

El número total de direcciones IP de origen rastreados globalmente puede controlarse por medio de la opción en tiempo de ejecución src-nodes .

max-src-nodes número

Cuando se usa la opción source-track, max-src-nodes limitará el número de direcciones IP de origen que pueden crear estado de forma simultánea. Esta opción solo puede usarse con source-track rule.

max-src-states número Cuando se usa la opción source-track, max-src-states limitará el número de entradas de estado simultáneas que pueden crearse por dirección IP de origen. El alcance de este límite (o sea, estados creados solamente por esta regla o estados creados por todas las reglas que usan source-track) es dependiente de la opción source-track especificada.

Las opciones se especifican entre paréntesis e inmediatamente después de una de las palabras-clave de estado (keep state, modulate state, or synproxy state). Si hay múltiples opciones, deben ir separadas por comas. En OpenBSD 4.1 y versiones más recientes, la opción keep state se utiliza de forma predeterminada implícitamente para todas las reglas de filtrado. A pesar de ello, cuando se especifican opciones de mantener estado, debe especificarse todavía una de las palabras-clave por delante de las opciones.

Una regla de ejemplo:

pass in on $ext_if proto tcp to $web_server \port www keep state \(max 200, source-track rule, max-src-nodes 100, max-src-states 3)

La regla anterior define el siguiente comportamiento:

Limita a 200 el número máximo de estados que esta regla puede crear Habilita el seguimiento del origen; limita la creación de estados basados en

estados creados solo por esta regla Limita a 100 el número máximo de nodos que pueden crear estados

simultáneamente Limita a 3 el número máximo de estados simultáneos por IP de origen.

Puede ponerse un conjunto separado de restricciones en conexiones TCP con estado que han completado la negociación en tres pasos (3-way handshake).

max-src-conn número Limita el número máximo de conexiones TCP simultáneas que hayan completado la negociación en tres pasos y que una única máquina puede realizar.

max-src-conn-rate número / intervalo Limita la tasa de nuevas conexiones a una cierta cantidad por intervalo de tiempo

Ambas opciones invocan automáticamente la opción source-track rule y son incompatibles con source-track global

Dado que estos límites solo son colocados en conexiones TCP que han completado la negociación en tres pasos, se pueden adoptar acciones más agresivas en direcciones IP ofensivas.

overload <tabla> Coloca una dirección IP de una máquina ofensiva en la tabla nombrada.

flush [global] Cesa cualquier otro estado que concuerde con esta regla y que fuese creado por esta IP de origen. Cuando global es especificado, cesa todos los estados coincidentes con esta IP de origen, sin discernir qué regla creó el estado.

Un ejemplo:

table <abusive_hosts> persistblock in quick from <abusive_hosts>

pass in on $ext_if proto tcp to $web_server \port www flags S/SA keep state \(max-src-conn 100, max-src-conn-rate 15/5, overload <abusive_hosts> flush)

Esto hace lo siguiente:

Limita a 100 el número máximo de conexiones por origen Limita la tasa del número de conexiones a 15 en un lapso de 5 segundos Pone la dirección IP de cualquier máquina que quiebre estos límites en la

tabla <abusive_hosts> Para cualquier dirección IP ofensiva, suprime los estados creados por esta

regla.

Indicadores de TCP

La concordancia de paquetes TCP basada en indicadores es algo que se suele usar para filtrar paquetes TCP que estén intentando abrir una nueva conexión. Aquí se puede ver una lista de indicadores TCP y sus significados:

F : FIN - Finish; final de la sesión S : SYN - Synchronize; indica una petición para iniciar la sesión R : RST - Reset; abandona una conexión P : PUSH - Push; el paquete es enviado inmediatamente A : ACK - Acknowledgement («acuse de recibo») U : URG - Urgent («urgente») E : ECE - Explicit Congestion Notification Echo («mensaje de congestión

explícita») W : CWR - Congestion Window Reduced («ventana de congestión

reducida»)

Para que PF inspeccione los indicadores TCP durante la evaluación de una regla se usa la clave flags con la sintaxis siguiente:

flags check/maskflags any

La parte mask indica a PF que sólo inspeccione los indicadores especificados, y la parte check especifica qué indicadores deben estar activos ("on") en la cabecera para que ocurra una concordancia. EL uso de la palabra-clave any permite que cualquier combinación de indicadores (flags) sea definido en la cabecera.

pass in on fxp0 proto tcp from any to any port ssh flags S/SA pass in on fxp0 proto tcp from any to any port ssh

Como los indicadores S/SA se definen de forma prederminada, las reglas anteriores son equivalentes. Cada una de estas reglas permite el paso de tráfico TCP con el indicador SYN activo, y sólo mira a los indicadores SYN y ACK. Un paquete con los indicadores SYN y ECE concordaría con la regla anterior, mientras que un paquete con SYN y ACK, o sólo con ACK, no concordaría.

Los indicadores predeterminados pueden sobreescribirse mediante la opción flags tal como se ha descrito anteriormente.

Hay que tener cuidado con el uso de indicadores; hay que entender qué es lo que se está haciendo y por qué, y tener cuidado con los consejos recibidos de otros ya que muchos suelen ser erróneos. Algunas personas han sugerido la creación de estado «solo si está activado el indicador SYN, y no otros». Una regla de este tipo terminaría así

. . . flags S/FSRPAUEW mala idea!!

La teoría es crear estado solo en el inicio de la sesión TCP, y la sesión debería iniciarse con un indicador SYN, y ningún otro. El problema es que algunos sitios están empezando a usar el indicador ECN, y cualquier sitio que use ECN e intentara conectar con nosotros sería rechazado por una regla de ese tipo. Un enfoque mucho mejor sería no especificar indicador alguno y dejar a PF que aplique los indicadores predeterminados a las reglas de usted. Si realmente necesita usted especificar indicadores, entonces esta combinación debería ser segura:

. . . flags S/SAFR

Aunque esto es práctico y seguro, también es necesario comprobar los indicadores FIN y RST si se está normalizando (scrub) el tráfico. El proceso de normalización de paquetes hará que PF descarte cualquier paquete entrante que

lleve una combinación ilegal del indicador TCP (como SYN y RST) y normalice combinaciones potencialmente ambiguas (como SYN y FIN).

Proxy de paquetes TCP SYN

Normalmente, cuando un cliente inicia una conexión TCP a un servidor, PF pasa los paquetes del saludo inicial ( handshake) entre los dos extremos según llegan. Sin embargo, PF también puede hacer de proxy para el saludo inicial. Con el modo proxy, PF completará el saludo inicial con el cliente, iniciará un saludo inicial con el servidor, y pasará los paquetes entre los dos. La ventaja de este proceso es que no se enviará ningún paquete al servidor antes de que el cliente complete el saludo inicial. Esto elimina la amenaza de que desbordamientos TCP SYN falseados puedan afectar al servidor, debido a que una conexión de un cliente falseado no podrá completar el saludo inicial.

El proxy TCP SYN se activa usando la clave synproxy state en las reglas de filtrado. Ejemplo:

pass in on $ext_if proto tcp to $web_server port www synproxy state

En este ejemplo, PF hará de proxy TCP para las conexiones del servidor web.

Debido al modo en que funciona synproxy state, también incluye la misma funcionalidad que keep state y modulate state.

El proxy SYN no funcionará si PF está funcionando sobre un bridge(4).

Bloqueo de paquetes falsificados

La falsificación de direcciones (spoofing) es cuando un usuario con malas intenciones falsifica la dirección IP de origen en los paquetes que se transmiten, con el objetivo de esconder su dirección real o de suplantar otro nodo en la red. Una vez que el usuario ha falsificado su dirección, puede lanzar un ataque a nivel de red sin revelar la dirección real de origen del ataque, o intentar obtener acceso a servicios de la red que estén restringidos para ciertas direcciones IP.

PF ofrece cierto nivel de protección contra la falsificación de direcciones mediante la clave antispoof:

antispoof [log] [quick] for interface [af]

log Indica que los paquetes que concuerden se deben registrar en un fichero a través de pflogd(8).

quick Si un paquete concuerda con esta regla, entonces se considerará que es la regla «ganadora» y finalizará la evaluación del grupo de reglas.

interface La interfaz de red en la que se va a activar la protección contra las falsificaciones. También puede ser una lista de interfaces.

af La familia de direcciones para la que se va a activar la protección contra las falsificaciones, y que puede ser inet para IPv4 ó inet6 para IPv6.

Ejemplo:

antispoof for fxp0 inet

Cuando se carga un grupo de reglas, cualquier suceso de la clave antispoof se expandirá en dos reglas de filtrado. Asumiendo que la interfaz fxp0 tuviera una dirección IP 10.0.0.1 y una máscara de subred de 255.255.255.0 (o sea, un /24), la regla antispoof anterior se expandiría así:

block in on ! fxp0 inet from 10.0.0.0/24 to anyblock in inet from 10.0.0.1 to any

Estas reglas realizan dos funciones:

Bloquean todo el tráfico que viene desde la red 10.0.0.0/24 que no pase a través de fxp0. Como la red 10.0.0.0/24 está en la interfaz fxp0, los paquetes que tengan una dirección de origen en ese bloque de red nunca entrarán por ninguna otra interfaz.

Bloquean todo el tráfico entrante desde 10.0.0.1, la dirección IP en fxp0. La máquina anfitriona no debería enviar nunca paquetes a sí misma a través de una interfaz externa; por lo tanto, se puede considerar que cualquier paquete entrante con una dirección de origen que pertenezca a la máquina es malicioso.

NOTA: Las reglas de filtrado resultantes de la expansión de la regla antispoof también bloquearán los paquetes que se envíen por la interfaz de loopback hacia direcciones locales. Es recomendable desactivar el filtrado en las interfaces de loopback, pero esto se convierte en necesidad cuando se utilizan reglas contra falsificaciones:

set skip on lo0

antispoof for fxp0 inet

El uso de antispoof se debe restringir a las interfaces a las que se les haya asignado una dirección IP. El uso de antispoof en una interfaz sin una dirección IP resultará en reglas de filtrado como:

block drop in on ! fxp0 inet allblock drop in inet all

Con estas reglas existe el riesgo de bloquear todo el tráfico entrante en todas las interfaces.

Unicast Reverse Path Forwarding

PF ofrece la funcionalidad Unicast Reverse Path Forwarding (uRPF). Cuando un paquete se somete a la comprobación uRPF, se busca la dirección IP de origen del paquete en la tabla de enrutamiento. Si la interfaz de salida hallada en la la tabla de enrutamiento es la misma por la que el paquete acaba de entrar, entonces la comprobación uRPF permite el paso del paquete. Si las interfaces no coinciden, entonces es posible que el paquete tenga su dirección de origen falsificada.

La comprobación uRPF puede realizarse en los paquetes utilizando la palabra-clave urpf-failed en las reglas de filtrado:

block in quick from urpf-failed label uRPF

Nótese que la comprobación uRPF solo tiene sentido en un entorno donde el enrutado es simétrico.

uRPF proporciona la misma funcionalidad que las reglas antifalsificación

Detección pasiva del Sistema Operativo

La identificación pasiva del sistema operativo (OS Fingerprinting u OSFP por sus siglas en inglés) es un método para detectar pasivamente el sistema operativo de una máquina remota basado en ciertas características contenidas en sus paquetes SYN TCP. Esta información puede usarse después como criterio en las reglas de filtrado.

PF determina el sistema operativo remoto comparando las características de un paquete SYN TCP con el archivo de huellas digitales (fingerprints), que por omisión es /etc/pf.os. Una vez que PF está habilitado, la lista actual de huellas digitales puede verse con la siguiente instrucción:

# pfctl -s osfp

Dentro de una regla de filtrado, una huella digital puede especificarse mediante una clase de sistema operativo, versión o nivel de subtipo/parche. Cada uno de estos elementos se lista en la salida de la instrucción pfctl de arriba. Para especificar una huella digital en una regla de filtrado se usa la palabra clave os:

pass in on $ext_if from any os OpenBSD keep stateblock in on $ext_if from any os "Windows 2000"block in on $ext_if from any os "Linux 2.4 ts"block in on $ext_if from any os unknown

La clase especial de sistema operativo unknown hace que los paquetes concuerden con la regla si las huellas digitales del sistema operativo son desconocidas.

TOME NOTA de lo siguiente:

Las huellas digitales de los sistemas operativos de vez en cuando son incorrectas debido a paquetes falsificados y/o fabricados que son hechos para parecer como si provinieran de un sistema operativo específico.

Ciertas revisiones o niveles de parcheo de un sistema operativo pueden cambiar el comportamiento de la pila y hacer que ya no concuerde con el archivo de huellas digitales o que concuerde con algún otro sistema operativo.

El OSFP sólo funciona con los paquetes SYN TCP; no funcionará con otro protocolos o con conexiones ya establecidas.

Opciones de IP

Por definición, PF bloquea los paquetes con las opciones IP activadas. Esto puede hacer las cosas más difíciles para utilidades de detección de sistemas operativos (OS fingerprinting) como nmap. Si se tiene una aplicación que requiere el paso de estos paquetes, como multidifusión o IGMP, se puede usar la directiva allow-opts:

pass in quick on fxp0 all allow-opts

Ejemplo de reglas de filtrado

A continuación tenemos un ejemplo de un grupo de reglas de filtrado. La máquina en la que está funcionando PF actúa como cortafuegos entre una red interna pequeña e Internet. Sólo se muestran las reglas de filtrado; las reglas de queueing, nat, rdr, etc.. se han omitido en este ejemplo.

ext_if = "fxp0"int_if = "dc0"lan_net = "192.168.0.0/24"

# tabla que contiene todas las direcciones IP asignadas al cortafuegostable <firewall> const { self }

# no filtrar en el interfaz loopbackset skip on lo0

# normalizar los paquetes entrantesmatch in all scrub (no-df)

# configurar una política de denegación predeterminadablock all

# activar la protección contra la falsificación de direcciones# para todas las interfacesblock in quick from urpf-failed

# permitir sólo conexiones por ssh si provienen# desde la máquina de confianza, 192.168.0.15;# usar "block return" para que se envíe un TCP RST# para cerrar inmediatamente las conexiones bloqueadas;# usar "quick" para que las reglas "pass" que# vienen a continuación no anulen esta regla.block return in quick on $int_if proto tcp from ! 192.168.0.15 \ to $int_if port ssh

# permitir el paso del tráfico hacia y desde la red local# estas reglas crearán entradas de estado debido a la opción# por omisión "keep state" que se aplica automáticamentepass in on $int_if from $lan_netpass out on $int_if to $lan_net

# permitir el paso de paquetes tcp, udp e icmp# salientes en la interfaz externa (Internet);# modular el estado en conexiones tcp y mantener el estado en udp/icmp.pass out on $ext_if proto { tcp udp icmp } all modulate state

# permitir el paso de las conexiones entrantes de ssh# en la interfaz externa siempre que su destino NO sea# el cortafuegos (o sea, aquellas cuyo destino sea# una máquina en la red local); registrar el paquete inicial# para que podamos ver más tarde quién intenta conectar.# Usar el proxy tcp syn para la conexión.# PF aplicará automáticamente los indicadores por omisión "S/SA"# a la regla.pass in log on $ext_if proto tcp to ! <firewall> \ port ssh synproxy state

FUNCIONAMIENTO Y CARACTERISTICAS DEL FIREWALL

SISTEMA INTEGRADO SEGURO EN TIEMPO REAL

Un sistema en tiempo real (STR) es aquel sistema digital que interactúa activamente con un entorno con dinámica conocida en relación con sus entradas, salidas y restricciones temporales, para darle un correcto funcionamiento de acuerdo con los conceptos de predictibilidad, estabilidad, controlabilidad y alcanzabilidad.

Los sistemas en tiempo real están presentes en nuestra vida diaria, prácticamente en todo lo que nos rodea; en los aviones, trenes y automóviles; en el televisor, la lavadora o el horno de microondas, en los teléfonos celulares y en las centrales telefónicas digitales. Son un elemento imprescindible para garantizar la generación, transmisión y distribución de la energía eléctrica y para asegurar la calidad y la seguridad de incontables procesos industriales.

La principal característica que distingue a los STR de otros tipos de sistemas es el tiempo de interacción. Sin embargo, antes de continuar es necesario aclarar el significado de las palabras "tiempo" y "real". La palabra "tiempo" significa que el correcto funcionamiento de un sistema depende no sólo del resultado lógico que devuelve la computadora, también depende del tiempo en que se produce ese resultado. La palabra "real" quiere decir que la reacción de un sistema a eventos externos debe ocurrir durante su evolución. Como una consecuencia, el tiempo del sistema (tiempo interno) debe ser medido usando la misma escala con que se mide el tiempo del ambiente controlado (tiempo externo).

Los STR se pueden encontrar en lugares muy importantes debido a los servicios que prestan: ellos monitorean, controlan y protegen, por ejemplo, los sistemas de transmisión y distribución que hacen llegar la energía eléctrica a las industrias y también a nuestros hogares. Los STR están presentes en el las áreas de monitoreo de tráfico de trenes; su importancia es relevante debido a que diariamente se transportan millones de pasajeros.

Un STR tiene tres condiciones básicas:

Interactúa con el mundo real (proceso físico), emite respuestas correctas y cumple restricciones temporales.

En contraste con la definición de STR, un sistema rápido produce su salida sin considerar las restricciones de tiempo del ambiente con que interactúa, para esa clase de sistemas no es importante el tiempo en el cual los datos llegan al sistema digital sino solamente el tiempo en que la salida es producida, en otras palabras únicamente interesa la rapidez de dar la respuesta dentro del intervalo de tiempo cuya medida, entre más pequeña es mejor, sin importar el costo de generar esa respuesta. De igual manera, tiende a confundirse el concepto de STR con el de sistema en línea:

Un sistema en línea es aquel que siempre debe estar encendido, disponible y generalmente conectado a una red de computadoras y depende de la capacidad

del hardware para atender peticiones de servicio y en ningún momento está en sincronía con el mundo real ni tiene restricciones temporales.

ALGORITMO DE SEGURIDAD ADAPTABLE (ASA)

El método de seguridad ASA, orientado a conexión, crea flujos de sesión basados en las direcciones de origen y destino, números de (TCP) ,números de puerto, y marcadores TCP adicionales. Esta información se almacena en una tabla, y todos los paquetes entrantes y salientes se comparan con las anotaciones de la tabla.

El firewall cuenta con la función "alternativa para abrir camino" -"cut-through proxy"- basada en el Sistema de Control de Acceso al Controlador de Acceso del Terminal (TACACS+) o el Servicio de Autenticación Remota del Usuario mediante Llamada Telefónica (RADIUS). Esta función permite que el firewall tenga un rendimiento más rápido que los servidores proxy.

También puede disponer de una función llamada Mail Guard que permite la transferencia de correo directamente a un anfitrión - host - de correo interno, eliminando así la necesidad de instalar un anfitrión -host- de transmisión de correo.

CONFIGURACION BASICA

Ahora veremos la configuración básica de un pix. Notaran que la sintaxis de los comandos del fos es muy parecida a la del ios.nota: limpie la configuración antes de usar el pix mediante el comando "write erase" (borra la configuración), y "reload" para reiniciar el firewall. Conectados al pix con un cable de consola. existe una similitud entre el fos y el ios en cuanto a los modos de operación:

pixfirewall>enablepixfirewall# configure terminalpixfirewall(config)# quitpixfirewall# disablepixfirewall>

Algo muy práctico, es que desde el modo de configuración podemos utilizar todos los comandos que se encuentran fuera de este modo. Otra cosa que se encuentra disponible en el ios, y no está disponible en el fos (finesse), es la posibilidad de que los comandos se autocompleten con latecla tab.el siguiente paso será cambiar el hostname del pix y configurar los passwords del modo no privilegiado y el modo privilegiado.

pixfirewall(config)# hostname ArcadiaArcadia(config)# password mal0rArcadia(config)# enable password MUYmal0r

CONFIGURACIÓN DEL FIREWALL DE POLÍTICA BASAD EN ZONAS CON CLI:

1.Crear las zonas para el firewall con el comandozonesecurity2.Definir clases de tráfico con el comandoclass-maptypeinspect3.Especificar políticas de firewall con el comandopolicy-m a p t y p e i n s p e c t4.Aplicar políticas de firewall a los pares de zonas de origeny destino usando el comandozone-pairsecurity5.Asignar interfaces de routera las zonas usando elcomando de interface

zone-membersecurity.