Beiträge von vmk

    Könntest du den Graphen bitte mal über 48h erstellen und dabei den Minecraft-Server laufen lassen? Aktuell kann man nur 2 Dinge annehmen:

    • Die Spieler schlafen nachts und beginnen morgen/vormittags zu spielen und damit steigt der RAM-Verbrauch. Dabei dürfte aber der Anstieg nicht so linear sein.
    • Der Server/Plugins haben Memory-Leaks. Das dürfte sehr genau den Graphen dem entsprechen.

    .

    Danke johnassel ;)


    a) Schlüssel werden auch nicht so oft benutzt wie Passwörter, d.h. es werden primär Passwörter angegriffen.


    b) Da stimme ich dir zu, Mordor. root sollte keinen direkten, externen Zugang haben. Irgendeinen Benutzer anlegen reicht aus und mit diesem dann einloggen. Aber im Hinterkopf mit d).


    c) Wenn ich einen Shell-Zugang habe, dann bin ich nicht automatisch root. Dafür muss ich ja noch weitere Dienste angreifen. Ausserdem ist sudo ist ja nicht für z.B. den Webserver möglich. Was aber effektiv egal ist, denn auch als Webserver kann ich z.B. Spam verschicken oder weitere Software runterladen und ausführen (z.B. IRC-Proxy, ftp-Server installieren, etc). Mehr Sicherheit bekommst du mit z.B. selinux. Ich halte das für einen (simplen) (v)Server übertrieben. Hier geht es nicht um kritische Daten.


    d) IP-Bereich für den SSH begrenzen. Klingt simpel, wird aber gerne übersehen. Wieso sollte man aus z.B. China einen SSH-Zugriff auf den Server erlauben? Und wer ist so dumm und greift Server im eigenen Land bzw. noch beim eigenen Provider an? Daher macht es Sinn den Bereich auf seinen eigenen DSL-Provider, Schule/Uni/Arbeitgeber sowie eventuell Freunde zu begrenzen.
    Hier im Forum wird dagegen immer wieder vorgeschlagen, SSH, etc global zu erlauben und dann potentielle Angreifer über fehlgeschlagene Logins per fail2ban zu sperren. Leider wird hierbei übersehen, dass dieses nicht gegen eine Sicherheitslücke im SSH-Server hilft, denn dieser wird dennoch die ersten 2, 3 Logins annehmen. Genau solche Sicherheitslücken gab es in der Vergangenheit Konsequenzen des OpenSSL-Debakels | heise Security und wird es auch immer wieder geben.

    elm, wenn schon aus RAM-Gründen auf Clamav verzichtet wird, dann ist das vorschlagen von amavis kontraproduktiv. Spamassassin fliegt wohl auch gleich raus, weil das ebenso Perl-RAM-Monster ist. exim kann sowohl clamav als auch SA direkt einbinden, damit spart man sich immerhin amavis. Aber ein Mailserver zum Empfangen von Mails ohne Viren und Spamerkennung macht für mich wenig bis gar keinen Sinn. Das Teil wird in kürzester Zeit mit Spam & Co voll sein, weil über 95% der Mails lehnt man ja seit Jahren schon wegen Spam/Viren ab.

    Ich dachte bis eben, procmail sei quasi tot und wird nicht mehr weiterentwickelt. Der Inhalt deines procmailrc scheint auch zweifelhaft zu sein. Wenn eine Mail einen Trojaner größer als 256kb hat, dann überspringst du die Prüfung. Wenn eine Mail einen Spam-Score höher als 99 hat, dann ist es kein Spam mehr. Und alle Mails mit Score größer als 3 sind Spam. Dann prüft du, ob die Mail als Virus markiert wurde. Du hast aber gar keine Software dafür laufen.


    Wann gab es da das letzte Update/etc? Aber egal, dir scheinen die MX-Einträge zu fehlen und dein rDNS ist ebenso falsch gesetzt hier wirst du schnell Probleme beim Mailen bekommen.
    Zusätzlich scheinst du nach deinen Logfiles erstmal jede Mail anzunehmen und dann auf Viren/Spam zu prüfen. Das war so zur bis ca 2005 üblich. Bei der heutigen Menge von Spam, macht man das technisch anders. Man prüft während der Annahme der Mail den Inhalt und verweigert diese dann. Der Absender bekommt dann direkt eine korrekte Fehlermeldung, wieso die Mail nicht angenommen wurde.

    Das Forum hier ist Kunde zu Kunde. Der Support liest ab und an mal mit, aber den erreichst du nur per Zufall. Für solche Fälle musst du dich schon an support@ wenden. Oder willst du nur Wissen, ob andere Kunden davon auch betroffen sind?

    Wenn du Software kompilierst, lautet die Faustregel n+1 für n CPU-Kerne. Wenn du dabei I/O-intensive Prozesse hast, dann kannst du auch mehr starten. Eine Festplatte bzw. Netzwerk bearbeitet deine Anfrage ja nicht in Nullzeit, sondern es gibt immer eine Verzögerung. Bei 2 Prozessen, wo einer auf die Festplatte und der andere auf das Netzwerk wartet, hättest du eine echte CPU-Auslastung von 0.

    1. Postgrey läuft nach der Übersicht an der öffentlichen IP, nicht an localhost.
    2. Ist IPv6 in Benutzung?
    3. Es gibt/gab hier und da mal ein Problem mit dem Loopback-Interface. Oft wird da nicht 127.0.0.1 die Adresse vom lo.

    Du versuchst bei Debian sun und/oder java zu finden? Selbst Firefox heißt da Iceweasel und mp3 bekommt man da nicht. Wieso nicht das openjdk?

    Mal ne Frage ist es normal das ich weder Java 6 noch Java 7 Installieren auf meinen KVM installieren kann !?


    Pauschal Ja. An welcher Stelle scheiterst du? Hast du eine Fehlermeldung? Dann wird das sicherlich sehr schnell ein Nein werden.

    Es wird immer nur per IP was übertragen, also liegt der Fehler wohl in minecraft. Ich würde darauf tippen, dass Minecraft vor jedem Ping erstmal eine erneuete DNS-Auflösung macht. Das sollte, bei korrektem DNS-Server in quasi Nullzeit erfolgen. DNS auf dem Server funktioniert sauber?

    Einige Schritte dabei sind auch überflüssig.


    Es reicht beim KVM-Server mit einer beliebigen Live-CD zu booten, die Festplatten zu partitionieren und dann kann man einfach per rsync/ssh vom alten System alle Daten übernehmen.