Besoin d'explications : fonctionnement des dépôts Ubuntu

[Tiduster]

Bien le bonjour.

Je termine actuellement un projet de sécurité basé sur l'attaque d'une machine virtuelle (sous Ubuntu Server 8.04 LTS) fournie par un intervenant (à coup de BackTrack 5 r3 et Nessus principalement).

C'est fun est on a bien rigolé, voili voilou.

Maintenant j'en suis à la phase de correction, où on est censé dire au propriétaire de la machine comment corriger les failles et boucher les énormes trous.

Je teste quelques trucs pour détailler un peu mon rapport, et par curiosité j'ai lancé un petit apt-get update/dist-upgrade sur la VM afin de voir combien de trous ça allait me réparer.

Et binh finalemet pas tant que ça !

Même après avoir mis à jour tous les paquets, j'ai encore des versions complètement obsolètes de ProFTP, de Samba et de MySQL (pour ne citer qu'eux).

Pourtant Hardy (8.04) est encore supporté par Canonical dans sa version Serveur, je devrais donc obtenir les mises à jour de sécurité non ?

C'est uniquement pour les composants du noyau ?

Donc pour ma connaissance personnelle, si un expérimenté de Linux pouvais m'expliquer comment fonctionne ces dépôts ?

Pour les logiciels, au bout d'un moment les maj sont bloquées et faut passer à la version d'Ubuntu suivante ?

[ragoutoutou]

Généralement dans les distros stables serveur, les empaqueteurs ne changent pas les versions major/minor des logiciels lors des mises à jour, mais prennent les patchs importants, genre sécurité et les appliquent à la version fixée du soft de la distribution.

Par exemple, si le soft xyz qui est fourni en version 1.2.3 dans la distribution a une faille de sécurité qui se fait corriger dans la version 1.3.5, le correctif va être prélevé sur la version 1.3.5 et réintégré à la version 1.2.3 afin de minimiser le risque de régressions ou de bris de compatibilité.

(Note: Bien entendu cette approche n'est pas valable pour les éventuels composants non-libres)

Techniquement, donc, le n° de version du soft ne bougera pas, mais le n° de version du paquet ainsi que son changelog changera.

Donc dans un audit de sécurité sur des composants d'une distribution linux pro, il ne faut pas travailler en recensant juste les versions des softs (p.ex OpenSSH 5.1p1, ou Apache HTTPD 2.0.32 ) et sortir ensuite la liste de cve ou cert-ist s'appliquant à cette version d'openssh ou apache pour savoir si le logiciel est vulnérable ou non. Il faut prendre en compte les versions des paquets et leur historique.

[seboss666]

De toute façon, il va falloir penser à une migration : 8.04 + 5 = 13.04, en clair, dans 3 mois, le support de la distrib par Canonical va s'arrêter. Au prochain bulletin de sécurité publié sur une seule des applis concernées, ça va commencer à chauffer.

Si c'est juste la philosophie de maintien à jour qui est à exposer, alors ragoutoutou a déjà tout dit. Un composant "ancien" dans Debian Squeeze est potentiellement aussi protégé que le même composant plus récent dans Ubuntu (dans le cas de la 8.04, il seront soit au même niveau, soit un poil plus ancien, mais le principe est là).

[Tiduster]

D'où le fait que j'ai des exploit qui ne fonctionne pas et/ou plus alors qu'ils devraient.

Si j'ai bien compris c'est par ce que Nessus lis les bannières des logiciels et en déduit la version, mais les trous ont été bouchés à l'aide de patch de sécurité (sans que cela ne change le numéro de version du logiciel).

Donc les exploit ne fonctionne plus, alors que la version du logiciel est censé contenir la faille.

Bon binh je dormirais moins con ce soir, merci pour ces infos .

Pour la migration de version ubuntu je pensais conseillé la 12.04 LTS plutôt que la 13, mais l'idée est la même ^^.

[seboss666]

LTS= Long Term Support, 5 ans pour les serveurs. 13.04 = normal, 18 mois. Le choix est vite faite en production.