Et c’est parti pour ubuntu 12.04
0Je sais, je suis le dernier des mohicans. Je ne pense pas être un Fanboy mais j’aime beaucoup ce que fait Canonical pour Ubuntu. Je suis même adepte d’Unity, c’est pour dire !
Bien entendu, Unity est très jeune et souffre de plein de défauts. Mais j’y vois d’autres choses… Que je n’étalerai pas ici. Par contre y’a un truc qui me fait perdre énormément de temps, c’est le alt-tab par défaut qui centralise les fenêtres par type d’application. Je propose donc la solution pour changer ce comportement et récupérer un alt-tab plus « classique ».
Premièrement on installe le gestionnaire de compiz :
sudo apt-get install compizconfig-settings-manager
Ensuite lancez-le avec la commande :
ccsm
Puis recherchez « Ubuntu Unity Plugin ». Dans l’onglet « Switcher », désactivez les 4 premiers raccourcis (Alt-tab etc) en cliquant sur le raccourcis et en décochant la case « Activé ».
Revenez sur la page d’accueil de ccsm, pui recherchez et activez « Static Application Switcher ». Il y en a d’autre mais c’est celui qui me semble le plus stable et rapide. Bon… quand je dis stable je le dis vite parce qu’il plante compiz la première fois que vous le lancez (en tout cas chez moi avec une nvidia). Mais après ça c’est du tout bon
Enjoy Unity.
Poisson frais – Skipfish et Jenkins
0Ok, comme dit dans un article précédent (Skipfish rapidos), je souhaitais intégrer skipfish à Jenkins. Finalement c’est pas compliqué, ça m’a pris 10 minutes le temps de comprendre comment étaient générées les pages skipfish et d’écrire le script qui va bien.
Côté Jenkins, créez un nouveau job (par exemple « Security »). Dans la description indiquez ceci (en changeant l’url) :
<iframe height= »800″ src= »http://jenkins.your.url/job/trunk-Security/Skipfish/? » type= »text/html » width= »900″></embed>
Dans la section build, nous allons exécuter deux commande (shell), une pour skipfish, l’autre pour faire planter le build si des failles sont découvertes.
Le premier doit avoir cette structure :
rm -rf /var/lib/jenkins/jobs/Security/workspace/skipfish; cd /usr/local/skipfish; skipfish -u -A YOURLOGIN:YOURPASSWORD -MEULV -W /dev/null -o /var/lib/jenkins/jobs/Security/workspace/skipfish/ https://your.software.url
Et le second celle là :
/usr/local/skipfish/test_results.sh
Le script test_results.sh doit contenir les lignes suivantes. C’est un peut crado comme script, mais vu la non complexité du truc, ça reste plus que lisible. D’ailleurs en lisant la ligne je me dis que le head -1 n’a rien à faire là. Vous pouvez remplacez « 0|1|2″ par le niveau de sécurité souhaité, je pense que se focaliser sur les niveau 3 et 4 sur une plateforme d’intégration est judicieux, mais si vous voulez ajouter le niveau 2 il faudra avoir « 0|1″ :
#!/bin/bash
exit $(grep severity /var/lib/jenkins/jobs/Security/workspace/skipfish/samples.js | awk ‘{print $3}’ | sed « s/,// » | grep -v -E « 0|1|2″ | head -1 | wc -l)
Et voilà, il ne reste plus qu’a valider et si skipfish remonte une alerte de sécurité supérieure à 2, vous serez averti : le build plantera. N’hésitez pas si je ne suis pas clair.
Sventon sur debian
0Objectif de sventon : se balader en web sur un repo SVN (je l’ai intégré à jenkins pour faire facilement un diff sur les dernières modifs).
Problème : à chaque redémarrage de tomcat, il perd sa conf.
Solution (attention ça ne résiste pas aux mise à jour je crois… y’a sans doute mieux mais ça fera mon affaire) :
Dans /var/lib/tomcat6/webapps/svn/WEB-INF/applicationContext.xml changer :
<bean id= »sventonTempRootDir »>
<constructor-arg value= »${java.io.tmpdir} »/>
<constructor-arg value= »sventon_config »/>
</bean>
Par :
<bean id= »sventonTempRootDir »>
<constructor-arg value= »/etc/ »/>
<constructor-arg value= »sventon_config »/>
</bean>
That’s it! (la conf arrive dans /etc/sventon_config… et bien sûr il faudra le reconfigurer une dernière fois, sauf si vous copiez le contenu de /tmp/tomcat6-tmp/sventon_config/ dans /etc/sventon_config)
LemonLDAP::ng je t’aime
0Shibboleth… J’ai testé et c’est 8h d’écriture de xml pour arriver à quelque chose. Et puis au moment ou l’on veut activer la feature qui tue, on se rend compte qu’il va falloir se pallucher toute la doc de SAML. Pas pratique.
Pour mes besoins (et ceux de la société dans laquelle je travaille), j’ai voulu tester lemonLDAP::ng. La doc est clair, la conf via clickodrôme efficace… En 2 heures, tout était fonctionne ! La cerise sur le gâteau, contrairement à shibboleth, LemonLDAP::ng gère le Single Logout (attention, à l’inverse shibboleth permet beaucoup plus de choses que LemonLDAP::ng).
Bref, aujourd’hui on passe l’install sur un serveur de prod. Contrairement à la plateforme de dev, on a l’erreur suivante lors de l’accès au manager :
Undefined subroutine Lemonldap::NG::Manager::doall
Pour ceux qui tomberaient sur cette erreur : votre « manager/index.pl » est obsolète (version 0.9x vs 1.1). Il suffit de réinstaller proprement le paquet du manager. Attention aux erreurs suivantes sur le handler… C’est la même blague.
Si ça peut aider…
Merci Clément – KPTN – Oudot pour son aide précieuse sur la conf de LemonLDAP::ng
/etc sous GIT… tout en un paquet
0Si comme moi ça fait 3 ans que vous vous dites « faudrait que j’essaie de mettre mes /etc/ dans une gestion de version : ne remettez plus à plus tard !
aptitude install etckeeper
Ajouter un nouveau fichier de conf : « git add file »
Commiter : « git commit -m « Modif de tel parametre »
enjoy !
(principal usage : le undo
Next step : faire en sorte de centraliser les etc de mes serveurs sur un git principal, et fournir un accès externe bien sécurisé. Cela me permettra de récupérer « facilement » les fichiers de confs déjà ok sur d’autres serveurs.
Passe-moi le poison – Skipfish
1Dans un contexte professionnel, j’ai mis en place un outil d’audit de code. Skipifsh : efficace, simple et rapide.
Un rapide howto pour le tester sur une appli nécessitant une authentification apache.
wget http://skipfish.googlecode.com/files/skipfish-2.03b.tgz tar xvzf skipfish-2.03b.tgz cd skipfish-2.03b aptitude install build-essential make ./skipfish -A LOGIN:PASSWORD -MEULV -W /dev/null -o /tmp/output_skipfish https://VOTRE_URL/
Avec cette commande, il n’y aura aucune attaque de bruteforce via dictionnaire. Vous obtiendrez donc quelques information de sécurité sur le rendu de vos pages, classés par criticité. Il nous a permis de mettre en lumière un petit soucis chez nous en moins de 30 minutes : sympa
Next step : intégration propre à Jenkins (il est déjà intégré mais je dois voir comment dire à jenkins de dire « Build Failed » quand une faille de criticité moyenne ou haute découverte.
N’espérez pas cracker une bonne clef WPA
0On reparle de l’importance d’un bon mot de passe…
Voici un article qui démontre qu’il est quasiment impossible de cracker une bonne clef WPA : le protocole est actuellement sûr (pas de faille intrinsèque comme le WEP), TKIP mis à part, la seule méthode de cracking est le brute force.
L’article va quand même jusqu’à utiliser la puissance du cloud d’amazon EC2 pour faire ses estimations.
Conclusion de l’article : si vous utilisez un mot de passe bien aléatoire, tout caractère (majuscules, minuscules, chiffres, ponctuations etc.), et d’une bonne longueur (~8 signes minimum), on pourra déchiffrer votre mot de passe «D’ici le prochain Big Bang, peut-être» (sic.).
L’article : http://www.presence-pc.com/tests/wifi-WPA-securite-23393/
vim a désormais besoin de dbus par défaut
0Ça se passe de commentaire…
Pour info, ce n’est pas le vim de sysresccd qui hurle, mais celui de l’environnement dans lequel j’ai chrooté, à savoir une FC14.
Mais en quoi vim peut avoir besoin de dBus? (enfin, en creusant un peu on a bien 2-3 réponses qui viennent à l’esprit mais bon…)
Proxy sock avec SSH
0Si comme beaucoup d’admins, il vous arrive de vous retrouver dans un réseau assez «fermé», filtrant par exemple des sites non autorisés, vous avez certainement cherché à passer au travers ce filtrage.
Il existe une méthode simple avec ssh, si le port 22 est laissé ouvert en sortie. Si le port 22 est fermé, soit on changera son serveur SSH de port d’écoute, soit on utilisera corkscrew, dont la configuration (pas très complexe), est détaillée un peu plus loin.
Pour faire simple, une ligne suffit :
ssh -D localhost:8080 user@monServeurPersoExterne.tld
Une fois la connexion établit, ssh aura créé un proxy «sock» sur localhost. Il suffit alors de configurer firefox/chrome/autre, pour utiliser ce proxy, comme les captures ci-dessous (préférences firefox):
En général, au bout de quelques jours, soit vous ne pouvez pas vous empêcher de vous vanter d’avoir trouver un moyen de «by-passer» le filtrage, soit quelqu’un regarde au moment inopportun au dessus de votre épaule et voit que vous consultez fessebouk, alors que ce dernier est normalement filtré. Après vous avoir menacé de tout balancer si vous ne lui expliquiez pas comment faire, vous vous décidez à partager votre connexion (faible que vous êtes). Rien de bien compliqué, il suffit de remplacer «localhost» par votre IP :
ssh -D monip:8080 user@monServeurPersoExterne.tld
Remplacez «monip» par l’IP attribuée à votre PC (fixe ou DHCP). En général, c’est une adresse en 192.168.x.y ou 10.x.y.z ou 172.16-32.x.y.. Dites ensuite à votre collègue adoré de configurer son firefox comme ci-dessus, mais en mettant dans le champs «hôte sock» votre IP au lieu de «localhost».
Voilà, vous êtes maintenant 2 personnes à tirer du trafic depuis une même IP externe (votre serveur perso) vers une même IP interne (la votre). Si le firewall de votre boite remonte des statistiques, vous serez grillé, à coup sûr. (Morale : il vaut donc mieux savoir être discret et fermer son caquet).
Si le port 22 est bloqué en sortie, pas de panique, il suffit de faire écouter votre serveur ssh sur le port 443 (non détaillé ici), et de vous connecter sur le bon port :
ssh -D localhost:8080 -p 443 toto1@monServeurPersoExterne.tld
Si toutes vos connexions passent par un proxy filtrant, il y a une solution qui marche tout aussi bien, en utilisant l’outil «corkscrew» (tire-bouchon en anglais). On l’installe :
yum|aptitude|emerge (install) corkcrew
Cet outil va négocier pour nous une connexion en mode «CONNECT», le proxy ne regarde alors plus les données qui transitent (mode utilisé pour le SSL). Par contre, il y a de forte chance pour que ce mode connecte ne fonctionne que sur le 443 sortant : à vous de mettre votre serveur SSH en écoute sur ce port (non détaillé ici).
On crée un fichier de configuration avec les paramètres du proxy :
mentos@raphux-ThinkPad-T61:~$ cat .corkscrew/proxy.monEntreprise rberlamont:sUp3r+m0t-De_p455 mentos@raphux-ThinkPad-T61:~$
Et on configure ssh pour utiliser corkscrew quand il se connecte à votre serveur :
mentos@raphux-ThinkPad-T61:~$ cat .ssh/config host monServeurPersoExterne.tld ProxyCommand /usr/bin/corkscrew IPouNomDuProxy 1234 %h %p /home/mentos/.corkscrew/proxy.monEntreprise
On se connecte à notre serveur, comme précédemment :
ssh -D localhost:8080 -p 443 toto1@monServeurPersoExterne.tld
Votre connexion SSH passe maintenant passer à travers le proxy.
Si vous ne voulez pas retaper toute la ligne à chaque fois, libre à vous d’inclure tous les paramètres dans le fichier de configuration de ssh :
mentos@raphux-ThinkPad-T61:~$ cat .ssh/config host monServeurPersoExterne.tld DynamicForward monIP:8080 Port 443 User toto1 ProxyCommand /usr/bin/corkscrew IPouNomDuProxy 1234 %h %p /home/mentos/.corkscrew/proxy.monEntreprise mentos@raphux-ThinkPad-T61:~$
Un simple … :
ssh monServeurPersoExterne.tld
…suffira désormais pour vous connecter à votre serveur ssh :
- sur le bon port (443);
- avec le bon user (toto1);
- à travers le proxy filtrant:
- en créant à votre tour un proxy pour vous et vos ptits collègues si gentils.
Elle est pas belle la vie d’admin?
NB : Attention avec tout ceci : vous de devez pas vous mettre en contradiction avec la charte informatique que vous avez certainement signé.



