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.

Esta nueva funcionalidad se está activando progresivamente y en unas semanas todos podremos disfrutar de una navegación más segura. Para activar el https, deberemos acceder a Configuración de la cuenta → Seguridad de la cuenta donde podremos ver algo como esto:

Una vez seleccionada la opción “https” pasaremos a ver la la barra de direcciones de color verde, como en la siguiente imagen:

La otra mejora que ha añadido Facebook tiene como función evitar que un atacante que haya conseguido nuestras credenciales pueda acceder a nuestra cuenta. Para ello, si por ejemplo accedemos a Facebook desde una dirección IP de Valencia, y en pocas horas, nos volvemos a loguear desde una IP rusa, Facebook detecta que ha habido una actividad sospechosa, y deberemos validarnos como los propietarios de la cuenta. Para ello, se nos mostrarán fotos de nuestros amigos, las cuales deberemos de reconocer.

Esta última medida tiene un pequeño “inconveniente”. Hay usuarios que son jugadores muy activos de juegos como FarmVille, CityVille, etc., que se dedican a agregar amigos que no conocen solo por el simple hecho de obtener dinero virtual. Estas personas, si necesitan alguna vez realizar una autenticación social, es muy probable que no superen la prueba y tengan que pedir un cambio de contraseña (sin contar con los problemas de privacidad asociados).

Desde mi punto de vista, Facebook ha mejorado bastante en materia de seguridad. Aparte de las medidas aquí descritas, hace relativamente poco se introdujeron las funcionalidades de logout remoto y one-time passwords que hacen que nuestros datos sean un poco más seguros. Y aunque por defecto, la privacidad sigue siendo escasa, se puede configurar nuestra cuenta para obtener una mayor seguridad y privacidad.

Nada más. Pasen un buen fin de semana, aunque sea frío y pasado por agua.

Dado que aspectos como la movilidad y el geoposicionamiento están poniéndose cada vez más de moda, en este post me gustaría repasar las diferentes tecnologías existentes y las implicaciones de privacidad, que en algunos casos son muy importantes. Veamos pues de qué estamos hablando.

• Métodos de posicionamiento por parte de “la red”
  • Posicionamiento por célula telefónica: La red de telefonía móvil sabe en cada momento dónde está cada teléfono móvil, con una precisión que varía según las células pero que puede estar entre 1 Km y 35Km. Así pues, la compañía de teléfonos sabe dónde estas, y si eso no fuese suficiente, esta información la almacenan, por lo que si llevas tu móvil encima, saben donde has estado en cada momento de tu vida. ¿Se puede acceder a esta información? Sí. Las Fuerzas de Seguridad del Estado están autorizadas para ello si lo solicitan a las operadoras mediante orden judicial. Por ejemplo, tras el atentado del 11-M, sea accedió a dicha información que fue clave para encontrar a los terroristas, ya que un móvil fue encendido antes del atentado en otra ubicación donde tenían su base.

    [Read more…]

He decidido poner el término Cloud computing en el titulo del post para tener mas visitas, ya que es un termino de moda, pero si me disculpan la pequeña “trampa”, en su lugar voy a hablar de la seguridad en Infraestructuras compartidas, que es un tema tanto o más interesante en seguridad.

Cuando hablamos de Infraestructuras compartidas nos referimos a la serie de infraestructuras TI que en cualquier organización son compartidas por diversos proyectos. Por ejemplo es habitual que se comparta la infraestructura de red, el almacenamiento en una cabina de discos, o los mismos servidores físicos mediante virtualización; si es un proveedor de servicios el que ofrece la infraestructura, estos elementos estarán compartidos además entre diversos clientes que en si mismo son organizaciones diferentes (vamos, el servicio de hosting de toda la vida).

Así pues, vamos a comentar diversas vulnerabilidades que con las medidas adecuadas están contempladas y en teoría resueltas, pero que son en todo caso posibles vulnerabilidades que pueden aparecer cuando se comparten infraestructuras.

Infraestructura de red compartida: No es difícil imaginar un escenario donde tenemos varios servidores conectados a la misma infraestructura de red, donde, si todo se configura bien no deberían haber problemas, pero si se configura mal, pueden pasar entre otras las siguientes cosas: (1)

• Sniffing: Un equipo puede ver el trafico del equipo de al lado; esto puede pasar si están conectados al mismo switch y no se han tomado las necesarias precauciones (arp posisoning).
• DOS: Al estar un equipo próximo a otro, puede atacarlo con un gran ancho de banda o un gran numero de conexiones.
• Interceptar/sustituir: Es posible que un equipo pueda suplantar a otro (p.e. cambiando la IP) para interceptar el trafico o suplantar respuestas.
• Atacar: Es posible que al compartir una misma infraestructura de red, desde dentro de la misma red (por ejemplo dentro de la misma DMZ) los equipos puedan atacar a los otros, teniendo mas visibilidad de servicios que desde el exterior están cerrados. Una descripción de cómo hacer esto pueden encontrarla aquí.

¿Están las infraestructuras de red compartidas convenientemente independizadas en los servicios de hosting y de Cloud?

Infraestructura de disco compartida: En cualquier infraestructura TI, es habitual que se disponga de una cabina de disco (SAN/NAS) a la que se conectan todos los servidores (desde servidores internos, hasta servidores de la DMZ)(2)

• Acceso a datos (no autorizados): Técnicamente es posible que un servidor se conecte al disco de otro servidor si comparte cabina, con lo que podría leer o incluso alterar los datos. Las cabinas de disco normalmente limitan qué servidor puede conectar a qué parte de disco, basándose en la direccion “MAC” (se llama WWN) de la tarjeta. ¿Podría un hacker cambiar esa dirección? ¿Tenemos hard-zoning para evitar este ataque? Aun no he visto ninguna instalación en que se configure hard-zoning ya que es bastante mas incómodo. Si piensa que es muy raro que todos los servidores tengan acceso a los mismos discos, piense en todos sus servidores host de virtualizacion que pueden acceder a todos los discos del cluster.
• DOS/Carga: ¿Qué pasa si un servidor monopoliza todos los recursos?
• Acceso a datos borrados: ¿Qué pasa si montamos una unidad de disco en el servidor de un cliente y luego la conectamos a otro servidor de otro cliente? ¿Si leemos el disco vemos los datos del otro cliente? Muchos me diréis que es una posibilidad muy extraña ya que las cabinas de discos limpian las LUNs antes de asignarlas, pero esto “se le paso” a Amazon Ec2.

¿Están las infraestructuras de almacenamiento convenientemente independizadas en los servicios de hosting y de Cloud? (3)

• Virtualización: Cualquier entorno TI de hoy en día dispone de servidores virtualizados, ya que es una de la manera mas efectivas de compartir recursos, garantizar la disponibilidad, ahorrar energía y muchas otras cosas. Numerosos sistemas Cloud (IAAS) están basados fundamentalmente en sistemas virtualizados, con APIs de autoprovisionamiento. Veamos algunos de los ataques que se pueden realizar en este tipo de entornos.
  • Ataques de guest a host: Ya han aparecido vulnerabilidades mediante las cuales un guest ha podido ejecutar código en el espacio del host, y por lo tanto desde un servidor virtual es posible atacar a otras maquinas virtuales. Véase este enlace para más detalles.
  • Consolas remotas compartidas (el “control panel” del cloud): Si tenemos un sistema de virtualización compartido, al cual accedemos desde una consola de gestión remota a través de Internet, ¿qué pasa si esta consola de gestión tiene alguna vulnerabilidad y alguien coge el control? Pueden haber muchos posibles problemas, desde vulnerabilidades de la aplicación de gestión remota (XSS para robo de sesión sería un ataque viable) a posibles pérdidas de credenciales. La autenticación de estos sistemas por ahora es simple y sin dispositivos robustos. Otro vector de ataque pueden ser las APIs de gestión de ofrecidas por los servicios de cloud, ya que mediante estas APIs se pueden crear o destruir servidores; ¿seguro que no hay vulnerabilidades mediante las cuales se puedan crear o destruir servidores de otro cliente?
  • Carga/DOS/QOS: ¿Qué pasa si un cliente monopoliza todos los recursos?
  • Vulnerabilidades del host (desde fuera, o desde los guests): El host es otro sistema que puede ser atacado, bien desde donde sea accesible (consola de gestión p.e.) o bien desde los propios guest que debido a alguna vulnerabilidad son capaces de coger control de host. Dicho de otra forma, aunque uno pueda tener su servidor web y sus aplicativos securizados, quizá el host que los alberga no lo está.
• Servidores web/servidores de aplicaciones compartidos: Es habitual compartir el mismo servidor de aplicaciones entre diversos proyectos, pero hay que contemplar los problemas que nos podemos encontrar:(4)
  • Tienen acceso al mismo almacenamiento.
  • Son el mismo usuario de maquina/BBDD/memoria.
  • QOS: Puede un usuario degradar el rendimiento de todos los usuarios.

  Un ejemplo de estos servicios en la nube son: Windows azure o Google Application Engine.

¿Están las infraestructuras de virtualización convenientemente independizadas en los servicios de hosting y de Cloud?

Hosting/Aplicaciones SAAS compartidas: Dentro de lo que está tan de moda del cloud, también se incluyen de alguna manera las aplicaciones compartidas modelo cloud (SAAS). En el fondo, éste es el modelo mas antiguo de hosting, en el que las aplicaciones originales eran servidores web, servidores de correo compartidos entre diversos clientes. Hoy en día se ofrecen aplicaciones mas elaboradas que ofrecen más valor a las organizaciones. Veamos qué problemas nos podemos encontrar en estos modelos.

Imagínese que comparte aplicación entre “perfiles” o clientes. Es posible que dos usuarios de la misma aplicación, por algún error de diseño de ésta, tengan acceso a lectura o modificación de otro usuario. Por ejemplo, recordarán que hace poco sucedió que un usuario de facebook podía ver cualquier conversación del chat de otro. Así pues, si usamos de manera compartida una “aplicación” SAAS, nos podemos encontrar con posibles problemas si no ésta no está bien implementada. ¿Podría pasar que en nuestro CRM en SAAS por un error de programación pudiéramos ver los clientes de otra empresa también albergada en este SAAS? Facebook tuvo una vulnerabilidad con la que podías ver los chats de otros usuarios.

¿Están las aplicaciones convenientemente independizadas en los servicios de hosting y de Cloud? (5)

Mira por dónde, sin quererlo, he acabado hablando de Cloud Computing, nada nuevo respecto a lo que ya conocemos en cuanto a infraestructuras compartidas, pero sin duda una novedad en cuanto a que está todo junto, con las ventajas que esto aporta, pero con el añadido que hay que considerarlo todo conjuntamente.

Por repasar los tipos de Cloud existentes:

• IAAS, Infraestructure as a service: básicamente podríamos decir que tenemos una macroplataforma virtualizada bajo demanda (1)(2)(3).
• PAAS, Platform as a Service: tenemos una especie de servidor de aplicaciones distribuido y autoescalable (4).
• SAAS, Software as a Service: tenemos una aplicación general la cual nos da servicio (5).

En este post hemos revisado algunas vulnerabilidades desde un punto de vista técnico que aparecen si compartimos infraestructuras. Desde el punto de vista de control sobre los servicios externalizados y concentrados en datacenters de megacorporaciones también hay mucho que hablar, y por otro lado los proveedores de sistemas virtuales están redefiniendo sus productos haciendo que cada vez se parezcan mas a una nube “privada” en cuanto a que se dispone de unas infraestructuras compartidas autogestionadas. Todas la posibles vulnerabilidades mencionadas sólo son posibles puntos de fallo por donde aparecerán vulnerabilidades, que aunque en principio ya están contempladas y cubiertas, debemos contar que irán apareciendo nuevas vulnerabilidades causadas por compartir infraestructura. Si dicha infraestructura es sólo compartida entre proyectos internos de la organización los riesgos son unos, pero si la infraestructura es compartida con no sabemos quién, y disponible en Internet los riesgos son mayores. Esto es lo que hay que saber valorar.

A pesar de ello, los servicios en Cloud son la evolución lógica de hosting (infraestructuras compartidas de toda la vida). Todo lo que tuviera sentido en ese entorno ahora lo puede tener en la nube; en todo caso los proyectos que necesitan una grandísima escalabilidad normalmente están asociados a accesos desde Internet, en cuyo caso la nube tiene todo el sentido del mundo, ya que nos permite acceder a proveedores con grandes capacidades de almacenamiento, ancho de banda y servidores. Es más, me atrevería a apostar que los proveedores serios de Cloud sí tienen en mente que todos los recursos compartidos deben estar independizados, y probablemente sean más conscientes de estos riesgos que los provedores de hosting más tradicionales, con aproximaciones más “ligeras” al Cloud.

Dicho esto, pasen un buen fin de semana, y ¡¡nos vemos en la nube!!

Recientemente recibimos un curso de Seguridad en SAP durante el que se analizaron los aspectos más importantes en la seguridad de estos entornos y los errores más comunes que pueden encontrarse en una implantación SAP. SAP es un sistema de planificación de recursos empresariales o ERP que permiten, mediante módulos, la integración y control de todas las operaciones relacionadas con la compañía, y como podrán imaginarse una reducción de costes para ésta. Se compone de una serie de módulos que realizan una función en concreto, como la gestión de almacenes (WM), producción (PP-PI), gestión de calidad (QM), gestión de materiales (MM), etc. Cada uno de estos módulos proporcionan al entorno SAP un mayor número de funcionalidades. En esta entrada de Security Art Work se comentarán, de forma resumida, los procesos correctores más comunes en el ámbito de la seguridad dentro de un sistema de estas características.

Los aspectos más habituales de seguridad SAP se centran en la parametrización general del sistema, la configuración de transacciones incompatibles desde el punto de vista operativo en el entorno de los procesos de negocio, la segregación de funciones y la gestión de identificación y autenticación de usuarios. Pero antes de comenzar a tratar cada uno de los puntos expuestos con anterioridad, debemos presentar el concepto de mandante. Un mandante es un subsistema o unidad independiente dentro de un sistema SAP. Las acciones que se realizan dentro de cada mandante reciben el nombre de transacción. Éstas son órdenes que llaman a un programa escrito en ABAP, que a su vez realiza transacciones a través del core de SAP, consultando en la mayoría de los casos la base de datos.

Desde el punto de vista de seguridad, los mandantes deben estar cerrados y no permitir las modificaciones a objetos del repositorio y la parametrización no dependiente del mandante. Para ello hay que restringir las transacciones SE06 y SCC4 indicando que no son modificables, no se debe permitir la comparación de customizing ni admitir cambios no dependientes del mandante, se debe seleccionar el nivel 2 de protección e indicar que el rol del mandante es de tipo productivo. Otras transacciones críticas a tener en cuenta a la hora de restringir su acceso son la SV01 (gestión de usuarios), SN01 (transacciones que se pueden realizar) y SCC5 (borrar el mandante).

Los mandantes por defecto en todo sistema SAP son 000, 001 y 066. Si no existe usuario para estos mandantes se podrá acceder a este mediante el usuario SAP* y la contraseña PASS, de la misma forma que si existen los usuarios por defecto, estos serán SAP* y DDIC, con contraseña 06071992 y 19920706 respectivamente. Otros usuarios por defecto son SAPCPIC y EARLYWATCH (sólo mandante 066), todos ellos con permisos de administración. Por tanto es importante en toda implantación SAP -como en toda implantación a secas- cambiar las contraseñas por defecto de dichos usuarios mediante el report RSUSR003.

En el entorno SAP existen una serie de transacciones que deben ser limitadas, incluso impedir desde cualquier usuario su llamada, debido a los riesgos de seguridad que implican. Principalmente se trata de la SE11, SE16, SE30, SA38, SM30, SE16m y SM49, y debemos prestar especial atención a RSBDCOS0, SM38 (shell de sistema), SM49 (creación de órdenes del sistema) y SM59 (ejecución de órdenes en el sistema). Otro punto de control a tener en cuenta son aquellas transacciones desarrolladas a medida para la empresa por un equipo de desarrollo no perteneciente a SAP y que, por tanto, no han pasado por el equipo técnico de calidad de SAP. Estas transacciones se identifican por la primera letra del nombre de la transacción (letra Z o letra Y) y son las llamadas transacciones Z* o Y*. Deben cumplir con unos requerimientos mínimos de seguridad que limiten su ejecución a los usuarios autorizados para ello; estas restricciones específicas se conocen con el nombre de authority-check y sin ellas cualquier usuario con acceso a la transacción de lanzamiento SE38 o SA38 podría ejecutar dichas transacciones (existe el report RSRSCAN1 que permite comprobar si se están realizando los correspondientes comprobaciones de autorización).

Otro aspecto de seguridad en el ámbito de SAP es el relacionado con la gestión de usuarios; de entrada, no se debe permitir a un usuario saltar a otro mandante distinto al asignado, para lo que aquellos usuarios que se conecten de forma remota (ya sea mediante la interfaz Web o mediante el cliente R/3) deben de estar configurados como usuarios de fondo y NO como diálogo. De la misma forma, es recomendable la aplicación de políticas de seguridad que fuercen al uso de contraseñas seguras, por ejemplo empleando la transacción SM30 → USR40 para especificar, mediante expresiones regulares, qué contraseñas no son válidas y un diccionario de palabras no permitidas. Adicionalmente, mediante el uso del report RSPARAM, se pueden parametrizar aspectos como el número de logins incorrectos, longitud mínima de la contraseña, seguimiento de la inactividad, etc.

Finalmente, pero no por ello menos importante, debemos hablar de una segregación de funciones correcta en SAP, que no permita a un determinado usuario acceso a determinadas combinaciones de transacciones; para ayudar en esta segregación de funciones, SAP dispone del report RSVR008_009_NEW, que permite indicar las combinaciones críticas existentes en el sistema.

Seguiremos añadiendo algún post de este mundo -SAP- que hasta el curso que hemos comentado, desconocía por completo y que, una vez hemos comenzado a entrar en él, se adivina inmenso -y conflictivo- desde el punto de vista de su seguridad.

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