Extensions, conseils pour protection anti hack ?

[Mister Paul]

Bonjour,


j’ai un site en cours de développement qui s’est fait hacker…
:-(

Je vais :
- changer les login/password FTP
- remplacer le site en ligne par une ancienne sécu locale
- changer les login/password database
- effacer et remplacer la base de données en ligne par une sécu clean

J’aimerais vos conseils sur les extensions que vous utilisez pour protéger vos sites…


Merci !
Paul

[GraphiqueDesign]

L'accès à l'administration, était il suffisant ? Gros mot de passe ? .htaccess dans administrator ? Il serait quand même intéressant de comprendre comment le site s'est fait hacker !

[Mister Paul]

.htaccess dans administrator ? Il serait quand même intéressant de comprendre comment le site s'est fait hacker !

Je n'ai pas d'.htaccess dans l'administrator...
Qu'inscrit-on dans le fichier ?

Oui je cherche aussi à comprendre par où ils sont passés, mais je bloque pour l'instant...

[SimonG]

Bonjour,

en plus d'identifiants et mot de pass solides, il est aussi possible d'installer aeSecure qui est gratuit dans ses fonctionnalités de sécurisation :

https://www.aesecure.com

[Mister Paul]

Merci pour le conseil de aesecure.
OK pour le .htaccess
Par contre je ne suis pas sûr que sur un mutualisé OVH le php.ini créé par aesecure soit pris en charge...

[RobertG]

Pas de problème en mutualisé chez OVH avec aeSecure.
Si le php.ini est ignoré, ce qui est possible, il reste la protection par les .htaccess

[Mister Paul]

S'il n'y a que le .htaccess, la protection est moindre j'imagine...
Et du coup il ne faudrait pas que ça soit redondant avec d'autres extensions que je prendrai pour compléter et qui peut-être gèrent aussi le .htaccess... (je crains des conflits possibles)

[RobertG]

Le contenu du php.ini ne te protègera pas plus que le .htaccess, à mon avis (mais Christophe nous en dira plus s'il passe par ici).
Exemple sur un de mes sites perso :

display_errors=off
error_reporting=0
zlib.output_compression=off
zlib.output_compression_level=0

Je ne vois personnellement pas l'intérêt de multiplier les systèmes de protection lorsque j'utilise aeSecure, en dehors d'un bon captcha pour protéger les formulaires.

[cavo789]

Bonsoir

Le fichier php.ini qui est généré (ou complété) par aeSecure reprends des instructions qui sont, également, mises dans le .htaccess comme la désactivation du rapport des erreurs ou l'activation de la compression logicielle. À ce titre, le fichier php.ini d'aeSecure est ... inutile mais, à l'époque, j'avais opté pour "Prévoyons le coup et peut-être tel ou tel hébergeur "exotique" ne gérérait pas l'instruction .htaccess aussi j'assure et je mets aussi dans php.ini".

En réalité, il s'avère que je ne connais aucun hébergeur qui ne gère pas les options du fichier .htaccess telles que mentionnées (gestionnaire des erreurs, compression, ...) et donc, si elles sont dans .htaccess, il n'est pas utile d'aussi les mettre dans php.ini.

En clair : les lignes ajoutées par aeSecure dans le fichier php.ini sont en doublons par rapport .htaccess.

Bonne soirée

[Mister Paul]

Désolé de ma réponse tardive mais j'ai des petits soucis ces derniers jours...
____________________


Merci à vous pour vos recommandations.Et Merci à Christophe d'avoir pris le temps de se pencher sur mon petit souci.

Donc si je résume :
- aesecure
- capcha sur formulaires
- mot de passe admin costauds


et j'ajouterais peut-être (avec votre consentement ?) :
- Brute Force Stop pour border les admins qui ne respecteraient pas la consigne des mots de passe costauds...


Avec ça pas de souci ? Paul

[chabi01]

Bonjour,
Personne ne pourra répondre "pas de souci" ! Respecter les règles comme celles-ci s'accompagnent également de diverses choses :
- sauvegarder son site périodiquement (de manière optimale tous les jours) et garder les backups de manière déportée (pas sur le même serveur que le site) en les testant également de temps en temps pour vérifier qu'elles fonctionnent,
- procéder aux mises à jour de son site
- vérifier que personne n'intègre du code "exotique" au site dans les pages sauf si le code est "garanti",
etc...

Ce ne sont que les bases et même avec cela, il peut toujours y avoir un "souci" un jour

Cordialement,