Clients mit abgekündigten Betriebssystemen

[ITKobold 1]

Hallo zusammen,

 

ich bin nun seit ein paar Tagen an einer Lösung für die Abschottung alter Clients (XP, Win 7, 2000 etc.) die nur mit sehr hohem finanziellen Einsatz aktualisiert werden können.

Nur leider bin ich noch nicht auf eine zufriedenstellende Lösung gestoßen.

 

Die Clients würde ich auf jeden Fall in ein eigenes VLAN setzen und dieses über die Firewall (Sophos SG 230) abschotten. So weit so gut.

Die Clients brauchen jedoch Zugriff auf Fileserver die in unserer AD hängen. Somit würde ich AD Zugriff und Zugriff auf die Fileserver benötigen.

 

Wie habt ihr diese Problematik gelöst bzw. würdet ihr diese lösen? Ein RODC im VLAN oder direkt die Ports mit statischen RPC Ports ins interne Netz freigeben? Problem mit dem Fileserver besteht ja dann immernoch.

 

Danke schonmal für eure Ideen:)

[testperson 1.675]

Hi,

 

ein Würgaround könnte ein Transfer-Server in einem entsprechenden Transfer-Netz sein:

• Daten werden vom Fileserver bspw. per SCP auf den Transfer-Server geschoben -> Transfer-Server schiebt auf Clients bzw. Clients holen ab
• Clients schieben auf den Transfer-Server bzw. Transfer-Server holt ab -> Daten werden zum Fileserver geholt

Gruß

Jan

[mwiederkehr 373]

Ein Problem beim direkten Zugriff auf den Fileserver sehe ich darin, dass dann Altlasten wie SMBv1 erhalten bleiben müssen.

 

Ich würde deshalb wie Jan einen Transferserver vorschlagen. Dieser könnte die Daten über Nextcloud zur Verfügung stellen. Oder man nimmt einen Linux-Server, mountet ein Verzeichnis vom Fileserver und stellt dieses über Samba zur Verfügung.

 

Was je nach Software auch ginge: die alten Systeme auf neue Rechner virtualisieren, zum Beispiel mit VMware Workstation bzw. Player. Datenzugriff über Shared Folders vom Host bzw. Copy-Paste. So baut der Host die Verbindung ins Netz auf und die VM hat nur Zugriff auf den Host und das auch nur über VMware. Damit ist auch gleich das Problem alternder Hardware erledigt. Das so betriebene Windows 98 eines Kunden bootet von SSD so richtig schnell.

[ITKobold 1]

@testperson Die Idee mit dem Transferserver werde ich mir definitiv genauer anschauen, danke dafür

Könnte mir das so vorstellen: eigene Domäne bzgl. Laufwerken und Drucker, steuerbare Benutzer (GPOs), Transferserver im neuen Forest und dann wie du meintest per Skript und SCP die Daten vom internen Netzwerk pullen, diese dann per SMB bereitstellen. Und das ganze dann wieder zurücksyncen .

Ist alles wie du meinst wirklich ein Würgaround, aber besser als im gleichen Netz oder mit einer Firewall im schweizer Käsestil. 

@mwiederkehr Virtualisierung ist leider nicht möglich, da die Geräte proprietäre Hardware (GPU etc.) enthalten (Messmaschinen etc.)

[Weingeist 159]

Kann Dir nachfühlen, habe auch diversen solchen Kram. Ein Roboter eines sehr nahmhaften Herstellers ist z.Bsp. noch auf W95 obwohl das damals schon völlig veraltet war. Aber der braucht wenigstens kein ERP-Zugriff. Solange es bei Filezugriff bleibt, kriegt man das meist irgendwie hin. z.Bsp. auch per FTP oder NFS via separaten Netzwerkadapter und dann alles andere per FW abklemmen.

 

Beim Transferserver könnte man das ganze evtl. auch mit einer Linux-Kiste lösen. Linux kann ja alles mögliche direkt mounten als ob es lokal angeschlossen wäre, also vermutlich auch ein Netzwerkshare auf einem Widows-Server. Das wird dann gleich wieder per SMB1 in das abgeschottete Netz mit einem eigenen Netzwerkadapter wieder zu Verfügung stellt. Leider kenne ich mich mit Linux zu wenig aus, aber hätte auch ein paar Szenarien wo das hilfreich wäre. Die sonstigen "Transfer-Übungen" mit Files manuell rein- und rauskopieren sind eine Katastrophe.

[lefg 276]

Am 25.9.2020 um 09:23 schrieb ITKobold:

Wie habt ihr diese Problematik gelöst bzw. würdet ihr diese lösen?

 

Moin

 

Ich schau mir diesen Thread schon einige Zeit an, überlegte ob ich Multihoming erwähnen sollte, da dieses von der Gemeinde wohl mehrheitlich abgelehnt wird und ich dafür Haue bekomme. Jetzt riskiere ich es doch.

 

In früheren Zeit betrieb ich Multihoming, d.h., der/die Server/DC hatten ein zweites, drittes, viertes Netzwerkinterface oder ein Netzwerkinterface mit mehreren LAN-Ports, jeder LAN-Port die IP seines Netzes.

 

Heute betriebe ich auf einem Interface wohl mehr als ein VLAN, soviel wie benötigt, so das Interface und Treiber das hergeben. Auch dies ist ein Multihoming.

 

Den Transferserver kannte ich bisher nicht, halte das für eine überlegenswerte Möglichlichkeit.

 

 

bearbeitet 26. September 2020 von lefg

[NorbertFe 2.032]

vor 8 Stunden schrieb lefg:

In früheren Zeit betrieb ich Multihoming, d.h., der/die Server/DC hatten ein zweites, drittes, viertes Netzwerkinterface oder ein Netzwerkinterface mit mehreren LAN-Ports, jeder LAN-Port die IP seines Netzes.

Dafür gibts auch zurecht „Haue“, denn das ist im allgemeinen sicherheitstechnischer Unsinn. Der Sinn der Segmentierung ist dabei nicht gegeben. Auch wenn man sich „gut“ damit fühlt, ist das aus technischer Sicht wohl kaum so. ;)

[Weingeist 159]

Multihoming gibt früher oder später fast immer Ärger mit der Namensauflösung. Kan man zwar tatsächlich alles so konfigurieren, dass es korrekt funktioniert, habe das in mehreren Umgebungen vor Jahren auch über sehr lange Zeit gemacht, weil eben Budget für viele physische Server, Router, zusätzliche USV-Leistung etc. nicht vorhanden waren und es Virtualisierung noch nicht gab. Lief also alles über einen SBS. Hat auch super funktioniert solange alles korrekt konfiguriert ist. Aber die Fehlersuche ist der totale Graus weil es bei Fehlkonfigurationen manchmal tut und manchmal nicht. Sprich Du gehst nach Hause und alles tut, am nächsten morgen steht die ganze Umgebung und solche Spässe. Nachzuvollziehen warum es nicht tut ist definitiv kein Spass. Insbesondere aufgrund der verschiedenen Namensauflösungs-Möglichkeiten wie Hosts, DNS, Wins und gecachten Namen. Früher war es meist auch nicht gleichermassen schlimm wenn mal nen Tag die IT stillstand, heute wo man in sehr vielen Betrieben hauptsächlich mit der IT arbeitet, sollte der Fokus eher in Richtung möglichst unkompliziertem, standardisierten Aufbau und schnelle Fehlerbehebung gelegt werden. Auch die Stundenansätze der IT-ler sind viel höher und etwas mehr 0815 Hardware hat keine wesentlich Einfluss mehr auf die Gesamtkosten.

 

@Norbert: Naja eine Trennung bekommst ja eigentlich schon hin mit Multihoming und mehreren Netzwerkadaptern. Wenn der DC korrumpiert ist, ist eh ende Gelände. Insofern müsste die Trennung ausreichen. Dumm nur, dass am Maschinennetz öfter auch Externe arbeiten und so etwas ins Hauptnetz einschleppen können. Eigentlich müsste man physikalisch abtrennen. Sprich komplett eigene Struktur für den Maschinenpark. Funktionierte früher, heute nicht mehr wirklich.

 

Daher: Wenn es wichtig ist, würde mir einen Linux-Spezi schnappen und einen Transfer-Server/Router erstellen welche die Welten möglichst gut trennt und jeden einzelnen Schritt sauber dokumentieren lassen. Oder eine Low-Budget Variante wählen, z.Bsp. mit einer NAS die in beiden Netzen hängt und zwei ansonsten getrennte Netze pflegen. Die NAS kannst dann auf die Hauptserver sichern, aber Daten welche beide Seiten brauchen, liegen auf der NAS.

[ITKobold 1]

Danke an alle für die Antworten.

Ich werde mich mal an einen Transferserver machen.

Ich werde mir mal beide Möglichkeiten antesten (Linux, eigene Domäne). Bei Linux sehe ich kein Problem, das sollte ich selbst hinbekommen, das einzige Problem sehe ich im manuellen Einrichten der Benutzer und Laufwerksmappings, deshalb kam bei mir ja die Überlegung mit der parallelen Domäne in den Kopf, dann müsste ich nur einmal Benutzer anlegen und die Geräte in die Domäne nehmen.

[ITKobold 1]

Zu Info wie ich es nun gelöst habe:

- Komplett abgetrenntes VLAN

- eigene Domäne

- nur port 22 in das Netz mit den Fileservern

- dort Windowsintegrierten SSH Server aktiviert

- auf dem Fileserver in der abgetrennten Domäne die Software RAI Drive installiert und die Laufwerke somit lokal verbunden und freigegeben.