BigAdmin System Administration Portal
Article de fond
Print-friendly VersionPrint-friendly Version



La traduction de cet article est le résultat du travail effectué par un logiciel de traduction, relu et corrigé par un humain. Elle vous est fournie, pour votre confort, telle quelle. Sun ne fournit aucune garantie et n'assume aucune responsabilité quant à la justesse et/ou la complétude du texte traduit ou de la page entière. Veuillez vous référer aux condition d'utilisation de ce site pour toute question regardant son utilisation et celle de ce logiciel.

 
 

Prévention d'attaques par déni de service dans Sun Java System Messaging Server

Octobre 2006

Cet article décrit certaines des façons d'éviter les attaques par déni de service (DoS) et attaques de spam similaires dans Sun Java System Messaging Server. Cet article vous indique :

  • les techniques courantes pour empêcher les attaques sur le serveur SMTP et les abus d'utilisateurs internes
  • comment réduire les attaques de clients utilisant des connexions ADSL pour envoyer de nombreux messages électroniques directement à la plate-forme à l'aide du courrier de masse

Remarque : n'oubliez pas que pour arrêter les spams, une solution douce peut être souvent plus efficace qu'une solution dure. Utilisons une analogie avec le jujitsu : plutôt que d'essayer de contrer directement le spam, on place un pied vers l'extérieur afin qu'il trébuche dessus (et s'écroule au sol). Pour les spams, cela revient à les laisser entrer tout en les mettant sur la touche (.HELDing il) en piégeant les transactions de spam suspectes (répondant intentionnellement très lentement lors du dialogue SMTP) et en utilisant d'autres solutions logicielles similaires.


À propos des attaques par déni de service

Une attaque DoS se produit lorsqu'une organisation a des difficultés à accéder aux ressources réseau qu'elle utilise normalement. En général, ce service de réseau est le courrier électronique, qui est alors indisponible ou a été déconnecté. Généralement envoyées intentionnellement et dans un but malveillant, ces attaques peuvent également se produire par mégarde, bien que ce soit rare. Une forme courante d'attaque DOS consiste è augmenter le trafic vers une adresse réseau de fa�on qu'il dépasse la capacité de gestion de la mémoire tampon du système. L'effet de cette attaque est d'empêcher l'ouverture de session aux demandes légitimes.


Techniques communes à utiliser

Limiter les connexions d'adresse IP spécifiées aux MTA

Il est possible de limiter le nombre de connexions d'une adresse IP au MTA de Messaging Server à l'aide de la bibliothèque partagée conn_throttle.so de la table de mappage d'accès aux ports. Limitez les connexions par adresses IP particulières peut s'avérer utile pour empêcher l'utilisation d'un trop grand nombre de connexions par ces attaques.

Pour plus d'informations, reportez-vous au chapitre 17, Filtrage du courrier électronique et contrôle d'accèsdu guide d'administration de Sun Java System Messaging Server, 4ème trimestre 2005.

Utilisation du mot-clé de canal holdlimit

Les listes d'adresses de destinataires très longues sont souvent�une caractéristique du spam. Le mot-clé holdlimit indique au MTA que les messages entrants dans le canal et dont le nombre de destinataires est supérieur au nombre spécifié doivent être marqués comme messages .HELD et mis en file d'attente dans le canal  de retraitement (ou tout canal spécifié par le mot-clé expandchannel). Les fichiers apparaîtront comme étant non traités dans la file d'attente en attendant l'intervention manuelle de l'administrateur du MTA.

Reportez-vous au chapitre 12, Configuration des définitions de canal, du guide d'administration de Sun Java System Messaging Server, 4ème trimestre 2005 pour plus d'informations.

Utilisation de conn_throttle à partir d'un mappage FROM_ACCESS

Utilisez conn_throttle à partir d'un mappage FROM_ACCESS plutôt que PORT_ACCESS, puis utilisez des retards $D pour retarder les réponses SMTP et/ou $H pour retenir (.HELD) les messages entrants au lieu de seulement les rejeter ($N) une fois la limite d'étranglement atteinte.

Une autre approche consiste à retarder et/ou retenir les messages lorsque qu'un niveau de seuil�"début de suspicion"�est atteint, puis de les rejeter è partir du seuil plus élevé "attaque certaine".

Reportez-vous au chapitre 17, Filtrage des messages et contrôle d'accès, du guide d'administration de Sun Java System Messaging Server, 4ème trimestre 2005 pour plus d'informations.

Utilisation des mots-clés de canal alternatechannel et alternaterecipientlimit

L'agent MTA fournit la possibilité de rediriger vers un autre canal de destination les messages dépassant  une limite spécifiée de nombre de destinataires, de taille de message ou de lignes de messages. Ceci est�implémenté sous la forme de l'ensemble des mots-clés de canal suivants : alternatechannel, alternateblocklimit,alternatelinelimit et alternaterecipientlimit, pouvant être placés sur tout canal de destination. Tout message dépassant un de ces seuils sera placé en file d'attente sur le canal alternatif au lieu�du canal de destination d'origine.

Utilisez les mots-clés de canal alternatechannel et alternaterecipientlimit pour forcer le routage des copies de messages ayant un grand nombre de destinataires vers un autre canal de destination (qui est peut-être configuré pour traiter les messages en les filtrant davantage grâce à un paramètre de limitation de tâches plus restrictif ou aux heures "hors-pointe" de la journée).

Reportez-vous à la section intitulée "Limitations des messages, quotas, destinataires et tentatives d'authentification" du chapitre 12, Configuration des définitions de canal, du guide d'administration de Sun Java System Messaging Server, 4ème trimestre 2005 pour plus d'informations.

Implémentation de l'utilisation de l'authentification SMTP

L'authentification SMTP, ou authentification SMTP (RFC 2554) est la méthode favorite pour sécuriser le serveur relais SMTP. Utilisez l'authentification SMTP pour envoyer des messages, enregistrer l'expéditeur authentifié (LOG_USERNAME=1 dans le fichier option.dat fichier) et imposer des sanctions à tout expéditeur de spam.

Reportez-vous au chapitre 19, Configuration de la sécurité et contrôle des accès du guide d'administration de Sun Java System Messaging Server, 4ème trimestre 2005 et au chapitre 13, Planification de la sécurité de Messaging Server du guide de planification du déploiement de Sun Java System Communications Services 2005, 4ème trimestre pour de plus amples informations.

Configuration du nombre limite de destinaires par canal

La configuration d'un nombre limite de destinataires à l'aide des commandes recipientlimit et recipientcutoff. recipientlimit permet d'indiquer le nombre total de destinataires qui vont être acceptés pour le message. recipientcutoff et compare avec la valeur spécifiée le nombre total de destinataires qui ont été présentée au MTA. Aucun message n'est accepté pour la livraison si la limite de la valeur est dépassée. Les deux mots-clés acceptent un seul argument de nombre entier. La valeur par défaut pour les deux est infinie à moins que le mot-clé de canal correspondant ne soit spécifié.

Les limites de destinataires peuvent également être définies sur un expéditeur ou un domaine d'expéditeur. Cette opération est effectuée en spécifiant un utilisateur ou attribut LDAP de domaine avec l'option MTA appropriée : LDAP_RECIPIENTLIMIT, LDAP_RECIPIENTCUTOFF,LDAP_DOMAIN_ATTR_RECIPIENTLIMIT, LDAP_DOMAIN_ATTR_RECIPIENTCUTOFF puis en ajoutant l'attribut à l'entrée utilisateur de l'expéditeur ou à l'entrée de domaine.

Cette technique peut être contreproductive, sauf si vous pensez également imposer des limites de transactions et/ou d'autres restrictions. Sinon, la simple limitation du nombre de destinataires par transaction peut supprimer les indices annonçant un spam.

Remarque : ces mots-clés ont été introduits dans Messaging Server 6 et n'existent pas pour les installations de Messaging Server 5.

Reportez-vous à la section intitulée "Limitations des messages, quotas, destinataires et tentatives d'authentification" du chapitre 12, Configuration des définitions de canal, du guide d'administration de Sun Java System Messaging Server, 4ème trimestre 2005 pour plus d'informations.

Rechercher des noms d'hôte appropriés dans le courrier de masse

Vérifiez si un nom d'hôte approprié est contenu dans la première ligne des courriers de masse. Si non, piégez-les (ou exécutez la commande HELD pour les rejeter).

Remarque : cette fonction a été introduite dans Messaging Server 6 afin  que la table de mappage FROM_ACCESS inclue le nom d'hôte présenté.

Configuration des packages de filtrage anti-spam

Ajouter un package tiers de filtrage anti-spam pour le déploiement de Messaging Server. Par exemple, SpamAssassin est un logiciel libre. Mais d'autres choix existent.  

Reportez-vous au chaptitre 14, Intégration de programmes de filtrage de spam et virus dans Messaging Server, du guide d'administration de Sun Java System Messaging Server, 4ème trimestre 2005 pour plus d'informations.

Recherche et suppression du spam sur le système

Utilisez la commande imsimta qtop (puis la  commande imsimta qclean) pour trouver (puis supprimer) le spam qui a été transmis au système et est toujours dans les files d'attente des canaux de l'agent MTA.


Améliorations futures dans la prochaine version de Messaging Server

Une nouvelle fonction MeterMaid est prévue dans la prochaine version de Messaging Server qui fournit une fonction similaire à la commande conn_throttle, mais s'étend sur l'intégralité du  déploiement de Messaging Server (plusieurs hôtes et plusieurs processus serveur SMTP par hôte qui accèdent au même référentiel d'informations de limitation de requêtes ), contrairement à la commande conn_throttle où les informations sont traitées par processus ( ainsi, avec la commande conn_throttle, un spammeur qui se reconnecte à un autre processus de serveur SMTP peut de nouveau envoyer des messages).


Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.


BigAdmin
  
 
BigAdmin Upgrade Hub