Hola,
Cuando auditamos un sistema operativo siempre es interesante analizar el perfilado de los usuarios. El perfilado arroja siempre información sobre los riesgos que derivan de que los usuarios tengan o no los privilegios adecuados para hacer uso del sistema, o si lo preferimos, de la capacidad que tienen los usuarios de realizar acciones maliciosas intencionadas o accidentales.
Por desgracia, es frecuente minusvalorar el análisis del perfilado, ya que muchas auditorías se centran en aspectos técnicos como la configuración de seguridad y la presencia de vulnerabilidades que permitan a un atacante la realización de actividades maliciosas en un equipo o conjunto de equipos. Sin restar importancia a este tipo de análisis, el estudio del perfilado cobra especial interés en grandes sistemas donde existe un número muy elevado de usuarios, algunos de los cuales podrían estar legítimamente presentes en el sistema con excesivas atribuciones que facilitarían en gran medida un ataque. En general, y para cualquier sistema, sería siempre deseable un estudio mixto que combine el análisis de la seguridad perimetral (test de intrusión basado en configuración de seguridad endeble y/o vulnerabilidades) así como el estudio de los perfiles (probabilidad de realizar acciones maliciosas disponiendo de cuenta en el sistema)
En grandes sistemas transaccionales es muy complicado, por no decir prácticamente imposible, la intrusión tradicional, es decir, aquella en la que un usuario sin cuenta logra acceso al sistema aprovechando vulnerabilidades. El histórico de vulnerabilidades en los 400, z/OS y similares es prácticamente inexistente, con lo que no es de esperar que existan vulnerabilidades que permitan entrar alegremente al sistema, ganar privilegios de administración o elevar los privilegios que tenemos concedidos. Donde normalmente vamos a encontrar problemas es en la configuración de seguridad, y concretamente, en cómo se administran los perfiles.
Es bastante frecuente que el perfilado no esté suficientemente ajustado a los requisitos deseables de seguridad establecidos para la instalación, y esto responde principalmente a dos factores: por un lado son sistemas con un legado anterior extenso, lo que implica que arrastran una configuración que puede tener años de vida y en la que pueden existir errores no advertidos, y por otro lado, son frecuentes las instalaciones donde se percibe cierta ausencia de tareas administrativas regulares que permitan sanear y actualizar la situación de los perfiles, lo que suele provocar que en la declaración de perfilado existan errores diversos como por ejemplo, la dotación de excesivos privilegios, la concesión de permisos sobre programas que el usuario no utiliza, bien porque ya no pertenece a la organización, bien porque ha cambiado su rol en la misma. En definitiva, cuando auditamos un 400 hay que prestar especial atención a los perfiles, ya que buena parte de la seguridad global del sistema reside en estas declaraciones.
Una vez más, seguiremos los contenidos de la guía de referencia de seguridad del fabricante, que hemos enlazado en los capítulos anteriores. Dado que el análisis de los perfiles de usuario requiere realizar numerosas comprobaciones, vamos a dividir este tema en varias secciones. En la que publicamos hoy, hablaremos de algunos conceptos introductorios y generales relacionados con la auditoría del perfilado, para ofrecer una visión general antes de entrar en detalle.
En capítulos anteriores …
Para situarnos, estos son los contenidos vistos con anterioridad:
Display User Profiles (DSPUSRPRF)
El comando de consola DSPUSRPRF (Display User Profiles) permite, como su propio nombre indica, obtener información sobre los perfiles declarados en el sistema, tanto de grupos como usuarios.
Su funcionamiento es muy sencillo. Así pues, DSPUSRPRF USRPRF(SHERNANDO) mostraría en pantalla el perfil del usuario shernando, siempre y cuando se tengan permisos para realizar la consulta. Empleando el mismo comando es posible obtener un fichero que contenga todos los perfiles dados de alta en el sistema:
DSPUSRPRF USRPRF(*ALL) TYPE(*BASIC) OUTPUT(*OUTFILE) OUTFILE(AUDITORIA/PERFILES)
Esta ejecución escribirá en el fichero PERFILES de la librería AUDITORIA todos los perfiles del sistema. Normalmente el auditor solicitará al administrador de seguridad la extracción de estos perfiles, ya que mostrar perfiles de usuario ajenos al nuestro requiere permisos especiales. Adicionalmente, por una cuestión de asepsia, es recomendable ordenar la extracción y recogerla junto al administrador de seguridad para que quede constancia de que el material proporcionado es conforme a los deseos de ambas partes.
Mediante la ejecución anterior estaremos en condiciones de realizar diversas pruebas sobre la totalidad de usuarios. La consulta mostrará información suficiente para poder analizar estos siete grupos de información y sus correspondientes campos de información:
- Fecha y hora: UPDCEN, UPDDAT, UPDTIM, UPSYST
- Nombre de usuario: UPUPRF, UPUSCL, UPJBDS, UPJBDL, UPTEXT
- Claves/Sign-on: UPDSIN, UPDSIN, UPPWCC, UPPWCD, UPPWCT, UPPWEI, UPPWEX, UPPWON, UPPSOC, UPPSOD, UPPSOT, UPNVSA, UPSTAT
- Capacidades: UPLDVS, UPSPAU, UPMXST, UPMXSU, UPPRLT, UPLTCP
- Condiciones iniciales de usuario: UPINPG, UPINPL, UPINMN, UPINML, UPATPG, UPATPL
- Pertenencias: UPOWNR, UPGRPF, UPGRAU, UPGRPI, UPACCD
- Auditoría: UPOBJA, UPAUDL
El objetivo del auditor será opinar, para todos los perfiles, sobre las condiciones de los campos enumerados anteriormente. Los veremos uno a uno en capítulos posteriores.
Autoridades especiales
En el 400 hay un conjunto de autoridades que se consideran especiales. Son, por así decirlo, privilegios elevados que se confieren a usuarios y grupos para la realización de tareas administrativas. Hay que ser especialmente cauto al analizar los perfiles de usuario, ya que si hay usuarios capaces de realizar acciones maliciosas, intencionadas o no, son los usuarios con atributos especiales.
La manera más fácil de analizarlos es enumerar la totalidad de usuarios obtenidos en nuestra descarga que no tienen el parámetro UPSPAU igual a *NONE (es decir, aquellos que no están marcados como usuarios sin autorizaciones especiales). Los tipos de autoridades especiales son:
- *ALLOBJ: Autoridad «todos los objetos» (All Objects). Permite realizar operaciones en todos los objetos del sistema.
- *AUDIT: Autoridad de auditoría (Audit). Permite a los usuarios definir las características de la auditoría del sistema, objetos y usuarios
- *IOSYSCFG: Autoridad de configuración de sistema (I/O System Config). Permite a los usuarios configurar la comunicación, así como los dispositivos de entrada y salidad del sistema.
- *JOBCTL: Autoridad de control de trabajos (Job Control). Esta autoridad ofrece control sobre los jobs del sistema.
- *SAVSYS: Autoridad de salvado del sistema (Save System). Permite salvar y restaurar objetos.
- *SECADM: Autoridad de administrador de seguridad (Security Administrator). Permite trabajar con perfiles de usuario del sistema.
- *SERVICE: Autoridad de servicio (Service). Permite la realización de funciones de mantenimiento del software en el sistema.
- *SPLCTL: Autoridad de control de colas (Spool Control). Permite obtener control total sobre los jobs sometidos a batch y las colas de salida.
Autoridades públicas (Public Authorities)
Las autoridades públicas sirven para simplificar la administración del sistema. Un objeto con autoridad pública implica que es accesible por todos los usuarios, siempre y cuando no recaiga sobre ese objeto alguna restricción particular que acote su disponibilidad.
Por defecto, muchos comandos vienen por defecto con la autoridad pública en *EXCLUDE, es decir, que por defecto se impide que cualquier usuario pueda realizar uso de esos comandos. Tómese en especial atención la presencia de autoridades públicas ya que entrañan un riesgo potencial elevado.
QSECOFR
Por último, para terminar esta introducción al perfilado de usuarios, resulta obligatorio hablar de QSECOFR. Este perfil es el perfil de máxima autoridad en el sistema, y suele venir de fábrica con la clave QSECOFR (expirada, luego obliga al cambio) y goza de las autoridades especiales *ALLOBJ, *SAVSYS, *JOBCTL, *SECADM, *SPLCTL, *SERVICE, *AUDIT y *IOSYSCFG
A todos los efectos, QSECOFR es el UID 0 del sistema. No debe perderse de vista que los 400 vienen, en una instalación de fábrica, con numerosos perfiles declarados (comienzan todos por Q), con lo que es más que recomendable ojear la guía de referencia de seguridad, concretamente la sección Appendix B. IBM-Supplied User Profiles para comprender la naturaleza de estos usuarios a la hora de auditar los perfiles.
En lo que a QSECOFR se refiere, no resulta admisible que sea un usuario empleado en el día a día de la administración del sistema. Lo usual es crear usuarios administradores de seguridad con privilegios elevados, trazables y personalizados, dejando a QSECOFR para acciones de emergencia o para eventos donde sea estrictamente necesaria su utilización. Es por tanto que la clave de QSECOFR debe estar custodiada y cambiada siempre que se haga uso del usuario y como no podía ser de otro modo, la monitorización de seguridad debe ser implacable, registrando todos los movimientos de este usuario, aún a riesgo de que podría eliminar sus trazas, con lo que es recomendable la monitorización específica del mismo por terceras personas ajenas a los administradores de seguridad en los centros de explotación (por ejemplo, en la sala de operación). Estas medidas son igualmente aplicables a todos los usuarios con autoridades especiales activos, lo que incluye a los administradores de seguridad.
En el próximo capítulo veremos cómo opinar sobre la seguridad del sistema atendiendo a la información que podemos obtener del perfilado de los usuarios declarados.
Un saludo,
Comentas en el artículo que «… El histórico de vulnerabilidades en los 400, z/OS y similares es prácticamente inexistente …», y bien es cierto que este tipo de amenazas (muy, muy pocas) no se llegan a hacer públicas o se «maquillan» con vulnerabilidades o fallos en sistemas anexos, por intereses de los propios clientes y del fabricante.
Zebra,
Pues mira, probablemente haya casos como los que comentas. No obstante lo que es innegable es que el número de incidentes de seguridad que sufren estas plataformas es ínfimo si los comparamos a las cajas UNIX o a los Windows.
Eso sí, por ínfimos que sean, como las meigas, haberlos «haylos», y no deben ser menospreciados.
Un saludo,
En comparacion con otras plataformas he visto que as400 es bien completa en seguridad. Las fallas de seguridad que he visto en as400 estan mas relacionadas a su mala configuracion que ha fallos en si.
Bueno apenas empiezo en el equipo as/400 , iseries, poco a poco empezare a entender mas sobre la seguridad y configuración de este sistema.
Como puedo saber quién dio de alta un usuario?
gracias, de antemano por su atención
me ha servido de mucho toda esta información
Dora,
Esa información deberías poder verla consultando la descripción de un objeto, en este caso, un perfil de usuario (Display Object Description (DSPOBJD). Prueba a lanzar un DSPOBJD OBJ(QSYS/perfil_a_investigar) OBJTYPE(*USRPRF) DETAIL(*FULL)
Normalmente será un administrador con capacidades *SECADM, o quizás el usuario QSECOFR.
Un saludo,
Quisiera saber como puedo verificar si los usuarios (o que usuarios tiene acceso a las herramientas especiales ejm SDA; SEU;DFU
Me gustaría me aclararam, si es posible, listar los usuarios con privilegios especiales en AS400.
Y dónde están «los capítulos posteriores»?