¿Mejores métodos para limpiar un sitio pirateado sin una versión limpia disponible?

Se me ha pedido que solucione un sitio pirateado que se creó utilizando osCommerce en un servidor de producción.

El sitio siempre ha existido en el host remoto. No hay una versión de limpieza sin conexión. Olvidemos lo estúpido que es esto por un momento y lidiemos con lo que es.

Se ha pirateado varias veces y otra persona lo ha solucionado al eliminar los archivos del shell web / cargar scripts.

Se piratea continuamente a menudo.

¿Que puedo hacer?

    Debido a que no puede confiar en nada en el host web (puede haber tenido un rootkit instalado), el enfoque más seguro es reconstruir un nuevo servidor web desde cero; no se olvide de actualizar todo el software externo antes de ponerlo en línea . Haga todas las actualizaciones en el lado feliz de un firewall draconiano.

    Cuando reconstruya el sistema, asegúrese de prestar especial atención a la configuración adecuada. Si el contenido web es propiedad de un usuario diferente de Unix que el ID de usuario del servidor web y los permisos de los archivos están configurados para prohibir la escritura, entonces el servidor web no puede modificar los archivos del progtwig.

    Configure la cuenta de usuario de Unix de su servidor web para que tenga acceso de escritura solo a sus archivos de registro y bases de datos, si están en el sistema de archivos. Un servidor web pirateado aún podría servir páginas pirateadas a los clientes, pero un reinicio podría ‘deshacer’ el ‘hackeo en vivo’. Por supuesto, los contenidos de su base de datos podrían enviarse al Yakuza o corromperse por personas que piensen que sus datos deberían incluir imágenes de unicornios. El Principio de Privilegio mínimo será una buena guía. ¿A qué exactamente necesita acceder su servidor web para hacer su trabajo? Concede solo eso.

    También considere implementar un sistema de control de acceso obligatorio como AppArmor , SELinux , TOMOYO o SMACK . Cualquiera de estos sistemas, configurados correctamente, puede controlar el scope de lo que se puede dañar o filtrar cuando se piratea un sistema. (He trabajado en AppArmor durante diez años y confío en que la mayoría de los administradores de sistemas puedan aprender a implementar una política de seguridad viable en sus sistemas en un día o dos de estudio. Ninguna herramienta es aplicable a todas las situaciones, así que asegúrese para leer sobre todas sus opciones).

    La segunda vez, asegúrese de mantener su configuración administrada a través de herramientas tales como marionetas , chef o, como mínimo, en un sistema de control de revisiones .

    Actualizar

    Algo más, un poco no relacionado con volver a estar en línea, pero potencialmente educativo de todos modos: guarde el disco duro del sistema comprometido, para que pueda montarlo e inspeccionar su contenido desde otro sistema. Tal vez hay algo que se puede aprender al hacer análisis forense sobre los datos comprometidos: es posible que el compromiso se haya producido meses antes y haya estado robando contraseñas o claves ssh . Es posible que encuentre un rootkit o más herramientas de explotación. Es posible que encuentre información para mostrar el origen del ataque, quizás el administrador de ese sitio aún no se haya dado cuenta de que ha sido pirateado.

    Tenga cuidado al inspeccionar datos pirateados: ese .jpg que usted no reconoce podría ser el exploit que crackeó el sistema en primer lugar, y verlo en un sistema “bien conocido” también podría descifrarlo. Haga el trabajo con un disco duro que puede formatear cuando haya terminado. (Virtualizado o con un sistema de control de acceso obligatorio puede ser suficiente para limitar los piratas informáticos “pasivos”, pero no hay nada como los sistemas desechables para la tranquilidad).

    Obtenga una copia nueva de la versión de osCommerce con la que se creó el sitio, y haga una diferencia entre el nuevo osCommerce nuevo y el sitio pirateado. También verifique los archivos que existen en el servidor pero no en el paquete osCommerce.

    Al comparar manualmente las diferencias, puede rastrear todos los lugares posibles que el hack haya creado o modificar los guiones.

    Sé que es un poco tarde para ofrecer esta solución, pero la solución oficial del desarrollo de osCommerce está aquí: http://library.oscommerce.com/confluence/display/OSCOM23/(A)+(SEC)+Administration + Herramienta + inicio de sesión + actualización

    Una vez que se aplican los cambios en el código, la mayor parte del trabajo real es limpiar el sitio web. El exploit de omisión de inicio de sesión de administrador será la causa que ha permitido a los atacantes cargar archivos a través del administrador de archivos (generalmente) en directorios que se pueden escribir, a menudo el directorio de imágenes.

    Hay otros archivos que a menudo también se pueden escribir, y pueden tener códigos maliciosos añadidos. cookie_usage.php e includes / languages ​​/ english / cookie_usage.php son los archivos habituales que se ven afectados, sin embargo, en algunas configuraciones de servidor, todos los archivos del sitio pueden ser susceptibles.

    Aunque el arreglo oficial de osCommerce está vinculado al anterior, también sugeriría hacer este cambio: en la página anterior, desplácese hacia abajo hasta que vea el enlace que dice “Actualizar el valor de PHP_SELF”. Haga esos cambios también.

    Esto corregirá la forma en que $ PHP_SELF informa y evita que los atacantes usen URL mal formadas en bashs de eludir el inicio de sesión de administrador.

    También sugiero que agregue el inicio de sesión de autenticación básica de htaccess en el directorio de administración.

    También vea un complemento que he creado, llamado osC_Sec, que es una solución de seguridad integral que, aunque funciona en la mayoría de los sistemas web respaldados por php, está específicamente diseñado para tratar los problemas que existen en las versiones anteriores de osCommerce. http://addons.oscommerce.com/info/8283