Hallo zusammen, ich bin dabei eine Server-Application in C++ zu schreiben und möchte dazu die IP und MAC-Adresse der Clients sichern. Jetzt habe ich das Problem an die MAC-Adresse zu kommen. Ich dachte das ich einfach aus dem Ethernet-Header die MAC-Adresse des Client auslesen kann oder komm ich an diese Informationen nicht heran? Ich habe viel darüber gelesen den arp -a Befehl zu verwenden. Wäre das der richtige Ansatz? LG xenon
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.
C++ ist eine Programmiersprache, die kennt per se gar kein Ethernet und kein IP. Also wird es irgend eine lib passend für dein Betriebsystem geben, die die benötigten Funktionen bereitstellt. Deren Doku wäre wohl die erste Anlaufstelle für solche Fragen. Oliver
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.
Jungs ihr seit echt schnell mit den Antworten top Ich befindet mich in einem locale Netzwerksegment auf einem Linux System. In diesem werden Sensordaten über TCP/IP oder UDP an einen Server gesendet. An dieser Stelle möchte ich möglichst viele Informationen über die angeschlossenden System einholen. Ich komme mehr aus der Elektrotechnik-Ecke und wollte anfangen mit IP und MAC auf zulässige Kommunikationspartner zu prüfen. In den nächsten Stufen soll dann das Daten-Protokoll gefiltert werden. An den Ethernet-Header komm ich also nicht über den socket-Descriptor ran. Dann muss ich also die ioctls benutzen. Oder würde es eventuell sinn machen kontinuierlich den arp -a befehl ausführen zu lassen und die Daten von einem andere Programm auszuwerten und in einem Speicher abzulegen auf den man dann zugreifen kann?
Nils X. schrieb: > mit IP > und MAC auf zulässige Kommunikationspartner zu prüfen Du weisst, dass man die MAC-Adresse beliebig wählen kann - das ist niemals ein Sicherheitsmerkmal. Um Kommunikation abzusichern solltest Du Dich z.B. mit Verschlüsselung beschäftigen.
Das mit den MAC-Adressen habe verstanden, da die Qeullen eine Verschlüsselung momentan noch nicht unterstützt wird dies sicher zu einen späteren Zeitpunkt ein Thema. Zum jetztigen Zeitpunkt muss ich mich an die gegebenheiten anpassen. Beim abprüfen von MAC und IP wird es auch nicht bleiben. Aber sollte ich die MAC-Adresse einfach ignorieren, anstatt es programmtechnisch mit zu implementieren?
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.
@ Dr. Sommer: Deine Idee nehme ich auf, geht auf jedenfall schneller und ist besser umzusetzen :)
Nils X. schrieb: > Das mit den MAC-Adressen habe verstanden, da die Qeullen eine > Verschlüsselung momentan noch nicht unterstützt wird dies sicher zu > einen späteren Zeitpunkt ein Thema. > > Zum jetztigen Zeitpunkt muss ich mich an die gegebenheiten anpassen. > Beim abprüfen von MAC und IP wird es auch nicht bleiben. Aber sollte ich > die MAC-Adresse einfach ignorieren, anstatt es programmtechnisch mit zu > implementieren? Ja! Spätenstens, wenn sich ein Router/L3-Switch zwischen Client und Server befindet, siehst Du nur noch die MAC des Routers für alles, was nicht aus der gleichen Broadcast Domain kommt. Der Einfachheit halber kann dein Sensor seine MAC auch in den Nutzdaten als ID mitsenden. fchk
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.
Beitrag #5444120 wurde von einem Moderator gelöscht.
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.
Beitrag #5444172 wurde von einem Moderator gelöscht.
c-hater so einfach ist es dann doch nicht... Nur weil du nicht auf den grünen Zweig damit kommst musst du es nicht verteufeln.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.