Beiträge von [netcup] Alex W.

    Man muss dafür in IMSCP die Mailfunktion des betroffenen Kunden bzw. der Domain gänzlich deaktivieren, dann sollte diese nicht als maildomain im System angelegt werden. Damit werden dann wiederum die MX Einträge berücksichtigt die per DNS gesetzt sind.

    Vielen Dank, sowas liest man natürlich gerne an einem Montag morgen. Das meiste kommt hier natürlich durch die User die sich gegenseitig helfen. Wir betreiben das Forum ja schließlich lediglich und bieten es als Anlaufstelle an ;) Wir sind gerne auch jederzeit für Verbesserungsvorschläge zu haben auch wenn wir aus mehreren Gründen diese evtl. nicht sofort umsetzen, prüfen wir jeden Vorschlag. Allen noch eine schöne ruhige Woche ;)

    Establishing connection failed, vorgehensweise der Prüfung:

    • Prüfen ob der mysql Server läuft
    • prüfen auf welchen IPs der mysql Server horcht
    • Zugangsdaten in Froxlor, Standardpath: /var/www/froxlor/lib/userdata.inc.php -> Datenbankzugangsdaten root
    • Mit diesen Daten über die shell einmal anmelden, wenn dies scheitert, hat sich das root pw geändert

    Hierbei dann ggf. das mysql root Passwort neu setzen, siehe dazu diesen Beitrag mysql root User Passwort neu vergeben.

    Im System ist also die richtige Zeit eingestellt. Wenn seitens PHP nun eine andere Zeitzone ausgegeben wird, ist in PHP schlichtweg eine andere Zone konfiguriert. Hier müssen Sie dann schauen wo Sie oder eines Ihrer Scripte die Konfiguration vorgenommen, z.B. per htacces, php.ini des vHosts oder im vHost selbst.

    Nicht 777! Maximal 755 Mehr ist weder nötig noch möglich ;) Bei 777 würde ein Internal Server Error (Error 500) kommen. In den meisten Fällen liegt ein 403 hieran:

    • Der Ziel Ordner der Domain (Document Root) ist leer.
    • Im Zielordner befindet sich eine htaccess Dateie mit ungültigen Inhalten
    • Im Zielordner befindet sich eine htaccess Datei ohne das mod_rewrite in Confixx aktiviert ist (Einstellungen -> httpd_Spezial)
    • Der Kunde sieht versteckte Dateien (wie htaccess) nicht weil sein FTP Client keine versteckten Dateien anzeigt (in FileZilla muss man es erst aktivieren

    und so wie du es sagst wurde dann mein Passwort geknackt, na sauber, dann ist alles klar.

    Achtung, ich habe Möglichkeiten genannt. Ich weiss nicht wie genau auf den Server eingedrungen wurde, dafür müsste ich dort eine vollständige Analyse durchführen. Dies können wir per Support auch gerne über die remote Hands Services anbieten, ist allerdings bei einem nicht managed Server mit entsprechend Kosten verbunden. Es gibt wie gesagt viele Wege, nicht nur Bruteforce. Bitte hier nicht auf einzelne Aussagen festnageln und alles im Text beachten, wir (und die anderen User) können nur Vermutungen äussern und Beispiele nennen, das bedeutet in keinem der Fälle das dies zwingend zutreffen "muss". Dies können nur Sie prüfen.

    da die Frage wieviel kostet mich das denn die Installation

    Wir bieten dies in Verbindung mit der Stellungnahme kostenlos als Service an.

    Mein Passwort für den Server wurde geknackt

    Das muss halt geaustens (!) geprüft werden welcher User "geknackt" wurde und wie dies ggf. geschah (per SSH, PHP, etc)

    PS2, Ist da nun mein Fehler gewesen das mein Passwort geknackt wurde?

    Jein. Streng genommen ja, da Sie wie gesagt für Ihren Server verantwortlich sind. Unterbinden kann man dies z.B. mit langen Passwörter, sicheren Clients, evtl. zusätzlichen Keys, Einschränkung der möglichen SSH Logins und FailAttempts sowie Anpassungen an der Firewall Konfiguration. Es gibt zum Schutz des Systems mindestens genau so viele Varianten wie die Möglichkeiten für die Kompromitierung. Die Kenntnisse muss man bei der Verwaltung eines vServers mitbringen oder sich sehr zeitnah aneignen.

    Ich denke mal das sich hier netcup Eingeloggt hat, das Passwort geändert hat , das mir dann zugeschickt wurde damit ich dann auf das Rettungssystem zugreifen kann.

    Achtung, nein! Wir kennen nicht die root Passwörter der Kunden und haben auch keinerlei Berechtigung auf die Server zuzugreifen. Das Rettungssystem wird gesondert gestartet und ist ein unabhängiges minimalsystem welches nur temporär in einem speziellen Speicherbereich startet. Darin wird ein Mounpoint für die Festplatte des Kunden gesetzt. Das root Passwort wird ebenfalls immer generiert gesetzt für das Rettungssystem. Auch im Rettungssystem melden wir uns nicht an. Wie ebenfalls erwähnt, verwenden wir keinen ausländischen Zugang ;)

    Über SSH ? Nur ich hatte den Zugriff, mein Vertrauens Admin hatte nur FTP rechte mit eigenem Ordner, um News schreiben zu können.

    Offenbar war eines der Passwörter wohl nicht sicher genug was die Log zumindest andeutet. Leider konnte der User über die Rechte des komprimitierten Users wohl auch noch das root Passwort für SSH ändern. Das ist, falls es so vor sich ging, dann ein fatales Rechteproblem im vServer gewesen. Dies kann ich allerdings aufgrund der genannten Angaben auch nur vermuten.

    Aber Alex, wie finde ich heraus mit welcher Software "Portscanner – Wikipedia" hier gearbeitet wurde?

    Das lässt sich in der Regel nur schwer rausfinden da eine Software für solche Zwecke nicht sich zu erkennen gibt, zumal es hier abertausende Tools ("leider") gibt. Ein Portscan lässt sich ja z.B. mit Linux und Windows Hausmitteln bereits bewerkstelligen. Interessanter ist viel mehr wieder Angreifer an das Passwort gelangt ist, ob eine BruteForce Attacke lief oder einer derjenigen die Zugangsdaten zum komprimitierten User hatte ggf einen Trojaner auf dem Client hat. Wie man sieht, auch hier gibt es einige hunderte Möglichkeiten der Quelle und Ursache.

    Neukundenbestellungen werden während der regulären Bürozeiten Mo-Fr zwischen 10-18 Uhr bearbeitet da hier Verifizierungen der Angaben notwendig sind welche nicht am Wochenende erfolgen können. Bestandskundenbestellungen können aufgrund bereits erfolgter Verifizierungen auch am Wochenende und Feiertagen erfolgen.

    Das Problem ist, das Sie für den Server und alles was darauf geschieht, verantwortlich sind. Wir müssen uns entsprechend absichern und unseren Pflichten wiederum nachkommen. Daher können wir aufgrund der rechtlichen Lage nicht auf die geforderte Zusicherung verzichten.

    Ihr Beispiel ist dabei nicht ganz richtig, passender wäre dieses Szenario. Sie haben ihr Fahrzeug an einer viel befahrenen Straße mit unverschlossenen Türen stehen lassen. Hierdurch konnte jemand in Ihr Fahrzeug eindringen, dieses kurzschließen und damit für einen Überfall missbrauchen. Hierbei würde Ihre Versicherung Sie ebenfalls selbst haften lassen da Sie "grob fahrlässig" gehandelt haben das Fahrzeug unverschlossen zu parken.

    Dies ist nur ein Beispiel!

    Auf irgendeine Weise muss also jemand Ihren Server missbraucht haben, Möglichkeiten gibt es dort sehr viele, je nach Einrichtung und Konfiguration des Systems z.B. per PHP, direkt per SSH etc. pp.