Base de connaissances · Hébergement web
Mon site web a été piraté, que faire ?
Dernière mise à jour : 2020-04-02
Here are some tips to keep your site secure. This was primarily written in response to a hacked site:
1. First thing you need to do is check all vendor/developer sites for ALL web scripts/applications used in your account for any updates including any mod you may be using in any web application. If you are using any open source web application, that may be the prime suspect. However, you must check all and keep them up to date. Check the database on www.secunia.com for any known exploits released in public.
2. Once you have verified that 100% of the installed scripts are the latest stable version, you will need to go through all files of your account and make sure none were uploaded by hackers before you audited or left by you from an old install of an application. There may be suspicious files in folders you would never imagine and in folders several levels down. You can use ftp or cPanel file manager to go through all files under public_html and compare them with your local copy. [You should always maintain a local copy for this comparison as well as backup.]
3. Make sure all passwords are a mix of alpha-numeric and not a dictionary word. Just because you thought of a difficult word from the dictionary does not make you safe. Please also use both capitals and lowercase and at least 8 characters.
4. The MySQL database access to all web applications should be using separate db users. Do not ever use your main account user/pass for it. Your main user/pass should never be stored in any file in your account.
5. In your control panel, activate archive option of your web logs in Raw Log Manager. This will give you the opportunity to check how the hacker exploited one of the scripts. Otherwise all raw logs are cleared after generating stats. If you have already been hacked, its too late now but you can archive the logs for future attacks.
6. If you have customized a web application with a mod, make sure it is also the latest stable version. Many popular web application may be stable but one of the addon mods may be exploitable and possibly not maintained any more.
7. Si vous avez écrit du code vous-même, veillez à ce que toutes les variables d'entrée soient assainies (c'est-à-dire vérifiées afin de s'assurer qu'elles contiennent des données valides avant leur utilisation). Dans le cas contraire, une seule ligne de code défectueuse peut donner accès à l'ensemble de votre compte. L'erreur la plus courante consiste à inclure un fichier en fonction de données saisies par l'utilisateur. Encore une fois, assurez-vous que toutes les données transmises à un script sont vérifiées. Toutes les failles exploitées reposent sur des données d'entrée. Si votre site ne reçoit aucune donnée, vous êtes protégé à 100% contre les attaques web, c'est-à-dire si vous exploitez un site en HTML statique à 100%, sans aucun script, où que ce soit dans votre compte.
8. For PHP, any application that uses register_globals to be active has more chances of being exploitable. Avoid such applications.
9. If you have some mail script, make sure it is safe from header injection. In essence make sure that email address, subject and other part of data that is being submitted by user does not contain line breaks. Some coding assistance is provided on our forums.
10. Using open source free web applications is great but you have to maintain it by regular updates or you can loose all your data and site if a new exploit is known about it. And as a hosting account owner, it is your responsibility that you have installed only stable applications in your account.
11. If your site has been running fine for years, it does not mean there were no security holes in it. It actually means that exploit was unknown or you were lucky that no one exploited it before.
12. Pour renforcer la sécurité, modifiez les permissions de vos fichiers de configuration (contenant les identifiants de base de données, etc.) en 660. Vous pouvez le faire via FTP ou le gestionnaire de fichiers. Cette fonctionnalité peut fonctionner sur les serveurs d'hébergement mutualisé, ou si votre VPS/serveur dédié dispose de phpsuexec via cPanel.
13. Pour renforcer la sécurité, si vous pouvez bloquer l'accès à certaines sections d'administration de votre site, faites-le en n'autorisant que les adresses IP autorisées et en bloquant l'accès à tous les autres, ou protégez-les par un mot de passe.
14. Si votre compte propose une fonction de téléversement de fichiers, veillez à ce que seuls les membres autorisés puissent l'utiliser.
Par ailleurs, le fichier téléversé ne doit pas être directement accessible via une URL web (c'est-à-dire qu'il doit être stocké en dehors de public_html), sauf si
a) il est téléversé uniquement par un administrateur du site (personne responsable)
b) il a été vérifié et validé comme n'étant pas exploitable
15. Si votre site propose une redirection d'URL ou un service de messagerie Webmail à ses membres, veillez à ne pas l'ouvrir à tous sans autorisation appropriée, faute de quoi il pourrait être utilisé pour envoyer du spam.
16. Si vous effectuez simplement un test ou un essai, dont vous seul avez besoin et que vous ne maintiendrez pas activement à jour, protégez-le immédiatement par un mot de passe.
17. Les serveurs mutualisés, sdx et revendeurs étant fournis avec suPHP, vous n'avez besoin d'aucun fichier ni dossier avec des permissions d'écriture pour tous. Les permissions normales des dossiers ne doivent pas dépasser 755. Les fichiers PHP/HTML peuvent être en 644 (ou plus restrictives via ssh). Les scripts CGI/Perl doivent être en 755.
18. Toute personne qui écrit du code d'application web doit connaître les principes de sécurité. J'ai trouvé ce livre dans ma bibliothèque locale, consacré en particulier à PHP : http://www.oreilly.com/catalog/phpsec/ Je le recommande à tous. Il couvre tous les aspects des vulnérabilités que l'on rencontre aujourd'hui dans les applications web. J'ai également découvert ce site grâce au livre : http://phpsec.org
1. First thing you need to do is check all vendor/developer sites for ALL web scripts/applications used in your account for any updates including any mod you may be using in any web application. If you are using any open source web application, that may be the prime suspect. However, you must check all and keep them up to date. Check the database on www.secunia.com for any known exploits released in public.
2. Once you have verified that 100% of the installed scripts are the latest stable version, you will need to go through all files of your account and make sure none were uploaded by hackers before you audited or left by you from an old install of an application. There may be suspicious files in folders you would never imagine and in folders several levels down. You can use ftp or cPanel file manager to go through all files under public_html and compare them with your local copy. [You should always maintain a local copy for this comparison as well as backup.]
3. Make sure all passwords are a mix of alpha-numeric and not a dictionary word. Just because you thought of a difficult word from the dictionary does not make you safe. Please also use both capitals and lowercase and at least 8 characters.
4. The MySQL database access to all web applications should be using separate db users. Do not ever use your main account user/pass for it. Your main user/pass should never be stored in any file in your account.
5. In your control panel, activate archive option of your web logs in Raw Log Manager. This will give you the opportunity to check how the hacker exploited one of the scripts. Otherwise all raw logs are cleared after generating stats. If you have already been hacked, its too late now but you can archive the logs for future attacks.
6. If you have customized a web application with a mod, make sure it is also the latest stable version. Many popular web application may be stable but one of the addon mods may be exploitable and possibly not maintained any more.
7. Si vous avez écrit du code vous-même, veillez à ce que toutes les variables d'entrée soient assainies (c'est-à-dire vérifiées afin de s'assurer qu'elles contiennent des données valides avant leur utilisation). Dans le cas contraire, une seule ligne de code défectueuse peut donner accès à l'ensemble de votre compte. L'erreur la plus courante consiste à inclure un fichier en fonction de données saisies par l'utilisateur. Encore une fois, assurez-vous que toutes les données transmises à un script sont vérifiées. Toutes les failles exploitées reposent sur des données d'entrée. Si votre site ne reçoit aucune donnée, vous êtes protégé à 100% contre les attaques web, c'est-à-dire si vous exploitez un site en HTML statique à 100%, sans aucun script, où que ce soit dans votre compte.
8. For PHP, any application that uses register_globals to be active has more chances of being exploitable. Avoid such applications.
9. If you have some mail script, make sure it is safe from header injection. In essence make sure that email address, subject and other part of data that is being submitted by user does not contain line breaks. Some coding assistance is provided on our forums.
10. Using open source free web applications is great but you have to maintain it by regular updates or you can loose all your data and site if a new exploit is known about it. And as a hosting account owner, it is your responsibility that you have installed only stable applications in your account.
11. If your site has been running fine for years, it does not mean there were no security holes in it. It actually means that exploit was unknown or you were lucky that no one exploited it before.
12. Pour renforcer la sécurité, modifiez les permissions de vos fichiers de configuration (contenant les identifiants de base de données, etc.) en 660. Vous pouvez le faire via FTP ou le gestionnaire de fichiers. Cette fonctionnalité peut fonctionner sur les serveurs d'hébergement mutualisé, ou si votre VPS/serveur dédié dispose de phpsuexec via cPanel.
13. Pour renforcer la sécurité, si vous pouvez bloquer l'accès à certaines sections d'administration de votre site, faites-le en n'autorisant que les adresses IP autorisées et en bloquant l'accès à tous les autres, ou protégez-les par un mot de passe.
14. Si votre compte propose une fonction de téléversement de fichiers, veillez à ce que seuls les membres autorisés puissent l'utiliser.
Par ailleurs, le fichier téléversé ne doit pas être directement accessible via une URL web (c'est-à-dire qu'il doit être stocké en dehors de public_html), sauf si
a) il est téléversé uniquement par un administrateur du site (personne responsable)
b) il a été vérifié et validé comme n'étant pas exploitable
15. Si votre site propose une redirection d'URL ou un service de messagerie Webmail à ses membres, veillez à ne pas l'ouvrir à tous sans autorisation appropriée, faute de quoi il pourrait être utilisé pour envoyer du spam.
16. Si vous effectuez simplement un test ou un essai, dont vous seul avez besoin et que vous ne maintiendrez pas activement à jour, protégez-le immédiatement par un mot de passe.
17. Les serveurs mutualisés, sdx et revendeurs étant fournis avec suPHP, vous n'avez besoin d'aucun fichier ni dossier avec des permissions d'écriture pour tous. Les permissions normales des dossiers ne doivent pas dépasser 755. Les fichiers PHP/HTML peuvent être en 644 (ou plus restrictives via ssh). Les scripts CGI/Perl doivent être en 755.
18. Toute personne qui écrit du code d'application web doit connaître les principes de sécurité. J'ai trouvé ce livre dans ma bibliothèque locale, consacré en particulier à PHP : http://www.oreilly.com/catalog/phpsec/ Je le recommande à tous. Il couvre tous les aspects des vulnérabilités que l'on rencontre aujourd'hui dans les applications web. J'ai également découvert ce site grâce au livre : http://phpsec.org
Tell us what you need
Compare available plans or describe your workload so we can discuss a suitable starting point.