Vous êtes ici : » Accueil » Serveur L’unix

Serveur L’unix

Serveur LUNIX

  • 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
  • Comment écrire sans faute la syntaxe Cron?

    Comme nous l’avons remarqué précédemment, un fichier crontab se constitue de cinq champs  (chaque champ est représenté par un astérisque) afin de fixer la date et l’heure d’une tâche spécifique à faire d’une façon répétitive.

    • Minute : La minute de l’heure à laquelle vous souhaitez que la commande soit faite (de 0 à 59)
    • Heure : L’heure à laquelle vous souhaitez la commande sera faite (de 0 à 23)
    • Jour du mois : Lejour du mois où la commande sera faite (de 1 à 31)
    • Mois :   Le mois où vous souhaitez que la commande en question soit exécutée.
    • Jour de la semaine :Le jour de la semaine où vous voulez que la commande soit faite (de 0 à7)

    Il existe également des caractères appropriés pour chaque fichier Crontab

    • Astérisque (*) : ce caractère est  utilisé pour la définition des paramètres de planification.
    • Virgule (,) : Pour fixer deux ou plusieurs dates d’exécution de la même commande.
    • Tiret (-) : afin de fixer le créneau horaire lorsque vous définissez de nombreuses dates d’exécution d’une commande
    • Barre oblique (/) : cette commande vous permet de fixer des intervalles de temps prédéterminées dans un créneau spécifique.
    • Last (L) : (Dernier en anglais).  Cette commande est utilisée pour fixer le dernier jour d’une semaine ou d’un mois spécifique.  A titre d’exemple, 4L signifie le dernier jeudi.
    • Weekday (W) : (le jour de la semaine en anglais) alors cette commande a pour fonction de déterminer le jour de la semaine le plus proche d’un moment donné.  Par exemple si vous souhaitez exécuter la commande le lundi  le 3 et que le 1erest un samedi, vous devriez taper 1W.
    • Hash (#) : Cette commande a pour but de préciser le jour de la semaine, suivi d’un nombre allant de 1 à 5.  Pour déterminer un deuxième lundipar exemple tapez 1#2
  • Translate »