RootForum Community

Leicht OT, aber für den Einen oder Anderen eventuell informativ (Bitte selbst durchklicken):
http://archives.linuxfromscratch.org/ma ... hread.html

netzmeister wrote:

Schlagt mich, wenn ich falsch liege, aber aus dem tcpdump-Log geht für mich klar hervor, dass hier ARP-Broadcasts über eine Collision-Domain hinweggeleitet werden - was insbesondere bei einem Switch zwar machbar, aber weder "regelkonform" noch sinnvoll ist.

Gut zu wissen. Bin gespannt, was der Support sagt.

Na hoffentlich ist "er" ganz leise, nickt nur und 10 Minuten später ist alles in Ordnung - natürlich ohne Berechnung und mit einem Quartal Kostenerstattung ;)

Mit welchen Optionen hast Du tcpdump aufgerufen?

Mit gar keinen. Einfach nur "nohup tcpdump > dump &" und dann ein logout.

Also lief's im promiscuous mode. Wollte nur sicherstellen, dass auch nicht "zugehöriger" Traffic mitgeschrieben wurde und das Gebrabbel nicht ausschließlich von Dir stammte.

Hängt die Maschine direkt am Switch oder klemmt da noch ein Hub dazwischen?

Wenn ich das beim Einbau des Servers und Rundgang durchs RZ richtig gesehen und verstanden habe, hängt die Maschine direkt an einem Cisco-Switch.

Wäre es möglich, ein paar mehr Details über die Netzwerkkonfiguration der Maschine (logische Position im Netz, verwendete IP-Adressen auf den Interfaces) zu erfahren?

Hmm, lo auf 127.0.0.1, eth0 auf 217.24.YYY.ZZZ, Netzmaske 255.255.255.0, Gateway 217.24.YYY.1

[traceroute entfernt]

Hmm - Also 08/15-Konfiguration. Kiste hängt direkt am Switch und dort wird auch für's Accounting gezählt. Dann sollte allerdings auch sichergestellt sein, dass wirklich nur für Dich bestimmter Traffic zu Dir gelangt (ich seh' da ein paar NetBT-Broadcasts, Browser Elections, usw. die wahrscheinlich nichts mit Deiner Kiste zu tun haben), auch aus Sicherheitsgründen (Sniffing/Spoofing/Snarfing). So, wie dein Dump es zeigt, wird der Switch als Hub betrieben. Unsinnig, unnötig und gefährlich.

Momentan übrigens "ifconfig":
RX bytes:375770422 (358.3 MiB) TX bytes:12126988 (11.5 MiB)

Und "iptables --list -v":
Chain INPUT (policy ACCEPT 42642 packets, 3415K bytes)
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
Chain OUTPUT (policy ACCEPT 23416 packets, 12M bytes)

Um nochmal sicherzugehen: iptables zählt wirklich alles mit, was für meine IP bestimmt ist?

Jau - Du kannst natürlich auch noch arptables einsetzen (musst Du in der Kernel-Config extra aktivieren), dann zählst Du auch den ARP-Verkehr zu Deinem Interface mit. IPTables zählt nur auf IP-Ebene mit, in Deinem Fall eher ungenau :/

Joe User wrote:Leicht OT, aber für den Einen oder Anderen eventuell informativ (Bitte selbst durchklicken):
http://archives.linuxfromscratch.org/ma ... hread.html

Mach' ich später, bin noch an d-u-g dran und habe d-d und l-d noch vor mir ;)

Hi!

Kleines Update in eigener Sache: das Problem sollte seit heute Abend behoben sein.

Laut Support existiert ein Zählrechner im LAN, der sämtlichen Broadcast- und ARP-Traffic loggt und bei der Monatsabrechnung vom Switch-Traffic wieder abzieht.

Bei mir wurde nun vergessen, diese Kompensation auf das Realtime-Traffictool aufzuschalten, so dass dort der falsche Stand angezeigt wurd.

Mal die nächsten Tage beobachten, was da passiert; zumindest die Traffickurve zeigt seit ungefähr einer Stunde steil nach unten :-)

Gruss und nochmals Danke an alle Ratgebenden,
Alexander

netzmeister wrote:Hi!

Kleines Update in eigener Sache: das Problem sollte seit heute Abend behoben sein.

:D

Laut Support existiert ein Zählrechner im LAN, der sämtlichen Broadcast- und ARP-Traffic loggt und bei der Monatsabrechnung vom Switch-Traffic wieder abzieht.

Bei mir wurde nun vergessen, diese Kompensation auf das Realtime-Traffictool aufzuschalten, so dass dort der falsche Stand angezeigt wurd.

Ã?ndert aber nichts an der unsicheren Switch-Konfiguration. Da 'nen Sniffer erfolgreich in's Netz zu hängen ist ein Kinderspiel, von MITM-Angriffen ganz zu schweigen. :evil:

Würde mir ernsthaft überlegen, den Provider zu wechseln. Selbst höhere Aufwände und Ausfallzeiten dürften "billiger" als geknackte Kisten sein (der Einbruch auf den Debian-Servern fing auch mit erlauschten Passwörtern an).

Mal die nächsten Tage beobachten, was da passiert; zumindest die Traffickurve zeigt seit ungefähr einer Stunde steil nach unten :-)

Gruss und nochmals Danke an alle Ratgebenden,
Alexander

Gern geschehen. :)