Hallo Hans-Dietrich, bei PDC und BDC denke ich noch in NT4-Domänen - was wohl für Samba 3.x auch angemessen ist. Was AD und Samba 4.x mehr können, weiß ich nicht.
Mit Windows NT könnte man Deine Idee vielleicht so umsetzen: Die Lehrerrechner sind Mitglieder der Domäne LEHRER. Sensible Daten befinden sich nur auf Servern der in Domäne LEHRER. Die Ressouren sollten versteckt sein. Die Domäne SCHULE vertraut der Domäne LEHRER, so dass die Lehrer auch auf Ressourcen der Domäne SCHULE zugreifen können, ohne dass eine doppelte Kontenführung erforderlich wird. Umgekehrt gibt es keine Vertrauensstellung, so dass man aus SCHULE nicht auf die versteckten Ressourcen in LEHRER zugreifen kann, d. H. sich von dort aus sich nicht einmal an der Domäne LEHRER anmelden kann. Hier einige Ansatzpunkte zu Vertrauensstellungen in Samba: https://books.google.de/books?id=JerK9MI3zJYC&pg=PA256&lpg=PA256&dq=samba+vertrauensstellung+zwischen+dom%C3%A4nen&source=bl&ots=SmTEjuFw5V&sig=57biT9oLxxH1UiFpdqqYhx-WjpE&hl=de&sa=X&ei=ot0LVfj_MIfjUeuEgvgI&redir_esc=y http://www.administrator.de/frage/vertrauensstellung-zwischen-linux-windows-dom%C3%A4nen-31570.html Um es nicht unnötig kompliziert zu machen (wenn es überhaupt ginge), würde ich zwei physikalische Server nehmen, allenfalls 2 virtualisierte, nicht jedoch versuchen zwei Instanzen von Samba auf einem Server zu implementieren. Gruß Jürgen P.S.: Den Ansatz die Netztrennung in der Anwendungsschicht zu sichern anstelle in TCP/IP finde ich alles andere als OT ;-) Am 20.03.2015 um 07:35 schrieb Hans-Dietrich Kirmse: > Hallo Tobias, > > die Argumentation in deiner Mail finde ich sehr überzeugend. Wenn man > den Gedanken weiterspinnt, kommt man doch zu folgender Lösung: > > Problem ist doch, dass sich der Computer nicht dafür authentifizieren > muss, "im richtigen Netz" zu sein. Aber wenn man statt "richtigen > Netz" eben in der "richtigen Domäne" verwendet, dann sollte ein > Angriff über das Fälschen von MAC und IP ins Leere gehen. > > Will damit sagen: es müßten 2 Domänen konfiguriert werden. Die Rechner > des Lehrernetzes kommen in die eine Domäne und die Rechner des > pädagischen Netzes in die andere Domäne. Durch das Aufnehmen des > Rechners in die Domäne durch den Administrator wird doch damit sicher > gestellt, dass die Rechner im richtigen Netz sind - sonst geht die > Anmeldung schief. > > Die Belastung der Lehrer nimmt nicht wirklich zu, weil doch bei den > Rechnern die Domäne "voreingestellt" ist. > > Ob man mit einem Samba 2 Domänen konfigurieren kann, weiss ich nicht > genau, ich denke aber ja. Aber zweifellos geht es mit 2 Instanzen von > Samba. Da ist es kein Problem die entsprechenden Shares zuzuordnen und > auch verschiedene Anmeldescripte zu verwenden. > > Alternativ kann man auch 2 Rechner (als PDCs) verwenden, muss aber > dann die Shares beiden Rechnern zur Verfügung stellen, d.h. zumindest > für mich, dass die auf ein NAS ausgelagert sein müssen. > > zusammengefasst: die Rechner müssen sich (ebenso wie die User) > authentifizieren. Aber genau dafür gibt es doch die Domäne(n). Also > startet man Samba zweimal und konfiguriert einen für das Lehrernetz > und einen für das pädagogische Netz. > > m.E. braucht es dann keine VLANs, keine managebaren Switche ... > > Dumm ist, dass der Netzbrief von uneterschiedlichen Netzen schreibt. > Hier würde aber der Zugriff aber durch die Software geregelt, die den > Zugriff auf die Dateien verwaltet (also Samba). D.h. erst nach dem > Netz. Das Netz wäre völlig irrelevant. > > Bemerkungen zur Umsetzung: so wie ich das sehe braucht man nur den > Samba entsprechend zu konfigurieren (sollte einfach sein) und zweimal > zu starten (das wäre ein Problem, denn man braucht ein weiteres > Startscript - das kann ich aber nicht). Es reicht der eine LDAP. Um > die 2. Domäne im LDAP anzulegen, dazu braucht man nichtmal einen > Befehl für den LDAP, das geht mit Befehlen für Samba. > > Viele Grüße > Hans-Dietrich > > > Am 20.03.2015 um 05:42 schrieb "T. Küchel": >> >> Hallo Holger, >> >> ich hab noch mal nachgelesen und, wenn du nichts dagegen hast, poste ich >> hier mein (Un?)verständnis: >> >> Ich beziehe mich mal auf die Doku von Thomas, >> http://www.linuxmuster.net/wiki/dokumentation:addons:subnetting:l3switch >> >> Am 19.03.2015 um 19:14 schrieb Holger Baumhof: >>> Also: ist das Netz richtig konfiguriert ist es nicht möglich, sich aus >>> irgend einem anderen subnet als dem Lehrernetz dem server gegenüber als >>> dem lehrernetz zugehörig aus zu geben. >> >> Das verstehe ich jetzt so: >> Hängt sich jemand an Thomas's L2-Switch 1 (Tags: 12,13,100,200) und gibt >> sich eine IP und MAC aus dem Lehrernetz, dann kann der L2-Switch ihn >> nicht taggen. Der Rechner muss aber über das Lehrernetz-Gateway >> 10.30.10.254 zum server, sonst kommt er gar nicht weiter. Das Gateway >> befindet sich aber im VLAN-50 getaggten Verkehr. >> >> Ich kann mir vorstellen, dass es von der Konfiguration der L2-Switche >> und des L3-Switches abhängt, was mit den nicht-getaggten Paketen des >> gefakten LZ-PCs passiert. Die Bilder suggerieren, dass man VLAN-50 >> Pakete von GE4 "ausschliessen" oder "verbieten" kann. Worin der >> Unterschied besteht, ... moment ... >> ja, so isses in etwa: >> >> http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/sf30x_sg30x/administration_guide/78-19308-01.pdf >> >> S.228 >> " >> * Forbidden >> — The interface is not allowed to join the VLAN even from GVRP >> registration. [snip] >> * Excluded >> — The interface is currently not a member of the VLAN. This is the >> default for all the ports and LAGs. The port can join the VLAN through >> GVRP registration. >> " >> >> Ich lese weiter (S224) und vermute, dass man PVID noch setzen sollte und >> das nicht das Lehrer-netz-VLAN sein sollte. >> Möglicherweise noch "Ingress Filtering" einschalten. (S227) >> >> Ich behaupte also: mit einer gefakten MAC und IP bekomme ich am falschen >> Port bei richtiger Konfiguration entweder die falsche oder keine VLAN-ID >> im weiteren Verkehr und entsprechend der Konfiguration am L2/L3 Switch >> komme ich nicht weiter.. >> >> Was ist also, wenn der Spitzbube (Spitzmädel?) an der VLAN-tagging >> barriere vorbeikommt? (entweder Fehlkonfig: er bekommt am falschen Port >> trotzdem die richtige VLAN-ID 50, oder ich hab noch was falsch >> verstanden) >> Dann kommt er tatsächlich mit einer IP aus dem Lehrernetz beim Server an >> und der kann nicht feststellen, ob der Client an einem erlaubten Port >> hängt. Soweit so gut. >> Wenn aber die Fehlkonfig dran schuld ist, dann seh' ich für den >> L3-Router auch keinen Grund, warum er den Spitzbuben nicht zum NAS >> durchlassen sollte, ist ja im richtigen VLAN angekommen. ACL erlauben >> ihm das. >> Oder ich versteh etwas falsch: was? >> >> Nochmal anders herum: Eure Argumentation ist: Richtige IP+MAC, falsches >> VLAN - und bis zum Server kommt Verkehr zustande, >> zum LZ-NAS dagegen lässt der L3-Router aufgrund der VLAN-zugeordneten >> ACL keinen Verkehr zu. >> Dann ist der Knackpunkt doch im L3-Router: kann ich mich mit der >> richtigen IP+MAC (10.30.10.x) in einem falschen VLAN (100) >> (weiter)bewegen? Ich vermute stark: nein, denn ich sehe das falsche >> Gateway (10.20.100.254). Selbst wenn ich irgendwie durch Tricks als >> Client 10.30.10.x/12 eintrage um das gateway 10.20.100.254 in meinem >> netzbereich zu haben. STellt sich die Frage, ob solche Pakete im >> 10.30.10.x/24 Netz des Routers akzeptiert werden. >> Aha. Noch eine Erkenntnis! Und selbst wenn ich bis zum Server >> durchkomme: der bekommt durch das falsche VLAN die Anfrage auf einem >> falschen eth-Port (!) und kann sehr wohl erkennen, dass hier was im >> Argen liegt. Sprich: Samba sollte für das share-LZ-only nur auf dem >> Interface des richtigen VLAN (50) lauschen/empfänglich sein. >> ok. nach weiterer recherche: das geht wohl nur, wenn für das >> share-LZ-only ein extra samba mit der option "interfaces eth0.50 " >> gestartet wird (und beim regulären samba dort nicht lauscht). Dann haben >> wir, was ihr empfehlt: ein NAS im Lehrernetz, nur dass das NAS ein extra >> samba-Prozess auf dem server ist. Ist billiger als ein NAS :) Die >> Erkenntnis hat mich nur eine Nacht gekostet :) >> >> >>> Beispiel: >>> lehrerrechner 1 hat die MAC xx und die IP yy und ist in Subnet LZ >>> Schüler mit Notebook ist in Subnet R155 (physikalisch, soll heißen: ihm >>> stehen nur Dosen im R155 zur Verfügung keine im LZ), dann könnte er die >>> MAC Adresse von lehrerrechner 1 fälschen und sich auch gleich die IP >>> geben: trotzdem käme er nicht an das NAS, welches im Subnet LZ steht, >>> weil weder L3 Switch noch Server ihn dort hin routen würden. >>> >>> Fälscht er nur die MAC, dann bekommt er in R155 eine IP vom DHCP aus >>> dem >>> für R155 vergebenen Lease: welches zumindest bei mir, garnichts darf: >>> kein Serverzugriff und kein Internetzugriff. >> >> ist für mich verständlich: Er bekommt das VLAN-Tag von R155 und kommt >> beim Server über die Route der R155-254 IP des L3-Switch beim server an, >> d.h. der server kennt zwar seine MAC aus der "workstations", es >> entscheidet aber die Konfiguration des DHCP-Servers, welche IP er >> bekommt - und ich vermute, der DHCP gibt ihm nur eine aus dem R155-Netz, >> weil er über diese Route kam. >> >>> >>> Das habe ich so schon überprüft, da es auch ein deutlciher Nachteil >>> ist. >>> Beispiel: ich habe in der Schule 40 Laptops: die sind naturgemäß >>> transportabel und genau für diesen Zweck angeschafft. >>> "Verortet" habe ich sie im Subnet NWT. Wenn ich so ein Laptop an einen >>> Port hänge, der in einem anderen subnet ist, so kennt der Server zwar >>> eigentlich die MAC Adresse und kennt eigentlich auch eine IP, die er >>> ihm >>> geben müßte: er macht es aber nicht, weil er in einem fremden Subnet >>> ist. >> >> obiges heißt für dich: wenn du GVRP an den entsprechend beteiligten >> Switches einschaltest, bekommt dein NWT-Laptop ein NWT-VLAN-ID-Tag, >> selbst wenn er am falschen Port hängt. DAs hatte ja schon mal jemand >> gepostet, dass das ("dynamic VLAN-tagging") geht. >> Stellt sich noch die Frage, warum man überhaupt verschiedene subnetze >> für Client-PCs braucht: Warum nicht *ein* "spielzimmernetz", in dem alle >> computerräume + nwt + medienstationen verortet sind und ein >> "lehrerimmernetz". >> Ich weiß - broadcasting vermeiden. Aber das ist halt die Abwägung wert. >> Warum nicht alle fest-installierten Computer-ports in so viele >> VLAN-Räume packen, wie man will. Alle anderen Ports in das >> "Spielzimmer". >> >>> >>> Bisher erscheint mir die Trennung Wasserdicht. >> >> Fazit für mich: >> 1. cool, wie das funktioniert. >> 2. cool, am ende braucht der server nur noch eine Netzwerkkarte (!) >> 3. Ich habe kapiert, dass der server u.U. die Herkunft der Anfrage nicht >> nachvollziehen kann. Ich behaupte aber, dass das NAS das dann auch nicht >> kann, d.h. ich sehe immer noch keinen sicherheits-vorteil eines NAS im >> Lehrernetz :) >> 4. oder der server kann die Herkunft doch nachvollziehen und >> dementsprechend samba konfiguriert werden. >> 5. ich stelle bei Durchsicht von Thomas' Beschreibung fest: jeder >> Server, der im "Serverraum" (VLAN 11) steht ist für Schüler-PCs >> zugänglich, nicht nur der Server selbst, d.h. ein Backup-NAS ist >> sinnvoller ins Lehrer-netz zu stellen (oder ein eigenes VLAN+subnetz >> aufmachen) (gilt bisher ja auch). >> >> >> puha, wiedermal was gelernt. >> >> Grüße, Tobias >> _______________________________________________ >> linuxmuster-user mailing list >> linuxmuster-user@lists.linuxmuster.net >> https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user >> > _______________________________________________ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > _______________________________________________ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
