Asegurar servidores web PHP

31

Las aplicaciones PHP tienen reputación de tener problemas de seguridad superiores a la media. ¿Qué técnicas de configuración utiliza para asegurarse de que la aplicación sea lo más segura posible?

Estoy buscando ideas como:

Normalmente uso Linux, pero siéntase libre de sugerir soluciones de Windows también.

David Pashley
fuente

Respuestas:

15
  1. Use la directiva open_basedir para limitar sus scripts PHP a su directorio de inicio y eventuales directorios de aplicaciones adicionales. Esto es muy eficiente por sí mismo.

  2. Use php reforzado porque eso no cuesta nada y puede ayudar.

  3. Use suPHP para que los scripts PHP se ejecuten como el propietario del archivo (un usuario por sitio web) y evite usar archivos con permisos incorrectos como 777 ... suPHP también puede permitirle tener php.ini por sitio web para que ese sitio sea estúpido requisito no destruir todo.

  4. Mod_security es una gran ventaja, pero debe usarse y configurarse bien.

Antoine Benkemoun
fuente
Algunos sitios malos realmente necesitan register_globals y fopen, por eso usa php.ini por sitio con suPHP. Un sitio puede simplemente convertirse en kamikaze y los otros pueden estar (casi) perfectamente seguros.
Antoine Benkemoun
44
Si utilizan register_globals y fopen, sugiere que la calidad es tan mala es posible que desee reconsiderar el uso de ellos :)
David Pashley
Si pagan 150 € / mes, no lo reconsideras.
Antoine Benkemoun
3

En mi experiencia, la mayoría de las vulnerabilidades en un sitio web basado en PHP son el resultado de un diseño pobre (del sitio), en lugar de fallas en el propio PHP.

Algunos consejos rápidos:

  • Filtro universal de entrada, salida de escape. Clarificación: el filtro no significa escape, significa "si encuentro algo sospechoso en esta entrada del usuario, provocará que falle el envío y le diga al usuario que vuelva a formatear".
  • En lugar de usar escapeshellcmd (), simplemente no permita que ninguna entrada de usuario se ejecute en el shell . Eso es peligroso y probablemente nunca sea realmente necesario.
  • No llame a funciones como phpinfo () en un sitio de producción (o si lo hace, consulte a continuación *).
  • Cuando diseñe una aplicación web, siempre considere "¿es este un posible vector de ataque?" Digamos, inyección SQL. Si la respuesta es "sí", conéctelo de inmediato; no diga "ok, lo agregaré más adelante en el desarrollo como una característica". La seguridad nunca es una característica.
  • Nunca envíe errores sin procesar al usuario; esto significa configurar php.ini's display_errors = Off, log_errors = On. Atrapa errores en tiempo de ejecución y genera algo bonito. Tomemos como ejemplo la ballena de Twitter: no le dará al usuario información sobre el nivel de depuración, solo dice "woops, algo se rompió, por favor actualice".

* También puede echar un vistazo a una breve publicación que escribí llamada "Asegurando phpinfo (), más o menos" y asegúrese de leer los comentarios http://egovsergo.com/2009/04/03/protecting-your-phpinfo/ Fue una idea rápida que tenía que proteger (algo) phpinfo () si de alguna manera olvidé eliminarlo en un sitio de producción.

De manera más general, algunos desarrolladores escriben contenedores para funciones confidenciales que verifican si el indicador "sitio de producción" no está configurado o no, y deshabilita la función sensible en producción.

msanford
fuente
Mi pregunta era más sobre cómo proteger su servidor contra PHP mal escrito. :) No quise decir que PHP en sí era inseguro, más que atrae a desarrolladores menos experimentados y la biblioteca estándar requiere que recuerden proteger cada llamada, en lugar de que la biblioteca proteja a todos los usuarios. +1 ya que es una respuesta muy útil.
David Pashley
Tuve esa impresión y respondí en consecuencia :) ¡Gracias por el comentario! No puedo meterme en todo esto aquí, obviamente, pero esos son algunos grandes pozos. Si tiene preguntas más específicas, seguramente puede plantearlas en Stack Overflow y yo y todos los demás contribuiremos. (Y por lo que vale, soy un ZCE).
msanford
3

Otros parámetros que deben modificarse para fortalecer el PHP:

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,shell_exec,show_source,phpinfo"

Almacene todos los errores de PHP en el archivo /var/log/phperror.log :

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log
Deem3n
fuente
1

He agregado los repositorios dotdeb a mi /etc/apt/sources.lst

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Como parchan php / apache / mysql con mucha más frecuencia que Debian.

Brent
fuente
1

Considera configurar open_basedir "por sitio". open_basedires una configuración de php.ini que evitará que sus scripts accedan a archivos fuera de una lista blanca definida. Si su servidor aloja varios sitios, evitará que un sitio lea la configuración de la base de datos de otro sitio. También evitará que un script php acceda / modifique archivos centrales del sistema. Open basedir es fácil de configurar, simplemente agregue la línea " php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/list" a cada servidor virtual Apache.

También considere desactivar el motor de script PHP para todos los sitios / carpetas que no deberían contener scripts PHP (por ejemplo, una carpeta de imágenes cargadas). Nuevamente, esto es simple, agregue "motor php_admin_value apagado" a cualquier Apache VirtualHosts que no necesite php. Para deshabilitar PHP en un directorio, coloque lo mismo en una etiqueta de Directorio.

Ejecute permisos de archivo lo más estrictos posible, evite el acceso de escritura a los scripts PHP para el usuario de Apache, esto evita que un script en ejecución se modifique a sí mismo u otros scripts en el mismo sitio / servidor. Si es posible, evite los permisos 777, calcule los permisos mínimos necesarios para ejecutar la aplicación y utilícelos.

Si aloja varios sitios, cada uno con su propia base de datos, use un usuario separado de MySQL / Postgres para cada uno y establezca permisos para cada usuario de modo que solo tengan acceso a las bases de datos relevantes. Una vez más, esto evitará que un script falso altere la base de datos de otra aplicación.

Suosin, HardenedPHP, mod_security y similares también son valiosos, pero úsalos además de una configuración estrechamente bloqueada, no en lugar de.

Jim OHalloran
fuente
0

Suhosin tiene un costo de rendimiento bastante sustancial, por lo que el comentario "no cuesta nada" está un poco fuera de lugar.


fuente
2
¿De qué sirve un sitio web rápido y pirateado? :) hardened-php.net/suhosin/benchmark.html sugiere 8.85% más lento en un punto de referencia. Eso puede ser aceptable por los beneficios de seguridad que proporciona. Esto probablemente debería haber sido un comentario en lugar de una respuesta.
David Pashley
Suhosin protege principalmente contra ataques locales. Por lo tanto, si comparte su servidor con personas en las que no confía, puede valer la pena. Si tiene su propio servidor, o su propio segmento vm, no veo el punto.
0

¿Está buscando algunas sugerencias básicas de firewall / topología? Me gusta la idea de usar cosas como libra para evitar el acceso directo al servidor web PHP desde las redes internas sin lavar. De esa manera, también puede segregar el servidor web de otras partes de su red.

DF
fuente
No, estoy buscando formas de mejorar la seguridad del tiempo de ejecución de PHP.
David Pashley
0

Usar Suhosin / mod_security / SuPHP ciertamente hará que su servidor PHP sea seguro. Deshabilitar ciertas funciones como exec, passthru, system y escapeshellcmd también ayudará mucho.


fuente
1
¿No se usa escapeshellcmd () solo para escapar de la cadena? No proporciona ninguna forma de ejecutar un proceso. ¿Cómo podría alguien usarlo para causar un problema?
David Pashley