SAVOIR-GÉOGRAPHIE · HÔTELAGE WEB
Mon site a été piraté, que faire ?
Dernière mise à jour 2020-04-02
Voici quelques conseils pour garder votre site sécurisé. Ceci a été principalement écrit en réponse à un site hacké:
1. La première chose que vous devez faire est de vérifier tous les sites de fournisseurs/développeurs pour TOUS les scripts/applications Web utilisés dans votre compte pour toute mise à jour, y compris tout mod que vous pouvez utiliser dans n'importe quelle application Web. Si vous utilisez une application web open source, cela peut être le principal suspect. Cependant, vous devez vérifier tous et les tenir à jour. Consultez la base de données sur www.secunia.com pour connaître les exploits connus publiés en public.
2. Une fois que vous avez vérifié que 100% des scripts installés sont la dernière version stable, vous devrez passer par tous les fichiers de votre compte et assurez-vous qu'aucun n'a été téléchargé par les pirates avant que vous avez vérifié ou laissé par vous à partir d'une ancienne installation d'une application. Il peut y avoir des fichiers suspects dans les dossiers que vous n'imagineriez jamais et dans les dossiers plusieurs niveaux vers le bas. Vous pouvez utiliser ftp ou cPanel file manager pour passer en revue tous les fichiers sous public html et les comparer avec votre copie locale. [Vous devriez toujours conserver une copie locale pour cette comparaison ainsi que la sauvegarde.]
3. Assurez-vous que tous les mots de passe sont un mélange de numérique alpha et non un mot de dictionnaire. Juste parce que vous avez pensé à un mot difficile du dictionnaire ne vous rend pas en sécurité. Veuillez également utiliser les majuscules et les minuscules et au moins 8 caractères.
4. L'accès à la base de données MySQL à toutes les applications Web devrait être effectué par des utilisateurs db distincts. N'utilisez jamais votre compte principal utilisateur/pass pour cela. Votre utilisateur/pass principal ne devrait jamais être stocké dans aucun fichier de votre compte.
5. Dans votre panneau de contrôle, activez l'option d'archive de vos journaux web dans Raw Log Manager. Cela vous donnera l'occasion de vérifier comment le hacker a exploité un des scripts. Sinon, toutes les grumes brutes sont effacées après avoir généré des statistiques. Si vous avez déjà été piraté, c'est trop tard maintenant mais vous pouvez archiver les journaux pour les futures attaques.
6. Si vous avez personnalisé une application web avec un mod, assurez-vous qu'il est également la dernière version stable. Beaucoup d'applications web populaires peuvent être stables, mais l'un des modules supplémentaires peut être exploitable et peut-être pas maintenu plus.
7. Si vous avez écrit vous-même un code, assurez-vous que toutes les variables d'entrée sont désinfectées (vérifiées pour des données valides avant de les utiliser). Sinon, une seule ligne de mauvais code peut donner accès à votre compte entier. La blunder habituelle est d'inclure un fichier basé sur l'entrée de l'utilisateur. Encore une fois, assurez-vous que toutes les entrées dans un script sont vérifiées pour des données valides. Tous les exploits sont basés sur des données d'entrée. Si votre site ne prend aucune entrée, vous êtes 100% sûr des exploits web, c'est-à-dire si vous exécutez 100% site HTML statique sans aucun script dans votre compte.
8. Pour PHP, toute application qui utilise register globals pour être active a plus de chances d'être exploitable. Évitez de telles applications.
9. Si vous avez un script de courrier, assurez-vous qu'il est sûr de l'injection d'en-tête. En substance, assurez-vous que l'adresse e-mail, le sujet et d'autres parties des données qui sont soumises par l'utilisateur ne contiennent pas de ruptures de ligne. Une aide au codage est fournie sur nos forums.
10. L'utilisation d'applications web libres est excellente mais vous devez le maintenir par des mises à jour régulières ou vous pouvez perdre toutes vos données et votre site si un nouvel exploit est connu à ce sujet. Et en tant que propriétaire de compte d'hébergement, il est de votre responsabilité que vous n'avez installé que des applications stables dans votre compte.
11. Si votre site fonctionne bien depuis des années, cela ne signifie pas qu'il n'y a pas de trous de sécurité. En fait, ça veut dire que l'exploitation était inconnue ou que vous avez eu de la chance que personne ne l'ait exploitée avant.
12. Pour une sécurité accrue, changez les permissions de vos fichiers de configuration (ayant des identifiants de base de données, etc.) à 660. Vous pouvez le faire via ftp ou gestionnaire de fichiers. Cette fonctionnalité peut fonctionner sur des serveurs d'hébergement partagés ou si votre serveur dédié VPS a phpsuexec via cPanel.
13. Pour une sécurité supplémentaire, si vous pouvez bloquer l'accès à certaines sections administratives de votre site, faites cela en donnant accès uniquement aux adresses IP autorisées et en bloquant l'accès pour tous les autres, Ou le mot de passe le protéger.
14. S'il y a une installation de téléchargement de fichiers dans votre compte, assurez-vous que seuls les membres autorisés peuvent l'utiliser.
Le fichier téléchargé ne devrait pas être accessible directement via l'URL du Web (c.-à-d. stocké en dehors de public html) sauf si
a) elle est uniquement téléchargée par un administrateur du site (personne responsable)
b) vérifié et validé pour ne pas être exploitable
15. S'il existe une possibilité de transfert d'URL ou de messagerie Web pour votre adhésion au site, assurez-vous qu'elle n'est pas donnée à tous sans autorisation appropriée ou qu'elle pourrait être utilisée pour le spam.
16. Si vous testez / essayez quelque chose, que vous seul avez besoin et que vous savez que vous ne vous tenirz pas à jour, fermez-le immédiatement derrière un mot de passe.
17. Puisque les serveurs partagés/sdx/reseller sont livrés avec suPHP, vous n'avez pas besoin de fichier ou de dossier avec des permissions d'écriture du monde entier. Les permissions normales de dossier ne doivent pas dépasser 755. Les fichiers PHP/HTML peuvent être 644 (ou inférieur à ssh). Les scripts CGI/Perl devraient être 755.
18. Quiconque écrit un code d'application Web doit être au courant de la sécurité. J'ai trouvé ce livre dans ma bibliothèque locale, en particulier sur PHP : http://www.oreilly.com/catalog/phpsec/ Je le recommande à tous. Il couvre tous les aspects des vulnérabilités trouvées aujourd'hui dans les applications web. Ce site a aussi été trouvé dans le livre: http://phpsec.org
1. La première chose que vous devez faire est de vérifier tous les sites de fournisseurs/développeurs pour TOUS les scripts/applications Web utilisés dans votre compte pour toute mise à jour, y compris tout mod que vous pouvez utiliser dans n'importe quelle application Web. Si vous utilisez une application web open source, cela peut être le principal suspect. Cependant, vous devez vérifier tous et les tenir à jour. Consultez la base de données sur www.secunia.com pour connaître les exploits connus publiés en public.
2. Une fois que vous avez vérifié que 100% des scripts installés sont la dernière version stable, vous devrez passer par tous les fichiers de votre compte et assurez-vous qu'aucun n'a été téléchargé par les pirates avant que vous avez vérifié ou laissé par vous à partir d'une ancienne installation d'une application. Il peut y avoir des fichiers suspects dans les dossiers que vous n'imagineriez jamais et dans les dossiers plusieurs niveaux vers le bas. Vous pouvez utiliser ftp ou cPanel file manager pour passer en revue tous les fichiers sous public html et les comparer avec votre copie locale. [Vous devriez toujours conserver une copie locale pour cette comparaison ainsi que la sauvegarde.]
3. Assurez-vous que tous les mots de passe sont un mélange de numérique alpha et non un mot de dictionnaire. Juste parce que vous avez pensé à un mot difficile du dictionnaire ne vous rend pas en sécurité. Veuillez également utiliser les majuscules et les minuscules et au moins 8 caractères.
4. L'accès à la base de données MySQL à toutes les applications Web devrait être effectué par des utilisateurs db distincts. N'utilisez jamais votre compte principal utilisateur/pass pour cela. Votre utilisateur/pass principal ne devrait jamais être stocké dans aucun fichier de votre compte.
5. Dans votre panneau de contrôle, activez l'option d'archive de vos journaux web dans Raw Log Manager. Cela vous donnera l'occasion de vérifier comment le hacker a exploité un des scripts. Sinon, toutes les grumes brutes sont effacées après avoir généré des statistiques. Si vous avez déjà été piraté, c'est trop tard maintenant mais vous pouvez archiver les journaux pour les futures attaques.
6. Si vous avez personnalisé une application web avec un mod, assurez-vous qu'il est également la dernière version stable. Beaucoup d'applications web populaires peuvent être stables, mais l'un des modules supplémentaires peut être exploitable et peut-être pas maintenu plus.
7. Si vous avez écrit vous-même un code, assurez-vous que toutes les variables d'entrée sont désinfectées (vérifiées pour des données valides avant de les utiliser). Sinon, une seule ligne de mauvais code peut donner accès à votre compte entier. La blunder habituelle est d'inclure un fichier basé sur l'entrée de l'utilisateur. Encore une fois, assurez-vous que toutes les entrées dans un script sont vérifiées pour des données valides. Tous les exploits sont basés sur des données d'entrée. Si votre site ne prend aucune entrée, vous êtes 100% sûr des exploits web, c'est-à-dire si vous exécutez 100% site HTML statique sans aucun script dans votre compte.
8. Pour PHP, toute application qui utilise register globals pour être active a plus de chances d'être exploitable. Évitez de telles applications.
9. Si vous avez un script de courrier, assurez-vous qu'il est sûr de l'injection d'en-tête. En substance, assurez-vous que l'adresse e-mail, le sujet et d'autres parties des données qui sont soumises par l'utilisateur ne contiennent pas de ruptures de ligne. Une aide au codage est fournie sur nos forums.
10. L'utilisation d'applications web libres est excellente mais vous devez le maintenir par des mises à jour régulières ou vous pouvez perdre toutes vos données et votre site si un nouvel exploit est connu à ce sujet. Et en tant que propriétaire de compte d'hébergement, il est de votre responsabilité que vous n'avez installé que des applications stables dans votre compte.
11. Si votre site fonctionne bien depuis des années, cela ne signifie pas qu'il n'y a pas de trous de sécurité. En fait, ça veut dire que l'exploitation était inconnue ou que vous avez eu de la chance que personne ne l'ait exploitée avant.
12. Pour une sécurité accrue, changez les permissions de vos fichiers de configuration (ayant des identifiants de base de données, etc.) à 660. Vous pouvez le faire via ftp ou gestionnaire de fichiers. Cette fonctionnalité peut fonctionner sur des serveurs d'hébergement partagés ou si votre serveur dédié VPS a phpsuexec via cPanel.
13. Pour une sécurité supplémentaire, si vous pouvez bloquer l'accès à certaines sections administratives de votre site, faites cela en donnant accès uniquement aux adresses IP autorisées et en bloquant l'accès pour tous les autres, Ou le mot de passe le protéger.
14. S'il y a une installation de téléchargement de fichiers dans votre compte, assurez-vous que seuls les membres autorisés peuvent l'utiliser.
Le fichier téléchargé ne devrait pas être accessible directement via l'URL du Web (c.-à-d. stocké en dehors de public html) sauf si
a) elle est uniquement téléchargée par un administrateur du site (personne responsable)
b) vérifié et validé pour ne pas être exploitable
15. S'il existe une possibilité de transfert d'URL ou de messagerie Web pour votre adhésion au site, assurez-vous qu'elle n'est pas donnée à tous sans autorisation appropriée ou qu'elle pourrait être utilisée pour le spam.
16. Si vous testez / essayez quelque chose, que vous seul avez besoin et que vous savez que vous ne vous tenirz pas à jour, fermez-le immédiatement derrière un mot de passe.
17. Puisque les serveurs partagés/sdx/reseller sont livrés avec suPHP, vous n'avez pas besoin de fichier ou de dossier avec des permissions d'écriture du monde entier. Les permissions normales de dossier ne doivent pas dépasser 755. Les fichiers PHP/HTML peuvent être 644 (ou inférieur à ssh). Les scripts CGI/Perl devraient être 755.
18. Quiconque écrit un code d'application Web doit être au courant de la sécurité. J'ai trouvé ce livre dans ma bibliothèque locale, en particulier sur PHP : http://www.oreilly.com/catalog/phpsec/ Je le recommande à tous. Il couvre tous les aspects des vulnérabilités trouvées aujourd'hui dans les applications web. Ce site a aussi été trouvé dans le livre: http://phpsec.org
Dites-nous ce qui doit rester debout.
A short conversation with an engineer. No quote-bot, no callback queue. We'll tell you honestly if we're not the right fit.