Recabamos en diferentes foros y así brindarte la solución a tu dilema, en caso de dificultades puedes dejarnos tu inquietud y responderemos con mucho gusto, porque estamos para ayudarte.
Solución:
Solución 1:
Estos son los argumentos a favor de la utilidad que he encontrado hasta ahora:
Los núcleos modernos corrigen el /lib/ld-linux.so agujero, por lo que no podrá asignar páginas ejecutables desde un noexec sistema de archivos
El punto de los intérpretes ciertamente sigue siendo una preocupación, aunque creo que menos de lo que la gente podría afirmar. El razonamiento que se me ocurre es que ha habido numerosas vulnerabilidades de escalada de privilegios que dependían de hacer llamadas al sistema mal formadas. Sin un atacante que proporcione un binario, sería mucho más difícil realizar llamadas al sistema malvadas. Además, los intérpretes de secuencias de comandos no deberían tener privilegios (sé que, históricamente, a veces no ha sido así, como con suid perl), por lo que necesitarían su propia vulnerabilidad para ser útiles en un ataque. Aparentemente, es posible usar Python, al menos, para ejecutar algunos exploits.
Muchos exploits ‘enlatados’ pueden intentar escribir y ejecutar ejecutables en /tmpy entonces noexec reduce la probabilidad de caer en un ataque programado (por ejemplo, en la ventana entre la divulgación de la vulnerabilidad y la instalación del parche).
Por lo tanto, todavía hay un beneficio de seguridad para montar /tmp con noexec.
Como se describe en el rastreador de errores de Debian, configurar APT::ExtractTemplates::TempDir en apt.conf a un directorio que no es noexec y accesible para root obviaría la preocupación de debconf.
Solución 2:
Muchos paquetes de Debian requieren que /tmp sea ejecutable para que el paquete se instale. Estos a menudo se marcan como errores (de gravedad ‘normal’/’lista de deseos’):
https://www.google.com/#q=site:bugs.debian.org+noexec+/tmp
Justo hoy recibí este error mientras instalaba un kernel actualizado en la rama estable.
Así que parece que Debian (¿y derivados?) no está listo para montar /tmp noexec…
Solución 3:
agregue lo siguiente a /etc/apt.conf, o /etc/apt/apt.conf.d/50remount
DPkg::Pre-Install-Pkgs "mount -o remount,exec /tmp";;
DPkg::Post-Invoke "mount -o remount /tmp";;
Solución 4:
Aunque existen soluciones alternativas para la mayoría de las medidas de seguridad complementarias que podría elegir implementar, incluso las medidas de seguridad más fáciles de eludir (como montar /tmp noexec o ejecutar SSH en un puerto alternativo) frustrarán los ataques automatizados o con secuencias de comandos que se basan en los valores predeterminados en orden. funcionar. No lo protegerá contra un atacante determinado y experto, pero más del 99 % de las veces, no se enfrentará a un atacante determinado o informado. En su lugar, se estará defendiendo de un script de ataque automatizado.
Solución 5:
Primero:
Cubre muchos casos de ataque diferentes. Apagarlo porque había algunas formas conocidas de evitarlo (algunos de los cuales incluso se arreglaron) es extraño. Los atacantes descargan código para /dev/shm o /tmp es una cosa común que hacen.
La defensa en profundidad se trata de asegurar los waypoints más comunes, cada uno de los cuales los detiene hace que su sistema tenga más capacidad de supervivencia. No es seguro. Pero también tendrá una oportunidad. Si no pueden obtener su carga útil secundaria, es muy probable que lo estés obteniendo.
- También puede ser detenido por restricciones de usuario de iptables.
- También puede ser detenido por SELinux.
- también podría no detenerse debido a otro exploit de fácil acceso.
El punto es hacerlo tan difícil como tú. fácilmente puede, y eliminó el 99% de los ataques.
Segundo:
Detiene las malas prácticas (ejecutar cosas de forma temporal, realizar instalaciones importantes de aplicaciones a través de /tmp en lugar de un usuario tmpdir), dejando datos en /tmp. Los instaladores personalizados suelen entiendo TMPDIR
Además: incluso si no: el tiempo de instalación, como una acción puntual, no es una razón válida para desactivar un problema de seguridad permanentemente.
Tercera:
Teniendo en cuenta los espacios de nombres anónimos en /tmp (una “característica”), realmente desea restringir lo que se coloca allí y ejecutar desde allí.
Cuatro:
La conveniencia no es un factor relevante en esto. Suponiendo que ejecutamos servidores por dinero y con un propósito: somos responsables de estas cosas. “Oh, no cerré /tmp porque luego necesito unos minutos más cuando actualice mi software el próximo año”. Seguramente no será solo esto lo que se interponga entre ser chantajeado y estar bien. ¿Una buena razón? No lo creo.
Que tal este:
“Aprendimos que los enemigos pueden atacar sin previo aviso. También podrían usar cientos de espías para envenenar la comida. Así que dejamos de dar armas a nuestros soldados”.
¿Esperar lo?
Hay otras medidas que requieren mucho más esfuerzo, experiencia y suerte para asegurar un sistema, y saber que las personas tienen dinero limitado, esperanza de vida y también les gustaría pasar tiempo con sus familias: No te saltes las cosas fáciles.