Comment les datagrammes UDP ne me possèdent pas en tant que destinataire atteignant mon server?

J'ai beaucoup de datagrammes UDP atteignant mon server qui ressemble à ceci:

Certains datagrammes UDP ne sont pas pour mon serveur

La question est que mon IP n'est pas 208.69.57.21 (c'était 208.69.57.101 ) alors, comment ces datagrammes sont-ils même reçus / enregistrés par mon tcpdump?

De plus, quel type d'attaque est-ce formellement appelé? Je ne pense pas que ce soit DOS.

4 Solutions collect form web for “Comment les datagrammes UDP ne me possèdent pas en tant que destinataire atteignant mon server?”

Je pourrais me tromper, mais la seule façon dont je peux penser qu'un datagramme arrive à votre ordinateur lorsque l'adresse de couche 3 ne correspond pas si l'adresse de couche 2 est résolue manuellement sur l'expéditeur et l'expéditeur est sur la même couche 2 segment. Si cela est vrai, vous devriez pouvoir identifier l'expéditeur par l'adresse source du calque 2 dans cette capture de packages. Je suppose qu'il est également possible que le périphérique de couche 3 (routeur ou pare-feu) qui s'asseoir sur votre segment de couche 2 pourrait être compromis ou mal configuré pour aboutir à une résolution incorrecte de cette adresse de couche 3 à votre adresse de couche 2.

Dans les deux cas, aller après l'expéditeur tel qu'identifié par leur adresse MAC.

Le masque de réseau est-il utilisé par votre réseau? S'il s'agit de / 24, vous risquez de voir le trafic de quelqu'un d'autre parce que leur adresse de destination n'est pas dans la table CAM du switch . Si un commutateur ne sait pas quel port un périphérique est connecté, il enverra le trafic destiné à ce périphérique sur chaque port.

Est-ce une attaque? Pas certain. Le fait que les numéros de port source et de destination soit 0 avec l'erreur de longueur UDP semble impair. Peut-être que quelqu'un essaie de voir si 208.69.57.21 est vulnérable à MS11-083 / CVE-2011-2013 .

À less d'avoir un réseau atypique, il n'y a pas de règles pour éviter qu'un package ne soit commuté sur des machines autres que sa destination. La couche Ethernet n'a aucune idée de l'adresse IP pour laquelle les packages sont liés, donc il ne peut pas les filterr de manière fiable par IP. Il filter par adresse matérielle Ethernet, mais il ne sait pas toujours quel port est associé à une adresse matérielle Ethernet. Donc, certains packages sont inondés sur tous les ports commutés.

Ceux-ci semblent être corrompus cependant.

Est-il possible que votre hôte soit un server privé virtuel? Peut-être que ces datagrammes sont destinés à un autre conteneur qui partage la même NIC avec votre nœud. ( … et pour une raison quelconque votre NIC est en mode promiscuous )

Ce serait une attaque par inondation UDP , si les datagrammes n'étaient pas corrompus et étaient destinés à des ports randoms.

  • Existe-t-il un moyen de dire à une machine accessible via un tunnel Gre pour join des groupes de multidiffusion via pimd ou smcroute?
  • Problèmes liés à l'inondation du MDNS sur le port 5353 UDP
  • Comment mesurer et minimiser la perte de packages UDP
  • Solution de surveillance réseau
  • HTTPS utilise TCP ou UDP?
  • Erreur OpenVPN: erreur TLS: les touches TLS locales / distantes sont désynchronisées:
  • Quels ports UDP sont nécessaires pour résoudre les hôtes externes?
  • Poinçonnage symésortingque NAT et UDP
  • Quelle est la taille de la window TCP par défaut sur Windows Server 2008?
  • Les packages UDP sont affichés au niveau de l'interface, mais ne sont pas livrés à l'application sur RedHat
  • Countermeasures contre l'attaque de reflection DNS entrante
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.