martes, 8 de diciembre de 2015

10 errores de seguridad que cometen los administradores de sistemas

Reportajes y análisis

Errores admiistradores seguridad

 La seguridad no es un mero problema técnico -es un problema de personas. Hay mucha tecnología que se puede descartar en una red antes de que lo aborden tontos problemas causados por personas.

Pero adivine qué. Esos errores frecuentemente son cometidos por las mismas personas que deberían saber mejor las cosas: los administradores de sistemas y otros miembros del staff de TI.
El reporte Insider Risk 2015 de Intermedia encontró que los profesionales de TI eran el grupo con mayor probabilidad de engancharse en "peligrosas prácticas de seguridad, como compartir passwords/logins, reusar passwords personales para aplicaciones de negocios, o dar credenciales de cuentas personales a otros.
Tales errores tienden a ser mucho más riesgosos que los de los usuarios comunes, debido a los poderes divinos que los administradores de sistemas tienen sobre la red. Los profesionales de TI pueden ser tan susceptibles como los usuarios al phishing, malware y otros ataques. Y las privilegiadas credenciales robadas casi siempre terminan en violaciones de seguridad mucho más graves.
He aquí 10 errores comunes de seguridad cometidos por administradores de sistemas y otros miembros del personal de TI:

Error Nº 1: El uso de Sudo para todo

Cuando uno se loguea como root, se tiene control total sobre la caja. Esto puede ser extremadamente peligroso porque si sus credenciales son robadas, un atacante puede hacer lo que él o ella quiera.
En el lenguaje de Windows no hay necesidad de loguearse como Administrador, si no hay alguna tarea de nivel administración que ejecutar. En lugar de ingresar directamente a los sistemas como root, regístrese a través de su cuenta personal y utilice Sudo para comandos específicos según se requiera.
Es fácil caer si no se es cuidadoso. Un script falla debido a que uno de los comandos necesitaba Sudo -y ahora todo debe ser reiniciado. Si falla en mantener el registro de qué comandos requieren privilegios elevados y cuáles no, puede regresar a ejecutar todo como Sudo.

Error Nº 2: Ejecutar scripts de origen desconocido

Instalar aplicaciones Linux de terceros es otra área en la que se puede abusar de Sudo. Todo lo que tiene que hacer es copiar y pegar el comando -el cual ya está ajustado para usar Sudo- directamente en el terminal para lanzar el script de instalación. Cada comando en ese script será ejecutado con privilegios de nivel elevado.
Aquí hay un ejemplo, copiado directamente de la Web (con la URL escondida):
sudo -v && wget -nv -O- https://xxx/xxx/linux-installer.py | sudo python -c "import sys; main=lambda:sys.stderr.write('Download failed\n'); exec(sys.stdin.read()); main()"
Esto le da a Sudo privilegios tanto hacia un elemento alojado en alguna parte en la web, como corriendo Python localmente. No es recomendable. Los administradores de Windows enfrentan potenciales catástrofes similares al ejecutar scripts PowerShell descargados.
Aún si confía en la fuente, nunca asuma que el script descargado de la Internet es seguro. Revise siempre los contenidos del script primero y verifique que la ejecución de los comandos no terminará en acciones nefastas.

Error Nº 3: Ejecución de servicios privilegiados como root

Las aplicaciones nunca deben ejecutarse como root. Cree cuentas de servicio único con privilegios muy específicos para cada aplicación y servicio ejecutándose en el equipo.
Las cuentas de servicio típicamente carecen de directorios de inicio y están restringidas a lo que pueden hacer en el sistema de archivos si alguien intenta loguearse usando la cuenta. Si un atacante compromete una cuenta de servicio, él o ella aún tiene que conseguir una vulnerabilidad local para obtener más privilegios para ejecutar código.
Cada aplicación debería usar una cuenta personalizada para acceder a la base de datos en lugar de root o de la cuenta personal del administrador. Las aplicaciones Web deberían ser propiedad del grupo y usuario adecuado. Cuando se asigna privilegios de dominio a aplicaciones de Windows, no otorgue el acceso de nivel de administrador.
Las principales distribuciones de Linux manejan servicios por defecto, pero el administrador manualmente configura paquetes de terceros, es fácil cometer un error. Recuerde cambiar los permisos después de que la instalación y configuración esté completa para asegurarse que el root o la cuenta personal del administrador ya no es el propietario de la aplicación.

Error Nº 3: Reutilizar los passwords

Adelante, abra los ojos. Todos hemos escuchado acerca de los peligros de reutilizar los passwords en los sitios, sistemas y aplicaciones. Pero el hecho es que es un gran problema y los administradores de sistemas no están inmunes.
Recientemente, Mozilla dijo que un atacante desconocido irrumpió en la cuenta de un usuario privilegiado en busca de su base de datos de rastreo de errores Bugzilla, y robó información acerca de 53 vulnerabilidades críticas. Resultó que el "usuario privilegiado había reutilizado el password de Bugzilla en otro sitio web y el password había sido expuesto en una vulnerabilidad de ese sitio.
Muchas veces, los servidores están ajustados con passwords de administrador débiles o con el mismo password que otros equipos de la red. Los ataques de fuerza bruta que utilizan passwords comunes y palabras del diccionario funcionan porque una cantidad suficiente de personas aún comete este error básico. Cuando muchas máquinas tienen el mismo password, el problema se agrava.
En lugar de ajustar el mismo password de root en todas las computadoras, los administradores de sistemas deberían optar por usar un archivo clave. Cada servidor debería tener un archivo de clave pública y la estación de trabajo del administrador de sistemas debería tener la clave privada asociada con la clave pública. De esta forma, el administrador de sistemas puede acceder a todos los equipos que han sido desplegados en la red, pero un atacante que se mueve lateralmente en la red no será capaz de registrase sin una clave válida. Y no hay ningún password que interceptar.

Error Nº 5: Compartir cuentas de administración

Las cuentas de administrador -como la de acceso a la base de datos y portales de administrador- frecuentemente son compartidas en la red. En lugar de ajustar el entorno de modo que los administradores soliciten privilegios elevados cuando se necesiten, estas cuentas de administración son compartidas queramos o no. Eso es buscar problemas.
Idealmente, debería haber cuentas separadas: una para root y una para cada administrador. Las cuentas de administrador no deberían comenzar con los niveles más altos de acceso -el administrador puede pedir derechos especiales de acceso cuando trabaje en tareas especializadas. El reporte de Intermedia encontró que 32% de los profesionales de TI han estado dando sus passwords y credenciales a otros empleados.
Es bastante malo no saber exactamente quién está usando la cuenta de administrador, pero es aún peor que los passwords raramente sean reiniciados cuando un administrador deja la compañía. Debido a que los passwords no son regularmente cambiados, los excolegas podrían regresar y causar daño con impunidad. La encuesta de Intermedia encontró que uno de cada cinco profesionales de TI dijo que accedería a información de la compañía después de haber dejado su trabajo actul. Las políticas de cambio de password no son solo para los usuarios finales. Cambie periódicamente sus passwords, en especial los de las cuentas de administración y servicio. Y cuando un administrador se vaya, reinicie los passwords.

Error Nº 6: Dejar las tareas de solución de problemas

Cuando se resuelven problemas se ejecutan varios trucos y experimentos para arreglar el problema. A medida que lo intenta, tiende a puentear el proceso usual. El problema viene cuando se trata de arreglar un problema y de moverse al siguiente. Los administradores con prisa pueden olvidar y dejar las cosas desarregladas y abiertas a potenciales abusos.
Puede que haya abierto puertos en el firewall, por ejemplo, mientras intentaba averiguar por qué una aplicación no respondía. Una vez que el arreglo está hecho, debe regresar y cerrar esos puertos antes de que puedan ser usados por atacantes. De la misma manera, si apagó el SELinux porque estaba interfiriendo con la solución de un problema, recuerde encenderlo de nuevo después de que todo está terminado.
Cuando se resuelven problemas mantenga un registro de lo que hace, mientras va avanzando, de modo que posteriormente puede restaurar las configuraciones a sus ajustes originales -excepto por los cambios que realmente necesite hacer.

Error Nº 7: Falla en mantener un registro de archivos de bitácora

Los archivos de bitácora son prácticos, especialmente cuando se trata de resolución de problemas, porque nos permiten ver lo que está ocurriendo al nivel más granular posible.
Cuando ya no necesita esos archivos más, apague el proceso que los generó. La última cosa que desea hacer es dejar el depurado encendido y generar archivos de bitácora que pueden ser útiles para los atacantes.
Como una buena práctica, siempre mantenga registro de los logs que ha creado y sepa qué clase de información hay en ellos.

Error Nº 8: Almacenar los passwords en archivos de texto plano

Cuando hay muchos passwords que seguir, es tentador escribirlos en un archivo de texto. Ese es un regalo para los atacantes que husmean por ahí, ya que accederán a varios sistemas. Suena obvio, pero todos saben al menos una instancia donde alguien guardó todos los passwords importantes en un archivo de texto.
Si los passwords deben ser grabados como texto plano en un archivo -como las credenciales de una base de datos para una aplicación- configure los permisos del archivo para restringir quién puede ver los contenidos del archivo. También asegúrese de que las cuentas de base de datos sean una cuenta despojadas de privilegios.

Error Nº 9: Dejar olvidadas cuentas no utilizadas

Las antiguas cuentas no utilizadas son pasivos. Quizás el software se instaló para evaluación, luego se removió -y las cuentas que fueron agregadas como parte de la instalación aún están en el sistema. No las deje ahí. Los atacantes podrían aprovechar cuentas olvidadas como esas, especialmente si tienen los passwords por defecto.
Para cuentas que deben permanecer en el sistema pero que no serán usadas más adelante, deshabilite la cuenta editando el archivo de password y reemplazando el password de la cuenta con una cadena de caracteres. Obviamente, cuando los empleados dejen su organización, se debe seguir un proceso para deshabilitar sus cuentas inmediatamente.

Error Nº 10: Ser laxo con los parches

La regla de oro: instale las actualizaciones de seguridad tan pronto como estén disponibles (respaldando primero los sistemas afectados). Muchos servidores son comprometidos no debido a una explotación de vulnerabilidad del día cero, sino debido a que un parche de un año de antigüedad nunca fue instalado.
Aún si se trata de un servidor crítico, un pequeño tiempo de caída como parte de una ventana de mantenimiento es mucho mejor que perder horas y días porque los atacantes comprometieron exitosamente la caja. Pruebe los parches tan pronto como sean liberados y cree un calendario para desplegar las actualizaciones.
Lamentablemente, puede verse frustrado en sus esfuerzos por colocar los parches de inmediato, usualmente porque los parches romperán una aplicación legacy. En ese caso, no se limite a encogerse de hombros y decir "qué mal. Muestre el problema a las instancias apropiadas. Escale el tema. Quizás hay formas de poner en cuarentena los servidores para minimizar el riesgo o adoptar nuevas tecnologías y reducir las dependencias en productos legacy.
En la vida real, los parches pueden ser un atolladero político. Si un gerente evita que parche un sistema, asegúrese de que todo el mundo entienda los riesgos de dejar de hacerlo.

No escatime en tecnología de seguridad

Como regla general, la tecnología de seguridad ayuda a mantener a los actores malos conocidos fuera, y puede ayudar a sacar los problemas a la superficie cuando las cosas van mal. Puede haber buenas razones para no ejecutar un antivirus o un firewall en una estación de trabajo o un servidor en particular, por ejemplo, pero esas situaciones son raras.
Considere los diversos tipos de malware DDoS que actualmente están rondando, infectando servidores Linux Web porque no tienen herramientas para mantener lo malo fuera. La tecnología de seguridad debería ser desplegada en cada punto final para mantener a los usuarios -la gerencia senior, trabajadores en las trincheras, administradores de sistemas, y otras personas con privilegios especiales- seguras contra los ataques.
Mantenga los equipos tan limpios como sea posible. Remueva las aplicaciones que no esté usando de modo que no tenga cuentas o herramientas olvidadas en el equipo. La meta es ejecutar el sistema tan limpio como se pueda para minimizar la superficie de ataque. Solo toma un error, un momento de falta de atención para que todo se caiga.
Las herramientas de seguridad le ayudarán a ver qué está ocurriendo en la red. Utilice Nmap para escanear puertos que pueden haber sido abiertos durante una sesión de resolución de problemas. Revise a qué equipos les falta parches y organice un plan.
Las herramientas están ahí para decirle lo que está mal y darle la oportunidad de arreglarlo antes de que los atacantes lo hagan. Pero toda la tecnología de seguridad del mundo no hará nada bien si los administradores de sistemas no enseñan con el ejemplo y siguen las reglas que establecieron para todos los demás.

 FUENTE: CIO PERU