Monitoreo de pfSense con Nagios (NRPE y SNMP)

Versión pfSense: 2.1.3
Módulos:
 NRPE v2 2.12_3 v2.

Si hay algo indispensable en cualquier infraestructura, es un buen monitoreo de disponbilidad y seguridad; tener un correcto control de los dispositivos de red y servidores, permite realizar acciones proactivas y evitar casi todos los problemas que puedan surgir.

Dada la criticidad de los firewalls, una correcta definición de alertas sobre los mismos, nos puede permitir disminuir los downtimes y mejorar nuestra seguridad.

La mejor herramienta para hacerlo, por su trayectoria, por su comunidad, por su flexibilidad, por ser open-source, por ser gratutita y por ser altamente efectiva (si, me encanta), es sin lugar a dudas Nagios. Es un software que funciona con un servicio web que gestiona y facilita el monitoreo mediante una gran cantidad de plugins. Es posible realizar casi cualquier chequeo utilizando los plugins predeterminados, o cualquier otro plugin ya desarrollado o desarrollando uno propio. Todo es monitoreable: desde si la página web está mostrando un string específico o un 200/OK, hasta si un backup se ejecutó de manera correcta e íntegra.

En este post, se verán algunos conceptos y explicaciones para integrar ambas herramientas y poder adaptarlas a la necesidad de cada usuario y obtener un eficaz resultado.

Básicamente hay 3 tipos de chequeos que se pueden realizar desde Nagios:

- Chequeos Remotos: Cualquier chequeo que se pueda realizar sin necesidad de acceder al equipo (por ejemplo chequear el estado de servicios/puertos de manera estandar como el web, https, smtp, o ftp).

- Chequeos Locales: Cualquier chequeo realizable “desde adentro” de un equipo para obtener datos que no son publicables y que necesitan ciertos privilegios que “desde afuera” no sería posible. Para realizarlos, se instala en los equipos a chequear un agente, que los ejecuta y que brinda cierta seguridad y facilidad para consultarlos desde nuestro monitoreo. Por ejemplo, es posible chequear el espacio en disco, el uso de memoria, si un servicio en particular esta activo, si un archivo no se modifico, y muchos más. Existen varios agentes para chequeos locales, pero los más utilizados, confiable y faciles de implementar, son para Unix/Linux/BSD NRPE, y para Windows NSCLIENT++.

- Chequeos SNMP: SNMP es un protocolo de consulta ampliamente aceptado y utilizado que poseen la mayoría de los dispositivos de red y sistemas operativos, que brinda de manera sencilla el acceso a muchísimas opciones de consulta de cada uno de los recursos de los dispositivos. Es una forma fácil de acceder a información de estados y funcionamiento sin necesidad de estar programando un script de consulta específico, sin embargo, se deben tener ciertos resguardos en cuanto a seguridad para asegurarnos que sólo nosros accedamos al dispositivo mediante este protocolo. Cada fabricante debe debería proveer una base de datos denominada MIB que asginan un ID númerico a cada tipo de consulta. Conociendo dicha base sabremos que nos es posible consultar mediante ese protocolo en cada equipo en particular.

¿ Que nos importa chequear en nuestro Firewall ?

En primer lugar, es siempre importante saber SI EL EQUIPO ESTA FUNCIONANDO. No ? Por lo tanto el chequeo más básico será de disponibilidad y la forma más sencilla de hacerlo es mediante el protocolo icmp (ping). Este será el único chequeo de tipo “remoto” que ejecutaremos en el equipo.

Otras ideas podrían ser:

  • UPTIME (Tiempo que estuvo activo. Si este tiempo vuelve a 0, significa que el equipo se reinició).
  • MEMORIA DISPONIBLE
  • ESPACIO EN DISCO
  • ESTADO DE LAS INTERFACES
  • ESTADO DE LAS VPNS
  • ESTADO DE LOS SERVICIOS
  • CANTIDAD DE USUARIOS CONECTADOS
  • DENEGACIONES EN LAS INTERFACES
  • TRÁFICO IN/OUT

No vamos a explicar en este artículo como implementar un sistema de monitoreo Nagios, y se asume que el usuario tiene ciertos conocimientos de dicha plataforma; si no los tenés, recomendamos leer la documentación disponible sobre la misma, que es mucha y muy buena.

Topología de Monitoreo ¿ Dónde ubicar nagios en la red ? :

La mejor opción sería ubicar Nagios en la misma red local, en una subnet específica y manejar los accesos desde ese equipo al resto o al firewall, mediante ACL específicas.

Si van a realizar un monitoreo desde algún punto remoto en Internet, sería muy recomendable realizarlo a través de una vpn ipsec; y en caso de que no sea posible, realizarlo vía intenet, pero restrigiendo mediante reglas de firewall el acceso por origen únicamente al nagios, para los servicios y puertos necesarios.

Vamos a utilizar los siguientes puertos que será necesario manejar en el firewall para que funcione, con origen Nagios y destino la IP del Firewall:

  • ICMP / PING – Para monitoreo remoto de disponibilidad.
  • 5666 / TCP – Para monitoreos NRPE
  • 161 / UDP – Para monitoreos SNMP

Configuración:

1) Definición de Template y Host:

En Nagios vamos a definir un template para este tipo de equipos que serán los firewalls pfSense de nuestra infra. Esto nos permitirá setearle parámetros de monitoreo específicos diferentes por ejemplo a servidores u otros equipos.

define host{
 name                            pfsense-firewall
 use                             generic-host
 check_period                    24x7
 check_interval                  5
 retry_interval                  1
 max_check_attempts              10
 check_command                   check-host-alive
 notification_interval           120
 contact_groups                  admins
 register                        0
}

El check_command, que define como se chequea el host para disponibilidad, en este caso será el por defecto check-host-alive, que realizar un chequeo ICMP

Y luego definiremos el Host que utilice dicho template.

define host{
 use                 pfsense-firewall
 host_name           pfsense.empresa.com.ar
 alias               pfsense.empresa.com.ar
 address             192.168.0.1
}

Con esta configuración ya Nagios agrega el host al dashboard y lo chequea para avisarnos de problemas de disponibilidad.

2) Chequeos Locales (vía NRPE):

Como dijimos, para este tipo de chequeos, es necesario instalar un agente en el equipo, y en este caso para el pfSense será NRPE. Por suerte pfSense nos facilita esta tarea mediante un paquete que se instala desde la GUI como cualquier otro, por lo tanto, en primer lugar, instalaremos el paquete “NRPE v2″, desde System -> Packages.

5Una vez instalado, deberemos configurarlo, para esto vamos a Services -> NRPEv2:

6En primer lugar se habilita el servicio con el primer tilde.

Se configura el puerto donde va a escuchar el servicio, si lo cambian, recuerden armar la correcta habiitación en el firewall.

La “Bind IP”, es la IP donde queremos que el servicio responda, por ejemplo si el firewall tiene más de una interface, tendremos que elegir la ip de alguna, si tenemos el Nagios en nuestra red local, seguramente la ip será una privada, en caso de que estemos monitoreando desde Internet, la IP será una pública. Si queremos que escuche en todas las interfaces, o si tenemos una ip pública que es dinámica, podemos ingresar 0.0.0.0, que se traduce en “todas”.

“Nagios Server” es la IP de nuestro Nagios, y es una medida de seguridad adicional a la regla de firewall, que únicamente permite que se hagan consultas desde esa IP.

Luego, se configurará los plugins que se ejecutarán internamente en el equipo, y la forma de consultarlos remotamente. Por default el paquete trae algunos, pero se pueden agregar cuantos necesitemos:

3La interface anterior, lo que hace es ayudarnos en la configuración y básicamente escribirla en /usr/local/etc/nrpe.cfg

La primer columna, es el nombre que se utilizará para llamar al chequeo desde el Nagios mediante el chequeo de nrpe.

Luego figura un tilde para especificar si realiza el chequeo com root o no (sudo).

La tercer columna “command”, especifica que plugin va a ejecutar, toma los plugins de /usr/local/libexec/nagios; si tienen alguna duda sobre como funciona algún plugin, pueden ir a ese path y ejecutar cada cuno con el parametro –help. Por ejemplo:

/usr/local/libexec/nagios(9): ./check_users –help

check_users v (nagios-plugins 1.4.15)
Copyright (c) 1999 Ethan Galstad
Copyright (c) 2000-2007 Nagios Plugin Development Team
<nagiosplug-devel@lists.sourceforge.net>

This plugin checks the number of users currently logged in on the local
system and generates an error if the number exceeds the thresholds specified.

Usage:
check_users -w <users> -c <users>

Luego se configuran los parámetros de alerta de Warning y Critical y un último campo para ejecuar parámetros adicionales si el plugin lo necesita. Por ejemplo el check_disk necesita un -p para especificar el path a chequear.

Si se necesita ejecutar otro plugin adicional, se agrega con el simbolo “+”, y se especifica como ejectuarlo y como llamarlo.

Vamos a agregar un chequeo más a nuestra medida, para mostrar como hacerlo, el chequeo utilizará también el plugin “ceck_procs”, pero ejecutado de la siguiente forma:

check_procs -w 10 -c 20 –metric=CPU

Que nos alertará en caso de que cualquier proceso esté usando más de 10% del CPU (Warning) o más de 20% para critical:

4

Ahora veamos como configurarlos en Nagios:

En primer lugar, se define el comando (que ya viene definido por default en la mayoría de las instalaciones) pero vamos a ajustarlo:

define command{
 command_name    check_nrpe
 command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p $ARG1$ -c $ARG2$ -t 200
 }

Lo que hicimos es definirle que cada vez que se lo llame se ejecuta pasando como parámetro la dirección del host en -H y el primer argumento al -p (puerto) y el segundo al -c (comando) y además un timeout generoso para evitar problemas de red que lo dejamos fijo en 200 segundos. Podríamos por ejemplo haberlo definido como -t $ARG3$ para que sea definido según el servicio que ejecutemos.

En la mayoría de las instalaciones, el -p también viene fijo en 5666 (-p 5666), pero dejarlo con ARG1, nos dará mayor flexibilidad en caso de que usemos diferentes puertos por equipo.

Ahora definimos los servicios para que chequee en el pfSense que vimos arriba:

define service{
 use                 generic-service
 host_name           pfsense.empresa.com.ar
 service_description DISCO: ROOT
 check_command       check_nrpe!5666!check_root
}
define service{
 use                  generic-service
 host_name            pfsense.empresa.com.ar
 service_description  DISCO: VAR
 check_command        check_nrpe!5666!check_var
}
define service{
 use                  generic-service
 host_name            pfsense.empresa.com.ar
 service_description  CARGA
 check_command    check_nrpe!5666!check_load
}
define service{
 use                   generic-service
 host_name             pfsense.empresa.com.ar
 service_description   USUARIOS
 check_command        check_nrpe!5666!check_users
}
define service{
 use                    generic-service
 host_name              pfsense.empresa.com.ar
 service_description    PROCESOS ZOMBIES
 check_command check_nrpe!5666!check_zombie_procs
}
define service{
 use                 generic-service
 host_name           pfsense.empresa.com.ar
 service_description PROCESOS TOTALES
 check_command check_nrpe!5666!check_total_procs
}
define service{
 use                 generic-service
 host_name           pfsense.empresa.com.ar
 service_description PROCESOS CPU
 check_command check_nrpe!5666!check_cpu_procs
}

Con la configuración anterior, Nagios ya es capaz de realizar los chequeos vía NRPE:

12

2) Chequeos SNMP:

Para realizar los chequeos SNMP, en primer lugar se debe habilitar el servicio en pfSense. Para esto vamos a ir System -> SNMP:

7Se habilita el SNMP Daemon, se configura el puerto, y se setea un commuity string, que en este protocolo, es similiar a un password. Se recomienda cambiar el mismo. Luego se configura en que interface se bindea (tal cual hicimos con NRPE) y los modulos a utilizar:

8

El plugin de Nagios para realizar chequeos SNMP, es check_snmp, se puede ver su utilización ejecutando un help del mismo:

check_snmp v2.0 (nagios-plugins 2.0)
Copyright (c) 1999-2014 Nagios Plugin Development Team
<devel@nagios-plugins.org>

Check status of remote machines and obtain system information via SNMP

Usage:
check_snmp -H <ip_address> -o <OID> [-w warn_range] [-c crit_range]
[-C community] [-s string] [-r regex] [-R regexi] [-t timeout] [-e retries]
[-l label] [-u units] [-p port-number] [-d delimiter] [-D output-delimiter]
[-m miblist] [-P snmp version] [-L seclevel] [-U secname] [-a authproto]
[-A authpasswd] [-x privproto] [-X privpasswd]

Básicamente, utiliza la librería net-snmp que contiene varias utilidades para consulta del protocolo snmp. Recomiendo primero hacer ciertas pruebas con dicha librería y con los comandos snmpget y snmpwalk para ponernos a tono con el protocolo; igualmente aca vamos a ver unos ejemplos.

Realmente me ha  resultado dificil encontrar buena documentación sobre este tipos de chequeos en pfSense, pero al menos les voy a presentar algunos chequeos básicos e interesantes. Cualquier información adicional que encuentren, la pueden poner en un comentario y será agregada.

Voy a utilizar IF-MIB y SNMPv2-SMI para diferentes chequeos:

A. Utilizando IF-MIB:

En primer lugar vamos a identificar el ID númerico que asigna la MIB a las interfaces que tenemos en el equipo.

Podemos hacerlo por mac:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 IF-MIB::ifTable.ifEntry.ifPhysAddress
IF-MIB::ifPhysAddress.1 = STRING: 0:c:29:45:7:69
IF-MIB::ifPhysAddress.2 = STRING: 0:c:29:45:7:73
IF-MIB::ifPhysAddress.3 = STRING: 0:c:29:45:7:7d
IF-MIB::ifPhysAddress.4 = STRING:
IF-MIB::ifPhysAddress.5 = STRING:
IF-MIB::ifPhysAddress.6 = STRING:
IF-MIB::ifPhysAddress.7 = STRING:
IF-MIB::ifPhysAddress.8 = STRING:
IF-MIB::ifPhysAddress.9 = STRING:

O por descripción:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 IF-MIB::ifTable.ifEntry.ifDescr
IF-MIB::ifDescr.1 = STRING: em0
IF-MIB::ifDescr.2 = STRING: em1
IF-MIB::ifDescr.3 = STRING: em2
IF-MIB::ifDescr.4 = STRING: plip0
IF-MIB::ifDescr.5 = STRING: enc0
IF-MIB::ifDescr.6 = STRING: pfsync0
IF-MIB::ifDescr.7 = STRING: lo0
IF-MIB::ifDescr.8 = STRING: pflog0
IF-MIB::ifDescr.9 = STRING: ovpns1

En nuestro equipo, la em0 con su mac 0:c:29:45:7:69, es la interface a la que vamos a consultar ya que es nuestra wan. Pueden chequear dichos datos en Status –> Interfaces:

1Ahora que sabemos el id numérico para las intefaces que queramos monitorear, vamos a probar algunos comandos para obtener data:

Tráfico in:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 IF-MIB::ifTable.ifEntry.ifInOctets.1
IF-MIB::ifInOctets.1 = Counter32: 110114086

Tráfico Out:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 IF-MIB::ifTable.ifEntry.ifOutOctets.1
IF-MIB::ifOutOctets.1 = Counter32: 84756753

Estado de la Interface:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 IF-MIB::ifTable.ifEntry.ifAdminStatus.1
IF-MIB::ifAdminStatus.1 = INTEGER: up(1)

B. Utilizando SNMPv2-SMI

Nuevamente identificamos las interfaces con esta tabla:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.1 = STRING: “all
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.2 = STRING: “carp
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.3 = STRING: “em0
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.4 = STRING: “em1
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.5 = STRING: “em2
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.6 = STRING: “enc
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.7 = STRING: “enc0
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.8 = STRING: “lo
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.9 = STRING: “lo0
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.10 = STRING: “openvpn
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.11 = STRING: “ovpns1
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.12 = STRING: “pflog
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.13 = STRING: “pflog0
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.14 = STRING: “pfsync
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.15 = STRING: “pfsync0
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.16 = STRING: “plip0
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.17 = STRING: “tun

La que nos interesa a nosotros es la “em0” o sea el ID 3, y podemos consultar:

Paquetes bloqueados:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.12.3
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.12.3 = Counter64: 19202

Paquetes Aceptados:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.11.3
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.12.3 = Counter64: 19208

 

Hay muchos otros datos estadísticos que podemos consultar, recomiendo hacer un snmpwalk más amplio para ver todos los disponibles:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1

Ahora solo falta crear la configuración en Nagios para que levante dichos chequeos:

En primer lugar definimos el comando (generalmente creado en la instalación default), pero lo vamos a mejorar un poco:

define command{
 command_name    check_snmp
 command_line    $USER1$/check_snmp -H $HOSTADDRESS$ -C $ARG1$ -o $ARG2$ -w $ARG3$ -c $ARG4$
}

Por lo tanto, el primer argumento será la community, el segundo el OID, el tercero el valor del warning y el último el valor del critical.

Creamos los servicios:

define service{
 use                   generic-service
 host_name             pfsense.empresa.com.ar
 service_description   TRAFICO IN - WAN
 check_command        check_snmp!p4ssw0rdSNMP!IF-MIB::ifTable.ifEntry.ifInOctets.1!150000000!140000000
}
define service{
 use                   generic-service
 host_name             pfsense.empresa.com.ar
 service_description   TRAFICO OUT - WAN
 check_command        check_snmp!p4ssw0rdSNMP!IF-MIB::ifTable.ifEntry.ifOutOctets.1!150000000!140000000
}
define service{
 use                  generic-service
 host_name            pfsense.empresa.com.ar
 service_description  INTERFACE STATUS - WAN
 check_command        check_snmp!p4ssw0rdSNMP!IF-MIB::ifTable.ifEntry.ifAdminStatus.1!1!1
}
define service{
 use                  generic-service
 host_name            pfsense.empresa.com.ar
 service_description  PAQUETES BLOQUEADOS - WAN
 check_command    check_snmp!p4ssw0rdSNMP!SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.12.3!100000!90000
}
define service{
 use                    generic-service
 host_name              pfsense.empresa.com.ar
 service_description    PAQUETES ACEPTADOS - WAN
 check_command    check_snmp!p4ssw0rdSNMP!SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.11.3!100000!90000
}

Listo. Servicios Creados.

10

Espero te haya sido util.

Sugerencias bienvenidas.

Autor: Gabriel Soltz

Funcionalidad NAT/BINAT (Network Overlapping) para IPSEC en pfSense

Versión pfSense: 2.1

A partir de la versión 2.1, pfSense estrenó una nueva funcionalidad muy solicitada por los usuarios de la comunidad, que permite el nateo en origen de las redes presentadas en el dominio de encripción de las VPN IPsec.

Esta funcionalidad resuelve algunos issues con respecto al solapamiento (OverLapping) de redes en VPN IPsec, cuando se quieren vincular dos redes que utilizan la misma numeración, lo que generaría problemas de ruteo.

Para aclarar algunas dudas con respecto al funcionamiento de este feature, es importante señalar que el mismo, lo que permite es presentar la red al peer remoto, con otra numeración; pero no permite el nateo de una red que recibamos de otro peer. Entonces, si nuestra red es 192.168.0.0/24, al igual que la del otro extremo, lo que podemos hacer es presentar la red al peer remoto con el segmento que queramos, por ejempo 10.0.0.0/24, entonces en el otro extremo, para acceder al host 192.168.0.24, deberá hacerlo al host 10.0.0.24.

Hay ciertos vendors (como Cisco) que mejoran aún más esta funcionalidad y permiten que aunque el otro extremo no nos mande la red nateada, podamos hacerlo al recibirla; esta funcionalidad aún no está soportada en pfSense.

Igualmente es más que interesante aprovechar estas configuración, para poder hacer funcionar una VPN donde las numeraciónes se superpongan y no sea posible un readdressing.

Escenarios Válidos:

- Nuestra Red es 192.168.0.0/24 y queremos conectar con 2 clientes que tienen la misma numeración en los que tenemos instalados pfSense. Podemos configurar los dos pfSense de los clientes para que nos presenten las redes vía IPSEC con numeraciones diferentes por ejemplo 192.168.1.0/24 y 190.168.2.0/24. Desde nuestra Red accederemos a dichos clientes utilizando la numeración nateada, y si queremos que los clientes accedan a nuestra red, presentaremos nuestro segmento también nateado.

- Queremos que un cliente acceda a nuestra Red que es 192.168.0.0/24, pero el tiene el mismo segmento de red configurado en su lado; sin embargo no tenemos control de su firewall. Podemos presentar nuestra red nateada a otro segmento e indicar que pueden acceder utilizando dicho segmento. Nosotros no podremos acceder a su red.

Escenarios NO Validos:

- Queremos acceder a la Red de un cliente que tiene nuestra misma numeración, sin embargo no podemos solicitarle que nos natee su Red (porque no sabe hacerlo, o porque su firewall no lo soporta), y claro, no tenemos gestión de su Terminador de Túneles. En este caso, la funcionalidad de pfSense nos permitirá enlazar la VPN, pero no tendremos acceso desde nuestra Red a sus hosts, ya que sus hosts tiene la misma numeración que los nuestros. Sin embargo, ellos si podrán acceder a nuestros hosts utilizando la numeración que definimos en la configuración de NAT/BINAT en el sentido contrario.

Configuración de pfSense para NAT/BINAT:

Vamos a mostrar un escenario en el que queremos configurar una VPN entre dos pfSense, los cuales cada uno tienen una interface LAN con la red 192.168.0.0/24 (misma red en ambos extremos), y su otra interface WAN donde manejan el addressing público.

RED1 <- PFSENSE1  <– WAN –> PFSENSE2 -> RED2

RED 1 y RED 2 originalmente son 192.168.0.0/24.

Las redes Nateadas serán:

RED 1 –> 172.16.1.0/24

RED 2 –> 172.16.2.0/24

Este escenario sería el que mayor configuración en ambos extremos requiere, ya que deberemos natear ambos para que funcione, en casos más sencillos donde sólo haya que natear un sólo extremo (porque el acceso que necesitamos es únicamente de un lado hacia el otro) esta configuración también servirá, configurando sólo el extremo necesario.

1. Configuración en PFSENSE1

En el Menú de VPN, vamos a IPSec, y luego al simbolito + para agregar un tunel.

En primer lugar se setean lo parámetros de la FASE 1.

Configuramos la interface outside del pfsense para levantar la VPN (la que mira a internet) y el peer remoto (ip pública o url) y si queremos una descripción:

1

Luego siguen las opciones de Autenticación de Fase 1. Esta configuración debe ser igual en ambos extremos, no ahondaremos en este post sobre las más seguras o más eficientes configuraciones, simplemente recordar que deben ser exactamente iguales para que funcione:

2

Y por último las opciones avanzandas según nuestras necesidades. Para conectar 2 pfSense, la siguiente configuración es óptima y es recomendable que también sea igual en ambos extremos:

3

En la configuración de la FASE 2, es donde se configuran los parámetros de numeración y correspondiente NAT/BINAT:

Para hacerlas, una vez creada la Fase 1, expandimos las configuraciones de Fase 2 y vamos al + correspondiente:

45

La primer parte de la configuración es la más relevante y es donde se configura el dominio de encripción, el nateo y la red remota.

A Saber:

Local Network –> Es la red que vamos a tunelizar, la red real, que queremos que el otro extremo tenga acceso. En nuestro caso es la RED1 (192.168.0.0/24).

Podríamos tener más de una red configuradas en nuestro firewall (más de una interface), por lo que debemos elegir la que nos interese encapsular, o podríamos presentar únicamente una parte de nuestra red, por ejemplo una única /25 de nuestra /24, o únicamente 1 host. Podemos escribir la red en formato Network, en formato Host, o seleccionar la subnet correspondiente a la Interface que vamos a configurar. En este caso vamos a Seleccionar “LAN Subnet” ya que así se llama en nuestro pfSense, que sería el equivalente a escribir 192.168.0.0/24. Es lo mismo escribirla a mano o seleccionarla con el nombre de la interface, pero para mi gusto queda más prolijo y claro seleccionarla.

In case you need NAT/BINAT on this network specify the address to be translated –>  Esta configuración hace el Nateo en origen. La red anteriormente especficada (192.168.0.0/24), se presentará al otro Peer como la que definamos aca.

Es importante que si en Local Network escribimos un host, aca escribamos otro host, y si lo escribimos una red, la que setiemos acá sea del mismo tamaño ya que sino habrá problemas. (salvo que queramos presentar toda una red como un sólo host, pero esto no permitirá la comunicación bidireccional, y no es a lo que apuntamos en este post.). Por lo tanto, en este parámetro, setearemos otra red el mismo tamaño (/24), que en este caso será 172.16.1.0/24.

Remote Network –> Acá especificaremos la red que nos está presentando el otro extremo. En nuestro escenario, la red remota es 192.168.0.0/24; sin embargo, como en PFSENSE2 la vamos a presentar nateada también, la que vamos a configurar aca, es la red Nateada que en este caso es 172.16.2.0/24.

Estas 3 configuraciones son los que harán funcionar la VPN de manera correcta. En el caso de que estemos configurando una VPN sin NAT/BINAT, el segundo parámetro no lo configuraremos, y en Remote Network, configuraremos la Red Original, que no deberá solaparse con nuestra Red.

6

Siguen las opciones de Seguridad (SA/Key Exchange). Lo único que diremos en este Post es que deben ser exactamente iguales en cada uno de los extremos.  La opción de ping host, si la necesitamos, mantiene la VPN activa aunque no haya tráfico, pingeando un host específico automáticamente que debe ser accesible por el túnel:

7

2. Configuración en PFSENSE2

PFSENSE2 se debe configurar en el otro extremo de igual manera en cuanto a Fase 1 (con el peer remoto como la WAN de PFSENSE1) y Fase 2 con las opciones de Red invertidas para que la VPN levante de manera correcta.

Local Network: 192.168.0.0/24

NAT/BINAT: 172.16.2.0/24

Remote Network: 172.16.1.0/24

Una vez establecida la VPN, se podrá acceder desde la RED1 a la RED2 mediante la Red Nateada 172.16.1.0/24 y viceversa, de la RED2 a la RED1 mediante la Red Nateada 172.16.2.0/24. Esta configuración permite el diálogo bidireccional sin ningún problema.

El nateo de RED a RED, es correlativo, entonces, por ejemplo, los hosts serán:

192.168.0.1 > 172.16.1.1

192.168.0.2 > 172.16.1.2

192.168.0.3 > 172.16.1.3

192.168.0.4 > 172.16.1.4

etc…

Recordar que es necesario además la configuración de los permisos (ACLS) correspondientes para permitir el paso del tráfico que requiramos, o sea, se debe configurar en Firewall -> Rules -> IPSec, las reglas que queramos (o un any), siempre recordando que dicha configuración se aplica en la interface de origen, por lo tanto en PFSENSE1 configuraremos reglas con origen 192.168.0.0/24 y destino 172.16.1.0/24, y en PFSENSE2, reglas con origen 192.168.0.0/24 y destino 172.16.2.0/24.

Espero te haya sido util.

Gabriel Soltz

Liberada la versión 2.1 de pfSense

Ayer 15/9/2013 fue liberada la versión 2.1 de pfSense para todas las plataformas. Nosotros veníamos probándola hace un tiempo, y la ansiedad de poder aprovechar las nuevas funcionalidades y mejoras era cada vez mayor.

La actualización desde la rama 2.0.x es muy simple y en ningún momento nos topamos con problemas, ni siquiera con el inconveniente con las open-vm-tools. Fue tan fácil como “Click Here to view update.” -> “Invoke auto-update” y listo. Descarga, actualiza, reinicia, reinstala los packages, y queda andando. Todo con un mínimo corte de servicio.

Las mejoras y las nuevas funcionalidades son muchas, y algunas esperadas con ansias.

Comenzando por el sistema operativo base, la versión 2.1 está basada en FreeBSD 8.3 p13(recordemos que la versión anterior corría sobre 8.1). Esto permite subsanar al menos 3 vulnerabilidades que se hallaban en versiones anteriores del sistema operativo:

  • Desbordamiento de enteros en implementación de multicast permitía elevar privilegios — CVE-2013-3077 — http://www.freebsd.org/security/advisories/FreeBSD-SA-13:09.ip_multicast.asc
  • Chequeo de credenciales insuficiente en ioctl permitiría denegación de servicio y ejecución de código arbitrario — http://www.freebsd.org/security/advisories/FreeBSD-SA-13:12.ifioctl.asc
  • Debilidad en implementación de nullfs podría permitir modificación de archivos de solo lectura — http://www.freebsd.org/security/advisories/FreeBSD-SA-13:13.nullfs.asc

Para intentar explotar estas vulnerabilidades se requería previamente acceso válido al sistema, al igual que otras vulnerabilidades anteriores, lo que reducía mucho el riesgo de ser explotadas.

 

Mejoras

La lista completa de cambios está en esta página del sitio de pfsense, pero vamos a citar sólo algunos:

  • Soporte de IPv6 para todas (o casi todas) las funcionalidades
  • Mejoras varias en la interfaz GUI
  • Múltiples portales cautivos
  • Soporte de sensores de temperatura a través de ACPI, coretemp, y amdtemp; agregado además a lista de widgets de la portada.
  • Failover multiwan de DynDNS, IPsec y OpenVPN
  • NAT antes de IPsec (1:1 o muchos:1) -> esto no lo probamos aun, pero permite manejar y acceder a redes remotas cuyos rangos de direccionamiento IP se solapan 8-)
  • OpenVPN puede aceptar atributos desde un servidor RADIUS, tales como in-acl, out-acl, servidor DNS y rutas
  • Privilegio nuevo de sólo lectura para poder asignar permisos a un usuario que no deba modificar config.xml
  • Múltiples mejoras en el logging: separación de logs de cada servicio, filtrado avanzado de logs de reglas de firewall, posibilidad de visualizar la descripción de la regla impactada, y la posibilidad de deshabilitar los logs correspondientes al tráfico generado mediante la propia administración web ;-)
  • Corrección del problema de update automático de 25 días de DynDNS y la posibilidad de establecer un intervalo de actualización. Además se agregó soporte para la versión gratuita de NO-IP y para otros proveedores. Adicionalmente, se puede habilitar el logging detallado para determinar y resolver problemas.
  • Posibilidad de capturar tráfico sin habilitar el modo promiscuo en la interfaz de red
  • Ahora el filtrado permite expresiones regulares, por ejemplo para los logs y para las ruta.
  • Se incorporaron algunos Scripts nuevos para administración vía línea de comandos (como reiniciar servicios e instalar paquetes)
  • Más módulos SNMP para monitorear
  • Pooles (rangos) DHCP adicionales al principal.
  • Mapeo estático DHCP (mac address <-> IP) ahora permite propiedades personalizadass para cada caso, por ejemplo para una mac-address determinada, además de la IP que se le asignará se le puede definir qué puerta de enlace debe usar, qué servidores DNS, etc.
  • Muchas otras mejoras y correcciones de bugs.

Todas estas mejoras no serían tanto si no fuera porque el producto es igual o más estable y performante que lo que estamos acostumbrados.

Los links de descarga son:

  • para nuevas instalaciones: http://www.pfsense.org/mirror.php?section=downloads
  • para actualizaciones http://www.pfsense.org/mirror.php?section=updates – aunque recomendamos actualizar mediante “auto update” (menú System > Firmware > Auto update)

Leonardo Brugues
@lbrug

Libros Publicados Sobre pfSense

¿ Buscabas un libro sobre pfSense ?

Los siguientes son los 2 libros publicados a la fecha. Si bien los mismos son fácilmente descargables de la red, su contenido es propietario por lo que dejo sus links para comprarlos.

 

   

pfSense 2 Cookbook

A practical, example-driven guide to configure even the most advanced features of pfSense 2

Versión en que se basa: pfSense 2.0-BETA5

Autor: Matt Williamson

Año: 2011

Link: http://www.packtpub.com/pfsense-2-cookbook/book

 

pfSense: The Definitive Guide

The Definitive Guide to the pfSense Open Source Firewall and Router Distribution

Versión en que se basa: pfSense 1.2.3

Autores: Christopher M. Buechler (co-fundador de pfSense) y Jim Pingle (consultor de pfSense)

Año: 2009

Link: http://www.amazon.com/pfSense-Definitive-Christopher-M-Buechler/dp/0979034280

 

¿ Conocés algún otro ?

Compartilo !

 

 

Autor: Gabriel Soltz

 

SI TE GUSTÓ ESTE ARTÍCULO,

HACÉNOSLO SABER CON UNA DONACIÓN A LA SIGUIENTE DIRECCIÓN BITCOIN:

[btcpayments address="1LTixtMfXWX8r6gczaKZL68xkh6cudBQGf"]

Implementación de VPN Cliente-Servidor con OpenVPN y pfSense

Versión pfSense: 2.0.3
Módulos:
OpenVPN Client Export Utility 1.0.11

En el siguiente artículo se explica la implementación de la función de terminación de túneles Cliente-Servidor con OpenVPN y pfsense, cuya funcionalidad es implementada nativamente en las actuales versiones.

OpenVPN fué creado en 2001, y actualmente es el estandar a nivel seguridad y performance habiendo desplazado a protocolos como PPTP y L2TP que demostraron ser vulnerables y no tan rápidos.

En los siguientes links puedes encontrar comparativas entre OpenVPN, L2TP y PPTP: link1 y link2

OpenVPN es actualmente compatible con todos los sistemas operativos.

Autenticación:

OpenVPN implementa SSL/TLS mediantes certificados RSA que se considera mucho más seguro que la utilización de claves precompartidas. Es posible también la implementación de OpenVPN en conjunto con LDAP o Radius para el manejo de usuarios y permisos, pero en este tutorial se utilizará la autenticación Local en el pfSense. Vamos a necesitar:

- Certificado Raiz, utilizado para generar los certificados clientes, en nuestro caso generaremos uno propio, por lo tanto seremos nuestra propia entidad certificadora, sin embargo también se podría utilizar una CA externa. [OpenVPN-CA]

- Certificado Cliente para el pfSense, que únicamente deberá estar en el pfSene. [OpenVPN-Servidor]

- Certificados Clientes para usuarios, es necesario un certificado para cada usuario que daremos acceso. [OpenVPN-Gabriel]

Clientes:

Mediante el paquete “OpenVPN Client Export Utility” es posible generar paquetes instaladores para cada usuario desde el pfSense que configuraran las pc clientes de manera muy sencilla: básicamente el paquete está conformado por el instalador de openvpn, el archivo de configuración con los datos de la vpn y los certificados necesarios para conectarse al servidor. Sin embargo, el plugin no siempre mantiene las últimas versiones de los instaladores; si se va a utilizar es recomendable chequear que no estén defasadas las versiones.

Para evitar este problema, en nuestro caso utilizamos el plugin únicamente para generar el zip con la configuración para cada usuario (certificados + archivo de configuración), que simplemente hay que copiar en la carpeta de configuración del cliente para funcionar.

Servidor:

Es posible configurar más de un servidor de OpenVPN en un mismo pfSense con diferentes configuraciones (por ejemplo diferentes métodos de autenticación, diferente configuración de puertos, diferentes redes a las que dará acceso, etc).

Topología:

Nuestro pfSense cuenta con 3 Interfaces: WAN (numeración pública), LAN (segmento de usuarios en la red) y DMZ (segmento de servidores en la red). La configuración que crearemos dará acceso a la red LAN (192.168.1.0/24).

Resumen:

Los pasos para esta implementación son:

1. Creación de Certificado Raiz (CA)

2. Creación de Certificado Servidor

3. Configuración del Servidor

4. Creación de Usuario + Certificado

5. Instalación de Cliente

Implementación:

Utilizaremos el Wizard propio de pfSense que simplifica el paso 1, 2 y 3. Para comenzar vamos al menú VPN, luego OpenVPN y por último a la solapa Wizards, que nos abrirá el asistente de configuración.

1. Seleccionamos el tipo de Servidor, que en nuestro caso será Local User Access, ya que los usuarios los crearemos y manejaremos mediante el pfSense. Como explicamos antes, también es posible configurarlo con un servidor LDAP o Radius. Next.

2. El próximo paso será la configuración del Certificado Raiz (la entidad certificadora).Este certificado será utilizado para luego crear el certificado del servidor y los certificados de usuarios.

Si ya existen CAs cargados en el pfSense el asistente nos dejará seleccionar uno (los mismos se pueden crear desde el menú System –> Cert Manager) o también crear uno nuevo; y en caso de no existir ninguno como en el nuestro, directamente nos llevará a la creación de uno:

Completar la información requerida respecto a la organización, el Key Lenght recomiendo utilizar 2048 ya que es optimizado entre seguro y performante, y el Lifetime es el tiempo de validez. Add new CA.

3. Ahora es necesario crear el certificado para el servidor, que será creado en base a la entidad certificadora creada en el paso anterior.

Si ya existieran certificados creados podríamos simplemente seleccionar uno, en nuestro caso, nos llevará directo a la creación de uno. La mayoría de los datos ya estarán completos basados en los datos de la CA. Faltaría completar el nombre y un correo.

Con los datos completos le damos click a Create new Certificate.

4. A cotinuación el asistente nos lleva a la configuración del Servidor, que se divide en 4 grupos:

General OpenVPN Server Information:

Contiene la configuración de la interface que atenderá las conexiones (en nuestro caso llegarán desde internet a la interface wan), el puerto y el protocolo que utilizaremos, en nuestro caso los default (en caso de cambiarlos, será necesario también cambiarlos en los clientes). No está demás aclarar, que si quisieramos agregar otro Servidor VPN (algo así como otra instancia de OpenVPN), tendremos que elegir otro puerto.

También será necesario una regla de firewall que permita las conexiones entrantes a ese puerto y procolo en la interface WAN, que crearemos luego.

Cryptographic Settings:

La configuración criptográfica que utilizaremos es la default, ya que nuevamente consideramos que brinda un buen nivel de seguridad y de performance.

Tunnel Settings:

Aquí setearemos la configuración propia del tunel, esta configuración es importante.

Tunnel Network, será la red que crearemos para los clientes que se conecten. Por lo tanto, con esta configuración estamos definiendo el rango de numeración que se le asginarán a los clientes al conectarse y también la ip de la interface virtual que será la primera de dicha red. Se deberá utilizar una red que no esté ya utilizada para evitar problemas de ruteo. En nuestro caso utilizaremos 10.0.1.0/24 (entonces, la interfaz virtual que se creará tendrá la 10.0.1.1 y los clientes que se conecten tendrán una dirección asignada entre la 10.0.1.2 y la 10.0.1.254).

Local Network, define la red a la que daremos acceso y que por ende, será ruteada en los clientes a través de la vpn. En nuestro caso, tal cual los descripto en el apartado Topología, configuraremos la red 192.168.1.0/24.

También se puede utilizar la opción Redirect Gateway, que lo que hará básicamente es rutear todo el tráfico del cliente por la VPN, esto hará que todas las conexiones que se generen se envien al tunel, incluso por ejemplo las peticiones a numeración pública (navegación web por ejemplo), entonces utilizará la salida del pfSense también para navegar. A veces se utiliza este método para dar un mayor nivel de seguridad a la red, evitando que el usuario “puentee” su salida a internet con la red a la que se está conectando saltéandose las restricciones que por ejemplo puedan estar configuradas en el proxy de navegación web. Nosotros no utilizaremos está opción para evitar que se utilice nuestra salida a internet para navegar u otros, y que el usuario únicamente nos envíe el tráfico destinado a nuestra red.

Podemos agregar un límite de conexiones concurrentes como medida de seguridad adicional o para asegurar la performance del equipo (cuanto más usuarios conectados, mayor uso de procesador).

También habilitaremos la compresión que hace mucho más performante la conexión.

Client Settings:

Por último las configuraciones que afectarán a los clientes que se conecten. Setearemos la opción Adress Pool, que afirma la configuración del Tunnel Network, o sea, hahbilita a que los clientes reciban una ip de la red definida (10.0.1.0/24). Si no caerían con su numeración pública, y esto es algo que no queremos porque perdemos control, por ejemplo a nivel acls.

Además setearemos el servidor dns, que en nuestro caso es el propio pfSense, para que el cliente pueda resolver nombres internos.

No necesitamos setear nada más, por lo que damos  a la opción Next.

5. El próximo paso nos permite agregar automáticamente la regla que permite el tráfico desde internet al puerto y protocolo configurado en el paso anterior.

Además nos permite agregar o no, una regla en la nueva interface que creará el pfSense, la 10.0.1.0/24, donde caerán los usuarios conectados, si seleccionamos esta opción, la regla que se creará sera de origen ANY, destino ANY, y puerto y protocolo también ANY. Ya que nosotros no quremos dar acceso a los usuarios que se conecten a la red DMZ y sólamente a la red LAN, no seleccionaremos esta opción y crearemos la regla a mano. Pueden seleccionar esta opción si no desean aplicar restricciones.

Cuando le demos Next, el asistente finaliza e indica que fué configurado el servidor correctamente.

6. Si ahora vamos al menú Firewall, y luego a Rules, veremos que se ha agregado la regla en la interface WAN, que permite todas las conexiones al puerto UDP/1194 y además que se ha creado una nueva solapa OpenVPN, donde manejaremos las reglas asociadas a todos los servidores OpenVPN:

Cuando vayamos a la solapa OpenVPN, estará vacía sin ninguna regla, pero en caso de que hayan seleccionado la opción que crea la regla automáticamente, aparecerá una regla permitiendo todo el tráfico. Nosotros creamos la regla a mano y quedará de la siguiente forma:

 

Usuarios:

Ahora crearemos un usuario habilitad0 para conectarse, en nuestro caso también generaremos un grupo OpenVPN, para incluir en el a este usuario y a todos los que creemos para conectarse a la VPN. Esto sirve para que administrativamente sepamos que usuarios tienen acceso a la VPN, además de poder asginar permisos de pfSense a todos los usuarios a la vez, por ejemplo para permitir el acceso a algún módulo de pfSense como el de cambio de Password.

1. Vamos al menú System, User Manager y luego a la solapa Groups. Allí buscamos el ícono de agregar (+) y creamos el grupo:

Le damos Save para crear.

2. Para crear un usuario, volvemos a la solapa Users, y nuevamente vamos al ícono de agregar (+):

Configuraremos las opciones básicas como el nombre de usuario, el nombre completo, la contraseña, la asociación al grupo que creamos antes, y en nuestro caso también seteamos una fecha de expiración que será a fin de año.

Seleccionamos la opción de crear certificado, y nos expanderá más opciones:

Debemos poenerle un nombre al certificado y elegir la entidad certificadora que creamos anteriormente.

Le damos Save y nos creará el usuario y su certificado automáticamente.

Podemos ir luego al menú System, a la opción Cert Manager para comprobarlo.

En la solapa CA, veremos la entidad certificadora que creamos:

Y en la solapa Certificates veremos el certificado del Servidor que creamos anteriormente, y el certificado del usuario gabriel que acabamos de crear. (También veran un certificado default que es que se utilizan al conectarse vía HTTPS al WebConfiurator).

 

Clientes:

El servidor ya se encuentra configurado y el usuario creado, ahora nos toca configurar el cliente que se conectará con el usuario gabriel.

Para esto es necesario instalar el cliente OpenVPN en el o los equipos que se conectarán y luego cargarle la configuración del servidor y la del usuario.

Para ayudarnos en la configuración de los clientes, instalaremos también el paquete “OpenVPN Client Export Utility” que nos permite exportar los zips de configuración para cada usuario de manera muy sencilla.

Por lo tanto, en primer lugar, instalemos el paquete desde el menú System, opción Packages y luego la solapa Available Packages. Buscamos el paquete y le damos al ícono de agregar (+).

Una vez instalado, se agrega en el apartado de OpenVPN (menú VPN, opción OpenVPN), una nueva solapa Client Export:

Si hicimos todo bien, en la parte de abajo de la página, veran un apartado con los nombres de usuario que están asociados al certificado de la VPN y de donde podremos exportar los clientes para cada sistema operativo, o la “Standard Configuration” que nos da un zip con el archivo de configuración de openvpn (*.opvn) y los certificados del usuario para permitir la conexión, este zip debe incorporarse a la carpeta de configuración del cliente OpenVPN de la pc que va a realizar la configuración y con esto ya se podrá conectar.

Veremos algunos ejemplos de configuración de clientes:

Instalación de Cliente OpenVPN en Windows

Existen dos clientes OpenVPN para Windows, el oficial (http://openvpn.net) y un Cliente llamado OpenVPN Manager (https://github.com/jochenwierum/openvpn-manager/), este segundo cliente, soluciona un problema conocido cuando el usuario no tiene permisos de administrador en la PC con la que se quiere conectar al servidor. Para funcionar la conexión, el cliente a conectar debe poder agregar ruteos (como ya explicamos en la configuración del Servidor) para conocer la red a la que se quiere acceder a través del tunel que se levantó. Sin permisos de administrador, no es posible realizar esa configuración, y OpenVPN Manager soluciona esta limitación mediante la creación de un servicio específico que se encarga de dicha configuración.

En caso de no contar con permisos de administrador, se debe utilizar ese cliente que se descarga acá (http://openvpn.jowisoftware.de/downloads/), y además, antes de exportar la configuración, se debe tildar la opción Management Interface OpenVPNManager, que adapta la configuración para este cliente:

En nuestro caso, tenemos permisos de administrador en el equipo Windows que se conectará por lo que no utilizaremos la anterior opción, y aprovecharemos el cliente original de OpenVPN, que realmente es un poco más performante que el OpenVPN Manager, y además, se actualiza con mayor periodicidad.

1. Descargamos el Cliente OpenVPN desde el sitio oficial http://openvpn.net/index.php/open-source/downloads.html. Tenemos disponible la versión de 32 o 64 bit, según corresponda. Descargamos la necesaria.

2. Realizar la instalación. La misma instalará una nueva interface, por lo tanto será necesario permisos de administrador para hacerlo, que  solicitará durante el proceso.

3. Finalizada la instalación, hay que ir al PATH de instalación y a la carpeta Config, en nuestro caso es C:Program FilesOpenVPNconfig, allí copiamos los archivos de configuración y certificados que descargamos con el OpenVPN Client Export Utility.

Con esto ya es suficiente para conectarse a la VPN creada.

4. Ejecutamos el cliente OpenVPN GUI, que se abrirá y se mantendrá minimizado en la barra del reloj. Al hacer click con el boton derecho sobre el mismo, tendremos la opción Connect (en caso de que tengamos más de una configuración VPN, veremos todas las disponibles con su respectiva opción Conect).

Hacemos click en la opción Conect para conectarnos.

La conexión se establece y vemos que nos asigna una ip del rango que habíamos configurado en la configuración del Servidor:

Si revisamos como quedó la tabla de ruteo en la PC conectada, veremos que se ha agregado la ruta a la red 192.168.1.0/24 por la interface de VPN:

 

Autor: Gabriel Soltz

 

SI TE GUSTÓ ESTE ARTÍCULO,

HACÉNOSLO SABER CON UNA DONACIÓN A LA SIGUIENTE DIRECCIÓN BITCOIN:

[btcpayments address="1AtS1DY6kRZ6zhUSkB48AxsgqQTyhpfFQg"]

Incio

Bienvenido !

Estamos creando la primer comunidad de pfsense en Latinoamérica.

El objetivo de este sitio será la promoción del uso de herramientas libres en todo latinoamérica mediante la producción de contenido de investigación que permita a los usuarios aprender a reemplazar tecnologías pagas como Cisco, Fortinet y Checkpoint, con tecnologías de código abierto y gratuitas.

Nos enfocaremos en producir material a la comunidad gratuito y de calidad, que permita la implementación de infraestructuras de alta seguridad y disponibilidad, sin dependencia de proveedores caros como actualmente se está acostumbrado.

Tenemos extensa experiencia en la implementación de este tipo de soluciones en pequeñas, medianas y grandes empresas, obteniendo excelentes resultados, que les permitirieron alcanzar altos estandares de seguridad avalados por certificaciones como 27002, SOX, PCI, HIPPA entre otras, ahorrándose los costos conocidos de proveedores de tecnologías propietarias.

Si querés conocer más sobre los autores de este blog, consulta la sección Autores.

Esperamos que este sitio sea de tu utilidad y consulta frecuente.

Si te interesa participar contactate.