Spiga

Webinar: smartphones que amenzan tu red

Hola!

La gente de AirTight Networks ha organizado un Webinar gratuito para mostrar cómo proteger la red corporativa de todos los dispositivos inteligentes, (smartphones, tablets...) personales que se llevan los empleados al trabajo. Será el miércoles 2 de Noviembre a las 11:00 AM Pacific Time, que en España son las 20:00. Aquí tienes toda la información y el registro.

La verdad es que leyendo la presentación del evento, me he acordado mucho de la genial charla "Malware en la empresa" que Pedro Sánchez impartió este Febrero en Sevilla durante la Gira Up To Secure. Durante la charla, Pedro nos contó un caso real de un trabajador de un banco muy importante que decidió llevarse su portátil Mac al trabajo y conectarlo a la red corporativa... con unas consecuencias dramáticas.  Os dejo aquí las diapositivas de la ponencia, por si a alguien le interesa echar un vistazo:





iPhone, Droids, Tablets: Smartphones que amenazan tu red


En la cultura BYOD (bring your own device, lleva tu propio dispositivo) en la que vivimos hoy día, hay 3 veces más dispositivos personales en el espacio de tu red que dispositivos corporativos. Para hacer aún peor las cosas, los usuarios autorizados muchas veces solo necesitan sus credenciales para conectar sus dispositivos no autorizados a tu red WPA/802.1x sin tu conocimiento ni autorización, exponiendo al resto de equipos de la red a amenazas de seguridad, malware y fuga de datos.


En este webinar interactivo aprenderás:
  • Las limitaciones de las prácticas comunes de seguridad que suelen aplicarse.
  • Cómo identificar smartphones conectados a tu red
  • Definir una política de acceso y forzar a los smartphones que la cumplan
  • Establecer controles para restringir el acceso de dispositivos personales a la red corporativa.

Un saludo!

Nessus: detectando malas configuraciones

Hola!

Éste es el segundo post de la serie Top 10  de cosas que no conocías sobre Nessus que está publicando David Letterman, de Tenable Security, y que yo iré traduciendo (y resumiendo) por aquí. En el artículo anterior, hay más de una forma de hacer las cosas, estudiamos los beneficios de realizar un análisis con credenciales, y hoy vamos a ver cómo usar Nessus para descubrir malas configuraciones que puedan llevar a comprometer la seguridad de nuestros sistemas.

Nessus detecta malas configuraciones

Cuando yo trabajaba de administrador de sistemas [cuenta David Letterman], una de las tareas más difíciles era mantener las mismas configuraciones en todos los sistemas (o grupos de sistemas similares). Los sistemas cambiaban, se aplicaban actualizaciones, la gente hacía cambios a las 3:00 de la madrugada para corregir un problema de emergencia... todo ello contribuyendo a que las configuraciones se escaparan de las políticas en las que yo había trabajado tan duro para crearlas e implementarlas. Afortunadamente, Nessus permite auditar de forma consistente las configuraciones de tus equipos:
  • Ejecutar órdenes de shell Linux/Unix: dentro de la configuración de una política de auditoría, puedes especificar el comando a ejecutar, y comprobar los resultados deseados. Esto significa que puedes crear un script  para, por ejemplo, comprobar si las claves SSH tienen configuradas una contraseña.
  • Mirar dentro de los ficheros de configuración: Nessus permite buscar un fichero de configuración (o cualquier fichero en texto plano) de un equipo, localizar ciertos parámetros y realizar un test. Por ejemplo, si quieres estar seguro de que las configuraciones de tus servidores SSH no permiten que el usuario root haga un login, podríamos comprobarlo así:

system:"Linux"
type :FILE_CONTENT_CHECK
description:"2.3 Configure SSH - Checking if PermitRootLogin is set to no and not commented for server."
info:"ref. https://community.cisecurity.org/download/?redir=/linux/CIS_RHEL_5.0-5.1_Benchmark_v1.1.2.pdf Ch. 2, pp 24-25."
file:"/etc/ssh/sshd_config"
regex:"^[\\s\\t]*PermitRootLogin[\\s\\t]"
expect:"^[\\s\\t]*PermitRootLogin[\\s\\t]+no[\\s\\t]*$"


  • Inventario de software: se puede usar Nessus para identificar el software instalado. Por ejemplo, si queremos comprobar si nos hemos dejado instalado un compilador en nuestro servidor, podemos realizar lo siguiente:


type :RPM_CHECK
description:"SN.10 Remove All Compilers and Assemblers - gcc"
info :"ref. https://community.cisecurity.org/download/?redir=/linux/CIS_RHEL_5.0-5.1_Benchmark_v1.1.2.pdf App. A, page 119."
rpm :"gcc-0.0.0-0"
operator:"lt"


Y aquí tenéis el vídeo de la sesión:





Un saludo!

iptables, un tutorial sencillo

Hola!

Baśandome en la documentación de Juan Céspedes, profesor del GSYC de la Universidad Rey Juan Carlos, y en los libros Linux Network Administrator's Guide (Tony Bautts, Terry Dawson & Gregor N. Purdy) y Linux Cookbook (Carla Schroder), he escrito un artículo en el que se presenta iptables, se describe su estructura, se realiza un resumen de la sintaxis básica para la creación de reglas de filtrado de paquetes y se ofrece un script para un ejemplo completo. Espero que os sirva de ayuda.

Un cortafuegos (firewall) es un dispositivo hardware o software que tiene como objetivo proteger una red de otras redes a las que está conectado. El cortafuegos se configura con una serie de reglas que determinan el tráfico que puede pasar de una red a otra y el tráfico que debe ser bloqueado.
Para comprender el funcionamiento de un cortafuegos, podemos pensar en cómo desempeñan su trabajo los guardias de seguridad de una discoteca. Los dueños del local establecen los criterios que debe cumplir un potencial cliente para poder pasar a la sala y, cada vez que alguien llega a la puerta, el portero lo evalúa:
  • si cumple los criterios → pasa
  • si no los cumple  → no pasa
En la siguiente figura se representa el esquema de una red de ordenadores que utiliza un cortafuegos para proteger la red local de la red externa:

Figura 1. Esquema de una red que utiliza un Cortafuegos. (Fuente: Wikipedia)

Se pueden construir cortafuegos más sofisticados, como veremos a lo largo del artículo, que incluyen equipos separados del resto de la red local (Zona Desmilitarizada) para aumentar aún más la seguridad. De hecho, en las grandes corporaciones, es posible encontrar instalaciones con más de un cortafuegos, que separan los equipos de diferentes áreas de la empresa.
 
Linux como cortafuegos
El núcleo de las máquinas GNU/Linux incorpora el framework Netfilter, que permite interceptar y manipular paquetes de red. Además, en el espacio de usuario, el administrador puede usar iptables para establecer las reglas del firewall.

iptables
iptables se usa para crear, mantener y revisar las tablas de filtrado de paquetes en el kernel de Linux, y se estructura de la siguiente manera:
 
- Existen diferentes tablas (tables) dentro de las cuales puede haber varias cadenas (chains). 
- Cada cadena consiste en una lista de reglas con las que se comparan los paquetes que pasan por el cortafuegos. Las reglas especifican qué se hace con los paquetes que se ajustan a ellas (target).
Para cada paquete que recibe el cortafuegos, se examina la primera regla de la cadena correspondiente. Si el paquete no se ajusta a esa regla, se continúa examinando la siguiente hasta que se ajusta  con alguna. En ese momento se ejecuta el target:
  • DROP: el paquete se descarta, no puede pasar 
  • ACCEPT: el paquete continúa su camino normal
Si se llega al final de una cadena predefinida se ejecuta un target por defecto, llamado chain policy. El chain policy establece, por tanto, la política por defecto de nuestro cortafuegos.

Tablas
Como decíamos, en iptables existen varias tablas, que tienen diferentes objetivos:
- La tabla filter es la tabla por defecto, y se utiliza para especificar filtros de paquetes. Contiene 3 chains predefinidas:
  • INPUT: Se consulta para los paquetes que van dirigidos al propio cortafuegos
  • FORWARD: La atraviesan los paquetes enrutados a través de esta máquina, es decir, aquellos paquetes en los que el origen y el destino son equipos de redes diferentes.
  • OUTPUT: Para paquetes generados localmente
- La tabla nat se consulta cada vez que se ve un paquete que inicia una nueva conexión, con el objetivo de alterar algún parámetro de esa conexión. Tiene 3 chains predefinidas: 
  • PREROUTING: se consulta con los paquetes que entran en la máquina cortafuegos, tan pronto como llegan, antes de decidir qué hacer con ellos. 
  • OUTPUT: se utiliza para alterar paquetes generados localmente, antes de    enrutarlos. 
  •  POSTROUTING: para alterar los paquetes que están a punto de salir de la máquina.
- La tabla mangle es una tabla especial, destinada a alterar determinados parámetros de los paquetes (TOS, TTL ...), que se utiliza para realizar configuraciones complejas del cortafuegos. Cuenta con 5 chains predefinidas: INPUT, OUTPUT, PREROUNTING, POSTROUTING Y FORWARD.
 
Flujo de los paquetes a través de iptables
En la figura 2 se muestran todos los posibles caminos que un paquete puede seguir al atravesar nuestro cortafuegos.
 
Figura 2. Flujo de paquetes a través de iptables


Veamos el camino que seguiría, por ejemplo, un paquete que se origina en nuestra red local y va destinado a una máquina de Internet (para el esquema básico de la figura 1):
- El paquete entra en el cortafuegos por una interfaz de red, por tanto, primero se comprobarían las reglas de la cadena PREROUTING.
- A continuación se comprobarían las reglas de la cadena FORWARD, ya que el paquete no va destinado a un proceso del cortafuegos, si no que va a atravesarlo, saliendo por la interfaz que lo conecta con la red externa.
- Por último, si el paquete no ha sido filtrado y sigue adelante, antes de salir del cortafuegos por la otra interfaz de red, se comprueban las reglas de la cadena POSTROUTING

Comandos de configuración
 
Vamos a ir explicando, a continuación, los comandos básicos de configuración de iptables. Veremos algún ejemplo sencillo, y terminaremos con un ejemplo completo de configuración de un firewall con DMZ.
 
Listado de reglas
#iptables [-t tabla] [opciones] -L [chain]

Muestra un listado de todas las reglas de una cadena, o de todas ellas. Las opciones disponibles son:
-v: información detallada
-n: salida numérica
-x: valor exacto de cada número
 
Borrado de contadores:
#iptables [-t tabla] -Z [chain]

Borra los contadores de una determinada chain, o de todas ellas. Es habitual colocar este comando al principio de todos los script de configuración, para borrar las reglas que existieran de antemano. Se puede combinar con la opción -L para mostrar la información justo antes de borrarla.
 
Borrado de reglas:
#iptables [-t tabla] -F [chain]

Borra las reglas de una determinada chain o de todas ellas.
 
Creado y borrado de reglas:
#iptables [-t table] -A chain rule-spec
#iptables [-t table] -I chain [rulenum] rule-spec
#iptables [-t table] -R chain rulenum rule-spec
#iptables [-t table] -D chain rule-spec
#iptables [-t table] -D chain rulenum

Las opciones son las siguientes:
-A: añade una regla al final de la lista
-I: inserta una regla al comienzo de la lista o en el punto especificado
-R: reemplaza una regla (especificada por su número de regla) por otra
-D: borra una regla determinada
 
Para especificar una regla podemos usar los siguentes parámetros:
-p [!] protocolo: el protocolo del paquete a comprobar. Puede ser 'tcp', 'udp', 'icmp' o 'all'
-[sd] [!] dirección[/máscara]: dirección ip origen (s) o destino (d) del paquete
-[io] [!] iface: nombre de la interfaz de entrada (i) o de salida (o) del paquete
-j target: especifica el target de dicha regla. Puede ser una acción predefinida (ACCEPT, DROP), una extensión o el nombre de una chain
 
Establecimiento de un política por defecto:
#iptables [-t table] -P chain target

Establece el taget que se ejecutará para los paquetes que no cumplan con ninguna regla de la chain especificada

Un ejemplo sencillo 
Con estos comandos básicos de configuración ya podemos resolver muchos de los problemas con los que se encuentra una empresa al exponer sus sistemas de información a Internet.
Vamos a ver un ejemplo sencillo para entender cómo se deben escribir las reglas en iptables. Observemos la figura 3, que representa una instalación sencilla, con una máquina que actúa como router y cortafuegos conectando dos redes distintas.
 
Figura 3. Un ejemplo sencillo



Supongamos que queremos que sólo la máquina B pueda hablar con C, y además sólo pueda usar el protocolo TCP. Los paquetes que no cumplan estas condiciones serán descartados.
Lo primero que tenemos que decidir es ¿en qué tabla e qué cadena vamos a colocar las reglas? En este caso, queremos realizar filtrado de paquetes, por lo que está claro que trabajaremos con la tabla filter... pero ¿en la cadena INPUT, OUTPUT o FORWARD? Como los paquetes que queremos filtrar son los que van a atravesar el Firewall de una red a otra, trabajaremos con la cadena FORWARD.
Los comandos que deberíamos usar para conseguir estos objetivos son los siguientes:


  1. #iptables -F FORWARD
  2. #iptables -P FORWARD DROP
  3. #iptables -t filter -A FORWARD -p tcp -s 192.168.1.2 -d 192.168.2.1 -j ACCEPT
  4. #iptables -t filter -A FORWARD -p tcp -s 192.168.2.1 -d 192.168.1.2 -j ACCEPT



La línea 1 borra las reglas que pudiera haber en la cadena FORWARD de la tabla filter (que es la tabla por defecto).
La línea 2 establece la política por defecto a DROP (denegar), por lo tanto, los paquetes que no cumplan con las reglas que especifiquemos serán rechazados.
Las líneas 3 y 4 permiten el tráfico entre las máquinas B y C según las reglas especificadas en el enunciado. Veamos con detalle su significado en la figura 4.

Figura 4. ¿Cómo se lee una regla de iptables?

Los aministradores no suelen sentarse delante de la máquina que actúa como cortafuegos y ejecutan los comandos uno a uno. Es más habitual escribir todos los comandos en un script de shell y ejecutar solamente el script. No sólo se hace por comodidad, sino porque esta opción permite incluir comentarios y reutilizar el código:

#!/bin/bash
##Script de iptables – Un ejemplo sencillo

##Borramos las reglas de la chain FORWARD de la tabla filter
iptables -F FORWARD

##Establecemos la política por defecto -> DROP
iptables -P FORWARD DROP

##Aceptamos los paquetes TCP entre B y C
iptables -t filter -A FORWARD -p tcp -s 192.168.1.2
            -d 192.168.2.1 -j ACCEPT
iptables -t filter -A FORWARD -p tcp -s 192.168.2.1
            -d 192.168.1.2 -j ACCEPT


Extensiones de las reglas

Con las opciones vistas hasta el momento podemos controlar los parámetros más básicos de la cabecera IP del paquete. Puede ser necesario un control más estricto, por ello existen una serie de extensiones que permiten utilizar opciones nuevas:
-m extensión: activa una extensión para poder especificar los parámetros del paquete
 
Veamos algunas extensiones de las reglas:
tcp: añade las siguientes opciones
  • --sport [!] port[:port]: especifica el puerto o rango de puertos origen
  • --dport [!] port[:port]: especifica el puerto o rango de puertos destino
  • [!] --syn: la regla concordará sólo con los paquetes cuyo bit SYN=1 y los flags ACK y FIN valgan 0. Los datagramas con estos valores se utilizan para abrir las conexiones TCP
udp: añade las siguientes opciones
  • --sport [!] port[:port]: especifica el puerto o rango de puertos origen
  • --dport [!] port[:port]: especifica el puerto o rango de puertos destino

Ejemplo: supongamos que quieres crear una regla para permitir el paso a las peticiones a un servidor web que tiene la IP 172.16.0.254.
#iptables -A FORWARD -p tcp -d 172.16.0.254 --dport 80 -j ACCEPT

icmp: añade la opción –-icmp-type tipo, que indica qué tipo ICMP debe tener el paquete (echo-request, echo-reply, network-unreachable...)
mac: añade la opción –-mac-source [!] dir_mac, que especifica la dirección MAC que debe tener el paquete


Ejemplo: quieres permitir que se realice ping al cortafuegos desde la máquina del administrador, que tiene IP dinámica y MAC 00:21:00:16:82:9f 
#iptables -A INPUT -p icmp --icmp-type echo-request -m mac --mac-source 00:21:00:16:82:9f -j ACCEPT  
#iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT


 state: Añade la opcion --state valor, que indica el estado en el que debe estar la conexion correspondiente a dicho paquete. Los tipos de estado principales son:
  • NEW: el paquete corresponde a una conexión nueva
  • ESTABLISHED: el paquete está asociado a una conexión ya establecida
  • RELATED: el paquete corresponde a una conexión nueva, pero relacionada con una que ya está establecida (como un canal de datos FTP o un error de ICMP)

Extensiones de target
 
Existen otros target diferentes a DROP y ACCEPT que permiten que nuestro cortafuegos realice otras funciones a parte del filtrado de paquetes:
 
- MASQUERADE: sólo es válida en la chain POSTROUTING. Indica que la dirección origen del paquete (y de todos los de esa conexión) será cambiada por la IP local de esta máquina. Muy útil para IP dinámica (es lo que se conoce como NAT)

Ejemplo:
# iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
 
- SNAT: sólo es válida en la chain POSTROUTING. Indica que la dirección y puerto origen del paquete (y de todos los de esa conexión) sea modificada según se especifica con la opción –-to-source. El target será SNAT (en lugar de MASQUERADE) cuando tengamos una IP fija.

Ejemplo:
# iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 189.29.35.15
 
- DNAT: sólo es válida en las chains PREROUTING y OUTPUT. Cambia la dirección IP destino (y de todos los futuros de esta misma conexión) por el especificado con la opción -–to-destination. Es lo que se conoce como 'abrir el puerto' en el router.
Por ejemplo, si la máquina 192.168.1.2 de nuestra red local aloja un servidor web que queremos que sea accesible desde la red externa:
# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.2:80
 

DMZ, zona desmilitarizada

Observa la figura siguiente, que representa una red en la que tenemos un servidor web público, al que vamos a permitir el acceso desde Internet, y un servidor de BBDD privado, con toda la información de nuestra empresa.
 
Figura 5. Firewall de 2 patas

¿Qué ocurriría si un atacante consigue comprometer la seguridad de nuestro servidor web? A partir de ese momento, el acceso a los recursos de la red local sería inmediato, ya que ambos servidores se encuentran en la misma red.

En estos casos, el uso de una DMZ permite que se puedan dar servicios a la red externa a la vez que se protege la red interna en el caso de que un intruso comprometa la seguridad de los equipos situados en la zona desmilitarizada:

Figura 6. Firewall de 3 patas

Un ejemplo completo
Observemos la figura 7, que representa la configuración de la red de nuestra empresa:
 
 Figura 7. Esquema de la red de nuestra organización


En el ejemplo supondremos que nuestra máquina GNU/Linux está conectada a un ROUTER que nos proporciona el acceso a Internet por la interfaz eth2. Este router está configurado como monopuesto (no hace NAT y deja pasar todo el tráfico a nuestra máquina Linux).


Las direcciones de la máquina son las siguientes:
  • eth0: 192.168.1.1/24
  • eth1: 192.168.2.1/24
  • eth2: dirección IP obtenida por DHCP (dinámica)

En la DMZ tenemos un servidor WEB y un servidor SSH que queremos sean accesibles desde Internet y la red local. Las direcciones son:

Servidor WEB: 192.168.2.2/24
Servidor FTP: 192.168.2.3/24

Las máquinas de la red local podrán navegar por Internet accediendo a servidores WEB, servidores WEB Seguros, servidores FTP y servidores DNS. El resto de conexiones serán filtradas.

Todas las máquinas de la red local tienen direcciones del rango 192.168.1.0/24.

Supondremos que en el firewall hay instalado un servidor ssh para que el administrador pueda conectarse desde la red local.

Se presenta a continuación un script, con una parte configurable por el usuario, para que pueda ser fácilmente adaptado a otras instalaciones y requisitos:


#!/bin/bash

####################################################################   
#            Ejemplo de configuración de un firewall con DMZ y red local           #
####################################################################

### SECCIÓN CONFIGURABLE POR EL USUARIO ###

# REDLOCAL    Dirección IP de la red local interna
# BCASTLOCAL    Dirección de Broadcast de la red local
# IFAZLOCAL    Nombre del interfaz de red local
# CUALQUIERA    Dirección de red 0.0.0.0
# IFAZEXT        Nombre del interfaz de red externo
# WEB        Dirección IP del servidor WEB
# FTP            Dirección IP del servidor FTP
# REDDMZ        Dirección IP de la red DMZ
# IFAZDMZ        Nombre del interfaz de red de la DMZ
# TCPLOCAL    Lista de puertos TCP que permitimos usar en la red local
# UDPLOCAL    Lista de puertos UDP que permitimos usar en la red local


REDLOCAL = “192.168.1.0/24”
BCASTLOCAL = “192.168.1.255”
IFAZLOCAL = “eth0”

CUALQUIERA = “0/0”
IFAZEXT = “eth2”

WEB = “192.168.2.2”
FTP = “192.168.2.3”
REDDMZ = “192.168.2.0/24”
IFAZDMZ = “eth1”

TCPLOCAL = “www,ftp,ftp-data,https”

UDPLOCAL = “domain”


                ###IMPLEMENTACIÓN###

# Borramos todas las reglas que pudiera haber anteriormente, y los contadores

iptables -F
iptables -t nat -F
iptables -X         #borra las cadenas creadas por el usuario
iptables -Z
# Cambiamos la política por defecto en todas las cadenas de la tabla filter
# Chain Policy -> DROP

iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP

# Permitimos que se acceda al cortafuegos por ssh

iptables -A INPUT -s $REDLOCAL -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -d $REDLOCAL -p tcp --sport 22 -j ACCEPT

##CONEXIONES TCP

# Permitimos las conexiones establecidas, desde la red externa y desde la DMZ hacia la red local en los puertos permitidos

iptables -A FORWARD -d $REDLOCAL -p tcp  -m state --state ESTABLISHED -m multiport --sports $TCPLOCAL -j ACCEPT

# Permitimos el tráfico desde la red local hacia la red externa y hacia la DMZ en los puertos permitidos

iptables -A FORWARD -s $REDLOCAL -p tcp -m multiport --dports $TCPLOCAL -j ACCEPT

# Permitimos el tráfico desde la red local y desde la red externa al servidor WEB  por el puerto 80

iptables -A FORWARD -d $WEB -p tcp --dport 80 -j ACCEPT

# Permitimos las conexiones establecidas desde el servidor WEB a la red local y a la red externa

iptables -A FORWARD -s $WEB -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT

# Permitimos el tráfico desde la red local y desde la red externa al servidor FTP por el puerto 20 y 21

iptables -A FORWARD -d $FTP -p tcp --dport 20:21 -j ACCEPT

# Permitimos las conexiones establecidas desde el servidor FTP a la red local y a la red externa

iptables -A FORWARD -s $FTP -p tcp --sport 20:21 -m state --state ESTABLISHED -j ACCEPT

# Permitimos las conexiones relacionadas desde el servidor FTP a la red local y a la red externa

iptables -A FORWARD -s $WEB -p tcp --sport 20:21 -m state --state RELATED -j ACCEPT

##CONEXIONES UDP

# Permitimos las conexiones establecidas desde la red externa hacia la red local en los puertos permitidos

iptables -A FORWARD -d $REDLOCAL -i $IFAZEXT -p udp  -m state --state     ESTABLISHED -m multiport --sports $UDPLOCAL -j ACCEPT

# Permitimos el tráfico desde la red local hacia la red externa  en los puertos permitidos

iptables -A FORWARD -s $REDLOCAL -o $IFAZEXT -p udp -m multiport --dports     $UDPLOCAL -j ACCEPT


## Hacemos NAT para las máquinas de la red local y para las máquinas de la  DMZ

iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

# Si la dirección IP Pública fuera estática haríamos SNAT

## Hacemos DNAT para que las peticiones que recibimos de Internet lleguen a los servidores

iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j DNAT --to-destination $WEB:80

iptables -t nat -A PREROUTING -i eth2 -p tcp –dport 20 -j DNAT --to-destination $FTP:20

 
Un saludo!

Nessus: ventajas de un análisis con credenciales

Hola!

La empresa  Tenable Network Security, desarrolladora de Nessus, tiene un blog muy interesante en el que publica artículos con trucos para sacar todo el partido a sus productos.

Uno de estos tutoriales ha sido bautizado como Top 10  de cosas que no conocías sobre Nessus, y yo os voy a ir publicando por aquí la traducción (resumida) de los que me resulten más interesantes.

El primero de estos trucos, el número 10, se llama "Hay más de una forma de hacer las cosas..." 

Una de las características más desconocidas de Nessus es su capacidad de ejecutar un análisis con o sin credenciales. Ejecutar Nessus sin credenciales contra tu red es muy rápido y muy útil. Sin duda alguna, configurar un servidor Nessus en tu red y dejar que escanee cada dispositivo conectado, es una solución muy potente y puede ofrecerte una gran cantidad de información sobre tu red, manteniendo un equilibro entre velocidad, precisión y no intrusión.


Análisis con credenciales



Sin embargo, lanzar un análisis con credenciales presenta varias ventajas y te ofrece un nivel de información más profundo sobre tu red y tus equipos:
  • Análisis no intrusivo - como el análisis se realiza con credenciales, las operaciones de identificación de vulnerabilidades son ejecutadas en el propio equipo, en lugar de de hacerlo a través de la red. Todo se ejecuta lanzando órdenes en el equipo analizado, y luego se envían los resultados de esos comandos al servidor Nessus, por lo que se consumen muchos menos recursos.
  • Lista definitiva de parches pendientes - En lugar de probar un servicio de forma remota y tratar de encontrar una vulnerabilidad, Nessus realizará una consulta al host local para ver si el parche para esa determinada vulnerabilidad se ha aplicado correctamente. Este tipo de consulta es mucho más precisa y segura que las realizadas por los análisis remotos.
  • Vulnerabilidades del software de terceros - mirando el software instalado en el equipo y su versión, Nessus encontrará vulnerabilidades que en un análisis tradicional basado en la red no habrían sido descubiertas.


Picture 83.png
Vulnerabilidades del software de terceros   
  • Descubrir nuevos tipos de "vulnerabilidades" - Nessus puede leer políticas de contraseñas, obtener una lista de dispositivos USB, comprobar la configuración del Anti-Virus o enumerar los dispositivos Bluetooth conectados al equipo analizado.

Por último, hay que tener en cuenta que el uso de credenciales en los análisis no tiene por qué suponer un riesgo, ya que Nessus ofrece varias opciones para asegurar su uso. Por ejemplo, cuando se usa SSH, se pueden configurar claves públicas/privadas, sudo, su, su+sudo o lectura del fichero SSH known_hosts.


SSH Settings


Opciones de configuración de las credenciales

Y aquí tenéis el vídeo de la sesión:



Un saludo!

Autenticación en RIPv2 y OSPF con Linux

Hola!

Hace un tiempo estudiamos cómo se configura el encaminamiento dinámico en routers Linux utilizando la suite Quagga, que incorpora implementaciones de OSPFv2, OSPFv3, RIP v1 y v2, RIPng y BGP-4 para plataformas Unix (FreeBSD, Linux, Solaris y NetBSD). En ese artículo vimos cúal es la arquitectura de Quagga, lo instalamos y realizamos la configuración de RIPv2.

Hoy vamos a ver cómo añadir algo de seguridad a RIPv2 y OSPF, de manera que los routers se autentiquen unos a otros usando una contraseña MD5 para evitar que cualquier equipo pueda actualizar de forma ilegítima nuestras tablas de encaminamiento. Para ello vamos a seguir una receta del genial libro LINUX networking cookbook de Carla Schroder.

Autenticación MD5 en RIPv2

Para configurar una contraseña MD5 en los routers tan sólo hay que añadir las siguientes líneas en el fichero /etc/quagga/ripd.conf:

#nano /etc/quagga/ripd.conf

key chain mired
  key 1
    key-string contraseña

 
interface eth1
  ip rip authentication mode md5
  ip rip authentication key-chain mired


Debes reemplazar mired por el nombre que más te guste y asegurarte de que configuras la interfaz de red correcta.


Autenticación MD5 en OSPF


ospfd utiliza una sintaxis algo diferente:

#nano /etc/quagga/ospfd.conf

interface eth0
  ip ospf authentication message-digest
  ip ospf message-digest-key 1 md5 contraseña
 

router ospf
  network 172.16.1.0/24 area 0.0.0.1
  area 0.0.0.1 authentication message-digest



Debes modificar el fichero para usar los nombres de interfaces y direcciones de red adecuados. Pueden crearse diferentes keys para diferentes interfaces, numerándolas de forma secuencial.

Reinicio del servicio

No olvides que para que los cambios tengan efecto debes reiniciar el servicio:

#/etc/init.d/quagga restart


Un saludo!

LibreOffice para la web, iOS y Android

Hola!

En la pasada conferencia de LibreOffice, la Document Foundation ha anunciado un prototipo de LibreOffice Online, del que puedes ver una demo en el siguiente vídeo:


video

http://people.gnome.org/~michael/data/2011-10-10-lool-demo.webm 


Además, se anunció el comienzo de un proyecto de portabilidad para Android e iOS, con el objetivo de llevar la suite ofimática a tablets con Android y al iPad, aunque quizás pueda instalarse también en dispositivos más pequeños.

Estas soluciones no están aún disponibles para los usuarios finales, aunque ya se encuentran en un estado avanzado de desarrollo, y se espera su lanzamiento para finales de 2012 o comienzo de 2013.

¡Un saludo!

Fotos de WorldSkills Londres 2011

Hola!

Os paso unas fotos de WorldSkills Londres 2011, donde estoy participando como jurado de la especialidad Administración de Sistemas en Red.

Ayer fue la ceremonia de inauguración, que se celebró en el O2 Arena y contó con la intervención de Nick Clegg, vicepresidente de UK.


Aquí podéis ver el momento en el que la selección española salió a escena:

 

Hoy, por fin, ha comenzado la competición y los estudiantes han empezado a realizar las pruebas. Esta es la pinta que tiene nuestra zona:


Ésta es Tamara Beisti, la representante de España en esta especialidad, al haberse proclamado campeona en el último SpainSkills.


Y éste es el equipamiento con el trabaja cada competidor:
  • 2 servidores
  • 1 portátil
  • 1 teléfono IP
  • 1 Punto de Acceso
  • 2 routers
  • 3 switches
 

Ya os iré contando cómo va todo. ¡Un saludo!