Servidor raíz hackeado a través de httpd - consecuencias y prevención futura

Question

Servidor raíz hackeado a través de httpd - consecuencias y prevención futura

4

Desde antes de mediados de 2014, mi servidor raíz fue atacado por hackers y recientemente obtuvieron acceso limitado. Deshabilité todos los servicios una vez que me di cuenta de que el servidor se había comprometido y comencé a investigar. Según los registros, esto fue aproximadamente una semana después de la intrusión exitosa.

Solía alojar un sitio web para un amigo que se basaba en el CMS de Joomla. Durante las investigaciones, me di cuenta de que el sitio web estaba muy desactualizado y prácticamente abandonado. Como su dominio y sitio eran el objetivo principal, sospecho que los atacantes explotaron errores conocidos o fallas de seguridad en el software para cargar sus propios scripts, principalmente para enviar correos electrónicos no deseados.

Acabo de enterarme de que un gran problema es, de hecho, que todos los sitios web tienen el mismo usuario. Una vez que los hackers obtuvieron acceso, podrían ejecutar comandos del lado del servidor con este usuario (que es "www-data").

No me importaría si esto solo hubiera afectado el sitio de mi amigo, pero desafortunadamente, crearon un script en uno de los otros dominios (que hasta esa fecha solo mostraba un index.html vacío). El archivo es una variante del shell remoto de PHP llamado WSO y es la razón principal por la que estoy pidiendo ayuda. Antes de limpiar y reinstalar mi servidor raíz, quiero asegurarme de que esto no volverá a suceder y quiero hacer estas preguntas:

Al parecer, el pirata informático logró instalar un script php fuera de los límites del dominio obsoleto / roto. ¿Como el hizo eso? ¿No debería nginx o php5-fpm tener algún tipo de mecanismo para evitar que los scripts php accedan a directorios fuera de la raíz del dominio actual?
Sé que algunos CMS como Joomla te preguntan si quieres usar la función php mail () o un servidor SMTP. ¿Cómo puedo evitar estrictamente que php envíe correos electrónicos por correo () y solo permitir smtp autenticado?
¿Es posible encapsular completamente el sitio web de mi amigo, de modo que una vez que un pirata informático logra inyectar algún script, no lo ayude a acceder a ningún otro sitio web, y mucho menos al sistema de archivos del servidor?
¿Cuál es la forma de ISP de restringir los scripts de los clientes y el comportamiento de envío de correo electrónico? ¿Es lo suficientemente bueno limitar el envío de correos electrónicos?

webserver hardening php cms

pregunta 08frak 15.02.2015 - 02:49

fuente

1 respuesta

Lea otras preguntas en las etiquetas webserver hardening php cms

¿Por qué se presenta FREAK como una vulnerabilidad completamente nueva? SSH frambuesa pi seguridad

score 4 · Accepted Answer

El atacante tuvo acceso a todos los demás hosts virtuales (lo que usted llama "dominios") porque todos se ejecutan bajo el usuario www-data , una vez que obtuvo los privilegios de este usuario, podría acceder a todos los demás dominios.

Para mitigar esto, puede usar mod_privileges en Apache para ejecutar cada host virtual bajo un usuario diferente y haga que cada host virtual use un grupo diferente de PHP-FPM que también se ejecuta bajo ese mismo usuario diferente. Si un atacante logra obtener acceso de shell en la cuenta de un host virtual e intenta ls el directorio de host virtual de otra persona, solo obtendrá un error Permiso denegado (a menos que "alguien más" haya ejecutado chmod -R 777 en su directorio, pero entonces él solo merece ser comprometido).

La directiva PHP open_basedir también puede ayudar, pero no es a prueba de balas y solo protegerá contra la lectura de archivos utilizando las funciones de E / S de archivos habituales de PHP, pero no ejecutando comandos de shell.

¿Cómo puedo evitar estrictamente que php envíe correos electrónicos por correo ()

PHP tiene una directiva de configuración para deshabilitar ciertas funciones, por lo tanto, como una solución simple, puede usar eso, pero no lo protegerá contra el uso de sockets en bruto para conectarse a un servidor de correo y volcar el spam allí. La mejor solución es bloquear las conexiones salientes al puerto 25. El SMTP autenticado puede usar el puerto de envío (587), por lo que los usuarios legítimos aún podrán usar el servidor de su propio proveedor de correo o el servidor que proporcione, pero no podrán escanear para relés abiertos en el puerto 25 y trate de enviar su spam.

¿Es posible encapsular completamente el sitio web de mi amigo

Puede poner cada servidor en una jaula chroot y ejecutarse en un puerto diferente, y tener un servidor web liviano frente a ellos que actúa como un proxy para redireccionar las conexiones del puerto HTTP estándar al servidor chroot correcto. en el nombre de dominio. Puede ir aún más lejos utilizando LXC (contenedores) o máquinas virtuales / servidores físicos completos para esto, dependiendo de sus requisitos de seguridad.

¿Cuál es la forma de ISP de restringir los scripts de los clientes y el comportamiento de envío de correo electrónico?

Algunos ISP (malos) simplemente bloquean el puerto 25 a cualquier cosa que no sean sus propios servidores (desde donde pueden rastrear al usuario incluso si no se autentica porque saben qué IP pertenece a quién), algunos le permiten usar el puerto libremente y asumo que simplemente cancele su cuenta si reciben demasiadas quejas sobre el spam de su IP.

Después de leer los términos y condiciones de OVH (un popular ISP francés), parecen monitorear su tráfico SMTP saliente y pasar cada main a través de su filtro basado en Spamassasin, y si muchos correos electrónicos se consideran spam, bloquean su puerto 25.