.: [ INTRO ]

Rooted CON es un Congreso de Seguridad que se celebrará en Madrid
(España) en Marzo de 2010. Nuestro objetivo es promover la seguridad,
ofreciendo charlas altamente técnicas con un enfoque práctico (combinación
de teoría / demo) y neutralidad (aunque apostamos por las empresas y
queremos que éstas participen en el congreso, deberá primar el contenido
técnico y objetivo).

También deseamos que la gente participe, se divierta… ¡y hasta se
lleve un premio a casa! Por ello, llevaremos a cabo diversos eventos
(aparte de las conferencias), siendo uno de los más importantes el
concurso CTF (”Capture the flag”), que contará con importantes premios
en metálico y que ha sido diseñado por ni más ni menos que uno de los
“Sexy Pandas” (equipo finalista del tradicional “Defcon CTF”).

Y por supuesto si todavía te quedan fuerzas también podrás aprovechar
para vivir a tope el encanto de las noches madrileñas…

.: [ FORMATO ]

Nos gustaría recibir dos tipos de propuestas:
- charlas rápidas. Duración: 20′.
- charlas normales. Duración: 50′.

Si tienes una idea loca/interesante y fresca que se puede contar en
poco tiempo, por favor, no lo dudes y propón una charla rápida. Si tu
idea es más loca todavía y necesitas más tiempo para explicarla en
profundidad usa la segunda modalidad: la charla normal.

Sólo aceptaremos propuestas en español e inglés. Haremos todo lo
posible para tener traducción simultánea en la sala pero no podemos
prometer nada ya que dependerá del presupuesto y de los patrocinadores.

.: [ TEMÁTICA ]

Nos interesa cualquier tema puntero del mercado de la seguridad. Éstos
son sólo algunos ejemplos:
- técnicas innovadoras tanto defensivas como ofensivas.
- todo lo relacionado con el fraude, phishing, troyanos en entornos
financieros, mecanismos de protección asociados, etc.
- “ingeniería inversa”, técnicas de bajo nivel, kernel, …
- descubrimiento de vulnerabilidades, “fuzzing” y técnicas relacionadas.
- ataques en entornos virtualizados, sistemas de cluster, “cloud
computing” y nuevos productos de seguridad “en la nube”.
- criptografía y criptoanálisis.
- seguridad en entornos móviles.
- herramientas de hacking: desarrollos propios.
- seguridad documental.
- voz sobre IP, “phreaking”, …
- análisis forense y contramedidas.
- seguridad en dispositivos inalámbricos.
- esteganografía y todo tipo de canales subliminales.
- seguridad en aplicaciones web.
- …

.: [ PROCEDIMIENTO PARA PRESENTAR UNA PROPUESTA ]

¿Te gustaría hablar en Rooted CON? ¡No te olvides de hacer las charlas
ilustrativas e incluir demos!

Envíanos tu solicitud por correo electrónico a:
cfp -AT- rootedcon.es

Para que tu charla sea aceptada en el proceso inicial de selección
*deberá* respetar el formato descrito previamente e incluir *toda* la
información siguiente:

- título
- autor (nombre completo y opcionalmente nick/apodo)
- bio (unas líneas diciendo quién eres)
- duración (¿charla normal o rápida?)
- resumen (deberá ser lo suficientemente extenso como para poder ser
correctamente evaluado)
- ubicación/nacionalidad
- medios necesarios para impartir la charla
- ¿tienes pensado dar la misma (o similar) charla en otras conferencias?
¿En cuál?

.: [ FECHAS ]

1 Octubre, 2009 – Se abre el CFP.
20 Diciemebre, 2009 – Se cierra el CFP.
31 Diciembre, 2009 – Ponentes seleccionados.
10 Enero, 2010 – Entrega del “paper” final y materiales de la presentación.

.: [ PRIVILEGIOS PARA PONENTES ]

Los ponentes gozarán de los siguientes beneficios:
- Alojamiento gratuito.
- Acceso gratuito al congreso.
- Gastos de viaje (en la medida de lo posible).
- Tickets/bebidas gratis durante la fiesta.

.: [ PATROCINADORES ]

Todavía tienes la oportunidad de ayudarnos a organizar el mejor
congreso de seguridad de España y a la vez obtener un interesante ROI.
Si estás interesado en ser uno de nuestros patrocinadores, por favor
contacta con nosotros:

patrocinio -AT- rootedcon.es

.: [ ENLACES ]

- Sitio Web
http://www.rootedcon.es/
- Grupo en Facebook
http://www.facebook.com/group.php?gid=96410924798
- Grupo en LinkedIn
http://www.linkedin.com/groups?gid=1969438
- Lista de correo “sólo-anuncios”
https://listas.rootedcon.es/mailman/listinfo/rooted-announce

-=EOF=-

Compártelo

::Instalación SSOO::

Instalamos Debian en ambos nodos, solo el sistema base.
Para el particionado reservamos dos particiones para el HA sin montar, una para los metadatos(con 128 MB basta) la otra para var2.
Una vez instalado añadimos las siguientes lineas al fichero /etc/apt/sources.list

—-
deb http://ftp.es.debian.org/debian/ etch non-free
deb-src http://ftp.es.debian.org/debian/ etch non-free
deb http://www.backports.org/debian etch-backports main contrib non-free
deb http://apt.opsview.org/debian etch main
deb http://ftp.debian.org/debian etch non-free
—-

Después de esto al hacer “aptitude update” obtendremos errores de certificados, se solucionan importándolos con los siguienetes
comandos:

gpg –keyserver subkeys.pgp.net –recv-key XXXXXXXX
gpg –export –armor XXXXXXXX | apt-key add -

Donde XXXXXXXX son los últimos 8 dígitos numéricos del cedrtificado y se obtienen del error al hacer el “aptitude update”
COnfiguramos para que nodo1 y nodo2 tengan IP’s estáticas y completamos el fichero /etc/hosts para que resuelvan uno contra el otro.

:: Instalación Software ::

Instalamos el software necesario mediante aptitude:

aptitude install heartbeat
aptitude install drbd8-source
aptitude install drbd8-utils
aptitude install ssh
aptitude install opsview

Creamos el módulo para el drbd8:

module-assistant auto-install drbd8

:: Configuración de la HA ::

En ambas máquinas sustituimos el fichero /etc/drbd8.conf por este:

—-
global {
usage-count no;
}
common {
}
resource “r0″ { # r0 es el nombre del recurso
protocol C;
startup {
wfc-timeout 80;
degr-wfc-timeout 120;
}
disk {
on-io-error detach;
}
net {
}
syncer { rate 10M; }
on nodo1 { # nodo1
device /dev/drbd0; # dispositivo HA
disk /dev/sda6; # partición que compartirán los nodos en HA (var2)
address X.X.X.X:7780; # IP y puerto que se utilizará para balancear
meta-disk /dev/sda8[0]; # partición donde se guardan los metadatos
}
on nodo2 { # idéntico para el nodo2
device /dev/drbd0;
disk /dev/sda6;
address X.X.X.X:7780;
meta-disk /dev/sda8[0];
}
}
—-

Para ajustar los permisos ejecutamos los siguientes comandos:

chgrp haclient /sbin/drbdsetup
chmod o-x /sbin/drbdsetup
chmod u+s /sbin/drbdsetup

chgrp haclient /sbin/drbdmeta
chmod o-x /sbin/drbdmeta
chmod u+s /sbin/drbdmeta

En ambos nodos creamos el dispositivo para el recurso:

drbdadm create-md r0

Acto seguido iniciamos el servicio:

/etc/init.d/drbd8 start

Ahora en el nodo que inicialmente será el maestro (nodo1) ejecutamos:

drbdadm — –overwrite-data-of-peer primary r0
mkfs -t ext3 /dev/drbd0
mkdir /var2
mount /dev/drbd0 /var2

En el nodo2 creamos el directorio var2 (mkdir /var2).

Para iniciar la sincronización entre ambos nodos introducimos el siguiente comando en el nodo primario (nodo1):

drbdadm — connect all

En ambos nodos eliminamos el incio automático del software que será balanceado, ya que éste será iniciado mediante HA:

update-rc.d -f opsview remove
update-rc.d -f opsview-web remove
update-rc.d -f mysql remove
update-rc.d -f apache2 remove
update-rc.d -f opsview-agent remove

En ambos nodos reemplazados el fichero /etc/ha.d/ha.cf por el siguiente:

—-
debugfile /var/log/ha-debug
logfile /var/log/ha-log
keepalive 2
deadtime 30
warntime 10
initdead 120
auto_failback off
bcast eth0
# This is a ping test in our network to check which server can ping it
ping X.X.X.X # IP virtual a la que los clientes deberán dirigirse para utilizar los servicios ofrecidos en HA
node nodo1
node nodo2
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster
—-

Em ambos nodos reemplazamos el fichero /etc/ha.d/haresources por el siguiente(idéntico en los dos nodos):

—-
nodo1primario drbddisk::r0 Filesystem::/dev/drbd0::/var2::ext3 10.10.10.120 mysql opsview opsview-web apache2
# nodo que actua de primario, recurso, filesystem, punto de montaje, IP virtual, servicios en HA
—-

En ambos nodos reemplazamos el fichero /etc/ha.d/authkeys por el siguiente:

—-
auth 1
1 sha1 MySecret
—-

Modificamos los permisos del fichero /etc/ha.d/authkeys:

chmod 600 /etc/ha.d/authkeys

Una vez sincronizados deberemos preparar /var em ambos nodos para que los datos a compartir por los servidores estén en la partición en HA.
Para ello vamos a tomar el recurso compartido en el nodo2, realizaremos la preparación, acto seguido repetir los pasos, tomando el recurso
el nodo1 y haciendo la misma preparación:

En el nodo1 “soltamos” el recurso:

umount /var2
drbdadm secondary r0

En el nodo2 “cogemos” el recurso:

drbdadm primary r0
mount /dev/drbd0 /var2

A continuación vamos a preparar /var y /var2. La idea es que los recursos que se necesitan en HA estén realmente en /var2, aunque la máquina
a nivel local los trate como si estuvieran en /var.

cd /usr/local/
tar cvzf nagios.tar.gz nagios
mv nagios.tar.gz /var2
rm -r nagios
cd /var2
tar xvzf nagios.tar.gz /var2
ln -s /var2/nagios /usr/local/nagios
cd /usr/local/
tar cvzf opsview-web.tar.gz opsview-web
mv opsview-web.tar.gz /var2
rm -r opsview-web
cd /var2
tar xvzf opsview-web.tar.gz /var2
ln -s /var2/opsview-web /usr/local/opsview-web
cd /var/lib/mysql
tar cvzf mysql.tar.gz mysql
mv mysql.tar.gz /var2
rm -r mysql
cd /var2
tar xvzf mysql.tar.gz /var2
ln -s /var2/mysql/ /var/lib/mysql/mysql

Reemplazamos los agentes NRPE de Nagios:

apt-get install nagios-nrpe-server nagios-plugins-basic
rm /etc/nagios/nrpe.cfg
cp /var2/nagios/etc/nrpe.cfg /etc/nagios/nrpe.cfg

Editamos el fichero /etc/nagios/nrpe.cfg y lo modificamos para cambiar las rutas “/usr/local/nagios/libexec” por “/usr/lib/nagios/plugins”
Reiniciamos el servicio:

/etc/init.d/nagios-nrpe-server restart

Tras realizar el último paso en el nodo1 podemos reiniciar las máquinas y dispondremos de OPSView en HA.
Para acceder al servicio los clientes deben dirigirse a la IP virtual, en este caso http://X.X.X.X:3000

:: NOTAS ::

Un error comun a la hora de sincronizar con drbd es el “Repair Split-Brain detected, dropping connection!”

Para solucionarlo debemos seguir los siguientes pasos:
Paramos el heartbet en ambos nodos.
En el secundario ejecutamos el siguiente comando:

drbdadm — –discard-my-data connect r0

En el primario ejecutamos el siguiente comando:

drbdadm connect r0

Si aún con ello no levanta probamos el siguiente comando en el primario:

drbdadm primary r0

:: Referencias ::

http://docs.opsview.org/doku.php?id=opsview2.14:hamaster-debian-howto
http://wiki.centos.org/HowTos/Ha-Drbd
http://www.estrellateyarde.es/discover/drbd-en-linux
http://liyuangarcia.blogspot.com/2007/11/cluster-de-alta-disponibilidad-sobre.html
http://gobok.serveblog.net/system-admins/howto-repair-split-brain-detected-dropping-connection/

Compártelo

Es un artículo que repasa brevemente las capacidades de este detector de intrusos y aborda su instalación en modo local sobre un Slackware Linux, ideal para que los interesados en el tema puedan iniciarse.

El artículo tiene un marcado caracter divulgativo y creo que es interesante ya que la reciente adquisición del proyecto a manos de una consultora importante ha dado un nuevo empuje al mismo, desde entonces han salido varias versiones. La mejora es evidente y no hay duda de que será una herramienta con una relevancia cada vez mayor.

Compártelo

1. El 4 de Julio se hacia publica una nueva versión de OSSEC, la v1.5.1. Leyendo el Changelog se puede apreciar que las correcciones han sido leves. OSSEC se ha caracterizado por no actualizarse muy a menudo pero parece ser que desde la compra esto ha cambiado (había prisa por publicar una nueva release bajo el apadrinamiento Third Brigade).

2. El mismo 4 de Julio en el Blog de Daniel B. Cid (autor de OSSEC) aparecía un interesante artículo en el que se explica como compilar y utilizar la herramienta ossec-logtest, incluida en el IDS y que nos permite la comprobación de las reglas utilizadas por el sensor y, lo que es más importante, nos sirve de depurador para la creación de reglas propias.

3. Cuatro días más tarde se publica un nuevo artículo más interesante aún si cabe que el anterior: OSSEC empieza a desarrollarse para comprobar el cumplimiento con los CIS benchmark tests. Para quién no sepá qué son estos test una gran referencia es el Blog SDB (Security By Default) que hace poco publicó un interesante artículo al respecto.

Actualmente solo se comprueba la comformidad para sistemas Debian y Ubuntu/Kubuntu/Xubuntu pero la idea es ampliar estos test e incluso cubrir las políticas FDCC, lo cual sería muy pero que muy interesante. Hay que recordar que actualmente a excepción de las herramientas gratuitas de CIS no hay ninguna herramienta OpenSource que compruebe estas políticas ( las reglas DirectFeed de Nessus son de pago ).

Compártelo

1. OSSEC seguira siendo OpenSource.
2. Daniel B. Cid seguirá siendo el lider del mismo.

Esta historia ya ha sucedido recientemente con SGUIL (comprada por CISCO), con ClamAV (adquirida por SourceFire) y ya hace algún tiempo con Nessus (absorbida por Tenable Network Solution).

Es un gran paso para alguien que comienza con un pequeño proyecto OpenSource y sueña con poder dedicarse a él plenamente.

Como nota señalar que hace poco escribí un artículo sobre OSSEC para hakin9, que debido a su suspensión temporal será publicado en el próximo número de Linux+.

Compártelo

Por otro lado Ossec ha sacado nueva release con importantes novedades (ver el anuncio oficial). Nuevamente he colaborado con el beta testing de la release sobre Slackware con resultados satisfactorios y me eleva muco el ego ver que aparezco en los créditos como colaborador.

Compártelo

El propósito de este post es demostrar que, si bien la correlación de eventos puede detectar intentos de intrusiones no es la panacea ni muchísimo menos. En concreto nos centramos en la “única” regla anti XSS de OSSEC. Esta regla se encuentra en el fichero web_rules.xml y tiene el siguiente aspecto:

<rule id="31105" level="6"><if_sid>31100</if_sid><url>%3Cscript|%2Fscript|script>|script%3E|SRC=javascript|IMG%20|</url><url>%20ONLOAD=|INPUT%20|iframe%20</url><description>XSS (Cross Site Scripting) attempt.</description><group>attack,</group></rule><br />

Como podemos apreciar las reglas de correlación de eventos son facilmente entendibles debido a que están escritas en formato XML. En este caso se basan en una pequeña lista negra:

%3Cscript
%2Fscript
script>
script%3E
SRC=javascript
IMG%20
%20ONLOAD=
INPUT%20
iframe%20

Esta regla está relacionada con la que veremos a continuación:

<rule id="31106" level="12"> <if_sid>31103, 31104, 31105</if_sid><id>^200</id><description>A web attack returned code 200 (success).</description> <group>attack,</group></rule><br />

De manera que si la regla 31105 (XSS) salta y el código de resultado que devuelve el servidor es un 200 OK salta la alerta 31106 (A web attack returned code 200).

Lo primero que hay que destacar es que la búsqueda de patrones se realiza sobre los ficheros de log del servidor web. En el caso de Apache estos tags aparecerán en el fichero access_log con lo cual tenemos la primera debilidad: cualquier intento de XSS utilizando el método POST no será detectado. Tampoco serán detectados los intentos de XSS en las cabeceras http. Esto es debido a que por lo general una traza del fichero access_log tiene la siguiente pinta en el caso de un GET:

127.0.0.1 – - [27/Apr/2008:19:30:44 +0200] “GET /ossec/index.php?f=VALOR_DEL_PARAMETRO HTTP/1.1″ 200 259

En el caso de que se produzca inyección de código en el parametro f podrá ser correlado. Sin embargo en el caso de utilizar el método POST el valor del parametro no queda registrado en la traza por lo que no se puede correlar:

127.0.0.1 – - [27/Apr/2008:19:30:44 +0200] “POST /ossec/index.php HTTP/1.1″ 200 259

De la misma manera no quedan registrados los valores de la cabecera (El servidor Apache puede ser configurado para que sí se muestren aunque en su configuración por defecto no es así y no es habitual encontrarse con servidores Apache que muestren mucha más información en sus trazas de las expuestas anteriormente).

Nos situamos en el caso de que el ataque se produzca utilizando el método GET. En este caso el correlador de logs compara con la lista negra y en caso afirmativo produce una alerta:

** Alert 1209321044.76264: mail – web,accesslog,attack,
2008 Apr 27 20:30:44 MI_SERVIDOR->/var/log/httpd/access_log
Rule: 31106 (level 12) -> ‘A web attack returned code 200 (success).’
Src IP: 127.0.0.1
User: (none)
127.0.0.1 – - [27/Apr/2008:20:30:43 +0200] “GET /ossec/index.php?f=s%3Cscript HTTP/1.1″ 200 2593

Vemos que en este caso el patrón %3Cscript ha hecho saltar las alarmas. A partir de aqui no es dificil imaginar que la correlación con la lista negra es facilmente evitable.
Si probamos esa misma inyección de manera ofuscada en código hexadecimal comprobados la cadena en el fichero access_log:

127.0.0.1 – - [27/Apr/2008:20:41:28 +0200] “GET /ossec/index.php?f=s%3c%73%63%72%69%70%74 HTTP/1.1″ 200 2593

Sin embargo en el detector de intrusos no salta la alarma. Hemos conseguido realizar el ataque evandiendo el detector de intrusos.

Conclusiones.

La correlación de eventos puede prevenir algunos tipos de ataques web pero no es la panacea para la detección de los mismos. Estos detectores pueden ser evadidos sin demasiada dificultad. Las listas negras son a menudo insuficientes y tienen como riesgo añadido la falsa sensación de seguridad que aportan.

Compártelo

// Snort Database Settings

$maxRows = 15;
$pollTime = 5;

En realidad solo sirve para cuando estés continuamente pegado a la pantalla para ver los ultimos eventos, ya que no guarda información de ningún tipo, pero es muy util sobre todo para realizar pruebas cuando estamos creando reglas, ver si saltan, etc.
Aqui podemos ver una captura de pantalla:

Compártelo

En esta ocasión el escenario no cambia: internet, repite parte del reparto con m313( yo mismo ) y mi libro( la guia de Snort ) y hay nuevos actores en escena: Sourcefire, o lo que es lo mismo: la empresa propietaria de Snort.
La trama es la ya conocida, han publicado mi guia en la web oficial !!!!

Seguimos en la cresta de la ola

Compártelo

El caso es que ha salido la nueva versión de OSSEC y en el mismo artículo de presentación mi tocayo Daniel B. Cid me nombra entre los agradecimientos, en esta ocasión por hacer de beta testing, si bien mantengo correos electrónicos con él sugiriendole mejoras en las reglas de detección y espero ser más util en futuras versiones.

Estamos en la cresta de la ola, que no lo olvide nadie.

Compártelo