Para ver la respuesta específica a su pregunta, consulte /magento//a/72700/361
Antecedentes
En primer lugar, no hay una vulnerabilidad específica : hay una serie de artículos que circulan en este momento que no han leído ni entendido el artículo original.
El artículo original simplemente decía (y estoy parafraseando),
Si un hacker eran capaces de obtener acceso a sus archivos de Magento, que podrían capturar la información de su cliente
La parte clave es que el hacker necesita acceder a su servidor y modificar los archivos.
No se asuste ... esto no es nada específico de Magento
En términos de captura de información, no hay nada específico para Magento que cualquier otro sitio web / plataforma. Si un pirata informático obtiene acceso a sus archivos, se termina el juego de manera efectiva: podría capturar la información que quisiera.
Lo mejor que puede hacer (y, en última instancia, lo mínimo que debe hacer) es mantener una buena política de seguridad que cumpla con los Estándares de Seguridad PCI de la industria de procesamiento de pagos, puede encontrar la lista aquí, https://www.pcisecuritystandards.org /documents/Prioritized_Approach_for_PCI_DSS_v3_.pdf
Endurece tu tienda
Realmente puede bloquear las facetas de su tienda que reducen en gran medida el área de ataque de superficie para un pirata informático, o al menos, retrasan su progreso si logran entrar /
Bloquear permisos
Puede restringir los permisos en la raíz del documento para permitir solo la escritura en directorios esenciales ( /vary /media)
Esto es lo que hacemos por defecto en MageStack ,
echo -n "Fixing ownership"
chown -R $SSH_USER:$WEB_GROUP $INSTALL_PATH && echo " ... OK" || echo " ... ERROR"
INSTALL_PATH="/path/to/public_html"
chmod 750 $INSTALL_PATH
find $INSTALL_PATH -type d ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing file permissions"
find $INSTALL_PATH -type f ! -perm 740 -exec chmod 740 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing cron permissions"
find $INSTALL_PATH/*/cron.sh -type f ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var file permissions"
chmod -R 760 $INSTALL_PATH/*/media $INSTALL_PATH/*/var && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var directory permissions"
find $INSTALL_PATH/*/media $INSTALL_PATH/*/var -type d ! -perm 770 -exec chmod 770 {} \; && echo " ... OK" || echo " ... ERROR"
Ajustar INSTALL_PATH,SSH_USER,WEB_GROUPa la medida. Lo importante es que SSH_USERno es el mismo usuario que PHP usa para el proceso del servidor web, de lo contrario, esencialmente estaría proporcionando acceso de escritura completo al servidor web (mitigando cualquier beneficio).
Bloquee su acceso de administrador / descargador
En MageStack, configuraría esto en ___general/x.conf
set $magestack_protect_admin true;
set $magestack_protect_downloader true;
En Nginx, puedes usar esto,
location ~* ^/(index.php/)?admin{
satisfy any;
allow x.x.x.x;
auth_basic "Login";
auth_basic_user_file /microcloud/data/domains/x/domains/x/___general/.htpasswd;
deny all;
location ~* \.(php) {
include fastcgi_params;
}
try_files $uri $uri/ /admin/index.php ;
}
Hay un poco más de documentación sobre cómo preparar un .htpasswdarchivo aquí
Envuelva el cron.shproceso
Me he encontrado con otros proveedores de alojamiento que usan máquinas dedicadas para el uso de cron / admin, lo que significa que modificar el cron.sharchivo permitiría la ejecución remota de código en el cron / admin sin necesidad de acceder a él. Terminar el proceso con el usuario correcto en un fakechroot puede ir un poco más allá para bloquear el proceso.
Hay demasiado código para publicar, pero hay un script aquí . Es específico de MageStack, pero podría ajustarse para su uso en configuraciones de servidor menos elegantes :)
Auditoria, auditoria, auditoria
Linux es fantástico en términos de inicio de sesión y aprovechar eso le dará una visión completa de lo que está haciendo su servidor.
Una característica fantástica en MageStack es la herramienta de auditoría que registra todos los tipos de acceso e incluso los cambios de archivos a diario. Puedes encontrar los registros aquí,
/microcloud/logs_ro
|-dh[0-9]+
|---access-YYYY-MM-DD.log.gz
|---backup-YYYY-MM-DD.log.gz
|---magescan-YYYY-MM-DD.log.gz
|---php-differential-YYYY-MM-DD.log.gz
|-acc[0-9]+
|---access-YYYY-MM-DD.log.gz
Si no está utilizando MageStack, puede replicar algo de esto con su propio proveedor de alojamiento con bastante facilidad, rsyncsiendo la herramienta más simple para hacerlo.
P.ej. Si sus copias de seguridad están disponibles localmente, puede hacer lo siguiente. Esto ejecutará en seco comparar dos directorios y producir una lista de parches diff.
rsync -na /path/to/public_html/ /path/to/backup/public_html/ > change.log
grep -E '\.php$' change.log | while read FILE; do
diff -wp /path/to/public_html/$FILE /path/to/backup/public_html/$FILE >> php-differential.log
done
Los cambios en PHP son tan poco frecuentes que puede programar que se ejecuten diariamente (o varias veces al día) y notificarle por correo electrónico si hay un cambio en el archivo PHP.
En resumen
- Use el control de versiones, es más fácil rastrear cambios
- Solo tener un certificado SSL no es suficiente para que su sitio sea seguro
- No esperes a ser hackeado para considerar la seguridad
- El hecho de que redirija a su proveedor de pasarela de pago (en lugar de capturar información) no significa que pueda evitar el cumplimiento de PCI, aún debe cumplir
- Sea proactivo, esté seguro y completo: verifique el código del módulo antes de instalarlo, revise los archivos PHP diariamente, revise los registros, verifique el acceso FTP / SSH, cambie las contraseñas regularmente
Sus clientes depositan una enorme cantidad de confianza en usted cuando pasan toda su información privada, y si traiciona esa confianza al no operar un negocio seguro, perderá su costumbre y toda la costumbre futura.
Las investigaciones forenses de PCI son increíblemente caras, requieren mucho tiempo y, en última instancia, arriesgan su capacidad de poder volver a aceptar pagos con tarjeta. ¡Nunca te dejes poner en esa posición!
Parchear
Magento lanzó recientemente una serie de parches que arreglaron agujeros, incluidos algunos que permitían la ejecución remota de código. Puede buscarlos aquí, https://www.magentocommerce.com/products/downloads/magento/
Pero estos nuevos artículos no se refieren a un nuevo exploit, simplemente indican cómo los hackers están aprovechando los exploits históricos (o cualquier otro vector de ataque) para poder capturar la información del titular de la tarjeta.
Fuentes