Auditoría RACF: Introducción y problemas de seguridad más frecuentes

Buenas,

Tenia pendiente hablar un poco de seguridad RACF en el blog, y una reciente conversación con un amiguete me ha recordado que le debía un articulo sobre el tema.

Voy a estructurar el artículo en dos grandes secciones:

  1. En primer lugar haremos una introducción, tanto técnica como no técnica, para comprender un poco mejor que es RACF y como funciona. El objetivo es disponer del conocimiento previo necesario para abordar la auditoria con garantías, evitando la tentación de que el trabajo lo realicen personas que siguen un programa de trabajo sin entender realmente que se cuece por debajo (tristemente, algo usual en el mundo de la auditoría de sistemas)
  2. Seguidamente daremos un repaso a los 10 errores mas frecuentes en la configuración de seguridad RACF. Cumplir estos 10 puntos no garantiza que la seguridad del montaje sea ideal, pero su análisis facilita realizar una auditoria rápida y determinar, sin la necesidad de invertir una cantidad de recursos enorme, una primera fotografía del estado del gestor de seguridad.
  3. Queda pendiente, quizás para otro artículo futuro, hablar de los pasos de auditoría usuales en RACF, que son muchos más que diez. Es un tema denso, y nos puede llevar llevar una decena de artículos tranquilamente. De momento pondremos atención a la introducción y los problemas más frecuentes.

1. INTRODUCCIÓN Y FUNDAMENTOS TÉCNICOS DE RACF

En el mundo de los mainframes IBM, Resource Access Control Facility (RACF) es probablemente el estándar de facto a la hora de gestionar la seguridad del sistema. No es la única solución, ya que existen competidores con ofertas similares, como es el caso de ACF2 y TopSecret, de Computer Associates, aunque me atrevería a decir que el grueso de la clientela de estos mainframes se suele inclinar por RACF por una razón sencilla y obvia: es una solución muy decente y la facilita el propio fabricante, con lo que no hay que andar negociando con terceros la presencia de software crítico en el sistema, especialmente en lo que a implementación y mantenimiento se refiere.

RACF es una solución que tradicionalmente ha proporcionado a los sistemas z/OS y z/VM control de acceso (autenticación y autorización) y trazas de auditoria. La tendencia actual y futura es, sin embargo, que RACF se ocupe de otras tareas, como por ejemplo, servicios PKI, y que pueda ser empleado por otros sistemas además de los mainframes, como por ejemplo los derivados UNIX.

RACF es complejo, y auditarlo no es una tarea sencilla. Existen infinidad de puntos de control que podemos auditar y por tanto, el trabajo puede extenderse durante periodos prolongados de tiempo si no definimos un alcance acotado. Tal y como hemos mencionado anteriormente, nos centraremos solo en aspectos esenciales, dejando al lector la tarea de documentarse y ampliar el programa de trabajo que aquí esbozaremos.

Técnicamente hablando merece la pena comentar que el control de acceso y la auditoria la realiza en primera instancia SAF (System Authorisation Facility). Cuando cualquier porción de código requiere la toma de decisiones relacionadas con la seguridad, se constituye lo que se denomina un punto de control. Estos puntos de control le pasan a SAF la información necesaria para que SAF pase a gobernar la situación a través del uso del servicio RACROUTE.

SAF es un componente que los gestores de recursos utilizan para poder determinar el curso de acción en acciones de control de acceso y auditoria. Sin embargo, lo normal es que este servicio se configure para delegar en RACF (o en el gestor de seguridad que se haya escogido) los citados mecanismos. SAF puede funcionar sin software satelital de apoyo en un modo independiente, pero esto es extremadamente infrecuente. Es parte del sistema operativo base z/OS y puede ser invocado desde numerosas instancias en el sistema, incluso por software de terceros. Es habitual encontrar en la literatura referencias al router SAF para denominar al punto único de gestión del componente al que se dirigen las peticiones que deben ser procesadas.

Las tres funcionalidades de seguridad que hemos mencionado (autenticación, autorización y auditoria) se corresponden con tres definiciones del servicio RACROUTE claramente diferenciadas:

  • Autenticación y verificación: RACROUTE REQUEST=VERIFY
  • Autenticación: RACROUTE REQUEST=AUTH
  • Auditoria: RACROUTE REQUEST=AUDIT

Existen otros servicios RACROUTE además de los citados, como DEFINE (para definir, modificar, renombrar o eliminar un recurso de RACF), DIRAUTH (para comparar dos etiquetas de seguridad), EXTRACT (para recuperar o reemplazar determinados campos en un perfil RACF), FASTAUTH (para comprobar la autorización de acceso a un recurso por parte de un usuario), LIST (para aprovisionar perfiles), SIGNON (para gestionar las listas de acceso relacionadas con verificación persistente) , STAT (para determinar si RACF esta activo), TOKENBLD (para construir UTOKENS, user tokens, los tokens de seguridad de un usuario), TOKENMAP (para mapear un token del sistema) y TOKENEXTR (para extracción de UTOKENS).

Respecto a los mecanismos de auditoria, es frecuente que en sistemas z/OS se hable de los mensajes SYSLOG y los eventos SMF. Cuando los requisitos de seguridad son elevados se hace indispensable la conservación de todo lo disponible, lo que suele generar un problema de almacenamiento especialmente relevante, sobre todo si el sistema es un sistema transaccional, donde los registros de auditoria que derivan de cientos o incluso miles de operaciones por segundo pueden y de hecho requieren cantidades ingentes de almacenamiento, lo que en la practica hace necesario seleccionar con inteligencia que eventos se conservaran, dejando fuera los que no aportan valor para la instalación. Normalmente SYSLOG se ocupa de mensajes operacionales, aunque no debemos descartar su utilización para la monitorización de seguridad.

Respecto a que tipos de registros SMF conservar no existe mucho consenso al respecto, o yo al menos no he encontrado nunca una definición exacta. Todo dependerá de los requisitos de seguridad y operación de la maquina. Así, por poner un ejemplo, desde el punto de vista de seguridad, el tipo 119 -que ofrece estadísticas TCP/IP- podría de entrada ser poco relevante para ciertas organizaciones, mientras que otras grabaran con gusto los subtipos 119-70 y 119-72, que registran transferencias FTP completadas y errores de acceso vía FTP. En lo que a estrictamente seguridad se refiere, los tipos ochenta son los que suelen tener mas relevancia. El tipo por excelencia suele ser el 83, el registro de auditoria para juegos de datos, siendo el tipo 82 frecuente en mainframes financieros con requisitos criptográficos, como por ejemplo, autoservicios o puntos de venta. Los tipos 80 (procesamiento de productos de seguridad) y 81 (inicialización RACF) son igualmente interesantes y deben ser considerados. Menos frecuente es el tipo 84, para monitorizar el subsistema de entrada de trabajos JES3, aunque podría servir para implementar controles de acceso ilegitimo a producción. El tipo 85 es especifico al rendimiento de transacciones OAM, el tipo 88 esta relacionado con datos de almacenamiento de un sistema determinado en un Parallel Sysplex de producción, y el tipo 89 esta orientado a uso del sistema y los productos de seguridad que lo conforman, lo que suele ser empleado para obtención de información relacionada con licencias de uso.

La variabilidad de las trazas y su repercusión hace necesarios que antes de ponernos a examinar aspectos específicos obtengamos una buena imagen de lo que se esta grabando, tanto SYSLOG como SMF. Una vez entendamos que se esta auditando, estaremos en condiciones de emitir una mejor opinión.

2. LAS 10 PROBLEMÁTICAS MAS USUALES EN LA CONFIGURACIÓN DE SEGURIDAD DE RACF

Resulta muy difícil sintetizar en 10 las problemáticas habituales en un gestor RACF. A buen seguro si contactas a 10 auditores distintos, probablemente escucharás 10 versiones distintas, con lo que se hace realmente difícil reducir a un número determinado los problemas usuales. De entre las muchas opciones posibles me quedo con el decálogo de Vanguard, un fabricante de software de auditoría para RACF. De mayor a menor gravedad:

  1. Modos NOPROTECTALL o PROTECTALL(WARNING) activos. Quizás el peor de los problemas, y bastante frecuente además, por increíble que parezca. Estos modos de protección permiten disponer de data sets sin custodia completa de RACF, con lo que podrían ser creados y accedidos. La diferencia entre ambos es que el modo PROTECTALL(WARNING) al menos deja una traza de auditoría, mientras que NOPROTECTALL ni tan siquiera la deja. El caldo de cultivo ideal para un programador con conocimiento y ganas de colocar código malicioso en ejecución.
  2. Uso excesivo de atributos privilegiados. Este problema no sólo es patrimonio de RACF, sino de muchos otros sistemas. Es relativamente frecuente, por mal diseño de la solución, emplear los atributos SPECIAL y OPERATIONS en exceso, con el peligro que ello conlleva: ambos permiten acceso completo a la base de datos RACF y a todos los data sets de z/OS. Los identificadores de usuario con atributo SPECIAL deberían ser los mínimos posibles y sujetos a fuerte monitorización, y aquellos con atributo OPERATIONS no tienen razón de existir. Eliminadlos, y negociad sólo el uso de este atributo para usuarios no humanos que sean precisos para administrar la producción.
  3. Protección inadecuada en librerías APF. Las librerías APF (Authorized Program Facility) se emplean para agrupar programas que correrán en el sistema con privilegios especiales y que suelen tener impacto muy elevado en el sistema. Si estas librerías están mal protegidas, nada impide que alguien coloque en ellas programas que correrán con altos niveles de privilegios, causando problemas en el sistema que podrían llegar a desestabilizarlo, además de tener capacidad de evitar los mecanismos de seguridad. Este problema se puede solventar, entre otras medidas, con listas específicas de acceso. Caldo de cultivo para colocar código malicioso que pase inadvertido.
  4. Presencia de excesivos data sets con modo WARNING. El modo WARNING, aunque permite la escritura de una traza de auditoría y el aviso en tiempo real en la consola de operadores, no impide que se permita el acceso al recurso. El modo FAIL suele ser la mejor manera de abordar el problema, que siempre representa un claro indicativo de que la administración de seguridad es inadecuada.
  5. Colocación maliciosa de programas en las tablas de propiedades de programas con el atributo de salto de protección mediante contraseña. En este escenario, aplicando dicho atributo, se conseguirán data sets que no serán custodiados por los mecanismos de acceso de RACF, quedando invalidada la auditoría. Ojo.
  6. Accesos universales por defecto (UACC) incorrectos en data sets críticos. Este es un fallo típico, e implica que un determinado data set, si se configura con nivel de acceso inadecuado, puede quedar expuesto a cualquier usuario con cuenta en el sistema. La situación ideal es aplicar NONE a todos los datos como valor de UACC, dejando excepciones para READ cuando sea preciso. En el primer caso el acceso universal sería impedido, y en el segundo, sólo se permitiría la lectura.
  7. Tareas en ejecución con atributos inadecuados o erróneos de privilegio (PRIVILEGE) o confianza (TRUSTED). La concesión de estos atributos a las tareas en ejecución puede tener efectos catastróficos cuando la situación ni está justificada ni monitorizada. El atributo de privilegio tiene consecuencias tan graves como la ausencia de auditoría, mientras que el atributo de confianza sólo debe otorgarse a tareas del sistema base muy específicas y determinadas. Es frecuente que esto se pase por alto, mucho ojo.
  8. Ausencia de monitorización y gestión de incidentes. RACF está pensado para dotar al sistema de una granularidad en la seguridad excepcional, lo que permite construir mecanismos monitorización, notificación y alerta igualmente granulares. Por muy bien que se encuentre el gestor, no tiene utilidad ninguna si no está respaldado por un sistema de monitorización que permita detectar en tiempo y forma las problemáticas.
  9. Usuarios para la gestión de trabajos en producción con excesivas capacidades. Deriva también de la mala planificación y la administración inadecuada. Los usuarios con responsabilidad relacionada con el control de trabajos en producción tienen que tener sus capacidades restringidas a los trabajos que los atañen, debiéndose impedir que estos usuarios tengan acceso a todos los data sets del sistema. Adicionalmente, estos usuarios no deberían tener el atributo OPERATIONS, y en caso de ser estrictamente necesario, es obligatoria la monitorización.
  10. Número de usuarios inactivos excesivo. Un problema común causado por la ausencia de uan administración adecuada, y que no requiere más explicación. Se puede solventar automatizando la eliminación de usuarios periódicamente.

Espero que el artículo os haya sido de utilidad. Si os queda alguna duda, dejad un comentario :)

Saludos,

Análisis de volcados de núcleo colapsado (Kernel Crash Dump) y volcados de procesos en ejecución en auditorías de sistemas Unix

Hola,

Aunque no es un tema estrictamente relacionado con la seguridad, ya que los colapsos de núcleo pueden tener otros disparadores como por ejemplo el desarrollo y la depuración, quiero compartir con vosotros estas notas sobre cómo analizar este tipo de volcados. Como parte de la explicación veremos igualmente la potencial necesidad de estudiar estos volcados en una auditorí­a de un sistema de producción Unix. Llamaremos a estos eventos de colapso Kernel Crash Dump (KCD), ya que en la literatura es frecuente que se respete la acepción anglosajona original.

¿Por qué analizar KCDs?

Una de las grandes ventajas que ofrecen los núcleos derivados de Unix es la posibilidad de modificarlos para que, en un evento catastrófico, como por ejemplo pánico en el núcleo (kernel panic) salvemos una copia de la memoria. A muchos os sonará el término core dump, o volcado del núcleo, que no deja de ser una grabación de la memoria en el momento del evento catastrófico. Esto se hace fundamentalmente para habilitar una traza que permite detectar problemas, algo especialmente útil en el desarrollo de aplicaciones y complementos para el sistema y del propio sistema, pero también pueden tener utilidad para investigaciones de seguridad.

Los volcados de núcleo suelen estar relacionados con errores en el desarrollo, pero también es factible que se provoquen por la acción maliciosa de los usuarios del sistema. Generalmente, en caso de este segundo hipotético escenario, los volcados catastróficos pueden ser provocados de manera no intencionada, por ejemplo, al tratar de modificar un componente del sistema de manera maliciosa cometiendo algún error relevante que lleve al núcleo a un estado de pánico, aunque es igualmente factible que el estado sea inducido de una manera controlada, no sólo para el núcleo completo, sino para determinados procesos. Afortunadamente estos casos son enrevesados, requieren un conocimiento elevado y no suelen ser frecuentes, siendo mucho más frecuente la grabación de volcados legí­timos que luego quedan a merced, por una pobre configuración de seguridad, de los usuarios del sistema, los cuales pueden acceder a ellos y obtener datos especialmente sensibles.

Dejando atrás las implicaciones en la seguridad, las razones usuales para inspeccionar volcados son, principalmente, debidas a problemas que requieren depuración y análisis. Ejemplos usuales son sistemas que no responden adecuadamente, kernel y aplicaciones lentas, acceso constante a disco duro, fallos catastróficos, etc.

¿Cómo se analiza un Kernel Crash Dump (KCD)?

Aunque existen numerosas herramientas quizás la más completa sea crash de Redhat. Es ventajosa por múltiples razones, la primera es que permite el análisis de sistemas en ejecución, así­ como sistemas accesibles en red. También permite el análisis estático de volcados obtenidos con Kdump, makedumpfile, Diskdump y otras facilidades similares, incluyendo volcado s390/s390x incluso en entornos virtualizados (xendump). Desde el punto de vista técnico crash resuelve las limitaciones de utilizar gdb sobre /proc/kcore, especialmente la dificultad de acceder a la totalidad de la estructura del kernel si el fichero vmlinux se ha construido con determinados flags. Tampoco conviene olvidar que a veces el acceso a /proc/kcore es limitado dependiendo del entorno que estemos estudiando, con lo que quizás no sea la mejor fuente para obtener un volcado. Estas y otras razones han convertido a crash en prácticamente un estándar de facto en el análisis de volcados.

Los requisitos par analizar un KCD

En el caso de crash la utilidad puede ser lanzada en un sistema en ejecución, y hará uso de la memoria (/dev/mem) o incluso, en sistemas Red Hat y derivados, del dispositivo /dev/crash dispuesto al efecto. De todos modos no es normal realizar análisis en sistemas en ejecución, ya que habitualmente si están en ejecución es porque no presentan problemas, siendo mucho más usual proporcionar a la utilidad un fichero de volcado procedente de un sistema que ha sufrido un evento catastrófico que requiere estudio.

Para la obtención de un volcado destacamos Linux Kernel Crash Dump (LKCD), ya que producir un colapso en el núcleo no es, por motivos obvios, una funcionalidad innata del sistema. En este modo de operación son necesarios siempre dos componentes: un fichero vmlinux construido con los flags -g C (para que contenga los datos de depuración necesarios) y un volcado del kernel.

Nótese la diferencia entre los ficheros vmlinux y vmlinuz. En la mayorí­a de sistemas sólo estará presente el segundo, que es una versión comprimida y ejecutable del primero. Si vais a usar crash aseguraos de tener la versión descomprimida o de lo contrario la utilidad arrojará un mensaje del tipo cannot find booted kernel — please enter namelist argument. Sin vmlinux no es posible ejecutar crash sobre /dev/mem ni con ficheros de volcado. Aunque es factible realizar la descompresión manualmente, tened en cuenta que no es inmediata y que suele ser mucho más fácil recompilar el núcleo para disponer de ambas versiones.

Una vez se disponga de los requisitos comentados, se puede lanzar crash para efectuar el análisis. Si queréis conocer más de esta utilidad, podéis leer el documento http://people.redhat.com/anderson/crash_whitepaper/.

Analizado volcados de procesos

Lo descrito anteriormente tiene, desde el punto de vista de la seguridad, una gran problemática asociada. Los volcados del núcleo contienen absolutamente todo lo que estaba en ejecución, y por tanto son una fuente jugosa de información, pero quizás excesivamente abundante, lo que puede dificultar encontrar información. Adicionalmente, para tener un fichero de volcado hay que o bien inducir un evento de colapso (lo cual no es tan sencillo como parece), o bien esperar a que el sistema, de manera natural, colapse para que las utilidades que hayamos dispuesto graben la memoria del núcleo, si es que estas utilidades están instaladas. Esto, en un sistema Unix bien depurado no es algo que pase todos los dí­as. Incluso teniendo lo necesario no es trivial ahondar en las cadenas de texto de un volcado para localizar, por ejemplo, contraseñas, ya que no vienen marcadas como tal.

Para resolver este problema es posible recurrir, en vez de a la grabación e inspección completa del núcleo, al forzado de colapsos en determinados procesos. Estos son mucho más silenciosos y los ficheros a analizar son mucho más pequeños y nos permiten localizar información relevante de una manera más compartimentalizada. Para obtener volcados de procesos en ejecución existen múltiples opciones, si bien gcore facilita la tarea enormemente.

El análisis de procesos tiene sentido, una vez más, desde el punto de vista del desarrollo. Desde la oṕtica de la seguridad tendrá sentido cuando querramos determinar si los volcados que se puedan estar ejecutando pueden quedar a merced de los usuarios del sistema. Que nadie espere encontrar contraseñas en el volcado de un proceso SSH o FTP, ya que lo máximo que hallará son llamadas a PAM, con lo cual el escenario tí­pico de revelación de información sensible será aquel en el que se realicen volcados legí­timos de procesos que luego pueden ser accedidos por terceros a consecuencia de una pobre configuración de seguridad. Pongamos un par de ejemplos. En el primer caso vamos a capturar un volcado de un proceso Skype:

forensics

Una vez obtenido, investigamos las cadenas y buscamos, siendo inmediato encontrar información sensible. Además de la contraseña, que lógicamente aparecerá en el volcado, en este caso obtenemos los teléfonos de los contactos del usuario:

forensics

Este ejemplo es perfecto para volver a la utilidad de los volcados desde la óptica del desarrollo y de la seguridad. Si el usuario que invoca el volcado es el mismo que tiene abierto el proceso, es obvio que desde la óptica de seguridad no hay problema alguno, ya que yo sé mi contraseña y sé a quien tengo agregado en Skype como contacto. Este volcado será útil para mí­ para analizar hipotéticos problemas técnicos, pero poco más. Sin embargo, ¿qué sucederí­a si yo ejecutase regularmente estos volcados con una tarea cron y los estuviera volcando en un recurso local o de red al que tengan acceso otros usuarios? Evidentemente se genera un problema de seguridad, ya que estoy facilitando a terceros el acceso a mis datos sensibles. Otro ejemplo con Thunderbird:

forensics
forensics

Conclusiones

Estos ejemplos sirven perfectamente para ilustrar la necesidad, en una auditorí­a Unix, de entender si existen volcados totales o parciales y dónde se almacenan. Estos volcados, útiles y frecuentes en el desarrollo y optimización de sistemas, pueden provocar problemas de seguridad si no se gestionan adecuadamente.

Estos ejemplos también deben hacernos plantearnos los alcances de las auditorí­as. Yo soy el primero que no suelo conceder mucha importancia a los volcados, ya que como se ha visto son aspectos técnicos muy concretos que no siempre están presentes, con lo que los riesgos pueden ser inexistentes si no se producen, o poco relevantes si se producen de una manera controlada. No obstante, en un sistema crí­tico de producción, donde existan datos verdaderamente relevantes, siempre dedico 5 minutos a comprender si existen volcados y cómo se gestionan.

Un saludo,