Aller au contenu principal

7. Considérations de sécurité (Security Considerations)

7.1. Sécurité du courrier et usurpation d'identité (Mail Security and Spoofing)​

Le courrier SMTP n'est pas intrinsèquement sécurisé en raison de :

  • Manque de mécanismes d'authentification intégrés
  • Facilité d'usurpation des adresses d'expéditeur
  • Absence de chiffrement dans le protocole de base

Les adresses MAIL FROM et RCPT TO peuvent être facilement usurpées. Des protocoles supplémentaires comme SPF, DKIM et DMARC aident à atténuer l'usurpation d'identité (spoofing), mais ceux-ci ne font pas partie du cœur de SMTP.

7.2. Copies "aveugles" ("Blind" Copies)​

Les destinataires BCC (Blind Carbon Copy, Copie Carbone Invisible) NE DOIVENT PAS (MUST NOT) apparaître dans les en-têtes du message. Ceci est généralement géré en :

  • Créant des transactions SMTP séparées pour les destinataires BCC
  • Supprimant les champs d'en-tête BCC avant l'envoi

7.3. VRFY, EXPN et sécurité (VRFY, EXPN, and Security)​

Les commandes VRFY (vérification) et EXPN (expansion) peuvent être utilisées pour collecter des adresses e-mail valides. Les serveurs PEUVENT (MAY) :

  • Désactiver ces commandes
  • Exiger une authentification avant utilisation
  • Retourner des réponses génériques qui ne confirment pas la validité de l'adresse

7.4. Reroutage du courrier basé sur les codes de réponse 251 et 551 (Mail Rerouting Based on the 251 and 551 Response Codes)​

Les codes de réponse 251 (utilisateur non local, transférera) et 551 (utilisateur non local) peuvent être exploités pour :

  • Découvrir les adresses de transfert
  • Collecte d'adresses
  • Analyse de trafic

Les serveurs DEVRAIENT (SHOULD) être prudents quant au transfert automatique et aux informations divulguées dans ces réponses.

7.5. Divulgation d'informations dans les annonces (Information Disclosure in Announcements)​

Les salutations du serveur (réponse 220) et les réponses EHLO NE DEVRAIENT PAS (SHOULD NOT) divulguer :

  • Informations détaillées sur la version du logiciel
  • Architecture système interne
  • Détails de configuration de sécurité

Les attaquants peuvent utiliser ces informations pour cibler des vulnérabilités connues.

7.6. Divulgation d'informations dans les champs de traçage (Information Disclosure in Trace Fields)​

Les champs d'en-tête Received contiennent :

  • Adresses IP
  • Noms d'hôte
  • Informations de chronologie
  • Topologie du réseau interne

Bien que nécessaires pour le débogage, ces informations peuvent être utilisées pour :

  • Cartographie du réseau
  • Analyse de trafic
  • Identification de l'infrastructure de sécurité

7.7. Divulgation d'informations dans le transfert de messages (Information Disclosure in Message Forwarding)​

Lors du transfert de messages, les serveurs DEVRAIENT (SHOULD) :

  • Éviter de divulguer les adresses internes
  • Assainir les informations de traçage lors du passage des limites de confiance
  • Considérer les implications de confidentialité du transfert automatique

7.8. Résistance aux attaques (Resistance to Attacks)​

Les serveurs SMTP DEVRAIENT (SHOULD) implémenter des protections contre :

Déni de service (Denial of Service, DoS)​

  • Limites de connexion par source
  • Limitation de débit
  • Limites de consommation de ressources
  • Application de délais d'expiration

Dépassements de tampon​

  • Validation stricte des entrées
  • Application de limites de longueur
  • Gestion de chaînes sécurisée

Injection de commandes​

  • Analyse appropriée des commandes
  • Validation des arguments
  • Rejet des entrées mal formées

Attaques de collecte d'annuaire​

  • Limitation de débit des commandes RCPT TO
  • Réponses retardées ou génériques
  • Journalisation et blocage du comportement de scan

7.9. Portée d'opération des serveurs SMTP (Scope of Operation of SMTP Servers)​

Les serveurs SMTP DEVRAIENT (SHOULD) :

  • Définir clairement leur portée d'opération
  • Implémenter des contrôles d'accès appropriés
  • Distinguer entre :
    • Soumission de messages internes
    • Relais de messages externes
    • Livraison finale de messages

Les relais ouverts (open relays) (serveurs qui acceptent et transfèrent le courrier de n'importe qui vers n'importe où) NE DOIVENT PAS (MUST NOT) être déployés car ils :

  • Permettent la distribution de spam
  • Facilitent les abus
  • Nuisent à l'infrastructure de courrier Internet

Pratiques de sécurité recommandées​

  1. Utiliser TLS/STARTTLS : Chiffrer les connexions lorsque possible
  2. Implémenter l'authentification : Exiger SMTP AUTH pour la soumission de messages
  3. Déployer SPF/DKIM/DMARC : Ajouter l'authentification de l'expéditeur
  4. Limitation de débit : Prévenir les abus et les attaques DoS
  5. Contrôles d'accès : Restreindre correctement l'accès au relais
  6. Journalisation : Maintenir des journaux détaillés pour l'analyse de sécurité
  7. Mises à jour régulières : Appliquer les correctifs de sécurité rapidement
  8. Surveillance : Détecter et répondre aux activités suspectes
Dernière mise à jour le