Forum Linux.debian/ubuntu [postfix] est ce que mon serveur est piraté? Est il utilisé comme relai?

• # Open Relay Test

  Posté par paulez (site web personnel) le 14 juin 2018 à 01:29. Évalué à 1.

  

  J'utilise https://mxtoolbox.com/diagnostic.aspx pour vérifier que mon serveur SMTP n'est pas un open relay.

• # les logs

  Posté par seb le 14 juin 2018 à 08:26. Évalué à 1.

  

  Salut,

  en root journalctl -f tu verras l'activités en direct (très verbeux) mais tu auras plus d'infos qu'avec mailq.

• # Je pense pas ... mais pas assez d'infos !

  Posté par LaBienPensanceMaTuer le 14 juin 2018 à 10:27. Évalué à 3.

  

  Alors, voyons les messages au cas par cas:

  (host mailstore1.secureserver.net[68.178.213.243] refused to talk to me: 421 p3plibsmtp02-15.prod.phx3.secureserver.net bizsmtp Temporarily rejected. Reverse DNS for 213.179.181.19 failed. IB108 http://x.co/srbounce)

  Ca c'est le serveur en face qui t'envoie bouler parce que, vraisemblablement, tu n'as pas de reverse DNS associé à ton IP.
  Cette vérification est souvent mise en place pour lutter contre le spam.
  Pour être "bien", il faut qu'un dig -x <ton ip> donne un nom DNS valide et surtout renseigné comme étant MX sur le domaine.

  91CA51E8A 3327 Wed Jun 13 17:01:33 MAILER-DAEMON
  (connect to nzdb.com[202.208.222.48]:25: Connection timed out)
  lxssgtfnx@nzdb.com

  De mon point de vue ces mails sont générés parce que, à un moment, tu as accepté des emails pour un user qui n'existait pas sur ton domaine.
  Ton postfix a donc généré des MAILER-DAEMON pour l'expéditeur … qui était vraisemblablement un expéditeur bidonné, sur un domaine ou les serveurs de mails sont soit inexistants (le connection timeout du premier) soit fatigué (les autres).

  Après, sur l'unique base de ces logs, c'est compliqué de dire ce qui c'est réellement passé.
  Pour bien faire, il faudrait que tu recherches toutes les occurences des domaines incriminés (jdmo.net, nzdb.com) dans tes logs pour déterminer ce qui a provoquer la génération des MAILER-DAEMON….

• # réponse

  Posté par parazitenew le 14 juin 2018 à 13:33. Évalué à 0.

  

  Bonjour,
  d'après l'outil, tout est OK, sauf le reverse DNS. Donc je devrais être tranquille. Mais en affichant le journal; avec la commande envoyée par @srayneau, je vois des trucs bizarre comme:

  juin 14 12:18:23 exchange sshd[1295]: reverse mapping checking getaddrinfo for 185.13.87.165.ua.bluezonejordan.com [185.13.87.165] failed - POSSIBLE BREAK-IN ATTEMPT!
  juin 14 12:18:23 exchange sshd[1295]: Invalid user teamspeak from 185.13.87.165

  juin 14 12:16:55 exchange sshd[1290]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=177.193.197.5
  juin 14 12:16:57 exchange sshd[1290]: Failed password for invalid user cvsuser1 from 177.193.197.5 port 63752 ssh2
  juin 14 12:16:59 exchange sshd[1290]: Connection closed by 177.193.197.5 [preauth]

  Il est clair que c'est gens qui essayent de se connecter en ssh non?

  pour le SMTP, c'est toujours les même lignes avec les adresses générées.

  @Gérald, j'ai trouvé dans la boite Maildir/new de l'utilisateur linux, des e-mails automatisés, en plus de ceux que j'envoyais lors de mes testes. Des e-mail envoyés à root par root(cron daemon), le contenu est:

  Subject: Cron root@exchange /usr/bin/freshclam --quiet
  MIME-Version: 1.0
  Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  X-Cron-Env: SHELL=/bin/sh
  X-Cron-Env: HOME=/root
  X-Cron-Env: PATH=/usr/bin:/bin
  X-Cron-Env: LOGNAME=root

  c'est désactivable?

  • [^] # Re: réponse

    Posté par Jack DeNoumea (site web personnel) le 14 juin 2018 à 16:46. Évalué à 2.

    

    Bonjour,
    Cron envoie par mail tout ce qui sortirai à l'affichage dans un terminal. Si tu ne le veux pas, il faut rediriger ces flux dans un fichier ou dans /dev/null

  • [^] # Re: réponse

    Posté par kna le 15 juin 2018 à 00:48. Évalué à 3.

    

    Il est clair que c'est gens qui essayent de se connecter en ssh non?

    Oui. C'est commun sur un serveur SSH accessible publiquement, généralement des bots.

    Assures-toi simplement d'utiliser des bons mots de passe, ou mieux, d'autoriser uniquement l'accès SSH avec une clé.

    Pour éviter de pourrir tes logs, tu peux :
    - firewaller le port SSH pour autoriser certaines adresses ;
    - bloquer les adresses qui font trop d'auth fail avec par exemple fail2ban ;
    - changer le port d'écoute de SSH - je conseille quand même de rester sur un port privilégié (<1024) ;
    - faire du port knocking.

    • [^] # Re: réponse

      Posté par Kerro le 15 juin 2018 à 23:24. Évalué à 3.

      

      Je conseille quand même de rester sur un port privilégié (<1024)

      Pour quelle raison ?

      • [^] # Re: réponse

        Posté par kna le 18 juin 2018 à 14:37. Évalué à 4.

        

        Pour éviter qu'un utilisateur puisse mettre un faux service en écoute sur le port et capturer mots de passe et autres joyeusetés.

        Je concède qu'en pratique, ça s'avère assez difficile :
        * il y a normalement déjà le vrai service en écoute, donc le port sera occupé (à moins de trouver un moyen de le stopper, ou d'attraper une fenêtre ou il redémarre) ;
        * il n'a pas accès aux clés du serveur, donc le client renverra une alerte si ce n'est pas sa première connexion.

• # proposition de tuto

  Posté par Ericounet le 19 juin 2018 à 12:19. Évalué à 1.

  

  Bonjour,

  j'ai un tuto en cours d"écriture sur l'installation d'un serveur sécurisé, avec partie serveur mail quasi terminée. Ce n'est pas un tuto à suivre , mais un tuto avec explications et tests à chaque étape; il n'est pas finalisé, mais la partie écrite marche parfaitement (testée sur 2 serveurs). Je peux vous l'envoyer en l'état. Mon adresse émail est dispo sur ma page web Le Yojik, page contact. (site complètement sans pub ni traceurs ou autres joyeusetés )

  Eric

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.