10. Juli 2024 15:27
Hallo Zusammen,
vielleicht kann mir jemand weiterhelfen bei einem sehr mysteriösen Problem:
unsere Software sendet zu mehreren Firmen Client seitige API Anfragen.
Das sind meistens REST API's und wir haben die Ansteuerungs-Logiken in C# umgesetzt,
entweder über .NET Klassen wie den simplen C# Web-Client oder über 3thrd Party Komponenten wie den RestClient.
Das Ganze ist in einer .NET Bibliothek, die wir über BC14 Server seitig ansteuern.
Ein Kunde hat nun auf Grund eines interen Sicherheitsvorfalles eine komplett neu Firewall aufgezogen,
die extrem restriktiv ist.
Es ist irgendwie alles gesperrt was nicht explizit erlaubt ist.
Natürlich haben wir dem Kunden die Endpunkte der jeweiligen API's mitgeteilt.
Manche Dienste gehen dann wieder einige Tage, dann nach ca. einer Woche gehen dann Dienste wieder nicht mehr, ganz seltsam.
Der Kunde bindet auch glaube 2 Kataloganbieter in die Firewall ein, einer davon müsste Cloudfare sein.
Um den Fehler einzuschränken, habe ich dann eine der API's ausgewählt, die sehr simpel aufgebaut ist.
Einen REST Service mit 2 Parameter die einfach an die URL angehängt werden.
Vorteil bei dieser einfachen Variante ist, dass über den Browser das Ergebnis direkt angezeigt werden kann.
Dann haben wir das in Postman nachgestellt und noch den eigenen C# Code, den ja BC14 über den Application Server Dienst
ausführt in ein externes kleines C# Tool gepackt.
Jetzt haben wir wirklich den Fall, dass am Server beim Kunden: der Browser Daten anzeigt, Postman ebenso
und das C# Testtool ebenso.
Wird der gleiche C# Code am Dynamics Application Server ausgeführt, wir der API Call geblockt.
C# Tool und Dynamics Dienst laufen unter dem selben Admin User.
Ein Admin beim Kunden hat die Anfrage an der Firewall zwischen dem C# Testool und aus BC14 heraus verglichen und keinen Unterschied gefunden.
Ich bin mit meinem Latein am Ende.
Die Ausführung eines .NET Codes sollte doch aus einer Windows Forms App das Gleiche sein wie wenn der Application Server Dienst den C# Code ausführt.
Natürlich werden auch keine Dialoge etc.geöffnet, dass könnte der Server Prozess ja nicht, das habe ich schon ausgeschlossen.
Bei keinem anderen Kunden haben wir das Problem, die geben einfach die jew. Endpunkte in der Firewall frei und stellen ein, dass zur gemachten Anfrage
alle ANtworten/Redirects durchgelassen werden.
Hat jemand vielleicht irgendeine Ahnung, wo man da Ansetzen könnte.
Danke
Gruß
30. Juli 2024 10:55
Ist vielleicht irgendein Programm ala Crowdstrike installiert, welche die Anfragen auf dem Rechner blockiert?
Wireshark is your friend.
30. Juli 2024 14:08
Hi, danke Dir für die Antwort.
So weit ich weiß, ist nur die Firewall aktiv und die blockt das.
In der Zwischenzeit hat der Kunde alle API's bis auf eine einzige zum Laufen gebracht.
Das hat der Kunde laut seiner Aussage dadurch erreicht, in dem er in der Firewall etliche CDN's freigeschaltet hat, z.B. Cloudflare,GlobalSign,VeriSign und sogar einige Microsoft CDN's, eins davon Microsoft-Dynamics CDN.
Ich muss sagen, ich wusste bis vor einer Woche nicht, was ein CDN ist.
Laut dem Kunden soll anscheinend auch Dynamics 365 an irgendwelchen Stelle im Netz was nachladen und braucht dafür diese CDN's.
Ich ging eigentlich immer davon aus, dass es zur Freischaltung einer API reicht, den Endpunkt des API Anbieters in der Firewall freizuschalten,
aber dass man auch weitere Komponenten freischalten muss, auf die evtl. wiederum die API zugreift ist mir neu.
Auf jeden Fall wüsste ich da kein Mittel, das zu ermitteln.
Wireshark haben wir schon kurz versucht, aber selbst bei einem 15 Sekündigen Mittschnitt haben wir als nicht "Netzwerk-Spezalisten" kaum eine Chance da was in den Log Dateien rauszufinden.
Das einzige was ich soweit debuggen konnte ist, dass mir die C# WebClient Klasse eine Web Exception wirft, aber leider nur mit der Meldung Timeout erreicht. Die Anfrage kommt also nie beim API Endpunkt an
2. August 2024 18:18
Also ist einfach eine zu restriktive Firewall das Problem. Das ist eben bei den genannten CDNs echt ein Problem. Und wenn dann die Dokumentation fehlt, welche Domains angesprochen werden, wird's nicht einfacher.
6. August 2024 15:05
danke für Deine Antwort.
Stimmt, die Firewall ist sehr streng eingestellt.
Die eine API, die noch nicht geht, da habe ich beim Provider nachgefragt. Dieser sagt mir, dass die API nur reine https Technik und keine CDN's verwendet.
C# nativ am Server ausgeführt klappt ja, gleiche C# Logik ausgeführt am Dynamics 365 Server Dienst nicht.
Irgendwas muss Dynamics da nachladen, aber ich habe keinerlei Quelle/Idee wie man das dann finden soll.
Gerade bei API's, die Daten zur Laufzeit recherchieren und bereitstellen, macht ein CDN doch überhaupt keinen Sinn.
CDN's stellen doch näher am Client, statische Inhalte bereit.
Ich vermute mal, dass es mit den API's selbst eh nichts zu tun hat, sondern der Dynamics 365 Server je nachdem welche Subklassen im .Net angesprochen werden, irgendwas aus dem Internet laden möchte.
7. August 2024 13:36
Gollum83 hat geschrieben:...Ich vermute mal, dass es mit den API's selbst eh nichts zu tun hat, sondern der Dynamics 365 Server je nachdem welche Subklassen im .Net angesprochen werden, irgendwas aus dem Internet laden möchte.
Diese Versuche sollte man auf der Firewall aber erkennen können.
7. August 2024 16:59
danke Dir, sehe das auch so.
Dir IT vom Kunden sieht in den Anfragen aber keinen Unterschied.
Ich hätte auch gemeint, dass es irgendeinen Unterschied geben muss.
Für mich ist das alles eine Black Box...
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.