Webapplikation (IIS) sicher vom Technik-LAN ins Produktiv-LAN spiegeln
Hallo,
ich habe ein kleines Problem bzw. eine Nuss zu knacken. Bei einem unserer Kunden sollte ich ein Energiemanagementsystem implementieren - dieses besteht aus:
einer Webapplikation mit Anbindung an einen seriellen Bus (Online Werte) und einer SQL Datenbank (historische Werte).
Der Webserver (IIS) und der SQL-Server laufen auf einem Server im Techniknetz. Die Geräte welche über TCP/IP-RS485 Umsetzer angesprochen werden sind ebenfalls im Technik-LAN integriert. Bis hier ist alles rund - flache Hierachie, alle Komponenten in einem Netz. Die Bearbeiter sind glücklich weil sie ihre technischen Anlagen in Echtzeit und historisch überwachen können - und das mittels Browser.
Jetzt kommt aber die Buchhaltung die ebenfalls Auswertungen (der Energie) durchführen möchten - die Buchhaltung "steckt" aber logischerweise im Produktiv-Netz der Firma. Somit habe ich vorgeschlagen das wir dem Server eine zweite Netzwerkkarte spendieren:
Technik-LAN----|SERVER|----Produktiv-LAN----
Jetzt wurde das aber von der EDV vor Ort bzw. dem übergeordneten Konzern verweigert bzw. wollen diese kein "Loch" zwischen den Netzen aufmachen - schon gar nicht über Port 80.
Wenn es nur die SQL-Daten wären könnte man viel über eine nächtliche Datenbank-Replikation zwischen den SQL-Servern realisieren. Aber das Web "holt" sich Daten live über das Technik-LAN vom seriellen Bus - das kann ich nicht duplizieren bzw.
diese eine Webapplikation sollte unbedingt sicher aus beiden Netzen erreichbar sein!
Jetzt sollte ich natürlich eine Lösung finden bzw. habe ich dazu generell ein paar Fragen:
1. Wie würdet Ihr Euch jetzt generell dieser Problematik annehmen?
2. Verständnisfrage: Mal angenommen wir lassen unsere Webapplikation auf einem anderen Port "laufen" bzw. anstatt Port 80 z.B. Port 9999 etc. Dann kann ich das System doch so veriegeln (wie in einer Firewall LAN<->DMZ) das aus dem Produktiv-Netz wirklich nur dieser Port ins Technik-Netz freigegeben wird, oder? Wäre das wirklich sicherheitsrelevant so bedenklich?
Danke im Voraus für Eure Lösungsvorschläge!
ich habe ein kleines Problem bzw. eine Nuss zu knacken. Bei einem unserer Kunden sollte ich ein Energiemanagementsystem implementieren - dieses besteht aus:
einer Webapplikation mit Anbindung an einen seriellen Bus (Online Werte) und einer SQL Datenbank (historische Werte).
Der Webserver (IIS) und der SQL-Server laufen auf einem Server im Techniknetz. Die Geräte welche über TCP/IP-RS485 Umsetzer angesprochen werden sind ebenfalls im Technik-LAN integriert. Bis hier ist alles rund - flache Hierachie, alle Komponenten in einem Netz. Die Bearbeiter sind glücklich weil sie ihre technischen Anlagen in Echtzeit und historisch überwachen können - und das mittels Browser.
Jetzt kommt aber die Buchhaltung die ebenfalls Auswertungen (der Energie) durchführen möchten - die Buchhaltung "steckt" aber logischerweise im Produktiv-Netz der Firma. Somit habe ich vorgeschlagen das wir dem Server eine zweite Netzwerkkarte spendieren:
Technik-LAN----|SERVER|----Produktiv-LAN----
Jetzt wurde das aber von der EDV vor Ort bzw. dem übergeordneten Konzern verweigert bzw. wollen diese kein "Loch" zwischen den Netzen aufmachen - schon gar nicht über Port 80.
Wenn es nur die SQL-Daten wären könnte man viel über eine nächtliche Datenbank-Replikation zwischen den SQL-Servern realisieren. Aber das Web "holt" sich Daten live über das Technik-LAN vom seriellen Bus - das kann ich nicht duplizieren bzw.
diese eine Webapplikation sollte unbedingt sicher aus beiden Netzen erreichbar sein!
Jetzt sollte ich natürlich eine Lösung finden bzw. habe ich dazu generell ein paar Fragen:
1. Wie würdet Ihr Euch jetzt generell dieser Problematik annehmen?
2. Verständnisfrage: Mal angenommen wir lassen unsere Webapplikation auf einem anderen Port "laufen" bzw. anstatt Port 80 z.B. Port 9999 etc. Dann kann ich das System doch so veriegeln (wie in einer Firewall LAN<->DMZ) das aus dem Produktiv-Netz wirklich nur dieser Port ins Technik-Netz freigegeben wird, oder? Wäre das wirklich sicherheitsrelevant so bedenklich?
Danke im Voraus für Eure Lösungsvorschläge!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 134957
Url: https://administrator.de/contentid/134957
Ausgedruckt am: 13.11.2024 um 11:11 Uhr
6 Kommentare
Neuester Kommentar
Eine Kommunikation ist physisch nur möglich wenn du Technik Netz und Prod.Netz irgendwie koppelst. Soviel ist klar.
Ohne an den Maschinen rumzufummeln und Ports zu verbiegen könntest du das mit einem billigen DSL Router und dessen NAT Firewall machen.
Mit dem WAN/DSL Interface hängst du ihn ins Prod.Netz und gibst ihm dort eine feste IP. Das LAN Bein geht ins Technik Netz..
Nun konfigurierst du auf dem Router ein Port Forwarding von z.B. TCP 9999 auf lokal (Technik Netz) Server IP mit dem lokalen Port 80. Also eine simple Port Translation.
Jeder der im Prod.Netz im Browser "http://<router_ip_prod_netz>:9999" eingibt landet dann auf dem Server auf der Weboberfläche.
Der Router lässt nur einzig Port TCP 9999 durch mehr nicht, denn das verwindert sicher die NAT Firewall des Routers.
Wenn du nun noch das LAN Interface des Routers mit einer Accessliste zumachst die nur noch den Konfigurationszugriff auf seine eigen IP erlaubt kann auch keiner vom Techniknetz mehr ungefragt ins Prod.Netz.
Ganz auf Nummer sicher gehst du wenn du das mit einer freien Firewall wie Monowall oder Pfsense machst, denn nicht alle DSL Router supporten Incoming ACLs auf ihren LAN Ports (dd-wrt kann sowas z.B.)
Damit hast du dann ein absolut wasserdichtes System. Wenn du das dann politisch bei der EDV durchbekommst hast du dein Problem so gut wie kostenfrei im Handumdrehen gelöst !
Ohne an den Maschinen rumzufummeln und Ports zu verbiegen könntest du das mit einem billigen DSL Router und dessen NAT Firewall machen.
Mit dem WAN/DSL Interface hängst du ihn ins Prod.Netz und gibst ihm dort eine feste IP. Das LAN Bein geht ins Technik Netz..
Nun konfigurierst du auf dem Router ein Port Forwarding von z.B. TCP 9999 auf lokal (Technik Netz) Server IP mit dem lokalen Port 80. Also eine simple Port Translation.
Jeder der im Prod.Netz im Browser "http://<router_ip_prod_netz>:9999" eingibt landet dann auf dem Server auf der Weboberfläche.
Der Router lässt nur einzig Port TCP 9999 durch mehr nicht, denn das verwindert sicher die NAT Firewall des Routers.
Wenn du nun noch das LAN Interface des Routers mit einer Accessliste zumachst die nur noch den Konfigurationszugriff auf seine eigen IP erlaubt kann auch keiner vom Techniknetz mehr ungefragt ins Prod.Netz.
Ganz auf Nummer sicher gehst du wenn du das mit einer freien Firewall wie Monowall oder Pfsense machst, denn nicht alle DSL Router supporten Incoming ACLs auf ihren LAN Ports (dd-wrt kann sowas z.B.)
Damit hast du dann ein absolut wasserdichtes System. Wenn du das dann politisch bei der EDV durchbekommst hast du dein Problem so gut wie kostenfrei im Handumdrehen gelöst !
Hallo Zusammen,
so wie ich die Frage verstehe, könnte eine funktionierende Infrastruktur für's Routing bereits bestehen (inkl. ACLs) - diese soll nur nicht für alle HTTP-Anfragen geöffnet sein. Wenn dem so ist, würde lediglich ein URL-Filter fehlen (denn ob andere Anwendungen auf dem Server laufen, ist ja nicht bekannt).
Ein zusätzlicher (billiger) Router wäre so in meinen Augen nicht besser als die Lösung mit zwei Netzwerkkarten.
Grüße, Steffen
so wie ich die Frage verstehe, könnte eine funktionierende Infrastruktur für's Routing bereits bestehen (inkl. ACLs) - diese soll nur nicht für alle HTTP-Anfragen geöffnet sein. Wenn dem so ist, würde lediglich ein URL-Filter fehlen (denn ob andere Anwendungen auf dem Server laufen, ist ja nicht bekannt).
Ein zusätzlicher (billiger) Router wäre so in meinen Augen nicht besser als die Lösung mit zwei Netzwerkkarten.
Grüße, Steffen
Na ja, ob nun die Öffnung des Webservers in die große weite (Internet) Welt eine bessere Lösung sein soll als nur die Öffnung auf ein einzelnes Netz ist doch mehr als fraglich....
Die Anforderungen die dann an den Webserver gestellt werden sind horrend höher, da das Gefahrenpotenzial nun ein ganz anderes geworden ist und vielfach höher liegt. Wenn dieser Webserver auf einem MS OS laufen sollte wären die Bauchschmerzen noch erheblich größer...gerade mit der Lösung eines billigen Consumerrouters und simplen Port Forwarding ohne zusätzlichen Schutz.
Auf den ersten Blick hört sich diese Lösung erheblich gefährlicher an als der erste Vorschlag. Die Denkweise dieser "EDV vor Ort" ist schon zweifelhaft und schwer zu verstehen. Verstehen die überhaupt etwas von der Materie oder müssen die auch in Foren nachfragen ??
Die Anforderungen die dann an den Webserver gestellt werden sind horrend höher, da das Gefahrenpotenzial nun ein ganz anderes geworden ist und vielfach höher liegt. Wenn dieser Webserver auf einem MS OS laufen sollte wären die Bauchschmerzen noch erheblich größer...gerade mit der Lösung eines billigen Consumerrouters und simplen Port Forwarding ohne zusätzlichen Schutz.
Auf den ersten Blick hört sich diese Lösung erheblich gefährlicher an als der erste Vorschlag. Die Denkweise dieser "EDV vor Ort" ist schon zweifelhaft und schwer zu verstehen. Verstehen die überhaupt etwas von der Materie oder müssen die auch in Foren nachfragen ??