Nous avons été occupés cette semaine, toujours en retard sur nos e-mails, mais nous continuons avec le développement de Kali. Nous avons empaqueté de nouveaux outils qui ont été signalés comme manquants par la communauté, tels que inguma , arachni , intimidateur , lbd , uniscan , automate , ainsi que commencé à créer un cadre de bibliothèques et de correctifs pour les outils de reniflage Bluetooth et Ubertooth. Nous avons également corrigé le menu Kali pour qu'il soit à nouveau modifiable.
Avec plus de 300 outils dans notre référentiel, il nous est presque impossible de maintenir * chaque * outil à jour avec la dernière version de git, tout le temps. Un bon exemple de cela s'est produit il y a quelques jours, lorsque nous avons mis à jour le SET forfait. Deux jours après la mise à jour du package, nous avons reçu une demande de « mise à niveau d'outil » pour SET dans notre outil de suivi des bogues, car notre package était déjà obsolète. Cela vous semble un peu extrême ? Peut-être pas, considérez l'énigme suivante :
Vous avez un audit demain et vous préparez vos outils. Vous démarrez Kali Linux, exécutez un "apt-get update &&apt-get upgrade " pour vous assurer que vous utilisez les dernières versions stables de $your_favorate_tool . Après la mise à jour, vous remarquez que $your_favorate_tool a un paquet qui a été mis à jour la semaine dernière dans nos dépôts. Cependant, la semaine dernière, des mises à jour assez impressionnantes ont été ajoutées à $your_favorate_tool en amont, et vous avez vraiment besoin de ces nouvelles fonctionnalités pour l'évaluation à venir. Que faites-vous ?
Pire chose à faire.
En supposant que vous n'utilisez pas Kali en tant qu'"instance jetable", la pire chose à faire dans ce cas est d'écraser les fichiers empaquetés. Par exemple, les commandes suivantes pour mettre à jour un outil qui est mis à jour fréquemment est un grand non-non et finira par casser votre installation à l'avenir.
# dont update tools like this!
cd /usr/share/
rm -rf $your_favorate_tool
git clone $your_favorate_tool
D'accord à faire…mais, meh.
Puisque vous ne devriez pas jouer avec les fichiers empaquetés , l'option la plus courante est de svn ou git checkout $your_favorate_tool dans un répertoire temporaire et utilisez-le à partir de là comme indiqué ci-dessous. Dans la plupart des cas, toutes les dépendances nécessaires à l'outil mis à jour existent déjà dans Kali. Vous pouvez également choisir de reconstruire le package source, qui inclut vos mises à jour et modifications.
cd ~
mkdir work
cd work
git clone $your_favorate_tool
cd $your_favorate_tool
./your_favorate_tool
Notre solution.
Nous avons dit *fermer* à impossible, non? Voyant ce clash entre la fréquence de mise à jour de certains outils et le besoin (de certaines personnes, pas de tout le monde) de "toujours avoir la dernière révision de $your_favorate_tool », nous avons trouvé une solution intéressante. Nous avons mis en place un opt-in "Kali à la pointe ” référentiel qui contient des versions quotidiennes de plusieurs outils utiles et fréquemment mis à jour. Ces référentiels sont encore très expérimentaux (ce qui signifie que nous nous attendons à ce que les choses se cassent de temps en temps jusqu'à ce que nous recevions plus de commentaires de la communauté). Si vous souhaitez essayer cette fonctionnalité, vous pouvez ajouter le référentiel de pointe comme indiqué ci-dessous, mais n'oubliez pas ce terme "point de saignement ”. Il y a une raison pour le sang.
echo deb http://http.kali.org/kali kali-bleeding-edge contrib non-free main >> /etc/apt/sources.list
apt-get update
apt-get upgrade
Nous avons actuellement une poignée d'outils dans ce référentiel, qui incluent se-toolkit (ensemble), aircrack-ng , reconnaissance DNS , sqlmap , rfidiot , boeuf-xss , libnfc , libgratuit , mfoc et mfcuk . Nous nous attendons à ce que cette liste s'allonge avec le temps.