Auditoría de IBM Power Systems (AS/400). Parte 2. Valores del sistema

Buenas,

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 en http://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 jobs interrumpidos. 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.

Un saludo,