Ist die Ausrüstung des ISP falsch konfiguriert? Abrufen von Mars-Paketen über die Internetschnittstelle

Wir haben einen / 28 Block von unserem ISP. Angenommen, 1.1.1.240/28 mit einem Gateway von 1.1.1.241. Wir erhalten Mars-Pakete von einem anderen Kunden am 1.1.1.214. Sie senden Sendungen an 1.1.1.255. Sollten wir diese Pakete bekommen? Ich verstehe das Senden in diesem Szenario nicht.

Syslog-Nachricht

Marsquelle 1.1.1.255 vom 1.1.1.214 auf dev eth0
ll Header: ff: ff: ff: ff: ff: ff: 00: XX: f3: XX: 69: ad: 08: 00

Netzwerkschnittstelle:

$ ifconfig eth0
eth0 Link-Kapselung: Ethernet HWaddr XX: XX: XX: XX: XX: XX: XX
          inet addr: 1.1.1.243 Bcast: 1.1.1.255 Maske: 255.255.255.240
          UP BROADCAST RUNNING MULTICAST MTU: 1500 Metrisch: 1
          RX-Pakete: 15161982 Fehler: 0 verworfen: 0 Überläufe: 0 Frame: 0
          TX-Pakete: 1627243 Fehler: 0 verworfen: 0 Überläufe: 0 Träger: 0
          Kollisionen: 0 txqueuelen: 100
          Empfangsbytes: 1028191733 (1,0 GB) TX-Bytes: 140279903 (140,2 MB)
          Speicher: fbde0000-fbe00000

Oder ist die Schnittstelle falsch konfiguriert? Der Bcast ist dort als 1.1.1.255 aufgeführt. Wenn dies normal ist, sollte der Kernel meiner Meinung nach nicht jede Minute Hunderte davon an Syslog senden.

AKTUALISIEREN

Diese Pakete kommen ständig in 2-3 pro Sekunde. Ich habe sie erfasst und sie UDP src / dst Port 15001: 10: 00: 91: 13: 00: 00: 39: 22: 23: 02: 00: 00: 00: 00: 00: 01: 3c: 62: 65 : 61: 63: 6f: 6e: 2f: 3e

linux-networking

— Jeremy
quelle

Das ist beängstigend - es riecht so, als würde Ihr ISP die Broadcast-Domains der Kunden nicht isolieren, und bei diesem anderen Kunden ist die Netzmaske einfach als / 24 falsch konfiguriert.

Wenn dies der Fall ist, handelt es sich um ein ziemlich ernstes Sicherheitsrisiko, da sie Ihre Geräte effektiv offline schalten oder versehentlich oder böswillig Datenverkehr für Ihre Systeme binden können.

Sie können ARPing für das System des anderen Kunden testen (was ohne eine Neukonfiguration der Schnittstelle Ihres Routers etwas schwierig sein könnte) oder einfach ARP in der Leitung beobachten und prüfen, ob Sie ARP-Anforderungen für dessen Subnetz erhalten.

Wenn die Broadcast-Domains tatsächlich verbunden sind, müssen Sie ein Herz an Herz mit Ihrem ISP haben.

— Shane Madden
quelle

Hmm, ich versuche den ARP-Verkehr auf der Schnittstelle mit tcpdump 'arp' -e -i eth0 -n -p -t -vv zu überwachen. Ich sehe keine Anfragen für etwas anderes als das, was in unserer / 28 steht. Ich schalte die Mars-Protokollierung auf der Benutzeroberfläche ein und aus, um sicherzugehen, dass sie noch läuft und tatsächlich so ist.

— Jeremy

@Jeremy Da der Datenverkehr ihres Systems ständig weitergeht, werden ARPs wahrscheinlich nicht sehr oft zwischen ihrem Router und dem ISP benötigt. Versuchen Sie möglicherweise, etwas anderes in ihrem Netzwerkbereich ( .215oder etwas anderes ) von einem anderen ISP-Uplink zu pingen, um einen ARP von den ISPs zu erzwingen Router für diese Adresse?

— Shane Madden

Der Router wird vom ISP verwaltet, daher bin ich dort eingeschränkt. Ich habe versucht, einen Ping zu fälschen: hping3 --icmp -a 1.1.1.215 1.1.1.214, aber keine ARP-Anfragen erhalten. (.214 Pings ohne gefälschte Adresse). Ich frage mich, ob das ein guter Grund ist, sich darüber keine Sorgen zu machen. Ich habe auch versucht, .215 von einem anderen ISP mit den gleichen Ergebnissen zu pingen.

— Jeremy

@ Jeremy Hmm, ja, hört sich so an, als würden Sie keine Broadcast-Domain teilen, was gut ist. Vielleicht hat der ISP nur eine neuartige Filterung, bei der diese spezifischen Pakete fehlen? Eine andere Sache, die Sie überprüfen sollten, wenn Sie können, ist, eines dieser Mars-Pakete zu erfassen, um einen Blick darauf zu werfen, was es tatsächlich ist - kommen sie regelmäßig genug herein, damit Sie möglicherweise eines erfassen können?

— Shane Madden

Meine Frage wurde beantwortet, was im Grunde "das sollte nicht passieren" ist. Danke für die Hilfe. Senden Sie es die Fahnenstange.

— Jeremy