Quelles sont les meilleures méthodes pour attraper le spam en raquettes?


21

J'utilise Smartermail pour mon petit serveur de messagerie. Nous avons eu récemment un problème pour obtenir des vagues de spam de raquettes qui suivent le même modèle. Ils viennent par lots de 3 ou 4 à la fois. Les corps sont presque identiques, sauf pour le nom de domaine auquel ils sont liés. Les adresses IP source ont tendance à provenir du même bloc / 24 pendant un certain temps, puis elles passent à un autre / 24. Les domaines ont tendance à être flambant neufs. Ils ont des enregistrements PTR et SPF valides et ont du charabia aléatoire au bas du corps pour usurper les filtres bayésiens.

J'utilise une douzaine de RBL différents, dont Barracuda, Spamhaus, SURBL et URIBL. Ils font un travail décent en attrapant la plupart d'entre eux, mais nous avons encore beaucoup de problèmes, car les adresses IP et les domaines n'ont pas été mis sur liste noire.

Y a-t-il des stratégies que je peux utiliser, y compris des RBL qui bloquent les domaines nouvellement créés ou traitent spécifiquement du spam de snoeshow? J'espère éviter d'avoir à utiliser un service de filtrage tiers.


2
Je recommande de modifier votre titre pour le rendre moins pointu dans la direction de "quel produit dois-je utiliser", car les questions d'achat sont hors sujet pour les sites Stack Exchange. L'atténuation des attaques de raquettes est un bon sujet pour ServerFault, et je demanderai à un de mes collègues de commenter.
Andrew B

Utile pour savoir ce qu'est le spam Snoeshow .
ewwhite

1
La majorité des RBL sont des services gratuits que tout administrateur de messagerie peut utiliser. Est-ce que cela compte comme du shopping?
pooter03

Oui, parce qu'ils sont gratuits ou non, la réponse n'est valable que pour une fenêtre de temps particulière. (que ce lien touche) Les entreprises cessent leurs activités tout le temps, y compris celles qui fournissent des services gratuits.
Andrew B

1
J'ai changé la question. Veuillez me faire savoir si cela est plus approprié.
pooter03

Réponses:


14

Est-ce que cela devient un vrai problème pour vos utilisateurs?

Je recommanderais un service complet de filtrage du courrier à ce stade. Le bayésien n'est plus vraiment si chaud. La réputation, la RBL, l'analyse d'en-tête / d'intention et d'autres facteurs semblent aider davantage. Envisagez un service de filtrage cloud pour combiner plusieurs approches ( et volumes collectifs ) pour offrir une meilleure protection ( j'utilise la solution cloud ESS de Barracuda pour mes clients ).

Et bien sûr: Lutte contre le spam - Que puis-je faire en tant qu'administrateur de messagerie, propriétaire de domaine ou utilisateur?

Nous n'avons pas été affectés négativement par la hausse des attaques de raquettes. J'ai vu une période où le volume de courrier a triplé au jour le jour avec ces attaques. Mais aucune des mauvaises choses n'a réussi. En 3 jours, Barracuda a ramené les volumes à des niveaux normaux.

Je pense que les solutions de filtrage qui ont une vue d'ensemble de l'activité de messagerie mondiale peuvent mieux réagir aux attaques que les filtres de messagerie individuels.

Modifier:

Cela a également été discuté récemment sur la liste de diffusion LOPSA :

Ma contribution: https://www.mail-archive.com/tech@lists.lopsa.org/msg04180.html
Un autre avis: https://www.mail-archive.com/tech@lists.lopsa.org/msg04181 .html


1
Ils commencent à se plaindre. Ce ne sont que quelques dizaines de clients et nous proposons notre service de messagerie à faible coût ou même gratuitement en bundle avec d'autres services que nous achetons, donc nous espérions éviter les services payants si possible. Je vais investir ce produit cependant.
pooter03

C'est environ 8 $ / utilisateur / an.
ewwhite

Merci. Considérez cela comme un vote positif virtuel jusqu'à ce que j'obtienne le représentant pour le faire. :)
pooter03

+1 pour Barrucada.
poke

2
Je recommande toujours le filtrage de courrier Barracuda Cloud. C'est probablement la solution la plus propre à votre problème actuel.
ewwhite

8

Je suis un gars DNS Ops qui travaille en étroite collaboration avec un groupe qui est fréquemment soumis à ces attaques. Gérer les attaques de raquettes est principalement un problème de processus, et comme le souligne ewwhite, il peut être hors de portée de votre entreprise de résoudre en interne. J'irais jusqu'à dire que si vous n'avez pas une opération importante et plusieurs flux RBL commerciaux, vous ne devriez probablement pas essayer de résoudre ce problème vous-même en utilisant un service de filtrage commercial.

Cela dit, nous avons une certaine expérience dans ce domaine et il est plus intéressant de partager qu'autrement. Certains points de contact sont:

  • Si possible, formation de votre plateforme de messagerie pour identifier les caractéristiques d'une attaque Snowshoe en cours et rejeter temporairement les messages des réseaux en question. Les clients qui se comportent bien essaieront de renvoyer des messages en cas d'échec temporaire, d'autres non.
  • Assurez-vous que vos administrateurs DNS surveillent UDP-MIB::udpInErrorsvia SNMP, car les plates-formes de messagerie sont très capables de déborder les files d'attente de réception des écouteurs UDP lorsqu'une attaque Snowshoe est en cours. S'ils ne le sont pas, un moyen rapide de le savoir sous Linux est de s'exécuter netstat -s | grep 'packet receive errors'sur les serveurs DNS en question; un nombre élevé indique qu'ils doivent se débarrasser de leurs balles et commencer à prêter attention. Ils devront augmenter la capacité ou augmenter la taille des tampons de réception en cas de déversement fréquent. (ce qui signifie des requêtes DNS perdues et des opportunités de prévention du spam perdues)
  • Si vous voyez fréquemment ces attaques utilisant des domaines fraîchement créés, des RBL qui les mettent en évidence existent. Un exemple de l' un est NOD FarSight ( les gens qui lisent ce qui devrait effectuer leurs propres recherches), mais ce n'est pas libre.

Divulgation complète: Farsight Security a été fondée par Paul Vixie, à qui j'ai la mauvaise habitude de m'exprimer lorsque les gens violent les normes DNS.


Votre deuxième point est particulièrement intéressant. Je soupçonne que nous manquons des requêtes DNS aux RBL qui avaient déjà mis l'IP ou l'URL sur liste noire, mais je n'ai pas pu le prouver. Cependant, le serveur de messagerie est sous Windows 2012 et utilise le serveur DNS Windows. Il s'agit d'un serveur à faible volume mais je souhaite approfondir cette question. Malheureusement, cela n'explique pas tout, car certaines des choses qui se sont glissées n'avaient pas encore eu le temps pour que leurs domaines ou adresses IP soient capturés par les principaux RBL.
pooter03

Le volume moyen du serveur DNS n'aura pas autant d'importance. La principale caractéristique d'un débordement de file d'attente de réception n'est pas en mesure de traiter vos paquets entrants assez rapidement pour les faire sortir de la file d'attente, et l'attaque en raquettes basée sur le volume est plus que capable de le faire en fonction du nombre de recherches DNS que vous effectuez par Spam.
Andrew B

2
Votre première suggestion est communément appelée liste grise .
Nate Eldredge

2
@Nate C'est une forme de liste grise, mais utiliser ce terme sans réserve suggérerait à la plupart des gens que cette action soit prise en réponse à la nouvelle IP observée. Les réseaux attaquants ont tendance à passer du temps à établir des connexions (sans envoyer d'en-têtes) en préparation de la livraison synchronisée de la charge utile. Ce trait est ce sur quoi vous agissez, car il vous permet de prédire que les adresses IP que vous n'avez pas encore vues sont impliquées dans l'attaque.
Andrew B

Pour tout ce que ça vaut, j'ai (une liste plus générale) de liste grise activée sur le serveur et les spammeurs répondent correctement après une certaine période. À toutes fins utiles, le courrier électronique semble provenir de serveurs de messagerie légitimes avec des enregistrements PTR correctement configurés, des enregistrements SPF, etc.
pooter03

1

J'ai installé Declude (qui est gratuit) et Message Sniffer (qui ne l'est pas) et au cours des 4 derniers jours, j'ai vu un message de spam arriver dans mon compte de messagerie de test, contrairement aux dizaines qu'il recevait par jour. Pour autant que je sache, nous n'avons pas filtré les bons e-mails. Spamassassin serait probablement aussi une bonne solution même si je n'ai pas eu de chance avec cela lorsque j'ai essayé Spam Assassin in a Box ..


0

Beaucoup de réponses ici concernent l'anti-spam général. Dans une certaine mesure, cela a du sens puisque les spammeurs semblent se diriger vers la raquette comme méthode de livraison préférée.

Snowshoe était à l'origine toujours envoyé à partir de centres de données en faible volume (sur une base par IP) et incluait toujours un lien de désabonnement (pour ne rien dire de son fonctionnement). De nos jours, la raquette n'a presque jamais d'informations de désabonnement et est envoyée en grand volume à partir de ses adresses IP, mais est envoyée en rafale de sorte qu'au moment où l'IP soit mise sur liste noire, l'envoi de courrier soit déjà terminé. C'est ce qu'on appelle le spam de grêle .

Pour cette raison, les DNSBL et même les signatures basées sur des modèles serrés sont horribles pour attraper le spam en raquettes. Il y a quelques exceptions, telles que la liste CSS Spamhaus (qui est spécifiquement destinée aux réseaux de raquettes et fait partie à la fois de SBL et de ZEN), mais en général, vous aurez besoin d'une liste grise / tarpitting (ce qui peut retarder la livraison jusqu'à ce que les DNSBL rattrapent ) et, plus important encore, un système d'apprentissage automatique basé sur des jetons comme le filtrage bayésien du spam . Bayes est particulièrement efficace pour détecter les raquettes.

La réponse d'Andrew B mentionne les nouveaux domaines et noms d'hôte (NOD) de Farsight Security , qui essaient d'anticiper les réseaux de raquettes à neige au fur et à mesure qu'ils sont lancés mais avant qu'ils ne commencent à spammer. Spamhaus CSS fait probablement quelque chose de similaire. CSS est prêt à être utilisé dans un environnement de blocage, tandis que NOD est vraiment conçu pour être un flux vers un système personnalisé plutôt qu'un système autonome / bloquant.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.