Spam émis par les kaznautes #1

New Issue

nikki · 2024-12-22T15:30:57+01:00

nikki commented

2024-12-22 15:30:57 +01:00

Rappel des faits

Un kaznaute s'est fait voler ses identifiants. Son compte de messagerie a été utilsé pour expedier du spam en masse.
conséquence : mauvais réputation de l'IP de sortie du serveur mail de KAZ
Même après changement de MDP du kaznaute concerné, ce problème reviendra avec un autre kaznaute etc...

Solution actuellement en oeuvre

Un cronjob purge régulièrement la file d'attente de postfix
Efficace ? oui
Trop efficace ? oui aussi. risque de suppression de mails legits.
Cette suppression provoque-t-elle au moins un bounce pour informer le kaznaute ? J'ai pas regardé. @didier ?

Solution initialement proposée

tuner spamassassin et/ou amavis pour bloquer le spam sortant.
après tests : on voit que les mails sortants sont bien analysés par spamassassin avec un score et tout. ci-dessous un extrait de mail.log

2024-12-21T20:30:58.379155+01:00 mailserver amavis[867]: (00867-09) Passed SPAM {RelayedOpenRelay,Quarantined}, [172.19.0.1]:44478 <nikki@lab.lan> -> <SECRET-RECIPIENT-LOL>, quarantine: D/spam-DvDUfhd747Ip.gz, Queue-ID: 751C540BC3, Message-ID: <a6a7b031b6ffb5d18a187658d41a9ad5@lab.lan>, mail_id: DvDUfhd747Ip, Hits: 11.57, size: 903, queued_as: 4EDE440BC0, 5836 ms
2024-12-21T20:32:32.413902+01:00 mailserver amavis[868]: (00868-10) Passed SPAM {RelayedOpenRelay,Quarantined}, [172.19.0.1]:52170 <nikki@lab.lan> -> <SECRET-RECIPIENT-LOL>, quarantine: 4/spam-4F2TBMsCeE_R.gz, Queue-ID: 0F09440BC5, Message-ID: <de67e61fd49010d56cbaf51185e6f028@lab.lan>, mail_id: 4F2TBMsCeE_R, Hits: 10.468, size: 936, queued_as: 627FF40BC4, 5252 ms

Par contre, on voit aussi qu'ils sont à la fois mis en quarantaine ET transmis à postfix pour envoi, normal.
Raison de ce comportement : SPAMASSASSIN_SPAM_TO_INBOX=1. On veut ça pour que les kaznautes recoivent au moins les faux-positifs dans leur boite.

conclusion : obligé de passer par un relai différent du postfix hébergé sur la solutoin mailserv.

Solution testée

un MTA dédié au filtrage des mails
- sollicité après un premier passage par le service mailServ. En clair : Client mail => mailServer => conteneur dédié antispam => internet
- configuré avec un SA_KILL inférieur à 10 de façon à notifier l'utilisateur que le mail a été rejeté. Nécessaire pour indiquer à l'utilisateur que son compte est piraté !
mise en oeuvre (perfectible) :
- 1 service supplémentaire dans le docker-compose de mailServer :
  - basé sur l'image officielle de docker-mailserver
  - sans mappage de port sur le serveur host (inutile, port 25 ouvert en interne seulement)
  - 1 link déclaré dans le docker-compose pour permettre la résolution de nom entre les deux services.
  - Les variables d'environnement suivantes
```
environment:
  - ENABLE_RSPAMD=0
  - ENABLE_CLAMAV=1
  - ENABLE_FAIL2BAN=1
  - ENABLE_SPAMASSASSIN=1
  - ENABLE_SPAMASSASSIN_KAM=1 # optionnel ?
  - SPAMASSASSIN_SPAM_TO_INBOX=0 # necessaire
  - MOVE_SPAM_TO_JUNK=0
  - PERMIT_DOCKER=host  ## necessaire aussi. Attention ! openrelay
  - ENABLE_IMAP=0
  - ENABLE_POP3=0
  - SMTP_ONLY=1
  - SA_KILL=6.31
```
- intégration avec l'existant : ajouter une variable d'environnement au service mailServer comme suit DEFAULT_RELAY_HOST=${newservice_Servicename}
- axes d'amélioration :
  - voir pour désactiver ClamAV ? en principe, le scan antivirus est effectué systématiquement. S'il est fait par le premier maillon, inutile de passer du temps CPU à refaire un test qui devrait toujours être négatif
  - mode openrelay sur le conteneur dédié à spamassassin. la conf proposée par docker-mailserver ne permet que d'autoriser tout le subnet du conteneur à transmettre du courrier à postfix ($mynetworks). Le mieux serait peut-être une authentification. compte dédié pour discuter entre mailServ et le smarthost ?
  - double appel à spamassassin :
    - pour rappel : [client mail] => mailServer(spamassassin --mode_passoire=1) => relayhost(spamassassin --mode_serieux=1) => internet.
    - possiblité de forcer le seveur roundcube à remettre le courrier sortant directement au serveur smarthost, mais ça nécessitera de l'intégrer avec le LDAP
    - Soulève le problème des clients externes. Il faudra séparer le MX du nom utilisé pour le smtp sortant. Nécessite aussi d'exposer un port du smarthost à internet.

Reste à faire

intégrer ce truc dans le docker-compose de kaz, avec variables, template et tout

## Rappel des faits - Un kaznaute s'est fait voler ses identifiants. Son compte de messagerie a été utilsé pour expedier du spam en masse. - conséquence : mauvais réputation de l'IP de sortie du serveur mail de KAZ - Même après changement de MDP du kaznaute concerné, ce problème reviendra avec un autre kaznaute etc... ## Solution actuellement en oeuvre - Un cronjob purge régulièrement la file d'attente de postfix - Efficace ? oui - Trop efficace ? oui aussi. risque de suppression de mails legits. - Cette suppression provoque-t-elle au moins un bounce pour informer le kaznaute ? J'ai pas regardé. @didier ? ## Solution initialement proposée - tuner spamassassin et/ou amavis pour bloquer le spam sortant. - après tests : on voit que les mails _sortants_ sont bien analysés par spamassassin avec un score et tout. ci-dessous un extrait de mail.log ``` 2024-12-21T20:30:58.379155+01:00 mailserver amavis[867]: (00867-09) Passed SPAM {RelayedOpenRelay,Quarantined}, [172.19.0.1]:44478 <nikki@lab.lan> -> <SECRET-RECIPIENT-LOL>, quarantine: D/spam-DvDUfhd747Ip.gz, Queue-ID: 751C540BC3, Message-ID: <a6a7b031b6ffb5d18a187658d41a9ad5@lab.lan>, mail_id: DvDUfhd747Ip, Hits: 11.57, size: 903, queued_as: 4EDE440BC0, 5836 ms 2024-12-21T20:32:32.413902+01:00 mailserver amavis[868]: (00868-10) Passed SPAM {RelayedOpenRelay,Quarantined}, [172.19.0.1]:52170 <nikki@lab.lan> -> <SECRET-RECIPIENT-LOL>, quarantine: 4/spam-4F2TBMsCeE_R.gz, Queue-ID: 0F09440BC5, Message-ID: <de67e61fd49010d56cbaf51185e6f028@lab.lan>, mail_id: 4F2TBMsCeE_R, Hits: 10.468, size: 936, queued_as: 627FF40BC4, 5252 ms ``` Par contre, on voit aussi qu'ils sont à la fois mis en quarantaine ET transmis à postfix pour envoi, normal. Raison de ce comportement : `SPAMASSASSIN_SPAM_TO_INBOX=1`. On veut ça pour que les kaznautes recoivent au moins les faux-positifs dans leur boite. - conclusion : obligé de passer par un relai différent du postfix hébergé sur la solutoin mailserv. ## Solution testée - un MTA dédié au filtrage des mails - sollicité après un premier passage par le service mailServ. En clair : Client mail => mailServer => conteneur dédié antispam => internet - configuré avec un SA_KILL inférieur à 10 de façon à notifier l'utilisateur que le mail a été rejeté. Nécessaire pour indiquer à l'utilisateur que son compte est piraté ! - mise en oeuvre (perfectible) : - 1 service supplémentaire dans le docker-compose de mailServer : - basé sur l'image officielle de docker-mailserver - sans mappage de port sur le serveur host (inutile, port 25 ouvert en interne seulement) - **1 link** déclaré dans le docker-compose pour permettre la résolution de nom entre les deux services. - Les variables d'environnement suivantes ```yml environment: - ENABLE_RSPAMD=0 - ENABLE_CLAMAV=1 - ENABLE_FAIL2BAN=1 - ENABLE_SPAMASSASSIN=1 - ENABLE_SPAMASSASSIN_KAM=1 # optionnel ? - SPAMASSASSIN_SPAM_TO_INBOX=0 # necessaire - MOVE_SPAM_TO_JUNK=0 - PERMIT_DOCKER=host ## necessaire aussi. Attention ! openrelay - ENABLE_IMAP=0 - ENABLE_POP3=0 - SMTP_ONLY=1 - SA_KILL=6.31 ``` - intégration avec l'existant : ajouter une variable d'environnement au service mailServer comme suit `DEFAULT_RELAY_HOST=${newservice_Servicename}` - axes d'amélioration : - voir pour désactiver ClamAV ? en principe, le scan antivirus est effectué systématiquement. S'il est fait par le premier maillon, inutile de passer du temps CPU à refaire un test qui devrait toujours être négatif - mode openrelay sur le conteneur dédié à spamassassin. la conf proposée par docker-mailserver ne permet que d'autoriser tout le subnet du conteneur à transmettre du courrier à postfix ($mynetworks). Le mieux serait peut-être une authentification. compte dédié pour discuter entre mailServ et le smarthost ? - double appel à spamassassin : - pour rappel : [client mail] => mailServer(spamassassin --mode_passoire=1) => relayhost(spamassassin --mode_serieux=1) => internet. - possiblité de forcer le seveur roundcube à remettre le courrier sortant directement au serveur _smarthost_, mais ça nécessitera de l'intégrer avec le LDAP - Soulève le problème des clients externes. Il faudra séparer le MX du nom utilisé pour le smtp sortant. Nécessite aussi d'exposer un port du smarthost à internet. ## Reste à faire intégrer ce truc dans le docker-compose de kaz, avec variables, template et tout

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KAZ/KazV2#1