OT:Fragen zu einer Existenzgründung...

[Alexander (HH)]

Moin Moin!

Hallo,

Laufwerke? DVD-ROM oder Brenner? Cardreader? Offene USB-Anschlüsse?

ja, irgendwas davon unbedingt.

Sehe ich auch so, aus Kundensicht. Aus Administrator-Sicht natürlich nicht, denn man kann mit lokalen Laufwerken und erst recht mit USB-Anschlüssen reichlich Unfug treiben, bis hin zu Schäden an der Hardware.

Wie verhinderst Du, dass von einem lokalen Medium gebootet und damit Dein Netz angegriffen wird? [...]

Gehen wir mal davon aus, dass man die BIOS-Einstellungen hinreichend gegen unbefugte Manipulation absichern kann, und dass außer LAN kein anderes Bootmedium benutzt wird. Wie man das realisiert, steht noch auf einem anderen Blatt.

Wenn Du (bzw. Gary) das schafft, sind offene Laufwerke nicht mehr das große Problem.

keine offen liegenden Laufwerke oder USB-Anschlüsse

Wenn ich mich in die Rolle eines Kunden versetze, der im Internet-Café surfen will, und ich hätte keine Möglichkeit, die heruntergeladenen Daten auf ein mitgebrachtes Speichermedium

Zwischenfrage: 3,5er USB-Festplatte mit eigenem Netzteil? OK, hat man eher selten in der Hosentasche, aber gelegentlich doch dabei. Die Frage ist also: Hat man am Tisch eine freie Netzsteckdose für genau diesen Fall? Oder meldet man sich dann besser am Tresen, wo der freundliche Mitarbeiter die Platte in einen etwas privilegierteren Rechner stöpselt und dem Kunden via LAN zur Verfügung stellt? Oder läßt man den Kunden in dem Fall dumm stehen und verweist auf nicht spezifikationskonforme 2,5er-USB-Platten ohne eigenes Netzteil und USB-Sticks?

(in aller Regel wohl ein USB-Datenträger) zu speichern, würde ich sagen: "Ihr spinnt ja wohl!" [...]

Exakt. Das ist das Problem mit den Kunden. Ohne die wäre das Admin-Leben viel einfacher ... ;-)

DVD-ROM bzw. DVD-Brenner sind, nachdem das Boot-Problem gelöst ist, relativ harmlos. Ggf. nörgelt die GEMA oder sonst irgendein "geistiges Eigentum" schreiender Verein nochmal herum, bis sie mit genügend Kohle ruhig gestellt sind.

USB direkt vom Mainboard lädt ein, Unsinn zu treiben. Kurzschließen wäre meine erste Idee, wenn ich in die Rolle des Bösewichts schlüpfe. Nicht jedes Mainboard hat Sicherungen vor dem USB-Anschluß, und nicht jede Sicherung ist selbstheilend. Da könnte ein einfacher, billiger USB-Hub mit eigenem Netzteil Abhilfe schaffen, der sich stellvertretend für das Mainboard opfert. Damit wäre mein zweiter Angriff, nämlich Überspannung, auch gleich ausgehebelt.

(Beides hilft allerdings nicht gegen Angriffe gegen den USB-Stack.)

Wie schützt Du die Kunden voreinander? Wie verhinderst Du, dass Surfer A via LAN ungefragt auf den Rechner von Surfer B zugreift und dort eine CD oder das Bankkonto abgreift?

Angenommen, die eingangs formulierte Prämisse gilt noch:

Ja, nehmen wir mal an. Außerdem müssen wir annehmen, dass niemand mit einem eigenen Rechner in das LAN kann, z.B. via WLAN.

Durch entsprechend restriktive Einstellungen des Betriebssystems auf den Surfstationen und auf dem Server.

Windows auf den Surfstationen schließe ich mal aus. Windows nimmt viel zu oft an, dass andere Windows-Rechner im selben Netz freundlich sind, und ein brauchbares Windows per PXE zu starten halte ich für recht schwierig. Ebenso, ein Windows komplett abzuschotten. Und das Windows-Image müßte sehr oft aktualisiert werden.

Gehe ich also von einem Linux/*BSD aus, das per PXE gebootet wird, sich per NFS große Teile des Dateisystems read-only mountet, und den Rest des Dateisystems in RAM-Disks unterbringt.

Angriffsvektor: Zugriff auf den X-Server. Geht nur, wenn der falsch konfiguriert ist (TCP/IP-Socket auf LAN-Adresse statt Unix-Socket).

Angriffsvektor: Zugriff via Telnet / SSH / VNC / FTP / Samba / NFS & Co. Geht wieder nur bei falscher Konfiguration. Diese Dienste haben auf den Surfstationen schlicht nicht zu laufen. SSH vielleicht, und dann nur mit Public-Key-Verfahren, damit das Personal und ggf. Server-Software auf die Surfstationen zugreifen kann.

(Windows kann SSH nicht native, kann per CLI längst nicht alle Funktionen steuern.)

Angriffsvektor: Gemeinsam genutzte Verzeichnisse auf dem Server. Alle Surfer haben die selbe Benutzer-ID. Auch wieder falsch konfiguriert. $HOME muß lokal in einer RAMDisk liegen, ebenso /tmp, /var usw. Zufällige Benutzer-IDs (Benutzer wird beim Booten neu angelegt) würden diesen Angriff noch schwieriger machen.

Angriffsvektor: Backdoor-Software, eingespeist über einen USB-Stick als statisch gelinktes Programm. Wieder ein Konfigurationsfehler. mount -o noexec für alle RAMDisks und alle externen Medien (CD/DVD, externe Massenspeicher), Schreibrechte für den Surfer nur dort, wo noexec aktiv ist, und schon mal gar nicht auf dem Server. Außerdem sollte nach unserer Theorie der Rechner für jeden Surfer rebootet werden, um Schadsoftware los zu werden. Hier hat also die Reboot-Automatik bzw. das Personal, dass den Reboot manuell auslösen soll, versagt. (Ein herausgeführter, vom Kunden zu drückender Reset-Taster wäre nicht schlecht ...)

(Windows kennt kein noexec. Alles, was *.EXE, *.COM, *.BAT, *.CMD (...) heißt, wird gnadenlos ausgeführt, egal von welchem Medium.)

Rechner unter Kundenkontrolle, insbesondere über WLAN, haben wir bislang ausgeschlossen. Kunden werden aber sicherlich WLAN nachfragen.

Die Kunden vor ihrer eigenen, unsicheren WLAN-Konfiguration zu schützen, kann eigentlich nicht Aufgabe des WLAN-Betreibers sein. Deswegen ignoriere ich das Problem einfach mal.

Mein Problem ist hier der Rechner unter Kundenkontrolle, der plötzlich im Netz erscheint, z.B. via WLAN.

Einfachste Lösung: Er erscheint nicht im LAN. Surfer-LAN und WLAN sind zwei völlig getrennte Netze, die beide über die Firewall ins Internet dürfen, aber nicht untereinander kommunizieren können. Triviale Aufgabe für eine Firewall.

Wenn sich die WLAN-Nutzer gegenseitig angreifen, ist das per Definition nicht unser Problem.

Fällt jemandem ein vernünftiger Grund ein, warum eine Surfstation und ein WLAN-Laptop miteinander kommunizieren sollten?

Dann müßte man darüber nachdenken, LAN und WLAN doch zusammenzulegen.

Der Kundenrechner darf auf gar keinen Fall den Server beschädigen können, daher muß der so dicht wie möglich sein. Eine Firewall vor dem Server würde gegen versehentlich offene Ports auf dem Server schützen, das kann auch die selbe Firewall sein, die den Internet-Zugang macht.

Die Surfstationen müssen dann natürlich auch so dicht wie möglich sein, allein SSH für die Abrechnung / Fernwartung darf im Public-Key-Modus als von außen erreichbarer Service laufen. (Bei getrenntem Betrieb von LAN/WLAN schadet es natürlich auch nicht, die Surfstationen abzudichten.)

Noch eine Idee: Leute schleppen eigene Rechner an und wollen die per Ethernet nutzen. Auch da wäre der einfache Weg wieder ein eigenes Netz, entweder zusammen mit den Leuten, die das WLAN nutzen, oder auch von denen isoliert.

Dann wären da noch der Kassen- und Admin-Computer. Die müssen natürlich von allen Kunden getrennt sein und können den Server und über diesen auch die Surfstationen steuern.

Vom Kassen-Rechner kann man NICHT surfen, der Internet-Zugang wird an der Firewall blockiert. (Nicht, dass ich dem Personal nicht das Surfen gönne, das ist einfach eine Hygienemaßnahme für das priviligierte Personal-Netz. Wer surfen will, soll eine Surfstation benutzen.) Die Kasse ist bitte nicht mit dem Server identisch.

Die Admin-Station dagegen kann ins Internet, irgendwo her müssen die Updates ja kommen. Die Admin-Station ist auch der einzige Rechner, der die Firewall konfigurieren kann. Deswegen muß die Admin-Station besonders gesichert sein.

So sieht das Netzwerk im Maximalausbau aus:

Switch 1         Firewall
[ Surfstation 1 ]<--->|                   #
...                   |<----------------->#
[ Surfstation N ]<--->|                   #
                                          #
  Switch 3              Switch 2          #
    |<--->[ Server 1 ]<--->|              #
    |                      |<------------>#
    |<--->[ Server 2 ]<--->|              #
    |                                     #<----> Internet Weg 1
    |<--->[ Admin-Station ]<------------->#
                                          #<----> Internet Weg 2
                            [ Kasse ]<--->#
                                          #
                  Luft                    #
[ WLAN-PC 1 ]<--->()                      #
...               ()<--->[ WLAN-AP ]<---->#
[ WLAN-PC N ]<--->()                      #
                                          #
                Switch 4                  #
[ Kunden-PC 1 ]<--->|                     #
...                 |<------------------->#
[ Kunden-PC N ]<--->|                     #

Switch 1 bildet das "Internet-Cafe"-Netz.

Switch 2 kann ggf. statt eines Switches auch ein Loadbalancer sein (bei nur einem Server schlicht ein Kabel) und bildet das "öffentliche" Server-Netz, über das PXE (TFTP) und NFS im Internet Cafe bereitgestellt werden. HTTP-Proxy und HTTP-Server wären auch möglich, erreichbar auch vom WLAN-AP und vom Kundennetz, der HTTP-Server vielleicht auch aus dem Internet.

Switch 3 ist das "private" Netz, mit dem man den/die Server steuern und administrieren kann. Ggf. läuft über diesen Switch auch ein Heartbeat für die Server. In diesem Netz gibt es nicht unbedingt DNS- und DHCP-Server, /etc/hosts und feste IP-Adressen reichen hier aus.

Switch 4 ist sind öffentlich nutzbare Ethernet-Anschlüsse im Internet-Cafe.

Zwischen Admin-Station und der Firewall gibt es noch ein kleines, eigenes "Netz" aus einem Kabel, dass der Admin-Station ziemlich uneingeschränkten Internet-Zugang gewährt und die Administration der Firewall erlaubt. Noch besser ist eine serielle Konsole für die Administration der Firewall.

Noch so ein "ein-Kabel-LAN" gibt es zwischen Kasse und Firewall. Die Firewall läßt die Kasse zu den priviligieren Ports der Server durch, aber nicht ins Internet.

Man kann recht schmerzfrei auf das private Servernetz verzichten, Switch 3 entfällt. Dann sind die administrativen Zugänge der Server aber zwangsläufig von der Firewall-Seite aus erreichbar. Die Firewall sollte diese Zugänge explizit sperren, die Admin-Station hängt dann nicht mehr direkt an der Firewall, sondern am Switch 2. Mit festen IP-Adressen in diesem Netz kann man in der Firewall einen Internet-Zugang für die IP-Adresse der Admin-Station freischalten. Die Kasse bleibt aber weiter außen vor, damit niemand von der Kasse aus die Server töten kann.

Notfalls können Server und Admin-Station auch zusammenfallen, man arbeitet dann eben direkt auf der Konsole des Servers.

WLAN-AP, Switch 4, zweiter Internet-Zugang können je nach Bedarf wegfallen.

Eigentlich müßte noch was zu Schulungen gesagt werden, aber mein Posting ist jetzt schon reichlich lang.

Alexander