Hi,
Rootserver sind mittlerweile (leider) in aller Munde und es kann sich fast jeder einen “holen” wenn er im Monat ca. 19 Euro dafür ausgeben möchte.
Leider kommt hierbei häufig die Sicherheit und die Konfiguration etwas zu kurz.
Ich hatte ein ähnliches Problem und habe mich deswegen mit der ganzen Rootserver Geschichte beschäftigt.
Die Ergebnisse habe ich in meinem Wiki
www.schroedi.info
zum besten gegeben.
Es ist vielleicht nicht alles richtig, aber ich hoffe, dass die wesentlichen Sachen korrekt sind und weiterhelfen. Als Anfang durchaus brauchbar und bestimmt die entscheidende Hilfe für alle die gerne einen SPAMenden Mailserver oder gehackten Webserver vermeiden wollen
Viel Spaß beim testen, Fehler finden und hoffentlich auch korrigieren.
Wiki lebt vom mitmachen.
schroedi
Es scheint, als sei das ,,Abenteuer” noch nicht ganz vorbei, denn beim Aufruf deiner Seite erscheint:
Forbidden
You don’t have permission to access / on this server.
Apache/2.0.53 (Gentoo/Linux) mod_perl/1.99_17 Perl/v5.8.6 mod_ssl/2.0.53 OpenSSL/0.9.7e PHP/4.3.11 Server at http://www.rootserverbuch.de Port 80
Also nochmal zurück in den Dschungel, Indianer Jones ;)
gefixt…. Update Problem :-(
schroedi
[1] http://www.schroedi.info
Hallo schroedi,
die erste Anmerkung:
Forbidden
You don’t have permission to access / on this server.
Apache/2.0.53 (Gentoo/Linux) mod_perl/1.99_17 Perl/v5.8.6 mod_ssl/2.0.53 OpenSSL/0.9.7e PHP/4.3.11 Server at http://www.rootserverbuch.de Port 80
Sehr sicher muß ich sagen!!
man kommt nicht drauf :)
Gruß Pepsi
Ein grundlegendes Problem besteht darin, dass oft schon in der Defaultkonfiguration viel zu viel installiert wird und vor allem weniger erfahrene Admins alles an Software hinzu packen, was sie irgendwann mal benötigen könnten, oder wenn auch nur der Paketname vielversprechend klingt. Einige Rootserver enthalten komplett lauffähige KDE- oder GNOME-Installationen, inkl. OpenOffice, Firefox, aufwändigen Spielen, X-Server und grafischem Login. Diese sind erfahrungsgemäß meist die ersten, die von 1337 h4x0rZ 0wn3d werden, und erreichen selten Uptimes von mehr als einem Monat. Nach wie vor kann ich nur dazu raten, kein Paket zu installieren und kein Konfigurations-Feature zu aktivieren, das nicht wirklich gebraucht… Mehr »
Sicherlich empfehlenswert, ich habe im Grunde auch so damit angefangen. Ich
hätte da aber noch ne Frage zu Debian. Ich brauch keinen Mailserver auf der
Kiste, aber es muß ja immer ein MTA installiert z.B. für Systemmails an die
User. Wie löst man das am sichersten? Gibt’s was anderes als einen nehmen, den
nicht richtig zu konfigurieren (funktioniert also nicht nach außen) oder zur
Not noch ne Regel davorzuschieben, die die betreffenden Ports dicht macht?
Und nebenbei: Grafische Oberflächen sind sowieso nix für
Unix/Linux-Systeme. ;)
Hups, da ist mir ein Fehler passiert. Grafische Oberflächen sind natürlich etwas für Linux-Systeme, gemeint war dass genannte auf Rootservern nichts zu suchen haben sollten.
Wenn du Systemmails haben willst (z.B. Logwatch oder auf Webservern häufig auch skriptgenerierte Mails nach draußen), würde ich einen MTA nehmen, den du gut kennst bzw. dessen Konfigurationslogik dir möglichst schnell einleuchtet (gerade wenn du eben nicht viel damit machen willst).
Anschließend relaying komplett abschalten und nur lokal generierte Mails zulassen. Nachdem diese Konfiguration sicher ist (als ersten Anhaltspunkt gibt es hier die div. Relay-Testing-Dienste), schalte den Paketfilter ein, so dass Port 25 etc. nicht mehr erreichbar sind.
fs
Exim4 auf Debian Sarge lässt sich recht einfach so konfigurieren, dass er nur noch auf dem Loopback-Interface lauscht. Mails nach draußen kann man dann immer noch verschicken aber von außen angreifbar ist er damit nicht mehr.
Günter
Exim kannst Du sogar komplett stoppen! Dann nimmt er überhaupt keine Mails
mehr über das Netz entgegen (und braucht noch nicht mal Ressourcen;-) und
liefert trotzdem lokal mit dem sendmail-wrapper versendete (also z.B. alles
was mit dem mail-Befehl verschickt wird) aus.
Ich brauch keinen Mailserver auf der Kiste, aber es muß ja immer ein MTA installiert z.B. für Systemmails an die User. Aber dieser MTA muss nicht an den öffentlichen Port 25 gebunden werden. 127.0.0.1:25 tut’s vollkommen. Dann ist der MTA von außen nicht erreichbar. Dito für Datenbanken und andere Scherze. BTW ist man für den SSH-Dienst (sofern nicht öffentlich angeboten) keineswegs auf Port 22 festgenagelt. Verlegt man diesen auf irgendwo im oberen Bereich (z. B. 35313), findet kein Passwort-Rate-Wurm den SSH-Dienst, und im Logfile herrscht himmlische Ruhe. ;-) Nur beim Einloggen hat man mit ssh -p 35313 $user@$host minimal mehr… Mehr »
Hallo DocSnyder!
BTW ist man für den SSH-Dienst keineswegs auf Port 22 festgenagelt. Verlegt man diesen auf irgendwo im oberen Bereich (z. B. 35313), findet kein Passwort-Rate-Wurm den SSH-Dienst, und im Logfile herrscht himmlische Ruhe. ;-) Nur beim Einloggen hat man mit ssh -p 35313 $user@$host minimal mehr Tipparbeit.
Nicht mal die Tipparbeit musst Du Dir machen. Lege auf dem Clinet eine Datei ~/.ssh/config an, mit folgendem Inhalt: Host $host Port 35313
Und schon kannst Du Dich wieder mit ssh $user@$host einloggen.
Harald