Seguridades en el AS400

Tomado de: Auditoria

Comienzo aquí una serie de algunas entradas sobre auditoría de seguridad en entornos AS/400. Me váis a permitir que emplee la nomenclatura deAS/400, incorrecta por obsolescencia, pero es la que todo el mundo comprende. Realmente, AS/400 ya no existe como tal, puesto que esta nomenclatura dejó de usarse para pasar a utilizar eServer iSeries, IBM System i, y por último, IBM Power Systems.

En cuanto al sistema operativo, más de lo mismo. Lo que en su día eraOS/400 se pasó a llamar i5/OS, y hoy en día se llama IBM i. Para facilitar la comprensión de este batiburrillo de nomenclaturas he confeccionado esta tabla, que recoge para cada producto el año de introducción. No he podido confirmar al 100% el año de introducción de la nomenclatura i5/OS, motivo por el cual aparece asteriscado:

Algunos IBM System i (AS/400)

A pesar de que las nomenclaturas han sido cambiantes a lo largo del tiempo, en la jerga lo usual es que se hable de auditoría de un AS/400, aunque nos refiramos a la auditoría de seguridad del sistema operativo que corre en eseAS/400, siendo comunes otras acepciones coloquiales, como Análisis de la Seguridad de un 400 y expresiones similares. En adelante, y espero que nadie se ofenda, yo emplearé la nomenclatura a la antigua usanza :)

Hechas estas matizaciones, introducimos un poco qué es un 400, para qué se utiliza y cuál será el ámbito de estudio al que circunscribiremos estos artículos.

El AS/400 (IBM Power Systems)

Para introducir un poco este tipo de máquina, podemos decir que un AS/400es una máquina intermedia que cubre el hueco existente entre un mainframe(también conocido como host) y los pequeños servidores que normalmente operan en clúster atendiendo servicios distribuídos. En la literatura es habitual hablar de estas máquinas intermedias como máquinas mid-range, y son frecuentemente utilizadas para procesado de transacciones, con lo que es usual ver máquinas AS/400 al cargo de la transaccionalidad de empresas de seguros, entidades financieras, sistemas gubernamentales, etc., siempre con el permiso de los hermanos mayores del AS/400: los mainframes.

Teniendo en cuenta que la brecha entre los mainframes y las máquinas mid-range se ha reducido drásticamente en los últimos años, a pesar de seguir existiendo, los 400 gozan de una gran ventaja, que deriva de su menor capacidad: costes menores de adquisición y mantenimiento, lo que los hace ideales cuando la transaccionalidad es fuerte en ambientes donde no se requiere una computadora central.

Modo normal de funcionamiento

Los AS/400 están pensados para funcionar de muchas maneras, siendo el modo más frecuente la existencia de un hardware común compartido que da servicio a un número determinado de distintos LPAR o particiones lógicas. En el caso de máquinas IBM, los LPARes pueden funcionar con distintos sistemas operativos: z/OS, z/VM, z/VSE, z/TPF, AIX, Linux e IBM i y cada LPAR puede cubrir distintos objetivos (desarrollo, QA, producción). En el caso de AS/400, lo normal es que funcionen con IBM i (recordad: lo que en su día era OS/400), aunque no necesariamente tiene por qué ser así.

Seguridad en IBM i

Hoy en día no es descabellado catalogar a IBM i como uno de los sistemas operativos más seguros de la industria, debido, entre otras cosas, a que:

• Es un sistema que requiere un conocimiento muy específico para ser administrado y operado, y por tanto, también para ser atacado.
• Es un sistema en el que la seguridad ha ido de la mano de su desarrollo desde prácticamente sus orígenes, otorgándole una más que merecida relevancia.
• Aunque es un sistema que atiende entornos complejos, no deja de ser un sistema concebido desde la simplicidad. Y la simplicidad es siempre un aliado de la seguridad.
• El sistema operativo tiene una comunión perfecta con las características de seguridad que puede ofrecer el hardware (por ejemplo, el cifrado de datos) y la integración con otras plataformas.
• Aunque no tiene necesariamente que ser así, es frecuente que los 400 estén en el back de una instalación. Esto implica que la relación con el exterior y sus ataques es muy limitada y está fuertemente controlada, conviertiendo a los ataques internos en principales candidatos.

La seguridad en IBM i se basa en el concepto del diseño basado en objetos. Esto abre la veda para poder implementar la seguridad en diversas capas, como por ejemplo, la utilización de perfiles de usuario, permisos de los objetos, firma de los objetos y verificaciones de integridad de los mismos.

Los objetos se empaquetan en contenedores que agrupan objetos consistentes entre sí, así como con el contenedor. Los objetos están siempre encapsulados en estos contenedores, lo que tiene una implicación vital para la seguridad. Un objeto nunca puede ser usado si el uso requiere que se pierda consistencia con el tipo de objeto y su contenedor.

Esto hace fácil articular que los datos no sean tratados como código ejecutable y viceversa, lo que hace muy complicado, en un ambiente de administración adecuado, que los objetos puedan ser usados de modo incorrecto. Este modo de confinamiento tiene como principal ventaja no cohibir la flexibilidad del sistema, pero tiene como principal inconveniente la necesidad de una puesta en marcha y una administración de seguridad exigente que entraña complejidad.

En síntesis, la seguridad estará principalmente basada en relaciones entre usuarios y recursos:

• Desde la óptica de los usuarios, en sentido creciente, los perfiles de usuario, las descripciones de tareas, los perfiles de grupo y los valores de sistema
• Desde la óptica de los recursos, también en sentido creciente, los objetos individuales, las librerías y directorios, las listas de autorización y los valores del sistema.

Material de estudio y libro de referencia

Todo, o prácticamente todo lo que comentemos estará alineado con los manuales del fabricante. Son completos y suficientes, y ellos son los que mejor conocen su producto. Es por tanto que para sacarle el mayor provecho a estos artículos, una lectura y comprensión de este material es aconsejable.

Para no inundaros con una lista extensa de PDFs, creo que lo mejor que podemos hacer es basarnos en el propio manual del fabricante. La última edición que he podido encontrar es Security Guide for IBM i V6.1, que data de finales de mayo de 2009. Os recomiendo tenerlo a mano, ya que en él podréis encontrar información extensa sobre lo que veremos en esta serie de artículos.

En la próxima entrega hablaremos del análisis de los valores del sistema (WRKSYSVAL), donde prestaremos atención a los valores generales relacionados con la seguridad.

En el capítulo anterior vimos una pequeña introducción a lo que son los AS/400, cómo operan, y cuáles son las características generales que definen su seguridad. En este artículo vamos a ir desgranando un poco los conceptos generales, con la idea de ofrecer una idea mínima de cómo debe afrontarse la auditoría en estos sistemas.

Importante

Aunque trataré de explicarlo de la manera más sencilla, auditar un 400 requiere conocer al menos cómo funciona. Habrá cosas que pase por alto (por ejemplo, explicar qué es la toma de atribuciones, qué es un pass-through, qué es una tarea o job, etc.) con lo que insisto en que es recomendable leer y comprender el material de estudio antes de leer estos artículos, o de lo contrario, a duras penas se podrán comprender.

No obstante, podéis dejar comentarios si existen dudas.

Conexión a la consola de AS/400

Aunque existen clientes libres para acceder a un 400, como por ejemplo, tn5250, yo os recomiendo encarecidamente trabajar con el cliente propietario de IBM, que forma parte de las herramientas que conforman la suite IBM Personal Communications. Esta suite, además del cliente telnet para conectar al 400, trae un cliente 3270 para conectarse a su hermano mayor el mainframe.

Hago esta recomendación por dos motivos principales: el primero es que el cliente tb5250, a mí al menos, me ha dado problemas de estabilidad, dejándome la consola frita en más de una ocasión. El segundo es que las herramientas IBM traen funcionalidades que facilitan enormemente trabajar con la consola: edición, impresión, múltiples sesiones ... en definitiva, es un producto más usable.

Recordaos que para poder tener línea de mandatos, tenemos que tener esta atribución. Lo usual es que sólo los usuarios técnicos tengan acceso a la línea de comandos, de modo que los usuarios de aplicaciones sólo acceden a los programas que para ello se dispongan. Es la manera más elemental de construir seguridad en un sistema de estas características.

Work with System Values (WRKSYSVAL). Trabajar con los valores del sistema

Lo primero que hay que mirar en un 400 son los valores de sistema. Es la parte más fácil de inspeccionar, ya que es es muy intuitiva y fácil de comprender. Los valores del sistema son un conjunto de parámetros que dictaminarán cómo debe comportarse el sistema a la hora de funcionar.

Para poder trabajar con ellos, existe un comando de línea que se llama Work with System Values (Trabajar con los valores del sistema), y se invoca con el mandato WRKSYSVAL. Nosotros nos vamos a centrar sólo en los valores de sistema que tienen que ver con la seguridad, y optaremos siempre por auditar solicitando extracciones de información. La mejor manera de auditar es sentarse con el administrador de seguridad, y pedirle ejecuciones que serán volcadas a fichero o a impresora, según proceda, para nuestro posterior análisis. No es una buena práctica recibir atributos especiales para lanzar nosotros mismos consultas, ya que el riesgo de cometer un error y perjudicar la producción es elevado.

Para inspeccionar los valores delsistema, solicitaremos la ejecución de WRKSYSVAL, siendo preferente la obtención de un fichero que nos permita localizar después los parámetros:

WRKSYSVAL SYSVAL(*SEC) (mostrará los valores en pantalla, sólo es útil para consultas específicas)

WRKSYSVAL SYSVAL(*SEC) OUTPUT (*PRINT) (enviará al spool de impresión el resultado, puede ser interesante para tener una copia en papel)

WRKSYSVAL SYSVAL(*SEC) OUTPUT (*FILE) fichero (grabará la ejecución en el fichero especificado, lo recomendable.)

La descripción técnica de este mandato la tenéis enhttp://publib.boulder.ibm.com/infocenter/systems/scope/i5os/index.jsp. Llegado a este punto se hace muy recomendable tener a nuestro lado el documento V5R3 iSeries Security Reference (SC41-5302-07), para poder encontrar descripciones completas de lo que estamos estudiando.

Siguiendo el mismo orden que aparece en la documentación oficial, en este capítulo aprenderemos a interpretar los siguientes grupos de parámetros:

1. Nivel de Seguridad (QSECURITY)
2. Valores de sistema generales de seguridad
3. Valores de sistema relacionados con la seguridad
4. Valores de sistema de backup y restauración relacionados con la seguridad
5. Valores de seguridad que aplican a las contraseñas
6. Valores de sistema que controlan los parámetros de auditoría

Veamos en qué consisten, uno a uno.

1. QSECURITY (Nivel de seguridad)

El nivel de seguridad es un valor numérico que establece las condiciones de contorno generales del nivel de seguridad. Es un número creciente, lo que implica que valores más elevados implican una seguridad más elevada. Los niveles estándares de seguridad en un 400 son los siguientes:

• Nivel 10 (Seguridad del sistema no obligatoria, no es posible establecerlo)
• Nivel 20 (Seguridad sign-on)
• Nivel 30 (Seguridad sign-on y de recursos)
• Nivel 40 (Seguridad sign-on, de recursos y protección de integridad)
• Nivel 50 (Seguridad sign-on, de recursos y protección de integridad mejorada)

Según el fabricante se recomienda un valor mínimo de 30 (en algunos textos más recientes, recomienda 40), siendo lo realmente oportuno acudir al menos al nivel 40. El nivel de seguridad 40 incluye a los niveles 20 y 30, mejorándolos especialmente en lo que a controles de integridad se refiere:

• Prevención ante el uso de interfaces no soportadas
• Protección de descripciones de jobs, forzando a que aquellos que envíen trabajos a la cola deban tener autoridad *USE para que estos no fallen
• Impedimento del uso de los login por defecto
• Permisividad el uso de HSP (Enhanced Storage Protection, protección mejorada de almacenamiento), haciendo marcajes específicos en los bloques de información de sólo lectura, lectura-escritura o sin acceso
• Protección específica de los espacios asociados a cada programa y direcciones de jobs

Salvo requisito regulatorio no es preciso, por lo general, irse a niveles superiores como el 50, en el que básicamente se adoptan medidas de integridad mejoradas que sí pueden, al contrario que el nivel 40, tener afectación sobre el rendimiento.

2. Valores de sistema generales de seguridad

En este apartado estudiaremos algunos parámetros que guardan relación con aspectos generales de la seguridad del sistema. Son los siguientes:

• Allow User Domain Objects (QALWUSRDMN). Este parámetro dicta qué librerías del sistema permitirán la existencia de objetos de usuarios de los tipos *USRSPC, *USRIDX, and *USRQ. El valor recomendado es *ALL, aunque yo soy partidario de permitir sólo la presencia de estos objetos en la librería de temporales QTEMP.
• Authority for New Objects (QCRTAUT). Define la autoridad pública para un objeto de nueva creación cuando la autoridad de creación de la libería en la que estará ese nuevo objeto es *SYSVAL y el nuevo objeto creado tiene la autoridad pública *LIBCRTAUT. No es excesivamente relevante, y se recomienda el valor *CHANGE.
• Display Sign-On Information (QDSPSGNINF). Define si se mostrará información en el sign-on: fecha de última conexión, número de intentos de conexión inválidos y número de días que restan hasta la expiración de la clave. El valor recomendado es 1 (activo)
• Inactive Job Time-Out Interval (QINACTITV). Número de minutos que se permite antes de que se tomen acciones sobre los jobs inactivos. Es usual que este parámetro esté a *NONE (no se realizan estas verificaciones por parte del sistema), delegando la monitorización en la supervisión manual de los operadores.
• Inactive Job Time-Out Message Queue (QINACTMSGQ). Aplica sólo si tenemos las verificaciones de inactividad activas. Dicta qué acción tomar si se produce un timeout. El valor recomendable es *ENDJOB (finalización del job), si bien lo usual es que estas tareas administrativas se realicen desde sala por parte de los operadores.
• Limit Device Sessions (QLMTDEVSSN). Establece si se permite a los usuarios estar conectados a más de un dispositivo. Por motivos obvios (usuarios que comparten contraseña) se recomienda que este valor esté a 1 (un único dispositivo por usuario)
• Limit Security Officer (QLMTSECOFR). Es ideal para restrigir la capacidad de login de usuarios privilegiados (aquellos con atribuciones *ALLOBJ o *SERVICE) a sólo algunas estaciones especialmente protegidas. Se recomienda hacer uso de esta funcionalidad (parámetro a 1), lo que impedirá que en caso de compromiso de los usuarios privilegiados, se pueda ganar consola desde cualquier estación.
• Maximum Sign-On Attempts (QMAXSIGN). Número máximo de intentos erróneos de conexión. Un valor de 3 intentos es razonable.
• Action When Sign-On Attempts Reached (QMAXSGNACN). QUé hacer si se supera el número máximo de intentos erróneos de conexión. Lo recomendable es poner este parámetro a 3, lo que implicará deshabilitar el usuario y el dispositivo asociado, frenando los intentos de acceso mediante fuerza bruta.
• Retain Server Security (QRETSVRSEC). Este parámetro dictaminará si es factible conservar en el sistema información descifrable relacionada con la autenticación de usuarios, o de listas de validación (*VLDL). Se recomienda dejar a 0, lo que implica que no se rentendrá esta información.
• Remote Sign-On Control (QRMTSIGN). Empleado para gestionar conexiones remotas, lo que incluye conexiones Telnet (las ordinarias) y los pass-through que existan entre particiones (práctica muy extendida). El valor recomendado es *FRCSIGNON, lo que hará que las conexiones remotas tengan que pasar por el servicio de sign-on ordinario.
• Scan File Systems (QSCANFS). Permite construir mecanismos para el escaneo de sistemas de ficheros en busca de, por ejemplo, malware. Se recomienda el valor *ROOTOPNUD, para que al menos se escanee el sistema de ficheros del root. No perdamos de vista que este parámetro requiere que se hayan definido las listas de qué, dónde y cómo mirar.
• Scan File Systems Control (QSCANFSCTL). Similar al anterior. El valor *NONE es el recomendado.
• Share Memory Control (QSHRMEMCTL). Define qué usuarios tienen potestad para hacer uso de la memoria compartida con capacidad de ser escrita. El valor recomendado es 1, lo que permite hacer uso de la memoria compartida.
• Use Adopted Authority (QUSEADPAUT). Define qué usuarios pueden crear programas con la autoridad especial que permite la adopción de autoridades (*USEADPAUT(*YES)). El valor recomendado es *NONE, lo que provocará que todos los usuarios pueden hacer uso de las autoridades adoptadas sólo en caso de que el perfilado de los programas y servicios lo permita. Es preferible delegar en el correcto perfilado antes que frenar la capacidad de desarrollo y operación.

3. Valores de sistema relacionados con la seguridad

• Automatic Device Configuration (QAUTOCFG). Determina si los dispositivos añadidos al sistema deben configurarse automáticamente o no. El valor recomendado es 0 (desactivado), con la idea de prevenir la conexión sin supervisión de dispositivos maliciosos.
• Automatic Configuration of Virtual Devices (QAUTOVRT). Determina si los dispositivos virtuales procedentes de pass-through y/o vía TELNET serán configurados automáticamente o no. El valor recomendado es 0 (desactivado)
• Device Recovery Action (QDEVRCYACN). Establece las acciones a tomar cuando se producen errores I/O en el tratamiento de tareas. El valor recomendable es *DSCMSG (desconexión del job y posterior envío del mensaje de error al usuario en el próximo sign-on)
• Disconnected Job Time-Out Interval (QDSCJOBITV). Guarda relación con el anterior. Es el tiempo en minutos para que el sistema termine los jobsinterrumpidos. Se recomiendan 240 minutos, suficientes para tomar acciones y a la par, impedir la presencia de tareas muertas en la cola.
• Remote Service Attribute (QRMTSRVATR). Establece si es posible analizar sistemas remotamente a través de las utilidades de servicio remoto. Se recomienda no activar esta característica (valor 0) por motivos más que obvios. Puntualmente puede habilitarse, siempre que se tengan las máximas precauciones y que el proceso esté debidamente supervisado.

4. Valores de sistema de backup y restauración relacionados con la seguridad

Debemos revisar los siguientes parámetros:

1. Verify Object on Restore (QVFYOBJRST). Este parámetro determina si los objetos que han de ser restaurados deben tener firmas digitales para verificar su idoneidad y permitir su restauración. Se recomienda que esté activo, con el valor 3, lo que hará que sólo se restauren comandos firmados y objetos firmados en caso de que las firmas sean válidas. Por desgracia, el uso de componentes firmados no es una práctica muy extendida.
2. Force Conversion on Restore (QFRCCVNRST). Este parámetro indicará si es preciso forzar la conversión de determinados objetos en el momento de restaurar, como por ejemplo, programas (*PGM) y programas de servicio (*SRVPGM), así como paquetería SQL (*SQLPKG) y módulos (*MODULE). La idea es dotar de mejor integridad al proceso de restauración, ya que los objetos que no puedan convertirse al no contener suficiente información no serán restaurados. El valor mínimo recomendado para el parámetro es 3, lo que implica que los objetos en los que haya sospecha de adulteración o simplemente presencia de errores, serán convertidos antes de ser empleados.
3. Allow Restoring of Security-Sensitive Objects (QALWOBJRST). Establece si los objetos considerados de alta sensibilidad son susceptibles de recuperación. El valor en operación debe ser *NONE, es decir, no se permite la recuperación de objetos sensibles, pero por necesidades obvias, en un evento de restauración debe estar a *ALL, lo que permitirá ejecutar la restauración siempre y cuando se disponga de la autoridad adecuada.

5. Valores de seguridad que aplican a las contraseñas

Los podéis encontrar en la página 288 de nuestro material de estudio. Son autoexplicativos, y son básicamente una colección de parámetros que tienen que ver con las contraseñas que se utilizan en el sistema. La reproduzco a continuación:

En este campo habrá que ajustarse a lo que nos dicte el sentido común, y a la política de seguridad de la compañía que estemos auditando. La gestión de claves de un 400 puede ser muy profunda y enrevesada, y lo que menos querremos causar es complicar las cosas recomendando acciones sobre las contraseñas que obliguen a la compañía a tomar acciones costosas que sólo provoquen quejas e incidencias con mínimos incrementos de la seguridad.

Los parámetros a estudiar son los siguientes:

• Password Expiration Interval (QPWDEXPITV). Determina la vida útil de la contraseña en días para forzar su cambio. Se recomienda que sea de 30 a 90 días.
• Password Level (QPWDLVL). El nivel de contraseña permite a los administradores seleccionar entre claves de 1 a 10 dígitos, o bien de 1 a 128 dígitos. El valor adecuado debe discutirse con los administradores de seguridad, ya que forzar hasta 128 dígitos puede tener repercusiones en otros sistemas que beban del 400 y que no admitan tales longitudes.
• Minimum Length of Passwords (QPWDMINLEN). Longitud mínima de las claves. Se recomienda un mínimo de 6 caracteres para evitar claves sencillas.
• Maximum Length of Passwords (QPWDMAXLEN). Longitud máxima de las claves. El fabricante recomienda 8 caracteres, si bien esto puede ser modificado de acuerdo a los administradores.
• Required Difference in Passwords (QPWDRQDDIF). Este parámetro nos dirá si el sistema requiere que las claves que usemos deban ser o no diferentes a las anteriores. El valor recomendado es 5, lo que equivale a que el sistema comprobará que la nueva contraseña no sea ninguna de las escogidas en las 10 últimas ocasiones. Este punto es siempre fuente de controversia, ya que los administradores lo querrán tener a 0 (se permite duplicidad) por facilitar la operativa y por disminuir las quejas de los usuarios.
• Restricted Characters for Passwords (QPWDLMTCHR). Este parámetro indica si se limitará la presencia de ciertos caracteres en las contraseñas. El fabricante recomienda limitar el uso de vocales para construir claves más sólidas (impiden la construcción de palabras). Los caracteres #, $ y @ suelen estar restringidos igualmente por compatibilidad con otros sistemas.
• Restriction of Consecutive Digits for Passwords (QPWDLMTAJC). Este parámetro nos indica si se permite la adyacencia numérica en las claves. Por ejemplo, si una clave que sea 12345 o 12er45 se permite o no. La idea es prevenir el uso de fechas, números de DNI, etc. como contraseñas. Por defecto es una opción que se permite, y no suele estar restringida por asuntos de operatividad. Carne de discusión con los administradores, y nunca fácil de resolver.
• Restriction of Repeated Characters for Passwords (QPWDLMTREP). Similar al anterior, pero en vez de dígitos, este parámetro dictamina si un caracter puede estar repetido en una clave o no. Por ejemplo, la clave ekgDf4e, que contiene dos veces el carácter "e". Por defecto está a 0, luego se permiten. A discutir con los administradores. Sólo justificaría su uso en instalaciones de máxima seguridad, y cuando se considere que aporta mejoras a la gestión de contraseñas.
• Character Position Difference for Passwords (QPWDPOSDIF). Controla la repetición de los mismos caracteres en las mismas posiciones respecto a claves anteriores. Es algo enrevesado, y suele estar desactivado (valor a 0). Nunca lo he visto activo.
• Requirement for Numeric Character in Passwords (QPWDRQDDGT). Este parámetro indica si se requiere la presencia de números en la contraseña o no. La idea es prevenir la existencia de claves débiles con sólo caracteres (palabras sencillas como hola, root, usuario, etc.). Por defecto viene a 0, es decir, no se exige, aunque yo lo veo una práctica recomendable.
• Password Approval Program (QPWDVLDPGM). Determina si existen medios de aceptación adicionales de las claves elegidas antes de ser incorporadas al sistema. No suele estar activo, ya que el sistema sólo acepta programas de aprobación que residan en pools de almacenamiento auxiliares (ASP, Auxiliary Pool Storage), lo que implica costes adicionales. Por defecto viene a *NONE, es decir, no se emplean programas de aceptación adicionales.

6. Valores de sistema que controlan los parámetros de auditoría

Esta colección de parámetros nos darán información relevante sobre los mecanismos de auditoría intrínsecos de la plataforma, y es crucial tratarlos con sumo cuidado. Son los siguientes:

• Auditing Control (QAUDCTL). El el parámetro primario. Este parámetro indicará si están activas o inactivas las medidas de auditoría de los parámetros QAUDLVL y QAUDLVL2, la auditoría de cambios en objetos objetos mediante Change Object Auditing (CHGOBJAUD), los comandos de cambio de auditoría DLO (CHGDLOAUD) y la auditoría a usuarios que se efectúe mediante (CHGUSRAUD). Por defecto está a *NONE, lo que implica que esta auditoría no se realiza. Si no existen problemas de rendimiento, yo aconsejo que esté en los valores *OBJAUD (cambios en objeto mediante los comandos CHGOBJAUD, CHGDLOAUD y CHGAUD) y *AUDLVL (se auditan las funciones definidas en QAUDLVL, QAUDLVL2, así como el comando (CHGUSRAUD) Change User Audit. Es aconsejable, mediante el parámetro *NOQTEMP, que las acciones de auditoría no se ejecuten en la librería de temporales QTEMP, ya que no suele aportar nada más que consumo de recursos.
• Auditing End Action (QAUDENDACN). Este parámetro nos indica qué debe hacer el sistema si la auditoría está funcionando y por cualquier razón (principalmente, disco lleno) no se pueden seguir grabando entradas a la bitácora de auditoría. Lo usual es que esté a *NOTIFY, lo que hará que se envíen mensajes CPI2283 a las colas QSYSOPR y QSYSMSG para que los operadores puedan tomar las acciones establecidas en caso de falta de espacio.
• Auditing Force Level (QAUDFRCLVL). Define cómo articular el paso de la bitácora de auditoría de memoria a almacenamiento en disco. Se recomienda el valor *SYS, lo que hará que el sistema decida en base a criterios de rendimiento cuándo migrar los registros. En algunas ocasiones son los operadores los que realizan los tránsitos, aunque lo usual es que sea el sistema el que se ocupe.
• Auditing Level (QAUDLVL). Nivel primario de auditoría. Junto a QAUDLVL2 dictaminará que eventos de seguridad serán grabados en el registro de auditoría. Este comando admite muchísimos valores, y debe ser discutido con los administradores. Como mínimo, deberían grabarse los eventos de fallo de autoridad (*AUTFAIL), las operaciones de creación de objetos (*CREATE), de eliminación (*DELETE), las acciones que afectan a jobs (*JOBDTA) y las relacionadas con seguridad (*SECURITY), pero en función a la instalación, pueden ser muchos más.
• Auditing Level Extension (QAUDLVL2). Se emplea cuando son necesarios más de 16 valores de auditoría, siendo una extensión del anterior.
• Auditing for New Objects (QCRTOBJAUD). Determina el valor de auditoría para los objetos de nueva creación, siempre y cuando la librería donde esté ese nuevo objeto esté puesta en *SYSVAL. También es el valor que controla los nuevos documentos del sistema que no están en contenedores. Un buen valor es auditar los cambios, mediante *CHANGE. Ojito porque, por defecto, está desactivada (*NONE).

Resumen

Estos son los principales valores del sistema que tienen relación con la seguridad. No son los únicos, y sólo deben tomarse como una guía de lo que usualmente se suele comprobar para dictaminar si la parametrización de seguridad de un AS/400 es razonable o no.

En la siguiente entrega, siguiendo escrupulosamente el manual del fabricante, haremos un estudio de los perfiles de usuario. Es una de las partes más importantes en la auditoría de un 400, ya que a fin de cuentas, como sucede en cualquier otro sistema, un mal perfilado puede resultar letal para la seguridad.

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:

Parte 1. Introducción

Parte 2. Valores del sistema

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:

1. Fecha y hora: UPDCEN, UPDDAT, UPDTIM, UPSYST
2. Nombre de usuario: UPUPRF, UPUSCL, UPJBDS, UPJBDL, UPTEXT
3. Claves/Sign-on: UPDSIN, UPDSIN, UPPWCC, UPPWCD, UPPWCT, UPPWEI, UPPWEX, UPPWON, UPPSOC, UPPSOD, UPPSOT, UPNVSA, UPSTAT
4. Capacidades: UPLDVS, UPSPAU, UPMXST, UPMXSU, UPPRLT, UPLTCP
5. Condiciones iniciales de usuario: UPINPG, UPINPL, UPINMN, UPINML, UPATPG, UPATPL
6. Pertenencias: UPOWNR, UPGRPF, UPGRAU, UPGRPI, UPACCD
7. 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.

Contraseñas por defecto

Estudiar las contraseñas por defecto es una tarea típica en el análisis de la seguridad de un sistema operativo. El caso de un 400 no es una excepción.

En sistemas transaccionales de medio y largo alcance es relativamente frecuente, dado el elevado número de usuarios, que existan muchos perfiles con contraseñas por defecto. Adicionalmente son sistemas que vienen de fábrica poblados con multitud de perfiles que tienen contraseñas por defecto, los cuales, en ausencia de una administración de seguridad adecuada, pueden perdurar en la vida útil del sistema pasando inadvertidos. Para facilitar su localización, los sistemas operativos de un 400 tienen una utilidad a disposición de los administradores de seguridad: el análisis de las contraseñas por defecto.

El riesgo de la existencia de contraseñas por defecto es más que obvio, ya que facultan a un atacante a lograr acceso al sistema sin la necesidad de explotar vulnerabilidades.

Analyze Default Password (ANZDFTPWD)

Tal y como se puede leer en el capítulo cuarto de la guía de referencia de seguridad del fabricante, este comando permite imprimir un informe completo de todos los perfiles de usuario declarados en el sistema que tienen contraseña por defecto, así como tomar medidas para mitigar los riesgos que estos perfiles representan. Las acciones pueden ser *NONE (no se toma ninguna medida), *DISABLE (desactivar el perfil) y *PDWEXP (poner la contraseña como caducada, lo que hará que al siguiente inicio de sesión el usuario deba cambiarla). En un 400 se entiende como contraseña por defecto aquella en la que el nombre del perfil de usuario coincide con la clave de dicho perfil.

Este comando, restringido para el oficial de seguridad (QSECOFR), está principalmente orientado a localizar perfiles por defecto que están declarados en el sistema en una instalación nueva, pero lógicamente, también permite al auditor localizar malas prácticas en la gestión de contraseñas, identificando perfiles a los que en vez de otorgar claves complejas, le han sido otorgadas claves simples, coincidentes con su nombre de perfil. Técnicamente hablando, el comando se surte del fichero de datos QASECPWD2, presente en la libería QUSRSYS.

Contraseñas por defecto de fábrica

Las siguientes credenciales suelen ser las habituales en una instalación de fábrica. Resulta fácil comprobar que la lista de duplas (notadas comoperfil;contraseña) no es precisamente corta, lo que hace más que justificable el análisis de las contraseñas por defecto:

11111111;11111111
22222222;22222222
IBM;PASSWORD
IBM;2222
IBM;SERVICE
IBM;IBM
QAUTPROF;
QDBSHR;
QDOC;
QLPAUTO;
QNETSPLF;
QPGMR;QPGMR
QSECOFR;11111111
QSECOFR;22222222
SECOFR;SECOFR
QSRVBAS;QSRVBAS
QTFTP;
QTSTRQS;
QBRMS;
QDBSHRDO;
QDSNX;
QLPINSTALL;
QNFSANON;
QPM400;
QSNADS;
QSVCDRCTR;
QTMHHTTP1;
QUMB;
QCLUMGT;
QDFTOWN;QDFTOWN
QEJB;
QMQM;
QNOTES;
QPRJOWN;
QSPL;
QSYS;
QTMHHTTP;
QUSER;QUSER
QCLUSTER;
QDIRSRV;
QFNC;
QMQMADM;
QNTP;
QRJE;
QSPLJOB;
QSYSOPR;QSYSOPR
QTMPLPD;
QYPSJSVR;
QCOLSRV;
QDLFM;
QGATE;
QMSF;
QPEX;
QRMTCAL;
QSRV;QSRV;IBMCEL
QTCP;
QTMTWSG;
QYPUOWN;
QSERV;QSERV

El menú SECTOOLS

Esta utilidad es parte de un menú especial llamado SECTOOLS, un menú accesible mendiante go sectools, en el que además del análisis de contraseñas por defecto (ANZDFTPWD), es posible desplegar la lista de perfiles activos (DSPACTPRFL), los inactivos, analizar la actividad de los perfiles (ANZPRFACT), consultar la agenda de activación y desactivación de perfiles (DSPACTSCD), cambiar la agenda (CHGACTSCDE), gestionar la agenda de expiraciones (DSPEXPSCDE y CHGEXPSCDE) y imprimir información interna de los perfiles (PRTPRFINT).

Una auditoría completa del 400 haría recomendable revisar todas estas ejecuciones para determinar si existen indicios de una configuración de seguridad incorrecta. Elementos que nos pueden hacer sospechar son, por ejemplo, una agenda de desactivación y/o expiración sin entradas (síntoma de que los perfiles se crean sin expiración), un elevado número de perfiles inactivos, etc.

En el próximo capítulo indagaremos más en el análisis de los perfiles de usuario.