MAC übers Internet

N

namespace

Mitglied
Ich hätte da jetzt mal ne richtig blöde Frage, zu der ich irgendwie nicht wirklich ne Antwort finde.

Wird im Internet in den einzelnen Paketen auch die MAC-Adresse übertragen?
Wenn das so wäre, könnte man ja einzelne MAC-Adressen sperren um das Spammen einzelner Personen in einem Gästebuch o.ä. zu verhindern (klar lässt sich diese schnell ändern, aber ich glaube nicht, dass solche Leute soweit denken).
 
Wird im Internet in den einzelnen Paketen auch die MAC-Adresse übertragen?
Ja! Und zwar die vom letzten Router.
Wenn das so wäre, könnte man ja einzelne MAC-Adressen sperren um das Spammen einzelner Personen in einem Gästebuch o.ä. zu verhindern (klar lässt sich diese schnell ändern, aber ich glaube nicht, dass solche Leute soweit denken).
=> Nein geht nicht. Da würdest du nicht nur einen User aussperren.

blue
 
1. Es gibt keine dummen Fragen - nur dumme Antworten! ;-)

2. Klaro wird die MAC Adresse ständig mitgesendet.
Ist nur die Frage, ob man als "normaler" Webmaster so einfach an die dran kommt.
(Auslesen der Protokolle...)
 
blue schrieb:
Ja! Und zwar die vom letzten Router.
D.h. der Router über den ich mit meinem Home-LAN am Internet hänge? Oder meinst du bspw. auch die Switches der T-Online?

=> Nein geht nicht. Da würdest du nicht nur einen User aussperren.
Würde sich das nur auf ein Büro/Home-Netzwerk beziehen wäre das ja egal, die Chancen, dass gerade noch einer aus diesem die Seite besucht, ist ja relativ gering.

Ist nur die Frage, ob man als "normaler" Webmaster so einfach an die dran kommt.
Geht mir eigentlich nur mehr um die Theorie.

Danke euch zweien.
 
Kann ich gestern tot gewesen sein? *G


Ich halte es für unwarscheinlich da ich noch nie etwas von einem ban auf mac basis im internet gehört habe. (soll aber nicht heißen das es das nicht gibt nur weil ich es nicht kenn)
 
D.h. der Router über den ich mit meinem Home-LAN am Internet hänge? Oder meinst du bspw. auch die Switches der T-Online?
Damit mein ich auch die Router von den Providern.

blue
 
2. Klaro wird die MAC Adresse ständig mitgesendet.
Ist nur die Frage, ob man als "normaler" Webmaster so einfach an die dran kommt.
(Auslesen der Protokolle...)
Natürlich wird die mitgesendet. Im Ethernet. Das Internet ist aber glücklicherweise kein großes Ethernet. U.a. weil ethernet ein bisschen scheisse skaliert.
 
foobarflu schrieb:
Natürlich wird die mitgesendet. Im Ethernet. Das Internet ist aber glücklicherweise kein großes Ethernet. U.a. weil ethernet ein bisschen scheisse skaliert.
Was willst du jetzt sagen? :frage:

Ich halte es für unwarscheinlich da ich noch nie etwas von einem ban auf mac basis im internet gehört habe.
Jo, hab ich auch noch nicht, wäre aber eigentlich effektiver als ein Ban gegen eine best. IP.
So, und jetzt ein paar Ideen zur Verwirklichung ;)
Man könnte ja sicherlich einfach einen Sniffer laufen lassen, das Ganze mit nem Perl-Script auswerten und wenn die MAC mit der angegebenen übereinstimmt wird die IP in die Liste gesperrter Hosts gesetzt.
 
OSI-Layer 8 hat zugeschlagen ! :D

also leute (ohne jetzt klugscheisserisch klingen zu wollen) versuche ich euch mal die sache zu erklären ...
und das ist wohl der erste versuch der welt, das osi layer modell für teenies aufbereitet zu servieren *scnr* ....

stellt euch bitte mal folgendes vor: ...

Herr Müller (client) möchte eine banane zur Frau Fröhlich (server) transportieren, ok.

Herr Müller wird die banane natürlich nicht einfach so bei der post abgeben, also verpackt er sie anständig mit empfänger und absender adresse (ip-paket mit ip destination/target - address) versehen. Er hat nun verschiedene möglichkeiten den inhalt und die art des packetes zu gestalten: ganz schlicht, ohne jegliche emotion die banane in grauem papier eingewickelt (udp, verbindungslos, stateless) oder mit besonders viel aufwand und wunderschön bunt mit grusskarte und einschreiben per rückbrief (tcp, verbindungsorientiert, statefull). Herr Müller möchte gerne länger mit Frau Fröhlich in verbindung bleiben, also wählt er die zweite, verbindungsorientierte version. Nun packt Herr Müller das Paket ins auto mit dem kennzeichen "HU-XV 320" (hardwareebene, mac address) und fährt damit zur örtlichen post (1. router) und gibt da das paket ab (sending SYN) . die dame von der post nimmt das paket an und Herr Müller fährt fröhlich - auf eine reaktion wartend - nach hause zurück. mehrere postautos - mit uns natürlich unbekanntem kennzeichen (mac address) - transportieren das paket jetzt bis zu Frau Fröhlichs haus. ein, oder eher zwei tage später - und gerade noch rechtzeitig, denn bananen halten ja nicht ewig (TTL, time to live, verfallszeit des paketes[1]) - klingelt der postbote (letzter router) bei Frau Fröhlich und sie öffnet die tür. Frau Fröhlich nimmt nun freudig das paket entgegen (receiving SYN) und unterschreibt den einschreibebeleg (sending SYN/ACK). schnell schaut nun Frau Fröhlich noch wo denn das paket her kommt. auf dem nummernschild steht "FR TK-238" (mac address). Herr Müller bekommt noch den einschreibe empfang bestätigt (receive ACK) was aber für uns hier unerheblich ist.

so, und nun kommt die frage: kann Frau Fröhlich auf das nummernschild (mac address) des absenders Herrn Müller rückschliessen? wie kann Fr. Fröhlich den absender erkennen? doch ausschiesslich am paket (ip address), da das absender-kfz-kennzeichen durch den transport verfälscht ist, oder nicht?

[1] im realfall wird das paket ausgesondert, wenn es ausläuft und pervers nach schwarzer banane stinkt (TTL abgelaufen, praxistest: ping -t 1 web.de)

ich hoffe, die ausführung klärt die situation. absender-mac-adressen verfallen an _jedem_ hardwaredevice beim transport, genau so, wie sich das derzeitige nummernschild des autos (HW address) beim umladen eines paketes verändert.

gruss, systemdefender.
 
Zuletzt bearbeitet:
Joa, dass das nicht funktioniert, hat blue uns ja schon mitgeteilt... aber schöne Geschichte.

Mal ne andere Frage dazu, wird dann eigentlich die Netzwerk-IP im Paket mitgesendet?
Denn bei der Antwort des Servers, muss der Router vom Lokalen Netzwerk ja auch wissen, an wen das Paket jetzt gehen sollt (also wer es ursprünglich versendet hat).
 
namespace schrieb:
Joa, dass das nicht funktioniert, hat blue uns ja schon mitgeteilt... aber schöne Geschichte.
danke. der vorteil von erkenntniss gegenüber wissen ist, dass du nicht nur die information, sondern auch die hintergründe kennst. (beispiel:geometrie-formeln auswendig lernen vs. selber -ggf. unter anleitung- entwickeln)
namespace schrieb:
Mal ne andere Frage dazu, wird dann eigentlich die Netzwerk-IP im Paket mitgesendet?
Denn bei der Antwort des Servers, muss der Router vom Lokalen Netzwerk ja auch wissen, an wen das Paket jetzt gehen sollt (also wer es ursprünglich versendet hat).
ok, als ausgangssituation vergessen wir erst mal die mittlerweile riechende banane.

also, dein client (Herr Meier) will dem server (Frau Fröhlich) eine nachricht schicken. jetzt kommt es darauf an, ob du einen gewöhnlichen router hast (eine normale postfiliale) oder ob du einen chiffre-dienst - also nicht deine eigene adresse (client ip address) - benutzt. im ersten fall müsstest du eine real-ip (echte postadresse angeben) haben. als dial-in-verbindung hast du i.d.r. nur eine realip, nämich die deines einwahlrouters. deshalb muss der router etwas tricksen und deine internen adressen den anfragen/antworten zuordnen und die internen adressen sozusagen übersetzen (NAT, network address translation). der nat-router merkt sich also die kommunikations partner und den status der verbindung (ähnlich der arbeit des chiffre-büros). wenn du einen nat-router nutzt kann der server nicht wissen, welcher client aus deinem internen netzwerk die anfrage stellt - denn der nat-router hat die absender ip umgeschrieben - ausser der client (Herr Müller) teilt es dem server (Frau Fröhlich) aktiv mit.

gruss, sysdef.


siehe auch: http://www.selflinux.org/selflinux/html/nat.html
 
Zuletzt bearbeitet:

Ähnliche Themen

Einige Anfängerprobleme

printk (Server) Probleme bei zuvielen Verbindungen

Routing-Probleme bei Suse 10.0

Gigaset USB Adapter + ndiswrapper und grundsätzliche WLAN-Fragen

Server-Monitoring mit RRDTool

Zurück
Oben