Site web: sécurité ou indexation, faut-il choisir ?

Pas mal de sites Web mettent à disposition du contenu sous la forme de forum avec questions/réponses.
Les réponses peuvent-être rémunérées afin de motiver les visiteurs à alimenter le site.

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.

Cisco ASA / VPNSSL: unable to send authentication message.

Si vous mettez en oeuvre un accès distant Cisco « 2.0 », c’est à dire à travers un tunnel SSL, avec ou sans client, vous aurez peut être ce message d’erreur.

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à!

Vers une DSI++: incassable

La sécurité informatique est souvent vue comme une contrainte coûtant de l’argent, ce qui la met en première ligne quand il s’agit de faire des économies. Déjà faut-il encore sortir du clivage « Mon McAffee est mieux que ton Symantec« .
Surtout qu’il s’agit de mesurer un risque et une probabilité, un peu comme une assurance vie…

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 »

Demandez pourquoi vos admins vont sur les serveurs

Je suis tombé sur une question intéressante dans les newsgroups: Demander pourquoi aux admins pourquoi ils ouvrent une session sur un serveur. La personne aurait voulut le faire par GPO, mais cela n’est pas possible. Son objectif était d’avoir quelque chose de similaire au formulaire que windows 2003 affiche quand on veut redémarrer & co.

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

 ‘==========================================================================


‘ NAME: <logger.vbs>

‘ AUTHOR: Mathieu CHATEAU, gollum123@free.fr
‘ DATE  : 11/10/2007

‘ COMMENT: <Ask a reason for logging, then keep a trace in Application eventlog>

‘==========================================================================
option explicit
Dim msg, objshell,UserName
Const EVENT_SUCCESS = 0
Set objShell = Wscript.CreateObject(« Wscript.Shell »)
UserName = objShell.ExpandEnvironmentStrings(« %username% »)
msg = InputBox(« Pourquoi ouvrez-vous une session? »)
if msg = «  » then
msg= »a refuse de dire pourquoi »
end if

objShell.LogEvent EVENT_SUCCESS, UserName &  » a ouvert une session car: » & msg
Set objShell = Nothing

Détecter les versions de SSL acceptées par un serveur web

Il est parfois utile de vérifier quelles versions du protocole SSL sont acceptées par un serveur Web. Les anciennes versions sont considérées faibles et peuvent permettre des attaques de l’homme du milieu & co.

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

ISA 2006 en ferme(array) et le service pack 2 de Windows 2003

Nous avons eu des problèmes entre une ferme ISA 2006 et le Service Pack 2 de Windows 2003.

En labo, nous avons installé d’abord ISA 2006 puis le service pack 2. Aucun problème.

Puis nous avons recommencé, mais en installant d’abord le Service pack 2 puis ISA 2006. Rien à faire, plus rien n’a fonctionné, l’ISA bloquait tous les paquets malgré un classique « allow any any ». La désactivation du RSS n’a rien changé non plus

Politique de mots de passe. Encore une fois.

This article is a translated version of a blog post from Steve Riley. You can read the original version here.

Cet article est une traduction d’un post de Steve Riley, dont vous pouvez lire la version originale ici.

Récemment dans les newsgroups (news:microsoft.public.security, pour être précis), la gestion des mots de passe et leurs paramètres par défaut est ressortie. L’auteur s’est plaint sur un certain nombre de choses : que Microsoft n’active pas le verrouillage de compte par défaut, que nous n’avons pas de mécanisme natif pour désactiver automatiquement les comptes inutilisés, que l’expiration par défaut au bout de 42 jours est troublante. Voici ma réponse ; j’imagine quelle fera un billet très utile en même temps.

Verrouillage de comptes

Le verrouillage de comptes est une faible substitution par rapport aux bons mots de passe – et s’avère être une des plus chère fonctionnalités de sécurité. Imaginons maintenant la menace. Quelle menace essayons-nous de réduire ? La découverte de mots de passe. Comment rendre la découverte de mots passe inutilisable par un pirate ? Deux possibilités : le verrouillage de comptes ou alors un mot de passe de qualité, c’est-à-dire long.

Considérons le premier choix, le verrouillage de comptes. Le coût typique dans une entreprise pour réinitialiser un compte est de 55€ par appel à la hotline. Dans une entreprise de taille moyenne ou importante, cela peut devenir un coût récurrent très important. Dans pratiquement tous les cas, l’appel vient des utilisateurs qui ont eux même verrouillé leur compte (peut être un peu trop d’alcool dans l’avion?), et n’est pas dû à un pirate essayant de découvrir leur mot de passe. Ce verrouillage crée un autre dangereux problème : il offre la possibilité de faire du déni de service sur des comptes voir sur le domaine entier ! Même avec l’utilisation d’un verrouillage temporaire, de 15 minutes par exemple, un attaquant peut écrire un script qui fait des essais toutes les 15 minutes et 2 secondes. En conséquence, contrairement à ce qui est attendu, l’activation de cette fonction peut avoir un impact très néfaste sur le bon fonctionnement.

Le verrouillage de comptes est prévu pour les personnes qui en ont absolument besoin. Mais je n’arrive pas à imaginer aucun cas où cela soit avéré. A la place, créons une politique qui demande des mots de passe simples, d’au moins 15 caractères. Oubliez les règles de complexité qui obligent les utilisateurs à écrire leur mot de passe sur un papier. Une simple « passphrase » (une courte phrase) est facile à se rappeler, rapide à taper, et de loin plus solide que n’importe quel mot de passe complexe mais court. Une courte phrase va résister aux attaques de mots de passe, y compris celles basées sur des « rainbow tables ». Et vous pouvez même utiliser une méthode afin de vous souvenir d’une phrase unique par site si vous le souhaitez :

  • webmail: « mon chien et moi avons du courrier »
  • courses: « mon chien et moi avons acheté des choses »
  • bureau: « mon chien et moi sommes au travail »

C’est la raison pour laquelle nous désactivons par défaut le verrouillage de comptes. Il y a de bien meilleur — et moins cher — moyens de réduire la menace.

Désactiver les comptes inutilisés

Vous avez raison, il n’y a pas de méthode native pour automatiquement désactiver les comptes inutilisés. Plusieurs produits tiers peuvent fournir cette fonctionnalité. Je pense que certains sont gratuits, peut être même un simple script. J’ai lancé une recherche sur « automatiquement désactiver les comptes inutilisés » et j’ai vu quelques liens prometteurs. Cette fonction, particulière, appartient néanmoins au processus des Ressources Humaines. Un certain nombre de clients avec qui j’ai parlé incluent la création/désactivation/suppression de comptes dans leur processus RH. Quand un nouvel utilisateur est embauché, son compte est crée, quand il part, son compte est désactivé, puis supprimé quelque temps après. C’est le système des Ressources Humaines qui s’en charge, et non les administrateurs du domaine ou de l’entreprise. J’ai écris davantage sur ce sujet dans « When you say goodbye to an employee. »

Expiration des mots de passe

L’expiration des mots de passe est un paramètre important pour tout le monde. Cela réduit deux menaces : les collaborateurs qui partagent leur mot de passe, et les pirates qui les découvrent. Parce que nous éliminons la deuxième menace à travers des mots de passe longs et simples comme décris plus haut, nous n’avons plus qu’une seule menace : le partage de mots de passes. Votre estimation de cette menace dans votre environnement vous guidera dans le choix de la durée d’expiration qui vous convient le mieux. 42 jours est une durée par défaut raisonnable ; notre propre réseau a une valeur de 70 jours. Mon expérience avec la plupart des clients montre que le partage de mot de passe n’est pas un problème. Je pense qu’une valeur de 120 jours est raisonnable pour ceux qui rendent obligatoires les mots de passe longs et simples.

Windows commence à vous notifier 14 jours avant l’expiration du mot de passe. Vous pouvez changer ce délai à travers les politiques de groupes. J’ai été récemment dans une situation similaire. Le mois dernier, mon mot de passe du domaine a expiré pendant que j’étais en Australie pour les TechEd. J’ai pu continuer à m’authentifier sur mon portable avec mon compte en cache, mais je ne pouvais plus utiliser Outlook Web Access ou RPC+http. Je me suis donc connecté sur un ordinateur Terminal Serveur que nous avons sur Internet, authentifié dessus, et j’ai changé mon mot de passe.