mai 2011 | Machins de dev

Personnaliser le WebDeploy

Posted on 27 mai 2011Leave a comment

WebDeploy est un outil dans Visual Studio permettant de compiler puis déployer un projet web sur un serveur IIS. Il est très simple d’usage mais… la personnalisation est inexistante.

Compte tenu de la complexité du processus de build des projets .NET et de la qualité de la documentation fournit, ça n’a pas été évident mais j’ai pu finalement cracher ce bout de XML. Il est à ajouter dans le fichier csproj du projet web à la fin.

Voici ce qu’il fait :

On renseigne en paramètre l’exécutable signtool, qui permet de signer numériquement un fichier PE (ça correspond à l’onglet « Signatures numériques » dans les propriétés d’un fichier signé
On renseigne le certificat à utiliser par sa somme de contrôle SHA1
On indique avec un nom de variable particulier le fichier snk contenant les clés pour ajouter un nom fort aux assemblies. Les variables sont KeyOriginatorFile et _FullKeyFile et sont reconnus par le processus de compilation.
Après la compilation normale du projet, on signe le fichier *.dll et les fichiers *.ressources.dll généré par le projet web
Après l’étape 4, on lance la cible MvcBuildViews qui va compiler toutes les vues dans une assembly qui se nomme {nom du projet web}.WebUI.dll. Une fois que c’est fait, on signe également la nouvelle assembly et ses ressources.
Le processus normal reprend et pousser le résultat sur le serveur IIS

<PropertyGroup Condition="Exists('C:\Users\veovis')">
 <Sha1Thumbnail>6b30be2f5fd6cb22225191b803c9232755dc07b8</Sha1Thumbnail>
 <SignAssembly>true</SignAssembly>
 <SignToolLocation>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe</SignToolLocation>
 <AssemblyOriginatorKeyFile>C:\Users\sebastien\Documents\Security\euphor.snk</AssemblyOriginatorKeyFile>
 <_FullKeyFile>$(AssemblyOriginatorKeyFile)</_FullKeyFile>
 <KeyOriginatorFile>$(AssemblyOriginatorKeyFile)</KeyOriginatorFile>
 <DelaySign>false</DelaySign>
 <OnAfterCopyAllFilesToSingleFolderForPackage>
MvcBuildViews;
 </OnAfterCopyAllFilesToSingleFolderForPackage>
</PropertyGroup>
<Target Name="AfterBuild" Condition=" '$(Configuration)' == 'Release' And '$(SignToolLocation)' != ''">
 <ItemGroup>
 <OutputFiles Include="$(TargetPath)"/>
 <OutputFiles Include="$(TargetDir)\*\$(TargetFileName).resources.dll" />
 </ItemGroup>
 <Exec Command="&quot;$(SignToolLocation)&quot; sign /sha1 $(Sha1Thumbnail) /tr &quot;http://www.startssl.com/timestamp&quot; /ph &quot;%(OutputFiles.FullPath)&quot;" />
</Target>
<Target Name="MvcBuildViews">
 <RemoveDir Directories="$(_PackageTempDir)2" />
 <AspNetCompiler VirtualPath="temp" PhysicalPath="$(_PackageTempDir)" Force="true" Updateable="false" FixedNames="true" TargetPath="$(_PackageTempDir)2" />
 <AspNetMerge ExePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools" Nologo="true" SingleAssemblyName="$(TargetName).WebUI" ApplicationPath="$(_PackageTempDir)2" CopyAttributes="true" AssemblyInfo="$(TargetPath)" KeyFile="$(_FullKeyFile)" />
 <ItemGroup>
 <DllFiles Include="$(_PackageTempDir)2\bin\$(TargetName).WebUI.dll" />
 <DllFiles Include="$(_PackageTempDir)2\bin\*\$(TargetName).WebUI.resources.dll" />
 </ItemGroup>
 <Exec Command="&quot;$(SignToolLocation)&quot; sign /sha1 $(Sha1Thumbnail) /tr &quot;http://www.startssl.com/timestamp&quot; /ph &quot;%(DllFiles.FullPath)&quot;" />
 <RemoveDir Directories="$(_PackageTempDir)" />
 <Exec Command="rename &quot;$(_PackageTempDir)2&quot; &quot;PackageTmp&quot;" />
</Target>

Toutes ces étapes ne sont évidemment pas obligatoires et ce fichier DOIT être personnalisé en fonction de son environnement.

Configuration robuste d’un serveur SSL

Posted on 22 mai 2011Leave a comment

En visitant le site cacert.org, notamment pour voir où en était leur intégration dans les différents systèmes d’exploitation et navigateurs, je suis tombé sur Qualys SSL Server Test un site permettant de scanner la partie SSL d’un site web.

Je passe le test pour mon blog, on va voir ce que ça donne…
Pour note, mon blog est desservi par nginx, lui-même linké à openssl pour tous se qui se rapport au chiffrage.
C’est long… et surprise, je décroche un F ! Bravo, je ne peux pas faire pire !

Analysons le résultat :

tout d’abord, mon certificat est trusted, mais il semble qu’il y ait un problème sur la chaîne de certification. Une petite vérification m’a permis de confirmer qu’effectivement le serveur ne contient que le certificat du site et le certificat racine, en oubliant le certificat intermédiaire (chaîne de 3 certificats). Qu’à cela ne tienne, une petite concaténation m’a permis de corriger ce soucis. Le problème que ça aurait pu engendrer est qu’un navigateur qui n’a jamais visité un site certifié par Start SSL (qui est l’entité émettrice de mon certificat) aurait jugé que le certificat n’est pas valide, puisqu’il n’arrive pas à remonter de mon certificat à un des certificats racines du navigateur, vu qu’il lui manque le fameux certificat intermédiaire que je n’ai pas présenté.
second problème, j’ai des algorithmes de chiffrages qui sont considéré insecure. oups ? J’avais pourtant bien restreint les algorithmes à HIGH:-DES pourtant ! Il se trouve après avoir trouvé le dénominateur commun aux algorithmes non secure que le coupable est anonymous DH, ou bien ADH. Je change donc dans nginx la liste des algorithmes autorisés à HIGH:-DES:ADH et je repasse le test… avec succès 🙂 Dans les sources, j’ai pu trouver un lien expliquant de façon succincte pourquoi cette famille d’algorithmes n’est pas sûre : du fait que le Diffie-Hellman est effectué en clair (anonymous), l’échange de clé reste secret (cela est assuré par le procédé Diffie-Hellman), mais n’empêche pas une attaque du milieu, à savoir un agent positionné entre deux participants et qui intercepterait les échanges des deux participant pour proposer ses propres paramètres Diffie-Hellman ; le procédé Diffie-Hellman a été bien réalisé… mais pas avec la bonne personne !
dernier problème, mineur celui-là, l’incapacité à renégocier une session chiffrée. Une petite ligne de configuration à rajouter, plus difficile à trouver cependant. Corrigé, je repasse le test, et cette fois, tout est vert, j’ai un A 🙂

Pour résumer, voici à quoi ressemble la configuration SSL dans le fichier de configuration de nginx :

ssl_ciphers HIGH:-DES:-ADH;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 SSLv3;
ssl_session_cache shared:SSL:1m;

Pour comparer, j’ai balancé le test sur un serveur sous Windows Server 2003, et un autre sous Windows Server 2008 R2, tous deux avec les configurations par défaut.
L’un est catastrophique, l’autre est parfait, plus parfait même que mon nginx tuné, notamment par le support du protocol TLS 1.2.
Il est dommage toutefois de constater le faible choix disponible dans la liste des algorithmes proposés sous Windows Server 2003.
Je vais essayer de désactiver SSLv2 sous Windows Server 2003 et voir ce que cela donne…

Bien que les notes fournies par Qualys puissent paraître sévères en rapport avec le monde réel (qui utilise encore ADH parmi les navigateurs modernes ?), reconfigurer proprement la partie ssl d’un serveur ne mange pas de pain (mis à part le cas IIS où la configuration est on ne peut plus restreinte), alors go on !

Voir aussi

Impact de la virtualisation sur les performances brutes

Posted on 22 mai 2011Leave a comment

Sur les serveurs dédiés sous ma responsabilité, il m’arrive d’y installer un client BOINC. C’est un logiciel qui rapatrie, pour divers projets scientifiques, du travail à effectuer par la machine, laquelle fait alors partie d’une grille de calcul. Bien entendu, BOINC ne travaille que lorsque le serveur ne fait rien, ou plutôt utilise les cœurs non utilisés des CPUs des serveurs. Il n’est pas question que les services en production souffrent de la présence de BOINC. Sous ces conditions, pourquoi pas, ça permet d’utiliser les ressources non utilisées pour une bonne cause, on évite le gâchis.
Ce programme m’a permis de comparer la puissance de calcul brute de plusieurs configuration, sachant que tous les clients BOINC sont configurés pour travailler sur le même projet. En particulier, il y avait deux machines identiques en RAM (non saturées) et en CPU, un Core i5.

L’une de ces machines était sous VMware ESXi avec une seule VM sous Windows Server 2003, l’autre était directement sous Windows Server 2008 R2.
La configuration CPU/RAM identique m’a permis de comparer quantitativement la perte de performance induite par la couche ESXi simplement en regardant le score de BOINC par client.
J’avais entendu parler au cours d’une conférence d’évangélisation que la perte induite par des outils de virtualisation comme VMware Workstation ou Hyper-V R1 était de 15%, tandis que celle de ESXi était seulement de 5%, grâce à son noyau super léger, mais qu’en est-il réellement ?
Pour ce qui est de Workstation, j’en ai aucune idée, je m’en sers que pour le développement donc pas en continue. En revanche on voit une différence de… 15% de entre l’utilisation ou non de VMware ESXi. Wow ! ce n’est pas rien !

On m’aurait menti ? J’ai attendu plusieurs jours pour que le score quotidien des clients BOINC se stabilise et on note toujours cette nette différence de 15%, quelque soit le travail effectué (mais toujours sur le même projet). Il est à noter également que concernant ces deux serveurs, ils ne faisaient quasiment que de l’idle, donc normalement pas perturbés par d’autres processus. C’est un test approximatif et il vaut ce qu’il vaut, mais a l’avantage de donner une assez bonne précision de ce qu’on perd en CPU brut avec cette couche de virtualisation.

Pour autant, la virtualisation n’est pas à jeter, ça dépend de l’utilisation de la machine. Pour mon cas où le CPU est loin d’être le goulet d’étranglement sur ces machines, surtout un Core i5, cette perte est significative, mais acceptable.