m313 Security Blog

===============================
- Rooted CON 2010 -
C A L L F O R P A P E R S
===============================

.: [ 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

OPSView es un sistema de monitorización libre. El siguiente tutorial cubre la instalación de dos servidores maestros de monitorización en alta disponibilidad. Está realizado sobre Debian Linux y aunque hay tutoriales y documentación en la página oficial, si queréis montar dos Debian maestros en HA no os recomiendo seguir la guia oficial al pie de la letra (yo ya lo hize).
La guía mostrada a continuación no es enteramente mía. Está basada en documentación oficial y en trozos de las páginas que menciono en el apartado referencias. Además no habría podido realizarla sin la ayuda de mis compañeros adolfop, 4lv3rn3, spanic y vege10n. Ahí vamos:

::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

No he hecho nunca publicidad de ninguna revista en mi blog. Esta vez es diferente, os animo a todos a comprar el número de Septiembre de la revista Linux+ ¿Porqué? Porque en este número he escrito un artículo sobre el detector de intrusos OSSEC.

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

Hace poco comentaba la compra de OSSEC por parte de Third Brigade. Parece que a raiz de esto la aplicación ha recibido un nuevo impulso y en apenas dos semanas han aparecido nuevas e interesantes funcionalidades:

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

El proyecto OSSEC ha sido comprado por la consultora Third Brigade.
Podemos ver la noticia tanto en la web del proyecto como en la de la consultora. Lo que a todos nos interesa es saber en qué va a afectar esto al popular HIDS. Daniel B. Cid ha escrito en su blog un FAQ sobre esta adquisición sobre la que hay que destacar dos aspectos:

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