Serverwechsel - was zu beachten?

[maticze]

Hallo,

mal ne Frage:
Wir haben vor, von unserem aktuelen Dienstleister ein paar unwichtigere Domains abzuziehen und diese auf unserem eigenen root zu hosten.

Wie geht man da am geschicktesten vor?? Domains laufen über schlundtech und Server steht bei Schlund. Ich dachte ich lege zunächst alle Domains schonmal auf dem neuen Root an und richte auch schon die Mailaccounts ein.

Dann muß ich doch bloß noch die daten per FTP rüberschieben und bei Schlundtech die entsprechenden Einträge eingeben.

Habe ich nun irgendwas übersehen/vergessen/zu leicht vorgestellt?

Es sind alles statische Seiten, also ohne PHP/MySQl...

Dachte ich ziehe das an einem Wochenede durch, dann kann ich noch rumspeieln, falls was schiefläuft. Die Clients der Mailer wollen ja auch eingerichtet werden, da ja alle nun neue Passwörter bekommen...

Besten Dank schonmal für die Hilfe...

Gruß

[niemand]

Ich dachte ich lege zunächst alle Domains schonmal auf dem neuen Root an und richte auch schon die Mailaccounts ein.

Wäre es nicht sinnvoller, erst auf dem neuen Server alles zum Laufen zu bringen, die Daten mit dem alten Server abzugleichen und dann erst die DNS-Einträge zu ändern, damit es keine Unterbrechungen gibt? Bis alle DNS-Server die aktuellen Daten haben, dauert es sowieso eine Weile.

Als Anregung: Wenn ich eine größere Menge Systemdaten übernehmen will, schreibe ich mir ein kleines Import-/Exportscript und muss mich nicht mit hunderten Datensätzen rumärgern (ich weiß gerade nicht, was für dich "Clients der Mailer" sind).

cu

[mattiass]

Wir haben vor, von unserem aktuelen Dienstleister ein paar unwichtigere Domains abzuziehen und diese auf unserem eigenen root zu hosten.

Habe ich nun irgendwas übersehen/vergessen/zu leicht vorgestellt?

Im Prinzip ist die Vorgehensweise OK. Zum Testen empfiehlt sich ein Eintrag in der /etc/hosts Deines Arbeitsplatzrechners, der bereits auf den neuen Server zeigt. So kannst Du feststellen, ob die VirtualHost-Konfiguration auf dem Rootserver sauber ist.

[dante77]

Ich würde dringend dazu raten, beim Umzug auf einen eigenen Rootserver folgendes zu beachten:

1. Rootserver sind von Haus aus ungeschützt gegenüber Angriffen. Das heisst, es sollten jemanden geben, der auf dem Ding erstmal einen vernünftigen Firewall mit iptables konfigurieren kann und den SSH-Zugang absichert.

2. Genauso sollte es jemanden geben, der sich mit Mailserver-Administration auskennt. Die Schlund-Postfächer waren warscheinlich mit einem Spam-Filter versehen - die Postfächer auf Rootservern sind das erstmal nicht.

[mattiass]

1. Rootserver sind von Haus aus ungeschützt gegenüber Angriffen. Das heisst, es sollten jemanden geben, der auf dem Ding erstmal einen vernünftigen Firewall mit iptables konfigurieren kann und den SSH-Zugang absichert.

Ich weiss nicht, was Ihr alle mit "iptables" auf einem Rootserver habt. "iptables" sind ein guter Schutz um beispielsweise zu verhindern, dass eine per Perl-Script mit Rechten des Webservers gestartete Backdoor auf einem von ihr geöffneten Port eingehende Verbindungen annimmt. Sie versagt aber schon, wenn die Backdoor "pollt" also die für Sie bestimmten Befehle selbst per HTTP abholt.

"iptables" kann deshalb nur ein kleiner Baustein eines Sicherheitskonzeptes sein, jedenfalls keiner der so sehr hervorgehoben werden muss, wie Du das getan hast.

[dante77]

Meine zwei Punkte sollten keineswegs ein vollständiges Sicherheitskonzept darstellen. Aber ein vernünftig konfigurierter Paketfilter ist für mich nun mal der erste Schritt in Richtung Absicherung des Servers. Schlecht programmierte PHP- oder Perl-Skripte können einem dabei natürlich schnell in den Rücken fallen, das ist aber eine andere Baustelle.

Bei meinen Servern stellt der Paketfilter z.B. sicher, dass überhaupt nur ich eine Möglichkeit zum Login per SSH bekomme. Das lässt sich wunderbar über DynDNS lösen, sofern man nicht sowieso eine statische IP hat. Warum Angreifern überhaupt eine Möglichkeit zum Herumprobieren geben?

Vom Firewall mal abgesehen, laufen auf frisch verkauften Rootservern gerne Dienste wie FTP (was kein Mensch braucht) und ein MySQL, der auf Port 3306 fröhlich in alle Welt horcht und in den man sich mit "root" und ohne Passwort einloggen kann. Über derartige Dinge sollte man sich im klaren sein, wenn man einen Rootserver anschafft.

Will damit nur sagen, dass es mit "einfach mal schnell umziehen" nicht getan ist. Das geht u. U. solange gut, bis sich jemand mal genauer für den neuen Server interessiert.

[rootsvr]

Bei meinen Servern stellt der Paketfilter z.B. sicher, dass überhaupt nur ich eine Möglichkeit zum Login per SSH bekomme. Das lässt sich wunderbar über DynDNS lösen, sofern man nicht sowieso eine statische IP hat. Warum Angreifern überhaupt eine Möglichkeit zum Herumprobieren geben?

Welcher Server verfügt nicht über eine statische IP? für daheim, wo man nen NAT machen will um seinen HomePC via Linux ans Netz zu bringen ja klar, aber sonst?

Vom Firewall mal abgesehen, laufen auf frisch verkauften Rootservern gerne Dienste wie FTP (was kein Mensch braucht) und ein MySQL, der auf Port 3306 fröhlich in alle Welt horcht und in den man sich mit "root" und ohne Passwort einloggen kann. Über derartige Dinge sollte man sich im klaren sein, wenn man einen Rootserver anschafft.

Bei den Rootservern die ich kenne ist im Minimalimage nichtmal ein mysql drauf, installiert man den horcht er standardmäßig nicht auf 3306 sondern nur socket.

Ich stimme das mit MatthiasS überein, ein iptables kann helfen (hat mir auch schonmal auf nem HomeServer, generell macht man seinen Server sicher indem man nur installiert was man braucht und nicht einfach per iptables zumacht was läuft und was man nicht braucht.

Das man seinen Server kennen sollte ist klar.

[dante77]

Welcher Server verfügt nicht über eine statische IP? für daheim, wo man nen NAT machen will um seinen HomePC via Linux ans Netz zu bringen ja klar, aber sonst?

Ich meinte nicht die IP des Servers sondern des eigenen Internetzugangs. Da man hier in der Regel nicht über eine statische IP verfügt, kann man sich dennoch per DnyDNS-Dienst jederzeit eine temporär verschaffen. Einen entsprechenden Lookup ins iptables-Skript eingetragen und regelmäßigen Neustart von iptables per Cronjob vorausgesetzt, ergibt sich ein wirksamer Schutz gegen unerwünschte Zugriffsversuche. Eine Alternative wäre hier wohl nur Port Knocking.

Auch wenn manche das hier anders sehen mögen - ich ziehe es vor, den Datenmob schon am Gartenzaun zu stoppen und nicht erst an der Haustür.

[/quote]

[rootsvr]

Du bekommst mit dyndns keine statische IP nur einen mehr oder weniger festen Hostnamen.

Portknocking ist zwar nett, aber wenn man mal unterwegs ist, wie erzeugt man dann die Portknock sequenzen und in wie wiet ist das dann sicherer als wenn man ein korrekt konfiguriertes und sichers SSH auf Standardport hat?

Inwieweit DNSabfragen für iptables sinnvoll/performancefressend sind weiß ich nicht.

[maticze]

Hi,

so domains und mailadressen sind alle eingerichtet.

Thema Sicherheit: der rootserver wird von einem admin betreut, also patches, security, backup etc... ich verwalte "lediglich" domains, also lege diese an, erstelle die mailadressen etc...

Nun noch mal Thema mailserver:
Wenn die Domain bisher bei einem Dienstleister inkl. Mailserver lag und ich diesen umziehe, wie kann ich es vermeiden, dass E-Mails verloren gehen, wenn ich bei Schlundtech die IP umstelle. Bisher liefen diemails auf dem Mailserver auf und wurden mit Tobit abgeholt.

Ich dachte nun ich stelle alles beim neuen Server ein, lege die Mailadressen an wie beim vorherigen und warte dann mit der Umstellung beim Tobitsystem eine zeitlang. Dann sollten doch DNS aktualisiert sein und ich kann im Tobit den neuen mailserver und die neuen User einstellen (also Paswörter und logins) Oder mache ich mir das zu einfach?

Gruß und Danke mal wieder im Voraus