A lo largo de una serie de artículos voy a publicar los principios básicos que todo SysAdmin debe respetar, practicar y predicar a sus pares. Estos principios los he tomado (y orgullosamente puedo decir que he respetado casi en su totalidad) del artículo General SysAdmin Principles & Guidelines publicado por el Dr. Joe Chung.



Los Administradores de Sistemas, más conocidos como SysAdmins, somos a menudo los superhéroes del departamento de sistemas, aquellos destinados a "salvar el día" (muy a menudo, generalmente). El primer capítulo trató el tema más importante en el trabajo de un Administrador de Sistemas: la documentación. Este segundo capítulo trata el tema más difícil en el trabajo de un SysAdmin: seguridad y backups.

La biblia del SysAdmin

Capítulo 1: Documentación

Capítulo 2: Lo difícil (seguridad y backups)

Capítulo 3: La eficiencia importa

Capítulo 4: Administración y acceso remoto

Capítulo 5: Reinicios y uptime

Capítulo 6: Automatización y scripting

Capítulo 7: Gestión de software y mantenimiento del sistema

Capítulo 8: Usuarios y soporte

Capítulo 9: Estandarización vs. diversidad

Capítulo 10: Promoción, ética y aprendizaje

Lo difícil (seguridad y backups)

  • Ocuparse primero de lo más difícil.
    • Los mayores temores de todo SysAdmin son:
      • Que un sistema sea comprometido o su seguridad vulnerada ("hackeado").
      • Que información importante se pierda o borre y no exista una copia de seguridad (backup).
      Los esquemas de backup, seguridad (hardening) y PRD (Plan de Recuperación ante Desastres) deben ser las primeras ocupaciones al momento de instalar/configurar un sistema o aplicación, y deben tener la mayor prioridad.
    • En ciertas empresas es necesario luchar a capa y espada (argumentos y justificaciones), todos los días, contra el mal management que sólo quiere que las cosas funcionen rápido y fácil, para luego “cuando haya tiempo" dedicarle un poco a la seguridad y backups.
    • Preguntarse a menudo ¿cuán bueno es nuestro esquema de backup?
      • ¿Existe hardware spare para reemplazar cada uno de los componentes de la infraestructura (dispositivos de energía, red, almacenamiento y servidores)?
      • En caso de utilizar tecnologías cloud, ¿se provee backup de toda la infraestructura en la nube? Si el proveedor cloud provee mecanismos de backup ¿se ha efectuado un análisis detallado del mismo? y ¿es posible auditarlo? En caso de desastres de grandes magnitudes, ¿tenemos backups disponibles para replicar toda la infraestructura cloud en otro proveedor? Claramente la tecnología cloud requiere todo un capítulo aparte, ya que abre todo un abanico de nuevas posibilidades, y la importancia de las cuestiones de backup y seguridad aumenta considerablemente.
      • ¿Existe un plan y metodología para restaurar un sistema completo desde cero (incluyendo hardware y sistema operativo)?
      • ¿Se han hecho pruebas suficientes para verificar que la información almacenada en las copias de seguridad y el mecanismo de restauración funcionan de manera efectiva? En este punto es de vital importancia que el equipo de SysAdmins tenga lugar en su agenda para al menos un simulacro anual de recuperación ante desastres (PRD). Esta tarea debe ser la prioridad #1 en el plan de trabajo anual del equipo para mantener a los procedimientos actualizados y probados.
      • Recuperar la infraestructura el día del juicio final debe ser una tarea de rutina.
    • Monitorear la correctitud e integridad de los sistemas de archivos periódicamente.
      • Los sistemas operativos suelen verificar la correctitud (fsck) de los sistemas de archivos automáticamente durante el inicio, aunque también es de vital importancia verificar periódicamente el estado de “salud" de los discos físicos que provee la tecnología S.M.A.R.T.
      • Utilizar una herramienta de comprobación periódica de integridad de los archivos, por ejemplo AIDE.
        • ¿Se protege adecuadamente la seguridad de la base de datos de la herramienta de monitoreo de integridad? ¿Se encuentra ésta almacenada en un medio de sólo lectura o accesible a través de un mount NFS de sólo lectura?
        • Si la base requiere acceso de escritura, ¿posee una configuración de permisos adecuada?
    • Correr un escáner de malware y rootkits periódicamente.
      • Preferentemente desde un medio de sólo lectura.
        Respecto a este punto es posible definir un export NFS, en un servidor de seguridad centralizado, que provea acceso a todas las herramientas de seguridad necesarias en modo de sólo lectura. De esta forma se evita que las mismas puedan ser corrompidas por un atacante (para pasar desapercibido) durante un break-in.
        Esto tiene un beneficio adicional que consiste en evitar tener que replicar una herramienta de seguridad a lo largo de todos los servidores de la infraestructura, lo que simplifica la tarea de mantenerla actualizada. Sólo basta definir un subdirectorio para cada sistema operativo y arquitectura de CPU.
    • Estar al tanto de las últimas vulnerabilidades, incidentes de seguridad y exploits descubiertos.
  • Suscribirse a sitios de noticias y listas de correo que provean información de seguridad:
  • Utilizar logwatch u otro software de monitoreo y análisis de archivos de log para detectar irregularidades en un sistema.
  • Aplicar el principio de mínimo privilegio o mínimo conocimiento a rajatabla:
    • Otorgar a los usuarios los permisos mínimos y necesarios para realizar su trabajo.
    • Otorgar a los procesos y servicios los permisos mínimos y necesarios para ejecutar sus tareas.
    • Permitir el acceso desde el exterior a la menor cantidad de puertos y protocolos posibles.
    • Ofuscar banners de servicios, acceso a aplicaciones, etc.
    • Aplicar la misma metodología en cada una de las capas de un sistema, desde red y sistema operativo, hasta aplicación.
    • Tener mucho cuidado con la mentalidad “no va a pasar aquí" o “los usuarios no son tan inteligentes" que puede involucrar grandes problemas de seguridad.
  • Pensar en términos de redundancia.
    • ¿Hay un backup del backup?

Referencias

Joe Chung - General SysAdmin Principles & Guidelines

Cómo instalar y configurar Bacula en Debian


Tal vez pueda interesarte


Compartí este artículo