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.

Alors que je surfouillais sur le web, un samedi après midi, je suis tombé sur un screenshot qui m’as intrigé.. top aurais évolué ? ça y ressemblait bien. Après quelques recherches je suis tombé dessus, le messie du monitoring !

htop est un moniteur système pour Linux, presque le même que top, que nous connaissons tous. Mais qui propose – enfin ? – une interface plus conviviale que ce dernier. Il est programmé en C à l’aide de la bibliothèque ‘ncurses’.

+ htop permet de ‘tuer’ un processus directement, sans se soucier de son PID.
+ htop permet, de la même manière, d’augmenter/réduire la priorité d’un processus dans connaître son PID.
+ htop est plus user-friendly, dans ses raccourcis, et sa présentation, le scroll.
+ htop permet un affichage en arborescence, identifiant clairement les processus pères et fils.
+ htop est plus rapide (sur les 3 machines sur lesquelles je l’ai testé). et vous ?
+ htop gère la souris (mettons de côté les réactions d’extrémiste du clavier..)
+ htop intègre une jauge de l’utilisation de la mémoire vive, cpu et swap (gadget, oui… mais sympa)
- Top est sûrement plus stable et plus précis.. car plus vieux et donc plus testé.

ou http://htop.sourceforge.net/

Attention, je n’ai jamais eu la prétention d’être un expert dans ce domaine, je vais donc seulement vous parler de ce je connais.. (les bases). Lire cet article ne vous rendra pas aussi populaire que Kevin Mitnik ou assimilé. De plus c’est un domaine très vaste et en constante évolution. Un bon administrateur saura se tenir informé et devra s’y intéresser: http://www.securityfocus.com/, http://www.linuxsecurity.com/… seront de bonnes sources d’inspiration :)

l’Installation

Tout d’abord je vais supposer que vous savez installer la distribution qui vous intéresse et que c’est fait – beau raccourci, hein ! – Mais sans X11.. parceque-c’est-moche-et-que-je-suis-un-l33t ? Non. Mais dans ce tutoriel, je ne l’aborderais pas.

Règle n°1: Si vous n’avez pas besoin de quelque chose (services, applications..) ne l’activez pas ! C’est très important, la raison est simple: Plus vous avez de services activés, plus vous encourez le risque d’être vulnérable a un exploit… Un chemin royal pour qui en voudrait a vôtre machine.

Verrouillage

Première étape pour sécuriser vôtre serveur, plusieurs choses importantes:

Changer le mot de passe root: J’insiste sur ce point, mais je vois trop souvent de mot de passes composés de quelques lettres ! Dans la plupart des cas, il devra être composé d’au moins 12 caractères dont 4 spéciaux (%*/;…) et 4 numériques. ex: Rv1-45/o;.V6 qui est considéré comme fort. Hey, vous au fond ! Inutile de l’écrire sous le clavier, juste un petit effort pour le retenir.. ;)
De plus, le changer régulièrement c’est pas une mauvaise chose.. tout les 2 mois par exemple.
Sachez qu’il existe des application qui peuvent « scanner » vos machines pour essayer différents mot de passes a partir de « dictionnaires », donc évitez la date de naissance de votre belle-mère.
Pour ce qui est des scanners (brute-force) nous verrons, plus tard comment s’en protéger un minimum.

Pour changer votre mot de passe root:

Pour changer le mot de passe de l’un de vos utilisateurs:

Désactiver les suid: Parfois très pratiques – et très dangereux – le SUID (« Set User ID ») vous permet de faire fonctionner une application en tant qu’autre utilisateur. Imaginez que quelqu’un ai accès a l’une de ces applications (via un shell, apache).. et puisse lire votre /etc/shadow.. toute la sécurité de votre serveur serait compromise.

Pour trouver tout les binaires qui utilisent un SUID, tapez la ligne suivante:

NOTE: Le « s » signifie que le fichier est SUID.

La plupart des administrateurs systèmes recommandent de désactiver les services comme « ping » ou traceroute » (lorsque vous n’en avec pas besoin).. Je vous conseillerais de désactiver, dans ce cas: chage, chfn, chsh, mount, umount, gpasswd, usernetctl, traceroute, traceroute6, newgrp, ping6, ping.

Désactiver le SUID sur ces binaires empêche tout autre utilisateur que le propriétaire de l’exécuter (tout en sachant que la plupart de ces services aurons besoin d’être exécuté en root pour fonctionner)

# -> Loggué en tant que root.
$ -> Loggué en tant qu’utilisateur (wowsvr, ici)

Si vous n’avez pas déj� installé Mysql sur votre serveur:

Puis on se connecte sur ce serveur:

La, on va créer un utilisateur ascent, une base de son nom et les 3 tables puis lui alouer les droits dessus:

On recharge les privilèges et on quitte:

Tout d’abord, installons les outils dont on aura besoin par la suite:

Puis ajoutons l’utilisateur qui fera ‘tourner’ le serveur:

Rapatrions les derniers fichiers de Ascent sur notre machine:

On configure:

(j’ai eu des soucis de compilation avec gcc4.2.. par contre nickel avec gcc4.1)
# aptitude install gcc-4.1 gcc-4.1-base
# update-alternatives –install /usr/bin/gcc gcc /usr/bin/gcc-4.1 40 –slave /usr/bin/g++ g++ /usr/bin/g++-4.1
(update-alternatives –config gcc pour changer de version de gcc/g++)

On compile:

Et on installe:

Passons maintenant a la configuration – Attention, ici je vous ais détaillé la configuration minimale pour que le serveur fonctionne, mais je vous invite a lire les fichiers, ils sont très détaillés et compréhensibles)

Editez les lignes suivantes (pour passer en mode édition tapez: « i » et « Echap » pour quitter le mode. Pour sauvegarder tapez: « :wq! »)

Bon, la on a déj� fait un grand morceau du chemin! Allez courage !

On crée les 3 dossiers qui vons contenir les maps, les vmaps et les DBC

Je met a votre disposition les fichiers que j’ai pu trouver sur le net:
DBC: http://www.megaupload.com/fr/?d=QF5KGDWH ou http://www.megaupload.com/fr/?d=EY3C7NLV
maps: http://dl.free.fr/iHWpvBSjy/maps.rar ou http://www.megaupload.com/fr/?d=657UAN8X
vmaps: http://dl.free.fr/kjaMn7jDb/vmaps.rar ou http://www.megaupload.com/?d=ZPTMQYY3 ou http://www.megaupload.com/?d=BPNLKG40
a copier dans les 3 dossiers qu’on a créé ci-dessus…

Bon maintenant, on va creer la structure des tables:

Puis on va appliquer les mises a jours – attention, il peut y avoir des erreurs, ignorez les.. rien de grave.

Maintenant, on va télécharger une Base de données des PNJ, Mobs, Skills… bref le contenu du jeu !

Puis a l’aide du script fourni, on va l’injecter ! Pour cela, il va falloir configurer un petit peu la moulinette:

Et convertir les fin de lignes format windows ^M au format Linux:

Allez, on lance le tout !

Tapez w
Tapez x

A ce niveau la je ne peut que vous conseiller de jeter un œil au fichier Notes de version, il y aura peut être des correctifs (.sql) a appliquer en fonction de la version utilisée..

Je vous fourni, dans mon extrême gentillesse un script de lancement des binaires:

Collez y ça:

On le rend executable:

A ce stade votre serveur est installé, il ne vous manque plus qu’as ajouter un utilisateur, pour ça,
la solution la plus simple: phpmyadmin. vous pouvez inserer dans la table ‘logon’ vos joueurs.

ça y est, le moment tant attendu est arrivé, on lance le schmilblik:

En option, voila un petit script php qui permetra au joueurs de s’inscrire sur votre serveur !
Il est tard j’en ai un peu marre, alors je vous lache ça en vrac:

Configurez.. enregistrez.. ça roule !
rendez vous sur http://adresse-de-votre-serveur/

N’hésitez pas a commenter le tutoriel si vous avez eu des galères, des trucs-qui-marchent-pas ou simplement un merci ? ça fait toujours plaisir, pour moi et pour ceux qui aurais le même souci :)

iftop

Connectez vous en ssh sur votre serveur
Installez un paquet supplémentaire ( iftop )

Ensuite listez vos interfaces réseau:

Vous renvoie: eth0, eth1, etc…
Ensuite pour monitorer votre interface comme ceci:

Les options de iftop:

Every sysadmin will try its best to secure the system/s he is managing. Hopefully you never had to restore your own system from a compromise and you will not have to do this in the future. Working on several projects to restore a compromised Linux system for various clients, I have developed a set of rules that others might find useful in similar situations. The type of hacks encountered can be very variate and you might see very different ones than the one I will present, or I have seen live, but even so, this rules might be used as a starting point to develop your own recovery plan.

In most cases if you have a system compromise at root level, you will hear that you have to fully reinstall the system and start fresh because it will be very hard to remove all the hidden files the attacker has placed on the system. This is completely true and if you can afford to do this then you should do it. Still even in this case the compromised system contains valuable information that can be used to understand the attack and prevent it in the future.

Here is a short overview of the steps that I will present:

* Don’t panic. Keep your calm and develop a plan of actions
* Disconnect the system from the network
* Discover the method used to compromise the system
* Stop all the attacker scripts and remove his files
* Restore not affected services
* Fix the problem that caused the compromise
* Restore the affected services
* Monitor the system

Don’t panic. Keep your calm and develop a plan of actions.

Ok. You have just found out that you have to restore a hacked system. My first suggestion is to remain calm. Don’t rush and do something you will regret later. Why? Of course you will have to take action as soon as possible, but you can assume that the compromise is probably active for some time and if you act in second 1 or minute 10 this will probably not make much of a difference. If you have experience with such situations and have a proper plan in your mind, go for it, and don’t waste any time. If not, just relax, take 5 minutes to think about what you should do and how to solve this problem.
Example of bad actions during this time: you will rush and kill all the running scripts the attacker has launched and then have a timeout when you will think what to do next… In this time the attacker might see you have discovered him (for example from his irc bot, etc.) and might become upset and clean up the system for you…
Of course you should not go on with your planned trip and take care of this when you get back, I am just saying to use 5-10 minutes to think on this and develop a short action plan. There should be no timeout in your actions and you should always know what is the next step.

Disconnect the system from the network

This might not always be possible. But if you have physical access to the system or even if you are remotely on a system in a datacenter that provides a way to connect from a console (either a regular remote console, or a KVM, or a DRAC card in Dell servers, etc.), then this should be the next step. Connect to the remote console and bring down the network interface.
If you don’t have a remote console, here are some other ideas: you might be able to rent a KVM for a limited time from your datacenter, or you might have to write some iptables rules to block any kind of access besides your own IP.
After this your system will appear down to everyone, including the attacker that will see that the system is completely down.
Discover the method used to compromise the system

This step in my opinion is the most important one and you should not proceed any further until you have a proper answer to the question: “How did the attacker get in?” This step will be probably the most time consuming as the type of attacks can be quite variate. Still if you don’t find out how the attacker got in, then you will risk that you place the system online and he will be able to compromise the system in a matter of minutes. And this time he might not be so nice and you will not have anything to restore… So even if there is not a general method for this, here are some ideas to get you started:

Depending from what tools you have already configured, you need to identify the files uploaded on the system:

* if you have a system like tripwire configured use it to find out what files where added/changed.
* if you don’t have any such system installed, you might have to use the find command to search for the files newer than x days that were added to the system (also changed files in the respective interval).

Who owns the uploaded files?

* finding out the owner of the files will probably show you what application was used to get in. For example files uploaded as the web user will indicate that the web service was used to get in.

Investigate the uploaded files.

* the files that were uploaded on the system might provide valuable information about the attack. For example the attacker might use the same exploit to attack other systems from your compromised server. This can quickly show you what exploit he is using.

Get as much information from the running scripts launched by the attacker.

* as you have seen I have not recommended to stop yet the running scripts that the attacker might have launched. Why? Because they contain invaluable information to identify the attack. Use lsof on them (lsof -p PID) to see useful details. Where are they located? what user owns them? You might find the source of the attack from this information.

Use Rootkit detection tools.

* you might want to run some rootkit detections tools like rkhunter or chkrootkit to quickly identify common attacks.

Investigate system logs.

* with the information gathered by now you might reduce the size of the log information you have to investigate.

Hopefully you have found the source of the attack by now. Again this is very dependent of the type of attack. The most common one you might see these days is an exploit using a vulnerable web application and an attacker that will launch various scripts (irc bots, scanning tools, attacks on other systems, etc.). Still you might see something different like an attacker not launching any script, loading kernel modules to hide its tracks, to make it more difficult to identify or even see the compromise.

Stop all the attacker scripts and remove his files

Once you have identified the cause of the attack you can safely kill all the running scripts launched by the attacker and remove all his files (save them in a different location for further investigation). At this point we no longer need the scripts running as we got the information we could find from them. The system is still unavailable at this point and no service is available to the world.

Don’t forget to clean-up also the locations that the attacker might have entered to start his scripts on system reboot. Look in init scripts, rc.local, cron tabs for this.

Restore not affected services

Once we know the service used for the attack we can stop it and restore the network connection and all the unaffected services the system might provide. For example if the web server was used to get in, we can stop it, and restore other services like mail, dns, to minimize the downtime of the system.

Fix the problem that caused the compromise

Before starting the service used to compromise the system you should fix the problem so this will not happen again once the service is open to the public… Depending on the problem this might involve: patching a vulnerable daemon, upgrading a vulnerable web application (or temporary disable it), writing some special rulers to block it (for ex. mod_security rules might help in case of no patch available for a web application), etc.
Restore the affected services

Once you have fixed the problem you can restart the service used to get inside the system.

Monitor the system

Now is the time to monitor closely the system and see if the fix you have implemented is working. Most certainly the attacker will try to get in again as he will see he has ‘lost’ the system. If you notice any problem stop the service at once and reiterate again to the step to fix the problem (stop the service, fix it, restore it).

Conclusion

These steps are obviously not usable all the time because of the variety of attacks you might encounter, but they can be used as a baseline to develop your own plan of actions. Again in such situations, keep your calm, don’t rush, and work to restore the system based on a clear set of steps.
If you had similar experiences please feel free to share your own tips to help others that might find themselves in such a situation.

Le Prompt

Le prompt est la première chose que l’on voit lors de l’utilisation du shell, il peut donc mettre en valeur des informations importantes. Il doit donc indiquer, au mininum ces information importantes:
- La machine sur laquelle on est loggué
- Le login
- Le répertoire courant
Pour cela j’utilise la configuration suivante soit dans le fichier /etc/bash.bashrc (tous les utilisateurs) soit dans mon ~/.bashrc (l’utilisateur courant) :

Cette configuration fait en sorte d’avoir un prompt bleu, jaune et blanc pour un utilisateur normal et rouge, jaune et blanc pour l’utilisateur root attirant ainsi mon attention sur le fait qu’en root, on ne tape par n’importe quoi… Il m’indique aussi le nom de la machine ainsi que son adresse IP. Ce qui donne :

Pour que vous puissiez customiser votre prompt a votre gout, voiçi la liste des codes de couleurs et de correspondance.

Le titre des terminaux graphiques

De la même manière que le prompt, le titre des terminaux est très utile pour se repèrer lorsqu’on utilise Xorg. Dans un terminal, il est possible de changer ce titre de manière dynamique avec un simple echo, il suffit alors d’utiliser la variable PROMPT_COMMAND pour stocker une commande que le shell éxécutera à chaque affichage du prompt.

Avec ces quelques lignes, les terminaux affiche la même chose que le prompt dans leur titre (sans les couleurs) lorsque le type de terminal commence par « xterm » (ce qui est le cas avec xterm mais aussi gnome-terminal ).

À noter que la seconde partie du case permet de supprimer le beep très énervant beep lorsqu’on est en console sans Xorg.