HtmlToText
skip to content home contact sommaire boite à idée linux attitude le libre est un état d'esprit contact sommaire boite à idée apache ftp like aug 18 sysadmin par peck niveau : résumé : alias / /%{username} aujourd'hui je voudrais faire un serveur web qui se comporterait comme un serveur ftp ou sftp. lorsqu'un utilisateur unix se connecte à un serveur ftp avec un login et un mot de passe, il lui est présenté un contenu qui lui est propre (son $home par exemple). comment faire l'équivalent avec apache ? dit autrement, je voudrais que les 2 commandes suivantes renvoient un contenu différent : $ wget http://usera@www.monserveur.com/ # répertoire a $ wget http://userb@www.monserveur.com/ # répertoire b pour cela il faut jouer avec les rewriterules, mais c'est plus balaise que ça en a l'air. premièrement il faut une authentification. j'ai choisi ldap, mais prenez la méthode que vous préférez : http://httpd.apache.org/docs/2.2/mo... tout ce qui commence par mod_authn est valable. voici comment on la met en place : <location /> authtype basic authname "my server" authbasicprovider ldap authldapurl ldap://serveur.ldap.com/dc=domaine,dc=com?uid?sub authldapbinddn cn=user,ou=technical,dc=domaine,dc=com authldapbindpassword password require valid-user </location> ensuite on joue avec rewriterule, les variables s'appellent sous la forme %{env:variable} # utilisez %{env:user_auth} pour ceux qui n'ont pas choisi l'authent ldap rewriterule ^(.*) /%{env:authenticate_uid}/$1 mais ça ne marche pas. tout d'abord on apprend qu'il faut mettre les règles dans le location sinon les variables d'authentification ne sont pas disponibles. ensuite on a oublié d'activer le rewrite engine. et enfin dans un location (ou un directory) on ne matche plus la request uri mais le chemin créé à partir de cette uri. cela qui une fois corrigé nous donne quelque chose comme ça : <location /> rewriteengine on # le résultat sera automatiquement préfixé par le documentroot si on ne le fait pas nous même # notez l'absence du / initial dans le pattern ... rewriterule ^var/www/html/(.*) /%{env:authenticate_uid}/$1 </location> mais ça ne marche toujours pas. en effet, le rewrite engine d'apache est réentrant, quelle que soit la modification et quel que soit le flag utilisé, si une url est modifiée, apache fait une redirection interne et relance toute la machinerie (dont les redirections). pour les petits malins, non [l] n'est pas fait pour ça, par contre la doc évoque un [end] qui aurait cette fonctionnalité mais je ne l'ai pas trouvé. il nous faut donc un moyen de détecter qu'une url a déjà été transformée par une rewriterule. malheureusement les variables (comme %{env:authenticate_uid}) ne sont valables que dans la partie gauche de rewritecond ou dans la partie droite de rewriterule ce qui nous limite sévèrement. on ne peut pas matcher le chemin en pour détecter qu'il contient le répertoire de l'utilisateur. de plus on ne peut pas utiliser une autre racine, apache ajouterait automatiquement le documentroot en cours. j'ai essayé en utilisant des variables d'environnement temporaire (avec [e=var:value]), mais le rewrite engine l'évalue trop tard et ne détecte pas la nouvelle valeur de la variable modifiée par lui-même. ma solution est donc de mettre en place un unique répertoire contenant les utilisateurs avec un nom improbable car il ne pourra pas être utilisé comme nom de répertoire dans les répertoires utilisateurs. et d'utiliser ce nom de répertoire comme marqueur d'url déjà traitée. ce qui nous donne : # mon répertoire s'appelle ____data____ rewriterule ^var/www/html/(?!____data____/)(.*) /____data____/%{env:authenticate_uid}/$1 c'est bien joli, mais ça n'empercherait pas un utilisateur d'aller voir dans le répertorie de son voisin. en effet, ce ne sont que des rewrite rules, pas des droits d'accès. puisqu'on ne peut pas utiliser les noms de répertoire utilisateur dans les require pour le matcher avec les nom d'utilisateur (on se mordrait la queue (et ça fait mal (au dos))). il nous faut donc le garantir d'une autre façon, en forçant tout utilisateur a n'accéder qu'à son répertoire avec une autre règle. # ce qu'on veut c'est éviter l'utilisateur qui voudrait bypasser la première règle avec un http://www.monserveur.com/____data____/userx rewriterule ^var/www/html/____data____/.*?/(.*) /var/www/html/____data____/%{env:authenticate_uid}/$1 # et on voudrait ausst éviter que l'utilisateur puisse scanner la racine rewriterule ^var/www/html/____data____/?$ /var/www/html/____data____/%{env:authenticate_uid}/ notez l'ajout de /var/www/html dans les chaines de remplacement, c'est pour éviter qu'apache pense qu'on a modifié le chemin si on n'a rien changé. et c'est gagné, on a enfin trouvé ! je vous laisse donc profiter du résultat : edit : la version finale minimise l'appel aux règles, prend en compte les chemins qui se terminent par / et les tentatives d'accès à des répertoires non autorisés. <location /> authtype basic authname "my server" authbasicprovider ldap authldapurl ldap://serveur.ldap.com/dc=domaine,dc=com?uid?sub authldapbinddn cn=user,ou=technical,dc=domaine,dc=com authldapbindpassword password require valid-user # make http behave like ftp rewriteengine on # create home dir var rewriterule .* - [e=user_root:/var/www/html/____data____/%{env:authenticate_homedirectory}] rewritecond %{env:user_root} !-d rewriterule .* - [e=user_root:/var/www/html/forbidden] # redirection vers les repertpoires utilisateur rewritecond %{request_filename} !^/var/www/html/____data____ rewriterule ^var/www/html/(.*) %{env:user_root}/$1 [l,dpi] # impossibilite de lire la racine rewritecond %{request_filename} ^/var/www/html/____data____/?$ rewriterule .* %{env:user_root} [l,dpi] # impossibilite de lire le repertoire d'un autre rewritecond %{env:authenticate_homedirectory}|%{request_filename} !^(.*?)\|/var/www/html/____data____/\1 rewriterule ^var/www/html/____data____/?[^/]*/?(.*) %{env:user_root}/$1 [l,dpi] </location> <directory /var/www/html/forbidden> deny from all </directory> note : et pour ceux qui voudraient vraiment faire du ftp avec apache il y a mod_ftp . 1 comment apache , planet-libre , planete-libre , serveur read more j’ai pété gpt guid partition table aug 13 sysadmin par peck ... désolé niveau : résumé : gdisk /dev/sda le format gpt guid partition table est un format de partitionnement de disque. il ne faut pas confondre un format de partitionnement avec le formatage d'une partition avec système de fichier. il y a de nombreux formats de système de fichier : ext4, swap, xfs ... mais il n'existe que peu de format de partitionnement, les plus connus étant : mbr : format utilisé par les premiers pc sous dos et encore en usage sur la beaucoup de vos machines disklabel : utilisé sur solaris et bsd gpt : apparu récemment (il y a environ 15 ans) pour les besoins de l'itanium ce format a pour but de palier les différents problèmes de son prédécesseur direct le mbr : stockage de la table en double et checksum du contenu : la table étant une structure très importante, on peut enfin se dire qu'on ne la perdra plus stockage des offset en lba sur 64 bits : on arrête de parler de chs obsolètes depuis longtemps et on espère pouvoir tenir assez longtemps la croissance des tailles de disques : 9 milliards de téra octets avec des secteurs de 512 octets on dépasse donc la limite des 2to supportés par le format mbr, si vous avez un disque de plus de 2tio il est a peu près certain qu'il a déjà du gpt tous les identifiants sont des uuid : garantis uniques, on peut en créer autant qu'on veut (2^128) et il y en a partout la table fait au minimum 16kio : on n'a plus de question de table primaire/logique/étendue et on peut stocker au moins 128 partitions sans se poser de question accessoirement on peut stocker des noms de partition directement dans la table attention, on stocke des adresses de secteur ( lba comme en mbr depuis un certain temps) et non d'octets, et la taille d'un secteur peut varier d'un disque à l'autre, il faut faire attention à ne pas copier les tables gpt trop littéralement. gpt est indiqué comme nécessaire pour le support du boot sur efi, bien qu'il soit théoriquement possible de faire sans. partitionner en gpt pour partitionner en gpt vous avez le choix entre deux familles d'outil : parted et gparted gdisk, sgdisk et cgdisk (remplaçants de la famille fdisk) le moins dangereux est de ne partitionner que vos nouveaux disques en gpt, mais il y a moyen de refaire la table de partition d'anciens disques s'il y a suffisament de place pour stocker la table gpt (16kio en début et en fin de disque plus le mbr). si l'espace est disponible, c'est simple, il vous suffit de reporter les adresses de début et de fin de chaque partition du mbr vers le gpt. choix des partitions tout d'abord je vous recommande d'aligner vos partition sur 1mio, le minimum recommandé étant de 4kio. le minimum de 4ko s'explique par le fait que de plus en plus de disques ont des secteurs de 4ko, et si vos écritures ne sont pas alignées sur 4kio vous allez voir vos performances dégringoler. il faut ajouter que de plus en plus de disques sont des ssd. les ssd ont des pages sur lesquelles il est aussi intéressant de se caler et elles peuvent aller jusqu'à 1mio. donc ne vous posez plus la question et prenez la valeur par défaut de l'outil qui aligne sur le mio. si vous avez un boot sur efi, vous devez faire une partition efi (type esp), ne soyez pas radin, mettez-y au moins 100mo si vous avez un boot sur un bios d'origine, il est conseillé de faire une partition de type bios. certaines personnes indiquent que celle-ci est indispensable car gpt ne laisse pas de place caché pour le bootloader. c'est faux puisqu'il suffit d'aligner les partitions pour faire apparaître de la place. mais puisqu'on en en est à faire des trucs propres, profitez-en pour faire ce qui aurait du être fait depuis très longtemps et faites de la place pour stocker un bon grub2 avec tous ses modules (1mo) si vous voulez permettre l'hibernation de votre machine (ou si vous avez peu de ram) n'oubliez pas d'inclure une partition de swap. pensez à séparer système et données sur deux partitions différentes. la partition de données est naturellement /home pour une particulier, mais sur un serveur c'est plus flou : /var /srv /home sont des répertoire de données. compatibilité mbr dans la notion de mbr (un unique secteur de 512 octets) il faut différencier le code et la table des partitions. si vous utilisez un bios classique, le code du mbr restera le même (grub/lilo/boot windows ...). si vous utilisez efi, le code du mbr peut être vide (ce que fait en général gdisk), mais il peut être intéressant de mettre un code fonctionnel avec un avertissement. la table des partitions du mbr doit elle être protégée pour éviter à un outil d'édition de cette table de tenter d'y faire des modifications et d'effacer vos précieuses données. c'est pour cela qu'on y inscrit un "protective mbr" qui indique que le disque est entièrement utilisé par une partition unique de type gpt. 2 comments disque , planet-libre , planete-libre , système read more quand on me demande un script shell pour corriger un problème d’architecture jan 26 paul et mickey par peck republié par http://lesjoiesdusysadmin.tumblr.co... 4 comments none read more nouveautés ext4 jan 20 sysadmin par peck niveau : résumé : stats howdy ho ! savez-vous ce qu'il y a de nouveau dans ext4 ? tout le monde sait à peu près qu'il y a moyen de stocker plus de fichiers et des fichiers plus gros que dans ext3. bon c'est gentil, mais quand on ne s'appelle pas google ou la nsa, stocker des fichiers de plus de 2to n'est pas vraiment notre priorité. de plus l'usage des extents, qui permet ce genre de choses, a l'avantage de réduire la fragmentation. bien. passons à des choses plus sympathiques, savez-vous que ext4 peut stocker la liste des blocs inutilisés ? Ça n'a l'air de rien, mais du coup la durée de fsck n'est plus proportionnelle à la taille du volume, mais à la quantité de données stockées ! enfin une bonne nouvelle. ext4 supporte la méthode discard, c'est à dire l'indication au block device que certains blocs ne sont plus utilisés. cette fonctionnalité est indispensable pour conserver les performances des ssd sur le long terme. parlons des dates maintenant. le format de stockage des dates a changé, ce qui veut dire deux choses : on est maintenant y2038 safe et on peut maintenant stocker des dates précises à la nanoseconde. de plus il est possible de stocker une date supplémentaire : la date de création (crtime). cette information était un gros manque pour les habitués du système de microsoft. en effet, il est trop facile et fréquent de toucher aux fichiers et par là même mettre à jour les dates du fichier. la date de création elle est immuable et permet de savoir quand est apparu un fichier. des nouveaux timestamps ! ceux-ci dépendent d'une nouvelle fonctionnalité d'ext4 : les inodes de 256 octets. on ne peut donc avoir les timestamps à la nanoseconde et la date de création que sur des systèmes de fichiers fraîchement créés et pas sur des systèmes upgradés depuis ext3 s'ils avaient été créés avec la taille par défaut. pour pouvoir les stocker, il faut passer l'option -i 256 à la création du système de fichier. $ mkfs.ext4 -i 256 /dev/sdxy et pour les utiliser ? sachant qu'il s'agit de fonctionnalités d'un système de fichiers, il faut passer par le vfs pour les utiliser. le problème c'est que le vfs n'avait pas prévu ce cas. il y a donc de nombreuses modifications à faire avant de les voir arriver dans ls : modifier le vfs pour avoir une fonction permettant de récupérer ces données, modifier l'appel système stat, modifier la libc, modifier ls et ses amis pour qu'ils affichent l'information. c'est trop bête, nous avons l'information sur le disque et nous n'y avons pas accès. heureusement, si on est root, un disque ça se lit, il suffit juste de savoir où est l'info et d'aller la chercher. lire la date de création d'un fichier je rappelle que les autres dates directement disponibles avec stat sont : atime (dernier accès), mtime (dernière modification du contenu) et ctime (dernière modification de métadonnées). on récupère l'inode du fichier $ stat -c%i fichier on récupère la partition sur laquelle est stockée le fichier $ df fichier | awk 'nr==1 {next} {print $1; exit}' et enfin on lit les infos directement sur le disque avec debugfs (il faut être root) $ debugfs -r "stat <$inode>" /dev/sdax ce qui agrégé en une ligne de commande donne pour le fichier $file : $ file=/bin/ls; debugfs -r "stat <$(stat -c%i "$file")>" $(df "$file" | awk 'nr==1 {next} {print $1; exit}') | grep time 11 comments disque , système read more repartitionner sans rebooter jan 13 sysadmin par peck niveau : résumé : hdparm -z /dev/used_device comment repartitionner un disque contenant une partition indispensable (par exemple /) sans rebooter ? si l'intégralité de votre disque est en lvm, cet article ne vous concerne pas puisque vous pouvez simplement redimensionner vos volumes lvm. mais supposons que vous ayez au moins une "partition" que vous voulez redimensionner. posons une limite : il ne vous sera pas possible de toucher à une partition en cours d'utilisation et de prendre en compte cette modification sans rebooter ou la désactiver temporairement. une partition est dite utilisée si elle est montée ou activée en tant que swap, utilisée dans un md lancé ou présente comme pv (physical volume) dans un vg (volume group) actif. c'est parti maintenant nous avons un disque dont une partition au moins est utilisée, et une autre (celle qu'on veut redimensionner ou déplacer) ne l'est pas. modifions la table des partitions avec fdisk (cfdisk ou parted feront l'affaire). attention, pour toute autre opération qu'une création ou un changement du secteur de fin (déplacement), fdisk ne suffira pas. lorsque vous quittez l'outil et que vous écrivez sur le disque, celui-ci tente de relire la table des partitions. puisqu'une des partitions est en cours d'utilisation, il vous indique qu'il n'a pas pu le faire. si vous pouvez libérer la partition temporairement, alors il suffit d'utiliser la commande suivante pour que sa table des partitions soit relue : $ hdparm -z /dev/sdx supposons que vous ne puissiez pas libérer la partition. la solution est simplement d'utiliser un loopback ! pour cela, récupérez l'offset à utiliser depuis la table de partition : $ fdisk -lu /dev/sda | grep sda2 > /dev/sda2 1026048 286515199 142744576 83 linux ici l'offset de début est 1026048*512 et celui de fin 286515199*512. il n'y a plus qu'à créer le loopback. attention pour la taille la formule est "secteur de fin - secteur de début + 1" car ces secteurs sont inclus : # unités : octet $ losetup -o $(($start*512)) --sizelimit $((($end-$start+1)*512)) -f --show /dev/sda # un message d'erreur apparait, mais il peut être ignoré et voilà, vous pouvez maintenant faire un resize2fs sur le device de loopback et/ou un mount directement ! ps : on pourrait croire qu'on peut faire mieux avec device mapper et dmsetup. mais en fait ce n'est pas possible car device mapper considère que le disque complet est en cours d'utilisation si une de ses partitions est utilisée. 2 comments système read more signer ses logs nov 2 sysadmin par peck niveau : résumé : syslog | openssl dgst vous êtes vous déjà posé la question de la sécurisation de vos logs ? sont-ils accessibles ? modifiables ? peut-on détecter une falsification ? comment faire pour que les logs ne soient pas altérés par une personne de peu de principes ? je vous propose une solution qui n'est pas une solution miracle, mais c'est une solution qui sera une brique de plus dans votre défense en profondeur. nous allons signer cryptographiquement les logs pour que tout altération devienne visible comme le nez au milieu de la figure. signature et validation des logs je vous au préparé pour cela deux programmes (lien en fin d'article), l'un pour signer les logs, l'autre pour les valider. bien sûr, on ne va pas signer les fichiers de logs directement, ça laisserait tout le temps à un attaquant de les modifier avant la signature. nous allons plutôt nous insérer dans le système syslog pour disposer des lignes au fur et à mesure. mais nous n'allons pas non plus signer toutes les lignes, ce serait trop lourd. nous allons plutôt signer des blocs de lignes, par exemple une signature toutes les 100 lignes, sans oublier un timeout pour éviter que 99 lignes restent en mémoire trop longtemps.. enfin une des fonctionnalités importante de ces outil est le chaînage. le chaînage est le fait d'utiliser la signature du bloc précédent comme faisant partie du bloc suivant. ceci garanti qu'il ne peut y avoir suppression ou ajout d'un bloc eu milieu d'une chaîne de blocs. et tant qu'on y est nous pouvons aussi chaîner les fichiers pour obtenir le même résultat au niveau fichier. au final toute modification, ajout ou suppression de ligne entraine l'invalidation de la signature. toute modification, ajout ou suppression de bloc ou de fichier de log entraine l'invalidation de la signature. voici donc un exemple d'usage sous forme de pipe : $ openssl genrsa -out key.pem 1024 # il nous fait une clé de signature $ echo "log important" | signlogger -k key.pem -f logfile notez que c'est utilisable avec syslog puisque celui-ci vous permet d'utiliser un pipe à la place d'un fichier. je ne détaille pas cela ici car cela dépend du sylog que vous utilisez (syslogd, syslog-ng, rsyslog ...). et pour vérifier que votre fichier de log n'a pas été modifié ? $ openssl rsa -in key.pem -pubout > pubkey.pem # on récupère la version publique de la clé $ signvalidator -k pubkey.pem -f logfile si vous voulez utilisez cet outil avant logger ou avant l'envoi à un serveur centralisé, il faudra modifier signvalidator pour qu'il ignore les éléments ajoutés par syslog dans la vérification de la signature (date, pid, ...). usage dans la vraie vie quand on parle de sécurité, il faut se demander de quoi on veut se prémunir. signer les logs a pour but d'éviter qu'on puisse modifier les logs a posteriori, puisqu'on n'empêche personne de transformer les logs avant qu'ils ne soient envoyés à syslog. mais toute personne qui a accès en écriture aux logs a posteriori, a les mêmes droits que le processus qui écrit les logs. il a donc accès au système de signature. mais alors qu'a-t-on gagné ? tout d'abord, un difficulté légèrement accrue pour un attaquant, c'est pas grand chose, mais ça peut toujours servir. ensuite, il nous suffit maintenant de séparer les droits du système de chiffrement de ceux du système d'écriture pour enfin détecter la modification par une personne possédant les droits d'écriture. pour cela vous avez plusieurs moyens à votre disposition : utiliser des pipes et des des utilisateurs séparés pour la signature et pour l'écriture utiliser l'attribut append only des fichiers de log pour interdire toute modification du fichier a posteriori (sauf par root qui peut retirer l'attribut) utiliser un medium read only pour écrire les logs utiliser un hsm pour interdire la réutilisation de la clé déporter les logs vers un serveur syslog ou toute combinaison de ceux-ci. vous remarquerez que ces techniques ont déjà pour but d'empêcher la modification des logs a posteriori. la signature n'apporte qu'une preuve supplémentaire. mais prenez l'exemple du serveur syslog centralisé. on ne peut plus modifier les logs depuis le client, mais on le peut toujours depuis le serveur. la signature, si elle est effectuée côté client permet d'apporter une garantie supplémentaire puisqu'il faut cette fois un accès coté client et côté serveur pour effecture la modification. si on y ajoute l'append only, il faut être root, si on y ajoute le hsm, il faut disposer d'une carte à puce ou d'un mot de passe, si on y ajoute un media read only, il faut disposer d'un accès physique pour le modifier. et chacun de ces éléments peut être géré par une personne différente pour rendre impossible toute modification par une unique personne malintentionnée. a vous de choisir votre niveau de sécurité ! en détail je vous colle ici l'usage complet des commandes (c'est du perl pour ceux qui veulent savoir) $ signlogger --help usage: signlogger [options] options --key|-k keyfile use private key for signing (pem encoded) --file|-f file log to file instead of stdout --lastsig|-l line use line as last signature (used for chaining) --initfile|-i file use last line of file as last signature (used for chaining) --blocksize|-b lines insert signature each "lines" count (default 50) --timestamp|-t seconds insert signature each "seconds" seconds (default 30mn) --help|-h this help $ signvalidator --help usage: signvalidator [options] options --key|-k keyfile use public key for validation (pem encoded) --file|-f file read file instead of stdin --lastsig|-l line use line as last signature (used for chaining) --initfile|-i file use last line of file as last signature (used for chaining) --help|-h this help et pour les télécharger : signlogger pour la signatrue des logs signvalidator pour la validation des logs 3 comments logs , système read more log de l’historique sep 12 sysadmin par peck niveau : résumé : trap debug ; prompt_command voici comment loguer l'activité d'un utilisateur. mais tout d'abord, commençons par apprendre comment envoyer une ligne dans syslog. c'est simple, il suffit d'appeler logger avec les options qui vous intéressent (toutes optionnelles) et un message : $ logger -i -p local5.info -t bash "$(tty): bonjour syslog" on enregistre le pid (option -i) pour permettre la corrélation avec d'autres lignes de logs. on utilise la facility local5 qui est une sorte de tag utilisé par syslog pour savoir dans quelle catégorie mettre les logs. les facilities servent essentiellement à faire des règles de tri des logs (par exemple il y a une facility authpriv pour tout ce qui est authentification). il y a 8 facilities disponible pour les administrateur qui voudraient utiliser des valeurs qui ne sont pas standard. j'ai choisi local5. on utilise le niveau de log info qui est quelque chose de standard parmi les systèmes de logs en général et permet de filtrer facilement. on en profite pour loguer le tty en cours pour permettre une corrélation avec la commande last (on ne sait jamais). nous avons aussi besoin de la commande capable de nous donner la dernière commande tapée : # lister la dernière commande sans son numéro $ fc -ln -1 il n'y a plus qu'à mettre l'une de ces lignes dans le fichier /etc/profile qui est lu par bash au lancement de sessions interactives : # envoyer la commande dans syslog pour chaque commande avant exécution $ trap 'logger -i -p local5.info -t bash "$user $(tty): $(fc -ln -1)"' debug # envoyer la commande dans syslog pour chaque commande apres exécution $ prompt_command='logger -i -p local5.info -t bash "$user $(tty): $(history 1)"' # fc ne marche pas correctement dans prompt_command pourquoi enregistrer cette info peut être utile puisque les logs ne sont pas modifiables par un utilisateur simple. et si vous avez un serveur syslog centralisé, ils ne le sont même pas par root depuis la machine d'origine. mais ceci ne doit pas vous faire oublier eux choses. tout d'abord le shell est un processus lancé par l'utilisateur, ce qui veut dire que l'enregistrement de cette information est nécessairement soumis à la bonne volonté de l'utilisateur. un utilisateur peut supprimer le trap ou remplacer le prompt_command. et supposons que vous trouviez un moyen pour l'en empêcher, l'utilisateur peut toujours tuer son propre shell, lui faire faire un exec vers un autre shell n'ayant pas de logs, tracer son shell pour modifier son activité etc. ensuite il faut être bien conscient de ce qu'on enregistre. on enregistre l'activité interactive d'un shell. ceci exclue les transferts de fichiers (scp,...), les exécutions automatiques (cron, ...), les exécutions via un code (vi script; ./script). et si on regarde bien ce dernier cas, on comprend qu'à moins de loguer tous les appels systèmes avec tous leurs paramètres, il est impossible de garantir qu'un utilisateur malveillant n'a pas exécuté une commande. en conclusion ce système n'est pas là pour garantir l'enregistrement de toute activité d'un utilisateur plus ou moins malveillant, mais ça peut être une piste de recherche parmi d'autres lorsqu'un problème survient (qui a supprimé ma libc ?). 7 comments commande read more 57 pages older entries linux attitude linux attitude sondage seriez-vous pret a payer pour avoir un os libre ? oui oui avec un service d'expertise non voir les résultats loading ... commentaires poc domotique arduino + raspberry pi – les fabriqueurs on faire communiquer des socket avec socat le monde geek | pearltrees on le chercheur, l’ingénieur et l’informaticien bairreg on processus et threads willy on log de l’historique mirana on log de l’historique tags 2ans android apache bibliothèque c code commande curiosité debian disque firewall graphisme historique hors série hébergement interface graphique ipv6 lecture de code lectures logs matériel noyau pam perl planet-libre planete-libre routeur réseau savoir-faire scripting serveur son ssh standard système sécurité théorie versioning virtualisation x11 catégories android développement paul et mickey perso réseau sysadmin sites ami test1 archives august 2014 january 2014 november 2012 september 2012 august 2012 july 2012 june 2012 february 2012 january 2012 july 2011 june 2011 may 2011 april 2011 march 2011 february 2011 january 2011 december 2010 november 2010 october 2010 september 2010 august 2010 july 2010 june 2010 may 2010 april 2010 march 2010 november 2009 october 2009 september 2009 august 2009 june 2009 may 2009 april 2009 march 2009 february 2009 january 2009 december 2008 november 2008 october 2008 september 2008 august 2008 july 2008 june 2008 april 2008 march 2008 february 2008 january 2008 december 2007 november 2007 october 2007 september 2007 august 2007 july 2007 june 2007 may 2007 april 2007 march 2007 copyright © 2018 linux attitude design by srs solutions top
linux-attitude.fr rapport :
Visitez le site