DHCP-Eintrag am Server wird überschrieben - wie kann man das verhindern?

Faltohrkatze

Neuling
Thread Starter
Mitglied seit
26.10.2013
Beiträge
35
Ort
nebenan
Leider wird auch in unserem Netz von einigen Nutzern rum gespielt. So haben wir Nutzer, die verpassen Ihrer privaten Technik eine feste IP aus unserem Netz und verbinden dann die gebootete private Endtechnik mit dem LAN. U.a. um damit via TCP/IP-Printerporteinrichtung die hochwertigen Farbdrucker privat zu nutzen. Wird zu diesem Zeitpunkt nun der zu der IP gehörende Betriebs-PC gestartet, führt das leider zu Problemen. Denn der Betriebs-PC kann nun leider vom Server die ihm gemäß DHCP-Eintrag zugeordnete IP nicht erhalten und hat damit keine Netzverbindung. Noch schlimmer aber ist, dass gleichzeitig auch die MAC-Adresse am Server für den DHCP-Eintrag durch irgendwas überschrieben wird. Und damit der zugehörige Betriebs-PC auch nach dem Entfernen der Privattechnik beim Booten keine IP mehr bekommt.
Wobei unser DHCP beim Booten eigentlich ein PXE-Boot ist. Im AD steht natürlich weiterhin die richtige MAC des gestörten PC noch drin.
*
Hat hier jemand eine wirklich gute Idee, die auch wirklich funktioniert? Also MAC-Filterung an den Switch ist bei uns nicht nutzbar, dafür ist bei uns viel zu viel Bewegung im Netz.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Nun, wenn es dir technisch (= MAC-Filterung/802.1x am Switch) nicht möglich ist unauthorisierte Geräte im Netzwerk zu unterbinden bleibt ja wohl nur noch die organisatorische. Also nochmal drauf hinweisen dass es verboten ist Privatgeräte an's Firmennetz zu hängen, und wenn das nicht fruchtet -> Abmahnung.
 
In dem Netz werden u.a. mindestens 12 000 (verschlüsselte) Notebooks an jedem Datenanschluss eingesetzt, von denen täglich einige ausgetauscht werden. Damit hat sich hoffentlich jede Diskussion zum Thema MAC-Filterung an den Switch erledigt.
Und der Hinweis bringt natürlich auch nichts, solange man den Täter nicht direkt auf frischer Tat stellen kann. Und der Hauptverdächtige hat allein in dem am meisten betroffenen Objekt rund 100 Datenanschlüsse zu freien Auswahl und kann dort stundenlang unbemerkt hantieren ... .
Juristisch wurde die Sache inzwischen als Straftat eingestuft! Aber das nützt uns nichts ... .
*
Gibt es wirklich keine echte funktionierende Lösung am Server? Unser nicht gerade kleines Team hat trotz sporadischer (also wenn mal Zeit ist) aber nun schon wochenlanger Suche im Internet bisher nichts wirklich brauchbares gefunden Wobei: mitunter sieht man ja den Wald vor lauter Bäumen nicht. Deshalb frage ich ja hier.
 
also grundsätzlich solltest du mal mehr zu deiner Infrastruktur sagen, mit den paar Brocken kann niemand was anfangen.
Von was für einem DHCP Server reden wir überhaupt? Und was hat der mit PXE Boot zu tun? Und wenn es ein Windows DHCP ist, der speichert kein MAC Adressen im AD ...

Desweiteren ist natürlich auch die Frage was du eigentlich erreichen möchtest? Diesen einen Störenfried finden? Dafür sorgen dass seine Aktion keinen Office-PC lahmlegt? Eine generelle Lösung um fremde Geräte im Netz zu blocken?

Da so viele Parameter nicht bekannt sind, einfach mal ein paar unstrukturierte Ideen dazu:

- Anscheinend ist euer DHCP ja so konfiguriert dass ohne passende Reservierung keine IP vergeben wird. Das zu ändern würde erstmal dem Office PC helfen. Dann bekommt er zwar nicht "seine" IP, aber wenigstens überhaupt eine und funktioniert.
- unter Linux kannst du das Paket Arp-watch installieren. Das informiert dich wenn eine unbekannte MAC Adresse auftaucht, bzw eine IP plötzlich eine andere MAC Adresse hat. Kommerziell und schöner gibts das natürlich auch, nennt sich Arp Guard.
- Mit der passenden Infrastruktur (Switches, Zertifikatsverteilung etc.) kannst du 802.1x fahren und damit unauthorisierte Geräte im Netz verhindern. Das ist natürlich nicht mal eben in 5 min eingerichtet.
 
Sehe an der Mac Filterung trotzdem kein Problem...ihr betankt doch die rechner auch irgendwie per pxe?
Und wenn ihr eine verdacht habt wer es ist und den Bereich eingrenzen könnt dürften es doch eh nur eine Handvoll mac Adressen sein oder nicht?

NAP/NAC/802.1x wäre eine Lösung aber ist eben nicht nur auf "dem Server" (ich verstehe eh nicht ganz, was hat der Server mit den druckern zu tun?)
 
Zuletzt bearbeitet:
In diesem Teil des Forums geht es um Windows Server 2008 R2 - was also bitte soll Deine Frage? Und da laut Deine Ansicht es keine MAC Adressen im AD gibt, schein Dein Durchblick nicht besonders umfangreich zu sein.
Wir haben natürlich auch lokale Gast-PC, die sich eine freie Gast-IP ziehen können. Aber die lokale Masse der PC muss aus diversen Gründen mit einer festen IP arbeiten. Genauso wie die Gast-PC daheim. Und dann versuche Dir mal ein schönes großes Netz mit mehr als 240 000 Client vorzustellen. Das können die wenigsten Leute.
 
Back Up and Restore the DHCP Database
DHCP servers store DHCP lease and reservation information in database files. By default, these files are stored in the %SystemRoot%\System32\DHCP directory.

Also nix mit MAC Adressen im AD.

Da du aber anscheinend eh nicht an einer Lösung interessiert bist, sondern nur mit Client Zahlen protzen willst war's das hier für mich.
Holt euch irgend nen Consultant wenn ihr zu doof seid das selber gebacken zu bekommen.
 
In diesem Teil des Forums geht es um Windows Server 2008 R2 - was also bitte soll Deine Frage?
weil mir nicht ersichtlich ist was die hochwertigen drucker nun mit dem/den Server/n zu tun haben
Und da laut Deine Ansicht es keine MAC Adressen im AD gibt, schein Dein Durchblick nicht besonders umfangreich zu sein.
weiss zwar nicht wo ich das gesagt hab aber ja im AD finden sich keine MAC Adressen der Rechner - ausser man schreibt sie auf welchem weg auch immer in ein freies Feld rein.
Wir haben natürlich auch lokale Gast-PC, die sich eine freie Gast-IP ziehen können. Aber die lokale Masse der PC muss aus diversen Gründen mit einer festen IP arbeiten.
wenn die per dhcp versorgt werden habt ihr ja diese macs...behelfen könntet ihr euch auch mit gäste lan/und private lan ports getrennt durch vlans...und was an den privaten ports lauffähig ist dürfte hoffentlich selbstredend sein - oder auch nicht.

Dein aggressiver Tonfall gefällt mir allerdings nicht wirklich und schließe mich deshalb ara1, besorg dir n Consultant der dein Problem löst (von dem abgesehen kann ich dir ja so oder so nicht helfen da mein Durchblick nicht besonders groß ist, hf)
 
Zuletzt bearbeitet:
Schade, Aber es hätte ja sein können, dass man zufällig hier jemanden mit einer perfekten Lösung findet. Mitunter kommt man ja leider nur auf den tollsten Umwegen an einen Wissenden mit der perfekten Lösung. Auf die Art und Weise haben wir auch schon mal Kontakt zu einem der extrem wenigen Freelancer (gibt es mehr als 5 weltweit ?) bekommen, der von der Optimierung des Caching unserer großen Datenbanken wirklich Ahnung hatte (was solche Leute kosten steht auf einem anderen Blatt). Ich danke Euch trotzdem für Eure Ideen und Anregungen. Aber das die MAC-Filterung auf Grund unserer Bedingungen nicht machbar ist, das hatte ich ja gleich ultimativ beim Start des Fadens konkret mitgeteilt. Unser Netz ist halt größer als in der Masse üblich und so ist bei uns natürlich auch einiges anders, als man das ansonsten aus kleineren Netzen so kennt. Aber das ist kein Vorwurf. Auch wir müssen fast täglich dazu lernen ... und erleben trotzdem täglich neue Überraschungen.
 
Weshalb ist die MAC-Filterung nicht möglich?
Es reicht doch, die MAC des Störers herauszufinden und dann zu sperren.
Mit Netzwerksniffern lässt sich auch feststellen, wann der gerade aktiv ist und an welchem Port er angestöpselt ist.
Dann könnt ihr den doch auf frischer Tat festsetzen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh