RootForum Community

Hallo,

ich habe einen Debian5 Minimal Vserver mit Apache2, PHP5, MySQL5 und Proftpd konfiguriert.
Nun möchte ich eine einfache Aufgabe lösen:

Alle Mails an mail@domain.de sollen an xyz@gmx.de weitergeleitet werden,
Alle mails an post@domain.de sollen z.B. an xyz@yahoo.de weitergeleitet werden.
Der Vserver soll keine Mails speichern, kein Webmail bereitstellen, kein Pop3 oder Imap.

Die Aufgabe ist entweder so einfach oder ich sehe den Wald vor Bäumen nicht, aber ich habe Stunden gegoogelt und finde keine passende Anleitung.
Meine Linux-Kenntnisse sind rudimentär, d.h. ich bräuchte Schritt-für-Schritt die Befehle, die ich auf der Konsole eingeben muss.
Exim ist soweit ich weiß nicht installiert - aber wenn es eine ganz einfache Lösung gibt, wäre es super, wenn ihr mir auch schreibt, wie ich das entsprechende Paket installiere.
Conf-Dateien anpassen per vi oder nano ist auch kein Problem!

Vielen Dank,
und viele Grüße,
Heiko

Ist jetzt nicht Exim spezifisch - aber 2 Virtual User anlegen (mail & post) die jeweils auf einen lokalen Account mappen und vom lokalen Account per Alias das Ganze remote.
Etwas wie:

post@blah.com -> forward-1 -> user@blahblah.com

Geht vielleicht auch ganz ohne den "forward-1" User. Das Ganze klappt aber nur wenn dein MTA sich erfolgreich bei den anderen Mailservern authentifizieren kann als SMTP Client.

Erstmal danke für deine Antwort.

Ich hab weiter gegoogelt und finde leider einfach nichts - auch dieser Beitrag hat mir nicht weitergeholfen:
http://www.rootforum.org/forum/viewtopi ... 98#p318096

Ich habe mittels installiert.

Aber wie es jetzt weiter geht mit dieser Konfiguration weiß ich nicht.
Ich bräuchte also eine Schritt-für-Schritt-Anleitung, in welche config-Datei was rein muss.

Und wie stelle ich sicher, dass das Authentifizieren klappt?

Viele Grüße,
Heiko

Sorry, du bist Server-Admin und da wird von dir erwartet, dass du deine Materie im Griff hast. Ne Schritt-für-Schritt-Anleitung für plumpes und unverstandenes Abtippen wird dir hier keiner liefern. Die prinzipielle Lösung auf deine konkrete Frage hast du erklärt bekommen, die notwendigen Basics liest du dir bitte selbst an. Wenn du im Netz nichts findest, dann besorge dir ein Buch und mach dich schlau.

Wenn das nicht passt für dich: Persönlichen und individuellen Support bekommst du gegen entsprechende Rechnung von vielen professionellen Admins. Einfach Anfrage hier im Forum stellen.

Naja, irgendwann muss man es lernen.
Wenn jemand einen Link kennt zu einem Schritt-für-Schritt-Tutorial, bin ich dankbar.
Hatte bislang nur Webhostinge, da waren Mail-Forwards mit einem Klick eingerichtet über Confixx...

heikoh wrote:Naja, irgendwann muss man es lernen.

Absolut! Nichts anderes habe ich dir geschrieben. Du sollst es vernünftig lernen. Meinst du im Ernst, du lernst vernünftig, indem du ein paar vorgefertigte Zeilen in die Shell hämmerst, die du nicht verstehst? Das klingt eher nach dem Gegenteil von lernen wollen.

Ich denke schon.
Ich brauche gerade keinen vollen Mailserver.

Ich hab grad ein Hosting-Paket, und das hab ich gekündigt.
Dort habe ich keine Lust auf die Einschränkungen, wo nichtmal Gallery2 läuft. Die Vserver sind recht günstig geworden.

Ich bereite mich gerade vor und probe mit einem Vserver von einem Kumpel, der gerade brach liegt.
Bis November habe ich Zeit, das mit der Weiterleitung hinzubekommen.
Apache2, PHP & MySQL5 laufen super - mehr brauche ich ja gar nicht zu wissen...

heikoh wrote:Ich denke schon.
Ich brauche gerade keinen vollen Mailserver.

Was meinst du wohl wer deine E-Mails entgegennimmt und weiterleitet? :paling:

Ich bereite mich gerade vor und probe mit einem Vserver von einem Kumpel, der gerade brach liegt.
Bis November habe ich Zeit, das mit der Weiterleitung hinzubekommen.
Apache2, PHP & MySQL5 laufen super - mehr brauche ich ja gar nicht zu wissen...

Ähm Hallo? Was du hier von dir gibst klingt so "Das Auto fährt super - von der Straßenverkehrsordnung brauche ich garnichts zu wissen." 8-}

Was dir @papabaer sagen will ist das du für den Server verantwortlich bist (auch wenn es "nur" ein VServer ist) und genau wissen solltest was du da tust.

Das heißt im Klartext: Du bist für die Sicherheit des Servers verantwortlich.

Deine Aufgabe ist es:

• - Sämtliche Software auf dem Server so zu konfiguieren und zu aktualisieren damit Sicherheitslücken nicht entstehen bez. vorhandene Sicherheitslücken geschlossen werden. (Apache2, PHP & MySQL5, Postfix sind nur ein kleiner Teil von dem was auf deinen Server sonst noch läuft.)
  - Sämtliche Datei- und Benutzerrechte so zu setzen, das keine Sicherheitslücken entstehen.
  - Regelmäßig Server und Log Dateien überprüfen.

Sollte der Server mißbraucht werden und das geht sehr schnell heutzutage wenn der Server nicht ausreichend abgesichert ist, dann kannst du dafür zur Rechenschaft gezogen werden. z.B. Dein Server wird gehackt und es wird urheberrechtlich geschützte Musik hochgeladen, die sich dann andere herunterladen. (Es gibt Mittel und Wege auf den Server etwas vor dir zu verstecken.) Dann ist es nur eine Frage der Zeit, bis die Polizei deinen Server sicherstellt und dich besucht und du Post vom Anwalt erhälst. Auch wenn du nicht selbst die Musik hochgeladen hast, so wirst du dennoch verklagt werden. Sollte sich dann bei der Verhandlung herausstellen das du kaum Ahnung hast um einen Server zu betreiben, so wirst du wegen grober Fahrlässigkeit zu Schadensersatz verurteilt und das kann verdammt teuer werden.

Das würde mich in der Tat wieder von einem Vserver abhalten.
Aber auch für das Absichern gibt es bestimmt ein Tutorial :-)
Nur hier werde ich es wahrscheinlich nicht kriegen.

heikoh wrote:Das würde mich in der Tat wieder von einem Vserver abhalten.
Aber auch für das Absichern gibt es bestimmt ein Tutorial :-)
Nur hier werde ich es wahrscheinlich nicht kriegen.

Eine allgemein gültige Anleitung zum Absichern kann dir keiner geben, je nach verwendeter Software auf dem Server sind verschiedene Sachen zu beachten. Du solltest dir dringend erst einmal ein gewissenes Grundwissen aneignen (Das ist nicht gerade wenig!), damit du die Hintergründe verstehst warum man dieses und jenes macht. Die meisten Anleitungen bauen auf diesen Grundwissen auf und setzen voraus das der Anwender genau weiß was er sonst noch zu beachten hat bez. was er damit bewirkt.

heikoh wrote:Das würde mich in der Tat wieder von einem Vserver abhalten.
Aber auch für das Absichern gibt es bestimmt ein Tutorial :-)
Nur hier werde ich es wahrscheinlich nicht kriegen.

Da gibt es bestimmt ein Tutorial im grossen www, ich weiss warum Du hier keine ir zuträgliche Antwort bekommst.

-> Die meisten von uns machen das täglich und aus beruflichen Gründen.

Wenn ich mir die Tutorials so an sehen, sind die ja viele ganz nett, lasen aber den Anwender im unklaren, was er da eigentlich gerade blindlings abgetippt hat.
Insbesondere lassen Sie den Anwender oft im unklaren darüber, dass das Tutorial ganz grob und ganz unwichtige Dinge abdeckt.

Da ich gelegentlich selbst immer wieder mal Tutorials schreibe, fällt mir auf, dass ein ernsthaftes Tutorial Ellenlang würde, würde man halbwegs vernünftig einen Server absichern wollen. Schnell kommt man vom Pontius zum Pilatus und steht vor dem Punkt, dass das nichts mehr mit einem Tutorial zu tun hat.
Oder es haben sich schon wieder so viele essenzielle Sachen geändert, dass man es niemandem mehr zumuten kann.

Langer Rede kurzer Sinn. Auch wenn es ggf. ein kleiner Versuch gewesen sein mag die User hier aus der Reserve zu locken.
Dass Du von uns kein Tutorial bekommst, hat Gründe und liegt nicht an unserer Unfähigkeit oder Unwillen.

1. Zeit , ein gutes Tutorial braucht Zeit.
2. Die Grundlagen soweit vermitteln, dass ein DAU nicht in die Verleihung kommt, blind ein Tutorial abzu tippen ohne verstanden zu haben, was er da gemacht hat.
3. Basierend auf 2. soweit Verantwortung übernehmen, dass man das Tutorial auch guten Gewissen veröffentlichen kann.
4. Vollständigkeit. Ich baslte mir ein Setup, das genau meinen Ansprüchen genügt. Aber wie ist das mit dem Anwender? Der braucht eventuell etwas spezielleres was wiederum eine Vielzahl an Abhängigkeiten mit sich bringen kann. Das müsste man in einem Tutorial erklären.
5. Abhängigkeit zu anderen Distributionen. Das kann einem ziemlich aufs Kreuz legen.
6. Aktualität. Wer nimmt sich denn "Ewigkeiten" eines Tutorials an, pflegt diese weiter, prüft es auf kritische Mängel und Kompatibilität zu aktuelleren Versionen?
7. Komplexität. Gerade die Absicherung eines Websrvers / Rootserver bringt mit jedem einzelnen eingesetzten Produkt eine weitere Fülle an Komplexität mit. Wer kann das alles überblicken? Und wer bringt die das Grundlagenwissen bei, dass hier nötig ist. Denn auch ein Tutorial erfordert u.U. Grundlagenwissen.


Das sind die Gründe, warum Du hier wenige Tutorials findest. Sicherheit ist ein Thema, da darf man sich eigentlich nicht auf die Kompetenz eines beliebigen Authors verlassen. Sonst kommen da so sahen raus, wie:

Der SQL User ist jetzt stark beschränkt.
Darf aber immer noch Daten löschen, Einfügen, Updaten obwohl eigentlich nur lesend zugreifen müsste.
* Gesehen und herzlich drüber gelacht in einem anderen Forum.

Bei Tutorials muss man selbst in der Lage sein, zu begreifen, was man da macht.
Dies erfordert einen nicht unerhebliches Grundlagenwissen.
Also ist ein Tutorial, kein Heilmittel für Inkompetenz. Eher der Todestoss dazu.

Ok, hab schon verstanden.
Zwischenzeitlich bin ich hier fündig geworden, was auch funktioniert.
[Link entfernt. Dieses Tutorial kann ich niemandem empfehlen!]

Wenn aber Vserver so unsicher wären, dann dürfte ja niemand selber selbst ein Hosting-Paket mit MySQL5 verwenden.
Denn da kann sich ja auch jemand reinhacken und Sachen hochladen, die dann andere wieder runterladen können...

heikoh wrote:Ok, hab schon verstanden.

Und warum machst du dann weiter, als wäre nix gewesen?

heikoh wrote:Zwischenzeitlich bin ich hier fündig geworden, was auch funktioniert.

Und das weißt du woher? Weil es das macht, was du erwartest? Bist du dir sicher, dass es nicht noch was anderes ermöglicht, was du nicht bemerkt hast? Du hast keinen Plan und rennst irgend welchen Leuten hinterher, die unter Umständen (in der Realität leider die Regel) kaum mehr Plan haben als du.

heikoh wrote:Wenn aber Vserver so unsicher wären, [...] kann sich ja auch jemand reinhacken und Sachen hochladen, die dann andere wieder runterladen können...

Und genau das passiert jeden Tag hundertfach Leuten wie dir, die es nicht checken. Ich kann dir, wenn du mir das nicht glaubst willst, eine lange Liste mit Links dieser Geschichten posten: "Hilfe *Heul* Server gehackt, Polizei, ich hab doch so gar keine Ahnung davon ... (und ich hab doch extra mein SSH nach diesem tollen Tut abgesichert)"

Nicht umsonst verdienen Leute viel Geld mit so etwas.

heikoh wrote: Wenn aber Vserver so unsicher wären, dann dürfte ja niemand selber selbst ein Hosting-Paket mit MySQL5 verwenden.
Denn da kann sich ja auch jemand reinhacken und Sachen hochladen, die dann andere wieder runterladen können...

Die Infrastruktur zwischen "vServer", Rootserver und eine Webserverfarm unterscheidet sich nicht unerheblich.
Und die, die das ernsthaft betreiben, haben verstanden, wie man so etwas absichert.
Das basiert in den wenigstens Fällen auf irgend einem Tutorial.

BTW: Mag mir jemand wieder Mod Rechte geben? Den Link zu dem Tutorial würde ich doch lieber wieder löschen. Kaum verantwortbar, was der Mensch da geschrieben hat.

Ich hab jetzt immer noch 3 Monate Zeit darüber nachzudenken, ob ich nun wirklich einen Vserver will oder ob ich doch einfach ein kleines Webhosting-Paket buche.

Was genau ist jetzt an den Befehlen in dem Link so gefährlich?
Es muss keine ausführliche Erläuterung sein, nur ein paar Stichworte, welche Lücken durch diese Konfiguration entstehen können...

Er geht auf wesentliche Grundkonfigurationen nicht ein.

Und ein paar Sachen sind sogar falsch, so z.B. dass man i.d.R. einen anderen "Hostname" verwendet als die Domain, für die er ggf. zuständig ist. Das gibt in Verbindung mit virtual Domains Probleme.

Der check mit telnet. ob dr Dienst läuft, unzureichend. Es ist wirklich nicht kompliziert, per telnet auch schnell ab zu prüfen, ob eine Maileinlieferung auch klappt.

Nimm Webspace! Selbst ich würde Webspace nehmen, wenn es nur um das Hosten einer Website geht. Das erspart einem unnötige Admin-Arbeit und ist obendrein meist um einiges günstiger.

(v)Server sind nicht dazu gedacht, seine Website zu hosten. Die nimmt man, wenn man was wirklich Spezielles umsetzen will oder eigene Dienste betreiben will.

Ja, aber gerade die Gängelungen bei Webseiten haben mich verleitet, am liebsten einen VServer zu nehmen.

Pro/Contra Webhosting:
(-) exec() ist häufig aus, das braucht aber Gallery2 oder Gallery3
(-) Ich kann nicht einfach ein Paket wie Gallery2 per Wget überspielen, sondern muss im schlimmsten Fall per FTP das gesamte ZIP-Archiv als Einzeldateien überspielen
(-) Ich will von einer IPCam per FTP regelmäßig Bilder auf dem Webspace ablegen lassen. Kann diese aber nicht zippen (da exec() aus ist) und müßte dann alle Mini-JPGs per Einzelfile runterladen
(-) Ich kann Verzeichnisse nicht rekursiv löschen, wenn ich z.B. Gallery2 wieder entfernen möchte.
(+)Safe_Mode ist glücklicherweise meistens aus mittlerweile

Und Webhosting-Pakete mit SSH-Zugang sind recht teuer.
Ich brauch keine Hochleistungswebseite und auch die Verfügbarkeit ist bei mir nicht von Bedeutung. Wenn es mal nen Tag nicht geht, auch nicht schlimm, dann kommen halt ein paar Werbemails nicht an.
Will ja keinen Shop oder dergleichen betreiben...

(-) exec() ist häufig aus, das braucht aber Gallery2 oder Gallery3

Wird nicht unbedingt für Gallery2 u. 3 benötigt.

(-) Ich kann nicht einfach ein Paket wie Gallery2 per Wget überspielen, sondern muss im schlimmsten Fall per FTP das gesamte ZIP-Archiv als Einzeldateien überspielen

Nutz doch in PHP die Streams und schon kannst du wget in php haben. http://www.php.net/manual/de/book.stream.php

(-) Ich will von einer IPCam per FTP regelmäßig Bilder auf dem Webspace ablegen lassen. Kann diese aber nicht zippen (da exec() aus ist) und müßte dann alle Mini-JPGs per Einzelfile runterladen

Warum verwendest du nicht die zlib Funktionen dazu und machst mit PHP Zips draus? http://www.php.net/manual/de/book.zlib.php

(-) Ich kann Verzeichnisse nicht rekursiv löschen, wenn ich z.B. Gallery2 wieder entfernen möchte.

Mit etwas PHP Code geht auch das.

Webspace inklusive SSH und Cronjobs: http://www.hetzner.de/hosting/produkte_webspace/level19

Um den Thread nochmal aufzugreifen - und da ich nicht so schnell aufgebe, bitte ich um Bewertung meiner durchgeführten Sicherungsmaßnahmen auf meinem Test-Vserver:

Offene Ports kontrolliert
SSH für root gesperrt
SSH2 ist aktiv
SSH-Port auf hohe zufällige Zahl geändert
Lange Passwörter vergeben
SQL-Passwörter unterscheiden sich von den Benutzer-Passwörtern
fail2ban installiert + für SSH sowie Proftpd aktiviert
MTA mit Relay-Tests im Internet getestet - alle Relay-Versuche waren nicht erfolgreich
fail2ban.log regelmäßig kontrolliert - keine Auffälligkeiten
mail.log kontrolliert - ca. 2-3 Connection-Versuche von unbekannten Hosts, die allerdings noch in derselben Sekunde wieder disconncted werden

Jetzt könnte ich noch chrootkit installieren sowie ClamAV.
Was sonst wäre nun noch zu tun, um den Server gegen eine feindliche Übernahme zu schützen?

Viele Grüße,
Heiko

heikoh wrote:
Offene Ports kontrolliert

Von einem Fremdsystem z.B. mit nmap.
Beachte bitte, per default werden nicht alle Ports überprüft.
Auf dem System selbst wäre netstat das tool der Wahl.

heikoh wrote: SSH-Port auf hohe zufällige Zahl geändert

Das ist verzichtbar. Eine Anmeldung ausschliesslich über pubkey mit einer hohen Verschlüsselung von 2048 BITs oder mehr ist ausreichend.

heikoh wrote: Lange Passwörter vergeben

Komplexe Passworte.
Gross Kleinschreibung, Zahlen und Sonderzeichen.
z.B.
$PkK43Rf&?akz
ist auf jeden Fall sicherer als
11111111111111111111111111111111111111111111111111111111111
auch wenn es kürzer ist. Bei SSL wie schon gesagt, keine Password Anmeldung sondern nur mit Pug Key.

heikoh wrote: SQL-Passwörter unterscheiden sich von den Benutzer-Passwörtern

So oder so Sinnvoll,aber auch hier möglichst komplexe Passworte nutzen.
Zudem, sofern es um eigeine Skritpe / Lösungen geht, einen Login pausieren lassen, so dass z.B. von einer IP und einem Benutzer der Loginvorgang 1 Sekunde dauert. Das bremst Brute Force Attacken erheblich aus.

heikoh wrote: fail2ban installiert + für SSH sowie Proftpd aktiviert

Da scheiden sich die Geister. Für ftp mag es i.O. sein aber für ssh mit einer PubKey authentifizierung ist es irrelevant.

heikoh wrote: fail2ban.log regelmäßig kontrolliert - keine Auffälligkeiten

Alle Logfiles kontrollieren nicht nur fail2ban!

heikoh wrote: Jetzt könnte ich noch chrootkit installieren sowie ClamAV.
Was sonst wäre nun noch zu tun, um den Server gegen eine feindliche Übernahme zu schützen?

Logfiles Analysieren, regelmässig alle Dienste entsprechend der Dokumentation akriebisch absichern.
Damit meine ich den Apache Webserver, PHP, Mailserver, Datenbank.
Sich generell überlegen, wie man das Filesystem z.B. möglichst härtet, so dass ein Benutzer mit einer ggf. erlangten Remoteshell keine Binaries ausführen kann, die eer nicht ausführen soll.
Einzelne Distributionen bieten eine "Härtung" des Filesystemes an.
VHosts so gegeneinander absichern, dass diese in eigenen Benutzerkontexten laufen. Das kann man z.B. mit suexec, oder fastcgi Prozessen erreichen.

Das System auf das nötigste Reduzieren.
Wird kein Python benötigt, weg damit, wird kein Kompiler benötigt, weg damit. Wird Perl nicht benötigt, weg damit. Weniger ist an der Stelle mehr.

Die Webanwendungen z.B. akribisch auf Schwachstellen untersuchen, ggf. selbst oder über den Maintainer patchen.
Dito Security Fixes etc. einspielen.
Entweder über den Maintainer oder selbst.
Security Newsletter der eingesetzen Software abonnieren.
Nochmals, Logfiles lesen.

Abhängig vom Provider über dessen Sicherheitsmechanismen informieren und ggf. dessen externe Firewall nutzen um z.B. ungewollten ausgehenden Datenverkehr zu verhindern.

Betriebsdaten sammeln, (monitoring)
Betriebsdaten analysieren, auswerten und erhebliche Abweichungen auf den Grund gehen. Also den normalzustand des Systemes ermitteln.

Sicherheitseinrichtungen auf Funktion prüfen z.B. Fail2ban, denn es bringt nichts, wenn diese Tools instalierrt sind aber ggf. gar nichts sauber funktionieren.

Einzelne Bücher zum Theme Sicherheit speziell auf Linuxsystemen besorgen, durchlesen Angriffsmethoden verstehen und ggf. mal selbst ausprobieren, wie sowas geht und wie man es verhindert. Letzteres macht man natürlich zuhause!

Logfiles lesen.

Das sieht für mich (mal wieder) nach nem typischen HowTo aus dem Netz aus. Und es führt genau zu dem, was ich oben skizziert habe: Du hast ssh abgesichert und gecheckt, dass du keinen Open Relay laufen hast (bis hierhin ok).

Nur: Die wenigsten Angriffe laufen über ssh. Wenn man nicht ein selten dämliches Passwort gewählt hat, kann da so gut wie nix passieren. Außer Debian baut mal wieder Mist mit den Schlüsseln, aber da hilft dir dein Vorgehen auch nicht.

Die meisten Angriffe erfolgen über weitere Dienste. Und die musst du gehörig absichern und härten. Ziel Nr.1 sind Web-Applikationen, und über Apache, PHP und Co. lese ich in deinem Post nix.

Es gibt aber kein allgemein gültiges Vorgehen, weil dein System einzigartig ist. Also braucht du auch das nötige Wissen für deinen Einzelfall. Und das steht in keinem HowTo.

Da etwas durchaus Wichtiges bisher noch nicht genannt wurde - Backups machen - regelmässig. Und die bis zu einem gewissen Zeitpunkt aufheben, damit notfalls zurückverfolgt werden kann wenn mal etwas schiefgeht.
Nicht nur wegen der Sicherheit - eine HDD raucht auch mal ab und dass meist dann wenn man es nicht braucht.