KnowLEDGEBASE · SUSCANDO WEB
Mi sitio web fue hackeado, ¿qué hacer?
Última actualización 2020-04-02
Aquí hay algunos consejos para mantener su sitio seguro. Esto se escribió principalmente en respuesta a un sitio hackeado:
1. Lo primero que necesitas hacer es comprobar todos los sitios de proveedores/desarrolladores para TODOS los scripts/applicaciones web utilizados en tu cuenta para cualquier actualización incluyendo cualquier mod que puedas usar en cualquier aplicación web. Si usted está usando cualquier aplicación web de código abierto, que puede ser el principal sospechoso. Sin embargo, debe comprobar todo y mantenerlos al día. Consulte la base de datos en www.secunia.com para cualquier explotación conocida publicada en público.
2. Una vez que haya verificado que el 100% de los scripts instalados son la última versión estable, tendrá que pasar por todos los archivos de su cuenta y asegurarse de que ninguno fue subido por los hackers antes de que usted auditó o dejó de una antigua instalación de una aplicación. Puede haber archivos sospechosos en carpetas que nunca imaginaría y en carpetas varios niveles abajo. Puede utilizar ftp o cPanel gestor de archivos para revisar todos los archivos bajo public html y compararlos con su copia local. [Siempre debe mantener una copia local para esta comparación así como copia de seguridad.]
3. Asegúrese de que todas las contraseñas son una mezcla de alfa-numeric y no una palabra de diccionario. Sólo porque pensabas que una palabra difícil del diccionario no te hace seguro. Por favor, utilice también mayúsculas y minúsculas y al menos 8 caracteres.
4. El acceso a la base de datos MySQL a todas las aplicaciones web debe estar utilizando usuarios separados de db. No utilice nunca su cuenta principal usuario / pase para él. Su usuario/pass principal nunca debe ser almacenado en ningún archivo en su cuenta.
5. En su panel de control, active la opción de archivo de sus registros web en Raw Log Manager. Esto le dará la oportunidad de comprobar cómo el hacker explotaba uno de los scripts. De lo contrario, todas las troncos crudos se limpian después de generar estadísticas. Si ya has sido hackeado, es demasiado tarde ahora pero puedes archivar los registros para futuros ataques.
6. Si ha personalizado una aplicación web con un mod, asegúrese de que también es la versión más reciente de la versión estable. Muchas aplicaciones web populares pueden ser estables pero uno de los mods addon puede ser explotable y posiblemente no se mantiene más.
7. Si usted ha escrito algún código usted mismo, asegúrese de que todas las variables de entrada están sanitarias (verificados para datos válidos antes de utilizarlo). De lo contrario una sola línea de código malo puede dar acceso a toda su cuenta. El error habitual es incluir un archivo basado en la entrada del usuario. De nuevo, asegúrese de que toda la entrada a un script se comprueba para datos válidos. Todas las explotaciones se basan en datos de entrada. Si su sitio no toma ninguna entrada, usted está 100% seguro de las explotaciones web, es decir, si usted ejecuta el sitio HTML 100% estático sin script en cualquier lugar de su cuenta.
8. Para PHP, cualquier aplicación que utilice register globals para ser activa tiene más posibilidades de ser explotable. Evite tales aplicaciones.
9. Si tiene algún script de correo, asegúrese de que es seguro de la inyección de encabezado. En esencia, asegúrese de que la dirección de correo electrónico, el sujeto y otra parte de los datos que está siendo enviado por el usuario no contenga rupturas de línea. En nuestros foros se presta asistencia para la codificación.
10. Utilizar aplicaciones web gratuitas de código abierto es genial pero tienes que mantenerlo por actualizaciones regulares o puedes perder todos tus datos y sitio si se conoce una nueva explotación al respecto. Y como propietario de una cuenta de hosting, es su responsabilidad que usted ha instalado sólo aplicaciones estables en su cuenta.
11. Si su sitio ha estado funcionando bien durante años, no significa que no haya agujeros de seguridad en él. Significa que la explotación fue desconocida o tuvo suerte de que nadie la explotara antes.
12. Para mayor seguridad, cambie los permisos de sus archivos de configuración (con credenciales de base, etc.) a 660. Puedes hacerlo a través de ftp o gestor de archivos. Esta función puede funcionar en servidores de alojamiento compartidos o si su servidor VPS/dedicado tiene phpsuexec a través de cPanel.
13. Para mayor seguridad, si puede bloquear el acceso a ciertas secciones administrativas de su sitio, haga eso al dar acceso a direcciones IP autorizadas y bloquear el acceso para todos los demás, O la contraseña lo proteja.
14. Si hay alguna instalación de carga de archivos en su cuenta, asegúrese de que sólo los miembros autorizados puedan utilizarla.
También el archivo subido no debe ser accesible directamente a través de URL web (es decir, almacenado fuera de public html)
a) sólo es subido por un administrador del sitio (persona responsable)
b) comprobar y validar para que no se pueda explotar
15. Si hay alguna instalación de dirección URL o de correo web para su membresía del sitio, asegúrese de que no se da a todos sin la autorización adecuada o podría ser utilizado para el spamming.
16. Si sólo estás probando / intentando algo, lo que sólo necesitas y sabes que no vas a mantenerte al día, simplemente cierra detrás de una contraseña de inmediato.
17. Dado que los servidores compartidos/sdx/reseller vienen con suPHP, no necesita ningún archivo o carpeta con permisos de escritura mundial. Los permisos normales de carpeta no deben exceder 755. Los archivos PHP/HTML pueden ser 644 (o más abajo a través de ssh). Los scripts CGI/Perl deben ser 755.
18. Cualquier persona que escriba el código de aplicación web, debe estar familiarizado con la seguridad. Encontré este libro en mi Biblioteca local particularmente en PHP: http://www.oreilly.com/catalog/phpsec/ Lo recomiendo a todos. Cubre todos los aspectos de vulnerabilidades que se encuentran hoy en las aplicaciones web. Encontramos este sitio también del libro: http://phpsec.org
1. Lo primero que necesitas hacer es comprobar todos los sitios de proveedores/desarrolladores para TODOS los scripts/applicaciones web utilizados en tu cuenta para cualquier actualización incluyendo cualquier mod que puedas usar en cualquier aplicación web. Si usted está usando cualquier aplicación web de código abierto, que puede ser el principal sospechoso. Sin embargo, debe comprobar todo y mantenerlos al día. Consulte la base de datos en www.secunia.com para cualquier explotación conocida publicada en público.
2. Una vez que haya verificado que el 100% de los scripts instalados son la última versión estable, tendrá que pasar por todos los archivos de su cuenta y asegurarse de que ninguno fue subido por los hackers antes de que usted auditó o dejó de una antigua instalación de una aplicación. Puede haber archivos sospechosos en carpetas que nunca imaginaría y en carpetas varios niveles abajo. Puede utilizar ftp o cPanel gestor de archivos para revisar todos los archivos bajo public html y compararlos con su copia local. [Siempre debe mantener una copia local para esta comparación así como copia de seguridad.]
3. Asegúrese de que todas las contraseñas son una mezcla de alfa-numeric y no una palabra de diccionario. Sólo porque pensabas que una palabra difícil del diccionario no te hace seguro. Por favor, utilice también mayúsculas y minúsculas y al menos 8 caracteres.
4. El acceso a la base de datos MySQL a todas las aplicaciones web debe estar utilizando usuarios separados de db. No utilice nunca su cuenta principal usuario / pase para él. Su usuario/pass principal nunca debe ser almacenado en ningún archivo en su cuenta.
5. En su panel de control, active la opción de archivo de sus registros web en Raw Log Manager. Esto le dará la oportunidad de comprobar cómo el hacker explotaba uno de los scripts. De lo contrario, todas las troncos crudos se limpian después de generar estadísticas. Si ya has sido hackeado, es demasiado tarde ahora pero puedes archivar los registros para futuros ataques.
6. Si ha personalizado una aplicación web con un mod, asegúrese de que también es la versión más reciente de la versión estable. Muchas aplicaciones web populares pueden ser estables pero uno de los mods addon puede ser explotable y posiblemente no se mantiene más.
7. Si usted ha escrito algún código usted mismo, asegúrese de que todas las variables de entrada están sanitarias (verificados para datos válidos antes de utilizarlo). De lo contrario una sola línea de código malo puede dar acceso a toda su cuenta. El error habitual es incluir un archivo basado en la entrada del usuario. De nuevo, asegúrese de que toda la entrada a un script se comprueba para datos válidos. Todas las explotaciones se basan en datos de entrada. Si su sitio no toma ninguna entrada, usted está 100% seguro de las explotaciones web, es decir, si usted ejecuta el sitio HTML 100% estático sin script en cualquier lugar de su cuenta.
8. Para PHP, cualquier aplicación que utilice register globals para ser activa tiene más posibilidades de ser explotable. Evite tales aplicaciones.
9. Si tiene algún script de correo, asegúrese de que es seguro de la inyección de encabezado. En esencia, asegúrese de que la dirección de correo electrónico, el sujeto y otra parte de los datos que está siendo enviado por el usuario no contenga rupturas de línea. En nuestros foros se presta asistencia para la codificación.
10. Utilizar aplicaciones web gratuitas de código abierto es genial pero tienes que mantenerlo por actualizaciones regulares o puedes perder todos tus datos y sitio si se conoce una nueva explotación al respecto. Y como propietario de una cuenta de hosting, es su responsabilidad que usted ha instalado sólo aplicaciones estables en su cuenta.
11. Si su sitio ha estado funcionando bien durante años, no significa que no haya agujeros de seguridad en él. Significa que la explotación fue desconocida o tuvo suerte de que nadie la explotara antes.
12. Para mayor seguridad, cambie los permisos de sus archivos de configuración (con credenciales de base, etc.) a 660. Puedes hacerlo a través de ftp o gestor de archivos. Esta función puede funcionar en servidores de alojamiento compartidos o si su servidor VPS/dedicado tiene phpsuexec a través de cPanel.
13. Para mayor seguridad, si puede bloquear el acceso a ciertas secciones administrativas de su sitio, haga eso al dar acceso a direcciones IP autorizadas y bloquear el acceso para todos los demás, O la contraseña lo proteja.
14. Si hay alguna instalación de carga de archivos en su cuenta, asegúrese de que sólo los miembros autorizados puedan utilizarla.
También el archivo subido no debe ser accesible directamente a través de URL web (es decir, almacenado fuera de public html)
a) sólo es subido por un administrador del sitio (persona responsable)
b) comprobar y validar para que no se pueda explotar
15. Si hay alguna instalación de dirección URL o de correo web para su membresía del sitio, asegúrese de que no se da a todos sin la autorización adecuada o podría ser utilizado para el spamming.
16. Si sólo estás probando / intentando algo, lo que sólo necesitas y sabes que no vas a mantenerte al día, simplemente cierra detrás de una contraseña de inmediato.
17. Dado que los servidores compartidos/sdx/reseller vienen con suPHP, no necesita ningún archivo o carpeta con permisos de escritura mundial. Los permisos normales de carpeta no deben exceder 755. Los archivos PHP/HTML pueden ser 644 (o más abajo a través de ssh). Los scripts CGI/Perl deben ser 755.
18. Cualquier persona que escriba el código de aplicación web, debe estar familiarizado con la seguridad. Encontré este libro en mi Biblioteca local particularmente en PHP: http://www.oreilly.com/catalog/phpsec/ Lo recomiendo a todos. Cubre todos los aspectos de vulnerabilidades que se encuentran hoy en las aplicaciones web. Encontramos este sitio también del libro: http://phpsec.org
Díganos qué tiene que estar levantado.
A short conversation with an engineer. No quote-bot, no callback queue. We'll tell you honestly if we're not the right fit.