Netzwerke möglichst transparent verbinden über eine Firewall

[Weingeist 159]

Salut zusammen,

 

Netzwerk-Segmentation bin ich nicht wirklich der Hirsch. Bis jetzt konnte ich mich immer mit physisch vollständig, virtuell mit VLANS und sonst mit Netmasken durchschlängeln. ;)

 

Nun brauche ich eine Kommunikation zwischen zwei Netzen zwischen Rechner aus Bereich A (Maschinen, allenfalls CAD) zu bestimmten Rechnern aus Bereich B (Rest) die ich mit keinen Work-Arounds bewerkstelligen konnte die ich sonst so einsetze. Ein paar Endgeräte aus Bereich A sind SEHR fragwürdig oder werden es demnächst (XP, 7, 8.1 oder 10 ohne Updates), der Ersatz nicht ohne Einwurf zu grosse Noten möglich oder nicht möglich. Nun sollen nur bestimmte Clients/Server überhaupt miteinander sprechen können und das wiederum nur über definierte Protokolle/Ports (Überwachungstools, allenfalls Files, ERP-Anbindung).

 

• Kommunikation möglichst transparent zwischen zwei Netzbereichen im gleichen oder unterschiedlichen IP-Range
• die Kommunikation soll über eine Firewall, ich möchte also steuern über welche Ports und Protokolle von wo nach wo etwas gehen darf
• Ticket holen aus Bereich A für die sicheren Clients am DC in Bereich B soll aber gehen. Auch der WSUS soll erreicht werden können im Bereich B.
• Lösung auf Windows Basis ist tendenziell bevorzugt, Konfiguration möglichst einfach
• Alle Maschinen die von B nach A in Frage kommen - Ausser der DC (multihome) und vermutlich auch der Filer? - dürften eine zweiten Lan-Port haben für die zusätzliche physische Trennung. Aber ob das "hilft" für DNS?

 

 

Was ist die sinnvollste Lösung für sowas? Eine Bridge ist ja eher schwierig zum effektiven filtern, aber gilt das auch für eine Bridge unter Windows? Läuft das alles über die Firewall-Rules oder nur Routen?

 

Bevor ich jetzt gross stundenlang austeste kann mir ja vielleicht jemand nen Tipp geben ;)

 

Der ISA/TMG hätte sowas easy peasy gemacht... Aber der ist EOL und möglicherweise auch etwas overkill.

 

Vielen Dank!

[mwiederkehr 382]

Ob die Windows-Firewall im Bridge-Modus funktioniert, weiss ich nicht. Denke aber eher nicht. WatchGuard und Zyxel habe ich schon im Bridge-Mode eingesetzt, wenn auch selten. OPNsense soll es auch können und das läuft bestens auf Hyper-V. Falls das nahe genug an "unter Windows" ist.

[daabm 1.366]

Als "Bastellösung" ginge es auch mit Routing und RAS auf einem Windows-Server - aber das ist dann wirklich Gebastel...

 

[cj_berlin 1.329]

vor 23 Stunden schrieb Weingeist:

 

Der ISA/TMG hätte sowas easy peasy gemacht... Aber der ist EOL und möglicherweise auch etwas overkill.

...aber nur mit dem Client/Agent, der auf jede Maschine drauf müsste, zumindest innerhalb eines IP-Segments.

 

Zwei in unterschiedliche Zonen gesteckte NICs in einer Maschine sind das Gegenteil von Netztrennung, das ist Netzbrückung. Jeder Pentester kriegt bei sowas gleich feuchte Augen.

 

Ich würde hier die Windows-Firewall ins Gespräch bringen wollen, und zwar ausgehend von der Annahme, dass die schützenswerten Dinge ein recht modernes Windows-OS haben und die Firewall somit gut funktioniert, also besser als auf XP  Dann beschränkst Du mit Policies, wer MIT dieser Maschine kommunizieren darf und auf welchen Protokollen, also nur Inbound Rules. Damit ist es egal, ob in einem Segment oder über Segmentgrenzen hinweg.

[Weingeist 159]

Danke euch!

 

@mwiederkehr Zusätzliche 0815 Hardware will ich vermeiden wenn ausfallsichere Server vorhanden sind. Dann doch lieber eine VM-Appliance. Wenn es mit Bordmitteln von Windows sinnvoll klappt, ist das aber jeweils meine bevorzugte Variante (Kosten, KnowHow usw). 

 

@daabm Wieso meinst Gebastel? Weil es tendenziell mühsam in der Konfig/Konfigauswertung ist und nicht "Ressourcenschonend"?

Eigentlich will ich ja kein Routing sondern eine simple Bridge mit Filterfunktion. Wenn der Verkehr über die Windows-Firewall/BFE läuft, kann ich da ran, sonst nicht.

 

@cj_berlin ISA/TMG: Für alles brauchte man den Client nicht. Im Detail ist das per Schieberegister aus meinem Gedächnis raus, wann er es notwendig war und wann nicht. Konfig war halt sehr straight und imho einfach verständlich. Und selbst die GUI und die Logs waren gut. Beim TMG konnte man soweit ich mich erinnere die Patches über all die Jahre gesehen glaub an einer Hand abzählen. Muss also doch ziemlich gut programmiert worden sein. Und da sie in die BFE eingegliedert war, muss auch diese an sich ziemlich gut sein.

 

Aber zurück zum Thema: Im Grunde bin ich gezwungen davon auszugehen, das die "unsicheren" Maschinen grundsätzlich safe sind da von extern möglichst abgeschottet. Sonst dürften keine Daten zwischen Maschinen/CAD/Büro ausgetauscht werden. Auf gar keine Weise.

 

vor einer Stunde schrieb cj_berlin:

Zwei in unterschiedliche Zonen gesteckte NICs in einer Maschine sind das Gegenteil von Netztrennung, das ist Netzbrückung. Jeder Pentester kriegt bei sowas gleich feuchte Augen.

 

Ich würde hier die Windows-Firewall ins Gespräch bringen wollen, und zwar ausgehend von der Annahme, dass die schützenswerten Dinge ein recht modernes Windows-OS haben und die Firewall somit gut funktioniert, also besser als auf XP  Dann beschränkst Du mit Policies, wer MIT dieser Maschine kommunizieren darf und auf welchen Protokollen, also nur Inbound Rules. Damit ist es egal, ob in einem Segment oder über Segmentgrenzen hinweg.

Das ist mir durchaus bewusst. Genau deshalb soll diese Maschine zwischen den Netzen ja eine Brücke mit Kontrollstelle/Beschränkung sein. Also im Grunde einfache Firewall-Funktionen übernehmen. Hauptziel ist es, einem allfällig infizierten Desktop die Möglichkeit zu nehmen/erschweren/Potential einzugrenzen, die unsicheren Clients der Produktion direkt mit unsicheren/anfälligen Protokollen zu erreichen/befallen und somit die Produktion lahmzulegen.

Auch mit Kopien der Steuerung ist das äusserst mühsam (0-Punkte neu einlernen, neu kalibrieren, auslagern und neu einspielen von 800-1000 Werkzeuge pro Fräscenter, das gleiche mit Rohmaterial in den Roboter-Lager). Wenn jemand die Kontrolle über den Client hat, kann er die Schutz-Funktionen ja auch aushebeln. Wenn die Nutzung von der Brücke geblockt wird, hilft ihm das auf seinem Weg in die Produktion (hoffentlich) nicht weiter.

 

 

 

 

 

Etwas mehr Hintergrundinfos falls von Belang:

• Client A aus Bereich "Büro" ist Up to Date, hat empfohlenen Einstellungen, hat Internetzugriff
• Client B aus Bereich "Maschinennetz" mit denen ich ins Büro kommuniziere möchte sind Up to Date, haben ein modernes OS. Möglicherweisegewisse sind aber unsichere Einstellungen notwendig, um die Kommunikation innerhalb Netz zu den "alten" zu ermöglichen. Vieles was nicht sicher ist, kann ich per Windows-Firewall auf die Maschinenziele beschränken. Aber halt nicht alles (SMB1 z.B. kann nicht auf bestimmte Endgeräte beschränkt werden sondern nur SMB an sich, NTLM ist auch an oder aus).
• Wenn der eigentlich sichere B mit Einstellungen unsicher gemacht werden muss, soll der Zugriff von A auf B über einen sicheren Brückenkopf/Relay erfolgen. Dieser stellt dann auschliesslich die Funktionen bereitstellt die zwischen A und B benötigt werden. Dieser Brückenkopf (C) hat keine unsicheren Einstellungen wie aktiviertes SMB1/FTP und ist Bestandteil des AD.

Die Idee ist nun sicherzustellen, dass nur die C Server und die sicheren B von den Clients A erreicht werden können und umgekehrt. Auch wenn B und C sowie Uralt-Clients im gleichen Netz sind. Wenn ein C nicht mit verhältnissmässigem Aufwand zu bewerkstelligen ist obwohl B unsicher ist, soll die Bridge die Kommunikation mit dem proprietären Protokoll von A nach B direkt ermöglichen. Das soll dann auch möglichst nur auf Systemen sein, wo kein Usere mit Internetzugriff direkt darauf arbeitet.

 

Da das alles irgendwie einfach handelbar bleiben soll, auch für die Fehlersuche, möchte ich eben möglichst kein Routing sondern eine Bridge die gewisse Kommunikationswege erlaubt und den Rest blockiert. Auch soll es möglich sein, dass ich die Bridge zur Fehler-Ausschliessung raus nehmen kann.

 

 

Als letztes müssen noch Files hin und her. Messprotokolle, 3D-Zeichnungen, Überwachungsprotokolle usw.

Das geht über Workarounds/Transfersystem, habe ich schon Jahr im Einsatz, ist aber etwas umständlich. Wenn ich die strikte physische Netztrennung eh aufgebe, wären synchronisierte Filer schöner und bequemer für die Mitarbeiter. Da wäre die Idee SMB zwischen den Bereichen ganz zu blockieren oder nur zwischen den Filern freizugeben (sofern DFSR überhaupt SMB benötigt, sind ja eigene Protokolle).

Die Maschinen kommunzieren mit dem unsicheren Filer und authentifizieren sich mit Lokalen Service-Accounts/NTLM und erhalten Zugriff auf Files die sie betreffen. Die sicheren Clients gegen AD mittels Kerberos. DFSR übernimmt die Synchronisation.

 

Bessere Vorschläge sind natürlich herzlich willkommen!

[Admin666 3]

Hmm was für eine Firewall benutzt ihr denn?

 

Eine Firewall als Physisches Gerät hat ja eh mehrere NICs die können je nach Hersteller einfach mit einer Bridge oder mit bestimmten Routing Regeln versehen werden.

Normalerweise sollte die FW eine Bridge machen können so wie du dir das möchtest. Ansonsten sehe ich hier nur Routing mit strengen Regeln als Alternative wenn es einfach bleiben soll.

Wenn du nur bestimmte IPs miteinander reden lässt über bestimmte Protokolle sollte in der Theorie alles soweit gut sein (natürlich davon abhängig wie euer Netzwerk aussieht).

Wenn das Maschinen Netz nicht ans Internet angebunden ist, kommen die Bedrohungen ja von dem Clients oder den Servern die du als nicht bedenklich empfindest, (again laut Theorie) also solltest du schon mal dort anfangen die Sicherheit höher zu setzten.

An sich klingt das hier nach einer normalen Produktions Umgebung, wenn ihr Daten von aussen hereinbekommt sollten diese erst in euer Netz gelangen wenn diese "sicher" sind (hier sind halt ne gute FW und ein gutes AV zu empfehlen).

 

Zurück zu deinem Problem, diese unsicheren Clients (XP,7 etc) sind hoffentlich nicht in deiner Domäne. Zur Not kannste ne Taktik einsetzen die ich bei uns bebracht habe.

"Wenn Sie das Gerät nicht bald ersetzen dürfen Sie nur noch mit USB-Stick Daten hin und her tauschen". Hat sogar funktioniert.

[daabm 1.366]

vor 4 Stunden schrieb Weingeist:

Wieso meinst Gebastel? Weil es tendenziell mühsam in der Konfig/Konfigauswertung ist und nicht "Ressourcenschonend"?

 

Ich hatte das früher auf meinem Entwicklungsserver laufen, um die ganzen VirtualBox-Netze sauber zu verbinden. Hängt sich gern mal auf, es gibt kein gescheites Monitoring/Logging, und das UI ist etwas - hm - "spröde" 😂 Und die Windows-Firewall kann Regeln nicht an einzelne Adapter binden, die sind immer global.

[Weingeist 159]

@daabm Aufhängen.... Hmm, das wäre in der Tat unschön. Bis jetzt wusste ich nur, dass er etwas "grässlich" in der Konfig sein soll und nicht unbedingt das performanteste (wobei das bei einer >3GHZ CPU heute auch egal sein dürfte). Mein Link war halt folgender, MS macht mittlerweile viel auf Netzwerkebene mit HyperV, also sollte sie das mittlerweile auch zuverlässig können. Und auch der ISA/TMG konnte das problemlos zuverlässig vor über 10 Jahren. Also warum sollte das heute, über 15 Jahre nach dem ersten vernünftigen ISA, nicht auch mit Bordmittel gehen 

 

@Admin666 Ja klar ist es das klassische Produktions-Problem. Und gerade aus genannten Gründen, mag ich da keine LAN-Verbindungen. Daher sehe ich auch eher das Büro als Bedrohung für die Produktion als anderes rum, auch wenn in der Produktion die unsicheren Rechner sitzen. Ist ein Bürorechner befallen, hat er leichtes Spiel mit einem Rechner in der Produktion. Anders rum eher nicht und die Wahrscheinlichkeit ist deutlich tiefer ohne Internetzugriff.

 

An die Nutzung der Firewall welche jeweils den Internet-Teil erledigt, habe ich durchaus auch schon gedacht. Aber ich möchte ja eben nicht ein Gerät ohne doppelte Netzteile etc. als wichtiges Bindeglied haben. Gibt nur wieder Potential für super dringende Einsätze vor Ort und genau die möchte ich möglichst verhindern. Dann lieber eine Appliance. Oder eben Windows Aber Windows schlage ich mir wohl wieder aus dem Kopf auch wenn mir die Filtermöglichkeiten der Firewall ausreichen würden bzw. teilweise sogar einfacher ist (koppeln mit AD-Konten z.B.)

 

Am 25.5.2023 um 13:02 schrieb Admin666:

Zurück zu deinem Problem, diese unsicheren Clients (XP,7 etc) sind hoffentlich nicht in deiner Domäne. Zur Not kannste ne Taktik einsetzen die ich bei uns bebracht habe.

"Wenn Sie das Gerät nicht bald ersetzen dürfen Sie nur noch mit USB-Stick Daten hin und her tauschen". Hat sogar funktioniert.

Natürlich nicht. Aber die Daten müssen ja dennoch ausgetausch werden (siehe Posts weiter oben). Mit verschiedensten unsicheren Protokollen und eben mittlerweile immer mehr Live-Daten. Und nur weil man eine Firewall hat, heisst das ja nicht, dass es deswegen sicher ist wenn man auf unsichere Weise kommunziert.

 

Datenaustausch mit USB-Sticks.: Nope, das habe ich alles ausgemerzt. In jedem Betrieb gibt es ein absolutes Stick-Verbot. Egal ob Externe oder interne Mitarbeiter.

Man muss immer bedenken, eine Machschin die 50k bis 1 mio kostet, mechanisch top ist, wird nicht komplett getauscht nur weil der Steuerrechner veraltet ist. Da muss man eine erträgliche, manchmal kreative Lösung suchen. Bei hochtintegrierten Maschinen/Produktionszellen wird das zunehmend schwieriger. Insbesondere weil das so mit XP/7 erst so richtig angefangen hat. Aber auch ein aktuelles Windows 10 hilft nichts, wenn der Hersteller sämtlichen Support verweigert wenn Updates eingespielt werden. Was ich sogar verstehen kann bei der Pro Version (Bei XP 7 habe ich dank getrennten Sicherheits/Featureupdates die reinen Sicherheitsupdates dennoch problmlos eingespielt).

MS hätte ja Abhilfe geschaffen mit IoT/LTSC aber ich bin nicht sicher, dass ich das noch erlebe solange ich arbeite bis das in der Industrie durch ist und nicht mehr Pro verwendet wird. (Der Beschaffungsweg ist ja auch tendenziell beschissen). Im Messbereich gibt es schon löbliche Ausnahmen. :)

[Admin666 3]

Am 27.5.2023 um 10:30 schrieb Weingeist:

An die Nutzung der Firewall welche jeweils den Internet-Teil erledigt, habe ich durchaus auch schon gedacht. Aber ich möchte ja eben nicht ein Gerät ohne doppelte Netzteile etc. als wichtiges Bindeglied haben. Gibt nur wieder Potential für super dringende Einsätze vor Ort und genau die möchte ich möglichst verhindern. Dann lieber eine Appliance. Oder eben Windows Aber Windows schlage ich mir wohl wieder aus dem Kopf auch wenn mir die Filtermöglichkeiten der Firewall ausreichen würden bzw. teilweise sogar einfacher ist (koppeln mit AD-Konten z.B.)

 

Ah ich verstehe, du denkst es gibt nur Firewalls mit einem Netzteil und das wars. Nein da kann ich dich beruhigen es gibt da weitaus mehr, eine Firewall würde ich sowieso nie empfehlen mindestens einen Cluster in einer Produktions-Umgebung. Spart Zeit und Nerven glaub mir. Und keine Virtuelle FW das ist nichts dolles lieber gute alte harte Ware hier.

 

[Weingeist 159]

@Admin666 Verweis auf Kosten gesehen? Von den grösseren Hersteller ist das richtig teuer. Ebenso die Wartung pro Jahr. Für Leistung die ich ausser den Netzteilen nie brauchen werde. Heute wo alles virtualisiert ist, sehe ich das unkritisch. Insbesondere für eine interne FW. Die Funktion ist eh die selbe. Unterschied ist bei den grossen Hersteller nur ob ein propritäres System oder eben Vmware/HyperV die Virtualisierung übernimmt.

 

Wie dem auch sei, da niemand diesbzüglich mit Windows bzw. dessen Firewahl in Verbindung mit einer Bridge entsprechende Erfahrung zu haben scheint, werde ich die Tests selber machen. Sehe punkto Bridge zwar wenig Chancen aber schauen wir mal. Sonst gibt es eben eine Appliance.

[Dukel 455]

Es gibt auch Open Source Firewalls, bei denen man nur Hardware braucht. Und hier kann man einen kleinen, relativ günstigen Server nutzen mit mehreren Netzteilen oder als VM laufen lassen.

[Admin666 3]

@Weingeist Naja gut Wartung machen wir selber diese Kosten fallen schon mal weg bei uns.

Ich weiß jetzt nicht ob du externer oder interner bist.

Aber wenn ein Kunde bei uns schon bei der FW spart, ist das in der Regel eine "red flag" für uns. 

[Weingeist 159]

vor 19 Stunden schrieb Admin666:

@Weingeist Naja gut Wartung machen wir selber diese Kosten fallen schon mal weg bei uns.

Ich weiß jetzt nicht ob du externer oder interner bist.

Aber wenn ein Kunde bei uns schon bei der FW spart, ist das in der Regel eine "red flag" für uns. 

Wartung: Da verlangen die grossen Hersteller etwas für Garantie, Updates etc. Je 'grösser' und leistungsfähiger (Bandbreite) die FW, desto teurer wird das bei den 'besseren' Hersteller. Doppelte Netzteile gibts eigentlich bei allen erst bei den grösseren.

Es geht nicht per se um das sparen, es geht darum nicht unnötig Geld zu verpulvern für eine Leistung, die man nicht braucht. Ein zweites Netzteil ist z.B. nunmal keine 1000 Euro pro Jahr wert wenn man den rest nicht benötigt. Und jede zusätzliche Hardware die ich nicht einsetze, geht nicht kaputt.

 

Der Vorteil bei Windows-Bordmitteln sehe ich immer in den zeitnahen Updates und der bereits integrierten Rechte-Verwaltung. Sprich Kopplung an AD möglich ohne irgendwelche Verrenkungen. Und eben keine zusätzliche Hardware.

 

vor 23 Stunden schrieb Dukel:

Es gibt auch Open Source Firewalls, bei denen man nur Hardware braucht. Und hier kann man einen kleinen, relativ günstigen Server nutzen mit mehreren Netzteilen oder als VM laufen lassen.

Ist Dir grad etwas gutes bekannt? Sollte +- einfach in der Konfig, Updates etc. sein und über vernünftige Logs verfügen. Primär geht es aber nicht darum nichts zu bezahlen, sondern tendenziell wenig laufende Kosten zu verursachen.

[Nobbyaushb 1.475]

Moin,

SecurePoint kann man auch als VM fahren, kostet aber Lizenzen

Sonst OPNsense

Initial Installation & Configuration — OPNsense documentation

[NorbertFe 2.061]

vor einer Stunde schrieb Weingeist:

Doppelte Netzteile gibts eigentlich bei allen erst bei den grösseren.

Also so groß sind die hier nicht ;)

https://www.sophos.com/de-de/products/next-gen-firewall/tech-specs#XGSDesktop
 

muss man halt dazubestellen.