Appliances de seguridad perimetral (II)

En el artículo anterior, Appliances de seguridad perimetral (I), se presentaron las características globales que debe presentar una solución de seguridad encargada de proteger los distintos segmentos de una red.

Para este tipo de dispositivos existen múltiples modelos hardware y software (comercializados por distintas entidades), algunos de ellos gratuitos y otros con un coste económico asociado.

Un modelo hardware suele ser por ejemplo una solución que incorpora tanto el appliance (máquina física) como el software preparado y optimizado para dicha plataforma. Existen varios fabricantes que ofrecen soluciones de esta índole en función de distintos parámetros, como por ejemplo el número de conexiones que deberá soportar la arquitectura que se quiere proteger, los niveles de seguridad que se desean contratar, etc. Los principales fabricantes que comercializan este tipo de tecnología son:

• Fortinet (http://www.fortinet.com/)


• Astaro (http://www.astaro.com/)


• Symantec (http://www.symantec.com/)


• McAfee (http://www.mcafee.com/)


• Panda Security (http://www.pandasecurity.com/)

Un modelo software es una solución que aporta el programa o aplicaciones necesarias capaces de conformar una arquitectura All-In-One, y en este caso deberá ser el usuario final el que decida la plataforma hardware sobre la que se instalará. También se suelen ofrecer muchas veces como imágenes virtuales que podrán ser transportadas y levantadas en cualquier lugar independientemente del hardware subyacente.

Por lo general, la mayoría de estos productos son gratuitos y basados en sistemas Linux, y lo que habitualmente se comercializa es el soporte técnico o la posibilidad de adecuarlos a un hardware determinado. Decir también que las características ofertadas para esta clase de soluciones suelen ser bastantes inferiores a las ofrecidas por las empresas profesionales dedicadas exclusivamente a esta clase de tecnologías, pero en determinadas infraestructuras pueden llegar a ser una solución totalmente válida.

A continuación se exponen los principales productos de seguridad software ofrecidos a través de una licencia GPL (gratuitos):

• Untangle (http://www.untangle.com/)


• ClarkConnect (http://www.clarkconnect.com/)


• Endian Firewall (http://www.endian.com/)


• eBox (http://ebox-platform.com/)

Appliances de seguridad perimetral (I)

En la mayoría de las corporaciones, el único elemento de protección existente entre la red insegura (Internet) y las redes internas es un firewall como por ejemplo iptables, el cual filtra exclusivamente paquetes a nivel de red. Este dispositivo abrirá los puertos a los cuales haya que permitir su acceso y cerrará el resto.

Es un error muy grave el hecho de delegar a los puntos finales de la infraestructura (servidores, equipos de los usuarios, etc.) la seguridad de los servicios implicados. En cualquier caso, estas medidas internas deberían ser siempre el segundo elemento de protección encargado de frenar cualquier amenaza que hubiese conseguido atravesar la primera barrera: el punto de entrada a la red local a través del sistema de seguridad frontal.

Lo habitual es situar siempre como primer muro de protección a nuestra red, un elemento capaz de eliminar o atenuar la mayoría de dichas amenazas.

Estos dispositivos se conocen también como sistemas All-In-One o appliances de seguridad perimetral, y se denominan de esta forma porque son capaces de integrar en una única máquina todas las funcionalidades necesarias para salvaguardar la seguridad del perímetro. Por lo general, estamos ante sistemas que suelen ofrecer las siguientes características globales:

• Firewall: previene accesos no autorizados hacia o desde una red privada, filtrando tanto a nivel de red como a nivel de aplicación. Todo el tráfico que entra o sale de la LAN pasa a través del firewall, el cual examina cada paquete y bloquea aquellos que no cumplen unos determinados umbrales de seguridad.


• Servidor VPN: permite establecer redes privadas virtuales entre dos o más equipos conectados a través de una red insegura. Los usuarios se pueden conectar directamente entre ellos o a sus respectivas redes corporativas, estableciendo para ello túneles por los que la información viajará de forma segura (cifrada). Otra de las ventajas de las VPNs es que son más económicas que los enlaces dedicados, ya que son construidas sobre enlaces públicos compartidos, como por ejemplo Internet.


• Sistema de Protección de Intrusos (IPS): inspecciona toda la actividad entrante y saliente de la red, identificando patrones sospechosos que puedan indicar la existencia de un posible intento de ataque. Ante estas situaciones, el sistema tiene la capacidad de bloquear dichos ataques (IPS – Intrusion Prevention System) o simplemente dejar constancia de ellos a través de registros o alertas (IDS – Intrusion Detection System).


• Anti-malware: protección frente a virus, jokes, dialers, phishing, etc. Estos sistemas incorporan un motor antivirus capaz de interceptar todo tipo de malware en base a un fichero de firmas, el cual debe de ser actualizado periódicamente.


• Anti-spam: protección frente a correos spam. Estos sistemas incorporan un motor anti-spam capaz de clasificar los correos electrónicos en base a su contenido. Suelen emplear diferentes tipos de técnicas de detección, como por ejemplo la actualización periódica de una base de datos con las catalogaciones de spam, listas RBL (Real-time Blackhole List), etc.


• Filtrado web: restricción de aquellas páginas no permitidas.


• Filtrado de contenidos: protección frente a aquellos contenidos que se consideran indebidos o peligrosos, como por ejemplo archivos protegidos por contraseña, archivos anidados con un índice superior a cierto límite, archivos que exceden un determinado tamaño, etc.

La principal diferencia entre un IDS (como por ejemplo Snort) y un IPS, es que el primero evalúa la intrusión sospechosa una vez que ésta se está produciendo o ya ha tenido lugar, alertando en ese momento del peligro existente. Es decir, estamos ante un sistema pasivo frente a otro activo. Este retardo temporal desde que se recibe el evento hasta que efectivamente se toma una medida, puede provocar en la mayoría de los casos consecuencias fatales para una organización.

El objetivo de incorporar el servicio VPN dentro de dicho dispositivo All-In-One no es otro que el de poder analizar la información que circula a través del túnel, ya que el hecho de que ésta viaje encriptada a través del enlace no es garantía suficiente de que no pueda contener características maliciosas.

En la siguiente figura se ofrece un esquema funcional de una arquitectura de tipo All-In-One. En él pueden observarse los distintos subsistemas de protección encargados de analizar la información proveniente de una red insegura.

Otras características que presentan esta clase de sistemas son la posibilidad de configurarlos en alta disponibilidad (activo/pasivo, activo/activo) y balanceo de carga, o incluso que realicen tareas a nivel de servidor tradicional: servicios de autenticación e impresión, archivos compartidos, correo, proxy, etc.

Incrementar los logs de NFS

Hace poco me encontré con que no podía montar por NFS un sistema de archivos, y el cliente de NFS lo único que me daba era un simple timeout.

[root@client ~]# mount -vv -t nfs server:/data /mnt/test
mount: trying 192.168.1.11 prog 100003 vers 3 prot tcp port 2049
mount: mount to NFS server '192.168.1.11' failed: timed out (retrying).
...

En el /var/log/messages del servidor tampoco se volcaba nada.

Buscando por Internet descubrí que para incrementar los logs del servicio nfsd, había que modificar el valor de ciertos ficheros del sistema, que por defecto están a 0.

[root@server ~]$  echo 32767 > /proc/sys/sunrpc/rpc_debug

[root@server ~]$  echo 32767 > /proc/sys/sunrpc/nfsd_debug

Y para incrementar los logs en el cliente NFS:

[root@client ~]$  echo 32767 > /proc/sys/sunrpc/nfs_debug

Repitiendo la prueba con los logs en modo debug en el servidor, el único mensaje legible a destacar que pude observar fue el siguiente:

[root@server ~]$  tail -f /var/log/messages
...
Mar 31 14:19:57 client kernel: nfsd: connect from unprivileged port: 192.168.1.10:24498
Mar 31 14:19:57 client kernel: nfsd: connect from 192.168.1.10:5fb2

Venía a decir algo como que el cliente NFS (mount) se estaba intentando conectar desde un puerto del cual no podía. Como esto me seguía sin decir nada, al final tuve que recurrir a la herramienta de red por excelencia: tcpdump.

[root@server ~]$  tcpdump -nni eth0 \(tcp or udp\) and host 192.168.1.10
...
14:52:56.461748 IP 192.168.1.10.18036 > 192.168.1.11.111: S 3772663234:3772663234(0) win 5840 <mss 1460,nop,nop,timestamp 2288725875 0,nop,wscale 9>
14:52:56.462668 IP 192.168.1.11.111 > 192.168.1.10.18036: S 2887405046:2887405046(0) ack 3772663235 win 5792 <mss 1460,nop,nop,timestamp 2048429110 2288725875,nop,wscale 2>
...
14:52:56.476846 IP 192.168.1.10.61166 > 192.168.1.11.2049: . ack 29 win 12 <nop,nop,timestamp 2288725890 2048429124>
14:52:56.477097 IP 192.168.1.10.61166 > 192.168.1.11.2049: F 45:45(0) ack 29 win 12 <nop,nop,timestamp 2288725890 2048429124>
14:52:56.477761 IP 192.168.1.11.2049 > 192.168.1.10.61166: F 29:29(0) ack 46 win 1448 <nop,nop,timestamp 2048429126 2288725890>
14:52:56.478850 IP 192.168.1.10.61166 > 192.168.1.11.2049: . ack 30 win 12 <nop,nop,timestamp 2288725892 2048429126>


[root@client ~]# tcpdump -nni eth0 \(tcp or udp\) and host 192.168.1.11
...
14:52:56.459882 IP 192.168.1.10.18036 > 192.168.1.11.111: S 3772663234:3772663234(0) win 5840 <mss 1460,sackOK,timestamp 2288725875 0,nop,wscale 9>
14:52:56.461103 IP 192.168.1.11.111 > 192.168.1.10.18036: S 2887405046:2887405046(0) ack 3772663235 win 5792 <mss 1460,nop,nop,timestamp 2048429110 2288725875,nop,wscale 2>
...
14:52:56.475095 IP 192.168.1.10.61166 > 192.168.1.11.2049: . ack 29 win 12 <nop,nop,timestamp 2288725890 2048429124>
14:52:56.475257 IP 192.168.1.10.61166 > 192.168.1.11.2049: F 44:44(0) ack 29 win 12 <nop,nop,timestamp 2288725890 2048429124>
14:52:56.475400 IP 192.168.1.10.19867 > 192.168.1.11.111: UDP, length 56
14:52:56.477158 IP 192.168.1.11.2049 > 192.168.1.10.61166: F 29:29(0) ack 45 win 1448 <nop,nop,timestamp 2048429126 2288725890>
14:52:56.477173 IP 192.168.1.10.61166 > 192.168.1.11.2049: . ack 30 win 12 <nop,nop,timestamp 2288725892 2048429126>

Pues bien, en la traza del cliente puede observarse cómo éste estaba intentando mandar un paquete a través del protocolo UDP, el cual nunca llegaba al servidor. Lo que estaba ocurriendo es que el firewall situado entre ambas máquinas estaba cortando el tráfico UDP.

Monitorización de VMware ESXi con Zabbix (II)

Una vez que hemos establecido la infraestructura necesaria para poder monitorizar VMware ESXi con Zabbix, vamos a configurar Zabbix para poder realizar tal tarea.

Lo que he hecho ha sido desarrollar una plantilla para Zabbix, la cual está formada por 41 items (elementos encargados de obtener datos concretos) y 9 gráficos (utilizan los valores proporcionados por los items para representar los datos). En el siguiente link puede descargarse la plantilla: Template_ESXi.

Por lo tanto lo que haremos en primer lugar será ir a Configuration, Export/Import, con el objetivo de importar dicha plantilla. Una vez que la hayamos importado, iremos a la sección de Configuration, Host groups, y accederemos a la pantalla de Templates. Si pulsamos sobre el enlace Items, podremos ver la lista de todos los items que conforman la plantilla.


Hay uno de los items llamado "ESXi resxtop" el cual utiliza el script externo resxtop_esxi.sh para generar el fichero CSV (archivo que contiene los valores proporcionados por resxtop - consumo de CPU, memoria, disco, etc.) del VMware ESXi pasado a través de la macro HOSTNAME. Este item se ejecutará cada 30 sg de Lunes a Domingo. El resto de items utilizarán el script get_field_esxi.sh para obtener un valor concreto dentro del fichero CSV.


De esta forma si analizamos un item cualquiera, por ejemplo "Memory (Free)", podremos ver que al script get_field_esxi.sh se le pasarán dos argumentos a través de la línea de órdenes: la dirección IP o nombre del VMware ESXi (a través de la macro HOSTNAME) y el parámetro que queramos obtener dentro del fichero CSV. Para este caso concreto, como se quiere obtener la memoria que queda libre se le ha pasado la cadena de texto "\\Free MBytes".

Este item, que se ejecutará cada 30 sg de Lunes a Domingo, devolverá como resultado un número entero decimal que se corresponderá con los MB libres de memoria RAM. Para otros items lo único que cambiará será por ejemplo el tipo de resultado devuelto o la clase de unidad.


Esta plantilla ha sido creada teniendo en cuenta 8 cores, de ahí a que haya por ejemplo 8 items de tipo "Physical Cpu(0...7) Util Time". Por lo tanto, si la plantilla se utiliza para monitorizar otros VMware ESXi con menos cores, se pueden desactivar aquellos items no necesarios, o si por el contrario se dispone de más cores, se pueden añadir (clonar) más items.

Lo mismo ocurre también para el caso de los dos items relacionados con los interfaces de red: "Network Received Traffic (eth0)" y "Network Transmitted Traffic (eth0)". Si se tuviera algún VMware ESXi con otro interfaz de red, habría que clonar esos dos items y cambiar la cadena de texto "eth0" por "eth1".

La plantilla también dispone de 9 gráficos que utilizarán los items anteriormente comentados.


Si abrimos por ejemplo el gráfico de "Disk", podremos ver que hace uso de dos items: "Disk (Read)" y "Disk (Write)".


En la siguiente imagen podemos ver una de las gráficas (Physical Cpu Util Time) obtenidas por la plantilla Template_ESXi una vez que ha sido asignada a un VMware ESXi (ESXI01.LOCAL).