Campaign Classic - Liste de contrôle relative à la sécurité et à la confidentialité

Ce document présente les éléments essentiels à contrôler en ce qui concerne la sécurité et la confidentialité.

Pensez à consulter les documents de présentation de la conformité Adobe Marketing Cloud et de présentation de la sécurité Adobe Campaign.

Dernière mise à jour : 18/07/2019

Gestion des accès

La gestion des accès joue un rôle important dans le renforcement de la sécurité. Vous trouverez ci-dessous quelques-unes des principales bonnes pratiques à appliquer.

  • Créez suffisamment de groupes de sécurité.
  • Vérifiez que chaque opérateur dispose des droits d'accès adéquats.
  • Evitez d'utiliser l'opérateur admin et d'ajouter trop d'opérateurs au groupe admin.

Pour plus d'informations, reportez-vous à la documentation : Droits d'accès et Propriétés d'accès des dossiers.

En savoir plus

Développement

Lorsque vous effectuez des tâches de développement dans Adobe Campaign (workflows, Javascript, JSSP, etc.), suivez toujours ces instructions :

  • Scripts : essayez d'éviter d'utiliser des instructions SQL. Utilisez des fonctions paramétrables plutôt que la concaténation de chaîne et évitez toute injection SQL en whitelistant les fonctions SQL à utiliser.
  • Sécuriser le modèle de données : utilisez des droits nommés pour limiter les actions des opérateurs et ajoutez des filtres système (sysFilter).
  • Ajouter des captchas dans les applications web : découvrez comment ajouter des captchas dans vos pages d'inscription et landing pages publiques.
En savoir plus

Réseau, base de données et SSL/TLS

Le paramétrage du réseau est un élément très important que vous devez vérifier lorsque vous déployez un type d'architecture on-premise.

Vérifiez que le serveur Tomcat N'EST PAS directement accessible en dehors du serveur :

  • Fermez le port Tomcat (8080) sur les adresses IP externes (doit fonctionner sur localhost).
  • Ne mappez pas le port HTTP standard (80) sur le port Tomcat (8080).

Si possible, utilisez un canal sécurisé : POP3S au lieu de POP3 (ou POP3 sur TLS).

Pour obtenir des informations détaillées sur la configuration de SSL/TLS et de la base de données, cliquez sur le bouton En savoir plus.

En savoir plus

Paramétrage du serveur

Le paramétrage doit être effectué sur tous les serveurs. Les fichiers de configuration sont du type serverConf.xml et config-<instance>.xml. Voici les éléments essentiels qui doivent être vérifiés :

  • Zone de sécurité : configurez les zones de sécurité afin qu'elles prennent en compte directement les adresses IP des clients d'un proxy.
  • Protection des téléchargements de fichiers : limitez les types de fichiers pouvant être téléchargés sur le serveur Adobe Campaign grâce à un nouvel attribut uploadWhiteList, utilisable dans le fichier de configuration du serveur.
  • Relais : affinez le paramétrage des relais en désactivant les règles de relais pour les modules/applications inutilisés.
  • Protection des connexions sortantes et restriction des commandes (côté serveur)
  • Vous pouvez également ajouter des en-têtes HTTP supplémentaires et activer les options checkIPConsistent, enableTLS, sessionTimeOutSec, etc.

Pour plus d'informations, reportez-vous à la documentation.

En savoir plus

Paramétrage du serveur Web

Voici certaines des principales bonnes pratiques relatives au paramétrage du serveur web :

  • Modifiez les pages d'erreur par défaut.
  • Désactivez l'ancienne version de SSL et les chiffrements.
  • Supprimez la méthode TRACE.

En savoir plus

Des questions ? Visitez notre forum et échangez avec la communauté.

Suivez Adobe Experience Cloud sur les réseaux sociaux

Copyright © Adobe 2019

Gestion des accès

Close

Gestion des accès

L'opérateur webApp par défaut est un administrateur. Pour renforcer la sécurité, suivez les instructions suivantes :

  • Vous devez remplacer le droit nommé de cet opérateur par un autre (que vous pouvez appeler 'webapp'). Pour plus d'informations, reportez-vous à la documentation.
  • Ajoutez l'opérateur webApp à des dossiers (principalement des dossiers de destinataires) pour accorder un accès en lecture/écriture aux destinataires (voir la documentation).
  • Si vous utilisez une instance multimarque (ou multizone), vous souhaiterez peut-être répartir l'accès aux applications web entre différents dossiers de destinataires :
    • Dupliquez l'opérateur webApp et attribuez un nom aux doublons ('webapp_marque1' et 'webapp_marque2, par exemple).
    • Dupliquez un modèle d'application web pour disposer d'un modèle par marque et éditez les propriétés pour changer l'opérateur en sélectionnant l'option Utiliser un compte spécifique (voir la documentation).

Créez suffisamment de groupes de sécurité afin de donner aux opérateurs des droits suffisants pour qu'ils puissent effectuer les opérations nécessaires (et pas davantage).

N'utilisez pas l'opérateur admin (ou ne le partagez pas). Créez un opérateur par utilisateur physique (pour des logs et un suivi précis). Ajoutez les admirateurs nouvellement nommés au groupe admin. Si vous n'utilisez pas l'opérateur admin, ne le supprimez pas et ne le désactivez pas (cet opérateur est utilisé en interne pour exécuter le traitement). Vous pouvez toutefois interdire son accès depuis la console cliente (voir la documentation) et restreindre sa zone de sécurité (à localhost).

Evitez d'ajouter trop d'opérateurs au groupe admin (ou avec des droits nommés admin). Il s'agit d'opérateurs très puissants (ils peuvent effectuer toutes les instructions SQL, exécuter des commandes sur le serveur, etc.).

Adobe Campaign propose trois privilèges de niveau supérieur (droits nommés) :

  • admin : donne accès à tout et permet d'effectuer toutes les tâches (contourne les contrôles des droits nommés). Il comprend donc les droits nommés createProcess et SQL.
  • createProcess : permet d'exécuter des programmes externes (sur le serveur).
  • sql : permet d'exécuter des scripts SQL sur la base de données (ce privilège peut donc contourner le modèle de sécurité). Remarque : si vous devez effectuer des calculs complexes (des filtrages, par exemple), vous pouvez demander à l'administrateur de la base de données de créer une fonction SQL et de la whitelister (voir la section « Développement »).
  • Accordez ces privilèges à un nombre très limité d'opérateurs (de confiance).

Développement

Close

Développement

Scripts

Pour plus d'informations, reportez-vous à la documentation JSAPI Campaign.

Si vous écrivez un script à l'aide d'un workflow, d'applications web ou de jssp, suivez ces bonnes pratiques :

  • Evitez autant que possible d'utiliser des instructions SQL.
  • Utilisez des fonctions (instruction prepare) paramétrables au lieu de la concaténation de chaîne.
    • Mauvaise pratique :
                                    
      sqlGetInt( "select iRecipientId from NmsRecipient where sEmail ='" + request.getParameter('email') +  "'  limit 1" )
      
                                 
    • Bonne pratique :

                                    
      sqlGetInt( "select iRecipientId from NmsRecipient where sEmail = $(sz) limit 1", request.getParameter('email'));
      
                                 

Avertissement : sqlSelect ne prend pas en charge cette fonctionnalité. Vous devez donc utiliser la fonction de requête de la classe DBEngine :

                  
var cnx = application.getConnection() 
var stmt = cnx.query("SELECT sFirstName, sLastName FROM NmsRecipient where sEmail = $(sz)", request.getParameter('email'))
for each(var row in stmt) logInfo(row[0] + " : " + row[1]) 
cnx.dispose()

               

Pour éviter les injections SQL, les fonctions SQL doivent être whitelistées afin d'être utilisées dans Adobe Campaign. Une fois whitelistées, ces fonctions deviennent visibles par les opérateurs dans l'éditeur d'expression. Pour plus d'informations, reportez-vous à la documentation. Avertissement : si vous utilisez un build antérieur au build 8140, l'option XtkPassUnknownSQLFunctionsToRDBMS peut être définie sur '1'. Si vous souhaitez protéger votre base de données, supprimez cette option (ou définissez-la sur '0').

Si vous utilisez des saisies utilisateur pour créer des filtres dans des requêtes ou des instructions SQL, vous devez toujours les placer dans une séquence d'échappement (reportez-vous à la documentation JSAPI Campaign - Protection des données : fonctions d'échappement). Ces fonctions sont les suivantes :

  • NL.XML.escape(data)
  • NL.SQL.escape(data)
  • NL.JS.escape(data)
  • NL.XML.escapeAttribute(data)

Sécuriser votre nouveau modèle de données

Basé sur les dossiers

Reportez-vous à la documentation :

Droits nommés

En plus du modèle de sécurité basé sur les dossiers, vous pouvez utiliser des droits nommés pour limiter les actions des opérateurs :

Vous pouvez ajouter des filtres système (sysFilter) pour empêcher tout accès en lecture/écriture à vos données. Reportez-vous à la documentation.

                  
<sysFilter name="writeAccess">     
    <condition enabledIf="hasNamedRight('myNewRole')=false" expr="FALSE"/>   
</sysFilter>

               

Vous pouvez également protéger certaines actions (méthode SOAP) définies dans les schémas. Il suffit de définir l'attribut access avec le droit nommé correspondant comme valeur (voir la documentation) :

                  
<method name="grantVIPAccess" access="myNewRole">
      <parameters>
...
      </parameters>
    </method>

               

Avertissement : vous pouvez utiliser des droits nommés dans le nœud command d'un navtree. Cela offre une meilleure expérience utilisateur, mais ne fournit aucune protection (utilisez uniquement le côté client pour les masquer/les activer). Vous devez utiliser l'attribut access.

Autres

Si vous devez protéger des données confidentielles (partie d'un schéma) en fonction du niveau d'accès des opérateurs, ne les masquez pas dans la définition du formulaire (conditions enabledIf/visibleIf). L'entité entière est chargée par l'écran. Vous pouvez également les afficher dans la définition de colonne. Pour ce faire, vous devez créer une table d'Overflow. Pour plus d'informations, reportez-vous à la documentation.

Ajouter des captchas dans les applications web

Il est recommandé d'ajouter un captcha dans les landing pages/pages d'inscription publiques. Il est cependant relativement difficile de le faire dans les pages du DCE (Digital Content Editor). Nous allons vous expliquer dans cette section comment ajouter un captcha v5 ou un reCAPTCHA Google.

La méthode générale pour ajouter un captcha dans le DCE consiste à créer un bloc de personnalisation pour l'inclure facilement dans le contenu de la page. Vous devrez ajouter une activité Script et une activité Test.

Bloc de personnalisation

  1. Accédez à Ressources > Gestion de campagne > Blocs de personnalisation et créez un bloc de personnalisation.
  2. Utilisez le type de contenu Application web et cochez l'option Afficher dans les menus de personnalisation.

Pour plus d'informations, consultez la documentation.

Voici un exemple de captcha Campaign :

                  
<%
var captchaID = CaptchaIDGen();
%>
<img src="/nms/jsp/captcha.jsp?captchaID=<%=captchaID%>&width=200&height=50&minWordSize=8&maxWordSize=8"/>
<input id="captchaValue" name="captchaValue" <%= String(ctx.vars.captchaValid) === "false" ? class="ui-state-error" : "" %>>
<input type="hidden" name="captchaID" value="<%=captchaID%>"/>
<%
if( serverForm.isInputErroneous("captchaValue") ) {
%>
<script type="text/javascript">  
$("#captchaValue").addClass("ui-state-error")
</script>
<%
}
%>
               

Les lignes 1 à 6 génèrent toutes les entrées requises.

La ligne 7 et les lignes suivantes jusqu'à la dernière gèrent les erreurs.

La ligne 4 permet de changer la taille du cadre gris du captcha (width/height) et la longueur du mot généré (minWordSize/maxWordSize).

Avant d'utiliser un reCAPTCHA Google, vous devez vous enregistrer sur Google et créer un site reCAPTCHA : https://www.google.com/recaptcha/admin

                  
<div class="g-recaptcha" data-sitekey="YOUR_SITE_KEY"></div>
               

Vous devriez être en mesure de désactiver le bouton de validation, mais comme il n'existe pas de bouton/lien standard, il est préférable de le faire dans le code HTML. Pour en savoir plus, consultez le site suivant : https://developers.google.com/recaptcha/

Mettre à jour votre application web

  1. Accédez aux propriétés de votre application pour ajouter une variable booléenne nommée captchaValid.

  2. Entre la dernière page et l'activité Enregistrement, ajoutez une activité Script et une activité Test. Reliez la branche Vrai à l'activité Enregistrement et l'autre extrémité de la branche à la page qui contiendra le captcha.

  3. Editez la condition de la branche Vrai avec "[vars/captchaValid]" est égal à Vrai.

  4. Editez ensuite l'activité Script (le contenu dépendra du moteur de captcha sélectionné).
  5. Enfin, vous pouvez ajouter votre bloc de personnalisation dans la page DCE. Voir à ce propos la documentation.

    AVERTISSEMENT : Pour l'intégration de reCAPTCHA, vous devez ajouter un script JavaScript dans le code HTML (entre <head>...</head>):

                            
    <script src="https://www.google.com/recaptcha/api.js" async defer></script>
                         

Captcha Campaign

                  
var captchaID = request.getParameter("captchaID");
var captchaValue = request.getParameter("captchaValue");
 
if( !CaptchaValidate(captchaID, captchaValue) ) {
  serverForm.logInputError("captchaValue",
                           "Les caractères que vous avez saisis pour le captcha doivent correspondre à ceux de l'image.",
                           "captchaValue")
  ctx.vars.captchaValid = false
}
else
  ctx.vars.captchaValid = true
               

Ligne 6 : vous pouvez mettre n'importe quel type de message d'erreur.

reCAPTCHA Google

Veuillez consulter la documentation officielle.

                  
ctx.vars.captchaValid = false
var gReCaptchaResponse = request.getParameter("g-recaptcha-response");
 
// Call reCaptcha API to validate it
var req = new HttpClientRequest("https://www.google.com/recaptcha/api/siteverify")
req.method = "POST"
req.header["Content-Type"] = "application/x-www-form-urlencoded"
req.body = "secret=YOUR_SECRET_HERE&response=" + encodeURIComponent(gReCaptchaResponse)
req.execute()
var response = req.response
if( response.code == 200 ) {
  captchaRes = JSON.parse(response.body.toString(response.codePage));
  ctx.vars.captchaValid = captchaRes.success
}
 
if( ctx.vars.captchaValid == false ) {
  serverForm.logInputError("reCaptcha",
                           "Veuillez valider le captcha",
                           "reCaptcha")
  logInfo("reCaptcha not validated")
}

               

Pour utiliser JSON.parse, vous devez inclure "shared/json2.js" dans votre webApp :

Depuis le build 8797, pour utiliser l'URL de l'API de vérification, vous devez la mettre en whiteliste dans serverConf en l'ajoutant dans le nœud urlPermission :

                  
<url dnsSuffix="www.google.com" urlRegEx="https://www.google.com/recaptcha/api/siteverify"/>
               

Base de données et SSL/TLS

Close

Base de données et SSL/TLS

Base de données

Vous devez impérativement suivre les instructions de sécurité de votre moteur de base de données.

Configuration de SSL/TLS

Pour vérifier le certificat, vous pouvez utiliser openssl. Pour contrôler les chiffrements actifs, vous pouvez avoir recours à nmap :

                  
#!/bin/sh
#
# usage: testSSL.sh remote.host.name [port]
#
REMHOST=$1
REMPORT=${2:-443}

echo |\
openssl s_client -connect ${REMHOST}:${REMPORT} -servername ${REMHOST} 2>&1 |\
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' |\
openssl x509 -noout -subject -dates
  
nmap --script ssl-enum-ciphers -p ${REMPORT} ${REMHOST}

               

Vous pouvez également utiliser un script Python sslyze qui effectue les deux vérifications.

                  
python sslyze.py --sslv2 --sslv3 --tlsv1 --reneg --resum --certinfo=basic --hide_rejected_ciphers --sni=SNI myserver.com


               

Paramétrage du serveur Adobe Campaign

Close

Paramétrage du serveur Adobe Campaign

Vous trouverez ci-dessous des informations supplémentaires sur le paramétrage du serveur Adobe Campaign.

Paramétrage des zones de sécurité

Pour découvrir comment utiliser l'interface utilisateur de Security Zones Self Service pour gérer les entrées dans le paramétrage des zones de sécurité VPN, consultez cette technote.

Vérifiez que le proxy inverse n'est pas autorisé dans subNetwork. Si c'est le cas, l'ensemble du trafic est détecté comme provenant de cette adresse IP locale et est donc considéré comme digne de confiance.

Limitez l'utilisation de sessionTokenOnly="true" :

  • Avertissement : si cet attribut est défini sur true, l'opérateur peut être exposé à une attaque CRSF.
  • De plus, le cookie sessionToken n'étant pas défini avec un flag httpOnly, certains codes JavaScript côté client peuvent le lire.
  • L'utilisation de Message Center avec plusieurs instances d'exécution requiert toutefois l'activation de l'option sessionTokenOnly : créez une nouvelle zone de sécurité avec l'option sessionTokenOnly définie sur "true" et ajoutez uniquement les adresses IP nécessaires à cette zone.

Si possible, définissez les attributs allowHTTP et showErrors sur la valeur false (pas pour localhost) et vérifiez-les.

  • allowHTTP = "false" : force les opérateurs à utiliser le protocole HTTPS.
  • showErrors = "false" : masque les erreurs techniques (y compris celles de SQL). Cet attribut empêche l'affichage d'un trop grand nombre d'informations, mais il limite la possibilité des marketeurs de corriger les erreurs (sans demander des informations supplémentaires à un administrateur).

Définissez allowDebug sur true uniquement sur les adresses IP utilisées par les utilisateurs marketing/administrateurs qui doivent créer (ou plutôt prévisualiser) des questionnaires, webApps et rapports. Ce flag permet d'afficher les règles de relais et de les déboguer pour ces adresses IP.

Ne définissez jamais les attributs allowEmptyPassword, allowUserPassword et allowSQLInjection sur true. Ils ne servent qu'à faciliter la migration depuis la v5 vers la v6.0 :

  • L'attribut allowEmptyPassword permet aux opérateurs de disposer d'un mot de passe vide. Si c'est votre cas, demandez à tous les opérateurs de définir un mot de passe avec un délai. Une fois ce délai passé, définissez cet attribut sur la valeur false.
  • L'attribut allowUserPassword permet aux opérateurs d'envoyer leurs identifiants en tant que paramètres (afin qu'ils puissent être connectés par Apache/IIS/un proxy). Cette fonctionnalité était auparavant utilisée pour simplifier l'utilisation de l'API. Vous pouvez vérifier dans votre « livre de recettes » (ou dans les spécifications) si des applications tierces utilisent cet attribut. Si c'est le cas, vous devez demander à ces tiers de changer la façon dont ils utilisent notre API et supprimer cette fonctionnalité dès que possible.
  • L'attribut allowSQLInjection permet à l'utilisateur d'effectuer des injections SQL en utilisant une ancienne syntaxe. Apportez dès que possible les corrections présentées dans la documentation pour pouvoir définir cet attribut sur false.

Vous pouvez utiliser /nl/jsp/ping.jsp?zones=true pour vérifier le paramétrage de votre zone de sécurité. Cette page affiche l'état actif des mesures de sécurité (calculé avec ces flags de sécurité) pour l'adresse IP actuelle.

Cookie HttpOnly/useSecurityToken : reportez-vous au flag sessionTokenOnly.

Limitez les adresses IP whitelistées : par défaut, dans les zones de sécurité, nous avons ajouté les 3 plages pour les réseaux privés. Il est peu probable que vous utiliserez toutes ces adresses IP. Ne conservez donc que celles dont vous avez besoin.

Mettez à jour l'opérateur interne/webApp pour qu'il soit accessible uniquement dans localhost.

Protection des téléchargements de fichiers

Demandez aux utilisateurs quels types de fichiers ils téléchargent sur le serveur à l'aide de l'interface web/nlclient. Pour rappel, les besoins de l'entreprise peuvent être les suivants :

  • des images (jpg, gif, png, etc.),
  • des contenus (zip, html, css, etc.),
  • des ressources marketing (doc, xls, pdf, psd, tiff, etc.),
  • des pièces jointes à des emails (doc, pdf, etc.),
  • des fichiers ETL (txt, csv, tab, etc.)
  • etc.

Ajoutez tous ces types de fichiers dans serverConf/shared/datastore/@uploadWhitelist (expression régulière Java valide) : reportez-vous à la documentation.

Adobe Campaign ne limite pas la taille des fichiers, mais vous pouvez la limiter en configurant IIS/Apache (voir le paragraphe correspondant).

Relais

Pour plus d'informations, reportez-vous à la documentation.

Par défaut, toutes les pages dynamiques sont relayées automatiquement au serveur Tomcat local de la machine dont le module Web est démarré. Vous pouvez choisir de ne pas relayer certaines d'entre elles. Si vous n'utilisez pas certains modules d'Adobe Campaign (tels que webapp, interaction, certaines pages jsp), vous pouvez les supprimer des règles de relais.

Nous avons forcé la possibilité d'afficher par défaut les ressources des utilisateurs finaux à l'aide de HTTP (httpAllowed="true"). Comme ces pages peuvent afficher certaines PII (contenu/adresse email), un bon d'échange ou une offre, vous devez forcer de nouveau HTTPS sur ces chemins.

Si vous utilisez des noms d'hôte différents (un nom d'hôte public et un nom d'hôte pour les opérateurs), vous pouvez également empêcher le relais de certaines ressources dont les opérateurs ont besoin sur le nom DNS public.

Protection des connexions sortantes

La liste par défaut des URL pouvant être appelées par les codes JavaScript (workflows, etc.) est limitée. Pour autoriser une nouvelle URL, l'administrateur doit la référencer dans le fichier serverConf.xml.

Il existe trois modes de protection des connexions :

  • Blocking (Blocant) : toutes les URL qui ne figurent pas en whiteliste sont bloquées et un message d'erreur s'affiche. Il s'agit du mode par défaut après un postupgrade.
  • Permissive (Permissif) : toutes les URL qui ne figurent pas en whiteliste sont autorisées.
  • Warning (Avertissement) : toutes les URL qui ne figurent pas en whiteliste sont autorisées, mais l'interpréteur JS émet un avertissement pour que l'administrateur puisse les collecter. Ce mode ajoute des messages d'avertissement JST-310027.
                  
<urlPermission action="warn" debugTrace="true">
  <url dnsSuffix="abc.company1.com" urlRegEx=".*" />
  <url dnsSuffix="def.partnerA_company1.com" urlRegEx=".*" />
  <url dnsSuffix="xyz.partnerB_company1.com" urlRegEx=".*" />
</urlPermission>
               

Les nouveaux clients utiliseront le mode bloquant. S'ils souhaitent autoriser une nouvelle URL, ils doivent contacter leur administrateur pour la mettre en whiteliste.

Les clients existants provenant d'une migration peuvent utiliser pendant un certain temps le mode d'avertissement. Ils doivent entre-temps analyser le trafic sortant pour autoriser les URL.

Restriction des commandes (côté serveur)

Plusieurs commandes sont blacklistées et ne peuvent pas être exécutées à l'aide de la fonction execCommand. Une sécurité supplémentaire est fournie par un nouvel utilisateur Unix dédié afin d'exécuter les commandes externes. Pour les installations hébergées, cette restriction est automatiquement appliquée. Pour les installations on-premise, vous pouvez configurer manuellement cette restriction en suivant les instructions de la documentation dédiée. De plus, les activités de workflow Script et Tâche externe ne sont pas disponibles dans les instances nouvellement installées.

Autres paramétrages

Vous pouvez ajouter des en-têtes HTTP supplémentaires (pour toutes les pages). Pour plus d'informations, reportez-vous à la documentation :

  • Vous pouvez ajouter d'autres en-têtes tels que HSTS, X-FRAME-OPTIONS, CSP, etc.
  • Vous devez les tester dans un environnement de test avant de les appliquer en production. AVERTISSEMENT : l'ajout de certains en-têtes peut entraîner un dysfonctionnement d'Adobe Campaign.

Adobe Campaign permet de définir un mot de passe en clair dans l'élément <dbcnx .../>. N'utilisez pas cette fonctionnalité.

Par défaut, Adobe Campaign n'associe pas une session à une adresse IP spécifique, mais vous pouvez activer cette option pour empêcher tout vol de la session. Pour ce faire, dans le fichier serverConf.conf, définissez l'attribut checkIPConsistent (dans le nœud d'authentification) sur true.

Par défaut, le MTA d'Adobe Campaign n'utilise pas de connexion sécurisée pour envoyer du contenu au serveur SMTP. Vous devez activer cette fonctionnalité (ce qui peut réduire la vitesse de diffusion). Pour ce faire, définissez enableTLS sur true dans le nœud <smtp ...>.

Vous pouvez réduire la durée de vie d'une session dans le nœud d'authentification (attribut sessionTimeOutSec).

Paramétrage du serveur Web (Apache/IIS)

Close

Paramétrage du serveur Web (Apache/IIS)

Modifiez les pages d'erreur par défaut.

Désactivez l'ancienne version de SSL et les chiffrements :

  • sur Apache, éditez le fichier /etc/apache2/mods-available/ssl.conf. Voici un exemple :
    • SSLProtocol all -SSLv2 -SSLv3 -TLSv1
    • SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
  • sur IIS, (voir l'article Microsoft KB245030), effectuez la configuration suivante :
    • Ajoutez la sous-clé de registre dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
    • Pour que le système puisse utiliser les protocoles qui ne seront pas négociés par défaut (tels que TLS 1.1 et TLS 1.2), remplacez les données de la valeur DWORD de la valeur DisabledByDefault par 0x0 dans les clés de registre suivantes sous la clé Protocols :

      SCHANNEL\Protocols\TLS 1.1\Client

      SCHANNEL\Protocols\TLS 1.1\Server

      SCHANNEL\Protocols\TLS 1.2\Client

      SCHANNEL\Protocols\TLS 1.2\Server

    • Désactivez SSL x.0 :

      SCHANNEL\Protocols\SSL 3.0\Client : DisabledByDefault : valeur DWORD (32 bits) sur 1

      SCHANNEL\Protocols\SSL 3.0\Server : Enabled : valeur DWORD (32 bits) sur 0

Supprimez la méthode TRACE :

  • sur Apache, éditez le fichier /etc/apache2/conf.d/security : TraceEnable Off
  • sur IIS, (voir la documentation), effectuez la configuration suivante :
    • Vérifiez que la fonctionnalité ou le service de rôle Filtrage des demandes est installé.
    • Dans le volet Filtrage des demandes, cliquez sur l'onglet Verbes HTTP, puis sur Refuser un verbe. Dans le volet Actions, saisissez TRACE dans la boîte de dialogue ouverte.

Supprimez la bannière :

  • sur Apache, éditez le fichier /etc/apache2/conf.d/security :
    • ServerSignature Off
    • ServerTokens Prod
  • sur IIS (voir l'article Microsoft KB317741) :
    • Installez URLScan.
    • Editez le fichier Urlscan.ini afin d'obtenir RemoveServerHeader=1.

Limitez la taille des requêtes pour empêcher le téléchargement de fichiers volumineux :

  • Sur Apache, ajoutez la directive LimitRequestBody (taille en octets) dans le répertoire /. Consultez la documentation.

                            
    <Directory />
            Options FollowSymLinks
            AllowOverride None
            LimitRequestBody 10485760
    </Directory>
                         
  • Sur IIS, définissez maxAllowedContentLength (longueur maximale autorisée du contenu) dans les options de filtrage du contenu. Consultez la documentation).