Blocage d'ip / attaque smtp / iptables bannissement limit

[batman]

bonjour ,

bonne année à tous, et prospérité à ipcop et son auteur (qui fréquente ce site je pense)

j'utilise ipop 1.4.21 + copfilter

depuis ce matin 4h00 des ip dynamque de taiwan tentent de mettre à genoux mon serveur smtp (perso) sous postfix
les adresses ip changent toutes les minutes

je souhaitais donc savoir comment bloquer ce type d'attaques (3 mails/secondes, qui est je pense la limite de mon adsl perso + performance de mon serveur de mail, un pii 96moRam)

j'ai rien vu dans les menus de l'interface web


question subsidiaire
sous ipcop
iptables -A INPUT -p TCP -s 202.75.56.212 -j DROP -> semble inefficace
sur mon serveur de mail, la même commande bloque correctement l'ip
il faut envoyer ailleurs que dans drop ?, c'est pas dans INPUT ? (j'suis un peu une quiche en iptables, j'ai essayé au départ avec drop en minuscule et je comprenais pas pourquoi cela ne fonctionnait pas ....)


merci

[tomtom]

c'est pas dans INPUT ?

Bonne pioche.
C'est dans FORWARD.

voir le fameuxsite de Christian Caleca


Pour bloquer ce genre d'attaques, les paramètres limit de netfilter font des merveilles... mais il faut un peu creuser pour mettre de bons réglages et bien comprendre ce que l'on fait.


t.

[ccnet]

Une solution éventuellement de ce coté ci : http://mh-lantech.css-hamburg.de/ipcop/ ... p?view.197
Pour ceux qui veulent quelque chose qui s'intègre au fonctionnement d'ipcop sans modifier manuellement iptables avec les problèmes que cela comporte.

Une autre solution, puisque Postfix est présent, consiste à utiliser un fichier: /etc/postfix/access avec

Code: Tout sélectionner

202.75.56 REJECT

qui bloquera 202.75.56/24. A adapter en tant que de besoin.

Dans Postfix on mettra en place une restriction utilisant ce ficher avec le paramètre smtpd_client_restrictions. Quelque chose dans ce style :

Code: Tout sélectionner

check_recipient_access hash:/etc/postfix/access

Voir la doc postfix pour les informations complètes que je n'ai pas en tête.

Au delà, ce problème montre bien pourquoi Copfilter sur ipcop est vraiment une fausse bonne idée. Un Postfix avec Spamassassin bien configuré (Postfix surtout) est capable de se défendre tout seul. Il certain que cela n'est pas installable sur la configuration matérielle indiquée ici. Il est clair que l'on fait avec ce que l'on a.

[batman]

Une solution éventuellement de ce coté ci : http://mh-lantech.css-hamburg.de/ipcop/ ... p?view.197
Pour ceux qui veulent quelque chose qui s'intègre au fonctionnement d'ipcop sans modifier manuellement iptables avec les problèmes que cela comporte.

oui, au début de l'attaque je pensais à ce genre d'outils, mais les adresses sont multiples en adsl dynamique ( NK219-91-121-228.adsl.dynamic.apol.com.tw), je pense à une solution qui utiliserais le module limit d'iptables (je crois que c'est même hash-limit) avec une période de purge automatique histoire d'éviter le débordement de mémoire du routeur

Une autre solution, puisque Postfix est présent, consiste à utiliser un fichier: /etc/postfix/access avec
.

oui, mais y'a plusieurs inconvénient avec cette méthode :
- cela fait travailler postfix, il doit gérer la règle de refus, même si elle est en tête de liste dans le main.cf : pour info le log de postfix fait pour ce jour fait 17 Mo (c'est une taille equivalent pour 1 mois habituellement chez moi)
- cela fait un traitement tardif du problème et en plus l'attaque aurait pu être tenté sur un autre port (ftp, web, ....) : a titre personnel, et pour répartir la charge de travail, ce type de traitement je préfère qu'il soit fait sur mon routeur (ipcop) (qui passe son temp à rien faire, alors que mon serveur %idle à la louche 60% alors qu'ipcop 95% (pendant l'attaque il est idle à 90%).[/quote]

Au delà, ce problème montre bien pourquoi Copfilter sur ipcop est vraiment une fausse bonne idée. Un Postfix avec Spamassassin bien configuré (Postfix surtout) est capable de se défendre tout seul. Il certain que cela n'est pas installable sur la configuration matérielle indiquée ici. Il est clair que l'on fait avec ce que l'on a.

effectivement je regrette un peu de l'avoir installé (c'est pour déporter spamassin sur le routeur), car en plus la source devient l'adresse ip verte du routeur .... pas facile de traiter les ip internet dans ce cas .... mon serveur postfix a comme adresse de confiance mon routeur .... j'ai désactivé pour réduire les catastrophes ...

par contre j'ai pas vu de procédure de désinstallation de Copfilter

[batman]

Bonne pioche. C'est dans FORWARD.

voir le fameuxsite de Christian Caleca

le pire est que je connais ce site, mais j'avais oublié .....

Pour bloquer ce genre d'attaques, les paramètres limit de netfilter font des merveilles... mais il faut un peu creuser pour mettre de bons réglages et bien comprendre ce que l'on fait.

mince j'ai répondu au 2ième post avant le votre, je pensais aussi a 'limit'

avant de taper dans iptables (+sous ipcop)

- il est effecitvemenent important de savoir quoi faire, faut-il, par exemple, partir sur :
* bloquer au déla de 3 emails / secondes : risque de blacklister mes listes de diffusions ?
* bloquer s'il y a + de 2 x 60 tentatives sur 2 minutes ?
* durée de banissement (type fail2ban pour ssh je crois ?)

- ensuite dans quelle(s) règle(s) poser cela, je pense effectivement à FORWARD maintenant (plutôt qu'INPUT)
- et , the last but not the least : rédiger les règles iptables

la quiche que je suis a essayé 'comme une brute, qui ne réfléchi vraiement pas ' :
iptables -A INPUT -p tcp --dst $serveur -m hashlimit --hashlimit 1000 --hashlimit-mode dstip,dstport --hashlimit-name hosts --hashlimit-htable-expire 10000
iptables -A INPUT -p tcp --dst $serveur -m hashlimit --hashlimit 10 --hashlimit-mode dstip,dstport --hashlimit-name hosts
en résultat :

iptables: Unknown error 4294967295
iptables: Unknown error 4294967295


(ipt_limit est chargé), c'est ptet dans ipt_connlimit.o.gz ipt_dstlimit.o.gz qu'il faut voir ....

[ccnet]

oui, mais y'a plusieurs inconvénient avec cette méthode :
- cela fait travailler postfix, il doit gérer la règle de refus, même si elle est en tête de liste dans le main.cf : pour info le log de postfix fait pour ce jour fait 17 Mo (c'est une taille equivalent pour 1 mois habituellement chez moi)
- cela fait un traitement tardif du problème et en plus l'attaque aurait pu être tenté sur un autre port (ftp, web, ....) : a titre personnel, et pour répartir la charge de travail, ce type de traitement je préfère qu'il soit fait sur mon routeur (ipcop) (qui passe son temp à rien faire, alors que mon serveur %idle à la louche 60% alors qu'ipcop 95% (pendant l'attaque il est idle à 90%).

[/quote]

je ne partage pas vos analyses ni la démarche qui consiste à traiter un spam massif, donc un problème smtp avec le firewall, du moins pas intégralement.

Je ne vois pas le rapport entre une règle de Postfix, sa position dans main.cf (qui n'a rien à voir avec l'ordre d'exécution) et la taille des logs. Si le log est trop gros à votre gout pour une journée, ce qui est compréhensible, il suffit de modifier vos paramètres de rotation.

Vos motivations sur les pourcentages de charges doivent comporter des erreurs de saisie. Elles ne sont pas compréhensibles.

Je ne vois aucune raison de risquer un déni de service sur le firewall, ce qui fait "tout perdre" . Si l'on sait identifier la plage d'adresses on peut en effet la filtrer dès le firewall. Là l'intervention en amont est judicieuse. Faire tourner spamassassin sur le firewall sous prétexte que c'est en amont ne peut que conduire à la perte du firewall, au déni de service. Avec tous les risques que tout cela comporte. Ce qui vaut bien sûr pour Copfilter.

La nocivité des domaines comme apol.com.tw est assez connue. Par ailleurs la configuration qui comporte un serveur de mail sans la protection d'un relais smtp montre rapidement ses limites. Dans ce type d'attaque ,si dès les premiers mails, le spammeur se heurte à un rejet, il ne persévère pas il préfère des proies accessibles. Il faut donc utiliser tous les contrôles disponibles avant l'usage de spamassassin couteux en ressource machine. Les RBL en font partie ainsi que les tests des domaines, des mx etc ... Et le grey listing.

Des domaines tels que cable.triera.net, cable.net.co, dynamic.163data.com.cn etc il en arrive tous les jours sur les serveurs de mails que je gère ici et là. Ils sont rejetés dès la première tentative par les règles de Postfix et ils n'y reviennent pas.
La charge à 90% d'une passerelle smtp ne m'inquiète pas. Au pire les mails arriveront quelques minutes, quelques heures plus tard. Mais le reste du réseau est opérationnel. Sur le firewall le risque est maximum. A saturation comment se comporte il ?

Une bonne défense est une défense en profondeur. Tout remonter au firewall est une erreur.

l'attaque aurait pu être tenté sur un autre port (ftp, web, ....)

Là je ne comprend pas. Spam massif sur un port ftp, http ?

Au delà ce ces considérations générales, qui sortent un peu de votre cadre personnel, je comprend bien l'intérêt intellectuel des tentatives de traitement iptables. Le temps que vous trouviez la bonne syntaxe, le bon réglage iptables et vous aurez reçu quelques millions de mails depuis apol.com.tw. Mettre ce domaine en blacklist dans votre Postfix prend 5 mn pour traiter le problème.

[batman]

Je ne vois pas le rapport entre une règle de Postfix, sa position dans main.cf (qui n'a rien à voir avec l'ordre d'exécution) et la taille des logs. Si le log est trop gros à votre gout pour une journée, ce qui est compréhensible, il suffit de modifier vos paramètres de rotation.

Il me semblait que les règles étaient traitées dans l'ordre d'apparition (ce qui me semblait logique avec le permit en dernier, certes le traitement est de l'ordre de la millisecondes, mais même si je fais pas du temps réel, il me semblait utile de présenter les règles dans un ordre "judicieux" (hum, hum, très approximatif, je le conçois)

Vos motivations sur les pourcentages de charges doivent comporter des erreurs de saisie. Elles ne sont pas compréhensibles.

en fait j'utilise top pour "la charge", je préferais sar, mais il n'est pas sur ipcop (sar à d'autres travers .....)

Je ne vois aucune raison de risquer un déni de service sur le firewall, ce qui fait "tout perdre" . Si l'on sait identifier la plage d'adresses on peut en effet la filtrer dès le firewall. Là l'intervention en amont est judicieuse. Faire tourner spamassassin sur le firewall sous prétexte que c'est en amont ne peut que conduire à la perte du firewall, au déni de service. Avec tous les risques que tout cela comporte. Ce qui vaut bien sûr pour Copfilter.

je n'avais pas vu, effectivement l problème sous cet angle !

La nocivité des domaines comme apol.com.tw est assez connue. [...] Il faut donc utiliser tous les contrôles disponibles avant l'usage de spamassassin couteux en ressource machine. Les RBL en font partie ainsi que les tests des domaines, des mx etc ... Et le grey listing.

j'ai du rbl, visiblement j'ai pas les bons (bl.spamcop.net, relays.ordb.org, dnsbl.njabl.org, sbl-xbl.spamhaus.org, list.dsbl.org) + 2 3 trucs
smtpd_helo_required = yes
reject_unknown_sender_domain = yes
smtpd_helo_restrictions = reject_non_fqdn_hostname
[je vais pas mettre mon main.cf complet, vos n'avez sûrement pas envie de vous pencher la dessus sur un forum 'ipcop'

l'attaque aurait pu être tenté sur un autre port (ftp, web, ....)

Là je ne comprend pas. Spam massif sur un port ftp, http ?

je pensais à d'autres type d'attaques répétées : failles connus de servers iis (je suis sous apache) ou autres projets (roundcube, ....) , attaques par dictionnaires sur serveur ftp, ....

Au delà ce ces considérations générales, qui sortent un peu de votre cadre personnel, je comprend bien l'intérêt intellectuel des tentatives de traitement iptables. Le temps que vous trouviez la bonne syntaxe, le bon réglage iptables et vous aurez reçu quelques millions de mails depuis apol.com.tw. Mettre ce domaine en blacklist dans votre Postfix prend 5 mn pour traiter le problème.

j'ajouterais ce domaine à la blacklist

merci

[batman]

En fait j'en avais tellement marre de saturer mon /var/log pour rien, sur ipcop j'ai appliqué cette règle :

Code: Tout sélectionner

cat smtpProtect.sh
#!/bin/sh
DPort=25
Name=Smtp
delayBetweenSec=2
hitcount=2
echo "$0 : règles limitation attaques sur por $DPort($Name) : limitation a $hitcount tous les $delayBetweenSec"

iptables -I FORWARD -p tcp --syn --dport $DPort -m recent --update --seconds $delayBetweenSec --hitcount $hitcount --name $Name -j DROP
iptables -I FORWARD -p tcp --syn --dport $DPort -m recent --update --seconds $delayBetweenSec --hitcount $hitcount --name $Name -j LOG --log-prefix "$0: "

iptables -I FORWARD -p tcp --syn --dport $DPort -m recent --set --name $Name -j ACCEPT


les seules ip concerné reste celles en com.tw

cette règle ne semble pas impacté mes listes de diffusion ! la bonne affaire

faudra que j'améliore histoire de pouvoir le désactiver temporairement cette règle genre créer une destination 'overload' ....

[ccnet]

Ce serai là effectivement une fonctionnalité de défense à implémenter dans IPCOP. Elle existe par exemple sur Pfsense pour chaque règle. Concrètement cela permet de l'appliquer à un port, une adresse source ou une combinaison des deux avec une limitation de nombre de syn par seconde.

[ccnet]

Je reviens sur cette question à la suite d'attaques assez massives de spam ayant eu lieu aujourd'hui sur plusieurs systèmes de messagerie dont je suis en charge. Ce sont des domaines parfaitement distincts.

Vers 17h30 nous avons eu jusqu'à 15 tentatives de connexions par seconde, en particulier s'annonçant en provenance de versanet.de[62.214.246.91].

Les passerelles basées sur Clark Connect Community (Postfix +clamav + spamassassin) ont parfaitement résisté et conformément aux paramétrages de Postfix, tout ce petit monde a été rejeté dès le HELO. Ces passerelles sont toutes d'anciennes machines dont la configuration ne dépasse pas le PIII 800 Mghz avec un 1 Go de ram. Sur le firewall l'incidence en terme de trafic est très faible, moins de 10 % de la bande passante maximum consommée sur la journée. Ce qui n'est pas la bande passante maximum disponible.

Sur l'un des sites, équipé de Pfsense, les connexions concurrentes par ip source sur le port 25 ont été limité à 3 et le nombre de nouvelles connexions a été limité à 5 par seconde.

[batman]

Je reviens sur cette question à la suite d'attaques assez massives de spam ayant eu lieu aujourd'hui sur plusieurs systèmes de messagerie dont je suis en charge. Ce sont des domaines parfaitement distincts..

Bien !

en ce qui me concerne, l'attaque était fortement ciblé, car après avoir inséré une règle de filtrage (2 par tranches de 2 secondes pour une ip), la journée fut tranquille
Le lendemain, ces mêmes adresses sources sont revenus, avec une fréquence plus large : j'ai baissé à 1 par tranche d'1 secondes pour une ip .... la journée fut tranquille
Le lendemain (du lendemain ci-dessus) : idem fréquence encore un peu plus large : on aurait pus jouer a cela longtemps, mais j'ai franchement autre chose à faire :

Code: Tout sélectionner

iptables -I INPUT -p TCP -s 118.169.0.0/16 -j DROP
iptables -I FORWARD -p TCP -s 118.169.0.0/16 -j DROP

(il y avait d'après un grep -c -u ~ 200 ips différentes)

je suis passé de 500Mo/jrs log mail à 20Mo/jrs

tant pis pour ceux de cette zone qui sont de bonnes fois.

Cette ségrégation me dérange, mais faute de mieux ....