Una de las tareas comunes que deben aplicarse a un servidor que va a pasar a producción es fortalecer la seguridad que lleva por defecto el sistema. A esto se le llama bastionar o securizar. Como son muchos aspectos los que hay que tener en cuenta para llevar a cabo esta labor, he querido hacer un recopilatorio de las principales tareas de bastionado en Linux.

Los siguientes puntos se van a centrar únicamente en la seguridad de la máquina, sin extenderse en los elementos externos que se pueden utilizar para securizar el equipo, como NIDS, IPS, firewalls, auditorías periódicas o cañones de fotones.

• Software siempre actualizado. Imprescindible mantener el sistema siempre a la última en parches de seguridad. No hacerlo es el método más sencillo para que te vulneren o tumben el equipo. La mayoría de malware actual se basa en vulnerabilidades conocidas de un servicio o aplicación para infectar la máquina.
• Configuración deficiente de las aplicaciones. De nada serviría un servidor altamente bastionado si uno de los servicios disponibles tiene una configuración que permita a un atacante vulnerar su seguridad. Como es imposible abarcar todo lo que esta implicación supondría, enumeraré algunas indicaciones generales, aplicables a la mayoría de aplicaciones:
(Leer el resto de la entrada…)

Hoy les vamos a hablar de una Sandbox. Para aquellos que no estén familiarizados con este tipo de aplicaciones, una Sandbox (caja de arena en español) no es (en este caso) más que una aplicación de análisis de malware que, mediante el aislamiento del proceso o fichero malicioso que se quiere analizar, permite conocer su funcionamiento detallado, incluyendo, entre otros, información acerca de la actividad de red y llamadas al sistema.

CuckooSandbox tiene varias características interesantes. Por un lado, se sirve de técnicas de virtualización para conseguir el aislamiento de los ficheros a analizar, a diferencia de otras Sandbox que utilizan técnicas de enjaulado de procesos para conseguir su objetivo. Por otro, su estructura completamente modular permite un gran abanico de configuraciones y adaptaciones a entornos concretos, lo que permite ser válida ante situaciones muy diferentes. Además, se trata de un proyecto de software libre bajo licencia GPL versión 3.

Hoy me gustaría presentaros un módulo de Metasploit que he descubierto hace poco tiempo. Se llama Page collector y ha sido desarrollado por Spencer McIntyre. El módulo en concreto nos ayuda a descubrir páginas web de un rango de ips y nos las muestra de forma gráfica. Vamos a plantear un posible escenario en el nos resultaría útil este módulo: Estamos realizando un pentest de una red corporativa que tiene un rango 192.168.0.0/24 y nos interesa conocer rápidamente, si existen interfaces de administración (phpMyAdmin, páginas de login por defecto, consolas JBoss…).

La instalación del módulo es muy sencilla y funciona out-of-the-box en una metasploit4:

En este post vamos a hablar acerca de una vulnerabilidad descubierta por el equipo de CSIRT-cv y publicada ayer, como podéis ver en su página de alertas. La aplicación afectada es JasperServer, un servidor para generación de informes, análisis de datos y Business Intelligence ampliamente utilizado, y que tiene una versión de código abierto, que es la que se ha demostrado vulnerable.

Durante un test de seguridad realizado a la versión 3.7.0 CE, se detectó que, además de los parámetros necesarios para ubicar al usuario en la aplicación, había un parámetro llamado _flowExecutionKey que iba cambiando cada cierto tiempo, probablemente para controlar el flujo del usuario dentro de la aplicación. A continuación se puede ver un ejemplo de petición válida en el sistema:

Una vez presentada UMO en una entrada anterior, vamos a ver con un poco más de detalle cómo desplegarla para empezar a jugar con ella. Se ha probado la herramienta en un sistema con GNU/Linux Debian Squeeze y se ha utilizado Python 2.6.6.

Lo primero es descargar la herramienta:

Una vez descargada la descomprimimos:

Hace algo mas de un año, uno de nuestros colaboradores escribió el post titulado “Disponibilidad en los servicios de conectividad a internet” donde se hacía referencia al secuestro de los prefijos IP de youtube desde Pakistan Telecom (junto otros ejemplos).

Copiando de dicho post, el ejemplo fue el siguiente:

En la siguiente entrada vamos a tratar la herramienta de seguridad Snort, la cual es una aplicación de detección de intrusos a nivel de red (IDS). Su función es leer el tráfico de red, normalizarlo, catalogarlo y analizarlo mediante un motor de reglas en busca de una serie de patrones en el tráfico que identifiquen un posible ataque; por tanto se trata de un IDS basado en firmas. Así, dada una amenaza previamente conocida se crea una firma que permita la detección del tráfico malintencionado. Es por ello que la herramienta no dispone de la capacidad de detectar anomalías en el tráfico que permitan identificar vulnerabilidades no conocidas o malware dirigido.

Veamos lo expuesto con anterioridad en el siguiente ejemplo: se realiza una conexión saliente desde el equipo del gerente hacia China empleando el protocolo cifrado SSL a las tres de la madrugada. Es posible que este hecho requiera la intervención del equipo de gestión de incidentes, aunque implique inicialmente la actuación del primer nivel, para comprobar el motivo de esta conexión. ¿Pero cómo alertamos de esta conexión? Snort lo único que ve es una conexión desde un equipo a un servidor de Internet que emplea el protocolo SSL, es decir, una navegación web con protocolo HTTPS. Un IDS basado en reglas no entiende ni conoce los siguientes puntos:

La arquitectura de una red empresarial requiere un diseño que permita la separación entre los usuarios, servidores internos y los servidores perimetrales o DMZ. Un diseño básico inicial consiste en un cortafuegos principal que separa el tráfico que va a la red perimetral del que va al resto de redes, existiendo un segundo cortafuegos de distinto fabricante en la entrada de la red de servidores internos, y entre ambos el servidor de VPN. Un esquema resumido sería el siguiente:

Recientemente, hemos detectado una nueva tendencia en los ataques a servidores web IIS. Los ataques intentan explotar una vieja vulnerabilidad de 2004 en los servidores web de Microsoft. Es habitual que malwares antiguos todavía sigan funcionando años después de su gran apogeo, ya que muchas máquinas no se actualizan correctamente y siguen siendo vulnerables.

Lo que ya no es tan común es que años después haya un aumento tan elevado de ataques, siendo estos de distintos orígenes. Como ejemplo, sirva esta captura de nuestro sistema de posicionamiento de ataques en tiempo real:

Hace un par de días Facebook anunciaba desde su blog dos de sus nuevas funcionalidades para aumentar la seguridad de sus usuarios.

La primera, y una de las más demandadas por los usuarios, es el soporte de sesiones https. Hasta ahora, solo la parte de autenticación de login y password iban cifradas, dejando toda la actividad que realizáramos en la red social sin cifrar. De este modo, un atacante podría leer nuestras conversaciones, ver nuestras fotos, robar nuestras cookies, etc. Parece que la aparición de Firesheep, una extensión de Firefox que permite robar las cookies de sesión de multitud de sitios web, ha acelerado el proceso de incorporación de https a los servidores de Facebook.