Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

gelöst Routing zu HTTPS in einer VPS geblockt ?

Mitglied: satosan

satosan (Level 1) - Jetzt verbinden

31.01.2019, aktualisiert 16:40 Uhr, 283 Aufrufe, 11 Kommentare

Hallo,

ich betreibe einen Linux Server der jeden Tag Daten zum Download von einer Domain zur Verfuegung stellt. Die Domain wurde mit LetsEncrypt zertifiziert und der Zugriff auf die Dateien ist per Request mit HTTP und HTTPS moeglich.

Die 'Kunden' requesten die Daten mit einem 3rd Party Tool, von dem ich keine Kenntnis habe wie der Datei-Request angestossen wird, leider immer nur mit HTTP. Dadurch wird die Anfrage stets mit 301 geroutet, da LetsEncrypt so konfiguriert ist, dass HTTP Requests auf HTTPS umgeleitet werden. Ich sehe dann das mit 200 bestaetigt und geloggt wird, dass die Datei gefunden wurde. Der Kunde kann die Datei downloaden. Soweit so gut und funktioniert auch sehr gut, fuer Kunden die die Requests nicht von einer VPS starten. Kunden die die Requests von einer VPS starten, werden zwar mit 301 auf HTTPS geroutet, jedoch bekomme ich keine 200 geloggt und bestaetigt und die Kunden bekommen auch die Datei nicht.

So sieht das Log bei mir aus wenn die Kunden aus der VPS den Download der Datei 1.txt requesten und kein 200 gelogt wird:

XX.XXX.XX.XXX- - [24/Jan/2019:06:37:06 +0100] "GET /data/a/b/c/1.txt?a=132618343.00000000 HTTP/1.1" 301 178 "-" "XXX_API"
XX.XXX.XX.XXX- - [24/Jan/2019:06:38:06 +0100] "GET /data/a/b/c/1.txt?a=132678031.00000000 HTTP/1.1" 301 178 "-" "XXX_API"

So sieht das Log bei mir aus wenn alle Kunden den Download der Datei 1.txt requesten und bei denen es funktioniert und 200 gelogt wird:

XX.XXX.XX.XXX- - [24/Jan/2019:06:37:06 +0100] "GET /data/a/b/c/1.txt?a=132618343.00000000 HTTP/1.1" 301 178 "-" "XXX_API"
XX.XXX.XX.XXX- - [24/Jan/2019:06:37:06 +0100] "GET /data/a/b/c/1.txt?a=132618343.00000000 HTTP/1.1" 200 40382 "-" "XXX_API"

Kann das daran liegen das der VPS PORT 443 blockt ? Ich habe mir dazu einen NMAP Scan erlaubt und bei allen wird er Port 443 als 'Filtered' angegeben. Jedoch auch bei den Kunden, bei denen es funktioniert. Blockt der Hoster denn auch nochmal mit seiner eigenen Firewall ? Das Betriebssystem der VPS scheint alles Windows Server XXXX zu sein.

Ich bin ratlos.

Wenn mir jemand einen Tip geben koennte woran es liegt bzw liegen koennte, waere ich sehr sehr dankbar.

Viele Gruesse


Sato
Mitglied: Exception
LÖSUNG 31.01.2019, aktualisiert um 22:46 Uhr
Hallo,

Ich habe mir dazu einen NMAP Scan erlaubt und bei allen wird er Port 443 als 'Filtered' angegeben.

von wo hast du gescannt? Du müsstest ja von den VPS scannen, d.h. du bräuchtest Zugriff auf den VPS.
Folglich müsstest du auch das Betriebsystem und das Tool kennen, mit dem versucht wird, eine Verbindung aufzubauen.
Dann könntest du das ganz einfach testen, indem du mit einem HttpClient den Request tätigst und schaust, was passiert.

Kunden die die Requests von einer VPS starten, werden zwar mit 301 auf HTTPS geroutet, jedoch bekomme ich keine 200 geloggt und bestaetigt und die Kunden bekommen auch die Datei nicht.

Handelt es sich um mehrere Kunden? Alle beim selben Provider?
Alle das selbe Tool bzw. HttpClient?

Blockt der Hoster denn auch nochmal mit seiner eigenen Firewall

Bei einem Provider (unmanaged) ist das normalerweise nicht der Fall. Manche Provider bieten den Kunden eine zusätzliche dedicated Firewall an. Das Regelwerk muss vom Kunden selbst bestimmt werden. Ansonsten filtert der Provider überhaupt nicht. Nur in besonderen Fällen z.B. bei Attacken. Bei besonders schwerwiegenden Fällen wird dann der VPS vom Netz genommen bzw. die IP wird ins Jenseits geroutet.


VG
Exception
Bitte warten ..
Mitglied: LordGurke
01.02.2019, aktualisiert um 01:59 Uhr
Die Symptome klingen für mich eher so, als wenn der HTTP-Client der Weiterleitung nicht folgt oder das Zertifikat nicht gegen seinen lokalen Zertifikatsspeicher validieren kann (und dann keine sichere Verbindung aufbaut).
Letzteres siehst du auch im Logfile normalerweise nicht, da ja bereits der Aufbau des TLS-Tunnels scheitert.

Mache doch mal auf deinem Server mit tcpdump eine Aufzeichnung des Traffics eines problematischen Clients (also dessen IP) und sieh dir an, was da auf der Leitung wirklich passiert und ob er wirklich versucht, per HTTPS bei dir zu verbinden.
Bitte warten ..
Mitglied: satosan
03.02.2019 um 20:56 Uhr
Hallo Exception,

vielen Dank fuer Deine Rueckmeldung.

von wo hast du gescannt? Du müsstest ja von den VPS scannen, d.h. du bräuchtest Zugriff auf den VPS.
Folglich müsstest du auch das Betriebsystem und das Tool kennen, mit dem versucht wird, eine Verbindung aufzubauen.
Dann könntest du das ganz einfach testen, indem du mit einem HttpClient den Request tätigst und schaust, was passiert.

Ich habe nicht von der VPS gescannt, sondern von meinem 'Platz' aus. So habe ich gesehen dass der HTTPS relevante PORT 443 als 'filtered' dasteht. Offene 443 PORTS auf anderen Maschinen werden mir von NMAP auch als 'open' ausgewiesen. Warum muss ich den Scan direkt von der VPS aus machen ?

Handelt es sich um mehrere Kunden? Alle beim selben Provider?
Alle das selbe Tool bzw. HttpClient?

Es sind nur VPS Kunden betroffen, die entweder bei STRATO, PHP-Friends aka First Colo und/oder einem italienischen Hoster das 'Problem' haben. Betriebssystem weiss ich momentan nur von einem Kunden, WS2012R2.

Bei einem Provider (unmanaged) ist das normalerweise nicht der Fall. Manche Provider bieten den Kunden eine zusätzliche dedicated Firewall an. Das Regelwerk muss vom Kunden selbst bestimmt werden. Ansonsten filtert der Provider überhaupt nicht. Nur in besonderen Fällen z.B. bei Attacken. Bei besonders schwerwiegenden Fällen wird dann der VPS vom Netz genommen bzw. die IP wird ins Jenseits geroutet.

Ok, danke fuer die Information bzgl. der Firewall. Ein Kunde mit dem WS2012R2 hat ja angeblich PORT 443 geoeffnet. Erscheint aber nach wie vor als 'filtered'

VG Sato
Bitte warten ..
Mitglied: LordGurke
03.02.2019 um 21:08 Uhr
Zitat von satosan:

von wo hast du gescannt? Du müsstest ja von den VPS scannen, d.h. du bräuchtest Zugriff auf den VPS.
Folglich müsstest du auch das Betriebsystem und das Tool kennen, mit dem versucht wird, eine Verbindung aufzubauen.
Dann könntest du das ganz einfach testen, indem du mit einem HttpClient den Request tätigst und schaust, was passiert.

Ich habe nicht von der VPS gescannt, sondern von meinem 'Platz' aus.
Das macht es mir noch nicht wirklich klarer von wo nach wo du scannst.

So habe ich gesehen dass der HTTPS relevante PORT 443 als 'filtered' dasteht. Offene 443 PORTS auf anderen Maschinen werden mir von NMAP auch als 'open' ausgewiesen. Warum muss ich den Scan direkt von der VPS aus machen ?

nmap zeigt dir nicht, ob Ports durchlässig sind sondern ob auf bestimmten Ports Verbindungen angenommen werden - dort also Serverdienste unter diesem Port erreichbar sind.
Wenn du z.B. deinen eigenen Internetanschluss zu Hause scannst, wird dir auch Port 443 als "filtered" oder "closed" angezeigt, einfach weil dort kein Dienst auf diesem Port lauscht und Verbindungen annimmt.
Ein nmap auf einen VPS, auf dem selber keine HTTPS-Webseiten gehostet werden, hat also auch keinen offenen Port 443.
Unabhängig davon wird dieser VPS mit hoher Wahrscheinlichkeit Port 443 ausgehend auf anderen Servern erreichen können.
Ein Portscan kann daher immer nur von Client -> Server erfolgen, umgekehrt bekommst du keine sinnvollen Ergebnisse.

Hast du denn mal mit tcpdump auf deiner Seite geschaut ob du von den Problem-Servern überhaupt Verbindungen auf Port 443 erhältst und - falls ja - was da so im Handshake passiert?
Ältere Linux-Systeme und neuere LetsEncrypt-Zertifikate mit fehlerhaftem Chain könnten z.B. zu TLS-Handshake-Fehlern führen, da der Client dem Zertifikat nicht vertraut und die Verbindung daher abgebrochen wird.
Bitte warten ..
Mitglied: satosan
03.02.2019 um 21:17 Uhr
Hallo LordGurke,

cooler Name btw. Lustig. Auch Dir vielen Dank fuer Deinen Kommentar.

Die Symptome klingen für mich eher so, als wenn der HTTP-Client der Weiterleitung nicht folgt oder das Zertifikat nicht gegen seinen lokalen Zertifikatsspeicher validieren kann (und dann keine sichere Verbindung aufbaut).
Letzteres siehst du auch im Logfile normalerweise nicht, da ja bereits der Aufbau des TLS-Tunnels scheitert.

Warum sollte der HTTP-Client der Weiterleitung auf einer Desktop-Umgebung (Windows 10 etc) folgen und auf einem Server-BS wie WS2012R2 oder WS2016 nicht?

Mache doch mal auf deinem Server mit tcpdump eine Aufzeichnung des Traffics eines problematischen Clients (also dessen IP) und sieh dir an, was da auf der Leitung wirklich passiert und ob er wirklich versucht, per HTTPS bei dir zu verbinden.

Ich kann sehen das er kein HTTPS versucht, sondern HTTP. Der HTTP-Client ist bei allen Kunden der gleiche und somit sollte die Anfrage auch die gleiche sein. Tcpdump habe ich noch nicht gemacht.

VG Sato
Bitte warten ..
Mitglied: LordGurke
03.02.2019 um 21:22 Uhr
Zitat von satosan:
Ich kann sehen das er kein HTTPS versucht, sondern HTTP. Der HTTP-Client ist bei allen Kunden der gleiche und somit sollte die Anfrage auch die gleiche sein. Tcpdump habe ich noch nicht gemacht.


Mach das mal
Wenn die HTTPS-Verbindung fehlschlägt, weil es ein Problem mit der Aushandlung gibt, wirst du keine Anfrage in deinem Log sehen.
Bitte warten ..
Mitglied: satosan
03.02.2019, aktualisiert um 21:32 Uhr
Hallo LordGurke,

meine Antwort hat sich mit Deinem neuen Kommentar ueberschnitten.

nmap zeigt dir nicht, ob Ports durchlässig sind sondern ob auf bestimmten Ports Verbindungen angenommen werden - dort also Serverdienste unter diesem Port erreichbar sind.
Wenn du z.B. deinen eigenen Internetanschluss zu Hause scannst, wird dir auch Port 443 als "filtered" oder "closed" angezeigt, einfach weil dort kein Dienst auf diesem Port lauscht und Verbindungen annimmt.
Ein nmap auf einen VPS, auf dem selber keine HTTPS-Webseiten gehostet werden, hat also auch keinen offenen Port 443.
Unabhängig davon wird dieser VPS mit hoher Wahrscheinlichkeit Port 443 ausgehend auf anderen Servern erreichen können.
Ein Portscan kann daher immer nur von Client -> Server erfolgen, umgekehrt bekommst du keine sinnvollen Ergebnisse.

Ok, ich habe morgen Zugriff auf die VPS und werde dann dort mal scannen.

Hast du denn mal mit tcpdump auf deiner Seite geschaut ob du von den Problem-Servern überhaupt Verbindungen auf Port 443 erhältst und - falls ja - was da so im Handshake passiert?

Die Verbindungen kommen grundsaetzlich alle ueber PORT 80 als HTTP. Mit den Clients die nicht in einer VPS laufen, klappt das Routing 301 und ich habe dann eine 2. Verbindung mit dem Client auf PORT 443. Das kann ich mit 'tcptrack' eindeutig sehen. Ich habe leider keinen Einfluss, dass der Client immer nur auf HTTP requested und nicht gleich HTTPS. Der Dev hat keinen Bock das zu aendern. Leider.

Ältere Linux-Systeme und neuere LetsEncrypt-Zertifikate mit fehlerhaftem Chain könnten z.B. zu TLS-Handshake-Fehlern führen, da der Client dem Zertifikat nicht vertraut und die Verbindung daher abgebrochen wird.

Warum sollte ein Client von einer VPS dem LetsEncrypt Certificate nicht vertrauen, ein Client auf Win10 oder Win7 schon ? Liegts am Betriebssystem ? Eventuell ein Server-Betriebssystem Problem ? Ein Kunde hat jedenfalls WS2012R2.

Danke nochmals

Sato
Bitte warten ..
Mitglied: LordGurke
03.02.2019, aktualisiert um 21:49 Uhr
Zitat von satosan:
Warum sollte ein Client von einer VPS dem LetsEncrypt Certificate nicht vertrauen, ein Client auf Win10 oder Win7 schon ? Liegts am Betriebssystem ? Eventuell ein Server-Betriebssystem Problem ? Ein Kunde hat jedenfalls WS2012R2.

Jaein...
Zertifikate werden von Root-CAs unterschrieben, die dem Betriebssystem bekannt sein müssen - sonst werden die Zertifikate nicht als vertrauenswürdig eingestuft und Verbindungen werden nicht aufgebaut.
Die Root-CAs von Let's Encrypt sind natürlich noch nicht in älteren Trust-Stores enthalten, was dann dazu geführt hätte, dass nur wenige Systeme den Zertifikaten vertraut hätten. Deshalb haben die für die Übergangszeit ein Root-CA zum Unterschreiben verwendet, welches von IdenTrust, einer lange existierenden Zertifizierungsstelle unterschrieben wurden, die auch in den meisten älteren Betriebssystemen vertraut werden.

Let's Encrypt unterschreibt die Zertifikate nun mit ihrer eigenen CA, die in den aktuellen Trust-Stores vorhanden ist und der vertraut wird (Zertifikate sind also gültig). Für Abwärtskompatibilität mit älteren Systemen muss ein Intermediate-Zertifikat (auch "Chain" genannt) mitgesendet werden, was von Let's Encrypt ebenfalls bereitgestellt wird. Das ist im wesentlichen das Root-CA von Let's Encrypt, aber zusätzlich von IdenTrust unterschrieben und damit für ältere Systeme, die zwar IdenTrust, aber nicht Let's Encrypt kennen, vertrauenswürdig.


Wenn der Trust-Store auf dem betreffenden Client-System nicht aktuell ist (also lange keine Updates installiert) und zusätzlich das Chainfile nicht korrekt ausgeliefert wird, führt das dann auf diesen Clients zu Zertifikatsfehlern.
Der Unterschied zwischen den Systemen kann also das Patchlevel sein

Du kannst ja mal deinen Server unter https://www.ssllabs.com/ssltest/ testen, insbesondere ob der Chain korrekt ausgeliefert wird.
Bitte warten ..
Mitglied: satosan
04.02.2019, aktualisiert um 10:53 Uhr
Danke fuer die Erklaerung.

Jetzt merke ich zum ersten mal, dass wenn ich im Browser zBsp die Domain mit http:// aber ohne 'www' eingebe das ich eine Meldung 'Performing TLS handshake to ....' bekomme und das ganze dann in 'Timed out' endet. Wenn ich die Adresse mit 'www. angebe, dann 'geht alles durch'. Ist dann entweder das Certificate unter Nginx nicht richtig installiert oder die Nameserver Konfiguration falsch ?

Requests kommen immer nur direkt unter http://Domain.com/.... und nicht http://www.Domain.com/.... rein. Da haette ich dann aber wieder die Frage, warum ginge das nur bei Clients auf einer VPS nicht ?

Danke nochmals.

Sato
Bitte warten ..
Mitglied: LordGurke
LÖSUNG 04.02.2019 um 09:35 Uhr
Sind die Nameserver-Einträge denn unterschiedlich?
Auch hinsichtlich eventuell vorhandener AAAA-Einträge, die dann nur auf Servern mit IPv6-Anbindung Ärger machen könnten?

Entferne notfalls alles für "www" und lege dafür einen CNAME auf "domain.com" an, dann hast du für beides identische Konfigurationen
Bitte warten ..
Mitglied: satosan
11.02.2019 um 17:12 Uhr
Hallo an alle die hier mitgeholfen haben das Problem zu finden. Leider ist es mir bis heute nicht gelungen, dass Problem in irgendeiner Form einzugrenzen. Ich konnte die VPS der Kunden jeweils beim entsprechenden Hoster 1:1 replizieren und hatte das Problem mit normalen Einstellungen nicht.

Wir haben es dann 'gelassen' und das System auf den alten Status umgestellt, da nicht jeder Kunde bereit war uns auf seine VPS zu lassen.

Besonderen Dank nochmal an LordGurke und Exception.

Sato
Bitte warten ..
Ähnliche Inhalte
E-Mail

Emails von linux vps auf windows vps übertragen

Frage von fisch56E-Mail5 Kommentare

Guten Tag allerseits, ich habe einen linux Server mit ubuntu als VPS, und einen VPS mit Wondows 2012R Auf ...

Windows Server

Anfängerfragen zu VPS

Frage von ITneulingWindows Server13 Kommentare

Hallo Community Ich habe ein paar Programme welche auf einen VPS (Windows Server 2012) laufen und hätte dazu ein ...

Exchange Server

VPS - Remotedektopverbindung - Audio - Soundkarte

Frage von andisauspExchange Server2 Kommentare

Hallo, ich habe einen VPS bei Contabo angemietet, den ich gerne für Audio- / Videoaufzeichnungen verwenden möchte. Leider hat ...

Outlook & Mail

S Mime Verschlüsselung mit VPS

Frage von m.zeiseOutlook & Mail

Hallo zusammen, folgende Situation habe ich. Bei uns steht ein Exchange 2010 Standard mit Outlook 2010 Clients. Eine Handvoll ...

Neue Wissensbeiträge
Windows 7

Windows 7 u. Server 2008 (R2) SHA-2-Update kommt am 12. März 2019

Information von kgborn vor 1 TagWindows 74 Kommentare

Kleine Info für die Admins der oben genannten Maschinen. Ab Juli 2019 werden Updates von Microsoft nur noch mit ...

Firewall
PfSense 2.5.0 benötigt doch kein AES-NI
Information von ChriBo vor 2 TagenFirewall2 Kommentare

Hallo, Wie sich einige hier erinnern werden hat Jim Thompson in diesem Aritkel beschrieben, daß ab Version 2.5.0 ein ...

Internet
Copyright-Reform: Upload-Filter
Information von Frank vor 4 TagenInternet1 Kommentar

Hallo, viele Menschen reden aktuell von Upload-Filtern. Sie reden darüber, als wären es eine Selbstverständlichkeit, das Upload-Filter den Seitenbetreibern ...

Google Android

Blokada: Tracking und Werbung unter Android unterbinden

Information von AnkhMorpork vor 4 TagenGoogle Android1 Kommentar

In Ergänzung zu meinem vorherigen Beitrag: Blokada efficiently blocks ads, tracking and malware. It saves your data plan, makes ...

Heiß diskutierte Inhalte
Hardware
IT-Werkzeugkoffer bis 50,- EUR
gelöst Frage von departure69Hardware40 Kommentare

Hallo. Ich bin als IT-Systembetreuer einer Gemeinde zusätzlich auch der IT-Systembetreuer einer Grund- und Hauptschule. Dort muß ich jedoch ...

Netzwerke
Verteilung von Programmdaten außerhalb des internen Netzwerkes
Frage von mertaufmbergNetzwerke24 Kommentare

Guten Morgen liebe Administratoren, ich versuche zurzeit eine möglichst sichere und einfache Lösung zu suchen, um ein Programmverzeichnis über ...

Netzwerkmanagement
Richtfunknetzwerk mit vielen Hops stabiler gestalten
Frage von turti83Netzwerkmanagement21 Kommentare

Hallo, in meinem Dorf habe ich vor ca. einem Jahr ein Backbone aufgebaut um die Nachbarschaft mit Internet zu ...

Hyper-V
Intel MSC Raid 5 Rebuild
Frage von DannysHyper-V19 Kommentare

Hallo Community, Ich habe einen Modul Server von Intel in Betrieb. Dort ist eine Festplatte aus dem Raid 5 ...