Vous êtes ici : » Accueil » FOIRE AUX QUESTIONS ( FAQ )

FOIRE AUX QUESTIONS ( FAQ )

La FAQ n’est pas exhaustive. Elle est néanmoins très riche. Pour trouver la réponse à toute question que vous pourriez avoir, nous vous invitons à utiliser tout d’abord tous les outils habituels de recherche automatique sur le texte entier (“Edition / Rechercher” ou son raccourci “Ctrl+F“) et à consulter les textes applicables. Dans un deuxième temps, vous pouvez adresser toute question à laquelle la FAQ et les textes ne vous donnent pas de réponse  à l’équipe milbako:  info@milbako.com.

La commission Experts vous remercie par avance pour votre aide, vos critiques, vos suggestions. Dernière mise à jour : 06/2021

World Wide Web

  • Qu'elle est la différence entre HTTP et HTTPS ?

    L’Hypertext Transfer Protocol (HTTP, protocole de transfert hypertexte) est le protocole fondamental du web et codifie les interactions de base entre les navigateurs et les serveurs web. Le problème posé par le protocole HTTP simple consiste en ce que les données transférées du serveur au navigateur ne sont pas chiffrées, ce qui signifie qu’elles peuvent être visualisées, volées ou modifiées. Les protocoles HTTPS corrigent cela en utilisant un certificat SSL (secure sockets layer, couche de connecteurs sécurisée). La connexion ainsi sécurisée et chiffrée entre le serveur et le navigateur protège les informations sensibles.

  • Comment activer le mode « HTTPS uniquement » dans FireFox ?

    Lorsque vous utilisez le mode « HTTPS uniquement », cela garantit que toutes vos connexions sont chiffrées et sécurisées. Vous avez donc l’esprit tranquille, personne ne peut espionner le contenu des pages que vous visitez, ni pirater votre connexion à un site web pour voler vos mots de passe, les informations de votre carte bancaire ou d’autres informations personnelles. C’est particulièrement utile lorsque vous vous connectez à Internet par un réseau WiFi public dont l’intégrité ne peut pas vous être assurée.

    Par exemple lorsque le mode « HTTPS uniquement » est activé et qu’un site web est visité tel que http://example.com, Firefox surclasse la connexion, sans rien demander, en https://example.com

    Pour activer et désactiver le mode « HTTPS uniquement » suivez le guide ci-dessous:

    1. Cliquez sur le bouton de menu New Fx Menu et sélectionnez Options

    2. Sélectionnez Vie privée et sécurité depuis le menu de gauche.
    3. Descendez jusqu’à la section Mode HTTPS uniquement.
    4. Utilisez le bouton radio pour choisir d’activer ou désactiver le mode « HTTPS uniquement », ou sélectionnez de ne l’activer que pour la navigation privée.
      EnableHTTPSMode
  • Xampp : Le serveur Apache peut subitement s'arrêter, comment éviter le problème ?Toggle Title

    Quand vous utilisez XAMPP, le serveur Apache peut subitement s’arrêter. Voici comment éviter le problème.

    Quand vous utilisez XAMPP, le serveur Apache peut subitement s’arrêter à cause d’un problème alors qu’il était en train de démarrer. Le message Error: Apache shutdown unexpectedly. s’affiche alors sur le panneau de contrôle de XAMPP. La raison la plus courante pour expliquer cette erreur est l’impossibilité pour Apache d’utiliser les ports 80 et/ou 443. Si un autre programme utilise l’un des 2 ports, celui-ci est bloqué, et Apache ne peut pas l’utiliser. Il existe alors 2 solutions : faire en sorte qu’Apache soit le seul programme à utiliser les ports 80 et 443, ou bien configurer le serveur Apache pour qu’il utilise un autre port.

  • Comment définir les autorisations de fichier de mon serveur et les racines de mes documents?

    Pour maximiser la sécurité, vous devez adopter une politique stricte de «besoin de savoir» pour la racine du document (où les documents HTML sont stockés) et la racine du serveur (où les fichiers journaux et de configuration sont conservés). Il est très important d’obtenir les autorisations directement à la racine du serveur, car c’est ici que les scripts CGI et le contenu sensible des fichiers journaux et de configuration sont conservés.

    Vous devez protéger le serveur des regards indiscrets des utilisateurs locaux et distants. La stratégie la plus simple consiste à créer un utilisateur «www» pour l’administration Web/webmaster et un groupe «www» pour tous les utilisateurs de votre système qui ont besoin de créer des documents HTML. Sur les systèmes Unix, modifiez le fichier /etc/passwd pour faire de la racine du serveur le répertoire personnel de l’utilisateur www. Modifiez/etc/ group pour ajouter tous les auteurs au groupe www.

    La racine du serveur doit être configurée de manière à ce que seul l’utilisateur www puisse écrire dans les répertoires de configuration et de journalisation et dans leur contenu. C’est à vous de décider si vous souhaitez que ces répertoires soient également lisibles par le groupe www. Ils ne devraient pas être lisibles dans le monde entier. Le répertoire cgi-bin et son contenu doivent être exécutables et lisibles dans le monde entier, mais pas en écriture (si vous leur faites confiance, vous pouvez donner aux auteurs Web locaux l’autorisation d’écriture pour ce répertoire). Voici les autorisations pour un exemple de racine de serveur:

    drwxr-xr-x 5 www www 1024 8 août 00:01 cgi-bin/
    drwxr-x --- 2 www www 1024 11 juin 17:21 conf/
    -rwx ------ 1 www www 109674 8 mai 23:58 httpd
    drwxrwxr-x 2 www www 1024 8 août 00:01 htdocs/
    drwxrwxr-x 2 www www 1024 3 juin 21:15 icons/
    drwxr-x --- 2 www www 1024 4 mai 22:23 logs/

    La racine du document a des exigences différentes. Tous les fichiers que vous souhaitez diffuser sur Internet doivent être lisibles par le serveur pendant son exécution sous les autorisations de l’utilisateur «personne». Vous souhaiterez également généralement que les auteurs Web locaux puissent ajouter librement des fichiers à la racine du document. Par conséquent, vous devez rendre le répertoire racine du document et ses sous-répertoires appartenant à l’utilisateur et au groupe “ www ”, accessible en lecture universelle et en écriture de groupe:

    drwxrwxr-x 3 www www 1024 1 juillet 03:54 contenu
    drwxrwxr-x 10 www www 1024 23 août 19:32 exemples
    -rw-rw-r-- 1 www www 1488 13 juin 23:30 index.html
    -rw-rw-r-- 1 lstein www 39294 11 juin 23:00 resource_guide.html

    De nombreux serveurs vous permettent de restreindre l’accès à certaines parties de l’arborescence des documents aux navigateurs Internet avec certaines adresses IP ou aux utilisateurs distants qui peuvent fournir un mot de passe correct (voir ci-dessous). Cependant, certains administrateurs Web peuvent s’inquiéter du fait que des utilisateurs _locaux_ non autorisés aient accès aux documents restreints présents dans la racine du document. Il s’agit d’un problème lorsque la racine du document est lisible par tout le monde.

    Une solution à ce problème consiste à exécuter le serveur comme autre chose que «personne», par exemple comme un autre ID utilisateur non privilégié appartenant au groupe «www». Vous pouvez maintenant rendre le groupe de documents restreint – mais pas lisible par tout le monde (ne les rendez pas inscriptibles en groupe à moins que vous ne vouliez que le serveur puisse écraser ses documents!). Les documents peuvent désormais être protégés contre les regards indiscrets à la fois localement et globalement. N’oubliez pas de définir également les autorisations de lecture et d’exécution pour tous les scripts de serveur restreints.

    Le serveur du CERN généralise cette solution en permettant au serveur de s’exécuter sous différents privilèges d’utilisateur et de groupe pour chaque partie d’une arborescence de documents restreinte. Consultez la documentation du CERN pour plus de détails sur la façon de configurer cela.

    Si votre serveur démarre en tant que root mais s’exécute en tant qu’un autre utilisateur, il est particulièrement important que le répertoire des journaux ne soit pas accessible en écriture par l’utilisateur sous lequel le serveur s’exécute. Par exemple, les serveurs Netscape FastTrack et SuiteSpot sont livrés avec le répertoire des journaux accessible en écriture par l’utilisateur sous lequel le serveur s’exécute (c’est-à-dire en tant que ‘personne’ si vous choisissez les valeurs de configuration par défaut). Cela peut rendre l’effet de certains bogues CGI bien pire qu’ils ne le seraient normalement. Par exemple, si un bogue CGI permet à un utilisateur distant d’exécuter des commandes arbitraires sur le serveur, alors l’utilisateur distant peut également obtenir un accès root au serveur en exploitant le bogue pour remplacer un fichier journal par un lien symbolique vers /etc/passwd. Lorsque le serveur redémarre, le lien symbolique entraînera le chown’d de /etc/passwd à l’utilisateur du serveur.

    L’utilisateur distant peut à nouveau exploiter le bogue CGI pour ajouter une entrée à /etc/passwd. La solution de contournement suggérée consiste à modifier la propriété du répertoire des journaux afin qu’il ne soit pas accessible en écriture par l’utilisateur du serveur, puis à créer des fichiers journaux et pid vides appartenant à l’utilisateur du serveur (le serveur ne démarrera pas s’il ne peut pas ouvrez ces fichiers.) Bien que cette solution ne soit pas optimale, car elle permet aux pirates de falsifier les fichiers journaux, elle est bien meilleure que la configuration par défaut. Ce bogue peut également être présent sur d’autres serveurs commerciaux.

  • J'utilise un serveur qui fournit tout un tas de fonctionnalités optionnelles. Y a-t-il des risques pour la sécurité?

    Oui. De nombreuses fonctionnalités qui augmentent la commodité d’utilisation et d’exécution du serveur augmentent également les risques de faille de sécurité. Voici une liste de fonctionnalités potentiellement dangereuses. Si vous n’en avez pas absolument besoin, désactivez-les.

    Listes d’annuaires automatiques

    La connaissance est le pouvoir et plus le pirate à distance peut comprendre votre système, plus il a de chances de trouver des failles. Les listes d’annuaires automatiques proposées par le CERN, le NCSA, Netscape, Apache et d’autres serveurs sont pratiques, mais ont le potentiel de donner au pirate l’accès à des informations sensibles. Ces informations peuvent inclure: des fichiers de sauvegarde Emacs contenant le code source vers des scripts CGI, des journaux de contrôle du code source, des liens symboliques que vous avez créés une fois pour votre commodité et que vous avez oublié de supprimer, des répertoires contenant des fichiers temporaires, etc.

    Bien sûr, la désactivation des listes automatiques de répertoires n’empêche pas les utilisateurs de récupérer les fichiers dont ils devinent les noms. Cela n’évite pas non plus l’écueil d’un programme de recherche automatique de mots-clés de texte qui ajoute par inadvertance le fichier «caché» à son index. Pour être sûr, vous devez supprimer entièrement les fichiers indésirables de la racine de votre document.

    Lien symbolique suivant

    Certains serveurs vous permettent d’étendre l’arborescence des documents avec des liens symboliques. Ceci est pratique, mais peut conduire à des failles de sécurité lorsque quelqu’un crée accidentellement un lien vers une zone sensible du système, par exemple / etc. Un moyen plus sûr d’étendre l’arborescence de répertoires est d’inclure une entrée explicite dans le fichier de configuration du serveur (cela implique une directive PathAlias ​​dans les serveurs de style NCSA et une règle Pass dans le serveur CERN).

    Les serveurs NCSA et Apache vous permettent de désactiver complètement le suivi des liens symboliques. Une autre option vous permet d’activer le suivi de lien symbolique uniquement si le propriétaire du lien correspond au propriétaire de la cible du lien (c’est-à-dire que vous pouvez compromettre la sécurité d’une partie de l’arborescence de documents que vous possédez, mais pas celle de quelqu’un d’autre).

    Le côté serveur comprend

    La forme «exécutable» des inclusions côté serveur constitue une faille de sécurité majeure. Leur utilisation doit être limitée aux utilisateurs de confiance ou complètement désactivée. Dans NCSA httpd et Apache, vous pouvez désactiver la forme exec d’inclusions dans un répertoire en plaçant cette instruction dans la section de contrôle de répertoire appropriée de access.conf:

    Les options incluent: NoExec

    Répertoires gérés par l’utilisateur

    Permettre à tout utilisateur du système hôte d’ajouter des documents à votre site Web est un système merveilleusement démocratique. Cependant, vous devez faire confiance à vos utilisateurs pour ne pas ouvrir de failles de sécurité. Cela peut inclure la publication de fichiers contenant des informations système sensibles, ainsi que la création de scripts CGI, d’inclusions côté serveur ou de liens symboliques qui ouvrent des failles de sécurité. À moins que vous n’ayez vraiment besoin de cette fonctionnalité, il est préférable de la désactiver. Lorsqu’un utilisateur a besoin de créer une page d’accueil, il est probablement préférable de lui donner sa propre partie de la racine du document dans laquelle travailler et de s’assurer qu’il comprend ce qu’il fait. Que les pages d’accueil se trouvent dans les répertoires personnels de l’utilisateur ou dans une partie de la racine du document, il est préférable d’interdire les inclusions côté serveur et les scripts CGI dans cette zone.

  • J'ai entendu dire qu'exécuter le serveur en tant que «root» est une mauvaise idée. Est-ce vrai?

    Cela a été la source de certains malentendus et désaccords sur le Net. La plupart des serveurs sont lancés en tant que root pour pouvoir ouvrir le port 80 (le port HTTP standard) et écrire dans les fichiers journaux. Ils attendent ensuite une connexion entrante sur le port 80. Dès qu’ils reçoivent cette connexion, ils bifurquent un processus enfant pour gérer la demande et se remettent à l’écoute. Le processus enfant, quant à lui, change son ID utilisateur effectif en l’utilisateur «personne», puis procède au traitement de la demande distante. Toutes les actions entreprises en réponse à la demande, telles que l’exécution de scripts CGI ou l’analyse des inclusions côté serveur, sont effectuées en tant qu’utilisateur «personne» sans privilège.

    Ce n’est pas le scénario dont les gens mettent en garde lorsqu’ils parlent de «exécuter le serveur en tant que root». Cet avertissement concerne les serveurs qui ont été configurés pour exécuter leurs _processus enfants_ en tant que root, (par exemple en spécifiant ‘User root’ dans le fichier de configuration du serveur). C’est une énorme faille de sécurité car chaque script CGI qui est lancé avec des autorisations root aura accès à tous les coins et recoins de votre système.

    Certaines personnes diront qu’il vaut mieux ne pas démarrer du tout le serveur en tant que root, avertissant que nous ne savons pas quels bogues peuvent se cacher dans la partie du code du serveur qui contrôle son comportement entre le moment où il démarre et celui où il passe un enfant. C’est tout à fait vrai, bien que le code source de tous les serveurs du domaine public soit librement disponible et qu’il ne semble pas y avoir de bogues dans ces parties du code. L’exécution du serveur en tant qu’utilisateur ordinaire non privilégié peut être plus sûre. De nombreux sites lancent le serveur en tant qu’utilisateur «nobody», «daemon» ou «www». Cependant, vous devez être conscient de deux problèmes potentiels avec cette approche:

    Vous ne pourrez pas ouvrir le port 80 (du moins pas sur les systèmes Unix). Vous devrez dire au serveur d’écouter un autre port, tel que 8000 ou 8080.

    Vous devrez rendre les fichiers de configuration lisibles par le même ID utilisateur sous lequel vous exécutez le serveur. Cela ouvre la possibilité à un script CGI errant de lire les fichiers de configuration du serveur. De même, vous devrez rendre les fichiers journaux à la fois lisibles et inscriptibles par cet ID utilisateur, ce qui permet à un serveur subverti ou à un script CGI de modifier le journal. Voir la discussion sur les autorisations de fichiers ci-dessus.

  • Je souhaite partager la même arborescence de documents entre mes serveurs FTP et Web. Y a-t-il un problème avec cette idée?

    De nombreux sites aiment partager des répertoires entre le démon FTP et le démon Web. C’est OK tant qu’il n’y a aucun moyen pour un utilisateur distant de télécharger des fichiers qui peuvent être lus ou exécutés plus tard par le démon Web.

    Considérez ce scénario: le serveur WWW qui a été configuré pour exécuter tout fichier se terminant par l’extension «.cgi». En utilisant votre démon ftp, un hacker distant télécharge un script perl sur votre site ftp et lui donne l’extension .cgi. Il utilise ensuite son navigateur pour demander le fichier nouvellement téléchargé à partir de votre serveur Web. Bingo! il a dupé votre système en exécutant les commandes de son choix.

    Vous pouvez chevaucher les hiérarchies de serveur ftp et Web, mais assurez-vous de limiter les téléchargements ftp à un répertoire «entrant» qui ne peut pas être lu par l’utilisateur «personne».

  • Puis-je rendre mon site complètement sûr en exécutant le serveur dans un environnement «chroot»?

    Vous ne pouvez pas rendre votre serveur complètement sûr, mais vous pouvez augmenter sa sécurité de manière significative dans un environnement Unix en l’exécutant dans un environnement chroot. La commande système chroot place le serveur dans une «bulle d’argent» de telle sorte qu’il ne puisse voir aucune partie du système de fichiers au-delà d’une arborescence de répertoires que vous lui avez réservée. Le répertoire que vous désignez devient le nouveau répertoire racine «/» du serveur. Tout ce qui se trouve au-dessus de ce répertoire est inaccessible.

    Pour exécuter un serveur dans un environnement chroot, vous devez créer un système de fichiers racine miniature complet contenant tout ce à quoi le serveur a besoin d’accéder. Cela inclut les fichiers de périphérique spéciaux et les bibliothèques partagées. Vous devez également ajuster tous les noms de chemin dans les fichiers de configuration du serveur afin qu’ils soient relatifs au nouveau répertoire racine. Pour démarrer le serveur dans cet environnement, placez autour de lui un script shell qui invoque la commande chroot de cette manière:

    chroot /path/to/new/root /server_root/httpd

    La configuration du nouveau répertoire racine peut être délicate et dépasse le cadre de ce document. Voir le livre de l’auteur (ci-dessus), pour plus de détails. Vous devez être conscient qu’un environnement chroot est plus efficace lorsque le nouveau répertoire racine est aussi stérile que possible. Il ne devrait pas y avoir d’interpréteurs, de shells ou de fichiers de configuration (y compris /etc/passwd!) Dans le nouveau répertoire racine. Malheureusement, cela signifie que les scripts CGI qui reposent sur Perl ou des shells ne fonctionneront pas dans l’environnement chroot. Vous pouvez réintégrer ces interprètes, mais vous perdez certains des avantages du chroot.

    Sachez également que chroot ne protège que les fichiers; ce n’est pas une panacée. Cela n’empêche pas les pirates de s’introduire dans votre système par d’autres moyens, tels que la saisie de cartes système du service d’informations réseau NIS ou la lecture de jeux avec NFS.

  • Mon réseau local fonctionne derrière un pare-feu. Puis-je l'utiliser pour augmenter la sécurité de mon site Web?

    Vous pouvez utiliser un pare-feu pour améliorer la sécurité de votre site de plusieurs manières. L’utilisation la plus simple d’un pare-feu consiste à créer un «site interne», accessible uniquement aux ordinateurs de votre propre réseau local. Si c’est ce que vous voulez faire, il vous suffit de placer le serveur À L’INTÉRIEUR du pare-feu:

    autres hôtes
                 \
    serveur  PARE-FEU  EXTÉRIEUR
                 /
    autres hôtes

    Cependant, si vous souhaitez rendre le serveur disponible pour le reste du monde, vous devrez le placer quelque part en dehors du pare-feu. Du point de vue de la sécurité de votre organisation dans son ensemble, l’endroit le plus sûr pour le placer est complètement en dehors du réseau local:

    autres hôtes
                 \
    autres hôtes  FIREWALL  serveur  EXTÉRIEUR
                 /
    autres hôtes

    C’est ce qu’on appelle une configuration «agneau sacrificiel». Le serveur risque d’être cambriolé, mais au moins quand il y est brisé, il ne viole pas la sécurité du réseau interne.

    Ce n’est pas une bonne idée d’exécuter le serveur WWW sur la machine pare-feu. Désormais, tout bogue sur le serveur compromettra la sécurité de toute l’organisation.

    Il existe un certain nombre de variations sur cette configuration de base, y compris des architectures qui utilisent des serveurs appariés «internes» et «externes» pour donner au monde accès aux informations publiques tout en donnant au réseau interne l’accès aux documents privés. Voir le livre de l’auteur pour les détails sanglants.

  • Mon réseau local fonctionne derrière un pare-feu. Puis-je franchir le pare-feu pour permettre au reste du monde d'accéder au serveur Web?

    Vous pouvez, mais si vous faites cela, vous ouvrez une faille de sécurité dans le pare-feu. Il est de loin préférable de faire du serveur un «agneau sacrificiel» comme décrit ci-dessus. Cependant, certaines architectures de pare-feu ne vous donnent pas la possibilité de placer l’hôte en dehors du pare-feu. Dans ce cas, vous n’avez pas d’autre choix que d’ouvrir un trou dans le pare-feu. Il existe deux options:

    Si vous utilisez un type de pare-feu de type «hôte filtré», vous pouvez autoriser sélectivement le pare-feu à transmettre les demandes pour le port 80 qui sont liées ou reviennent du serveur WWW. Cela a pour effet de percer un petit trou dans la digue à travers lequel le reste du monde peut envoyer et recevoir des requêtes à la machine serveur WWW.

    Si vous utilisez un pare-feu de type «passerelle à double hébergement», vous devrez installer un proxy sur la machine du pare-feu. Un proxy est un petit programme qui peut voir les deux côtés du pare-feu. Les demandes d’informations du serveur Web sont interceptées par le proxy, transmises à la machine serveur et la réponse est renvoyée au demandeur. Un petit proxy HTTP fiable est disponible auprès des systèmes TIS à l’adresse: ftp://ftp.tis.com/pub/firewalls/toolkit/

    Le serveur CERN peut également être configuré pour agir en tant que proxy. Cependant, je me sens beaucoup moins à l’aise de le recommander, car il s’agit d’un logiciel volumineux et complexe qui peut contenir des failles de sécurité inconnues.

  • Comment puis-je détecter si mon site web a été piraté?

    Pour les systèmes Unix, le programme tripwire analyse périodiquement votre système et détecte si des fichiers système ou des programmes ont été modifiés. Il est disponible sur ftp://ftp.cerias.purdue.edu/pub/tools/unix/ids/tripwire/

    Vous devez également vérifier périodiquement vos fichiers journaux d’accès et d’erreurs pour détecter toute activité suspecte. Recherchez les accès impliquant des commandes système telles que ‘rm‘, ‘login‘, ‘/bin/sh‘ et ‘perl‘, ou des lignes extrêmement longues dans les requêtes d’URL (les premières indiquent une tentative de tromper un script CGI en invoquant une commande système ; ce dernier une tentative de saturation de la mémoire tampon d’entrée d’un programme).

    Recherchez également les tentatives infructueuses répétées d’accéder à un document protégé par mot de passe. Celles-ci pourraient être symptomatiques d’une personne essayant de deviner un mot de passe.

  • Serveurs Windows NT

  • Existe-t-il des problèmes de sécurité connus avec Netscape Communications Server pour NT?

    Vulnérabilité du code source d’inclusion côté serveur, 25 juin 1998
    Les programmeurs de San Diego Source, le service de nouvelles en ligne du San Diego Daily Transcript, ont découvert qu’en ajoutant certains caractères à la fin de l’URL faisant référence à un fichier d’inclusion côté serveur, un utilisateur distant peut récupérer le code source du fichier. , divulguant des informations exclusives, du code source protégé par le droit d’auteur et même des noms d’utilisateur et des mots de passe utilisés pour se connecter aux bases de données. En plus d’affecter les inclusions côté serveur, ce bogue affecte des produits populaires tels que Allaire Cold Fusion, Microsoft Active Server Pages et PHP.

    Les détails de l’exploit n’ont pas été publiés, mais vous pouvez trouver une description plus longue dans l’article original à http://www.sddt.com/files/library/98/06/25/tbc.html.

    Netscape travaillerait sur un correctif. Veuillez visiter le site Netscape pour les correctifs possibles. Si vous utilisez des inclusions côté serveur, vous êtes invité à effectuer une mise à niveau dès qu’un correctif est disponible.

    Les serveurs WebSite et WebSite Professional d’O’Reilly sont également vulnérables à ce bogue. Les serveurs Microsoft IIS ne semblent pas l’être.

  • Serveur UNIX

  • Existe-t-il des problèmes de sécurité connus avec NCSA httpd?

    Les versions de NCSA httpd antérieures à 1.4 contiennent une grave faille de sécurité liée à un tampon de chaîne de taille fixe. Les utilisateurs distants pourraient s’introduire dans les systèmes exécutant ce serveur en demandant une URL extrêmement longue. Bien que ce bogue ait été bien médiatisé depuis plus d’un an, de nombreux sites utilisent toujours des versions non sécurisées du serveur. La version actuelle du logiciel, la version 1.5, ne souffre pas de ce bug et est disponible sur le lien donné au début de ce paragraphe.

    Récemment, il est apparu que l’exemple de code C (cgi_src / util.c) distribué depuis longtemps avec le NCSA httpd comme exemple de la façon d’écrire des scripts CGI sûrs a omis le caractère de nouvelle ligne de la liste des caractères qui ne devraient pas être passés à coquilles. Cette ommission introduit un bogue sérieux dans tous les scripts CGI qui ont été construits au-dessus de cet exemple de code: un utilisateur distant peut exploiter ce bogue pour forcer le script CGI à exécuter toute commande Unix arbitraire. Ceci est un autre exemple des dangers de l’exécution de commandes shell à partir de scripts CGI.

    De plus, l’arborescence du code source du serveur NCSA contient elle-même le même bogue (versions 1.5a et antérieures). Le sous-programme défectueux est identique, mais dans ce cas se trouve dans le fichier src / util.c par opposition à cgi_src / util.c. Après avoir parcouru le code source du serveur, je n’ai pas trouvé d’endroit où une chaîne fournie par l’utilisateur est transmise à un shell après avoir été traitée par ce sous-programme, donc je ne pense pas que cela représente une faille de sécurité réelle. Cependant, il est préférable d’appliquer le correctif ci-dessous pour être sûr.

    Le serveur Apache, versions 1.02 et antérieures, contient également ce trou dans ses sous-répertoires cgi_src et src /. Il n’est pas improbable que le même problème soit présent dans d’autres dérivés du code source NCSA.

    Le correctif pour corriger les trous dans les deux fichiers util.c est simple. ‘phf’ et tous les scripts CGI qui utilisent cette bibliothèque doivent être recompilés après l’application de ce patch (le programme de patch GNU peut être trouvé à ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz ). Vous devez appliquer ce patch deux fois, une fois dans le sous-répertoire cgi_src / et une fois dans le répertoire src / lui-même:

    tulip% cd ~www/ncsa/cgi_src
       tulip% patch -f x;y--)
                      cmd[y] = cmd[y-1];
                  l++; /* length has been increased */
    /*---------------------------------- cut here ----------------------------------*/
  • Existe-t-il des problèmes de sécurité connus avec Apache httpd?

    En-têtes d’authentification, liste de bogues dans l’annuaire – 28 février 2001

    Les versions antérieures à la v1.3.20 contiennent des erreurs de programmation serveur qui présentent des risques de sécurité modérés à graves. Dans les bonnes circonstances, les en-têtes d’authentification ne seraient pas fournis au client. La configuration par défaut conduirait deux modules à présenter des listes de répertoires au lieu de présenter le fichier index.html par défaut, si l’URL récupérée était artificiellement longue et contenait de nombreuses barres obliques.

    Chemins NetWare – 31 janvier 2001

    Les fonctions NetWare ont créé un bogue dans lequel les directives pour les paramètres de chemin n’étaient pas interprétées correctement.

    mod_rewrite Globbing – 14 octobre 2000

    Le module mod_rewrite, si le résultat des réécritures de nom de fichier a amené un fichier à inclure $ 0 ou d’autres références similaires, pourrait entraîner la présentation des informations de configuration du serveur à un navigateur.

    Autre

    Les versions d’Apache httpd antérieures à 1.2.5 contiennent plusieurs erreurs de programmation qui présentent des risques de sécurité modérés. Les utilisateurs qui ont un accès local à la machine serveur (par exemple les auteurs Web) peuvent créer avec soin des fichiers HTML qui, une fois récupérés, donneront à l’utilisateur la possibilité d’exécuter des commandes Unix avec les autorisations utilisateur du serveur Web. Étant donné que les utilisateurs locaux ont généralement déjà autant, sinon plus, accès au système que le serveur Web, cela ne présente pas de risque majeur, mais cela peut préoccuper les FAI qui fournissent des services d’hébergement Web à des auteurs non approuvés. La version 1.2.5 d’Apache est exempte de ces bogues; mise à niveau dans les meilleurs délais. Si vous utilisez une version 1.3 beta d’Apache, vous pouvez appliquer un correctif situé sur le site Apache, ou attendre la sortie de 1.3b4.

    Les serveurs Apache antérieurs à la version 1.1.3 contiennent deux failles de sécurité qui sont beaucoup plus préoccupantes. Le premier trou affecte les serveurs compilés avec le module ‘mod_cookies’. Les serveurs compilés avec ce module contiennent une vulnérabilité qui permet aux utilisateurs distants d’envoyer au serveur des cookies extrêmement longs et de surcharger la pile de programmes, permettant potentiellement l’exécution de commandes arbitraires. Parce que cela donne aux utilisateurs distants l’accès à l’hôte du serveur, c’est une vulnérabilité bien plus grande que les trous évoqués ci-dessus, qui ne peuvent être exploités que par les utilisateurs locaux.

    Le deuxième problème avec 1.1.1 affecte les listes de répertoires automatiques. Normalement, un utilisateur distant ne peut pas obtenir une liste de répertoires si le répertoire contient une «page d’accueil», telle que «index.html». Un bogue fait échouer cette vérification dans certaines circonstances, permettant à l’utilisateur distant de voir le contenu du répertoire même si la page d’accueil est présente. Ce trou est moins grave que le premier, mais reste une fuite d’information potentielle.

    Vous trouverez plus d’informations et les binaires Apache actuels sur: http://www.apache.org/

  • Y a-t-il des problèmes de sécurité connus avec les serveurs Netscape?

    Les versions 3.6sp2 et antérieures du serveur Netscape Enterprise, ainsi que les versions 3.01 et antérieures du serveur FastTrack, contiennent un bogue de dépassement de mémoire tampon qui peut permettre à un utilisateur distant d’accéder à la machine serveur. Plus d’informations sur ce problème, ainsi que des pointeurs vers des correctifs, peuvent être trouvés à http://www.ciac.org/ciac/bulletins/j-062.shtml.

    Il y a également eu deux épisodes récents très médiatisés dans lesquels le système utilisé par Netscape Secure Commerce Server pour crypter les communications sensibles a été piraté. Dans le premier épisode, un seul message chiffré avec la clé de chiffrement 40 bits moins sécurisée de Netscape a été piraté par la force brute à l’aide d’un réseau de postes de travail. La clé de 128 bits utilisée pour les communications aux États-Unis et au Canada est considérée comme immunisée contre ce type d’attaque.

    Dans le deuxième épisode, il a été constaté que le générateur de nombres aléatoires utilisé dans le serveur pour générer des clés de chiffrement était relativement prévisible, permettant à un programme de piratage de deviner rapidement la bonne clé. Ce trou a été fermé dans les versions récentes du logiciel, et vous devez mettre à niveau vers la version actuelle si vous comptez sur le cryptage pour des communications sécurisées. Le serveur et le navigateur doivent être mis à niveau afin de fermer complètement ce trou. Voir http://home.netscape.com/newsref/std/random_seed_security.html pour plus de détails.

  • Qu’est-ce que SFTP Batch File et Comment automatiser SFTP à l’aide d’un script shell avec mot de passe en mode Batch?
    • Batch File dans SFTP peut être un fichier de format texte de plan qui contient une série de commandes.
    • Ces commandes sont lues par SFTP dans l’ordre séquentiel de haut en bas
    • Ce fichier de commandes est utilisé pour automatiser les transferts de fichiers SFTP, peut également être combiné avec des scripts pour transférer des fichiers sans aucune invite
    • Utiliser avec sftp pour fournir le nom et le chemin du fichier de commandes et pour utiliser le mode batch pour les transferts de fichiers sftp dans les scripts-b
    • Le mode Batch lit une série de commandes à partir d’un fichier batch d’entrée au lieu de stdin.
    • Étant donné que le mode batch manque d’interactions, vous pouvez utiliser le fichier batch avec le script shell SFTP sans demander de mot de passe à l’aide de sftp authorized_keys
    • Le fichier de commandes peut également être utilisé pour automatiser SFTP à l’aide d’un script shell avec mot de passe, mais vous pouvez avoir besoin d’outils supplémentaires tels que sshpass, attendez-vous, etc. pour éviter les invites de mot de passe et l’interaction de l’utilisateur
    • Un fichier de commandes de ” peut être utilisé pour indiquer l’entrée standard.-
    • sftp abandonnera si l’une des commandes suivantes échoue: get, put, reget, reput, rename, ln, rm, mkdir, chdir, ls, lchdir, chmod, chown, chgrp, lpwd, df, symlink et lmkdir.
    • L’arrêt en cas d’erreur peut être sup‐pressed sur une base commande par commande en préfixant la commande avec un caractère ‘-‘ (par exemple, ).-rm /tmp/blah*

    Donc, avec l’explication ci-dessus, nous savons en utilisant le fichier de commandes, nous pouvons automatiser les transferts de fichiers SFTP avec des scripts pour les deux situations

    1. Script shell SFTP sans demander de mot de passe, c’est-à-dire SFTP sans mot de passe (en utilisant sftp authorized_keys)
    2. Script shell SFTP avec mot de passe (à l’aide de , ou d’outils similaires pour transmettre le mot de passe)expectsshpass
  • WordPress

  • Quels prérequis techniques pour installer WordPress ?

    Avant de se lancer tête baissée dans la procédure d’installation, il convient de s’assurer que vous respectez l’ensemble des prérequis techniques. Un WordPress performant et sécurisé requiert de bonnes fondations. J’attire également votre attention sur le fait que ces prérequis évoluent nécessairement avec le temps. Il vous faudra être attentif aux changements et contacter votre hébergeur le cas échéant.

    Actuellement, les prérequis sont les suivants :

    • PHP 7 ou plus : PHP est un langage de programmation utilisé par WordPress. La version 7 sorti fin 2015 a permis de diminuer par deux les temps de chargement. Hélas, nous trouvons encore de nombreux sites sur des versions antérieures comme PHP 5.4, 5.5 ou 5.6. Aucune version 6 de PHP n’est sortie ;
    • MySQL 5.5 ou supérieure : MySQL ou son équivalent libre MariaDB est le langage de base de données. Une base de données stocke vos contenus ainsi que les réglages dans une sorte de grand tableau ;
    • La réécriture d’URL est fournie par mod_rewrite un module Apache, l’équivalent existe sous nginx ;

    Ces informations peuvent paraître techniques, c’est pourquoi je vous invite à vous rapprocher d’un spécialiste WordPress si nécessaire.

  • Comment installer WordPress en local ?

    Il existe de multiples façons d’installer WordPress sur un serveur local. La méthode la plus simple repose sur Local by Flywheel, mais des solutions historiques comme MAMP ou EasyPHP feront tout aussi bien l’affaire.

    Nous arrivons au terme de ce tutoriel pour apprendre à installer WordPress selon les règles de l’art. Un dernier conseil important : ne vous laissez pas tenter par les modules d’installation en un clic proposés par les hébergeurs. Vous ne disposerez pas toujours d’un accès à la base de données et vous serez bien souvent limités en performances. C’est une fausse bonne idée !

  • Que faire après l’installation de WordPress ?

    Nous avons pléthore de tutoriels à vous recommander pour optimiser votre installation en termes de sécurité et de performances, en voici une sélection :

    • Augmenter la limite mémoire : cette ligne de configuration vous évitera d’obtenir des pages blanches lors d’opérations lourdes en back-office, c’est une technique recommandée ;
    • Mettre en place une sauvegarde intégrale de votre site : planifiez des sauvegardes régulières de vos fichiers et de votre base de données afin de prévenir un piratage ou une erreur de manipulation. C’est indispensable mais bien souvent ignoré ;
    • 14 astuces pour sécuriser votre WordPress : une liste non exhaustive de bonnes pratiques en matière de sécurité.
  • Roundcube webmail

  • Comment activer le mode de débogage dans la messagerie Web Roundcube

    Veuillez suivre le didacticiel pour trouver d’abord le fichier de configuration Roundcube ( config/config.inc.php): Emplacements des fichiers de configuration et journaux des principaux composants

    Ensuite, ajoutez les paramètres ci-dessous dans config/config.inc.php:

    // system error reporting, sum of: 1 = log; 4 = show
    $config['debug_level'] = 4;
    
    // Log SQL queries
    $config['sql_debug'] = true;
    
    // Log IMAP conversation
    $config['imap_debug'] = true;
    
    // Log LDAP conversation
    $config['ldap_debug'] = true;
    
    // Log SMTP conversation
    $config['smtp_debug'] = true;
    

    Pas besoin de redémarrer le service Web.

    Roundcube est configuré (par iRedMail) pour se connecter au fichier journal de Postfix, c’est /var/log/maillogou /var/log/mail.log.

  • Bases de données

  • Qu'est ce que mariaDB ?

    MariaDB est un système de gestion de base de données open-source, couramment utilisé comme alternative à MySQL en tant que partie de la base de données de la populaire pile LAMP (Linux, Apache, MySQL, PHP/Python/Perl) Il est destiné à remplacer MySQL.

    Le tutoriel de démarrage rapide décrit comment installer MariaDB sur un serveur Ubuntu 20.04 et le configurer avec une configuration initiale sûre. Il portera également sur la manière de créer un compte administratif supplémentaire pour l’accès par mot de passe.

  • Translate »
     
    Laisser un commentaire
    Votre commentaire
    Avez-vous des commentaires supplémentaires?
    Suivant
    Entrez votre e-mail si vous souhaitez que nous vous contactions au sujet de vos commentaires.
    Retour
    Envoyer
    Merci d'avoir envoyé vos commentaires!
    %d blogueurs aiment cette page :