Antes de hablar sobre cuándo debería identificar que sus sistemas fueron hackeados, es importante que tenga en cuenta que el hackeo de un servidor IBM i es posible. Para muchos, la palabra "hackeo" se traduce en un criminal informático que viola, en forma encubierta, los perímetros de defensa establecidos por una empresa. Sin embargo, la realidad suele ser mucho más sencilla y menos dramática. En mi opinión, un hackeo es cualquier forma de acceso no autorizado a datos y programas, incluso cuando el acceso se origina dentro del firewall.
La reputación de IBM i y sus predecesores i5/OS y OS/400, se caracteriza por ser la de uno de los sistemas operativos más seguros disponibles en el mercado. Este beneficio estratégico es promocionado por IBM y es conocido por administradores, auditores, y algunos expertos en Seguridad. De todas formas, la integridad de cualquier dispositivo, aplicación o sistema operativo no depende solo de la existencia de controles de Seguridad robustos, sino también de la configuración correcta de esos controles. Cuando cualquiera de esos elementos falta, la Seguridad está en riesgo.
La Seguridad depende de la configuración adecuada de IBM i
La integridad de los sistemas operativos de IBM i está parcialmente garantizada por una serie de mecanismos únicos de protección, que incluyen restricciones que aseguran que los objetos del sistema sean promocionados y modificados solo por IBM y que las funcionalidades del servidor sean accesibles solo vía las interfaces proporcionadas por IBM, como comandos y APIs. Estos mecanismos no funcionan a menos que el nivel de Seguridad del valor del sistema (QSECURITY) esté configurado en 40 o 50.
Hace algunos años, IBM estableció que el nivel 40 era el nivel de Seguridad acordado por defecto, pero, de acuerdo al Estudio sobre el Estado de la Seguridad de IBM i, el 35% de los servidores que se ejecutan en IBM i no cumplen con este requerimiento. Esto suele ser el resultado de la restauración de los valores del sistema de generaciones anteriores del servidor.
Pese a que los mecanismos del Sistema Operativo son valiosos, no son efectivos para prevenir el uso no autorizado de objetos de usuario, como archivos de base de datos o programas de aplicación, que confían en la configuración apropiada de los permisos de objetos.
La configuración del perfil de usuario es otra consideración crítica. Por ejemplo, un usuario con el permiso especial All Object (*ALLOBJ) (el estudio reportó que existen 78, en promedio, por servidor) puede ignorar las configuraciones de Seguridad de objetos y emitir comandos que deshabiliten el sistema operativo y ¡destruyan la base de datos!
Los usuarios representan un gran riesgo para los datos
¿Por qué un usuario legítimo querría causar problemas en su compañía aprovechando la mala configuración de sus sistemas? Puede ser que se trate de un acto malicioso o accidental. En un Security Scan, descubrí que un programador había planificado una función destructiva utilizando el planificador de tareas de IBM i. La tarea fue planificada nuevamente, repetidas veces, para prevenir su ejecución y que entregue su carga dañina en una fecha futura, probablemente cuando el programador ya no esté entre los empleados de la compañía. Este ejemplo extremo fue un acto deliberado que amenazó la integridad de todo el entorno. Existen muchos ejemplos de usuarios legítimos que acceden a datos en formas que contradicen los intereses de la compañía, como realizar descargas no autorizadas a una PC desde interfaces no tradicionales, como ODBC o FTP.
Los accidentes también son muy probables. Descubrí a la fuerza los "archivos físicos de múltiples miembros" cuando, al incio de mi carrera como programador, elimine accidentalmente algunas de las tablas de la base de datos de mi cliente que aparecían sin datos. Lamentablemente, no sabía que los datos residían en miembros secundarios. Aunque parezca una tontería hoy, muchas de las personas en IT podrán recordar algún momento en el que desearon haber sabido en ese entonces, lo que saben ahora. El riesgo de que ocurran eventos desafortunados puede ser reducido si se configuran cuidadosamente los permisos a nivel de objeto, así como si se designan apropiadamente los usuarios privilegiados. En cualquier caso, se requiere un registro forense en la mayoría de las regulaciones.
La configuración correcta de IBM i y las aplicaciones de usuario exceden el alcance de este artículo. Sin embargo, existen múltiples recursos educativos, que incluyen sesiones en COMMON y webinars grabados. Para muchos, el libro IBM i Security Administration and Compliance es una gran fuente de consulta. Siempre sugiero a las empresas que comiencen un proyecto de Seguridad con una evaluación para documentar el punto de comienzo, medir el progreso, y priorizar los pasos de mitigación para reducir el riesgo al máximo.
Utilice QAUDJRN
El hackeo de IBM i se puede originar desde un perfil comprometido o un usuario legítimo, y puede ser un acto malicioso o un accidente. Afortunadamente, la auditoría integrada de usuarios y eventos, es uno de los aspectos valiosos de IBM i y siempre debe estar configurada para poder realizar un seguimiento en caso de que ocurra algo inesperado. IBM i registra los eventos en un journal especial de objetos (*JRN) llamado QAUDJRN.
Las ventajas del journal es que resiste alteraciones, protegiendo a las entradas de receptores para que no puedan ser modificadas o removidas. Esta funcionalidad es única de IBM i y fundamental para el cumplimiento regulatorio. Como con los journals de bases de datos, los datos se almacenan en un receptor de journal que puede residir en cualquier librería. Recomiendo alterar el predeterminado QGPL a una librería creada específicamente para alojar estos objetos. Una vez que el receptor está lleno, el umbral es definido en los ajustes de propiedad del journal, el sistema creará automáticamente uno nuevo con un nombre en secuencia. Dos valores de sistema, control de auditoría (QAUDCTL) y nivel de auditoría (QAUDLVL), controlan las principales funciones de auditoría y definen qué se audita a nivel de sistema. Los objetos y perfiles de usuario también poseen propiedades de auditoría y permiten una observación más detallada.
Confíe en el sistema de detección de intrusiones de IBM i
Los servidores empresariales, como los que ejecutan IBM i, tienen más chances de sufrir ataques en manos de usuarios de confianza, que de atacantes anónimos. Sin embaro, operar entre firewalls corporativos no elimina el riesgo de sufrir un ataque externo, o incluso la posibilidad de que el host se utilice como fuente de un ataque. Los firewalls, como cualquier software, son suceptibles a errores de configuración y pueden ser comprometidos fácilmente utilizando credenciales de red violadas, robadas, o falsificadas.
Esta posibilidad refuerza el beneficio de utilizar un modelo de defensa en profundidad, mediante el cual la Seguridad de aplica en múltiples capas independientes. Afortunadamente, y como una declaración potente sobre las capacidades de Seguridad inherentes a la plataforma, IBM i cuenta con un Intrusion Detection System (IDS) integrado. En mi opinión, el nombre IDS subestima el valor total de esta funcionalidad ya que la detección se complementa con capacidades de prevención y de monitoreo de eventos de intrusión y extrusión. Disponible sin cargo adicional, este componente del sistema operativo está diseñado para detectar, e incluso reaccionar, ante actividades anómalas de TCP/IP, como el escaneo de puertos o ataques distribuidos de denegación de servicio (DDoS) como ataques "Syn Flood" o "Smurf".
Active esta funcionalidad utlizando la interfaz GUI de IBM Navigator para i, y luego implemente una política por defecto o defina políticas personalizadas para controlar la detección o respuesta ante ataques, escaneos, e irregularidades de tráfico. A partir de IBM i 6.1, se eliminó la funcionalidad Quality of Service (QoS), de forma que IDS es mucho más fácil de configurar. Los eventos que violan las políticas se registran en el journal de auditoría como cualquier otro tipo de actividad sospechosa o no autorizada. También se puede notificar a las partes interesadas a través de notificaciones por email integradas. Obviamente, el éxito depende de que las funciones sean activadas y configuradas correctamente.
Prepárese para el peor escenario de Seguridad
Luego de iniciar la auditoría, es importante establecer un proceso de revisión, al menos de las entradas más críticas. Aunque suene obvio, muchas empresas recolectan datos de auditoría sin ninguna forma establecida de revisión de Seguridad. Esto muchas veces incluye a quieren usan soluciones de Alta Disponibilidad (HA) que utilizan la auditoría para detectar cambios en el sistema y replicarlos en el sistema de backup. Las aplicaciones comerciales de HA suelen purgar los datos de auditoría cuando ya no son necesarios para su propósito, generalmente 48 horas después de su recolección. Esta ventana de retención es inadecuada para los análisis forenses de Seguridad y no cumple con ninguna ley regulatoria moderna.
Hay otras empresas que no tienen la intención de revisar los datos, entonces no ven la ventaja en recolectarlos. Para ellos, cuento la analogía de un Circuito Cerrado de Cámaras de TV en un banco: a pesar de que el video en vivo pueda no ser controlado constantemente, la grabación sigue siendo necesario en caso de que ocurra algún incidente. Incluso si no se revisa continuamente, los datos de auditoría de IBM i deben ser capturados para que ser analizados en forma retroactiva si se observa cualquier actividad sospechosa..
Revisar manualmente miles o millones de entradas de auditoría es una tarea compleja. El sistema operativo contiene el comando Copy Audit Journal (CPYAUDJRN) que extrae entradas desde un receptor en archivos de bases de datos. La selección está basada en un tipo de entrada de registro de auditoría de dos caracteres, lo que significa que el desafío de lidiar con un repositorio único y enorme (que posiblemente contiene cientos de tipos de entradas diferentes) es reemplazado por el desafío de lidiar con más de cien archivos de bases de datos individuales, cada uno con un subgrupo del resgitro completo.
Considere herramientas que automaticen las tareas de Seguridad
Las herramientas forenses comerciales están diseñadas para minimizar el trabajo humano relacionado con la recolección, el filtrado y la clasificación de datos. Enviar entradas de registro en tiempo real a un SIEM (Gestión de Eventos de Seguirdad e Información) también es cada vez más popular. Sin embargo, existe el riesgo de que algunos eventos de Seguridad se escondan de los propios administradores del servidor. Algunos eventos de auditoría son más críticos que otros, entonces enfocarse en un subconjunto de eventos simplifica su gestión.
En caso de que no cuente con ninguna herramienta de automatización, aún así recomiendo recolectar todos los eventos, ya que siempre se puede comprar una solución comerciales para investigar dentro de los registros en caso de alguna filtración. Los presupuestos suelen ser muy variados. En este punto, siento que debo recordar a los lectores que algunas entradas, como el evento de falla de permiso "AF", será registrado solo si la configuración de Seguridad restringe determinados eventos. Si, por ejemplo, cada perfil tiene permisos de objetos (*ALLOBJ), o si los objetos están configuradores con un permiso *PUBLIC para *ALL, entonces un evento de falla de permiso técnicamente nunca ocurriría.
El sentido común le indicará la criticidad de las actividades no autorizadas en la red o el servidor, que deben ser registradas. También es importante establecer proactivamente un Plan de Respuesta ante Incidentes. La palabra proactivamente indica que no debe ser creado en estado de pánico cuando un incidente ya ha ocurrido. Planificar el peor escenario antes de que ocurra le permite garantizar que cualquier reacción será ejecutada oficialmente, a tiempo y será decisiva. Recuerde: un plan es beneficioso solo si el equipo está el tanto de él y si está capacitado para actuar ante un incidente.
Conclusiones
La protección de un entorno de IBM i se basa en los controles integrados de Seguridad, la configuración integral de esos controles, y la auditoría de las acciones de los usuarios. Si no realiza una auditoría, en lugar de preguntarse cuándo reconocer una filtración, deberá preguntarse si alguna vez sabrá si existe una filtración.
Es fundamental considerar que un servidor que ejecuta IBM i puede ser hackeado. Aunque no sea un defecto proveniente del sistema operativo, las debilidades están vinculadas con las configuracipones más frecuentes, como políticas de contraseña sub-par con contraseñas que coincidan con el nombre de usuario, servicios TCP no controlados (como, FTP, DDM, y ODBC), o la dependencia del valor predeterminado proporcionado por IBM para la autorización de objetos que deja los datos vulnerables al acceso no autorizado.
Comience hoy mismo
Descubra cuáles son los riesgos que se esconden en su IBM i.
