Privilegios de usuario para código no saneado

  

si es una buena idea hacer sandboxing y bajar privilegios

SIEMPRE! Cada vez, en todas partes (el inglés es raro), aísla tus procesos. En un mundo ideal, haríamos SELinux al infierno de cada aplicación, usuario, archivo, etc.

Un control de acceso obligatorio debidamente establecido proporciona tanto protección contra ataques como detección de compromiso cuando ve patrones en sus registros de auditoría que simplemente no deberían estar allí, que por supuesto siempre está revisando para corregir malas reglas o notar algo no deseado. ha sucedido.

WAF, MAC, firewalls, etc. son armaduras para tu servidor web. Te hacen más pesado y más lento, y la armadura de pecho no evita que te disparen en el brazo, pero mejora tus probabilidades de supervivencia.

AppArmor es una interfaz más simple para los módulos de seguridad de Linux, y un sustituto decente para la combinación de aplicaciones específicas que usted considera de alto riesgo si SELinux está derritiendo su cerebro.

  

si es una buena idea proteger o no las adiciones a un sitio antes de proteger el sitio en general

¡Sí otra vez! Cuanto más compartimentado puedas hacer las cosas, mejor estás. Si el módulo solo necesita acceso a la tabla de publicaciones, proporciónele un contexto donde no pueda acceder a la tabla de credenciales, etc. Es mucho más difícil filtrar el acceso que no tiene que el acceso que tiene.

hay buena información en algunas de las otras respuestas, seguro. Yo agregaría que puede derrotar a casi todas las inyecciones de código de bajo nivel con un simple truco: use un procesador que no sea x86. El malware o la carga útil escrita para x86 simplemente no funciona en un procesador que no sea x86. Linux y algunos BSD han sido portados a muchas arquitecturas de procesadores. Si usa una pila web portátil, puede simplemente compilarla para esas arquitecturas e implementar una aplicación web sobre ella. Configure las cosas correctamente y ahora solo tiene que preocuparse por los ataques de nivel de aplicación.

Algunos lo acusarán de ser seguridad por oscuridad. No es verdad. Esto es ofuscación y tiene valor comprobado. Funciona siempre y cuando no se adopte ampliamente hasta el punto de que los piratas informáticos pongan un montón de esfuerzo en la táctica. Ha funcionado para mí y para muchos otros, incluidos los grandes mercados de NUMA / mainframe, durante casi diez años. Eso está diciendo algo. La mayoría de los atacantes usan kits prefabricados. Y casi todas las personas que hacen kits escriben x86 de escritorio / servidor o ARM móvil. Simplemente no hay una mano de obra importante disponible para explotar fácilmente tus cosas ejecutando POWER, Alpha, MIPS, SPARC, etc. Entonces, es una especie de economía + ofuscación que funciona a tu favor.

Recuerde, sin embargo, combinar este truco con buenas prácticas de seguridad en el área de elección de software, configuración, permisos, monitoreo, etc. La ofuscación por sí sola no es suficiente para evitar todos los problemas. Sólo un montón de ellos. ;)

Nota: También trataría de evitar el uso de plataformas que sean fáciles de omitir o inyectar código. PHP tiene una mala historia con ese tipo de cosas. Los tiempos de ejecución estáticos, de tipo seguro y administrados suelen ser los más fáciles de proteger del código problemático. Solo tienes que preocuparte menos por ellos y tenemos trucos como SFI y Native Client para tratar con el código nativo en esas plataformas si uno está tan inclinado.