getluxed
Goto Top

Mobile Device Management hinter Nginx reverse Proxy

Hallo Zusammen,

ich habe ein MDM System aufgesetzt (Apptec um genau zu sein) und bin eigentlich relativ zufrieden damit, allerdings versuche Ich dieses hinter einem Nginx Reverse Proxy zu betreiben.

Die Ports 80,443 weiterzuleiten funktioniert auch einwandfrei, allerdings wird für das Android Rollout der Port 8080 auch verlangt. Nun zum eigentlichen Problem:
Mit Portweiterleitung and den MDM Server funktioniert es einwandfrei, mir wäre aber aus Sicherheit/Log Gründen lieber, diesen Port auch über den Proxy laufen zu lassen, allerdings führt das immer zu Fehlern.

Hat jemand hier Erfahrungen damit gemacht?

Ich habe die Portweiterleitung aufgesetzt wie jede andere auch und sogar invalid header zugelassen und websocket upgrade ausprobiert.
Der Error log sagt jedes mal nur:
"client sent invalid request while reading client request line, ..., request: "MDM ""

Danke im Vorraus

Content-ID: 667921

Url: https://administrator.de/contentid/667921

Ausgedruckt am: 21.11.2024 um 13:11 Uhr

godlie
godlie 05.09.2024 um 13:04:32 Uhr
Goto Top
Hallo,

wie hast du denn deinen nginx konfiguriert?

grüße
150631
150631 05.09.2024 um 13:54:35 Uhr
Goto Top
Und 8080 ist Webtraffic oder was?
GetLuxed
GetLuxed 05.09.2024 aktualisiert um 14:35:35 Uhr
Goto Top
Zitat von @150631:

Und 8080 ist Webtraffic oder was?

Im Handbuch steht IOS & Android kommunikation.


Zitat von @godlie:

Hallo,

wie hast du denn deinen nginx konfiguriert?

grüße

In die Richtung:
server {
    listen 8080 ssl;
    server_name ws.example.com;
    location / {
        proxy_pass https://localhost:8080; (Ja doppel ssl)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade; (funktioniert auch ohne diesen und nächsten header nicht)
        proxy_set_header Connection "upgrade";  
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    add_header X-Frame-Options "SAMEORIGIN" always;  
    add_header X-XSS-Protection "1; mode=block" always;  
    add_header X-Content-Type-Options "nosniff" always;  
    add_header Referrer-Policy "no-referrer-when-downgrade" always;  
    add_header Content-Security-Policy "default-src 'self' http: https: data: blob: 'unsafe-inline'" always;  

    proxy_read_timeout 300s;
    proxy_send_timeout 300s;

    access_log /var/log/nginx/ws.example.com.access.log;
    error_log /var/log/nginx/ws.example.com.error.log warn;
    ssl_certificate /etc/letsencrypt/live/ws.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ws.example.com/privkey.pem;
}
Dani
Dani 05.09.2024 aktualisiert um 17:31:07 Uhr
Goto Top
Moin,
könnte es daran liegen, dass auf dem Reverse Proxy und auf dem Backend nicht das selbe SSL-Zertifikat verwendet wird?!

Unabhängig davon wollen die vermutlich ihr Universal Gateway verkaufen wollen. face-smile


Gruß,
Dani
150631
150631 05.09.2024 um 17:36:04 Uhr
Goto Top
Ich fragte ob es eine Web-Kommunikation ist, wobei http(s) gemacht wird.
GetLuxed
GetLuxed 05.09.2024 um 17:36:36 Uhr
Goto Top
Zitat von @Dani:

Moin,
könnte es daran liegen, dass auf dem Reverse Proxy und auf dem Backend nicht das selbe SSL-Zertifikat verwendet wird?!

Unabhängig davon wollen die vermutlich ihr Universal Gateway verkaufen wollen. face-smile


Gruß,
Dani

Das mit dem Verkaufen kann ich mir gut vorstellen.
Selbe zertifikat hab ich nicht als mögliche Fehlerquelle erkannt. Ich werds die Tage mal probieren.
GetLuxed
GetLuxed 05.09.2024 um 18:38:43 Uhr
Goto Top
Zitat von @150631:

Ich fragte ob es eine Web-Kommunikation ist, wobei http(s) gemacht wird.

Ich bin mir nicht sicher worauf du hinaus willst bzw wie ich das checken kann. Es wird auf jeden fall mit ssl verschlüsselt. Ich hab jetzt nicht die Pakete gecheckt, was das genau für Anfragen sind.

Das hier steht im Administrationshandbuch dazu, was mir aber nichts für meine Frage bringt:
screenshot 2024-09-05 183633

Ich sehe keinen Grund warum port 8080 nicht durch einen rev-proxy funktionieren sollte und bin nicht so happy damit den Port für die ganze Welt zu öffnen und zu hoffen, dass die Ihr Produkt richtig sichern face-smile.
pebcak7123
pebcak7123 06.09.2024 um 11:04:15 Uhr
Goto Top
Würde einfach mal vermuten das es auf Port 8080 überhaupt kein http / https traffic ist.
Mal versucht das Nginx stream modul stattdessen zu nutzen ? nginx.org/en/docs/stream/ngx_stream_proxy_module.html
GetLuxed
GetLuxed 06.09.2024 um 12:03:10 Uhr
Goto Top
Das ist auch meine Befürchtung.
Stream Module funktioniert grad aus technischen gründen nicht (irgendwas mit letsencrypt, mir aber zu blöd zum debuggen) und würde mich auch keine waf dazwischen schalten lassen, da kann Ich gleich Portweiterleitung lassen.