Base de conocimientos · Alojamiento web
Mi sitio web ha sido hackeado, ¿qué debo hacer?
Última actualización: 2020-04-02
A continuación le ofrecemos algunos consejos para mantener su sitio seguro. Esto se redactó principalmente como respuesta a un sitio hackeado:
1. Lo primero que debe hacer es revisar los sitios de todos los proveedores y desarrolladores de TODOS los scripts y aplicaciones web utilizados en su cuenta para comprobar si hay actualizaciones, incluidos los módulos adicionales que utilice en cualquier aplicación web. Si utiliza alguna aplicación web de código abierto, puede ser la principal sospechosa. Sin embargo, debe revisarlas todas y mantenerlas actualizadas. Consulte la base de datos de www.secunia.com para ver si existen vulnerabilidades conocidas publicadas.
2. Una vez que haya verificado que el 100% de los scripts instalados son la última versión estable, deberá revisar todos los archivos de su cuenta y asegurarse de que ninguno haya sido subido por hackers antes de su auditoría ni haya quedado de una instalación antigua de alguna aplicación. Puede haber archivos sospechosos en carpetas que nunca imaginaría y en carpetas situadas varios niveles más abajo. Puede usar FTP o el administrador de archivos de cPanel para revisar todos los archivos de public_html y compararlos con su copia local. [Siempre debe mantener una copia local para esta comparación, así como una copia de seguridad.]
3. Asegúrese de que todas las contraseñas combinen letras y números y de que no sean una palabra del diccionario. El hecho de que haya pensado en una palabra difícil del diccionario no lo protege. Utilice también mayúsculas y minúsculas, y al menos 8 caracteres.
4. El acceso a la base de datos MySQL de todas las aplicaciones web debe realizarse con usuarios de base de datos distintos. No utilice nunca el usuario y la contraseña de su cuenta principal para ello. El usuario y la contraseña principales nunca deben almacenarse en ningún archivo de su cuenta.
5. En su panel de control, active la opción de archivar los registros web en Raw Log Manager. Esto le permitirá comprobar cómo el atacante aprovechó una vulnerabilidad de uno de los scripts. De lo contrario, todos los registros sin procesar se eliminan después de generar las estadísticas. Si ya ha sido hackeado, ahora es demasiado tarde, pero puede archivar los registros para futuros ataques.
6. Si ha personalizado una aplicación web con un módulo adicional, asegúrese de que también sea la última versión estable. Muchas aplicaciones web populares pueden ser estables, pero alguno de los módulos adicionales puede ser vulnerable y es posible que ya no reciba mantenimiento.
7. Si ha escrito código por su cuenta, asegúrese de que todas las variables de entrada estén saneadas (es decir, que se compruebe la validez de los datos antes de usarlos). De lo contrario, una sola línea de código defectuoso puede dar acceso a toda su cuenta. El error habitual es incluir un archivo en función de los datos introducidos por el usuario. Insistimos: asegúrese de que todos los datos de entrada de un script se validen. Todas las vulnerabilidades se basan en datos de entrada. Si su sitio no recibe ningún dato de entrada, está 100% a salvo de ataques web, es decir, si ejecuta un sitio HTML 100% estático sin ningún script en ninguna parte de su cuenta.
8. En PHP, cualquier aplicación que requiera tener register_globals activado tiene más probabilidades de ser vulnerable. Evite este tipo de aplicaciones.
9. Si dispone de algún script de correo, asegúrese de que esté protegido contra la inyección de encabezados. En esencia, compruebe que la dirección de correo electrónico, el asunto y el resto de los datos enviados por el usuario no contengan saltos de línea. En nuestros foros encontrará alguna ayuda sobre la programación.
10. Utilizar aplicaciones web gratuitas de código abierto es una gran opción, pero debe mantenerlas con actualizaciones periódicas, o podría perder todos sus datos y su sitio si se descubre una nueva vulnerabilidad. Además, como titular de una cuenta de hosting, es su responsabilidad instalar únicamente aplicaciones estables en su cuenta.
11. Que su sitio haya funcionado correctamente durante años no significa que no tuviera brechas de seguridad. En realidad, significa que la vulnerabilidad era desconocida o que tuvo la suerte de que nadie la aprovechara antes.
12. Para mayor seguridad, cambie los permisos de sus archivos de configuración (los que contienen credenciales de bases de datos, etc.) a 660. Puede hacerlo mediante FTP o con el administrador de archivos. Esta función puede utilizarse en servidores de hosting compartido, o si su servidor VPS/dedicado cuenta con phpsuexec a través de cPanel.
13. Para mayor seguridad, si puede bloquear el acceso a determinadas secciones administrativas de su sitio, hágalo permitiendo el acceso únicamente a las direcciones IP autorizadas y bloqueándolo para todas las demás, o protéjalas con contraseña.
14. Si su cuenta dispone de alguna función de carga de archivos, asegúrese de que solo los miembros autorizados puedan utilizarla.
Además, el archivo cargado no debe ser accesible directamente mediante una URL web (es decir, debe almacenarse fuera de public_html), a menos que
a) lo cargue únicamente un administrador del sitio (la persona responsable)
b) se haya revisado y validado que no es explotable
15. Si su sitio ofrece a sus miembros algún servicio de redirección de URL o de correo web (Webmail), asegúrese de no concederlo a todos sin la debida autorización, ya que podría utilizarse para enviar spam.
16. Si solo está probando o experimentando con algo que únicamente usted necesita y que sabe que no mantendrá actualizado, protéjalo con una contraseña de inmediato.
17. Dado que los servidores shared/sdx/reseller incluyen suPHP, no necesita ningún archivo ni carpeta con permisos de escritura para todos los usuarios. Los permisos normales de las carpetas no deben superar 755. Los archivos PHP/HTML pueden tener permisos 644 (o inferiores mediante ssh). Los scripts CGI/Perl deben tener permisos 755.
18. Toda persona que escriba código de aplicaciones web debe conocer los principios de seguridad. Encontré este libro en mi biblioteca local, específicamente sobre PHP: http://www.oreilly.com/catalog/phpsec/ Lo recomiendo a todos. Abarca todos los aspectos de las vulnerabilidades que se encuentran hoy en día en las aplicaciones web. También encontré este sitio gracias al libro: http://phpsec.org
1. Lo primero que debe hacer es revisar los sitios de todos los proveedores y desarrolladores de TODOS los scripts y aplicaciones web utilizados en su cuenta para comprobar si hay actualizaciones, incluidos los módulos adicionales que utilice en cualquier aplicación web. Si utiliza alguna aplicación web de código abierto, puede ser la principal sospechosa. Sin embargo, debe revisarlas todas y mantenerlas actualizadas. Consulte la base de datos de www.secunia.com para ver si existen vulnerabilidades conocidas publicadas.
2. Una vez que haya verificado que el 100% de los scripts instalados son la última versión estable, deberá revisar todos los archivos de su cuenta y asegurarse de que ninguno haya sido subido por hackers antes de su auditoría ni haya quedado de una instalación antigua de alguna aplicación. Puede haber archivos sospechosos en carpetas que nunca imaginaría y en carpetas situadas varios niveles más abajo. Puede usar FTP o el administrador de archivos de cPanel para revisar todos los archivos de public_html y compararlos con su copia local. [Siempre debe mantener una copia local para esta comparación, así como una copia de seguridad.]
3. Asegúrese de que todas las contraseñas combinen letras y números y de que no sean una palabra del diccionario. El hecho de que haya pensado en una palabra difícil del diccionario no lo protege. Utilice también mayúsculas y minúsculas, y al menos 8 caracteres.
4. El acceso a la base de datos MySQL de todas las aplicaciones web debe realizarse con usuarios de base de datos distintos. No utilice nunca el usuario y la contraseña de su cuenta principal para ello. El usuario y la contraseña principales nunca deben almacenarse en ningún archivo de su cuenta.
5. En su panel de control, active la opción de archivar los registros web en Raw Log Manager. Esto le permitirá comprobar cómo el atacante aprovechó una vulnerabilidad de uno de los scripts. De lo contrario, todos los registros sin procesar se eliminan después de generar las estadísticas. Si ya ha sido hackeado, ahora es demasiado tarde, pero puede archivar los registros para futuros ataques.
6. Si ha personalizado una aplicación web con un módulo adicional, asegúrese de que también sea la última versión estable. Muchas aplicaciones web populares pueden ser estables, pero alguno de los módulos adicionales puede ser vulnerable y es posible que ya no reciba mantenimiento.
7. Si ha escrito código por su cuenta, asegúrese de que todas las variables de entrada estén saneadas (es decir, que se compruebe la validez de los datos antes de usarlos). De lo contrario, una sola línea de código defectuoso puede dar acceso a toda su cuenta. El error habitual es incluir un archivo en función de los datos introducidos por el usuario. Insistimos: asegúrese de que todos los datos de entrada de un script se validen. Todas las vulnerabilidades se basan en datos de entrada. Si su sitio no recibe ningún dato de entrada, está 100% a salvo de ataques web, es decir, si ejecuta un sitio HTML 100% estático sin ningún script en ninguna parte de su cuenta.
8. En PHP, cualquier aplicación que requiera tener register_globals activado tiene más probabilidades de ser vulnerable. Evite este tipo de aplicaciones.
9. Si dispone de algún script de correo, asegúrese de que esté protegido contra la inyección de encabezados. En esencia, compruebe que la dirección de correo electrónico, el asunto y el resto de los datos enviados por el usuario no contengan saltos de línea. En nuestros foros encontrará alguna ayuda sobre la programación.
10. Utilizar aplicaciones web gratuitas de código abierto es una gran opción, pero debe mantenerlas con actualizaciones periódicas, o podría perder todos sus datos y su sitio si se descubre una nueva vulnerabilidad. Además, como titular de una cuenta de hosting, es su responsabilidad instalar únicamente aplicaciones estables en su cuenta.
11. Que su sitio haya funcionado correctamente durante años no significa que no tuviera brechas de seguridad. En realidad, significa que la vulnerabilidad era desconocida o que tuvo la suerte de que nadie la aprovechara antes.
12. Para mayor seguridad, cambie los permisos de sus archivos de configuración (los que contienen credenciales de bases de datos, etc.) a 660. Puede hacerlo mediante FTP o con el administrador de archivos. Esta función puede utilizarse en servidores de hosting compartido, o si su servidor VPS/dedicado cuenta con phpsuexec a través de cPanel.
13. Para mayor seguridad, si puede bloquear el acceso a determinadas secciones administrativas de su sitio, hágalo permitiendo el acceso únicamente a las direcciones IP autorizadas y bloqueándolo para todas las demás, o protéjalas con contraseña.
14. Si su cuenta dispone de alguna función de carga de archivos, asegúrese de que solo los miembros autorizados puedan utilizarla.
Además, el archivo cargado no debe ser accesible directamente mediante una URL web (es decir, debe almacenarse fuera de public_html), a menos que
a) lo cargue únicamente un administrador del sitio (la persona responsable)
b) se haya revisado y validado que no es explotable
15. Si su sitio ofrece a sus miembros algún servicio de redirección de URL o de correo web (Webmail), asegúrese de no concederlo a todos sin la debida autorización, ya que podría utilizarse para enviar spam.
16. Si solo está probando o experimentando con algo que únicamente usted necesita y que sabe que no mantendrá actualizado, protéjalo con una contraseña de inmediato.
17. Dado que los servidores shared/sdx/reseller incluyen suPHP, no necesita ningún archivo ni carpeta con permisos de escritura para todos los usuarios. Los permisos normales de las carpetas no deben superar 755. Los archivos PHP/HTML pueden tener permisos 644 (o inferiores mediante ssh). Los scripts CGI/Perl deben tener permisos 755.
18. Toda persona que escriba código de aplicaciones web debe conocer los principios de seguridad. Encontré este libro en mi biblioteca local, específicamente sobre PHP: http://www.oreilly.com/catalog/phpsec/ Lo recomiendo a todos. Abarca todos los aspectos de las vulnerabilidades que se encuentran hoy en día en las aplicaciones web. También encontré este sitio gracias al libro: http://phpsec.org
Tell us what you need
Compare available plans or describe your workload so we can discuss a suitable starting point.