it-swarm-es.com

Dado el acceso a SSH, ¿qué debo hacer para proteger las acciones de usuario de un servidor y monitorear (peligroso)?

contexto :

  • Pequeña empresa, sobre todo una casa de software para aplicaciones web, pero también un software de escritorio.
  • Muchos colaboradores externos, por lo que una variedad de usuarios externos con acceso a los servidores.
  • Un solo servidor físico, con Linux y Xen como una solución de virtualización, cada uno VM tiene usos específicos y acceso controlado. Los usuarios externos pueden acceder a dos de ellos
  • Los servidores (virtuales) proporcionan una variedad de servicios: pila de lámpara, correo electrónico, DNS, etc. Esta pregunta se refiere a mis inquietudes con el acceso al usuario local
  • Los usuarios pueden ssh en dos de las máquinas virtuales.

Requisitos

  • Dar a los usuarios acceder a herramientas de desarrollo comunes, tanto para web (PHP, Ruby en rieles, etc.) y aplicaciones independientes (GCC, G ++, etc.); Esto incluye no solo los compiladores y similares, sino también. Editores. En este momento, tienen acceso completo.
  • Los usuarios deben poder usar el control de origen en el servidor: SVN y GIT
  • Algunos tienen acceso a las bases de datos MySQL

Pregunta

¿Qué pasos debo tomar para:

  1. Proporcionar una cáscara completa a los usuarios si es posible, o una solución equivalente que cumpla con los requisitos anteriores de manera segura
  2. Automatice la supervisión de actividades peligrosas donde sea posible (como en las notificaciones de sudo/su)
  3. Minimizar los efectos si un usuario obtiene sus manos en un Exploit de escala de privilegios de los días antes de que alguien lo parpadea en el servidor, ¿es posible esto incluso?
13
tomeduarte

Si los usuarios deben tener SSH a su servidor, una herramienta útil para proteger su raíz del servidor es chroot : esto le permitirá darles la funcionalidad aparente de la raíz del servidor, sin darles realmente las joyas de la corona.

Alternativamente, a medida que usa máquinas virtuales de todos modos, ¿por qué no proporcionarles instancias de servidor virtual?

Ambos de estos le permitirán ejecutar herramientas de monitoreo (tales como TripWire ) para verificar los cambios en los archivos. El registro debe hacerse fuera del entorno de los usuarios.

Con las entradas en/etc/sudoers, puede limitar las actividades que los usuarios pueden llevar a cabo bajo su.

9
Rory Alsop

También puede restringir a los usuarios a usar Bash 4 (eliminar otras conchas) y registrar todos los comandos y enviar copias a un servidor de registro separado.

bash: historia a syslog ( http://blog.rootshell.be/2009/02/28/bash-history-to-syslog/ )

Esto puede ayudarlo a auditar las actividades de los usuarios y, lo que es más importante, realice los forenses cuando alguien hace algo malo. También haría la información de divulgación legal completa: todas las actividades son registradas y auditadas, los infractores serán procesados, etc.

Desplegando OSSEC (sistema de detección de intrusión basado en el host) también ayudaría; Tiene muchas reglas incorporadas para detectar y alertarlas a las cosas malas. Ossec puede alertarlo a todas las actividades de SUDO/SU.

7
Tate Hansen

No se olvide de los túneles, el reenvío del puerto. De forma predeterminada, PermisoTcPorwarding es SÍ en el archivo SSHD_CONFIG y permite a los usuarios reenviar los puertos arbitrarios. Puede causar mucho más problemas de lo que puedes adivinar. (Esta no es una respuesta ideal de estilo Stacekexchange, pero no pude encontrar una mejor respuesta, es difícil resumir el reenvío de puertos con algunas oraciones) debe aprender más sobre el reenvío de puertos antes de permitir el acceso.

reenvío de puertos en pocas palabras

SSH permite los flujos de datos multiplexante sobre una sola conexión SSH. Una o más de estas corrientes pueden ser un puerto hacia adelante , de modo que el tráfico a un puerto en la computadora cliente del atacante se envía a través de la conexión SSH a un especificado Puerto en un host especificado del servidor . Esto significa que si su servidor de Shell tiene acceso, por ejemplo, un servidor MySQL, entonces cualquier persona que se conecta a la caja SSH puede acceder directamente al servidor MySQL. Luego, pueden usar sus propias herramientas de cliente en lugar de limitarse al software que ha proporcionado en la caja SSH.

6
Nathan B.