• Interventions sur production bloquée
• Audits (tests d’intrusions, santé de votre infrastructure…)
• Problèmes de performances
• Projets de courte durée
• Pilotes, maquettes
• Veille technologique
• Télé administration
• …

Besoin d’un regard neuf sur un problème sans solution?

Ma triple compétence Microsoft/Réseau/Sécurité me permet d’intégrer toutes les briques de votre infrastructure dans la réflexion, et ainsi proposer la meilleure solution dans votre contexte.
Contrairement aux spécialistes mono techno voir mono produit, ma vision transversale me permet d’identifier les impacts à tous les niveaux et corréler des évènements ou paramétrages entre eux.
Vous avez certainement un caillou dans la chaussure que je serai ravi de vous enlever! A distance ou sur site, d’une heure à 2 mois de travail, nous trouverons ensemble une solution adaptée à votre contexte.

Aller plus loin

Vous pouvez aussi consulter mon CV

je suis joignable à cette adresse : mathieu.chateau@lotp.fr

Mon profil linkedin : http://www.linkedin.com/in/mathieuchateau

Je possède Ciel Compta avec l’option de sauvegarde en ligne. Suite à la réinstallation de ma station, je cherchais mon mot de passe pour la sauvegarde en ligne par essai successif. M’est venu alors l’envie de voir la nature des échanges avec leur serveurs, grosse erreur !

Petit rappel de la plaquette de Ciel sur la sauvegarde en ligne:

Wireshark suffit pourtant à voir que la demande d’authentification circule en clair (http), un comble !

A 30$ le certificat SSL chez GoDaddy, c’est carrément abusé…Surtout au prix des logiciels Ciel….

• Le site est bien en https
• Le domaine est paybox, très utilisé par les sites marchands
• Le certificat est de type Extended SSL, Internet Explorer a mis le fond vert dans la barre d’adresse

Je donne donc mon feu vert…30 secondes plus tard, une belle erreur SQL pas gérée du tout:

Pour une école, donnant notamment des cours informatique, cela me parait très léger:

• Ils ne devraient utiliser que des procédures stockées
• L’erreur n’apprend rien au client (il est censé prendre des cours d’informatique au mieux…)
• Elle apprend par contre à un pirate que le code du site a des faiblesses, et qu’il y a sûrement moyen de faire des injections SQL.

La seule bonne nouvelle, c’est que Paybox ne renvoi que le début de la carte bleue au site du cnam, qui n’affiche donc qu’une information partielle.

L’analyse des utilisateurs est parfois maladroite, mais la récurrence sur le jeudi précisément est tout de même troublante… Je jette un oeil sur l’antivirus..Surprise, scan général tous les jeudis à midi en priorité maximale!
Je dis scan général, car c’était à la fois pour les postes clients et les serveurs. Aucun doute que les serveurs de fichiers apprécient le geste.

J’ai changé le paramétrage comme suit:

Stations de travail:

• Scan quotidien à 21:00
• Priorité la plus basse
• pas de scan si il est sur batterie est qu’il reste moins de 20% de celle-ci
• Si un scan est raté, il est joué au prochain démarrage

Serveurs:

• Scan le dimanche midi
• Priorité la plus basse
• Si un scan est raté, il est joué au prochain démarrage

Le risque est que les utilisateurs éteignent leur stations le soir, et qu’ils aient donc un scan au démarrage tous les jours.

Cependant, je pense que c’est à l’informatique de gérer l’allumage/extinction des ordinateurs via un outil de gestion de parc. L’idée est de pouvoir déployer les patchs et applications la nuit sans rater de station (vive le wakeonlan).

Et vous, comment avez-vous programmé votre antivirus ?

Je n’ai pas utilisé mes VM de labo pendant quelque temps juste après les avoir installées..Et voilà que je ne me rappel plus du mot de passe administrateur du domaine… Plutôt que de réinstaller, j’ai trouvé un hack pour Vista , que j’ai réutilisé pour mon DC Windows Server 2008 ! J’ai juste poussé un peu plus loin en utilisant le DVD officiel d’installation de Windows Server 2008 au lieu de backtrack

Pour les allergiques ou trop pressé pour regarder la vidéo pas à pas, voici ce qu’il faut faire:

• Démarrer sur le DVD d’installation de Windows Server 2008
• Choisir « Réparer votre ordinateur »
• Lancer une cmd
• Aller dans c:\windows\system32
• renommer Utilman.exe en Utilman.exe.bak
• Copier cmd.exe en Utilman.exe
• redémarrer sur Windows
• Faire le raccourci clavier Windows + U devant la fenêtre de logon (lance normalement utilman.exe et donc là cmd.exe)
• net user administrateur Nouveaumotdepasse123
• Se logguer avec le compte administrateur du domaine
• changer le mot de passe
• Redémarrer sur le DVD pour remettre le fichier original Utilman.exe

Les sites demandent donc à s’enregistrer (et payer) afin d’accéder au contenu….

Sauf que pour avoir des visiteurs et donc des clients, il faut que ces questions/réponses soient indexées par les moteurs de recherche comme Google. Hors il n’est pas possible de donner un compte d’accès à ces moteurs de recherches. Il en résulte que pas mal de sites filtrent sur le nom du navigateur (User Agent), afin de laisser le contenu en libre accès aux moteurs de recherche afin d’être indexés. On pourrait penser qu’il suffit d’interdire les moteurs à mettre les pages en cache et que le tour est joué….Pas vraiment.

Pour contourner, cette fausse sécurité, il suffit de présenter son navigateur comme étant googlebot par exemple pour avoir accès à tout le contenu!
Rien de plus facile avec Firefox et l’extension User Agent Switcher!

Si vous avez la flemme de trouver le nom exact pour googlebot ou autre, il vous suffit de nourrir l’extension avec un XML tout prêt: http://techpatterns.com/downloads/firefox/useragentswitcher.xml

Par exemple, le site SQL Server Central implémente cette fausse sécurité.

Solution pour une DSI++: Filtrer aussi sur les adresses IP des moteurs de recherches.

L’erreur de configuration est triviale, mais l’absence d’information sur ce message d’erreur spécifique rend le diagnostique plus loin qu’il ne devrait!

Ce message apparait autant depuis le webvpn, que le client AnyConnect:

Le problème, au moins dans mon cas, était l’absence de groupe de serveurs pour l’authentification (positionné à None au lieu de LOCAL:

Et voilà!

Je vais essayer ici de vous faire une synthèse ici de l’essentiel, avec quelques friandises valant un « ++ »

Gestion des mots de passes

S’il y a bien un sujet où l’on sent la contrainte, c’est bien celui-là. Vous dites « mot de passe » à n’importe qui, il pense tout de suite sécurité! Et d’ajouter « ils doivent faire au moins 14 caractères » pour qu’il vous réponde « c’est sécurisé chez vous! » (suivi d’un regard plein de compassion sur la souffrance que vous devez éprouver!)
Traite de plaisanterie, les mots de passes sont une rempare comme une autre, et ne servent à rien si d’autres mesures ne sont pas là. J’ai déjà traduis un excellent article de Steve Riley, disponible ici

Gestion du mot de passe administrateur local
Le compte administrateur local est difficile à protéger si l’utilisateur est déterminé. Je vois deux grands axes:
-Rendre les choses difficiles pour décourager ou ralentir
-Faire des vérifications périodiques automatiques pour s’apercevoir des fraudes.

Corser le jeu:
-La longueur du mot de passe doit être supérieure à 14 caractères pour empêcher le stockage en LM hash.
-Chaque station doit avoir un mot de passe administrateur différent. Si c’est le même, n’importe qui l’ayant est admin local du parc, ce qui inclus votre station. Trop facile de vous piéger ensuite!
-Désactivez ce compte. Il n’est pas nécessaire en temps normal, et ne peut se verrouiller.
-Mettez un mot de passe bios, là encore un différent par station. N’autorisez que le boot sur disque dur: pas de CD ni clé USB, ni réseau (si possible).
-Imposez les membres des groupes administrateurs et utilisateurs avec pouvoir locaux via GPO (groupes restreints).

Vérifications récurrentes:
-Mettez un script de logon sur le compte administrateur local. Ce script créera un drapeau pour vous indiquer qu’il a été utilisé et quand. Base de registre ou fichier texte au choix.
-Auditez les journaux d’évènements pour des traces suspectes.
-Changez le mot de passe administrateur local tous les X mois. Quand vous le changez, vérifiez que c’est bien toujours l’ancien. Si quelqu’un l’a claqué, vous le saurez.
-Faites des inventaires des logiciels installés sur les stations. Le droit admin local est recherché pour pouvoir installer ce que l’on veut. Surtout sur les portables, que l’on peut amener chez son meilleur amis,l’expert en informatique bien sûr!

Gérer ses admins
En voilà une idée me direz vous… L’époque où l’admin travaillait avec un compte « administrateurs du domaine » en permanence est révolu, du moins d’un point de vue sécurité. Ils doivent avoir deux comptes, un standard pour la bureautique, et un avec pouvoir (genre monlogin-su), pour les opérations nécessitant des droits supplémentaires. Droits supplémentaires ne voulant pas dire forcément « administrateur du domaine »… Un admin SQL n’a pas besoin de ce privilège par exemple.

Le réseau n’est pas dupe

• Filtrez les adresses mac par vlan. Un poste venant de nulle part ne doit pas avoir un bail de votre serveur dhcp, ni pouvoir causer avec le réseau.
• Filtrez les annonces BPDU sur les ports où il n’y pas d’équipement réseaux, activez rootguard si possible.
• Limitez l’accès aux interfaces de gestion des routeurs/switchs/firewall à vos ip d’administrations.
• Telnet est interdit. SSH V2 est votre amis.
• Limitez à une adresse mac par port réseau pour les stations, afin d’empêcher de mettre des hub et autre joyeuseté.
• Installez une solution de type NAP si vous avez des nomades. Interfacez-là avec vos switch si possible.

Firewall sans trou

• Version de l’os/firmware ou logiciel à jour
• Seulement le strict nécessaire est ouvert
• Les règles de type « accept » ne sont pas logguées sauf raison valable
• Si possible, des restrictions horaires sont en place
• Aucun accès TCP direct vers Internet depuis les postes
• Antispoofing actif
• Firewall de type stateful

Spécifiques Windows

• Le compte administrateur du domaine est désactivé
• Les membres du groupe « Administrateurs du domaine » se comptent sur les doigts de la main. Et tous ces comptes ont un mot de passe > 14 caractères, avec expiration
• Les logs de sécurité des DC tiennent plus de 24H (rétention)
• Les eventlogs sont centralisés
• Il n’y a pas de verrouillage sur les comptes après des essais infructueux
• Vous avez un WSUS, et les patchs mensuels de sécurité sont appliqués
• Les machines du domaine sont dans un nuage IPSEC fermé
• Le firewall Windows est actif sur les stations
• Un antivirus à jour est installé
• Le mscache est à zéro si possible, à 1 sur les portables

Spécifiques Unix/Linux
On retrouve ici pas mal de classique…Rappelez-vous qu’un unix/linux par défaut n’est pas plus sûr qu’un Windows…

• Dites au revoir à inetd et tous les r* (rlogin…)
• Dites bonjour à SSH (v2 et pas de login root direct), NFSV3, NIS
• SNMP, oui mais restreint et protégé
• A jour en terme de patch et noyau ! Vous faites le malin avec un uptime de 800 jours ? Ca en dit long sur la fraicheur de votre kernel…
• Centralisation des logs avec syslogs

Les applications Windows

• Vos applications Windows s’appuient sur Active Directory pour l’authentification des utilisateurs…. Avec une authentification transparente (SSO): ++
• Vos applications se basent sur l’appartenance à un ou des groupes AD, et utilise le SID des groupes pour cette vérification
• Elles fonctionnent avec les droits utilisateurs standards Windows. Elles ont un Manifest pour XP et pour Vista.
• Elles ne contiennent pas de comptes d’accès, que ce soit SQL ou autre dans leur configuration.

Les sites Web

• Utilisez des reverse proxy, par exemple Microsoft ISA 2006. Confiez leur la charge SSL, et activez les protections contre les attaques DOS.
• Protégez la chaîne de connexion à la base de donnée en la cryptant
• Si vous avez un formulaire d’authentification:
  • Le nom du formulaire et des champs login/password doivent être dynamiques pour empêcher la saisie semi-automatique
  • La page doit être en SSL
  • Utilisez une procédure stockée pour vérifier la concordance dans la base de donnée.

La messagerie
C’est presque fusionnel avec les utilisateurs…Ils se plaignent de recevoir trop de mail, coupez le serveur, ils hurlent!

• Mettez toutes vos protections antispam le plus en amont possible, si possible sur le premier relais:
  • Whitelist
  • Reverse DNS
  • SPF / SenderID
  • Rbldns multiples
  • vérification dans les bases publiques type chainmail et phising
  • moteur bayésien
  • Gray listing
  • Antivirus
• Si vous avez Outlook, utilisez le SCL pour qu’outlook déplace tout seul ces mail dans « courrier indésirable »

J’ai donc écrit un petit script VBS qui pose la question et enregistre la réponse dans l’eventlog application:

Une possibilité est d’utiliser openSSL, notamment la version pour Windows:

La syntaxe est de la forme:

openssl s_client -connect www.google.fr:443

Par défaut, il négociera la meilleure version. Pour forcer le SSLV2:

openssl s_client -connect www.google.fr:443 -ssl2

Ou au contraire le SSLV3:
openssl s_client -connect www.google.fr:443 -ssl3

Une autre chose intéressante, les ciphers autorisés:

—
Ciphers common between both SSL endpoints:
RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5
EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5
—
SSL handshake has read 1004 bytes and written 239 bytes
—
New, SSLv2, Cipher is DES-CBC3-MD5
Server public key is 1024 bit
Compression: NONE