Starend

Mon problème a résoudre ici est assez simple. Permettre à un utilisateur sans droits du système de monter une clé USB définit à un emplacement spécifique.

Sous Linux, ça se serait traduit par une création de répertoire et une ligne ajoutée à /etc/fstab avec un UUID= et l’option users.
Mais je dois le faire sous FreeBSD et il n’y a ni l’option users ni udev.

L’exercice est fait ici avec FreeBSD Release 10.0. Le dossier à utiliser est /sas. La clé est formatée avec une seule partition en VFAT.

Label de partition

Insérer la clé USB.

Il faut commencer par trouver le périphérique de la partition qui nous intéresse. La commande dmesg nous renseigne sur le dernier périphérique utilisé :

# dmesg | tail
ugen2.2: <vendor 0x13fe> at usbus2
umass0: <vendor 0x13fe MEMUP, class 0/0, rev 2.00/1.10, addr 2> on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x4000
umass0:5:0:-1: Attached to scbus5
da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
da0: < MEMUP PMAP> Removable Direct Access SCSI-0 device
da0: Serial Number 0748374E0011
da0: 40.000MB/s transfers
da0: 1908MB (3907584 512 byte sectors: 255H 63S/T 243C)
da0: quirks=0x2<NO_6_BYTE>

Ici, c’est le périphérique /dev/da0. Si on regarde /dev/da0*, on a :
/dev/da0
/dev/da0s1

On va pouvoir ajouter un label à cette partition da0s1 de cette clé USB :
# glabel label sas /dev/ad0s1

La partition a maintenant un label permanent qui apparaît comme /dev/label/sas. Si on remplace la clé USB par une autre clé partitionnée de la même façon, le label ne sera pas remis en place, il est vraiment spécifique au couple clé/partition.

Point de montage

On commence par créer le dossier /sas avec les bons droits :
# mkdir /sas
# chmod 770 /sas
# chown toto /sas
# chgrp toto /sas

On pourrait monter la partition à la main, mais c’est mieux de l’automatiser. On ajoute à /etc/fstab :
/dev/label/sas /sas msdosfs rw,noauto 0 0

Ici, je permet l’écriture (rw) et interdit le montage automatique (noauto). Le montage se fera par une action volontaire de l’utilisateur.

On peut vérifier que la partition monte bien :
# mount /sas
# ls /sas
Photos
# umount /sas

On peut aussi vérifier avec une autre clé USB, ça ne marche pas.

Droit aux utilisateurs

Jusqu’ici, seul root peut utiliser cette partition.On va faire en sorte qu’un utilisateur le puisse aussi.

Ajouter au fichier /etc/rc.conf la ligne :
devfs_system_ruleset="localrules"

Ajouter au fichier /etc/sysctl.conf la ligne :
vfs.usermount=1

Créer le fichier (ou ajouter) /etc/devfs.rules avec comme contenu :
[localrules=10]
add path 'label/sas' mode 0660 group toto

Après redémarrage, en insérant la clé USB, on peut voir les droits de /dev/label/sas :
crw-rw---- 1 root toto 0x69 29 avr 23:45 /dev/label/sas

Et, reconnecté en tant que toto, on doit pouvoir monter la partition simplement en lançant :
$ mount /sas
$ ls /sas
Photos
$ umount /sas

Si on donne pas à toto les droits utilisateurs sur le répertoire de montage, il le peut pas monter la partition sur ce répertoire. Mais il peut la monter ailleurs dans son dossier personnel.

Et voila :-)

Liens

– http://www.freebsd.org/doc/handbook/geom-glabel.html
– http://scratching.psybermonkey.net/2010/07/freebsd-how-to-allow-normal-user-to.html
– http://www.freebsd.org/cgi/man.cgi?query=devfs.rules&sektion=5
– http://www.freebsd.org/doc/handbook/usb-disks.html

La tempête commence à passer pour OpenSSL et sa récente faille critique. C’est pour rappel un programme généraliste pour tout ce qui est chiffrement, y compris les certificats X509, les tunnels SSL et assimilés. On peut voir un peu partout sur internet les implications de cette faille nommée Heartbleed.

Un site web et un logo sont dédiés à cette faille :

http://heartbleed.com/

Évidemment, c’est un gros problème pour une grande partie des serveurs sur Internet, et pas que pour les serveurs web. Tous les services qui sécurisent leurs communications avec TLS sont potentiellement impactés, et surtout tous ceux qui utilisent la librairie OpenSSL. Cela inclut des serveurs web (https) mais aussi la messagerie (smtp, imaps, pop3s), la messagerie instantanée (xmpp), etc…
Le plus rude pour un administrateur d’un serveur concerné, c’est que rien n’apparaît dans les logs (journaux). Tout au plus peut-on voir les tentatives avec un IDS ou une analyse fine du trafic réseau.

Pour résumer l’ambiance, rien de mieux que la citation :

« Si vous gardez votre sang-froid alors que tout le monde panique autour de vous, peut-être avez-vous mal évalué la situation »
Stéphane Bortzmeyer (site)

Aujourd’hui, un serveur concerné par la faille et non à jour est un serveur vulnérable.

Et les machines utilisateurs ?
Elle sont concernées aussi. OpenSSL est inclus dans beaucoup de logiciels pour gérer facilement le chiffrement. La faille marche aussi en sens inverse, depuis un serveur malveillant.

Pour ma pomme, mon principal serveur utilise une version un peu plus ancienne de OpenSSL, packagée. Cette version reçoit régulièrement des correctifs mais n’est pas impactée par Heartbleed. Ça passe pour cette fois même si je suis bon pour devoir mettre à jour tout mon serveur prochainement…
J’utilise aussi OpenSSL pour le projet nebule et le projet sylabe. Les fonctions internes de chiffrement et signature ne sont pas concernées. L’accès aux serveurs, via https, est concerné pour certains robots de test de sylabe. Ils n’ont pas été utilisés pendant la semaine de tempête.

Quels utilisateurs sont potentiellement concernés ?
En fait, tous les utilisateurs qui ont utilisés un compte sur un serveur utilisant OpenSSL avec la faille.
Il suffit pour les admins de regarder les logs des connexions côté public et de prévenir tous les utilisateurs qui se sont connectés pendant la période de temps critique. Mais une société commerciale a-t-elle vraiment envie de diffuser à ses utilisateurs que ses serveurs ne sont pas forcément aussi sûrs que ça !?
Doit-on prendre comme début de période de temps la date de diffusion publique de la faille ? Ou doit-on prendre la date d’ajout de la faille (volontaire ou pas), 2012 ? On passe de la semaine aux deux dernières années. On passe des dernières connexions à tous les utilisateurs. L’impacte n’est pas le même.
Et puis ce n’est pas aussi simple que ça. Si le chiffrement des connexions est séparé des serveurs web, si on a des frontaux dédiés aux tunnels TLS, seuls ceux-ci sont concernés. Il n’est dans ce cas pas utile de faire changer les mots de passes des utilisateurs.
Certaines grosses sociétés américaines ont été prévenues un peu en avance de la diffusion pour être à jour au bon moment. Il ne s’agirait pas que des services critiques comme Google ou Facebook ne soient bloqués, les banques peuvent attendre ;-)

Il pourrait être tentant pour certains admins de changer de solution de chiffrement. Oui, mais laquelle choisir? GnuTLS? Celle de Microsoft? Une solution propriétaire payante?
Je ne suis pas sûr du tout qu’échanger un programme avec les sources publiques par un programme aux sources fermées (programme privateur) soit une bonne solution. Quelque soit la qualité de certains programmes de M$, en logiciels de sécurité, il n’est pas très bien vu de ne pas disposer des sources. Quelle confiance peut-on apporter à un programme qui ne peut être librement audité par tout le monde. Je passe sur les récentes affaires révélées par Mr Snowden. La sécurité par l’obscurité, c’est comme ça que cela s’appelle, est très souvent employée pour cacher les choses mal programmées.
Ceci dit, la diversité à aussi du bon. Mixer les technologies et implémentations permet de ne pas se retrouver avec tous ses serveurs à poil en même temps en cas de coup dur comme Heartbleed…
GnuTLS a eu des problèmes récemment, SecureTransport de Apple aussi. Les problèmes ne sont donc pas spécifiques aux logiciels à code ouvert.
Ce n’est pas la première fois que l’on a ce genre de problème, et ce ne sera pas la dernière.

Une solution, séparer la fonction de chiffrement TLS sur des serveurs dédiés. Le bout des tunnels sécurisés s’arrêtent aux portes des serveurs web, sur des machines spécialisées. Dans ce cas, seules les connexions en cours, leurs clés de sessions, sont vulnérables.
Les certificats de ces serveurs frontaux TLS sont aussi potentiellement compromis, donc à changer, sauf si ceux-ci sont stockés sur des cartes dédiées (pas en mémoire).
C’est d’ailleurs une bonne pratique pour tous les serveurs, et pas seulement les frontaux web : séparer les services entres eux et les applications sur des serveurs différents. Les séparer sur des machines physiques différentes et des réseaux physiques différents si leurs criticités sont différentes. Mais comme toujours, ça demande du temps, des compétences et du pognon.

L’autre solution, si tu es concerné :

1. mettre à jour les serveurs et les postes clients ;
2. changer les certificats des serveurs ;
3. changer les mots de passes des utilisateurs.

Une question reste en suspend. Est-ce une 0-days ?
Va-t-on découvrir que certains l’utilisaient depuis quelques temps ? La NSA par exemple ? Rien n’est jamais définitivement écrit.

Ça y est, nous avons franchi la date fatidique du 8 avril. Il y a eu beaucoup de bruit récemment sur la fin du support de M$ Windows XP. Et pourtant il ne se passe finalement pas grand chose pour l’instant. Pas de fin du monde en vue.
C’est comme si l’on avait enfin franchi le mur du son. On est encore surpris de ne pas s’être fracassé sur le mur… mais on ne se rend pas encore compte que le pire est à venir. Progressivement, on va commencer à perdre des pièces, petit à petit. La perte de contrôle, c’est pour bientôt.

C’est moche, OpenSSL est en train de voler la vedette dans l’actualité. Il faut dire, le problème est sérieux aussi…

Mais revenons à nos moutons…
Cela fait un moment que cette fin de support est prévue. Et pourtant, la presse ne s’en empare que depuis peu. Le laps de temps entre le début de la vague d’alerte et l’expiration de l’échéance a été très court. Tellement court que certains utilisateurs se rendent compte la veille que le machine va avoir des problèmes. Ce laps de temps ne laisse pas de temps de répit à ceux qui ne comprennent pas grand chose à l’informatique. Et oui monsieur, il va falloir très rapidement acheter une nouvelle machine!

Bon, le mur est passé, mais pour l’instant ça tient.
On peut se dire que ça tiendra bien au moins un mois, comme d’habitude entre deux diffusions des mises à jours par Microsoft. Ça n’est pas aussi simple. Il n’y aura sûrement pas plus de nouvelles failles de sécurité qui sortiront dans le même laps de temps. Mais le marché des failles 0-days doit exploser. Pour un groupe de pirates qui souhaite augmenter son botnet, son réseau de machines zombies, une grande quantité de machines vont devenir facilement corruptibles sans qu’un patch ou un anti-virus ne risque de les y déloger. Il s’agit maintenant d’en faire tomber un maximum avant la concurrence. Et une fois qu’une nouvelle machine est dans son botnet, il faut empêcher qu’elle ne tombe aux mains d’un autre botnet… qui éjectera ses concurrents.
Ce nouveau marché de machines prêtes à intégrer un botnet est gigantesque. Au niveau mondial, des statistiques montrent que plus de 27% des ordinateurs individuels sont encore sous Windows XP. Pour des pays comme la Chine, ce serait de plus de 50%.

Il est à noter que malgré le grand âge de Windows XP, 12 ans et 6 mois, et malgré ses nombreuses corrections de sécurité et améliorations (Service Pack) on lui trouve toujours régulièrement de nouvelles failles. Comme quoi, un système d’exploitation, et par extension tout programme, ne se bonifie pas beaucoup avec le temps en terme de sécurité.

Beaucoup vont le regretter, à commencer par les propriétaires des unes machines sur quatre dans le monde sur lesquelles Windows XP tourne encore.
Pourquoi tant de monde l’utilise encore ?

• C’est un système qui, bien qu’aillant subit plusieurs évolutions, est resté relativement léger. Il est capable de tourner sur des machines jugées aujourd’hui modestes voir complètement obsolètes. Pour ces machines, il est illusoire d’essayer de les migrer vers une version plus récente de Windows.
• Souvent, les logiciels sont plus problématiques que le système d’exploitation. Si on utilise une vielle application qui n’est plus supportée par son éditeur, on ne peut pas toujours espérer la réinstaller sur une machine plus récente. Et ce problème existe aussi avec certains périphériques que les constructeurs voudraient bien vous faire mettre à jour, bref vous faire racheter. On retrouve ce problème des applications et des périphériques dans les migrations de systèmes d’informations. Voila pourquoi une grande partie des entreprises n’a pas fait migrer ses machines si le besoin ne se faisait pas sentir. Je considère que c’est une faute professionnelle pour un DSI qui n’a pas encore fait migrer ses vieilles machines alors qu’il est forcément prévenu depuis quelques années maintenant. et c’est pareil pour la société de support informatique qui n’a pas prévenu ses clients, et qui va maintenant les mettre au pied du mur.
• Ensuite, bien d’imparfaite et pas vraiment ergonomique, les utilisateurs ont leurs habitudes avec l’interface. Migrer vers un nouveau système, c’est changer d’interface. Les jeunes s’adaptent vite aux nouveaux environnements. Les plus anciens ont déjà eu du mal à s’adapter à l’informatique, ils auront encore plus de mal à changer.
• Enfin, certaines machines anciennes sont encore utilisées voir recyclées avec Windows XP parce que cela coûte chère à l’achat ou à la migration. Ça coûte en terme financier, mais aussi en terme de temps et de terme de compétences. Quand on n’a aucun des trois, on garde ce que l’on a. Autant le dire tout de suite, il y a de bonnes chances, faute d’entretien régulier, que ces machines fassent partie d’un botnet.

Que faire avec sa vieille machine ?

1. Première option, celle que le vendeur voudrait vous voir adopter, c’est de jeter votre ancienne machine et en acheter une nouvelle.
2. L’autre option, c’est de tenter de mettre à jour a vieille machine vers une version plus récente de Windows. Évidement, il faut acheter une nouvelle licence alors que la machine marchait très bien jusque là (supposition). Il faut la réinstaller et réinstaller toutes les applications, ce n’est pas à la portée de tout le monde.
3. Et c’est tout ?
   Non, il y a aussi une autre solution, extrême. On peut garder la machine en l’état et ne plus la brancher au réseau. Fini le surf sur Internet, la consultation des messages, le partage des photos. Fini aussi les clés USB que l’on branche dessus avec insouciance… Capote version XXXL!
4. Il y a la solution de l’autruche. Faire comme si de rien n’était. Après tout, c’est sûrement encore un coup des sionistes/musulmans/capitalistes/états/extra-terrestres (rayer les mentions inutiles) pour étendre leur pouvoir sur la terre.
5. Et puis il y a la solution du recyclage. Une machine qui a dix ans, on peut encore la réinstaller avec Linux. Il faudra quand même éviter les environnement trop lourds comme Gnome ou KDE. C’est une migration en bonne est due forme, ça demande aussi quelques compétences. Mais, pour peu que l’on n’ai pas de besoin spécifique en logiciels ou des matériels très exotiques, on va pouvoir continuer à utiliser cette machine sur Internet un peu comme avant, mais protégé. Ça va demander de changer quelques habitudes, mais de toute façon, c’est ce qui vous attend quelque soit la solution retenu…

Ripe In Peace.
Leave room for the young.

Voici la suite de l’article sur les Station Linux et serveur Windows.

Le même script fonctionne avec un serveur M$ Windows au niveau fonctionnel 2008R2.

Tout est passé du premier coup :
– la génération d’un ticket Kerberos ;
– l’ajout de la machine dans l’AD ;
– la consultation du LDAP.

Pour rappel, la station est sous Ubuntu Linux 13.10 .

Les solutions sont parfois bien compliquées pour des problèmes simples à la base…

Je dépanne une machine d’une amie. Cette machine Toshiba Satellite C605-SP4101L est vendu avec M$ Windows 7 Starter et, chose classique, elle rame suite à un problème à l’origine indéterminée. Impossible de nettoyer suffisamment pour retrouver un état stable et correct.
Pas de virus résiduel sur la machine, l’anti-virus à bien travaillé.

Solution : réinstaller.

Sauf que… Cette version de Windows n’est pas disponible à la vente, et impossible de trouver un DVD de réinstallation sur un site sûr.
Le constructeur, classiquement, ne fournit pas de quoi réinstaller la machine si on a pas fait la sauvegarde lors de l’achat. Bref, ce que personne ne fait, en fait.
Il n’est pas prévu de procédure convenable pour réinstaller ce genre de machine au bout de quelques années.
Que faire ? Jeter la machine à la poubelle alors que physiquement elle fonctionne bien.

Je lui aurais volontiers installé un Linux. Surtout que la machine est très bien gérée par Debian 7.0 par exemple.
Mais… à cause d’un périphérique externe très peu diffusé, et donc non supporté par la communauté et l’éditeur, ça n’est pas une solution envisageable.

L’autre solution, c’est d’installer un Windows 7 dans une version commercialisée. Et ensuite, soit on garde cette machine avec un crack, pirate, soit on essaie de la descendre en version (downgrade).
J’ai choisis dans un premier temps de la descente en version depuis une installation en Home Premium. Ça n’a pas fonctionné. Ré-essaie depuis une version Pro, pareil…
Ne reste que le crack. Et ça marche. Elle est activée et fait bien ses mises à jours.

Il faut bien vérifier l’innocuité du crack. Habituellement, ça vient avec une vérole. Il faut aussi vérifier que l’anti-virus est toujours ‘vivant’, c’est à dire qu’il détecte encore les virus…

La morale de cette histoire c’est que, curieusement, on a moins de problème en contournant les protections que en essayant de les respecter.

CF :
– https://answers.yahoo.com/question/index?qid=20100317104813AA2xmui
– http://tuto4you.fr/crack-activation-windows-7-sp1-hal-7600/

Et merde, encore un article sur Windows, je vais tuer mes scores :'(
Bon, j’y ai quand même installé un Linux pour la prochaine fois où elle aura des problèmes :-)

Voici une mire d’utilisation des couleurs pour la communication :

Source : http://aea365.org/blog/chris-metzner-on-presentation-blues-and-reds-and-yellows/