MAC-Adresse mit C++ von Client bestimmen

Was wenn Server und Client nicht direkt in einem Ethernet-Netzsegment 
sind, also z.B. über das Internet oder ein VPN verbunden sind? Dann 
bekommt der Server die MAC vom Client niemals zu sehen und du müsstest 
sie manuell mitschicken.

xenon schrieb:
> Ich habe viel darüber gelesen den arp -a Befehl zu verwenden. Wäre das
> der richtige Ansatz?
Damit kannst du in einem Ethernet-Netz die Mac zu einer IP rausfinden, 
ja. Aber ob die sich nicht zwischenzeitlich geändert hat erfährst du so 
nicht.

Wozu brauchst du die MAC-Adresse? Die ist eigentlich nur für 
Netzwerk-Hardware relevant, zur IP-Kommunikation braucht man sie nicht.

MAC-Adressen werden nur im LAN verwendet, d.h. in IP-Paketen steht als 
Absender-MAC nur die des letzten Routers drin (der, der sie ins LAN 
eingespeisst hat). Rein theoretisch kann die bei jedem Paket anders sein 
(mehrere Router) und bei einigen Verbindungen gibt es gar keine (die 
nicht über Ethernet gegangen sind). Soviel ich weiß, gibt es keine 
standardisierte Funktion, die MAC-Adresse zu bekommen. Die remote 
IP-Adresse bekommst du mittels getpeername.

Grundsätzlich hast du zwei Probleme die gelöst werden wollen.
 1.) Normalerweise handelt das Betriebssystem den IP-Stream für dich, 
der Ethernet header kommt also garnicht bis zu dein Programm, ausser du 
verwendest RAW-Sockets aber dann musst du alles im TCP/IP von hand 
machen, dass will man meistens nicht.

 2.) wie man das Betriebssystem nach den Mac-Adressen fragt ist Os 
Spezifisch , unter Linux könnte arp -a eine möglichkeit sein. Ich gehe 
daher davon aus das du Linux nutzen willst. Dann ist "man 7 arp" Dein 
freund. https://www.systutorials.com/docs/linux/man/7-arp/ Ich würde 
wahrscheinlich  nicht versuchen den Output von arp zu parsen sondern die 
beschrieben ioctls nutzen.

Generell: in Zeiten von Routern, Firewalls, man in the middle, Deep 
Packet Inspection und der Tatsache das heute jedes Scriptkiddie 
Mac-adressen fälschen kann, würde ich mich nicht zu sehr darauf 
verlassen, dass der Client die MAC hat welche bei mir ankommt.

Nils X. schrieb:
> Aber sollte ich
> die MAC-Adresse einfach ignorieren, anstatt es programmtechnisch mit zu
> implementieren?

Sende in deinen TCP- oder UDP-Paketen doch einfach eine Seriennummer des 
Sensors mit; viele Mikrocontroller liefern ja eine eindeutige 
Seriennumer bereits mit. Das ist ähnlich "sicher" wie die Abfrage der 
MAC, dafür geht das aber über alle Arten von Netzwerken und überlebt 
auch Router, und du brauchst keine plattformspezifischen API's in der 
PC-Software.

Nils X. schrieb:

> Ich komme mehr aus der Elektrotechnik-Ecke und wollte anfangen mit IP
> und MAC auf zulässige Kommunikationspartner zu prüfen.

Das kannst du gleich erstmal voll knicken. MACs und IPs sind Schall und 
Rauch, sie lassen sich sehr einfach fälschen (oder neudeutsch: spoofen).

Wenn du "zulässige Partner" wirklich sicher identifizieren können 
willst, kommst du nicht um starke Kryptographie herum, also 
asymmetrische Verschlüsselung und ein sicheres Protokoll zum Austausch 
der Zertifikate.

Das alles brauchst du nicht selbst zu erfinden, gibt es alles schon. Was 
dir aber niemand abnehmen kann: du musst diesen Kram verstehen und zwar 
bis in's Detail. Sonst wird's nimmer sicher...

Blöd bloss: das ist wirklich ein fürchterlich großer Haufen Lesestoff 
und die fehlerfreie Umsetzung, selbst unter Benutzung der vorhandenen 
freien Libs, die dir die eigentlichen Knackpunkte schon weitgehend 
abnehmen, hat's auch in sich...

Ich fürchte: frühestens in ungefähr 10 Jahren könntest du soweit sein, 
es wirklich richtig zu machen...

c-hater schrieb:
> Ich fürchte: frühestens in ungefähr 10 Jahren könntest du soweit sein,
> es wirklich richtig zu machen...

Ah, also hat jeder Websitenbetreiber 10 Jahre daran gesessen seine Seite 
verschlüsselt per HTTPS anzubieten? Es gibt das ganze Kryptozeug auch 
schon handlich in Bibliotheken verpackt. Die kann man auch in deutlich 
unter 10 Jahren sinnvoll einsetzen, aber man muss natürlich schon wissen 
was man tut, es kann immer noch einiges falsch gemacht werden. Das 
gibt's auch für Embedded Systems, wie z.B. bei WolfSSL.

c-hater schrieb:
> Wenn du "zulässige Partner" wirklich sicher identifizieren können
> willst, kommst du nicht um starke Kryptographie herum, also
> asymmetrische Verschlüsselung und ein sicheres Protokoll zum Austausch
> der Zertifikate.
Verschlüsselung ist zur Authentifizierung und Integrität nicht 
zwangsweise erforderlich. Auch bei unverschlüsseltem Datenstrom kann man 
das Gegenüber sicher identifizieren. Es wird nur häufig beides 
kombiniert. Zertifikate selbst muss man nicht "sicher" austauschen, die 
sind quasi öffentlich. Für eine solche Anwendung braucht man Zertifikate 
gar nicht unbedingt, weil man ja beide Seiten kontrollieren kann. Es 
reicht eine normale Public-Key-Authentifizierung.

Mit den Messdaten die MAC-Adresse oder Seriennummer mitsenden, alles per 
Hash (das noch ein Shared Secret enthält) absichern, fertig.

Falls Replay-Attacken ein Thema sind, Timestamp und/oder Sequence Number 
mit rein.

Aber wenn Client und Server das hergeben, kannst Du auch gleich SSL/TLS 
einsetzen.

Dr. Sommer schrieb:

> Zertifikate selbst muss man nicht "sicher" austauschen, die
> sind quasi öffentlich.

Sorry, natürlich hast du hier Recht, die Zertifikate, also die public 
keys sind natürlich jederzeit öffentlich oder zumindest 
quasi-öffentlich, deren Austausch ist also nicht kryptographisch 
gesichert. Maximal nur dadurch, das man einfach nix austauscht, was 
irgendwie aber nicht im Sinne der Kryptographie ist, auch wenn es die 
Sicherheit de facto tatsächlich erhöhen kann...

Gemeint war natürlich der "sichere Schlüsselaustausch" beim Aufbau der 
Verbindung, wie du korrekt dargestellt hast.