Guten Morgen So langsam wird mir mein Webspace zu eng und ich würde mich gerne mit einem VServer veruchen (bzw habe mir schon einen V30 bei Strato geklickt). Meine Domains liegen ja alle bei All-Inkl und können wegen mir auch dort bleiben. "Verlinkt" bekomme ich das ja recht simpel über den A-Record der Domain. Aber ich habe noch ein paar weitere Anfängerfragen: 1.) Aufrufe sollen nur über https erfolgen dürfen. Dazu habe ich bei AllInkl LetsEncrypt Zertifikate installiert. Das ist einfach und kostenlos. Kann das auch so gemacht werden, wenn die Domain auf einen externen Server zeigt? Auch mit Subdomains? 2.) Auf dem VSerser ist Plesk installiert und das ist natürlich sehr verlockend, aber auch nervig, denn viele Erweiterungen (Docker) sind kostenpflichtig (5(!)€/mtl). Da ich aber keine Domain über Plesk angelegt habe, kann ich ja eigentlich gar nichts damit anfangen, oder? Mailkonten und Subdomains mache ich ja, wie bisher, bei AllInk wo die Domains liegen. 3.) Wie können Subdomains auf verschiedene Services umgeleitet werden? Z.B. von cloud.server.de auf die mittels Docker installierte Nextcloud. Danke schon mal fürs Lesen und n lieben Gruß vom Schreibtisch P.S. Da ich bestimmt nicht der erste Mensch bin, der sich diese Fragen stellt: Links zu guten Anleitungen helfen mir natürlich auch. Gefunden habe ich zu so konkreten Fragen aber leider keine konkreten Antworten.
Kolja L. schrieb: > 1.) Aufrufe sollen nur über https erfolgen dürfen. Dazu habe ich bei > AllInkl LetsEncrypt Zertifikate installiert. Das ist einfach und > kostenlos. > Kann das auch so gemacht werden, wenn die Domain auf einen externen > Server zeigt? Wenn du per A-Record auf den V-Server zeigst musst die Zertifikate auch auf dem V-Server installieren. Kolja L. schrieb: > Auch mit Subdomains? Let's Encrypt macht seit einiger Zeit auch Wildcard-Zertifikate falls du das meinst. Kolja L. schrieb: > 3.) Wie können Subdomains auf verschiedene Services umgeleitet werden? > Z.B. von cloud.server.de auf die mittels Docker installierte Nextcloud. Reverse-Proxy lautet hier das Stichwort. z.B. mit nginx. Ein (zufällige herausgegriffener) Beispiellink: https://blog.linuxserver.io/2017/11/28/how-to-setup-a-reverse-proxy-with-letsencrypt-ssl-for-all-your-docker-apps/
moep schrieb: >> Wie können Subdomains auf verschiedene Services umgeleitet werden? >> Z.B. von cloud.server.de auf die mittels Docker installierte Nextcloud. > > Reverse-Proxy lautet hier das Stichwort. z.B. mit nginx. Wer eine Domain verwaltet, kann unter anderem auch alle DNS Records für Sub-, Subsub-, usw. domains verwalten. In meinem fall bin das ich, in deinem fall aber dein Registrar / DNS-provider. Der kann widerum künstliche Einschränkungen machen. Wenn die A-records alle auf den selben server zeigen, dann braucht man dort aber wirklich eine art Proxy, um die zu unterscheiden. HTTP hat den Host header, TLS/SSL hat SNI. Mit denen geht das meistens, aber halt nicht für alles. moep schrieb: > Kolja L. schrieb: >> Auch mit Subdomains? > > Let's Encrypt macht seit einiger Zeit auch Wildcard-Zertifikate falls du > das meinst. Auch direkt Subdomains gehen, wird aber schnell unübersichtlich. Für wildcard certs muss man die DNS basierte challange nehmen, die ist eventuwll etwas komplexer aufzusetzen. Man muss dafür nen bestimmten DNS record automatisch setzen können. Bei Wildcards ist noch zu beachten, dass es da einen scope-mismatch zwischen DNS und Certs gibt. Bei certs geht das nähmlich nur für eine subomain ebene, während DNS da beliebig weit runter geht.
Hallo Moep Danke für die Antworten, das bringt schon etwas Klarheit. Zumindest weiß ich in welche Richtung ich weiter lernen muss. Also CA für die Domain erstellen, Domain mittela A-Record auf Server-IP leiten, auf dem Server CA erstellen. Wie die beiden CA zusammenkommen finde ich schon noch raus. Ist es, für nicht-Konsolen-Nuter wie mich, sinnvoll Software wie Virtualmin oder Webmin zu nutzen? Bei AllInkl gibt es, glaube ich, keine Windcard Zertifikate von LetsEncrypt. Reverse-Proxy ist eins dieser Stichworte, die ich brauche um mehr zu lesen, danke! Zum allgemeinen Vorgehen: Server läuft, Docker ist über SSH installiert, Plesk lasse ich erstmal außen vor. Nächste Schritte: Server absichern: fail2ban, sshguard, UFW installieren und neuen User mit Root-Rechten erstellen Schaffe ich alles über die Konsole, aber über Webmin o.ä. wäre es mir lieber.
Kolja L. schrieb: > Ist es, für nicht-Konsolen-Nuter wie mich, sinnvoll Software wie > Virtualmin oder Webmin zu nutzen? Nein. Sinnvoll ist’s, sich mit dem Kram vertraut zu machen, den man da betreiben will. Idealerweise bevor man ’nen (v)Server überhaupt mietet. In ’nem anderen Forum, zu einer der von mir bevorzugten Distributionen, erscheinen recht regelmäßig Threads zu Problemen, die von solcher Software verursacht wurden. Oft genug läuft’s auf Neuinstallation hinaus, weil die Software richtig was verkackt hat. Abgesehen davon ist’s ein beliebtes Angriffsziel – gerade Webmin glänzt da dann öfter mal. Leute, die sich damit nicht auskennen, schieben’s dann aber auf die Distribution („xxx ist total instabil, muss man dauernd neu installieren – und unsicher ist’s auch, wird bei mir immer aufgemacht!“), und das ist höchst bedauerlich. Linuxkisten werden nunmal sinnvollerweise über die Shell bedient. Wenn du was zum Rumklicken haben musst: es gibt auch Windows Server – das ist genau dafür ausgelegt.
Kolja L. schrieb: > Also CA für die Domain erstellen, Domain mittela A-Record auf Server-IP > leiten, auf dem Server CA erstellen. > Wie die beiden CA zusammenkommen finde ich schon noch raus. Mit CA meinst du vermutlich das Zertifikat für die Domain. Die CA (Certificate Authority, Zertifizierungsstelle) ist in dem Fall Let's Encrypt, also derjenige der dir dein Zertifikat ausstellt. Wenn du später alle Dienste auf deinem V-Server hast und die Domain per A-Record auf den Server umleitest brauchst du beim Domainanbieter (AllInk) kein Zertifikat erstellen. Nur auf dem Server der auch tatsächlich den Dienst anbietet. Die Frage wie die beiden zusammenkommen stellt sich also nicht :) Somit auch nicht, ob es bei AllInk Wildcard-Certs gibt oder nicht.
Kolja L. schrieb: > Bei AllInkl gibt es, glaube ich, keine Windcard Zertifikate von > LetsEncrypt. Für LetsEncrypt Zertifikate bist du nicht wirklich auf AllInkl angewiesen (Sofern die nicht stillschweigend CAA Records anlegen.). Die Domain selbst kann man nicht mit einem Zertifikat schützen. Es sind in der regel TLS/SSL Verbindungen zum Zielserver, die mit Zertifikaten geschützt werden, das Zertifikat braucht nur der Zielserver. Für normale Zertifikate mit Webchallange ist das sehr einfach, die meisten ACME Clients können Webserver automatisch so konfigurieren, dass die Challange und die Zertifikate gehen. Wildcards sind etwas aufwendiger. Für Wildcard Zertifikate musst du nur automatisiert einen TXT Records für _acme-challenge.deine-domain.tld setzen können. Die Möglichkeiten, die AllInkl bietet, scheinen ausreichend zu sein, um Wildcardzertifikate zu erlangen. Ich sehe zwar gerade keine gute API, um direkt einen TXT record zu setzen, aber A und NS sind wohl möglich. Das macht es zwar etwas komplexer, sollte aber ansonsten kein Problem sein, man kann da nämlich für _acme-challenge.deine-domain.tld den Zielserver DNS Server spielen lassen, und den TXT dann dort automatisch updaten. Das wäre dann:
1 | ns1.meinedomain.tld. A 11.22.33.44 ; Glue record. Mit IP für Zielserver ersetzen |
2 | _acme-challenge.deine-domain.tld NS ns1.meinedomain.tld. ; Wir kümmern uns selbst um die Zone |
Auf dem Zielserver könnte man dann bind9 installieren, als authoritativen Server einrichten, eine Zohne für _acme-challenge.deine-domain.tld anlegen, je nach dem wie mans' updated DNS Zohne Updates für aktivieren, einen ACME Client, der das unterstützt installieren, und das wärs eigentlich, der liefert dann die Zertifikate. Jack V. schrieb: > Abgesehen davon ist’s ein beliebtes Angriffsziel – gerade Webmin glänzt > da dann öfter mal. Für Interne, Private & Administrative Software, die potentiell Sicherheitslücken haben könnte, mach ich das Folgendermaßen: Zuerst kommt ein Webserver*, der nur Loadbalancing, Reverse Proxy und Authentifizierung macht. Der leitet dass dann auf die anderen Webserver* weiter, die nicht direkt von aussen erreichbar sein sollten. Öffentliches und Privates kommen nicht auf den selben Webserver*. Resultat ist dann, dass mir Misskonfigurationen bei dem Webserver* für Privates zeug egal sein können, weil ja zuerst ein Login beim Webserver* für die Authentifizierung nötig ist, bevor man überhaupt zu dem kommt. Einfach daran denken, die Firewall / iptables regeln zuerst einzurichten. * Die Software, nicht die Hardware
Kolja L. schrieb: > Zum allgemeinen Vorgehen: > > Server läuft, Docker ist über SSH installiert, Plesk lasse ich erstmal > außen vor. > Suboptimal, es ließt sich zwischen den Zeilen so als würdest du da von Hand Dinge installieren. die meisten Server sind kein Selbstzweck und wenn du oder jemand anderes in ein paar Monaten/Jahren, den Server neu aufsetzen will/muss, geht das große Rätselraten los was wurde denn gemacht? ich Empfehle dir mal nach "Pets and Cattles" zu googlen (vielleicht mit Devops, zusätzlich), wichtig ist das du alle Änderungen an deinen Server nachvollziehbar machst, damit du im zweifel Nachts um 3 nach einer durchgemachten Nacht den Server in endlicher Zeit neu aufsetzen kannst. Kolja L. schrieb: > > Schaffe ich alles über die Konsole, aber über Webmin o.ä. wäre es mir > lieber. Frei nach Loriot, "vielleicht stimmt mit deinem Gefühl etwas nicht" ;) Mal ernsthaft unter Unix/Linux hat die Konsole eine alte Tradition und der Vorteil, ist das man Dinge die man in der Konsole kann, auch ganz schnell in ein Script/Programm gießen kann, so das die Langweiligen Tasks schnell Automatisiert sind. Ich kann dir nur wärmsten empfehlen dich darauf einzulassen. Abgesehen davon braucht man für eine GUI noch 2 dutzend zusätlicher Pakete welche im zweifel Sicherheitslücken aufreißen die man sonst nicht hat. Kolja L. schrieb: > Nächste Schritte: > Server absichern: fail2ban, sshguard, UFW installieren und neuen User > mit Root-Rechten erstellen Die Idee ist gut. Ich empfehle als erstes alles zu deinstallieren, was du nicht brauchst. (Ist machmal Tricky zu erkennen ob man es braucht). Dann den ssh Deamon auf Key only Access umstellen. was Vermutlich mehr bringt als ein sshguard, nicht das der nicht auch zusätzlich eine gute Lösung ist. Ob UFW was bringt weiss ich nicht. Ist wahrscheinlich besser als nichts aber ich neige dazu meine NFT Firewall lieber selbst zu Konfigurieren, das ist kein Hexenwerk. Denn neuen Nutzer mit root rechten, halte ich für keine Gute Idee, das ist eher "security by obscurity", ich würde ausgewählten Benuzter die Möglichkeit geben via sudo oder su, root zu werden und den ssh Server so Konfigurieren das root sich gar nicht anmelden darf. Und danach solltest du dich mit capabilities and hardeing beschäftigen um die Services welche du betreibst so sicher wie möglich zu bekommen.
Guten Abend Danke für die ganzen Beiträge, jetzt bin ich wieder um ein paar Fragen reicher. Jack V. schrieb: > Sinnvoll ist’s, sich mit dem Kram vertraut zu machen, den man da > betreiben will. Genau das habe ich ja vor und wenn es um DNS und SSL geht, bringt mir mein Rechner im Heimnetzwerk oder ein per dynamicher IP aufrufbarer Rechner nicht viel. Dafür habe ich mir jetzt den VServer gemietet. DPA schrieb: > Es sind in > der regel TLS/SSL Verbindungen zum Zielserver, die mit Zertifikaten > geschützt werden, das Zertifikat braucht nur der Zielserver. Danke, der Hinweis war notwendig und hilfreich. DPA schrieb: > Für Wildcard Zertifikate musst du nur automatisiert einen TXT Records > für _acme-challenge.deine-domain.tld setzen können. Die Automatisierung nur aus Bequemlichkeit, damit das Zertifikat nicht bei jeder Subdomain einzeln eingepflegt werden muss? Für wildcards von LetsEncrypt habe ich hier eine Anleitung gefunden: https://www.techox.de/blog/debian-9-wildcard-ssl-zertifikat-von-lets-encrypt/ DPA schrieb: > Zuerst kommt ein Webserver*, der nur Loadbalancing, Reverse Proxy und > Authentifizierung macht. Der leitet dass dann auf die anderen Webserver* > weiter, die nicht direkt von aussen erreichbar sein sollten. Das klingt einleuchtend. Also der erste Server (wie oben genannt z.B. nginx) nimmt die Anfragen an und leitet diese, je nach Subdomain in der Anfrage, an das entsprechende Verzeichnis auf dem zweiten Webserver (gerne Apache) weiter und dieser verarbeitet die Anfrage dann. Loadbalancing wird wohl ehr nicht notwendig sein... Imonbln schrieb: > Suboptimal, es ließt sich zwischen den Zeilen so als würdest du da von > Hand Dinge installieren. Ja, wie auch sonst? Imonbln schrieb: > Mal ernsthaft unter Unix/Linux hat die Konsole eine alte Tradition und > der Vorteil, ist das man Dinge die man in der Konsole kann, auch ganz > schnell in ein Script/Programm gießen kann, so das die Langweiligen > Tasks schnell Automatisiert sind. Alles was ich bisher gemacht habe, bzw was ich macher werde, wird natürlich dokumentiert. Dab mich n Keks gefreut, als ich diese Datei gefunden habe: ~/.bash_history Imonbln schrieb: > Abgesehen davon braucht man für eine GUI noch 2 > dutzend zusätlicher Pakete welche im zweifel Sicherheitslücken aufreißen > die man sonst nicht hat. Imonbln schrieb: > Ich empfehle als erstes alles zu deinstallieren, was > du nicht brauchst. Mehr Pakete sind immer größeres Risiko, aber bevor ich anfange bekannter Software zu misstrauen, oder Pakete zu deinstallieren, werde ich dieses Risiko wohl eingehen müssen. So, jetzt erst mal was essen. Gruß Kolja
Kolja L. schrieb: > DPA schrieb: >> Für Wildcard Zertifikate musst du nur automatisiert einen TXT Records >> für _acme-challenge.deine-domain.tld setzen können. > Die Automatisierung nur aus Bequemlichkeit, damit das Zertifikat nicht > bei jeder Subdomain einzeln eingepflegt werden muss? > > Für wildcards von LetsEncrypt habe ich hier eine Anleitung gefunden: > https://www.techox.de/blog/debian-9-wildcard-ssl-zertifikat-von-lets-encrypt/ Zertifikate laufen irgendwann ab. Die, die von LetsEncrypt ausgestellt werden, tun das momentan nach je 90 Tagen. Man sollte sie erneuern, bevor das passiert. Ich mach das automatisiert einmal pro Monat. Da ständig von neuem wieder dran denken zu müssen, und manuell den Eintrag anlegen zu müssen, wäre mir auf dauer zu umständlich. Und falls dabei was schief geht, lass ich das System mir ne mail schicken.
Nabend DPA Das mit der Gültigkeit war mir nicht mehr bewusst. Für Domains bei AllInkl kann ein Häkchen bei "automatisch erneuern" gesetzt werden. Jetzt weiß ich zumindest, schon mal was dahinter steckt. AkkInkl hat eine API, von der ich schon oft Gutes gehört, aber sie noch nie selbst angewendet habe. Eine schnelle Suche ergab das hier:
1 | add_dns_settings(array $parameter) |
2 | folgende Parameter sind möglich: |
3 | kas_login: das betreffende KAS Login |
4 | kas_auth_data: die Authentifizierungsdaten |
5 | kas_auth_type: der Authentifizierungstyp |
6 | zone_host: die betreffende Zone |
7 | record_type: der TYPE des Resource Records (MX,A,AAAA usw) |
8 | record_name: der NAME des Resource Records |
9 | record_data: die DATA des Resource Records |
10 | record_aux: die AUX des Resource Records |
https://kas.all-inkl.com/schnittstelle/dokumentation/phpdoc/packages/API%20Funktionen.html Und ich bin bestimmt nicht der erste, der diese Funktion benötigt. Da wird sich schon was finden. Gruß Kolja
Kolja L. schrieb: > Genau das habe ich ja vor und wenn es um DNS und SSL geht […] … gibt’s noch wirklich viele Dinge zu lernen, bevor man sich darum kümmern muss. Dann stellten sich auch so Fragen nach Webmin oder Schlimmerem nicht mehr. Aber gut, was weiß ich Noob schon. Fahre ja auch erst seit neunzehn Jahren Server :)
:
Bearbeitet durch User
Webmin ist bei mir schon lange wieder rausgeflogen... Ich bin auch nicht bei AllInkl - sondern hab meine Domains bei INWX.de. Mit der API lässt sich sogar eine DynDNS realisieren. LetsEncrypt funktioniert auch tadellos - wobei ich da in Zukunft ein wenig ändern muss, mit den Subdomains wirds wirklich unübersichtlich, aber Wildcard will ich auch nicht. :D - Vielleicht werde ich von Virtual-Domains für nginx auf separate Einträge in der config übergehen. - Unübersichtlich wird es (bei mir!) zumindest nicht. Den restlichen Tips bzgl. erst auseinandersetzen, dann mieten, dann hardening, kann ich mich voll anschließen. Dazu kannst du z. B. in deinem Netz erstmal nen DNS-Server aufsetzen, als Forwarder für alles, außer einer "Testdomain", für die der DNS authoritativ ist. - Darunter trägst du dann IPs für die "server" ein Diesen Server kannst du dann nach belieben testen und mit Pentests befeuern, und wenn alles nach deiner Zufriedenheit läuft, das Setup auf den VServer übertragen. - So läufst du auch erstmal keiner Gefahr der Kompromitierung des Systems, da es Anfangs eh nur aus deinem Netz erreichbar ist. ;) Ich denke, wenn du nett fragst, kann dir der ein oder andere bei spezifischen Problemen auch via PN Antworten, sofern es etwas sensibleres ist, was du nicht veröffentlichen willst. - Jeder Serverbetreiber mag es, wenn er weniger "Ziel" von Bots ist, um die er sich vielleicht kümmern muss ;)
Kolja L. schrieb: > AkkInkl hat eine API, von der ich schon oft Gutes gehört, > aber sie noch nie selbst angewendet habe. Oh, ja, das sieht gut aus. Damit müsste es machbar sein. Ich schau mir das morgen mal genauer an. Scheint hinten dran ein WSDL zu sein[0], mit nur einer methode, die eigentliche API mit nem JSON aufruft. Etwas ungewöhnlich, da hätten die gleich ne richtige REST Schnitstelle bauen können. Sollte aber ansonsten kein Problem sein. 0) https://kasapi.kasserver.com/soap/wsdl/KasApi.wsdl
Imonbln schrieb: > ich Empfehle dir mal nach "Pets and Cattles" zu googlen (vielleicht mit > Devops, zusätzlich), wichtig ist das du alle Änderungen an deinen Server > nachvollziehbar machst, damit du im zweifel Nachts um 3 nach einer > durchgemachten Nacht den Server in endlicher Zeit neu aufsetzen kannst. Ach dieser Devops scheiß :-) Für gewisse Szenarien ist der Ansatz ja sogar ganz gut, aber dann muss es auch wirklich durchdacht aufgesetzt werden. Hatten gerade ein ganz "tolles" Projekt dazu beim AG. Ein Devops Superhero wurde eingestellt, hat jetzt >1 Jahr Zeit verbracht und sich immer weiter in irgendwelche Devops-Kapriolen mit immer neuen Tools verrannt um eine 1000% Lösung zu schaffen, anstatt mal ein Ergebnis zu liefern das zumindest 70% brauchbar gewesen wäre. Achja, er hat jetzt gekündigt. Wenn man mal davon ausgeht, dass auf dem Server auch irgendwelche relevanten Daten liegen, wäre doch vlt. ein Backup sinnvoller? Ja ich weiß, ist völlig out und "old school", kein Devops-Buzzword-Bingo etc. Aber habe gehört es soll sogar funktionieren.
Ich bin ja nicht so ein Fan vom Scripting mit php, ich finde das etwas overkill. In Anhang ist mal ein versuch von mir, die Schnitstelle mit python3 anzusprechen, um einen TXT Record anzulegen. Getestet hab ich es zwar nicht, aber ich glaube es müsste eigentlich so ungefähr passen. kas.py implementiert sich um den API spezifischen kram, und main.py nutzt kas.py um die API anzusprechen. Ich hab hier jetzt mal keine SOAP Libraries oder dergleichen genommen, es erschien mir ein wenig Overkill zu sein, wenn man beachtet, dass das da im Grunde sowieso nur ein JSON in ein XML gepackt wird. Es ist zwar noch zu beachten, dass es einen DNS Record mehrfach mit unterschiedlichem Wert geben kann, eventuell muss man da also neben dem Hinzufügen noch das Abfragen, updaten und Löschen von DNS Records anschauen. Falls das funktioniert, müsste man das nur noch mit einem geeigneten ACME Client verheiraten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.