Problemas de seguridad comunes a los que se enfrenta como proveedor de alojamiento (web) de Linux

Question

Pregunta a los usuarios que tienen su propio webhosting (ya sean servidores físicos o son revendedores):

¿Hay algún problema de seguridad común con el que tenga que lidiar en sus servidores? ¿Alguna sugerencia sobre cosas problemáticas que deberían desactivarse? ¿Algún error de seguridad estúpido específico del alojamiento web que deba evitar? ¿Alguna vulnerabilidad reciente que esté afectando a los servidores web?

Answer 1

La práctica de dar acceso a nivel de usuario a cualquier persona con una cuenta PayPal o tarjeta de crédito es en sí misma una locura. He estado trabajando en la industria del hosting durante la mayor parte de los últimos seis años y todavía lo encuentro una locura.

Esta es una lista de lo que hago para la mayoría de los servidores (compartidos o no) sin ningún orden lógico en particular:

• Casi nunca uso el kernel proporcionado por la distribución. Mantengo nuestro propio árbol de kernel que se mantiene en sintonía con la línea principal de Linux... hasta donde lo permite grsecurity. No es sólo una medida de seguridad, también es una medida de optimización. No encontrará cosas como soporte paralelo/usb/audio en nuestros núcleos (ya que los servidores web no los necesitan). Los núcleos están diseñados para utilizar sólo lo que necesitamos en la placa.
• 9/10 cosas malas son dejadas entrar por scripts de usuario con errores. Muchos clientes saben suficiente PHP como para ser peligrosos. mod_security es uno de mis mejores amigos, pago suscripciones a conjuntos de reglas reforzadas y las mantengo actualizadas casi semanalmente.
• La auditoría es fundamental, también recomiendo usar OSSEC o algo similar.
• Todos mis servidores están conectados a una LAN de mantenimiento, a la que puedo acceder independientemente de la red pública. Cuando las cosas van mal y encuentra su servidor tan ocupado enviando paquetes basura a través de Internet, apreciará tener otra forma de ingresar. También tengo IP KVM instalados en todos los servidores, o IPMI dependiendo del hardware.
• Últimamente he estado usando Xen como capa de gestión para servidores compartidos. Creo un único invitado que tiene el 99% de la memoria del sistema. Esto me permite hacer cosas como reparaciones del sistema de archivos/instantáneas/etc. de forma bastante sencilla. Realmente puede ayudar en la recuperación si algo sale mal (y es útil para ocultar la LAN del servidor compartido).
• Mantengo un firewall muy estricto basado en iptables que es especialmente estricto en lo que respecta a la salida.
• Tengo mucho cuidado con quién puede acceder al compilador del sistema y a las herramientas de vinculación.
• Actualizo el software del sistema religiosamente.
• Realizo análisis periódicos para asegurarme de que las personas no estén ejecutando, sin saberlo, versiones antiguas y vulnerables de aplicaciones populares como Wordpress, PHPBB, etc.
• Ofrezco instalación gratuita de cosas que los clientes "encuentran en Internet". Esto realmente me ayuda a auditar lo que se aloja y, al mismo tiempo, ofrecer a los clientes un valor adicional. También ayuda a garantizar que todo esté instalado de forma segura y correcta.
• Siempre, siempre, siempre refuerce PHP, asegúrese de usar suexec también para PHP. No hay nada peor que encontrar un bot en /tmp propiedad de 'nadie' :)

Finalmente, por último pero no menos importante:

• De hecho, leí los archivos de registro del sistema.Muchos hosts vienen corriendo para ver qué salió mal sólo después de que se da cuenta del problema. Incluso cuando se utilizan herramientas como OSSEC, es importante ser proactivo.

Answer 2

Parece que otras personas están entrando en muchos detalles, sin embargo, la mayor fuente de actividad maliciosa tiene que serftp.

Bloquearlo para ciertas IP, deshabilítelo para cuentas que no lo necesitan. Incluso deshabilite el servicio a menos que se solicite.

He tenido que lidiar con docenas de hacks después de que se carga código malicioso en sitios web, ya sea enviando spam al mundo o redirigiendo a los visitantes con inyecciones de iframe. Rara vez obtienen acceso de root o shell, sino que simplemente causan un montón de trabajo de limpieza manual al eliminar servidores de la lista negra y buscar código manualmente.

La fuente principal del hack no es el servidor en sí, sino las PC infectadas de los usuarios finales que huelen las contraseñas FTP y las envían de vuelta a la nave nodriza, para luego ser utilizadas desde una máquina diferente para cargar el código.

Answer 3

Trabajé para una empresa de alojamiento web durante un tiempo y es una pesadilla mantener seguros a todos los usuarios. Especialmente en un entorno compartido. Es mucho más fácil realizar un seguimiento de los servidores privados, ya que los problemas de seguridad se limitan únicamente a ese sistema.

Algunas cosas a tener en cuenta en un hosting compartido:

• Un error en un sitio puede afectar a todos los demás. Así que trate de limitar lo que cada usuario puede hacer y restrinja los permisos. Incluye ulimit, límites de php, etc.
• Monitorear el sistema y los sitios individuales. Una herramienta como OSSEC puede resultar muy útil para gestionar toda la información.
• El kernel de Linux no tiene un buen historial con respecto a los exploits locales. Así que asegúrese de que esté siempre actualizado y utilice extensiones de seguridad del kernel (grsecurity, SELinux, etc.).

Para los servidores privados, deja la seguridad en manos de sus usuarios, pero asegúrese de instalar QOS, NIDS y herramientas anti-DOS adecuadas en su red.