Sentinelle est-il un plugin fiable?

Réduire
X
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • [FAQ OK] Sentinelle est-il un plugin fiable?

    Bonjour

    Ma question est dans le titre...mais j'appuie mon raisonnement.

    J’avais un htaccess non blindé avec sentinelle, sentinelle faisait son taff mais après de multiples tentatives de hacking j’ai donc opté pour un htaccess plus sécuritaire.

    J’ai gardé sentinelle mais maintenant je doute de son utilisation et me demande si ce plugin est fiable.

    A part me bloquer mon adresse IP lorsque je boss sur le back-end du site et certains robots de référencement est-il utile de garder sentinelle…si oui pour quel type de tentatives de hacking et de failles ?

    J’ai parcouru l’ensemble des posts parlant des différentes solutions de sécurisation de joomla, il faut bien le reconnaître, chacun des auteurs de ses solutions font un boulot extraordinaire, j’en profite pour leurs tirer mon chapeau.

    Personnellement je dirais, que rien ne vaut un bon .htaccess et vous, vous en pensé quoi?

    @+
    Dernière édition par LeMalouin à 22/11/2010, 15h48 Raison: Topic passé en FAQ simplement
    SVP pas de MP pour de l'aide, le forum est l’outil idéal

  • #2
    Envoyé par lionel123 Voir le message
    Bonjour

    Ma question est dans le titre...mais j'appuie mon résonnement.

    J’avais un htaccess non blindé avec sentinelle, sentinelle faisait son taff mais après de multiples tentatives de hacking j’ai donc opté pour un htaccess plus sécuritaire.

    J’ai gardé sentinelle mais maintenant je doute de son utilisation et me demande si ce plugin est fiable.

    A part me bloquer mon adresse IP lorsque je boss sur le back-end du site et certains robots de référencement est-il utile de garder sentinelle…si oui pour quel type de tentatives de hacking et de failles ?

    J’ai parcouru l’ensemble des posts parlant des différentes solutions de sécurisation de joomla, il faut bien le reconnaître, chacun des auteurs de ses solutions font un boulot extraordinaire, j’en profite pour leurs tirer mon chapeau.

    Personnellement je dirais, que rien ne vaut un bon .htaccess et vous, vous en pensé quoi?

    @+
    le titre ne correspond pas à la vrai question qu'il faut se poser !! et avoir un raisonnement une fois certain d'avoir compris l'utilité de chaque mesure sécuritaire et d"être suffisamment compétent pour les mettre en place....

    Le plugin permet de

    -Bloquer une IP fixe ou temporaire
    -Recevoir une alerte sur les blocages en fonction des motifs de détection
    -Bloquer les actions sur des critères établis par les motifs
    -Bloquer l'usage du back-end ou front-end en dessous de superadmin

    -Le plugin permet de desceller une possible faille d'un développement tiers (lié aux motifs de détection), sentinelle bloque toutes actions de tentatives d'attaques XSS .

    -permet de sécuriser $POST et $GET d'un site sans htaccess (pour ceux qui ont oublié le renommage du .htaccess )

    le htaccess ne permettra JAMAIS de savoir par qui ni par quoi les tentatives sont faites.


    note si tu bloque ton IP en back-end c'est que suivant tes droits d'accès avec le compte utilisé tu n'as pas changé la configuration du plugin pour permettre l'édition en Back-end avec celui que t'utilises ...

    Tous comptes administrateur et manager sont bloqué par défaut dans la config du plugin

    Exemple le plus simple qui illustre la différence entre un script et htaccess:

    Le site d'une entreprise a été , hacké , défacé par X

    si je n'utilise que des régles sécuritaires htaccess je ne peux fournir aucune information sur ma plainte contre X puisque htaccess ne permet pas ce genre de contrôle , il bloque point barre !!

    -avec un script comme sentinelle ou autre , je peux fournir la provenance , et le mode opératoire qui pourrait servir aux enquêteurs de la section cybercriminalité , nous appelons cela tracer !

    - le fait de tracer permet d'établir un profil sur la personne , établir le mobile (concurrence déloyale par exemple)

    gérer un site Internet ne demande pas que mettre du contenu ,,, il demande également de prendre les dispositions nécessaires et usage d'outils complémentaires pour évaluer tous les aspects sécuritaires.

    Ce qui doit également permettre de responsabiliser l'hébergement en cas de faille OS serveur suite à des dégâts ou intrusions.

    D'ou l'importance de savoir doser l'usage du htaccess avec les scripts.

    @+
    Dernière édition par opware2000 à 18/11/2010, 08h48
    adaptations|conceptions

    Commentaire


    • #3
      Bonjour

      J'ai bien pris note de tes remarques mais j'ai plusieurs questions.

      -Recevoir une alerte sur les blocages en fonction des motifs de détection
      Il est vrai que cela marche très bien mais les alertes que je recevais avant un ".htaccess sécuritaire" sont depuis égale à zéro.
      Nous avons donc le ".htaccess" qui bloque avant sentinelle...et effectivement nous sommes d'accord sur le point que ".htaccess" ne me donne pas les raisons et la provenance de ces tentatives de hacking…mais…
      Crois tu, que si un site se fait hacker en passant par dessus le ".htaccess sécuritaire" sentinelle va lui prendre le relais?

      -Bloquer les actions sur des critères établis par les motifs
      Oui très bien mais malheureusement nous pouvons constater que trop blinder sentinelle c’est se risquer de bloquer l’accès même des gentils webeurs comme ses clients, les visiteurs de passage et nous-même.
      Il faut dire que pour un site e-commerce par exemple c’est ingérable.
      Les paramètres avancés du plugin comme ci dessous :
      Blocage FE Author
      Blocage FE Editor
      Blocage FE Publisher
      Blocage BE Admin
      Blocage BE Manager

      Sont personnellement désactivés, depuis que j’ai eu des blocages de robots de référencement et des retours par émail de clients étonnés.

      et avoir un raisonnement une fois certain d'avoir compris l'utilité de chaque mesure sécuritaire et d"être suffisamment compétent pour les mettre en place
      Mon raisonnement sur l’utilité de sentinelle est expliqué dans mon 1er post, donc pour toi devons nous en déduire que les personnes se posant les mêmes questions que moi, n’ont pas la compétence suffisante pour en comprendre son fonctionnement ?

      note si tu bloque ton IP en back-end c'est que suivant tes droits d'accès avec le compte utilisé tu n'as pas changé la configuration du plugin pour permettre l'édition en Back-end avec celui que t'utilise ...
      Effectivement, j’avoue, je n’ai jamais ouvert le plugin à la source pour m’attribuer des droits de non blocage…mais question vu que 90% des personnes n’ont pas d’IP fixe, penses tu que cela marche ?

      -permet de sécuriser $POST et $GET d'un site sans htaccess (pour ceux qui ont oublié le renommage du .htaccess )
      Devons nous, en conclure que sentinelle devient inutile après la mise en place d’un .htaccess sécuritaire ?

      Le site d'une entreprise a été , hacké , défacé par X
      si je n'utilise que des régles sécuritaires htaccess je ne peux fournir aucune information sur ma plainte contre X puisque htaccess ne permet pas ce genre de contrôle , il bloque point barre !!
      Ok donc sentinelle est-il un outil permettant d’appuyer une éventuelle plainte après un hacking sévère?
      Si oui il vaut mieux être une multinationale au cas ou le hackeur soit hors France, mais le plus probable hors CE…tu en penses quoi vu que
      -Bloquer une IP fixe ou temporaire
      des IP fixe venant de personne mal intentionnée, je doute que cela soit le cas dans la réalité.

      Ce qui doit également permettre de responsabiliser l'hébergement en cas de faille OS serveur suite à des dégâts ou intrusions.
      Oui mais…un petit tour par les conditions générales de vente de chaque prestataire d’hébergement et vous comprendrez que c’est improbable de responsabiliser l’hébergeur en cas de souci grave.

      Cela dit, je ne permets en aucun cas de critiquer le travail fait par chaque membre de ce forum afin de mieux sécuriser joomla…d’ailleurs je le redis, je vous tire mon chapeau.
      Mais vu que ce plugin (sentinelle) semble être capricieux et que j’ai un .htaccess sécuritaire (voir post de sirius) sentinelle est-il fiable pour bloquer ce que le ".htaccess" ne bloquera pas ?

      Il est évident que chacun défend sa solution et c’est normal !

      Sentinelle plusieurs fois avant la mise en place d’un .htaccess sécuritaire ma épargné une longue et coûteuse gestion en temps d’un après hacking.

      @+
      Dernière édition par LeMalouin à 22/11/2010, 15h49
      SVP pas de MP pour de l'aide, le forum est l’outil idéal

      Commentaire


      • #4
        bonjour ,

        je réponds dans ta quote ça reste plus parlant !!


        Envoyé par lionel123 Voir le message
        Bonjour

        J'ai bien pris note de tes remarques mais j'ai plusieurs questions.


        Il est vrai que cela marche très bien mais les alertes que je recevais avant un ".htaccess sécuritaire" sont depuis égale à zéro.
        Nous avons donc le ".htaccess" qui bloque avant sentinelle...et effectivement nous sommes d'accord sur le point que ".htaccess" ne me donne pas les raisons et la provenance de ces tentatives de hacking…mais…
        Crois tu, que si un site se fait hacker en passant par dessus le ".htaccess sécuritaire" sentinelle va lui prendre le relais?

        >> Normal car si tu instruis les mêmes directives au htaccess que celles contenues par les motifs de détection sentinelle , sentinelle qui est un script ne sera pas pris en charge car toutes directives HTACCESS sont prioritaires lors de l'exécution côté serveur ....

        Oui très bien mais malheureusement nous pouvons constater que trop blinder sentinelle c’est se risquer de bloquer l’accès même des gentils webeurs comme ses clients, les visiteurs de passage et nous-même.
        Il faut dire que pour un site e-commerce par exemple c’est ingérable.
        Les paramètres avancés du plugin comme ci dessous :
        Blocage FE Author
        Blocage FE Editor
        Blocage FE Publisher
        Blocage BE Admin
        Blocage BE Manager

        Sont personnellement désactivés, depuis que j’ai eu des blocages de robots de référencement et des retours par émail de clients étonnés.

        >> ok à chaque site sa mesure et de les appliquer au besoin ...

        Mon raisonnement sur l’utilité de sentinelle est expliqué dans mon 1er post, donc pour toi devenons en déduire que les personnes se posant les mêmes questions que moi, n’ont pas la compétence suffisante pour en comprendre sont fonctionnement ?

        >> tout à fait , une fois que l'on a compris l'importance des 2 mesures , il nous est possible de les utiliser séparément pour un besoin spécifique, à mon sens les 2 doivent se compléter !.

        Effectivement, j’avoue, je n’ai jamais ouvert le plugin à la source pour m’attribuer des droits de non blocage…mais question vu que 90% des personnes n’ont pas d’IP fixe, penses tu que cela marche ?

        >> je n'ai pas bien compris la question , 90% en ip dynamique je ne pense pas , enfin je n'ai pas de stats précise mais sachant que tout ceux qui sont en dégroupé total sont en IP fixe , c'est à voir et confirmer ...

        Devons nous en conclure que sentinelle devient inutile après la mise en place d’un .htaccess sécuritaire ?

        >> oui en ce qui concerne les directives si elles sont identiques aux motifs de détection sentinelle , chose qu'avec le htaccess t'es pas informé en temps réel ...

        Ok donc sentinelle est-il un outil permettant d’appuyer une éventuelle plainte après un hacking sévère?
        Si oui il vaut mieux être une multinationale au cas ou le hackeur soit hors France, mais le plus probable hors CE…tu en penses quoi vu que

        >> à partir du moment ou ton site fait l'objet d'une agression en vue de détruire ton travail , déposer une plainte coule de source ! donc autant que possible avec les éléments nécessaires pour la justifier et qui viendraient en complément de celles que pourrait éventuellement fournir l'hébergeur .... d'ou l'importance de laisser libre l'exécution des script sans les bloquer par htaccess ...

        des IP fixe venant de personne mal intentionnée, je doute que cela soit le cas dans la réalité.

        >> si l'attaquant ne prend pas les bonnes mesures pour se cacher , t'inquiètes qu'il est possible de le remonter !!


        Oui mais…un petit tour par les conditions générales de vente de chaque prestataire d’hébergement et vous comprendrez que c’est improbable de responsabiliser l’hébergeur en cas de souci grave.

        >> si on peut responsabiliser l'hébergement, j'en ai eu la preuve cette semaine , disparition de quelques centaines de pages html sur un hébergement pack Pro et la faute vient du serveur !! dans ce cas je suis désolé l'entreprise peut se retourner contre l'hébergeur pour certains préjudices ...

        Cela dit, je ne permets en aucun cas de critiquer le travail fait par chaque membre de ce forum afin de mieux sécuriser joomla…d’ailleurs je le redis, je vous tire mon chapeau.

        Mais vu que ce plugin (sentinelle) semble être capricieux et que j’ai un .htaccess sécuritaire (voir post de sirius) sentinelle est-il fiable pour bloquer ce que le ".htaccess" ne bloquera pas ?

        >> le script n'a rien de capricieux , il peut ne pas être la solution pour certains sites, c'est un fait ! mais pour d'autre il l'est !Ce que le htaccess ne bloque pas et qui est pris en charge par sentinelle OUI , car il est instruit par un die() qui termine l'action et donc ne renvoie pas la réponse demandé par le client mais celle instruite par un die() ou exit() suivant le cas ...

        Il est évident que chacun défend sa solution et c’est normal !

        >> en ce qui me concerne , je ne défend rien et j'oblige personne, j'utilise parce qu'il m'évite de perdre du temps à chercher les raisons ailleurs et il a été développé pour un Joomla clean . Maintenant si d'autres composant tiers ne facilitent pas sa mise en place , ça reste suivant le besoin de chacun ...

        Sentinelle plusieurs fois avant la mise en place d’un .htaccess sécuritaire ma épargné une longue et coûteuse gestion en temps d’un après hacking.

        >> c'est déjà ça de gagné et c'est bien pour cela qu'il est utile d'autant plus qu'il est extrêmement léger dans son intégration au core JOomla (pas de table en plus) comparé à d'autres scripts donc pas de ralentissement d'exécution côté serveur pour les tâches qui lui incombent ...

        @+
        @+
        Dernière édition par Thorhax à 17/11/2009, 17h18
        adaptations|conceptions

        Commentaire


        • #5
          >> tout à fait , une fois que l'on a compris l'importance des 2 mesures , il nous est possible de les utiliser séparément pour un besoin spécifique, à mon sesn les 2 doivent se compléter !.
          Ben voila et merci!

          Les 2 doivent se compléter! Rien de plus à dire que de me mettre au boulot pour combler mon manque de connaissance sur ce plugin.

          Merci

          @+
          SVP pas de MP pour de l'aide, le forum est l’outil idéal

          Commentaire


          • #6
            Bonjour,
            Moi perso, j'opte pour tout ce qui peut m'alerter. C'est quand même bien du temps de gagné.
            Par contre j'ai une question: comment peut-on faire la différence entre IP statique et IP dynamique? Si je vois bien l'intérêt de bloquer les IP statiques, j'aimerais être sûre de les identifier comme telles. Merci de votre aide
            Dernière édition par crapouille63 à 05/11/2010, 13h05 Raison: fôteu

            Commentaire


            • #7
              Envoyé par anonyme
              1-plugin seul
              - La première tentative (technique 1) est bloquée par le plugin, l'ip est loggée
              - La seconde tentative (technique 2) est bloquée par le filtrage par ip
              ==> Site protégé
              -anonyme
              Mais pour ça il faut bloquer manuellement les IP malveillants puisque le blocage automatique est déconseillé.
              Normalement sur mon site j'ai un htaccess blindé + sentinelle. Pendant un moment j'avais remis le htaccess d'origine en laissant uniquement sentinelle comme sécurité. Du coup je recevais une dizaine de mails d'avertissement par jour. C'est impossible de les référencer manuellement, ça prendrait beaucoup trop de temps.
              Dernière édition par Rocky Rider à 18/11/2010, 08h32

              Commentaire


              • #8
                Plug-in pas utile et vrais hacker-> des suggestions?

                Envoyé par anonyme

                Ceci dit, les vrais hackers se moquent bien des logs d'ip ;-)

                -anonyme
                Bon d'accord, mais koi faire contre les vrais hackers alors? Tu as des suggestions, des liens, des recommandations?

                Commentaire


                • #9
                  Bon d'accord, mais koi faire contre les vrais hackers alors? Tu as des suggestions, des liens, des recommandations?
                  Bonsoir,

                  Il n'y a pas de vrai et de faux hackers !! Il n'y a que des méthodes de Hacking !!!!!!!

                  et dans 98% des cas ces méthodes sont utilisées par des gens qui se font appeler hackeur et qui ne comprennent pas les 3/4 de leurs fonctionnement !

                  seul les 2% restant sont les codeurs de méthodes et les mettent à disposition de leur communauté !

                  les méthodes de hacking consistent à exploiter de potentielles failles , et cela va d'une simple application (joomla par exemple ou toutes applications tierces développées pour lui ) voir mieux carrément faille système du serveur (là faut savoir choisir des hébergeurs de qualité)

                  et des failles on en découvre tous les jours !!!

                  Ce qui est d'intérêt dans tout cela n'est pas vraiment s'intéresser à l'ip mais plutôt pouvoir bloquer ce qui est connu et surtout tracer les habitudes , les processus (composant ,modules, plugin ect ...) visés par les robots qui lancent des sondes sur des sites Joomla !

                  Les Ip seront d'intérêt pour tracer la provenance et permettre d'intervenir en bloquant par htaccess sur toute la tranche IP allouée à l'attaquant , cela aura pour effet d'obliger l'attaquant à changer de serveur pour effectuer ses requêtes. donc tu finis par isoler petit à petit les serveurs néfastes qui hébergent les fichiers distant contenant La fameuse METHODE du moment !!

                  Donc le véritable IP à Interdire n'est pas de celui qui tente de hacker ton site mais du serveur (change moins souvent et moins vite) qui heberge sa méthode

                  Puis si t'as la chance de tomber sur un attaquant trop stupide en IP fixe ou dyn lui appartenant t'auras au moins de quoi lui faire comprendre sa douleur

                  @+
                  Dernière édition par Thorhax à 18/11/2010, 19h46
                  adaptations|conceptions

                  Commentaire


                  • #10
                    Bonjour,

                    La meilleure solution de protection est la relation chaise > clavier ! personne (moi inclus) a jamais dit que ce plugin est "La" solution !

                    Ceux qui l'utilise savent pourquoi et pour quelle utilité !

                    La réponse à ta question est simple > parce que je ne l'ai pas soumis !

                    car la version disponible (qui faut le rappeler date de 2008) offre une contrainte pour un site anglophone sur les termes clé du motif.

                    Tout simplement et je l'ai dit depuis le début , ce plugin a été fait pour la communauté Fr.

                    Donc pas besoin du JED pour divulguer un travail de développement (google s'en charge ) et comme je remarque que l'intérêt participatif à faire évoluer un dev pour joomla reste plus contraignant que bénéfique je préfère garder certaines solutions pour mon entourage.

                    Il y a trop de parasites autour de Joomla et conflits d'intérêts ! qui contribuent à tuer l'information, à voir moins d'idées nouvelles se déployer et faire évoluer un produit ect ...

                    Pour finir ce sont les utilisateurs qui en pâtissent car doivent se contenter de ce qu'il leur est donné !

                    Le partage communautaire doit se faire non pas par contrainte répondant à la critique mais par plaisir de faire évoluer les choses.

                    Mais ça tu devrais déjà le savoir; de par notre historique justement !
                    Dernière édition par Thorhax à 20/11/2010, 14h17
                    adaptations|conceptions

                    Commentaire

                    Annonce

                    Réduire
                    1 sur 2 < >

                    C'est [Réglé] et on n'en parle plus ?

                    A quoi ça sert ?
                    La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

                    Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

                    Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
                    Comment ajouter la mention [Réglé] à votre discussion ?
                    1 - Aller sur votre discussion et éditer votre premier message :


                    2 - Cliquer sur la liste déroulante Préfixe.

                    3 - Choisir le préfixe [Réglé].


                    4 - Et voilà… votre discussion est désormais identifiée comme réglée.

                    2 sur 2 < >

                    Assistance au forum - Outil de publication d'infos de votre site

                    Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

                    Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

                    Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

                    UTILISER À VOS PROPRES RISQUES :
                    L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

                    Problèmes connus :
                    FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

                    Installation :

                    1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

                    Archive zip : https://github.com/AFUJ/FPA/zipball/master

                    2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

                    3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

                    4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

                    5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

                    6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
                    et remplacer www. votresite .com par votre nom de domaine


                    Exemples:
                    Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
                    Télécharger le script fpa-fr.php dans: /public_html/
                    Pour executer le script: http://www..com/fpa-fr.php

                    Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
                    Télécharger le script fpa-fr.php dans: /public_html/cms/
                    Pour executer le script: http://www..com/cms/fpa-fr.php

                    En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

                    Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
                    Voir plus
                    Voir moins
                    Travaille ...
                    X