Krunch a écrit 3959 commentaires

Ca serait quand même une bonne idée de réinstaller tout parce que rien ne garanti qu'une faille locale n'a pas été utilisée pour rootkiter la machine avec un truc qui n'est pas détecté par chkrootkit et compagnie.

Un moyen relativement sûr de faire la réinstallation à distance serait de commencer par compiler CryptCat ainsi que les binaires de base (BusyBox est ton ami) statiquement sur une machine sûre et les uploader sur la machine compromise. S'arranger pour ne plus utiliser que ces programmes. Notamment ne plus utiliser le sshd original qui peut avoir été compromis aussi. Tu devrais pouvoir obtenir un shell par cryptcat avec un truc genre "# cryptcat -e /safe/bin/sh -l -p 1234 -k mekmitasdigoat" et "$ cryptcat -k mekmitasdigoat example.org 1234". De la tu peux faire un chroot qui te forcerait à utiliser, les nouveaux binaires, dans ce cas, ne pas oublier de faire les mknod qui vont bien avant de passer à la suite.

Debootstraper un système Debian de base sur une machine sûre, le mettre sur un système de fichiers qui va bien, uploader la "partition" sur la machine compromise à traver CryptCat, genre "# cryptcat -k mekmitasdigoat -l -p 4321 -q0 > /safe/dev/hda2" et "$ cryptcat -k mekmitasdigoat example.org 4321 < debian-base.ext3" avec hda2 une partition "libre" que tu as démontée préalablement (genre n'importe quoi sauf /, éventuellement la partition de swap si elle est assez grosse, pas oublier de faire un swapoff avant). Maintenant tu peux monter la partition, chrooter vers le nouveau système et installer le bootloader. Ensuite yapluka rebooter et prier.

Si tu réussis, tu peux être raisonnablement sûr que tu as un système de bases propre. Si tu es paranoïaque, tu peux imaginer que le rootkit est au niveau du noyau et qu'il sait réinfecter un nouveau système que tu installes à partir de programmes non compromis ou que le sshd sait infecter les programmes qu'il voir passer de manière à ce qu'ils infectent à leur tour les fichiers qu'ils manipulent ou qu'il y a un daemon caché qui injecte du code malsain dans tous les nouveaux processes qu'il voit apparaitre ou qu'il y a quelqu'un connecté par une backdoor qui surveille ou bien... mais alors ya plus grand chose à faire à part réinstaller vraiment "from scratch".

A l'avenir pour diminuer les risques de compromission complète du système quand un daemon se fait exploiter tu peux mettre un maximum de truc dans des "jails chroot" ou mieux: des machines virtuelles en utilisant User-Mode-Linux par exemple. Par ailleurs le manuel de sécurisation Debian contient plein de trucs intéressants et faire tourner Sarge sur un serveur disponible depuis internet n'est peut-être pas une très bonne idée (oui je sais Woody est pas à jour mais au moins il y a des màj de sécurité et apt-get peut être mis dans un cron sans risque).

Bon amusement :/

Bien entendu je ne saurais être tenu pour résponsable des dégats éventuels causés par l'applications de ce que j'ai décrit plus haut.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ou CARP http://ucarp.org/(...)
Ou du RAID1 (mirroring de disques).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

pourquoi n'y a t-il pas OBLIGATOIREMENT une trace indélébile de ce qui s'est passé. Si le logiciel était un logiciel open source, on pourrait vérifier que tout est normal

Si le logiciel était Open Source ça ne changerait rien: tu peux toujours modifier le logiciel pour pouvoir effacer sans trace (devrait même y avoir moyen d'effacer les traces sans modifier le logiciel) et dire que tu utilises bien la version publiée qui n'a pas cette fonctionnalité. La seule solution que je vois à ce problème ça serait que la base de données des enchères soit publique mais ça pose des problèmes évidents.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

http://gcu.info/(...)
http://undeadly.org/(...) (en anglais)
http://00f.net/(...) (en anglais)

Mais ça remplace pas DLFP, c'est juste un complément :)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Heu je sais pas trop d'où tu sors ton pkg-config mais à mon avis ya des chances que c'est plutôt un truc genre "./configure --with-libmachin=/usr/local/libmachin/" qu'il te faut (suivi du make && make install).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Oui et non, si t'es pas le seul utilisateur de la machine, c'est généralement plus pratique d'installer dans /usr/local.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Encore un détail: si tu mets les permissions qui vont bien à /usr/local, ya moyen de pas passer root du tout pour installer. Evidemment le faire avec ton compte d'utilisateur normal n'est peut être pas une bonne idée non plus mais tu peux créer un compte spécial rien que pour /usr/local et tu fais tes installations à coups de "./configure --prefix=/usr/local/ && make && sudo -u installeur make install".

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Le "./configure --prefix=/usr" pour écraser l'installation existante c'est fort bourrin et potentiellement dangereux. Mieux vaut installer dans /usr/local et régler son PATH correctement pour avoir /usr/local/bin avant /usr/bin.

S'il te faut vraiment un truc dans /usr parce qu'un programme mal foutu en a besoin, tu peux installer dans /usr/local, éventuellement renommer le truc existant dans /usr (genre "mv brol brol.old") et faire un lien symbolique vers le truc qui va bien dans /usr/local ("ln -s /usr/local/brol /usr/brol").

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Le ./configure, il prépare juste à la compilation, il faut ensuite compiler et enfin installer. En général suffit donc de faire ensuite un "make && make install". Pour les paquets que tu installes toi même depuis les sources, il est généralement préférable de les installer dans /usr/local/ (ou /opt ?) histoire de pas avoir trop d'interférence avec urpmi/apt/... En général ça ce fait au configure ("./configure --prefix=/usr/local/"). Pour la désinstallation c'est un peu la foire. Le plus simple c'est probablement d'utiliser stow.

C'est aussi souvent une bonne idée de lire la documentation (ya souvent un fichier INSTALL qui traine) avant de commencer à compiler quoi que ce soit.

http://www.gnu.org/software/stow/stow.html(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tout à fait. Mon mot de passe, c'est tout simplement le nom de mon
chien. Mon chien, il s'appelle 23;{zk7W?p et il change de nom toutes
les semaines.
-- Uvoguine

https://linuxfr.org/comments/483919.html#483919(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je m'en doute mais quel est l'intérêt de ce préfixe ? Surtout s'il faut refaire la même chose pour Konqueror. Ensuite c'est IE, Opera et les autres qui vont s'y mettre et pour avoir des bords arrondis sur un maximum de browsers va falloir mettre les 50 attributs qui ne différent que par leurs premières lettres ? Je comprend pas l'intérêt d'utiliser une extension spécifique alors qu'il y a une draft du W3C qui fait la même chose.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Comment programmer un de ces touches pour arrêter mozilla directement ?

Si tes touches sont supportées par le noyau (dans le cas contraire tu peux toujours utiliser une combinaison genre ctrl+k+m) tu dois pouvoir faire ça avec xbindkeys.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et avec border-radius tout court ça marche pas ? C'est dans CSS3, même si c'est encore qu'une draft (qui a plus de 2 ans quand même) c'est toujours mieux que d'inventer des attributs spécifiques non ?

http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radiu(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je suis d'accord :)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Le problème c'est plutôt que PHP c'est tellement facile que n'importe quel neuneu de base peut faire un site web qui marche plus ou moins en quelques heures mais qu'il n'a aucune idée des problèmes de sécurité possibles jusqu'à ce que son site se fasse défacer.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Un ami pommiste qui se soigne me fait remarquer cette magnifique perle sur http://www.apple.com/fr/macosx/(...)

Panther, la quatrième version majeure de Mac OS X en seulement trois ans, est une véritable révolution en matière d'innovation, de simplicité d'utilisation et de fiabilité – il faudra des années aux autres systèmes d'exploitation pour le rattraper, si jamais ils y parviennent.

Même sur microsoft.com j'arrive pas à trouver un troll aussi beaux (à la limite "get the facts" mais non).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Si tu parles des pommistes, il faut parler des manchotistes/libristes (n'excluons pas les autres OS libres) et des fenêtristes.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ben oui mais non: genre si tu as un répertoire "privé" protégé par login/mdp au niveau HTTP (les .htaccess d'Apache) dans lequel tu as des .php qui ne sont censés être accessibles normalement, ton truc ne convient pas. Encore pire: apparement depuis PHP5, file_exists() gère certains protocoles dont FTP, avec ça tu te retrouves avec une belle grosse faille XSS.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Moi ce que je fais c'est un tableau associatif avec comme clé un nom de page et rien en contenu. La première clé du tableau est la page par défaut (mais on peut remplacer par une 404, suffit de pas envoyer les headers HTTP avant). Genre:

if (!isset($_GET['pg']) || !in_array($_GET['pg'], $valid_pages))
    $pg = $valid_pages[0];
else
    $pg = $_GET['pg'];
require("includes/pages/$pg.inc.php");

Evidemment si global_vars est on, faut faire gaffe à la définition de $valid_pages. Vaut mieux utiliser

$valid_pages = array('foo', 'bar', baz');

que

foreach ($pages as $pg)
    $valid_pages[$pg] = 1;

parce qu'alors un attaquant pourrait faire une requète genre machin.php?valid_pages['fichier_secret']=1&pg=fichier_secret

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

En plus du code, crois qu'il y a pas mal de doc sur l'écriture de drivers USB dans le tar.gz du noyau (dans linux/Documentation/DocBook/, faire un "make htmldocs" avant).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tu peux essayer de passer par le cache Coral: http://neverland.net.nyud.net:8090/bellamy/(...)
ou au pire par archive.org: http://web.archive.org/web/*/http://neverland.net/bellamy/(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Si, j'avais fait un backup heureusement :) Par ailleurs il semblerait que le bug soit résolu: http://bugs.debian.org/288724(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

http://undeadly.org/cgi?action=article&sid=20041231195454&m(...)
Il y avait un journal de seconde page il y a quelques jours sur le sujet (titré "entrez c'est ouvert" ou un truc comme ça) mais impossible de remettre la main dessus.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

my only gripe with the GPL has been how many words it seems to need to say something very simple

[+1] (vive BSD \o/)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je viens de tomber sur ceci (bon ça date un peu): http://slashdot.org/article.pl?sid=03/02/03/2137213(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.