Dans un précédent article j'évoquais la possibilité d'activer le "click to play" qui permet de charger les plugins à la demande (cela remplace FlashBlock). Sauf que depuis Firefox 23, l'astuce donnée, à savoir taper dans about:config, ne fonctionne plus.

En fait il faut aller dans le gestionnaire de modules complémentaires, puis lister les plugins, et dans le menu déroulant sélectionner "Demander pour activer".

Et voici ce qu'on obtient lorsqu'un vilain élément flash veut se lancer :

Et voilà !

Dans un article précédent j'ai cité un moyen d'utiliser IPv6 à travers un tunnel IPv4. Or il faut répéter la manipulation sur chaque machine, ce qui n'est pas très pratique, encore moins pour les appareils mobiles (Android).

Est-il possible de "déporter" cette passerelle sur une machine (serveur) et pousser automatiquement la configuration aux machines du réseau ? Oui ! Nous allons voir comment mettre en place une "IPv6 Box".

Comme le montre le schéma ci-dessus, la passerelle ne nécessite pas de structure particulière du réseau, elle se branche simplement sur le routeur (*box) comme n'importe quel autre périphérique. Aucune configuration ne sera nécessaire (c'est la magie de l'IPv6) sur les autres machines du réseau.

Le serveur

Il peut être physique ou virtuel (réseau bridge). Il n'y a besoin que d'une interface réseau ce qui simplifie amplement les choses. Ce serveur va :

• Établir et maintenir une connexion au tunnel IPv6
• Faire office de passerelle pour les machines du réseau
• Utiliser le daemon RADVD pour manifester sa présence sur le réseau (les machines s'auto configureront)

Le tutoriel est fait avec Debian, mais devrait fonctionner sur Ubuntu.

Demander un préfixe /48

Commencez par vous inscrire sur le site de Hurricane Electric, et créer un nouveau tunnel. Vous allez pouvoir choisir votre point de sortie (Paris) et spécifier votre adresse IP. Par la suite demandez un préfixe /48 en cliquant sur le bouton Assign, sur la page qui récapitule les paramètres de votre tunnel.

Voici ce que vous devriez obtenir :

Configuration de Debian

Le serveur dispose d'une interface réseau eth0 avec les paramètres suivants :

• Adresse IP fixe, 192.168.0.10/24
• Passerelle IPv4 (*Box) : 192.168.0.254
• Adresse IPv6 du tunnel : 2001:470:c851:10::1/64
• Adresse IPv6 eth0 : 2001:470:c851:192::1/64

Les adresses IPv6 choisies font partie du préfixe /48 attribué (2001:470:c851::). Aidez-vous du calculateur IPv6 Calculator si besoin.

Ouvrez et modifiez /etc/network/interfaces comme ceci :

auto lo

iface lo inet loopback



# The primary network interface

allow-hotplug eth0

iface eth0 inet static

        address 192.168.0.10

        netmask 255.255.255.0

        gateway 192.168.0.254

iface eth0 inet6 static

        address 2001:470:c851:192::1

        netmask 64



auto he-ipv6

iface he-ipv6 inet6 v4tunnel

        address 2001:470:c851:10::1

        netmask 64

        endpoint 216.66.84.42

        ttl 255

        gateway 2001:470:c851::1

Puis relancez le réseau avec la commande suivante (ou redémarrez le serveur) :

# service networking restart

Pour vérifier que le tunnel est bien en place, tapez la commande suivante :

# ping6 google.com

Ou alors :

# apt-get update

(Si vous utilisez les dépôts Debian par défaut, ils sont accessibles en IPv6...).

Radvd

Un réseau en IPv6 n'a pas besoin de serveur DHCP. En effet, le routeur va manifester sa présence sur le réseau, et les machines vont s'auto-configurer (Stateless Address Autoconfiguration, SLAAC). On va donc installer Radvd :

# apt-get install radvd

Créez le fichier /etc/radvd.conf et ajoutez :

interface eth0 {

        IgnoreIfMissing on;

        AdvSendAdvert on;

        MinRtrAdvInterval 30;

        MaxRtrAdvInterval 60;

        prefix 2001:470:c851:192::/64 {

                AdvOnLink on;

                AdvAutonomous on;

                AdvRouterAddr on;

        };

};

Lancez ensuite le service :

# service radvd start

Vérifications

Redémarrez une des machines de votre réseau, et vérifiez si elle récupère bien une IPv6. Attention, si cette machine utilise network-manager, il se peut que l'IPv6 soit désactivé par défaut ! Dans ce cas, éditez votre connexion réseau, et dans l'onglet "Paramètres IPv6" sélectionnez "Automatique". La capture d'écran ci-dessous montre le paramétrage sur CentOS6 + Gnome2 mais reste similaire sur Fedora et KDE.

Allez sur le site test-ipv6.com. Si vous obtenez un 10/10, c'est bon !

Si vous avez décidé de vous mettre à l'IPv6 mais que votre FAI ne "connait" que l'IPv4, inscrivez vous chez Hurricane Electric. Vous pourrez gratuitement créer votre tunnel IPv6. Et en prime, vous pouvez avoir un /64 et un /48 ! La manipulation est simple puisque sur votre compte utilisateur, il y a un outil permettant de générer des lignes de commandes à entrer dans votre OS favori (même Windows 7).

Amusez-vous bien et n'oubliez pas de tenter la certification !

GLPI est capable d'importer ses comptes utilisateurs depuis un annuaire LDAP (openldap, Active Directory, etc...). Malheureusement si les comptes utilisateurs sont renommés il ne les reconnait plus et créé alors des doublons. L'accès est toujours possible pour les utilisateurs, mais ils ne retrouvent pas leurs données.

C'est ce qui nous est arrivé, car dans le cadre d'un grand ménage et d'une mise aux normes, nous avons changé les logins A.D des utilisateurs. Après de longues recherches sur le web, demandes sur IRC, coups d’œils aux rapports de bug, j'en suis arrivé à la conclusion qu'on ne pouvait pas y faire grand chose. La solution est de modifier les comptes utilisateurs à la main. Or si les utilisateurs sont synchronisés sur un annuaire ldap, le login est impossible à modifier ! Il faut donc ruser.

Il n'est pas forcément nécessaire de migrer tous les comptes utilisateur, uniquement ceux qui ont travaillé sur des tickets. Pour les autres on peut accepter la création de doublon et supprimer l'ancien compte car il n'y a pas de perte de données.

Solution 1 : Interface graphique

Le cheminement à suivre est le suivant :

• Aller dans Administration > Utilisateurs
• Cliquer sur le compte utilisateur à migrer
• Dans l'onglet Synchronisation modifier la méthode d'authentification sur Authentification sur la base GLPI
• Valider.
• Changer l'identifiant de l'utilisateur pour le mettre en conformité avec l'annuaire ldap.
• Remettre la méthode d'authentification sur Authentification sur un annuaire LDAP et sélectionner votre connecteur.

L'utilisateur doit maintenant être capable d'accéder à GLPI avec son nouvel identifiant et retrouver ses tickets.

Solution 2 : SQL

Note : Il est recommandé de procéder à un export (sauvegarde) de la base de données avant de continuer.

Attaquer directement la base de données peut être plus rapide car on peut modifier directement le login. Pour vous faciliter les choses vous pouvez utiliser phpmyadmin si votre serveur le permet. Dans l'exemple suivant la base de données de GLPI s'appelle dbglpi ainsi que l'utilisateur associé. Imaginons que pour l'utilisateur "Xavier C", qui porte l'id 6*, je veux indiquer le login "cx49".

mysql -u dbglpi -h localhost dbglpi -p

update glpi_users set name = 'cx49' where id = '6';

*Pour visualiser les id utilisateurs :

• Soit passer la souris sur la liste des utilisateurs dans GLPI (l'id apparait dans l'url)
• Visualiser la table glpi_users sur phpmyadmin
• Utiliser la commande select name, id from glpi_users order by id;

Conclusion

Les comptes utilisateurs de GLPI ont été remis en conformité avec l'annuaire LDAP, le login est donc à nouveau possible et les tickets préservés.

Voici quelques règles de sécurité à respecter pour assurer la pérennité de votre serveur mail. Je me suis basé sur mon expérience et les failles de sécurité que nous avons rencontré en entreprise.

1.Le serveur mail est le seul autorisé à envoyer du courrier

Dans votre organisation, vous devez faire en sorte que seul votre serveur mail puisse envoyer du courrier, et pas vos postes clients. Concrètement vous devez ajouter une règle dans votre parefeu qui indique que seul l'IP du serveur mail peut utiliser le port 25 tcp sortant. Il doit être bloqué pour le reste des gens.

Imaginez qu'un poste client attrape un virus (très courant) dont le but est d'envoyer du spam. Si le poste client accède au port 25, rien n'empêchera le nuisible de le faire et vous vous ferez rapidement blacklister. Par contre si l'accès au port 25 est bloqué, l'impact sera limité (pas de blacklistage). Les nuisibles qui envoient du spam sont rarement capables de trouver et utiliser le serveur mail de l'entreprise.

2. Contrôlez ce que le serveur mail relaie

Un serveur mail ne doit pas être openbar. Il ne doit accepter de relayer le courrier qu'après une authentification du client. Si ce n'est pas possible pour certaines applications, autorisez les adresses IP des serveurs qui les font tourner. Mais un serveur mail ne doit pas relayer le courrier anonymement pour tous.

Bien souvent la configuration par défaut autorise le relai du courrier si l'émetteur est sur le même réseau. En pratique c'est rarement gênant mais cela peut constituer une faille et un point d'entrée pour l'émission de courriers non désirée.

3. Le serveur mail est protégé par une passerelle

Un serveur mail peut être sensible s'il contient des éléments critiques : par exemple un serveur Exchange est sur un domaine Active Directory. Il ne doit donc pas être compromis sous peine de donner l'accès à tout votre domaine et vos ressources réseau à l'attaquant. Vous devez donc utiliser une passerelle SMTP qui va effectuer un premier filtrage et ne fera que du relai. Ce rôle peut être rempli par diverses solutions : serveur linux avec postfix, appliance, etc.

4. Le serveur mail est clean

Votre serveur mail doit être mis à jour régulièrement et disposer d'un antivirus. Le système ne doit pas être compromis (par un virus, vers, rootkit...) sous peine de devenir une machine à spam. L'analyse des profils utilisateur et du comportement est un élément de diagnostic.

5. Votre serveur mail ne doit pas être accessible par internet

Le courrier entrant doit être dirigé dans la passerelle, située en DMZ, qui ensuite va les rediriger sur votre serveur mail. Il est important que le serveur mail lui-même ne soit pas accessible par internet. De trop nombreuses failles sont exploitables, notamment au niveau des logins administrateur. Un compte de test anodin sur un Active Directory avec un mot de passe "temporaire" (123456) permettra à quelqu'un de se connnecter en RDP et faire des dégâts.

De manière générale aucun serveur fournissant des services privés, comme du TSE, ne doit être accessible par internet. Si vous souhaitez que des utilisateurs distants ouvrent des sessions TSE, utilisez un VPN.