Virtual Patching en funcionamiento (Parte II)

Siguiendo la entrada anterior Virtual Patching en funcionamiento (Parte I) vamos a seguir viendo los efectos del Virtual Patching pero en el caso frente a un escáner de vulnerabilidades.

Lo que vamos a hacer es lanzar uno desde una máquina virtual con Kali Linux hacia un Windows XP vulnerable. ¿Por qué un XP? Porque este sistema operativo está aún muy presente en muchos equipos en entornos industriales y debido al largo ciclo de vida de las estaciones o instalaciones que gobiernan, siguen funcionando a pleno rendimiento. Sin embargo, como sabemos ya no hay soporte y muchos de ellos no están parcheados, lo cual les convierte en un objetivo muy apetecible a malware y usuarios malintencionados. Ni qué hablar de Windows 2000 que también los he visto… Buenos, el esquema era el siguiente:

Esquema 01

Como decía, en el post anterior trataba los resultados tras hacer un escaneo con Nmap. Ahora toca pasar a la siguiente etapa dentro de una supuesta intrusión, o auditoría. Encontrar vulnerabilidades para ser explotadas. Para ello se utiliza un escáner que en nuestro será “Nessus”, pudiendo encontrarse otros como OpenVAS y Nexpose.

Kali Linux no lo trae por defecto, así que lo hemos descargado de la página del producto, obtenido el código correspondiente, instalado y actualizado los plugins. Luego creamos el proyecto y definimos los perfiles que queremos utilizar. En mi caso he dejado sólo los relacionados con plataformas Windows para que sea algo más rápido. No obstante os dejo otro de mis post donde hablaba de la metodología del Pentesting. Lo podéis encontrar aquí.

Nessus 01

Por otro lado la configuración de reglas en el Fortinet Fortigate Rugged 60D quedaría como sigue:

Nessus 02

Como se puede ver se permite todo el tráfico entre las interfaces “Wan1” y “Wan2”, pero se someterá a los motores Antivirus, Control de Aplicación e IDS/IPS. Lo sé, lo sé, habría que restringir el tráfico sólo al imprescindible pero para la prueba lo dejaré así. En la vida real, ni se os ocurra hacer esto. En el caso de este último, el IDS, se ha configurado para que bloquee “Block” todo aquél tráfico que coincida con alguna de las reglas en él definidas.

Tras lanzar el escáner vemos que el resultado es el siguiente. El Fortigate ha bloqueado los paquetes desde el escáner:Nessus 03

Si a continuación hacemos un reporte de las vulnerabilidades encontradas vemos que sólo se han encontrado un total de 8 de nivel informativo.

Nessus 04

Así pues el supuesto atacante apenas podría haber obtenido información del objetivo, con lo que tendría más complicado a la hora de lanzar un exploit concreto cara a aprovechar una vulnerabilidad. Aunque no se aprecie en la imagen, los datos ofrecidos no son relevantes cara a este fin, la intrusión. En cambio, si deshabilitamos dicha protección, esto es:

Nessus 05

Y lanzamos de nuevo el escáner, el resultado sería bien distinto:

Nessus 06

Aquí veremos que sí se obtienen datos sobre el equipo con Windows XP y por tanto sería exitoso el ataque como el que se podría llevar a cabo en el punto siguiente. Entre ellas hay un total de 3 vulnerabilidades “Critical”, 2 “Medium”, y 20 “Info” destacando entre ellas la que figura a continuación.

34477 (1) – MS08-067: Microsoft Windows Server Service Crafted RPC Request Handling Remote 

Code Execution (958644) (uncredentialed check) 

Synopsis

Arbitrary code can be executed on the remote host due to a flaw in the ‘Server’ service.

Description

The remote host is vulnerable to a buffer overrun in the ‘Server’

service that may allow an attacker to execute arbitrary code on the remote host with the ‘System’ privileges.

See Also

http://technet.microsoft.com/en-us/security/bulletin/ms08-067

Solution

Microsoft has released a set of patches for Windows 2000, XP, 2003, Vista and 2008.

Risk Factor

Critical

CVSS Base Score

10.0 (CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C)

CVSS Temporal Score

8.7 (CVSS2#E:H/RL:OF/RC:C)

STIG SeverityI

References 

BID 31874

CVE CVE-2008-4250

XREF OSVDB:49243

XREF MSFT:MS08-067

XREF IAVA:2008-A-0081

XREF CWE:94

Exploitable with

CANVAS (true)Core Impact (true)Metasploit (true)

Plugin Information:

Publication date: 2008/10/23, Modification date: 2015/06/18

Hosts

XX.XX.XX.17 (tcp/445)

Queda bastante claro la funcionalidad de estos motores. A pesar de no restringir el tráfico mediante reglas de firewall tradicionales y dejar pasar todo, algo que obviamente NO DEBE HACERSE BAJO NINGÚN CONCEPTO, nos proporcionan un grado de protección evidente.

En este ejemplo lo hemos hecho sobre un Windows XP vulnerable, pero esto también podríamos emplearlo como elemento de seguridad perimetral sobre Sistemas de Control y Automatización Industrial u otros dispositivos con capacidades limitadas para la implementación de medidas de seguridad. Su protección en este caso radicaría en el Fortigate Rugged 60.

Así hemos terminado por hoy. En la próxima entrada veremos cómo comprometer el Windows XP mediante Metaesploit gracias a la vulnerabilidad anterior.

Como en otras ocasiones os animo a que dejéis vuestro comentario, tanto si es positivo como si no lo es. Todo sirve para mejorar.

Lo dicho, un saludo, nos vemos en la próxima!!

Virtual Patching en funcionamiento (Parte I)

Siguiendo con el tema de Virtual Patching ahora toca ver cómo funciona y los beneficios que puede aportarnos.

Para ello he creado un entorno con dos PCs interconectados por medio de un Fortinet Fortigate Rugged 60D configurándolo con motores Antivirus, IDS/IPS y Control de Aplicación. La parte de firewall la he dejado con un “permit any any any” (IP origen, destino y puerto, respectivamente) Hay que recordar que cada una de ellos lo podemos configurar en dos modos, “Monitor” o “Block”. Con el primero, en caso de que se detecte algún patrón que puda quedar recogido dentro de las reglas y firmas, no se tomará ninguna acción, sólo se registrará el evento y se dejará pasar. En cambio con “Block”, valga la redundancia se bloqueará y la amenaza será paralizada.

Luego, estas características han de aplicarse, o no, a las reglas de Firewall en él configuradas.

En cada uno de estos PCs he virtualizado un total de 3 máquinas.

Una con Kali Linux desde la cual simularemos la actividad de un atacante. Lanzaremos un escaneo de puertos con Nmap, escáner de vulnerabilidades con Nessus, intento de intrusión con Metaesploit y Armitage y por último copiar en un recurso de red el fichero EICAR.

Otra con un Windows XP vulnerable, el objetivo. Se ha elegido este ya que posee vulnerabilidades que para un ejemplo pueden ser fácilmente explotables. Aparte porque su uso en entornos industriales y o vida prolongada es aún bastante común.

Por último un Fortinet FotiManager con funciones FortiAnalyzer desde donde gestionaremos el equipo Fortigate Rugged 60D. Lo he querido utilizar ya que con un despliegue de varios equipos resulta aconsejable no sólo por la gestión centralizada sino porque nos permite almacenar los logs, analizar tráfico, sacar informes, ver registros, etc.

Todo queda resumido de la siguiente manera:

 

Esquema 01

En la imagen siguiente se muestra cómo el equipo Fortigate bloquea un total de 9965 amenazas catalogadas en un total de 1993 incidentes, provenientes de la IP XX.XX.XX.15 de la máquina Kali Linux. Esto es debido a que la aplicación Nmap envía sucesivamente paquetes para que en función de las respuestas obtenidas se pueda determinar si un equipo está activo, o no, puertos abiertos; versiones de aplicaciones, servicios; etc.

Para conocer un poco más recomiendo la siguiente lectura, pincha aquí.

Imagen 01

En esta otra se puede ver que el equipo destino tiene la IP XX.XX.XX.17.

Imagen 02

En la siguiente imagen se muestra las “sondas” enviadas desde el equipo Kali Linux identificando alguna aplicación que otra:

Imagen 03

Como se puede apreciar éstas han sido bloqueadas no pudiéndose obtener datos sobre el equipo objetivo, el XP. Esto mitigaría la etapa inicial de recolección de información que un atacante llevaría a cabo y poder, a partir de ahí, realizar otro tipo de acciones sobre nuestros sistemas.

Obviamente habría que configurar las reglas del firewall del modo más restrictivo posible y sobre el tráfico que dejamos pasar aplicar el análisis de los motores Antivirus, IPS y Control de Aplicación. Sin embargo para este ejemplo se ha querido dejar así para ver el comportamiento de la aplicación Nmap y qué es lo que sucede si no empleamos un cortafuego. Pero como como digo, siempre, siempre, siempre, ha de restringirse el tráfico sólo al estrictamente permitido por medio de estos firewalls.

Esto es todo por hoy, pero os debo las siguientes entradas sobre escáner de Vulnerabilidades, Metaesploit y EICAR Test File.

No s vemos en la próxima, y como siempre digo, se agradece cualquier comentario al respecto.

Muchas gracias!

Pfsense

Hola de nuevo. En esta ocasión os dejo una serie de entradas del blog Security Art Work de S2 Grupo.

Las mismas hablan de las distintas funcionalidades del Firewall Pfsense. No os voy a dar más detalles ya que está todo muy bien explicado. Excelentes artículos de tantos que podréis encontrar en este blog, y que invito a seguir.

Parte I

Parte II

Parte III

Parte IV

Parte V

Parte VI

Espero que os gusten!!

 

Cuando VLANs y Firewalls no son suficientes

Como comentaba en la entrada anterior, hace poco terminé el curso sobre Ciberseguridad en Sistemas de Control y Automatización Industrial impartido por el Instituto Nacional de Ciberseguriad (INCIBE) antes, INTECO.

Dentro de su contenido, en uno de sus módulos se trataba el tema de los incidentes de seguridad sobre dichos sistemas, analizando desde los posibles objetivos potenciales hasta las deficiencias técnicas, pasando por controles de acceso físico pobres o incluso nulos.

Entre esos puntos se apuntaba como orígenes a la red corporativa y a cortafuegos perimetrales mal configurados. En el primero de ellos, se explicaba que tanto los sistemas empresariales como industriales comparten la misma infraestructura de comunicaciones  permitiendo  llevar ataques desde la red corporativa a la de control aprovechando alguna vulnerabilidad en aquéllos. En lo referente a los cortafuegos perimetrales, se comentaban las malas configuraciones sobre ciertos protocolos y también, no considerar el sentido de las conexiones. Como ejemplo se hablaba de una intrusión en los sistemas de control, la ejecución de un “payload” en ellos e iniciar una conexión a un equipo remoto empleando un puerto abierto en el firewall.

Partiendo de la base que ninguna red es igual ya que las necesidades y usos pueden ser bien distintos, en la entrada de hoy voy a hablar de dos aspectos que afectan a las ideas descritas en los apartados anteriores.

Por mi experiencia, es muy común que equipos corporativos convivan con los de control dentro del mismo switch. Por ejemplo, en una cadena de producción tenemos un PC donde  ejecutamos distintas aplicaciones relacionadas con el proceso de fabricación, mientras que en otros puertos tenemos los autómatas que controlan la maquinaria (robots, sensores, válvulas, etc.). También puede ocurrir que existan incluso puntos de acceso inalábricos para aquellos dispositivos no cableados tipo PDAs industriales, lectores de códigos de barras, PCs portátiles de personal de mantenimiento, etc. ¡Y posiblemente todo dentro de la misma VLAN! Resultaría costosísimo, o incluso inviable, implementar dos o tres infraestructuras paralelas para separar físicamente todo el tráfico, así que la realidad es que unos y otros deben “viajar” por el mismo equipo y por la misma red, aunque separados lógicamente mediante el uso deVLANs.

Por otro lado, debemos pensar que a la hora de interconectarlo todo, no se puede implementar cortafuegos por cada enlace, subred, equipo, etc. para regular el tráfico a permitir o denegar. Si bien la inversión, condiciona en gran medida la solución tecnológica a utilizar (salvo que sobre el dinero, que viendo los tiempos que corren es poco probable…), debemos pensar,  en lo a la parte técnica se refiere, que los switches nos pueden ofrecer una serie de ventajas que, a veces, los cortafuegos no lo hacen. Por ejemplo, mayor densidad de puertos y uso de módulos SFP para distintos medios físicos como cable y fibra óptica. También es cierto que los cortafuegos realizan tareas que no hacen los switches. Unos no  son mejores que los otros, sino que cada cual hace su papel y se complementan.

A estas ideas debemos sumar también la implantación de medidas que garanticen una alta disponibilidad de los servicios prestados, con lo que aparte de equipos de comunicaciones, de seguridad, control, automatización, etc. debemos disponerlo todo de tal manera que en caso de producirse un fallo, la red pueda seguir funcionando sin que esto suponga un impacto en la calidad del servicio ofrecido.

Como bien dice el refrán “Una imagen vale más que mil palabras”  he creado un escenario para tratar de entender mejor lo dicho. He utilizado la aplicación de Cisco Systems, Packettracer, utilizada para la preparación de las certificaciones CCNA y CCNP, entre otras.

Basándome en los criterios de este post, aquí os dejo la topología:

Topología

Topología

Para explicarlo empezaremos de izquierda a derecha.

Tenemos el equipo “Switch Acceso” (Switch L2) al que se conectan por un lado los autómatas PLC-01 y PLC-02, y por otro un PC que pueda ser utilizado para la ejecución de aplicaciones relacionadas con la actividad industrial. También se ha incluido una impresora, como un elemento de red más que pueda ser utilizado para la impresión de algunos documentos, órdenes de montaje, códigos de barras para temas logísticos, etc.

Para segmentar el tráfico, los PLCs,  el PC y la impresora se han situado en VLANs distintas. PLC-01 y PLC-02 en la VLAN 10 con direccionamiento 192.168.10.0 /24; y PC-01 y Printer0 en la VLAN 20, y red 192.168.20.0/24. Como puerta de enlace será la primera IP de ambas redes, la .1.

Dado que es un entorno de alta disponibilidad, se ha configurado en los switches “sw-core-01” y “sw-core-02” (Ambos multicapa o L3) interfaces virtuales para cada una de las VLANs, y en ellas, el protocolo HSRP, aunque también hubiera servido VRRP. Si no sabéis o queréis refrescar los conceptos de interfaces virtuales o dejo un link a un artículo que publiqué hace un tiempo, aquí.

Luego tenemos los cortafuegos, que filtrarán el tráfico entre la red de servidores donde se sitúa el servidor de SCADA, Historiadores, etc y el resto. Esta red tiene un direccionamiento 192.168.254.0/24, y está en la VLAN 254. También está configurado HSRP.

No he dibujado la red corporativa como oficinas ya que no viene por ahí el problema de seguridad que quiero explicar, pero de existir, deberían colgar de cada uno de los nodos del firewall, como lo están las dibujadas.

Como podréis ver los cortafuegos tiene un enlace entre sí. Todo tiene una explicación.

Al igual que en los equipos de red tenemos HSRP, VRRP y GLBP para implementar alta disponibilidad, los cortafuegos tienen los suyos también. Lo que se hace es una topología tipo “Activo-Pasivo” o “Activo-Activo”. La primera de ellas, sería equiparable al comportamiento de HSRP y VRRP, donde uno de los nodos soporta todo el tráfico, el “Master”, mientras que el otro está de respaldo, el “Backup”. En caso de que el “Master” falle, el “Backup” entra en funcionamiento. El modo “Activo-Activo” es aquél en el que ambos nodos funcionan a la par, proporcionando no sólo una alta disponibilidad, ya que si uno falla el otro asume su rol, sino que además existe un balanceo de carga ya que se puede repartir el tráfico entre ambos.

En cualquiera de los dos casos, ambos nodos deben tener un enlace donde compartir una tabla con las conexiones que tiene abiertas, ya que si el nodo “Master” falla, el de “Backup” debe seguir permitiéndolas. Si no existiese este enlace y el nodo de “Backup” no tuviese dicha tabla, cuando uno de los equipos finales volviesen a generar tráfico de una sesión ya establecida, las cortarían.

Por no estar hablando siempre de Cisco, Juniper tiene su protocolo NSRP. Os dejo algunos enlaces pero si buscáis en por ahí  encontraréis un montón de información al respecto.

 Link 1

Link 2

Link 3

Fortinet también tiene soluciones similares. Os dejo más links:

Link 1

Link 2

Link 3

Vale, tenemos el PC y la impresora en una VLAN; y los PLCs en otra de tal manera que a nivel de capa 2 los tenemos “aislados” y cada uno en su propio dominio de broadcast. Mismo criterio con los servidores. Sin embargo, los equipos PLC no están todo lo protegidos que debieran.

¿Por qué? Porque si nos fijamos el PC-01 a pesar de estar en una VLAN distinta de los PLCs puede llegar a ellos sin problemas. Vamos a abrir un navegador del PC-01 y la IP del PLC-01.

Configuración Autómata

Configuración Autómata

¿Por qué? Sencillo. Cuando abrimos el navegador el tráfico llega al switch sw-core-01. Como éste tiene acceso a la VLAN donde está la dirección IP de destino, la 192.168.10.100, es el propio switch el que lo envía por la interfaz de la VLAN 10 ya que están ambas en el mismo equipo. La 10 y la 20.  Podríamos cambiar manualmente el enrutamiento para que fuese todo al tráfico hacia el firewall y éste lo descartase, pero tampoco tiene mucho sentido hacerlo “subir” hasta ahí para luego descartarlo  y ocupar un ancho de banda por poco que sea, nos puede resultar necesario, especialmente a los PLC en su comunicación con el servidor SCADA.

 Por tanto, hay una cosa que es clara y es que tenemos que filtrar el tráfico para evitar que ningún equipo de la red 192.168.20.0/24 pueda llegar a la 192.168.10.0/24. Sin embargo, sí que tenemos que permitir el tráfico desde la red 192.168.20.0/24 a cualquier otro equipo de la red.

Así que, ¿qué alternativa tenemos? La alternativa son las ACL, Access List. Pero esto lo dejamos para la siguiente entrada.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Distribuciones para seguridad y servicios de red

Que la seguridad es un elemento clave en cualquier entorno sea en infraestructuras de comunicaciones, informática o entornos industriales es algo que a esta altura del partido nadie se cuestiona.  Controlar el acceso a la red, los ficheros, gestionar los permisos y derechos de los usuarios, cifrado de comunicaciones, filtrado de contenidos, etc. etc. son algunas de tantas medidas que podremos adoptar para garantizar una seguridad global y proteger así nuestra información.

Como es costumbre no voy hablar de las configuraciones que nos ofrecen los Sistemas Operativos o aplicaciones sino que nos ceñiremos, como siempre, a las comunicaciones. Desde este punto de vista los firewalls e IDS/IPS juegan un papel clave. Deberemos empezar por tener muy claro dónde situarlos para proteger unos u otros segmentos de red en función de lo que allí tengamos. Mientras que los Cortafuegos permitirán o denegarán el tráfico dirigido equipos que prestan algún tipo de servicio; los IDS/IPS se encargarán de analizarlo y detectar posibles patrones de ataques o “movimientos” hostiles en nuestra red. Y si es posible, tomar alguna medida para bloquearlo.

Cada uno de nosotros tenemos una disciplina profesional definida, lo cual no quita que tengamos que saber de otras que circulan a nuestro alrededor. Todo lleva un aprendizaje previo, y con él un tiempo que puede no tengamos, al menos, para especializarnos todo que quisiéramos. Da igual si hablamos de tecnologías, comunicaciones, sistemas, aplicaciones, entornos,… todo lleva lo suyo. Por no hablar de las soluciones propietarias de fabricantes, que si Cisco saca tal o cual prestación, Juniper hace algo parecido con distinto nombre, etc. etc. vamos, la historia de nunca acabar.

Para facilitarnos las cosas, por suerte, existen algunos proyectos e iniciativas con los que podemos contar para que, con una menor inversión de tiempo y conocimientos, podamos acceder a ciertos sistemas, aplicaciones y funcionalidades. Tal es el caso de las distribuciones con un conjunto de herramientas dispuestas a cumplir con un fin concreto. Así como dentro del mundo de la seguridad y pentesting tenemos a “Kali” existen otras, las cuales están orientadas a la seguridad o servicios de red, que presento a continuación.

Firewalls

SmoothWall Firewall

M0n0wall

BrazilFW, Firewall and Router

IDS

SmoothSec

EasyIDS

Monitorización de redes

FAN, Fully Automated Nagios

Seguridad de redes

NST, Network Security Toolkit

Router

BSD Router Distribution

En el siguiente enlace os dejo un listado que podréis encontrar en Wikipedia donde se incluyen bastantes más, algunos incluso descontinuados. Pinchar aqui.

Almacenamiento

FreeNAS

Openfiler

Aparte de la facilidad de su despliegue y su uso gracias a sus interfaces gráficas, otra de las ventajas a destacar es su costo. Al estar basados en software libre, se hacen propicios en entornos donde no se cuente con recursos económicos para adquirir otro tipo de soluciones comerciales, o incluso sustituirlas según sean los casos. Pensemos, por ejemplo, en una PYME que pueda reutilizar un equipo reemplazado y que dotándolo con unas tarjetas de red adicionales pueda convertirse en un cortafuegos, router, web proxy, servidor VPN, o lo que sea. Lo que quiero decir es que no necesitamos invertir una cantidad de dinero más o menos considerable para garantizar la seguridad sino que además no tenemos que renunciar a ella en caso de no disponer de un capital para adquirir algún producto de los tantos que hay en el mercado.

En fin, bien por falta de tiempo o recursos económicos, no tenemos porqué perder unos servicios o funcionalidades en nuestras redes de datos. Tenemos a nuestra disposición un gran número de distribuciones, que sin tener un conocimiento exhaustivo de los sistemas sobre los cuales están basados, pueden cumplir con nuestras necesidades.

FWBuilder

Uno de los elementos que contribuyen a garantizar la seguridad en una red son los Cortafuegos (Firewalls). Estos equipos, básicamente,  permiten o deniegan, el tráfico en una red en función de unos parámetros dados que como norma general son las IPs de origen y destino, números de puertos (80, 443, 21, 22, etc.) y protocolos, generalmente TCP y UDP. Dependiendo de las características del Firewall en cuestión, éstos ofrecen otras funcionalidades adicionales como filtrado a nivel de aplicación (HTTP, FTP, DNS, etc.), creación de VPNs, etc.

Existen muchos fabricantes como Cisco, Juniper, Checkpoint, que ofrecen este tipo de equipos, pero independientemente de cualquiera de ellos,  diseñar, implementar y mantener una correcta y estricta política de filtrado de tráfico es vital para garantizar la seguridad de red.  Para poder llevar a cabo esta tarea los propios fabricantes disponen de herramientas propietarias para configurarlos, o incluso equipos específicos de administración.

Pero al margen de soluciones propietarias, GNU/Linux nos trae la herramienta iptables la cual nos permite no sólo filtrar el tráfico que pasa por el equipo sino además manipular los paquetes. Esta funcionalidad aparte de proteger equipos también nos puede servir para crear un firewall si a éste le añadimos varias tarjetas de red. Aquí os dejo un manual que explica muy bien esta funcionalidad, pincha aqui.

Como habréis podido ver, configurar las reglas tiene  los suyo sobre todo a medida que vamos añadiendo reglas y más reglas. Sin embargo existe una herramienta que nos puede ayudar mucho en esta tarea, y es FWBuilder. Con FWBuilder podremos crear reglas para distintas plataforma las cuales podremos consultar aquí.

En mi caso lo he probado sobre un Ubuntu 12.04 LTS, con lo que me he bajado el .deb correspondiente y gracias a la herramienta gdebi la he instalado.

Captura 01

Una vez instalada la aplicación, la abrimos y tendremos la siguiente ventana:

Captura 02

Para empezar a crear nuestra primera política pincharemos en “Create new firewall” apareciéndonos un asistente donde definiremos la plataforma. En nuestro caso iptables.

Captura 03

Luego nos pedirá definir las interfaces, paso que podremos saltarnos y hacerlo a posteriori si queremos. 

En la ventana encontraremos  distintos apartados. Por ejemplo en “Library” optaremos por “Standard” y “User”. En el primero tendremos predefinidos los servicios más utilizados en función sean en TCP o UDP. En “User” podremos definir aquellos que por una razón u otra personalizaremos según nuestras necesidades. Por ejemplo correr SSH en el puerto 65500 en lugar del 22.

Captura 04

Otra de las partes es la que cuelga bajo el nombre que le hayamos dado a nuestra regla, que son “Policy”, “NAT” y “Routing”. En Policy, indicaremos las reglas de filtrado como tal, IP origen, destino, servicio, interface, etc. y la correspondiente acción, denegar, permitir, etc.

Captura 05

En NAT, obviamente las reglas de “NATeo” que vayamos a definir en el caso de ser necesario.

Captura 06

Y finalmente “Routing” las tablas de rutas a las que estarán sujetos los paquetes que pasen por nuestro Firewall.

Captura 07

Para agregar una entrada en cada una de los puntos anteriores bastará con hacer doble click en la cruz verde bajo la opción “Install”.

Luego tendremos otros dos apartados denominados “Objects” y “Services”.  En el primero definiremos todo lo relacionado a equipos, grupos de equipos, redes, subredes, etc. mientras que en el segundo aquello vinculado a servicios, es decir protocolos IP, TCP, UDP, y sus correspondientes números de puerto.

Una vez tengamos todo hecho, tendremos que ir al apartado “Compile”. Con esto, la herramienta compilará todas las reglas (Policy, NAT y Routing) y generará un archivo si todo está correcto. Si no lo está, nos dará un error, el cual tendremos que corregir modificando el apartado erróneo. Finalmente, ejecutaremos el fichero en cuestión y se aplicará todo lo que hayamos configurado.

 Lo que he tratado de hacer en este post es presentar una herramienta que nos puede ayudar mucho en nuestras tareas de administración para elaborar nuestras reglas de filtrado en nuestro Firewall, y que, en caso de no disponer uno, si tenemos la posibilidad de instalar unas tarjetas de red en un PC, nos bajamos una distribución GNU/Linux como Ubuntu y con FWBuilder montarnos nuestro propio firewall.

También tenemos otras alternativas como utilizar alguna de las distribuciones ya creadas como pueden ser Smoothwall Firewall o Monowall Firewall

Seguiremos informando.