Je ne suis pas sûr que ce soit le bon endroit pour poser cette question. Mais maintenant je suis dans une grande situation difficile. Notre serveur subit une attaque DDoS SMTP. Le service de messagerie est totalement en panne. Nous avons vérifié auprès de l'équipe du centre de données et ils nous ont mis à jour pour acheter un nouveau module pare-feu, ce que je ne peux pas me permettre maintenant. Lorsque nous essayons de changer de port, l'attaque peut être stoppée mais le service de messagerie est désactivé. Est-il possible d'arrêter cette attaque?
OS: CentOS
Mail service : exim
SMTP port used : 25
Le journal de messagerie actuel est présenté ci-dessous:
2013-10-16 00:35:10 SMTP syntax error in "\223\032\020F\324\247\315f\200]\236m2\025\305sL\313\300y\377}\306\177]\246V\204\272n3\2115\031\335\215\240\247[\222\340*\340\230]\263\221\235\323=n\242\315\\260\2473\021q\255o\232a\263\262\306\016\2705A\261\2744\230`\302r\361\343=\376 \260\315\356-s\322\236C\255\327\353;\253\334h\304\207\341\276\201\324^\207\231\212\354\273"L\362:zNn\205\362\253r\240\032\235x\027u\211\006`\377\224\vR\204\360\020\265@k\025\301Y\212\033\204\346j!?9\026&\206)\215*:LP/[\006\3704\263W\206:P\340<@\360f\276D\365\3544I6\334\017O\242\377gT\277O\340Y\003B\330]\205\3103cj\201\333h\247|\264n]\366Bsr\260\352xXmH~\031]\210\203OG\351\207O&T\216b\276\273\221\fkY\230}\007G\024\271\351'\2422\r\367\246\366\352^#\203\b ): \244\266\311\272\304\273\221\344\016\301|\236R\305\027\354]\314\266\246\206\321,5\313\325\305X?\333Mx\377\337me\304\346\205\341\230\352@<\217\357:\277\003\365\\370\331o\251\017\005\377V\365\004\005\275\200\324\200\231\241\026\206\260^N\023\304IB\031\020\230j\036\277\270\254#R\323!\250\2037h,\262^]>\371\3437DQ\374qI\355\362oNr?wSV\234\216X\244\212\204]\213lpc\302\264\252\334O\274\354\341C\333@r'\224\350w\306\254"}\220=\007\202\336+\375\206\351\r\351\214l\270\273\006" H=[181.67.204.178]:36043 I=[64.31.38.66]:25 NULL character(s) present (shown as '?')
2013-10-16 00:35:10 SMTP syntax error in "Q\356\226J\226\244\021y\033;\027\320W$\246\244\b\304\253\3444\020\260o#\006\265A6\275\273DF%7\201\205\265;4\246\016\312\244{"E\277P\312<\266\374\312\332\\272\365\336@\031\216\343\211 \005\350\304\352o\356\rkl\363\261%\225\370\344\262O\376\327z\003\002a\257\~\026(\266\204+\333H\022\307\3006\027\361S\234\033L5\007"\372,)\235\377kWJ\314\242\3270\216\334\203\254\364\223\233\262I5R\270\273W,F\365\341\211J?\322?O\241\345\267U\036n\224Z\373b\021`L\2478e\3549vi,\027\177\346\376Xa\3547\277\235\360$\213[\366\300\250\310\002\314s\274\b\2423\374\004H\341u\223\253\235\037\230\203\360\255\235u\017o\243\fd~\250\211\354Z\255\371\016\036\262\252/`\267[P\242\274\374\330~\301\227_\332\306\354\265j\313\353:E\321MZ\006\327fH\374\333\343\320\330\340\253\020v\Rd\004b\335fl\360@#\026\365\372\227\b\373\322\260\321u\037\215t\204\032\033d\202\232"\361\017Y\201\211\024>hw\031\327\233\312\225\215\246\336#\263\323\306(\243C/\245\344\017r\251\373\034\232\257t\265 \266\302FFB\264e\007H\326#l\303\374\332XRyc5WQV\301\334\232\246:a\027/\027f\026\264\361k\233\373urs\201Tz\325=\376~\2437\375\372\020\245(\212\016\322\020\217\304n\335\vy\226 \020R\356\373\241[J\023\247Li\324\254\210\3631\261=\243P\267\320h\2752\351\271\220\301\244t\272\306Xa.\314\241Q\245\3208\246\264\3257+\217\333\232\3478\340" H=[181.67.204.178]:36043 I=[64.31.38.66]:25 NULL character(s) present (shown as '?')
2013-10-16 00:35:10 SMTP syntax error in "" H=[181.67.204.178]:36043 I=[64.31.38.66]:25 unrecognized command
Encore une fois, je m'excuse sincèrement si ce n'est pas le bon endroit pour poser cette question.
Cordialement, Arun Kurian
Réponses:
À en juger par la sortie ci-dessus, cela semble plus ou moins le même botnet que celui qui attaque l'un de nos serveurs ... nos journaux indiquaient quelque chose de moins que 30k IP uniques, avec des données binaires inutiles envoyées à partir du moment où la session TCP est terminée. .. dans une telle situation, la liste grise n’aide en rien, car le problème est causé par les connexions simultanées (à un moment donné, nous comptions environ 2 000 connexions actives / en attente dans la sortie netstat), ce qui entraîne le MTA dans sa limite de processus. , ou tue le processeur (si la limite des processus MTA est suffisamment élevée). Pour le moment, nous avons activé une politique de pare-feu pour bloquer tout SMTP entrant qui ne provient pas de nos réseaux (/ 16, / 19), en espérant que les enfants du script f @ cking se désintéresseront bientôt et arrêteront l’attaque par bot. Ce que nous aurions à configurer ici est une sorte d’outil transparent à faible impact qui prend en charge la négociation TCP, vérifie la bonne connexion, auquel cas il fausse la négociation et les données initiales et laisse le reste de la session se dérouler. à travers sans aucune interaction ... Oui, je sais qu'il existe des solutions commerciales qui le font, mais elles se situent bien dans la plage des 5 chiffres ...
la source
Il est très difficile de conseiller sans beaucoup plus de connaissances sur ce qui se passe (informations de trafic et profil du serveur), et même dans ce cas, ce n’est probablement pas le bon forum à poser.
Fermez le problème!
Selon votre profil, vous voudrez peut-être examiner "résoudre le problème". J'entends par là le recours à un autre fournisseur de messagerie pour gérer votre courrier entrant et le transférer vers vous. Autorisez uniquement les connexions de ce fournisseur de messagerie et de vos adresses IP internes. Une recherche sur "services de filtrage du courrier smtp" fournira probablement certains fournisseurs candidats ou votre fournisseur de upstrema pourrait proposer ce service.
Général "faites le vous-même" solutions:
Si vous êtes certain que son (hautement) distribué, essayez d'activer liste grise . Cela pourrait aider un peu en fonction de la nature de l'attaque.
Si le problème provient d'un certain nombre de serveurs (mais n'est pas extrêmement distribué), envisagez d'utiliser fail2ban et d'écrire des règles personnalisées. J'ai trouvé que cela faisait des merveilles sur les attaques distribuées sur mes sites wordpress.
Probablement pas une option, mais ça pourrait l'être. Vous pouvez peut-être utiliser iptables pour bloquer des régions géographiques - par exemple, si vos clients ne sont pas en Russie ou en Chine, vous pouvez bloquer les demandes SMTP entrantes provenant de ces plages à l'aide de la géolocalisation. Bien entendu, cela arrêtera également le trafic légitime - ce ne sera peut-être pas un problème dans un environnement d'entreprise avec un marché ciblé.
la source