Comme vous le savez, tous les gros bugs arrivent toujours le vendredi… celui-ci n’as pas dérogé à la règle.

Mise en situation: Un des serveurs mail que j’administre utilise un serveur LDAP distant pour l’authentification, le réseau entre les deux étant très sollicité, j’ai donc tout naturellement installé le service NSCD qui permet de mettre en cache les requêtes des services de noms les plus courants. Ce setup a fonctionné à merveille pendant un an…

Ce matin, j’ai eu des remontés de panne d’utilisateurs qui essuyaient des échecs (« Auth failed ») lors du relevé quotidien de leurs mail, alors que d’autres n’avaient aucun problème. On pouvait noter cet erreur dans les logs:

Après moultes recherches, infructueuses.. (n’oublions pas qu’il sagit de la panne chiante embêtante du vendredi) .. je me rends compte du fait que le service de cache nscd est au tas (et que bien évidemment je n’avais reçu aucune alerte. Vendredi, tout ça…)

Démarrage en mode debug du daemon:

Invalidons le cache:

Le service s’écroule au bout de 30s de travail… Passons aux choses sérieuses brutales.

Le tour est joué ! Trois heures que les choses ont repris, la chose est stable.

Pour information un bug est ouvert sur le bugtrack et il sagit de la version:

Aujourd’hui sur IRC j’ai eu droit a: « un PDF c’est mieux que des manpages toutes pourries dans un shell. »
Oui, mais non ! Il existe un moyen simple de colorer joliment vos manpages et donc de les rendre beaucoup plus agréable/pratiques.

Vos manpages en couleurs avec most:

Ce qui nous donne:

Pour le supprimer:

Rien de plus simple, on supprime la variable et on efface toutes traces de most.

One more thing:

On me souffle dans l’oreillette qu’il est possible de faire la même chose avec less:

Grand coup de stress pour moi ce soir ! En effet, les requêtes SQL des sites hébergés sur cette machine n’avaient plus aucun sens: drop, réponses érronées et j’en passe.. en jetant un oeil dans les logs j’ai trouvé ça:

Il se trouve que cette erreur arrive quand MySQL n’a plus d’espace disque disponible… En effet, le script – buggy – ne supprimais plus les vieux backups lors de la création de nouveaux. J’en suis vite arrivé a saturer ma partition temporaire. Erreur de débutant !

Pour me rendre d’autant plus utile, voici un petit script pour monitorer l’espace utilisé sur vos disque, il enverra un mail en cas d’utilisation d’une partition a plus de 95%.

A ajouter dans vos crontabs:

Sur ce, je peux reprendre un activité normale.. détendu !

Ce billet contient deux parties : la première explique succinctement les solutions et commandes pour pouvoir effacer toutes les données d’un disque (ou d’une partition). La deuxième approfondit les commandes et outils utilisés dans la première — Je me rend bien compte, après relecture du fait que j’ai pas mal dérivé dans l’écriture de cet article, il faut croire que j’avais beaucoup à dire.. donc si vous avez le temps, servez vous un café et profitez en bien.

Update le 6 Mai 2009: Correction des fautes d’orthographe…

ATTENTION: Toutes les procédures ci-dessous sont définitives et non réversibles. Après avoir exécuté ces commandes, vous (ou un tiers) ne pourrez JAMAIS récupérer les informations qui y étaient stockées.

Info: Dans ce billet j’utiliserais comme chemin pour mon disque dur a effacer : /dev/sdX, il vous faudra naturellement le remplacer par le vôtre. Vérifiez toujours d’abord vôtre table de partition avec « df » (utilitaire sans risques, il permet simplement de lister les disques montés sur vôtre système – NDLR : fstab)
Suivant la distribution *nix que vous utiliserez vous ne pourrez sûrement pas directement réinitialiser le disque système : il vous faudra utiliser un « live CD » ou booter sur un autre disque dur.

1. L’utilitaire « dd »:

L’utilitaire « dd » fourni avec tous les *nix et dérivés, permet de faire de nombreuses manipulations sur des fichiers ou des systèmes de fichiers comme (liste non exhaustive): Formatter une disquette à partir d’une image, découper un fichier en plusieurs morceaux, faire une image d’un DVD ou encore — et c’est ce qui nous intéresse ici — détruire les données d’un disque dur en le remplissant de zéros ou de données aléatoires.

Il faut toujours faire attention lorsqu’on utilise dd. Le simple fait d’oublier une option ou d’échanger les arguments aura des conséquences désastreuses.

1.1 Méthode rapide et peu sûre :

La première méthode consiste à écrire des 0 sur tous les secteurs du disque en une seule passe :

L’argument « conv=notrunc » permet de ne pas limiter la taille du fichier de sortie.

1.2 Méthode lente et moyennement sûre :

La seconde méthode, un peu plus sûre que la précédente consiste en l’utilisation du périphérique générateur d’aléatoires du noyau. Ce qui aura pour effet d’écrire des données aléatoires sur tous les secteurs du disque :

1.3 Méthode très lente et sûre:

Ici nous allons utiliser la première méthode, mais avec 32 passe.. De quoi vraiment tout effacer.

Notez qu’ici j’ai défini le paramètre « BS » qui correspond au nombre d’octets spécifié écrit en une seule fois. Ce qui permet de raccourcir considérablement le temps de chaque passe.

1.4 Méthode vraiment très lente et très sûre:

Pour cette dernière solution, vous l’aurez déduit par vous même, 16 passes de random, de quoi effacer définitivement n’importe quel octet sensible ! Suivant la taille du disque/partition, cette solution peut prendre énormément de temps…

Approfondissements :

Temps des opérations — Optimisations

Voyons comment se comporte dd pour un fichier test de 100Mb avec notre solution n°1 et un Block size de 1:

1 * 102400000 = 100Mb, dd a mis environ 7 minutes 38 secondes, pitoyable, pourquoi ?!

Petites précisions indispensables au sujet des secteurs (ou blocs):
Un secteur (ou bloc) est une subdivision d’une piste de votre disque dur. Chaque secteur peut stocker un nombre bien défini de données — les disques magnétiques fournissent généralement un espace de 512 octets (ce n’est pas le cas des SSD). La notion de bloc a été utilisée au début de l’informatique pour ce petit morceau de données, mais le terme secteur est devenu beaucoup plus courant. Puis peu à peu, « bloc » est devenu plus employé pour définir un certain nombre de données (variable) utilisé par un processus. Par exemple, le programme dd qui permet de définir la taille de bloc à utiliser lors de l’exécution avec le paramètre BS (= octets). En réalité, ça ne change pas la taille du secteur d’un support, seule la taille des données qui seront manipulées.

Notez que pour un CD, la taille d’un secteur est de 2.048 bytes (par exemple, si vous avez besoin de créer une image iso, tapez : dd if=/dev/hdc of=/tmp/mycd.iso bs=2048 conv=notrunc).

Reprenons — comment puis-je vérifier la taille des blocs sur un BSD ?

Et sur un GNU/Linux ?

Notez que sur le deuxième exemple, le système de fichier est en fait monté sur un RAID, d’où la réponse de BS de 4k.

Bien, maintenant que nous savons, essayons en spécifiant un BS de 512:

512 * 200000 = 100Mb, dd a mis à peine plus d’une 2,4s (contre 7m38) — la différence est énorme, pourquoi ?

En fait, l’explication est simple, c’est la synchronisation entre les données envoyées et les données écrites. Des blocs de 512 octets sont envoyés au disque et sont directement écrits sur les secteurs correspondants ; inutile de mettre en cache 512 fois 1 octet pour pouvoir écrire notre bloc. Et si on spécifie un BS supérieur, me direz-vous ? Essayons.

En effet, cela ne nous apporte rien ! notez que j’ai spécifié bs=512, mais en fait dd utilise par défaut le block size de 512.

/dev/zero, /dev/random ou /dev/urandom ?

Pour cette partie, je me suis largement inspiré des manpages de random que j’ai agrémentée d’exemples et quelques précisions.

Les fichiers spéciaux /dev/random et /dev/urandom existents depuis Linux 1.3.30 et ils fournissent une interface avec le générateur de nombres aléatoires du noyau. Il faut savoir que le noyau identifie chaque périphérique au moyen de deux numéros, le majeur (à gauche) et le mineur (à droite), ex:

Le fichier /dev/random a un numéro de périphérique majeur égal à 1, et un numéro mineur égal à 8. Les numéros du périphérique /dev/urandom sont 1 pour le majeur, et 9 pour le mineur et pour zero ils sont respectivement de 1 et 5. Ils sont de type c (Character), ils communiquent octet par octet (comme un port série) à l’inverse des disques durs qui sont de type b (Blocks) et qui – donc – communiquent par blocs de données.

Ce que l’on peut lire dans la documentation de noyau Linux a leurs propos :

1 char Memory device
    ...
    5 = /dev/zero        Null byte source
    ...
    8 = /dev/random   Nondeterministic random number gen.
    9 = /dev/urandom Faster, less secure random number gen.
    ...

En réalité, le générateur de nombres aléatoires récupère les séquences aléatoires en fonction du « bruit » généré par l’environnement : mouvement de la souris, frappe au clavier, etc.. Le générateur mémorise également une estimation du nombre de bits de bruit dans son réservoir d’entropie, et utilise son contenu pour créer des nombres aléatoires.
En effet, lors d’une lecture, le périphérique /dev/random sera limité au nombre de bits de bruit qu’il contient.
/dev/random est particulièrement adapté pour des cas où l’on a ponctuellement besoin de nombres hautement aléatoires (création de clés par exemple). Lorsque le réservoir d’entropie est vide, les lectures du périphérique /dev/random seront bloquantes jusqu’à l’obtention de suffisamment de bruits en provenance de l’environnement. Dans notre cas – ou l’on a besoin d’une très grande quantité de données —, nous risquons d’être très rapidement limité ! Heureusement, /dev/urandom renverra autant d’octets qu’on en demande. Toutefois, s’il n’y a plus assez de bits disponibles dans le réservoir d’entropie, les valeurs renvoyées pourraient être théoriquement vulnérables à une cryptanalyse basée sur l’algorithme employé par le pilote. Il n’existe pas de documentation sur ce type d’attaque dans la littérature publique actuelle, mais cela n’élimine pas le risque théorique.

Le fichier de périphérique /dev/zero quand a lui, se comporte comme s’il contenait une infinité d’octets à ~0. Quelle que soit la quantité de données que vous essayez de lire à partir de /dev/zero, il générera suffisamment d’octets nuls.

En résumé, nous allons plutôt utiliser /dev/urandom ou /dev/zero, sinon ça va prendre un temps fou. /dev/random donne de l’entropie « forte » (liée au matériel) et ne donne donc que quelques octets par seconde. /dev/urandom complète cette entropie forte avec du PRNG et génère donc les données aussi vite que nécessaire, ou presque..

Dans le cas d’un effacement de disque dur, ce risque nous importe peu, mais je trouvais intéressant d’en parler.

Petites précisions pour les BSD Users:
1) Le générateur de bruit random a été remplacé par un générateur cryptographique nommé « Yarrow algorithm » ;
2) /dev/urandom est un lien symbolique sur /dev/random.
3) Les numéros mineurs et majeurs ne sont pas les mêmes, ex:

Vérifications

Pour vérifier l’oeuvre de la commande dd couplée à random, nous allons utiliser « hexdump » (sur un fichier de 64b, pour une question de lisibilité).

Utilisons « zero » comme générateur:

Quand à utiliser « random », voici le résultat :

Vous pourrez, naturellement vérifier le résultat en situation « réelle » grace a la commande suivante :

Note finale

Il existe des logiciels comme « Shred » qui offrent des solutions « clés en main », mais qui au final ne font que ce que vous auriez très bien pu faire avec « dd » (un nombre X de passes random puis finir sur une « zero »), ex:

Les deux lignes suivantes font la même chose:

sachant que – pour un disque de 500Go – dd a été le plus rapide chez moi.

Il existe un ensemble d’outils nommé « secure_deletion toolkit », mais il n’est pas encore porté sur toutes les plates-formes. Par exemple, l’outil « sfill » pousse l’effacement sécurisé des fichiers à son paroxysme :

* Une passe avec 0xff
* 5 passes aléatoires avec la source /dev/urandom
* 27 passes avec des valeurs spéciales définies par Peter Gutmann. (Je vous invite d’ailleurs a lire son article très complet si vous voulez en savoir plus.)
* A nouveau 5 passes aléatoires.
* Une passe avec 0×00.

Il est peu être possible de lire « à côté des pistes », des résidus magnétisés et de retrouver ainsi des données écrites préalablement en décalant les têtes et peut être existe’il d’autres méthodes dont nous n’avons pas connaissance alors il reste une solution universelle et radicale : La destruction physique. C’est la seule solution réellement viable et irrécupérable : Perceuse, Masse, Acide et j’en passe..

Le générateur random et l’utilitaire dd sont disponibles sur énormément de distributions : Solaris, Mac OS X, FreeBSD, HP-UX, Tru64, AIX et j’en passe.

Suite au retours sur le tutoriel XDMCP, J’ai donc publié sa suite logique.. l’autre façon, plus adaptée au grand réseau Internet d’avoir accès à une session X distante. J’ai nommé NXFree. Le but de FreeNX est d’exporter un bureau graphique complet sur un poste distant en utilisant une bande passante minimum. FreeNX reposant entièrement sur un serveur SSH, il faut également qu’un serveur SSH soit opérationnel sur le serveur. Ceci n’est une solution complètement libre.. mais simple.

Serveur Linux

On aura aussi besoin de cette libraire:

Il faut donc ajouter la ligne suivante au fichier « /etc/apt/sources.list » :

Installer la clé gpg :

Mettre à jour la liste des paquets

Client Mac: Le client NX Free.

Si vous avez retenu le choix numéro 1, les paquets « officiels », placez vous dans le répertoire ou vous avez téléchargé les fichiers ci dessus, puis:

Si vous avez retenu les choix des dépôts Ubuntu:

A la question des clés, sélectionnez: « NoMachine Keys ».

Gestion des clés

Editez le fichier sshd_config:

Et assurez vous que l’utilisateur « nx » ai bien le droit de se connecter via ssh. Si vous avez défini un « AllowUser ».. sinon passez directement à la suite.

Ici, si vous rencontrez une erreur du type: « ssh_exchange_identification: Connection closed by remote host », Au lieu de chercher pendant une heure d’où viens le problème.. regardez tout d’abord votre /etc/hosts.deny.. pour voir si le loopback (127.0.0.1) n’y est pas interdit.. ça vous évitera une prise de tête sans noms..

Je ne vais pas vous la détailler tellement elle est simple.. amusez vous bien ;)

Autant vous le dire tout de suite, je ne n’aime pas les interfaces graphiques sur les serveurs.. d’ailleurs j’ai déjà emm** pas mal de monde avec mes idéos, ça bouffe de la mémoire et du réseau pour rien. Mais bon.. Je me trouve aujourd’hui confronté à un problème sur un de mes projets difficilement resolvable sinon en installant un serveur X sur mon serveur. Put** de capcha.
Je vais donc essayer de vous expliquer, ici, comment mettre en place une liaison Serveur X linux déportée sur un mac.

ATTENTION, Suite à certain retours, je tiens a préciser que ce n’est pas la meilleure solution pour administrer un serveur hebergé sur le net. c’est une très bonne option en LOCAL, pour du DISTANT, ce n’est à utiliser que très ponctuellement. Pour ceux qui aurais besoin d’avoir accès aux application x d’une machine distante il existe NX. (avec son client Mac, ici). J’essayerais de vous publier un tutoriel sur le sujet, bientôt. Sur ce, amusez vous bien ;)

Sur le serveur: xdm et un environnement graphique (j’ai choisi icewm pur sa légèreté, mais n’importe lequel fera l’affaire)

Sur votre mac: il vous faudra installer X11, vous le trouverez sur le CD1 d’installation du système Tiger ou Léopard (avant, je ne sais pas.. Quelqu’un saurait me le dire ?). Cherchez « Optional Installs.mpkg » et sélectionnez X11 dans le menu.

Configuration de Ssh:

Editez le fichier de configuration:

Modifiez ces deux ligne:

Puis relancez le tout:

Configuration de xdm

Editez le fichier de configuration:

Modifiez cette ligne (pour définir le port 177 en écoute)

Editez le fichier d’autorisation d’accès:

Décommentez la ligne suivante:

On sécurisera via iptables.

Configuration de IPTables:

Ici on va ouvrir les ports nécessaires:

Ici j’ai remplacé mon Ip par x.x.x.x, mettez la votre. (celle du Mac)

Pensez a ouvrir ces ports sur votre routeur local.. su vous en avez un !
- Port 177/UDP (XDMCP)
- Port 6000 à 6015 (X11)

Utilisation:

Sur le Mac, ouvrez un terminal et tapez ceci (remplacez l’ip de mon serveur par celle du votre, ici c’est celle de crashdump.fr ;)):

X11 devrait se lancer.. en attente d’un connexion.

Connectez vous ensuite sur votre Box linux en ssh, puis:

Replacez le x.x.x.x par l’adresse Ip de votre Mac.

Il ne vous reste plus qu’a lancer l’application en question.. pour la voir apparaître sur votre mac ! Exemple:

Et la magie opère ! ;)

http://misc.crashdump.fr/~polux/files/logcolorise-1.0.7.tar.gz

Pour l’installer, rien de plus simple:

Et enfin, pour en profiter:

Après quelques recherches sur « db_recover » et après avoir essayé de lire les pages man introuvables… je me lance à la sauvage:

Le service repart, puis s’écroule quelques minutes plus tard en m’insultant de la même façon. Seule option restante: Récupérer les .bdb stocké sur la bande de sauvegarde de la veille:

A la recherche de mes fichiers:

Ouf, tout est là: On restaure.

Si, comme moi, vos fichiers font plus de 2Go, allez donc boire une cafetière de café.. ou prendre un Xanax..

Je vous passe le tas de logs qu’il m’a vomi à ce moment précis -c’est plutôt bon signe- il est enfin lancé… et à l’air de s’y plaire. Attention à ne pas le stopper à l’aide d’un CTRL+C, ce qui pourrais causer une nouvelle corruption ! Pour cela on va lui demander plus poliment:

Puis on relance, proprement:

Note: n’oubliez pas de vérifier que les fichiers contenus dans le répertoire /var/lib/ldap appartiennent bien à ldap:ldap après la restauration, c’est du vécu..

Sachant que le serveur mail est Postfix.

En quelques lignes cela pourrais se répondre: man aliases, RTFM, mais je ne suis pas un salop, alors je vais vous décrire la solution que j’ai trouvé.. ;)

Le fichier aliases de Postfix permet, comme son nom l’indique, de créer des alias et donc de ridiriger tout les mails pour les comptes locaux. Ce fichier est un bête fichier texte qui, une fois modifié servira a postalias pour créer un .db. Il faudra donc le modifier en respectant une syntaxe particulière, le sauvegarder, puis l’exporter avec la commande « newaliases ». Mais rentrons directement dans le vif du sujet:

Le fichier accepte un format bien précis, de la forme suivante:

Exemple: Mettons une adresse grouik@crashdump.fr dont j’aimerais envoyer une copie de tout les messages à patate@crashdump.fr et à dindon@crashdump.fr (ça fait moins serieux, du coup!) mon fichier aliases ressemblera donc à ça:

Notez que j’ai répété grouik dans les destinataires, sinon il ne recevra plus les message qui lui sont destiné.

Un petit programme se charge de tout:

astuce: si vous avez beaucoup de destinataires, vous pouvez les écrire sur plusieurs lignes en commençant les lignes suivantes par un espace.

Merci de votre lecture, et n’hésitez pas a poser vos questions dans les commentaires. J’y répondrais le plus vite possible.

/etc/ssh/sshd_config ou /home/$USERNAME/.ssh.config

ServerAliveInterval
Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server. This option applies to protocol version 2 only.

ServerAliveCountMax
Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session. It is important to note that the use of server alive messages is very different from TCPKeepAlive (below). The server alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The server alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive.
The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds. This option applies to protocol version 2 only.

Si cela ne fonctionne toujours pas, il vous reste AutoSSH…

Ces lignes ont été retirée parce qu’elle produisait des erreurs avec certains outils (Utilisation d’une donnée non initialisée dans la plupart des projets liés a OpenSSL). Mais la suppression de des lignes en question à eu des effets collatéraux sur OpenSSL PRNG. En fait au lieux de mélanger différentes variables aléatoire pour la génération initiale, la seule variable « aléatoire » qui a été utilisée étais le PID du générateur -et quand on sais que le nombre maximal par défaut sous linux est de 32,768- le résultat est que PRNG utilise une très petite fourchette de valeurs initiales.

Impact:

Toutes les clés SSL et SSH générées sur des systèmes basé sur Debian (Ubuntu, Debina, Mint…) entre Septembre 2006 et le 13 Mai 2008 sont affectée par la vulnérabilité. Dans le cas des clé SSL, tout les certificats doivent être révoqué et a nouveau généré. Tous les administrateurs système doivent auditer leurs clés pour être sur qu’ils ne sont pas touché par la vulnérabilité ! D’ailleurs tout les outils liés de près ou de loin a OpenSSL PRNG peut être vulnérable, attention.

Tout flux d’un serveur SSH qui utilise une clé générée par un système vulnérable peut être sujet a une interception (man in the middle) sans que l’administrateur ne se rende compte de rien. Je vous rassure, les projets Debian et Ubuntu on développé des outils pour identifier les clé vulnérables, vous trouverez plus d’information a leurs propos en fin de page.

Q: Combien de temps cela prendrais de générer toutes les clés touchées ?
A: Avec 31 Xeon @ 2.33Ghz. Cela prend deux heures pour les clés DSA 1024-bit et RSA 2048-bit pour x86. Les clés RSA 4096-bit sont générés en 6 heures. En ce qui concerne les clés RSA 8192-bit cela prendrais environs 100 heures.

Q: Combien de temps cela prendrait il de cracker un SSH avec ces clés ?
A: Tout dépend de la vitesse du réseau et de la configuration du serveur SSH. Il devrait être possible d’essayer toutes les clés (32,767 DSA 1024 et RSA 2048) en quelques heures. Attentions aux scripts tels que Fail2Ban (anti-bruteforce).. etc.

Q: J’utilise une clé RSA 16384 bit, suis-je vulnérable ?
A: Oui, c’est juste une question de temps (processeur et réseau). Pour le RSA 8192 bit, cela prend environ 3100 heures pour générer toutes les clés. J’imagine que pour le 16384 bit, nous serions dans les 100,000 heures (en temps CPU). Mais gardez en tête que la « fourchette » réele est bien plus mince, basée sur PID du processus qui a servit a générer le tout. Donc, inutile de générer toutes les clé pour en couvrir la majorité ! (La plupart de ces clés sont dans les premiers 3,000 PID)..

http://www.debian.org/security/key-rollover/
http://wiki.debian.org/SSLkeys

Parfois, il arrive que les fichiers de cache soit corrompus.. soit ! Il suffit de les purger !

et c’est reparti !

Et que vous êtes dans l’impossibilité de la supprimer, voila la solution:

..et dire que c’est même pas écris dans les man pages.. Voila qui m’a donné envie d’écrire un tutoriel sur route ! a bientôt ;)

Un tutoriel de mise a jour du kernel par dedibox: http://documentation.dedibox.fr/doku.php?id=distrib:kernel&s=noyau

La faille a été corrigé par les équipes de sécurité de la plupart des distributions.
Aussi peut être pensez vous comme moi qu’un simple (pour debian)

Pourrais vous mettre à l’abri… Malheureusement chez dédibox il est optimisé pour C7, donc spécifique. Pas de panique ça reste assez simple a corriger quand même.

La manipulation pour corriger la faille est décrite ici:

Je l’ai testé sur une testing:

Si vous avez installé votre dédibox avant le 28 Mai 2006 (ou si vous possedez une version raid), cette partie ne vous concerne pas !
Sinon, distributions Ubuntu-Server, Ubuntu Dedibox et Debian Sarge comportent un bug dans le comportement de grub-install. On va donc patcher grub.

On cherche sur quelle partition est “/” (pour savoir sur quel disque on boot):

Ce qui devrait vous retourner quelque chose du genre:

C’est ce sda1 qui nous intéresse.. c’est le disque sur lequel boot votre machine !

On va donc lancer le script téléchargé précédemment, avec comme paramètre sda1 (dans notre cas, sinon remplacez par la bonne valeur):

Le script va modifier le fichier: /boot/grub/menu.lst pour y entrer les bonnes valeurs. Si un problème survient par la suite, le script créé une sauvegarde de ce fichier ici: /boot/grub/menu.lst.bak

Mise a jour du Kernel

On le télécharge:

Puis on l’installe :

On met a jour grub:

Tout va bien il a trouvé notre noyau.. donc on reboot:

Prennez un café… puis on vérifie:

Ipv6 Activé ?

Il faut impérativement penser que l’IPV6 est activé et qu’il faut mettre les règles adoc pour filtrer un minimum.
Personnellement, j e n’utilise pas « encore » ipv6 donc j’ai entré ces règles dans mon script iptables/ip6tables :

C’est bon, je peut donc aller me recoucher, en paix. ;)

On commence par telecharger et installer l’appli:

Configurer Exim4

Ouvrir le fichier de configuration exim4 concernant la configuration des options (attention, suivant le type d’installation d’exim le fichier de configuration peut ne pas se trouver au même endroit, en effet il existe une installation avec un fichier de configuration unique et un type d’installation avec un fichier .conf unique) donc:

Et décommenter la ligne suivante:

Configurer spamd

Editer le fichier config:
# vim /etc/default/spamassassin

Demmarer SpamAssassin

Mise a jour automatique

Et pour finir, on va mettre en place une mise à jour (via cron) de spamd… Pour cela:

PT fut conçu à l’origine pour fonctionner avec des paquets .deb sur des systèmes Debian, mais a depuis été adapté pour fonctionner avec des paquets Red Hat Package Manager avec l’outil apt-rpm, et pour fonctionner sur d’autres systèmes d’exploitation tels que Mac OS X (voir Fink). Sur les systèmes avec une gestion de paquets basée sur le format .deb, comme Debian, APT est une interface à dpkg.

APT simplifie l’installation, la mise à jour et la désinstallation de logiciels en automatisant la récupération de paquets à partir de sources APT (sur Internet, le réseau local, des CDs, etc.), la gestion des dépendances et parfois la compilation. Lorsque des paquets sont installés, mis à jour ou enlevés, les programmes de gestion de paquets peuvent afficher les dépendances des paquets, demander à l’administrateur si des paquets recommandés ou suggérés par des paquets nouvellement installés devraient aussi être installés, et résoudre les dépendances automatiquement. Les programmes de gestion de paquets peuvent aussi mettre à jour tous les paquets.

Il n’existe pas de commande apt en tant que tel. APT est essentiellement une bibliothèque C++ de fonctions utilisées par plusieurs programmes de gestion de paquets. Un de ces programmes est apt-get, probablement le plus connu.

Installer

, Installe [package]

, Simule l’installation de [package]

, Réinstalle [package]

, Installe la version de [package] de la distribution [package]

, Installe [package] dans la version [version]

, Télécharge le package source

, Télécharge le package source et le compile ensuite

, Télécharge les dépendances du package source qui va etre compilé

Désinstaller

, Désinstalle [package] et tous ceux qui en dépendent

, Désinstalle aussi les fichiers de conguration

Mettre jour

, Affiche la liste des packages pouvant etre mis jour

, Mise jour de la liste des packages disponibles

, Liste et met jour les packages pouvant Etre mis jour

, Met jour tout le système

Nettoyer

, Vide le /var/cache/apt/archives

, Enleve uniquement les packages obsolétes

S’informer

, Cherche dans la liste des packages disponibles les occurences de [foobar]

, Description de [package]

, Dépendances de [package]

, Affiche le nom du package qui fournnit [fichier]

, contenu de [package]

, Mise jour de la base de données de apt-le

Configurer

, Reconfigure [package]

Cloner

, Liste des packages installés danns le chier selected

, Sélection des packages répertoriés dans le chier selected

, Installation des packages sélectionné par dselect ou directement par dpkg

La fork bomb est un programme se dupliquant a l’infini. Si l’on prend en compte que le nombre de processus pouvant être exécutés simultanément sur un ordinateur est limité, vous comprendrez vite ou cela nous mène !

Comment elle fonctionne exactement ?

Comme je vous l’ai dit plus haut, Elle créé un grand nombre de processus très rapidement afin de saturer le nombre de processus maximum du système. Si la table des processus est saturée, aucun nouveau programme ne peut démarrer tant qu’aucun autre ne termine. Et encore, même si cela arrive, il est peu probable qu’un programme utile démarre étant donné que les instances de la bombe attendent chacune d’occuper cet emplacement libre. Bref, la misère.

Résultats ?

Non seulement les fork bombs utilisent de la place dans la table des processus, mais elles utilisent chacune du temps processeur et de la mémoire. En conséquence, le système et les programmes tournant à ce moment-là ralentissent et deviennent même impossibles à utiliser. Pour peut que les processus lancés soit un peut gourmand en mémoire, le système peut rapidement swapper et occuper toute la mémoire virtuelle (SWAP). Les fork bomb peuvent donc être considérées comme des virus non destructifs… Bien que énervants.

Exemples:

En Perl:

en Bash :

Via .Bat, ms-dos:

En C:

En HTML:

forkbomb.htm:

Difficulté

Une fois la fork bomb lancée avec succès dans un système, il peut devenir impossible de retrouver un fonctionnement normal sans redémarrer, étant donné que la seule solution à une fork bomb est de détruire toutes ses instances. Essayer d’utiliser un programme pour tuer les processus requiert la création d’un processus, ce qui peut être impossible s’il n’y a pas d’emplacement vide dans la table des processus, ou d’espace dans les structures mémoires.

Prévention

La fork bomb fonctionne en créant autant de processus que possible. Ainsi, pour empêcher une fork bomb, il suffit simplement de limiter le nombre de processus pouvant être exécutés par un programme ou par un utilisateur. En permettant aux utilisateurs de lancer seulement un petit nombre de processus.

Protection

J’aborderais uniquement la solution sous linux, sachant que je ne connais que celle la. :)

Les systèmes de type Unix permettent de limiter le nombre de processus via la commande ulimit.

Simple: utilisez la commande grep. (les fichiers doivent se trouver dans le même répertoire), pour rechercher la chaîne « texte », il faut faire :

Sinon, si les fichiers se trouvent dans une arborescence:

rechercher à partir du répertoire courant:

on cherche un fichier:

on execute une commande à chaque fichier trouvé:

recherche de « texte » dans les fichiers ( {} vaut le nom des fichiers trouvés):

fin de l’option exec:

Ceci dit, si vous avec une recherche a faire sur tout le sytème une petite modification sympose:

on affiche le chemin du fichier dans lequel a été trouvé le texte

vous evitera tous les messages d’erreurs a propos de permissions non accordées..

Exemple : téléchargement d’un site web

Téléchargement en local, tout le site de aemeth.org en une seule ligne :

Explication des options :

-r : récursif

-k : corrige les chemins pour que les liens en local ne soient pas cassés (très utile pour moi qui commence toujours mes liens par un / pour recevnir à la racine du site)

-p : page : se débrouille pour télécharger un max de trucs qui font que la page html sera correctement visible. (j’ai pas tout compris mais ça semble aider à avoir un bon mirroir local)

-E : rajoute .html à la fin de tout ce qui est téléchargé avec un type text/html mais dont le nom ne termine pas par .html. C’est formidable, car cela permet qu’un site tel que le miens, dont les pages n’affichent pas leur extentions, soient consultables off-line, depuis un disque dur.

Voila, en une seule instruction, vous avez téléchargé un site entier.
Télécharger un dossier et ses sous-dossiers

Pour télécharger un site qui se trouverait seulement dans un répertoire, sans déborder de se répertoire, voici l’instruction :

-np : no-parent : reste à l’intérieur du répertoire donné et n’en déborde pas.
Autres fonctionnalités

wget est vraiment bien foutu car il :
- comprends ssl et peut donc naviger sur les sites sécurisés
- comprends les cookies
- accepte les login/pwd pour se connecter à des sites privés
- accepte les proxies
- accepte le time stamping

1. Le prompt bash et la manipulation des titres des fenêtres
2. Navigation dans les répertoires en ligne de commande et les alias
3. L’historique et le complètement avancé avec bash
4. Les entrée/sorties, leur redirection et les motifs du shell

Ce billets est quant à lui consacré à l’enchaînement de commandes, au contrôles des tâches (jobs) puis à deux petites astuces bien pratiques à utilisées sans modération. Je pense que ce billet est le dernier de cette série, les prochains autour du shell seront probablement sur les scripts et diverses astuces plus ou moins pointues comme les deux présentées à la fin de ce billet.

Enchaîner les commandes

L’utilisation probablement la plus courante d’un shell consiste à taper une commande, regarder sa sortie ou son résultat et éventuellement recommencer en fonction du résultat précédent. On peut aussi vouloir exécuter plusieurs commandes à la suite. Pour cela, on peut écrire un script ou une fonction bash (ce sera probablement l’objet d’une prochaine série de billets) mais il est aussi possible de le faire en mode interactif.

Plusieurs commandes à la suite sans condition

Pour éxécuter plusieurs commandes de suite, il est possible de les écrire les unes à la suite des autres en les séparant par un point-virgule, par exemple :

Cette liste de 4 commandes est regroupée sur une ligne, j’aurais aussi bien pu taper chacune d’elle sur une ligne séparée, le résultat aurait été le même. Si l’une d’entre elles échoue, les autres sont quand même exécutées.

Plusieurs commandes à la suite sous condition

Chaque commande lancée renvoie normalement un code de retour. Par convention, un résultat normal (sans erreur) renvoie un code de retour égale à zéro, si quelque chose se passe mal, ce code est différent de zéro et peu avoir différentes significations selon les programmes. La variable $? contient le code de retour de la précédente commande lancée. En séparant des commandes par &&, bash vérifie que la commande a bien renvoyé un code de retour nulle avant d’éxécuter la suivante, sinon il interrompt la suite, exemple :

Cette suite de commande est interrompue après le test -L car son code de retour n’est pas nulle puisque /tmp n’est pas un lien symbolique.

Contrôle des tâches

En ajoutant le caractère & à une commande, celle-ci est lancée en arrière plan tout en restant « attaché » au shell qui l’a lancé. On peut aussi faire passer en arrière plan une commande avec le raccourci Ctrl+z. Pour récupèrer la main sur le programme passé en arrière plan, il est possible d’utiliser la commande fg . J’utilise couramment ce mécanisme lorsque j’édite un fichier à l’aide de vim en ssh et que je me rend compte que je dois lancer une autre commande, je peux alors faire Ctrl+z pour récupèrer le shell, je lance ma commande puis je tape fg pour reprendre la main sur mon éditeur. fg accepte en paramètre un entier qui indique le numéro de la tâche à remettre en avant plan. Ce numéro correspond à l’ordre dans lequel les programmes ont été mis en arrière plan.
Quelques trucs…

Un peu de couleurs avec grep

Les émulateurs de terminal sont capables d’afficher quelques couleurs (en général 16). La configuration par défaut sous la plupart des distributions fait en sorte que ls affiche sa sortie avec des couleurs en fonction du type de fichier ou de son extension. D’autres programmes sont capables d’améliorer leur affichage avec un peu de couleur.

C’est par exemple le cas de grep qui permet de filtrer un texte selon une expression rationnelle en mettant en avant les morceaux de texte correspondant au motif, c’est assez pratique lorsque l’on tente de déchiffrer un fichier de log ou tout autre fichier texte.

Cette ligne permet d’obtenir tous les alias de 2 caractères. Ce qui donne dans mon terminal :

Pour que ce comportement soit systématique, il suffit d’ajouter les lignes suivante dans son fichier ~/.bashrc :

Pour que tout appel à grep (et à egrep) mette en valeur le motif trouvé.

Suivre un fichier de log

tail est un programme qui propose d’afficher les n dernières lignes ou les n derniers octets d’un fichier. Il dispose d’une option -f (pour follow) très intéressante permettant de suivre un fichier pour faire défiler les dernières lignes ajoutées. Cette option combinée à d’autres utilitaires de traitement de texte (cut , sed , grep , …) permet de suivre différents types de journaux facilement, deux exemples courants :

À noter dans ces exemples, l’ajout du paramètre –line-buffered pour indiquer à grep de traiter les données ligne par ligne plutôt que par un buffer plus grand. Cette option permet de ne pas avoir de latence entre le moment ou tail écrit une nouvelle ligne et le moment ou grep la traite.