Ce message inonde mon syslog, comment savoir d'où il vient?

Lorsque je lance, dmesgcela arrive toutes les secondes environ:

[22661.447946] [UFW BLOCK] IN=eth0 OUT= MAC=ee:54:32:37:94:5f:f0:4b:3a:4f:80:30:08:00 SRC=35.162.106.154 DST=104.248.41.4 LEN=40 TOS=0x00 PREC=0x00 TTL=37 ID=52549 DF PROTO=TCP SPT=25 DPT=50616 WINDOW=0 RES=0x00 RST URGP=0

Comment puis-je retrouver la cause de ce message?

networking

— peterretief
source

C'est la journalisation ufw ennuyeuse. Tu peux l'éteindre. Il est également possible de configurer ufw pour utiliser un canal de journal différent, donc cela ne contamine pas dmesg, mais c'est très délicat (peut nécessiter même un petit patch ufw).

— peterh

FWIW si vous n'êtes pas familier avec UFW, vous ne devriez probablement pas avoir votre système connecté directement à Internet.

— MooseBoys

Réponses:

La réponse existante est correcte dans son analyse technique de l'entrée du journal du pare-feu, mais il manque un point qui rend la conclusion incorrecte. Le Colis

Est un RSTpaquet (réinitialisé)
de SRC=35.162.106.154
à votre hôte à DST=104.248.41.4
via TCP
de son port SPT=25
à votre port DPT=50616
et a été BLOCKédité par UFW.

Le port 25 (le port source) est couramment utilisé pour le courrier électronique. Le port 50616 est dans la plage de ports éphémères , ce qui signifie qu'il n'y a pas d'utilisateur cohérent pour ce port. Un paquet TCP de «réinitialisation» peut être envoyé en réponse à un certain nombre de situations inattendues, telles que des données arrivant après la fermeture d'une connexion, ou des données envoyées sans établir au préalable une connexion.

35.162.106.154résout à l'envers cxr.mx.a.cloudfilter.net, un domaine utilisé par le service de filtrage des e-mails CloudMark.

Votre ordinateur, ou quelqu'un prétendant être votre ordinateur, envoie des données à l'un des serveurs de CloudMark. Les données arrivent de façon inattendue et le serveur répond avec un RSTpour demander à l'ordinateur expéditeur de s'arrêter. Étant donné que le pare-feu abandonne RSTplutôt que de le transmettre à une application, les données qui provoquent l' RSTenvoi ne proviennent pas de votre ordinateur. Au lieu de cela, vous voyez probablement une rétrodiffusion d'une attaque par déni de service, où l'attaquant envoie des flots de paquets avec des adresses "de" falsifiées dans le but de mettre les serveurs de messagerie de CloudMark hors ligne (peut-être pour rendre le spam plus efficace).

— marque
source

+1 pour la grande analyse! Je n'en avais aucune idée ...

— PerlDuck

Les messages proviennent d' UFW , le "pare-feu simple" et il vous indique que quelqu'un

de SRC=35.162.106.154
essayé de se connecter à votre hôte à DST=104.248.41.4
via TCP
de leur port SPT=25
à votre port DPT=50616
et que UFW a réussi BLOCKcette tentative.

Selon ce site, l'adresse source 35.162.106.154 est une machine Amazon (probablement une AWS). Selon ce site, le port 50616 peut être utilisé pour l' accès au système de fichiers Xsan .

C'est donc une tentative de IP = 35.162.106.154 d'accéder à vos fichiers. Assez normal et rien de vraiment inquiétant car c'est à cela que servent les pare-feu: rejeter de telles tentatives.

— PerlDuck
source

Il semble que la tentative de connexion provient d'un compte Amazon, le port 25 est un port de messagerie dois-je le signaler ou simplement l'ignorer? Spamming my logs

— peterretief

@peterretief vous pouvez le bloquer sur votre routeur; alors vous ne le verrez pas. Mais il pourrait être judicieux de signaler cela à votre FAI.

— Rinzwind

En fait, il dit «RST» et non «SYN», c'est donc un paquet de tentative SMTP sortant refusé qui a été filtré.

— Eckes

L'autre réponse me semble plus susceptible d'être correcte.

— Barmar

@Barmar En effet, et très gentiment mis. Celui-là devrait être la réponse acceptée.

— PerlDuck