Ubuntu vServer SSL mit Domain

[Hugo Stiglitz]

Hallo,
seit mehreren Tagen versuche ich auf meinen vServer SSL mit certbot zum Laufen zu bringen.

Aber irgendwie will es nicht.


Nach der Installation von Certbot rufe ich meine Domain auf www.beispiel.com welche auch richtigerweise auf https://www.beispiel.com umgeleitet wird. Nur ist keine Internetseite zu sehen. "Kann keine Verbindung aufbauen" schreibt der Browser jedes Mal.

Ich habe nun die error.log von apache einmal angesehen, da steht, dass er für tc8xxx.myvserver.online kein zertifikat finden kann.


Kurz zum Setup:
Der vServer ist unter seiner IP und unter xxx.myvserver.online erreichbar.

Eine separte Domain www.meinedomain.com leitete ich bisher einfach auf die IP des Servers um - und mit passenden VHOST funktionierte das auch alles prima.


Hat irgendjemand eine Idee?

 

[derchris]

Wie leitest du um?

 

[Hugo Stiglitz]

Im Menü vom Provider kann ich einstellen, wohin die Domain leiten soll. Da hab ich einfach die IP des vServers eingegeben... Funktionierte ohne SSL auch wunderbar.

Ergänzung (26. August 2019)

Edit:
Ich habe bei den Einstellungen der Domain auch seither nichts geändert.

Ich habe nur per SSH am Server cerbot installiert für den vhost, der den Namen meiner Domain hat.
Seither ist meine Seite nicht mehr erreichbar bzw. nur über die direkte IP Eingabe oder eben diesen Hostname xxx.myvserver.online..... mit der Domain funktionierts seit certbot nicht mehr.


im übrigen: ssl funktioniert bei direkteingabe der ip u hostname auch nicht.

 

[Hugo Stiglitz]

Sorry für Doppelpost - dachte das geht automatisch zum vorigen Eintag :-(

Okay, ich weiß mittlerweile, dass einfach nur der Port 443 geschlossen ist - dieser aber gelauscht wird.
Am vServer gibt es ufw nicht - weiß jemand wie ich den Port freischalten kann?

 

[snaxilian]

ufw ist auch nur ein Aufsatz für iptables, also prüfe bitte ob nftables/iptables ggf. noch falsch konfiguriert ist. Nächster Schritt: Läuft der Webserver (Apache oder Nginx?) bzw. ist dahingehend konfiguriert, dass er auch auf Port 443 lauschen soll?

 

[Hugo Stiglitz]

Apache läuft und ist so eingestellt, dass er 443 u. 80 lauschen soll.

Ich habe die letzten Tage wirklich viel recherchiert, wie das mit iptables funktionieren soll - aber bis jetzt hab ichs nicht geschafft. Der Server ist auf Port 443 geschlossen und nicht erreichbar.

Am Server läuft Ubuntu 16.04

 

[snaxilian]

Solche Probleme behebt man immer von OSI Layer 0 an aufwärts. Da du per SSH drauf kommst gehen wir mal davon aus, dass Layer 0 bis 3 funktioniert.

sudo iptables -L -n gibt dir alle aktuell konfigurierten Regeln aus. Ganz am Anfang siehst du die Chains (input, output, forward, etc...) und ihre Standardeinstellung. Chain input policy accept erlaubt prinzipiell alles eingehend außer innerhalb der Chain ist es verboten. Dann kann man die Firewall auch abschalten... Besser wäre ein chain input policy drop und innerhalb der chain sollte es dann zwei Regeln geben: accept tcp - 0.0.0.0/0 public.ip.des.servers tcp dst:80 und accept tcp - 0.0.0.0/0 public.id.des.servers tcp dst:443. Bonuspunkte wenn du noch ein passendes conn_track oder ctstate setzt (minimal unterschiedliche Einstellungsarten je nach Distribution). Damit du dich nicht aussperrst solltest du noch eine passende Regel für SSH setzen

Passt die Firewall (oder ist aus weil du es liebst wenn dein Server früher oder später in einem Botnet mitspielt), kommen wir zum Webserver.

https://ma.ttias.be/apachectl-linux-get-entire-apache-vhost-configuration-one-output/ zeigt dir beispielhaft, wie du dir die Config des Apache anzeigen lassen kannst. Stelle sicher, dass dort auch mindestens ein vHost existiert, der auf :443 laufen soll.
Wenn der Apache Service dann nach erfolgreicher Prüfung der Config neu geladen oder gestartet wurde, prüfe bitte ob der Apache Service auch auf Port 80 und 443 lauscht per sudo ss -tlpen. Dort sollte dann der SSH-Server auf :22 als auch der Apache2 mit :80 und :443 zu finden sein.

edit: Ist der Apache denn auch so konfiguriert, dass er deine Seite auch per SSL und auf Port 443 ausliefert oder liefert er deine Seite nur per http und :80 aus? Ist im vhost nur IP die umgeleitete Domain als virtual Hostname gesetzt aber nicht die, für die certbot das Zertifikat holen soll?

 

[Hugo Stiglitz]

Vielen Dank für deine Rückmeldung - aber ich habs nun irgendwie doch selbst hinbekommen.

Vielleicht kurz zur Problemlösung: Man muss sich einfach ein bisschen in iptables einlesen.... Die Lösung war einfacher als gedacht.


@snaxilian die UFW kann ich ja immer noch installieren, oder? Botnet ist mir ein Begriff :-O

 

[snaxilian]

Ja, da ufw nur ein Frontend für iptables ist um die Einrichtung für Laien zu vereinfachen. Ich persönlich bin jedoch von ufw kein Freund, da es eben neben den Regeln, die man selbst setzt noch einige weitere Regeln aktiviert, die man ggf. nicht unbedingt möchte. Man sollte daher nach Einrichtung per ufw die iptables Regeln prüfen und ggf. nicht erwünschtes wieder entfernen.

 

[Hugo Stiglitz]

Okay. Weiß man, ob die bisherige Konfiguration von iptables dann überschrieben wird?
Ich muss hier halt aufpassen, dass ich mir den SSH Zugriff nicht sperre sonst bin ich rausgesperrt...

Um den vServer ausreichend zu schützen - reicht ufw + Konfiguration aus?

Oder muss ich dann sämtliche Ports, Dienste, usw. wieder erneut einstellen?

 

[snaxilian]

Snapshot machen, installieren, testen, ggf. rollback. Keine Ahnung ob ufw bei nachträglicher Installation alle bestehenden Regeln raus schmeißt oder übernimmt. In der Regel werden aber bestehende Sessions nicht gekillt. Wenn du also per SSH verbunden bist kannst es installieren und dir dann ansehen solange du die Verbindung nicht trennst. Ansonsten gibt es ja noch bei den meisten Hostern eine Webkonsole wo man sich dann quasi lokal am Server anmelden kann oder spielt eben den erstellten Snapshot wieder ein.

Eine Firewall alleine reicht nicht, nein. Diese schützt dich nur gegen unabsichtlich/versehentlich geöffnete Ports. Ist Port 80/443 offen, geht Traffic durch wenn auf den Ports ein Dienst/Anwendung lauscht. Ist diese Anwendung aber unsicher konfiguriert oder hat eine Sicherheitslücke so hast du ein Problem.
Miese Webanwendung die eine Remote Shell oder SQL Injection erlaubt kann problemlos ausgenutzt werden, dafür brauche ich ja keine neuen oder andere Ports.