Archives 2013
Rédigé par Xavier - - Aucun commentaire
Rédigé par Xavier - - Aucun commentaire
L'offre ADSL d'OVH est très tentante : ipv6, ipv4 fixe, garantie d'un réseau neutre... et pas de télévision inutile. Ils savent toucher les geeks et ont une touche communtaire. J'ai décidé d'y souscrire afin de constater s'il y a de réels avantages pour le geek qui désire s'auto-héberger. J'ai déjà un accès à internet pseudo-fibre Bouygues dont je suis assez satisfait mais il oblige à utiliser une *Box qui est une grosse boite noire et ne fournit pas d'ipv6 ni d'ipv4 fixe. Si l'offre ADSL OVH me plait je résilierai Bouygues.
Après avoir passé la commande je reçois le modem officiel OVH, un Thomson TG589vn. Et je dois dire qu'il est assez gros pour un modem, il a plutôt les dimensions d'une *box et c'est vraiment dommage. J'ai constaté également qu'en fonctionnement il siffle, un défaut très gênant. J'ai donc décidé de me commander mon propre modem ADSL, un D-Link DSL-320B (bien plus petit et très silencieux).
A gauche le D-Link DSL-320B, à droite le Thomson TG589vn
Je branche le modem, le configure avec les identifiants, et constate que cela ne marche pas : impossible d'accrocher le signal ADSL. J'essaie en modifiant les paramètres, en changeant les câbles, mais rien. Je sort donc le modem OVH de sa boite et le branche : idem.
J'écris donc au support technique (une interface pour créer des tickets est disponible dans l'espace client) en exposant mon problème et les tests que j'ai réalisé. Le lendemain matin je reçois une réponse d'un technicien qui me demande de tester sur une autre prise téléphonique et vérifier la présence d'un condensateur noir. Après vérification c'est pareil sur les 2 prises de mon logement et il n'y a pas de condensateur. Il me répond alors qu'il demande une intervention au niveau du NRA. Quelques jours après il m'informe qu'un problème a été corrigé au niveau du NRA et m'invite à retenter la connexion. Je branche mon modem mais toujours pas de signal, idem avec le Thomson.
Le technicien m'informe alors qu'Orange va intervenir chez moi car le problème doit se situer sur le raccordement de mon logement. En moins d'une semaine un technicien arrive et constate qu'au niveau du local technique de mon immeuble mon logement n'est pas raccordé. En moins de 10 minutes il effectue quelques branchements et mon modem parvient enfin à se synchroniser !
La connexion n'est pas terrible : 160kbps en download, 96 en émission, un ping de 150ms. Le technicien OVH qui suit mon dossier m'informe que ma connexion était en mode "safe", il me repasse alors en normal et le débit s'en trouve grandement amélioré. Voici maintenant une connexion fonctionnelle !
Le débit est clairement décevant : 4,1Mbps en download, ça pique... Le maximum théorique pour la ligne était 11Mbps, et OVH m'indiquait (à partir de statistiques) 8Mbps. Cela fait donc des téléchargements à 400ko/s, pas pratique pour les mises à jour de Fedora ou les ISO. Par contre, étrangement, la navigation web est très rapide.
Mon NRA (ou DSLAM) n'est pas dégroupé par OVH, ce qui signifie que :
La mise en place de la connexion a été l'épreuve du feu pour moi. Mais j'ai trouvé le support très réactif et les techniciens à l'écoute, compétents et capables de dialoguer avec moi sans suivre un script. Je n'ai pas encore mis en place l'ipv6 (le modem DSL-320B n'est pas compatible, c'est donc pfSense qui va gérer le PPPoE à travers le modem en bridge) mais cela va venir très vite.
Rédigé par Xavier - - Aucun commentaire
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.
Le cheminement à suivre est le suivant :
L'utilisateur doit maintenant être capable d'accéder à GLPI avec son nouvel identifiant et retrouver ses tickets.
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 :
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.
Rédigé par Xavier - - Aucun commentaire
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.
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.
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.
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.
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.
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.
Rédigé par Xavier - - Aucun commentaire
Depuis que je suis chez Bouygues je peux débloquer le port 25 sortant et donc envoyer des mails depuis mon serveur sans passer par un relai smtp. Tout se déroule bien jusqu'à ce qu'un de mes contacts m'avertisse qu'il ne reçoit pas mes mails. Un petit coup d’œil dans les logs Postfix me donne ceci :
"[...]status=deferred (host mx01.gmx.net[213.165.67.97] refused to talk to me: 554-gmx.net (mxgmx106) Nemesis ESMTP Service not available 554-No SMTP service 554-IP address is black listed. 554 For explanation visit http://postmaster.gmx.com/en/error-messages?ip=x.x.x.x)"
Diantre ! Un petit tour sur l'URL indiquée m'apprend que le destinataire (gmx) utilise son propre filtre antispam basé sur des bases de données telles que Spamhaus. Quel foutoir, déjà qu'il est difficile de suivre un mail sur internet, mais si en plus des antispam maison s'en mêlent on n'en sortira jamais.
mxtoolbox m'apprend que mon IP est OK sur toutes les bases de données antispam sauf Spamhaus. Je me rends alors sur ce site qui indique que je suis blacklisté en me citant plusieurs causes possibles mais sans vraiment me dire laquelle est juste. Apparemment il ne s'agit pas de mon adresse IP mais de la plage d'adresses. Soit quelqu'un dans cette plage a émis du spam et a provoqué le blacklistage, soit c'est par précaution.
J'ai donc envoyé une requête à spamhaus pour retirer mon adresse IP de leur base de données et être enfin tranquille. A l'heure où j'écris l'article c'est fait, et l'envoi de messages vers GMX est possible.