21
Internet für bestimmte PCs sperren.
Hallo zusammen,
ich weiss dass es diese Frage schon oft gegeben hat, habe aber leider nichts gefunden.
Zu meinem Prob:
Ein Netz aus ca.60 Rechnern in einem Subnetz.Ich habe die Aufgabe bekommen eine Abteilung (12 Rechner) für das Internet zu sperren.
Ist auch kein Prob mit dem Router, aber halt nur über IP.Bei DHCP nicht wirklich verlässlich.
Deshalb folgende Überlegung von mir:
Ich kann doch für die 12 Rechner im WS2003 dhcp je eine Reservierung vornehmen, die in einem Bereich liegen. Diesen Bereich kann ja auf dem Router dann gesperrt werden.
Meine Frage:
Hab ich da einen Denkfehler drin, bzw. gibt es eine andere Möglichkeit vielleicht mit weniger Aufwand?
Bevor ich damit Anfang wollte ich mir ein paar Meinungen einholen.
Was meint ihr dazu?
ich weiss dass es diese Frage schon oft gegeben hat, habe aber leider nichts gefunden.
Zu meinem Prob:
Ein Netz aus ca.60 Rechnern in einem Subnetz.Ich habe die Aufgabe bekommen eine Abteilung (12 Rechner) für das Internet zu sperren.
Ist auch kein Prob mit dem Router, aber halt nur über IP.Bei DHCP nicht wirklich verlässlich.
Deshalb folgende Überlegung von mir:
Ich kann doch für die 12 Rechner im WS2003 dhcp je eine Reservierung vornehmen, die in einem Bereich liegen. Diesen Bereich kann ja auf dem Router dann gesperrt werden.
Meine Frage:
Hab ich da einen Denkfehler drin, bzw. gibt es eine andere Möglichkeit vielleicht mit weniger Aufwand?
Bevor ich damit Anfang wollte ich mir ein paar Meinungen einholen.
Was meint ihr dazu?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 24474
Url: https://administrator.de/forum/internet-fuer-bestimmte-pcs-sperren-24474.html
Ausgedruckt am: 22.12.2024 um 22:12 Uhr
21 Kommentare
Neuester Kommentar
Unter Windows leider nicht.
Mit Linux hättest du mit iptables ein Filter auf MAC und IP Ebene kombinieren können.
Mit Linux hättest du mit iptables ein Filter auf MAC und IP Ebene kombinieren können.
... das einfachste, ich gehe bei 60 Rechner von einer Domäne aus, wäre es, die betreffenden Rechner in eine eigene OU zu schieben und über eine Policy einen falschen, nicht existierenden Proxy zuzuweisen. Gleichzeitig werden über die selbe Policy die Möglichkeiten der Änderung der Proxyeinstellungen genommen, das war's,
Gruß
Atti.
Gruß
Atti.
Meiner Meinung nach ist das auch die beste Lösung, alles andere bringt nochmehr Aufwand mit sich
Hallo Antos,
so einfach wie es sich anhört wird es nicht werden, es ist ein wenig mehr Pflegeaufwand notwendig. Es reicht nicht, einen separaten Pool für die Rechner anzulegen, es muß ja auch sichergestellt sein, daß die Rechner eine IP aus dem jeweils richtigen Pool bekommen (z.B. über die MAC-Adresse).
Und da wird's problematisch, denn die MACs müßtest Du händisch auf dem DHCP-Server pflegen - was den Vorteil der automatischen Adreßvergabe teilweise wieder aufhebt. Für jeden Wechsel der MAC-Adresse (Rechnertausch oder neuer NIC) müßtest Du den Eintrag auf dem Server anpassen.
Davon abgesehen sollte dieser Ansatz aber funktionieren. Beachten müßtest Du, daß Du dem Router entweder ACLs für die einzelnen IP-Adressen (dann mit /32'er Mask) oder eine ACL für ein Teilnetz des fraglichen Netzwerks geben mußt, wobei bei letzterer Methode 2 IP-Adressen (Base-Adresse und Broadcast des Teilnetzes) nicht verwendet werden dürfen.
Komfortabler wäre die Auftrennung des LANs in zwei VLANs mit jeweils unabhängigen IP-Netzen. Rechner mit Internet in ein VLAN, Rechner ohne Zugriff in's andere, die Konfiguration des Routers und des DHCP-Servers wäre dann sehr viel einfacher, da an der Quelle des DHCP-Requests schon die Zugehörigkeit ersichtlich wäre.
Voraussetzung hierfür ist aber, daß die beteiligten Switches VLANs unterstützen und daß der Router entweder über ein weiteres Interface oder über Trunking angebunden werden kann. Außerdem muß der Router das Forwarden von UDP/BOOTP/DHCP-Broadcasts unterstützen, damit die DHCP-Pakete auch zum DHCP-Server kommen, der dann ja für ein VLAN in einem anderen Subnet steht.
Ein komplett anderer Ansatz wäre die Verwendung eines Proxies, je nach Anforderungen und Vorhandensein von geeigneter Hardware.
Was meinst Du dazu? =)
Cheers,
-sai
so einfach wie es sich anhört wird es nicht werden, es ist ein wenig mehr Pflegeaufwand notwendig. Es reicht nicht, einen separaten Pool für die Rechner anzulegen, es muß ja auch sichergestellt sein, daß die Rechner eine IP aus dem jeweils richtigen Pool bekommen (z.B. über die MAC-Adresse).
Und da wird's problematisch, denn die MACs müßtest Du händisch auf dem DHCP-Server pflegen - was den Vorteil der automatischen Adreßvergabe teilweise wieder aufhebt. Für jeden Wechsel der MAC-Adresse (Rechnertausch oder neuer NIC) müßtest Du den Eintrag auf dem Server anpassen.
Davon abgesehen sollte dieser Ansatz aber funktionieren. Beachten müßtest Du, daß Du dem Router entweder ACLs für die einzelnen IP-Adressen (dann mit /32'er Mask) oder eine ACL für ein Teilnetz des fraglichen Netzwerks geben mußt, wobei bei letzterer Methode 2 IP-Adressen (Base-Adresse und Broadcast des Teilnetzes) nicht verwendet werden dürfen.
Komfortabler wäre die Auftrennung des LANs in zwei VLANs mit jeweils unabhängigen IP-Netzen. Rechner mit Internet in ein VLAN, Rechner ohne Zugriff in's andere, die Konfiguration des Routers und des DHCP-Servers wäre dann sehr viel einfacher, da an der Quelle des DHCP-Requests schon die Zugehörigkeit ersichtlich wäre.
Voraussetzung hierfür ist aber, daß die beteiligten Switches VLANs unterstützen und daß der Router entweder über ein weiteres Interface oder über Trunking angebunden werden kann. Außerdem muß der Router das Forwarden von UDP/BOOTP/DHCP-Broadcasts unterstützen, damit die DHCP-Pakete auch zum DHCP-Server kommen, der dann ja für ein VLAN in einem anderen Subnet steht.
Ein komplett anderer Ansatz wäre die Verwendung eines Proxies, je nach Anforderungen und Vorhandensein von geeigneter Hardware.
Was meinst Du dazu? =)
Cheers,
-sai
Und was soll das bringen?? Dann nehmen die halt Firefox oder ähnliches. Da hilft nur was auf IP Ebene. Oder gleich Squid anrollen lassen mit Autentifizierung.
Desweiteren könnte man mit Squid einen sogenannten transparenten proxy aufbauen. Da könnten die denn einstellen und nutzen was Sie wollen
Bei VLAN kannste ziemlich schnell ins Trudeln kommen, wenn dein Server keine Intel Netzwerkkarten hat. Da sich Windows bei Thema VLAN völlig auf den Treiber verläßt.
Bei VLAN kannste ziemlich schnell ins Trudeln kommen, wenn dein Server keine Intel Netzwerkkarten hat. Da sich Windows bei Thema VLAN völlig auf den Treiber verläßt.
... dürfen Deine User Firefox oder eine andere Software installieren? Unsere nicht ...
Gruß
Atti
Gruß
Atti
... oder man sperrt die IP's einfach in der (doch hoffentlich vorhandenen) Firewall,
Gruß
Atti
Gruß
Atti
Bei VLAN kannste ziemlich schnell ins
Trudeln kommen, wenn dein Server keine Intel
Netzwerkkarten hat. Da sich Windows bei
Thema VLAN völlig auf den Treiber
verläßt.
Trudeln kommen, wenn dein Server keine Intel
Netzwerkkarten hat. Da sich Windows bei
Thema VLAN völlig auf den Treiber
verläßt.
Sorry to say, aber das ist Unsinn. Es ging nicht darum, einen Rechner in mehrere VLANs zu setzen (d.h. Trunking zum Client) - da könnte es in der Tat Probleme geben, da der Treiber dann mit Tagged Frames umgehen können müßte.
Beim vorgeschlagenen Setup wäre jeder Rechner (inklusive des DHCP-Servers) in genau einem VLAN - und das ist völlig transparent. Wie sollte es also zu Problemen kommen?
Und wo willste denn die DHCP relay agenten unterbringen?
Und wo willste denn die DHCP relay agenten
unterbringen?
unterbringen?
Wie in meiner initialen Reply schon angedeutet - dahin, wohin er gehört: Auf den Router. Bei Cisco z.B. in der Config des entsprechenden Interfaces wie hier:
---8<--snip--8<---
interface Vlan3
description Internal Net
ip address 10.42.42.1 255.255.255.0
ip helper-address 10.42.43.12
no ip directed-broadcast
ip policy route-map toisdn
mls rp vtp-domain ailabs
mls rp management-interface
mls rp ip
---8<--snip--8<---
Die "ip-helper-address" ist die IP meines DHCP-Servers, der im Server-VLAN (10.42.43.x) steht.
Der Interfacename ist ein wenig seltsam, da es sich bei dem Router um ein RSM in einem Catalyst handelt, bei "normalen" Ciscos hieße das dann z.B. "Ethernet0", "FastEthernet0" oder ähnlich oder (bei Trunking) erweitert um die Bezeichnung des jeweiligen Sub-Interfaces.
Router anderer Hersteller haben vermutlich etwas equivalentes - DHCP-Forwarding ist mehr oder weniger Standard.
Falls der Router es nicht kann, auf einen separaten Rechner (was die Sache aber verteuern würde - deshalb sagte ich ja auch "Außerdem muß der Router das Forwarden von UDP/BOOTP/DHCP-Broadcasts unterstützen")
Cheers,
-sai
Falls er ein entsprechenden Router hat. Denn da wurde sich bisher ja ausgeschwiegen, wie das Netz im Detail aussieht
Wenn du ein Cisco Router hast
Ich hab sogar mehr als einen =) Sollte ja auch nur ein Beispiel sein.
Ernst beiseite, die vorgeschlagene Lösung ist natürlich nur sinnvoll, wenn der Router das übernehmen kann (was ich aber auch gesagt hatte ;). Ansonsten bräuchte man eine Kiste, die immer läuft und auf der der Relay Agent installiert werden kann. Was evtl. Geld kostet und das ist ja bekanntlich immer knapp ;)
Cheers,
-sai
Wenn das Equipment mitspielt halte ich die Lösung über VLANS für die Beste.
Bei der Ursprungsidee von Antos könnte der User u.U. noch Dummheiten machen (MAC Adresse ändern, feste IP einstellen). Aber das setzt dann Know How und Rechte voraus.
Bei der Ursprungsidee von Antos könnte der User u.U. noch Dummheiten machen (MAC Adresse ändern, feste IP einstellen). Aber das setzt dann Know How und Rechte voraus.
Das ging aber flott!
Danke für die Antworten!
Zum Netz:
60 Clients, 5 Server(PDC=WS2003), eine Domäne.
Zum Router:
Is ein älterer Sonicwall hastenichtgesehen.Leider nix mit relay agenten.Ich muss aber nochmal genau nachschauen.
Das Internet soll auch nicht immer gesperrt sein sondern Abends ab 18.00 Uhr bis Morgends 7.00 Uhr.
Auf dem Router kann ich einen Pool definieren (z.B. 192.168.1.x bis 192.168.1.y) und diesen dann für den Zeitraum sperren.Was den falschen Proxy angeht wäre es in meinem Fall mit Geplante Task zu o.ä. zu realisieren, was wieder mit Aufwand an den einzelnen Clients verbunden wäre.
Im Intranet wird der IE weiter verwendet.
Da es sich über eine überschaubare Anzahl von Rechner handelt denke ich das ich es über die Reservierungen machen werde.
Ich versuche insbesonderst den Hardware-Aufwand ingesammt möglichst klein zu halten, da evtl. ein neuer Router ins Haus steht.
Wenn ich auf dem DHCP-Server eine Reservierung vornehme:
rechnerxy = ip x.x.x.x
dann wird doch der Rechner per Namen identifiziert und dementsprechend die definierte IP zugewiesen!?!
Oder bin ich da falsch informiert?*grübel*
mfg
Antos
Danke für die Antworten!
Zum Netz:
60 Clients, 5 Server(PDC=WS2003), eine Domäne.
Zum Router:
Is ein älterer Sonicwall hastenichtgesehen.Leider nix mit relay agenten.Ich muss aber nochmal genau nachschauen.
Das Internet soll auch nicht immer gesperrt sein sondern Abends ab 18.00 Uhr bis Morgends 7.00 Uhr.
Auf dem Router kann ich einen Pool definieren (z.B. 192.168.1.x bis 192.168.1.y) und diesen dann für den Zeitraum sperren.Was den falschen Proxy angeht wäre es in meinem Fall mit Geplante Task zu o.ä. zu realisieren, was wieder mit Aufwand an den einzelnen Clients verbunden wäre.
Im Intranet wird der IE weiter verwendet.
Da es sich über eine überschaubare Anzahl von Rechner handelt denke ich das ich es über die Reservierungen machen werde.
Ich versuche insbesonderst den Hardware-Aufwand ingesammt möglichst klein zu halten, da evtl. ein neuer Router ins Haus steht.
Wenn ich auf dem DHCP-Server eine Reservierung vornehme:
rechnerxy = ip x.x.x.x
dann wird doch der Rechner per Namen identifiziert und dementsprechend die definierte IP zugewiesen!?!
Oder bin ich da falsch informiert?*grübel*
mfg
Antos
Hallo Antos,
ich hab' gerade mal in's Handbuch einer etwas älteren SonicWall (SonicOS 2.2) geschaut. Diese scheint einen DHCP-Helper zu kennen:
(Kapitel 4 - Network > IP Helper) (Seite 95 im "SonicOS Enhanced 2.2 Administrator's Guide" PDF)
---8<--snip--8<---
The IP Helper allows the SonicWALL to forward DHCP requests originating from the interface on a SonicWALL to a centralized DHCP server on behalf of the requesting client.
---8<--snip--8<---
Allerdings kann ich nichts zum Thema VLANs finden, wenn das Ding sie nicht unterstützt wäre ein freies Ethernet-Interface notwendig - wenn es denn noch ein freies hat.
Bei der Idee, die IP-Adressen per Hostname zuzuweisen gilt, daß der Hostname (wie in Grenzen auch die MAC-Adresse) vom Client geliefert wird. Wenn also die Clients 100% vertrauenswürdig sind (ergo die jeweiligen Angaben nicht vom Benutzer geändert werden können) sollte das so funktionieren. Wenn der User die zur Erkennung des Clients benutzte Information ändern kann, kann er auch den Schutz umgehen. Das aber nur als Hinweis, funktionieren sollte die Methode (kann man ja auch recht einfach mit einem Testrechner ausprobieren).
Vielleicht noch als weiterer Hinweis: Das alles kann man bei der Lösung ohne VLANs immer durch das Booten von z.B. Knoppix und dem Zuweisen einer statischen IP (Recycling einer berechtigten IP eines Kollegen) umgehen. Als Berufsparanoiker vertraue ich nie auf etwas, was ein Client mir erzählen möchte ;)
Cheers,
-sai
ich hab' gerade mal in's Handbuch einer etwas älteren SonicWall (SonicOS 2.2) geschaut. Diese scheint einen DHCP-Helper zu kennen:
(Kapitel 4 - Network > IP Helper) (Seite 95 im "SonicOS Enhanced 2.2 Administrator's Guide" PDF)
---8<--snip--8<---
The IP Helper allows the SonicWALL to forward DHCP requests originating from the interface on a SonicWALL to a centralized DHCP server on behalf of the requesting client.
---8<--snip--8<---
Allerdings kann ich nichts zum Thema VLANs finden, wenn das Ding sie nicht unterstützt wäre ein freies Ethernet-Interface notwendig - wenn es denn noch ein freies hat.
Bei der Idee, die IP-Adressen per Hostname zuzuweisen gilt, daß der Hostname (wie in Grenzen auch die MAC-Adresse) vom Client geliefert wird. Wenn also die Clients 100% vertrauenswürdig sind (ergo die jeweiligen Angaben nicht vom Benutzer geändert werden können) sollte das so funktionieren. Wenn der User die zur Erkennung des Clients benutzte Information ändern kann, kann er auch den Schutz umgehen. Das aber nur als Hinweis, funktionieren sollte die Methode (kann man ja auch recht einfach mit einem Testrechner ausprobieren).
Vielleicht noch als weiterer Hinweis: Das alles kann man bei der Lösung ohne VLANs immer durch das Booten von z.B. Knoppix und dem Zuweisen einer statischen IP (Recycling einer berechtigten IP eines Kollegen) umgehen. Als Berufsparanoiker vertraue ich nie auf etwas, was ein Client mir erzählen möchte ;)
Cheers,
-sai
Hallo sairath,
Danke für deine Antwort.
Die Sache mit Knoppix und co. gefällt mir an meiner Version auch nicht.Ich werde Morgen die Sonicwall mal genau unter die Lupe nehmen.Wär mir auch lieber.
mfg
Antos
Danke für deine Antwort.
Die Sache mit Knoppix und co. gefällt mir an meiner Version auch nicht.Ich werde Morgen die Sonicwall mal genau unter die Lupe nehmen.Wär mir auch lieber.
mfg
Antos
Nimm doch einfach nen Layer2 Switch, da kannst du festlegen welche Ports auf welche zugreifen können!
Dann sind auch deine Buchsen fest von wo aus Internet nicht möglich ist! VLAN fähig sind solche Switche auch, also relativ preiswert und sicher.
Grüße
Dann sind auch deine Buchsen fest von wo aus Internet nicht möglich ist! VLAN fähig sind solche Switche auch, also relativ preiswert und sicher.
Grüße
Und denn noch das ganze mit 802.1x dann kann denn auch keiner was umstecken oder so.
Wenn ich auf dem DHCP-Server eine
Reservierung vornehme:
rechnerxy = ip x.x.x.x
dann wird doch der Rechner per Namen
identifiziert und dementsprechend die
Reservierung vornehme:
rechnerxy = ip x.x.x.x
dann wird doch der Rechner per Namen
identifiziert und dementsprechend die
Nein, der Rechner wird anhand seiner MAC identifiziert. Die musst du bei der Reservierung auch angeben.
Hallo meinereiner ... äh, nee, eigentlich deinereiner ...
Nu mach' das arme DHCP doch nicht schlechter als es ist ... ein wenig mehr als tumbes MAC-Matchen kann es dann doch schon ;)
Cheers,
-sai
Nu mach' das arme DHCP doch nicht schlechter als es ist ... ein wenig mehr als tumbes MAC-Matchen kann es dann doch schon ;)
Cheers,
-sai
