12
REST API Server im Netz nach außen verfügbar machen
Hallo zusammen,
ich bräuchte mal eure Meinung bzw. Unterstützung bei einem Szenario.
Das Unternehmen bekommt eine neue Webseite und in dieser Webseite ist ein Webshop integriert der über eine REST-API Schnittstelle Daten aus dem ERP beziehen soll.
Dieser API Server ist bei uns im Netz als VM installiert. Nun soll es so sein, dass der Webshop auf den API Server zugreifen soll.
Ich habe den API Server als Objekt auf der Firewall in einem eigenen Subnetz angelegt.
Meine Überlegung wäre nun diesen in eine DMZ zu setzen und dann nur den Zugriff von extern zu diesem REST-API Server zu gestatten.
Über Firewallregeln würde ich dann noch die Kommunikation zwischen ERP System und REST-API beschränken.
Soweit meine Idee.
Es handelt sich um eine LANCOM Firewall GPA 300
ich bräuchte mal eure Meinung bzw. Unterstützung bei einem Szenario.
Das Unternehmen bekommt eine neue Webseite und in dieser Webseite ist ein Webshop integriert der über eine REST-API Schnittstelle Daten aus dem ERP beziehen soll.
Dieser API Server ist bei uns im Netz als VM installiert. Nun soll es so sein, dass der Webshop auf den API Server zugreifen soll.
Ich habe den API Server als Objekt auf der Firewall in einem eigenen Subnetz angelegt.
Meine Überlegung wäre nun diesen in eine DMZ zu setzen und dann nur den Zugriff von extern zu diesem REST-API Server zu gestatten.
Über Firewallregeln würde ich dann noch die Kommunikation zwischen ERP System und REST-API beschränken.
Soweit meine Idee.
Es handelt sich um eine LANCOM Firewall GPA 300
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 625586
Url: https://administrator.de/forum/rest-api-server-im-netz-nach-aussen-verfuegbar-machen-625586.html
Ausgedruckt am: 22.12.2024 um 19:12 Uhr
12 Kommentare
Neuester Kommentar
Moin,
ich würde mich bei der Kommunikationseinschränkung nicht nur auf die F/W verlassen und im Backend CORS und CRSF aktivieren/implementieren, so dass nur der Shop Anfragen an die API senden darf...
VG,
schleeke
ich würde mich bei der Kommunikationseinschränkung nicht nur auf die F/W verlassen und im Backend CORS und CRSF aktivieren/implementieren, so dass nur der Shop Anfragen an die API senden darf...
VG,
schleeke
Vielen Dank für deine Rückmeldung. Ehrlich gesagt kenn ich mich damit nicht aus. Wenn man sich dazu ein paar Artikel durchliest wird davon aber immer abgeraten. Ich kann mir darüber aber natürlich nicht wirklich eine Meinung bilden, da ich mich damit noch nicht tiefgründiger beschäftigt habe.
https://www.securai.de/veroeffentlichungen/blog/was-ist-cors-und-welche- ...
"Da die Applikation aber zusätzlich so offen im Bezug auf Cross Origin Requests war, konnte mit einem einfachen JavaScript Code ein erfolgreicher CSRF-Angriff auf die REST API über die Web-Applikation durchgeführt werden.
Grundsätzlich ist zu empfehlen, CORS nur zu implementieren, wenn es absolut notwendig ist und dann so restriktiv wie möglich."
https://www.securai.de/veroeffentlichungen/blog/was-ist-cors-und-welche- ...
"Da die Applikation aber zusätzlich so offen im Bezug auf Cross Origin Requests war, konnte mit einem einfachen JavaScript Code ein erfolgreicher CSRF-Angriff auf die REST API über die Web-Applikation durchgeführt werden.
Grundsätzlich ist zu empfehlen, CORS nur zu implementieren, wenn es absolut notwendig ist und dann so restriktiv wie möglich."
Wenn ich das richtig verstehe, kommen die API-Amfragen allesamt vom Backend des Webshops an die API, nicht vom Nutzer.
Dann ist CORS ohne Funktion und würde keinen Mehrwert bieten.
In dem Fall reicht es aus, den Zugriff auf die IP oder das Subnetz des Backends zu beschränken und ordentliches TLS zu machen.
Dann ist CORS ohne Funktion und würde keinen Mehrwert bieten.
In dem Fall reicht es aus, den Zugriff auf die IP oder das Subnetz des Backends zu beschränken und ordentliches TLS zu machen.
Folgende Aussage des Herstellers:
"Die Rest API ist nun bei XXX im Netzwerk aufgesetzt. Um XXX diese auch verfügbar zu machen, müsste der Webserver nach Außen geöffnet werden. Wir empfehlen dazu den Einsatz eines zusätzlichen Proxyservers, da der API-Server direkten Zugriff auf die Datenbank hat"
Ich verstehe es so, dass der Webshop von außen auf die Rest API zugreifen soll und dann Daten aus der Datenbank in den Webshop hochlädt.
Somit bin ich eigentlich der Meinung, dass meine Idee schon die richtige ist!?
API Server in ein eigenes Subnetz / DMZ setzen. Die Zugriffe von extern auf diesen Server von nur dieser einen externen IP zulassen und dann mittels Firewall Regeln den Zugriff von dem API Server auf die Datenbank über gewisse Ports zulassen.
Oder bin ich hier komplett auf dem Holzweg?
"Die Rest API ist nun bei XXX im Netzwerk aufgesetzt. Um XXX diese auch verfügbar zu machen, müsste der Webserver nach Außen geöffnet werden. Wir empfehlen dazu den Einsatz eines zusätzlichen Proxyservers, da der API-Server direkten Zugriff auf die Datenbank hat"
Ich verstehe es so, dass der Webshop von außen auf die Rest API zugreifen soll und dann Daten aus der Datenbank in den Webshop hochlädt.
Somit bin ich eigentlich der Meinung, dass meine Idee schon die richtige ist!?
API Server in ein eigenes Subnetz / DMZ setzen. Die Zugriffe von extern auf diesen Server von nur dieser einen externen IP zulassen und dann mittels Firewall Regeln den Zugriff von dem API Server auf die Datenbank über gewisse Ports zulassen.
Oder bin ich hier komplett auf dem Holzweg?
Moin,
Gruß,
Dani
API Server in ein eigenes Subnetz / DMZ setzen.
wenn die DMZ richtig entworfen und entsprechend gepflegt ist, muss es doch kein separates Subnetz sein. Denn normalweise sind gerade dort die Firewalls der Server so eng wie möglich abgesteckt. So dass der Aufruf der API theoretisch gar nicht möglch ist.Die Zugriffe von extern auf diesen Server von nur dieser einen externen IP zulassen
Korrekt. Am Besten ist es, wenn dein Projekt/Applikation einen dedizierten Server hat und somit die öffentliche IP-Adresse ausschließlich nur du nutzt.ann mittels Firewall Regeln den Zugriff von dem API Server auf die Datenbank über gewisse Ports zulassen.
Korrekt.Gruß,
Dani
Leute ich muss das Thema noch mal aufgreifen da wir momentan ein paar Probleme haben.
Der NFS Mount von dem REST-API Server (192.168.112.190) auf das ERP System (192.168.115.190) läuft nur sehr träge. Manchmal lassen sich diese auch garnicht mounten.
ll /home/sybase <- manchmal erscheinen sofort alle Freigaben. Manchmal passiert einfach nichts.
Es handelt sich beim REST-API Server um CentOS 7.
Das gleiche problem ist beim SSH Zugriff vom ERP System auf den REST-API Server. Ping in beide Richtungen läuft ganz normal.
Sobald ich den REST-API ins gleiche Subnetz hebe (also 192.168.115.xx) ist der Mount und auch der SSH Zugriff sofort gegeben.
Ich finde hier den Fehler einfach nicht
Hat einer eine Idee wieso der Zugriff (SSH und NFS Mount) so schlecht bzw. so träge stattfindet?
Ich hatte erst die Switche in Verdacht und habe als Gateway dann die IP-Adresse der Firewall eingetragen aber auch das hat nicht geholfen.
Der NFS Mount von dem REST-API Server (192.168.112.190) auf das ERP System (192.168.115.190) läuft nur sehr träge. Manchmal lassen sich diese auch garnicht mounten.
ll /home/sybase <- manchmal erscheinen sofort alle Freigaben. Manchmal passiert einfach nichts.
Es handelt sich beim REST-API Server um CentOS 7.
Das gleiche problem ist beim SSH Zugriff vom ERP System auf den REST-API Server. Ping in beide Richtungen läuft ganz normal.
Sobald ich den REST-API ins gleiche Subnetz hebe (also 192.168.115.xx) ist der Mount und auch der SSH Zugriff sofort gegeben.
Ich finde hier den Fehler einfach nicht
Hat einer eine Idee wieso der Zugriff (SSH und NFS Mount) so schlecht bzw. so träge stattfindet?
Ich hatte erst die Switche in Verdacht und habe als Gateway dann die IP-Adresse der Firewall eingetragen aber auch das hat nicht geholfen.
Moin,
wir kennen deine Umgebung nicht. Da hilft auch keine Glaskugel.
Skizziere erst einmal nochmal den physkalischen als auch logischen Netzaufbau. Über welche Server/Hops läuft das Datenpaket von REST API Server -> ERP Server und umgekehrt. Bitte gebe auch Namen bzw. IP-Adressen an. Damit es logisch ist.
Was ich nicht verstehe, warum du den REST-API Server in eine "DMZ" stellst, dann aber eine Freigabe aus dem LAN verbindest?! Ist für mich kein übliches Design.
Gruß,
Dani
wir kennen deine Umgebung nicht. Da hilft auch keine Glaskugel.
Skizziere erst einmal nochmal den physkalischen als auch logischen Netzaufbau. Über welche Server/Hops läuft das Datenpaket von REST API Server -> ERP Server und umgekehrt. Bitte gebe auch Namen bzw. IP-Adressen an. Damit es logisch ist.
Ich hatte erst die Switche in Verdacht und habe als Gateway dann die IP-Adresse der Firewall eingetragen aber auch das hat nicht geholfen.
Wie hast du den Verdacht aus dem Welt geräumt? Hat einer eine Idee wieso der Zugriff (SSH und NFS Mount) so schlecht bzw. so träge stattfindet?
Na im Worst Case mit Wireshark auf dem Servern bzw. den Firewall/Gateway den Traffic mitschneiden und hinterher analysieren.Was ich nicht verstehe, warum du den REST-API Server in eine "DMZ" stellst, dann aber eine Freigabe aus dem LAN verbindest?! Ist für mich kein übliches Design.
Gruß,
Dani
Internet: VDSL mit fester IP
Firewall: Lancom GPA300
Lokales Netz: 192.168.115.xx
DMZ: 192.168.112.xx
DMZ wurde vom LANCOM Techniker angelegt. Der Zugriff von der externen Webseite erfolgt mittels HTTPS auf das REST System. Dafür wurde nur die eine öffentliche IP-Adresse als Zugriff erlaubt.
Zitat von @Dani:
Was ich nicht verstehe, warum du den REST-API Server in eine "DMZ" stellst, dann aber eine Freigabe aus dem LAN verbindest?! Ist für mich kein übliches Design.
Der REST-Server muss sich die Daten aus dem ERP ziehen um dem Webshop zur Verfügung zu stellen. Dafür wurde eine Regel NFS (Port 111) vom REST-Server zum ERP angelegt.Was ich nicht verstehe, warum du den REST-API Server in eine "DMZ" stellst, dann aber eine Freigabe aus dem LAN verbindest?! Ist für mich kein übliches Design.
Die Lancom Techniker haben sich das ganze Konstrukt nochmal angeschaut und bestätigt das es so in Ordnung wäre.
Nun zum Problem:
Wenn der Rest-Server in der DMZ steht und die IP-Adresse 192.168.112.190 hat funktioniert der SSH Zugriff vom ERP zum REST-Server schlecht und das Mounten der Laufwerke vom REST-Server zum ERP ebenfalls.
Dann habe wir testhalber den REST-Server eine IP-Adresse aus dem lokalem Netz gegeben und der Zugriff mittels SSH und das Mounten funktioniert einwandfrei.
Mir ist beim Test noch was aufgefallen. Immer wenn das Mounten nicht funktioniert und man dann einen Ping auf das ERP absetzt, funktioniert danach das Mounten sofort.
Ich hoffe das reicht aus als Information.
Zitat von @Dani:
Na im Worst Case mit Wireshark auf dem Servern bzw. den Firewall/Gateway den Traffic mitschneiden und hinterher analysieren.
Na im Worst Case mit Wireshark auf dem Servern bzw. den Firewall/Gateway den Traffic mitschneiden und hinterher analysieren.
Im Moment mache ich das direkt über die Firewall. Müsste mich sonst mal mehr mit Wireshark auseinander setzen.
Moin,
Mit welchen Befehl verbindest du das NFS Share?
Gruß,
Dani
Der REST-Server muss sich die Daten aus dem ERP ziehen um dem Webshop zur Verfügung zu stellen. Dafür wurde eine Regel NFS (Port 111) vom REST-Server zum ERP angelegt.
Das erklärt zwar immer noch nicht, warum ein NFS Share gemountet werden muss, aber evtl. denke ich dazu statisch.Mir ist beim Test noch was aufgefallen. Immer wenn das Mounten nicht funktioniert und man dann einen Ping auf das ERP absetzt, funktioniert danach das Mounten sofort.
Duplicate IP in der DMZ bzw. LAN? Ist zwar bei dem kleinen Setup nicht vorstellbar aber nicht ausgeschlossen.Dafür wurde eine Regel NFS (Port 111)
TCP und/oder UDP?Mir ist beim Test noch was aufgefallen. Immer wenn das Mounten nicht funktioniert und man dann einen Ping auf das ERP absetzt, funktioniert danach das Mounten sofort.
Damit tippe ich auf die Firewall. Mit welchen Befehl verbindest du das NFS Share?Gruß,
Dani
Mir ist beim Test noch was aufgefallen. Immer wenn das Mounten nicht funktioniert und man dann einen Ping auf das ERP absetzt, funktioniert danach das Mounten sofort.
Duplicate IP in der DMZ bzw. LAN? Ist zwar bei dem kleinen Setup nicht vorstellbar aber nicht ausgeschlossen.Dafür wurde eine Regel NFS (Port 111)
TCP und/oder UDP?Mir ist beim Test noch was aufgefallen. Immer wenn das Mounten nicht funktioniert und man dann einen Ping auf das ERP absetzt, funktioniert danach das Mounten sofort.
Damit tippe ich auf die Firewall. Mit welchen Befehl verbindest du das NFS Share?systemctl restart autofs
über ll /home/verzeichnis wird dieses dann aufgerufen
Moin,
Wir können aber gerne tauschen. Ich such seit letzer Woche eine TCP/IP Fehler auf einem SQL Server.
Denn ll ist "nur" ein Anzeigebefehl.
Gruß,
Dani
Puh das ist kaum vorstellbar. Aber könnte ich mal testen.
ich kann nur Ideen liefern... du sitzt vor Ort.Wir können aber gerne tauschen. Ich such seit letzer Woche eine TCP/IP Fehler auf einem SQL Server.
Immer wenn das Mounten nicht funktioniert...
Du könntest du nach dem ersten Versuch einmal auf die Firewall schauen, ob die Verbindung angekommen und auch erlaubt wurde.Es handelt sich so wie ich das sehe um einen Automount:
Gut und recht. Aber wie sieht der Befehl für den Mount aus? Nicht vergessen Benutzer und Passwort zu entfernen. Denn ll ist "nur" ein Anzeigebefehl.
Gruß,
Dani
Sorry das ich mich jetzt erst wieder melde.
Wir haben den Fehler nun eventuell nach ein paar Stunden hoffentlich gelöst.
Das Problem hatte anscheind mehrere Ursachen. Unter anderem lag es wohl daran, dass alleine der Port 111 (NFS) für das Mounten nicht ausreicht.
Wir mussten noch Port 2049 freigeben. Außerdem wurde beim mounten anscheind immer noch ein zusätzlicher Port ausgehandelt. Diesen Port haben wir auf 20048 festgesetzt und in der Firewall ebenfalls eingetragen.
Außerdem wurde folgendes in die /etc/sysctl.d geschrieben:
Uns ist nämlich beim Ping Befehl vom REST Server zum ERP immer aufgefallen das er einen redirect hopp durchgeführt hat.
Wir haben den Fehler nun eventuell nach ein paar Stunden hoffentlich gelöst.
Das Problem hatte anscheind mehrere Ursachen. Unter anderem lag es wohl daran, dass alleine der Port 111 (NFS) für das Mounten nicht ausreicht.
Wir mussten noch Port 2049 freigeben. Außerdem wurde beim mounten anscheind immer noch ein zusätzlicher Port ausgehandelt. Diesen Port haben wir auf 20048 festgesetzt und in der Firewall ebenfalls eingetragen.
Außerdem wurde folgendes in die /etc/sysctl.d geschrieben:
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.ens192.accept_redirects=0Uns ist nämlich beim Ping Befehl vom REST Server zum ERP immer aufgefallen das er einen redirect hopp durchgeführt hat.
