web-dev-qa-db-fra.com

Pourquoi ufw enregistre-t-il les messages 'BLOCK' concernant un port pour lequel ufw est configuré pour les connexions 'ALLOW'?

Voici un exemple de message de journal:

 25 mai 10:36:07 noyau myserver: [7057243.392334] [UFW BLOCK] IN = eth0 OUT = MAC = 00: 02: 55: 67: 82: eb: 00: 06: b1: 3a: ef : 62: 08: 00 SRC = 69.197.128.26 DST = 192.168.100.101 LEN = 44 TOS = 0x00 PREC = 0x00 TTL = 32 ID = 0 PROTO = TCP SPT = 48788 DTC = 80 FENETRE = 972 RES = 0x00 RST URGP = 0 

D'après ce que je comprends, DPT signifie "port de destination", mais depuis que j'ai configuré ufw pour autoriser connexions entrantes sur le port 80, je suis perplexe de savoir pourquoi je verrais un tel un message de journal - un message de journal qui semble indiquer qu'ufw a bloqué une tentative de connexion sur ce port.

Voici les lignes pertinentes de ufw status:

 À partir du 
 - ------ ---- 
 80/TCP Autoriser partout 
 80/TCP Autoriser n'importe où (v6) 

Je l'ai maintenant vu à la fois sur Ubuntu 11.10 et maintenant (après la mise à niveau de la même machine) sur Ubuntu 12.04.

5
Chris W.

Le fil référencé par Caffeine Coma indique que cela est lié aux détails techniques bas dans la fermeture de TCP connexions réseau ... Différences obscures et subtiles entre les systèmes d'exploitation (Windows, Mac, La terminaison de connexion de Linux) entraîne apparemment une certaine confusion inoffensive entre serveur et client, ce qui entraîne en quelque sorte les messages de journal décrits ci-dessus.

Je ne comprends pas tout à fait les détails techniques, ni la raison pour laquelle cela mènerait à la journalisation des messages de journal "BLOCK" de UFW, mais je vais le comprendre, car c’est la seule réponse que j’ai trouvée qui ait un sens, et je n’ai pas vu. autre symptôme de quelque chose qui ne va pas sur mon serveur - seulement ces messages de journal UFW inoffensifs (bien que gênants).

Référez-vous à le fil de discussion mentionné pour une explication plus technique.

5
Chris W.

Je peux l'expliquer un peu en détail, sans être technique.

Je vais juste utiliser un simile.

Imaginez juste que deux personnes se parlent et supposons qu’elles font des affaires entre elles et qu’elles acceptent de mener leurs affaires d’une certaine manière.

Chaque fois qu'ils effectuent une transaction, cela se fait de la même manière.

  1. Meet and Greet - Ils conviennent qu'une transaction ne réussit que s'ils s'assoient dans la même pièce et se serrent la main, au début. C'est une étape obligatoire.

  2. Ecoute et re "envoi" - Ils conviennent qu'une transaction n'aboutit que si toutes les données nécessaires à cette transaction sont comprises et si une partie n'obtient pas une réponse adéquate, ils réévaluent le statut et "relient" sur certains aspects de la cette transaction, jusqu'à ce que les deux parties soient satisfaites du résultat et conviennent que la transaction est en ordre.

Ceci comprend

  1. a) La confirmation sous la forme d'une poignée de main au début de chaque rencontre et b) Une confirmation finale à la fin des deux côtés. De plus, le vendeur doit rester dans la pièce pendant un certain temps jusqu'à ce qu'il soit certain que l'acheteur est parti.

Les connexions TCP fonctionnent de manière similaire. Y a-t-il quelque chose qui cloche alors le pare-feu vous en parle?.

Pourrait être un faux acheteur, qui dit simplement bonjour et repart ensuite (sonde) Peut-être un véritable acheteur, qui n'est plus certain au milieu et qui quitte la pièce (utilisateur) Peut être un problème de communication (routage, réseau, etc.)

HTH, s1mmel

1
s1mmel

Je suis également curieux à ce sujet, car je reçois des entrées de journal similaires, même à partir de serveurs Googlebot.

Ce fil semble dire qu'il n'y a pas de quoi s'inquiéter, mais il me semble très étrange de les avoir comme registre BLOCK dans UFW.

0
Caffeine Coma