Re: [lmn] [langsam OT] Re: Subnetting - Netzbrief - Umsetzung

[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