Beiträge von perryflynn

    Sehr gut. Konnte jetzt nix finden was fehlt.


    Evtl könnte man noch den Zugang mit SSH via openVCP Firewall auf eine IP Beschränken. Ginge wenn man einen Internet Anschluss mit fester IP Adresse hat. (Wie zB bei uns auf der Arbeit)


    //edit
    Ah doch, man könnte den Zugang zu Server nur mit Keys erlauben. Sprich ssh user@server -i keyfile.

    Was für eine PHP Version läuft denn?


    Wenn PHP 5:

    • Putty öffnen
    • Einloggen und root Rechte verschaffen
    • apt-get install php5-gd
    • Extension in der PHP Konfiguration aktivieren, falls APT das nicht sowieso schon gemacht hat
    • freuen


    Bei PHP 4 halt php4-gd als Paketnamen benutzen.
    Have fun. ;)

    Davon inspiriert.


    Ich habe schon mal das /opt Verzeichnis meiner Workstation gekickt. Ich war da noch ziemlich grün hinter den Ohren, und hab deswegen mein System neu aufgesetzt. KDE ging halt nicht mehr. *g* /etc hat ich auch schon mal weg gehauen. ^^


    Habs auch schon mal geschafft mit dd den MBR meiner Platte zu killen. Habs zum Glück vorm Reboot bemerkt... ^^

    Ich würde sagen: gelitten.


    Eventuell hast Du noch eine Chance es über die Paketverwaltung wieder grade zu biegen. man apt & man aptitude bringt info. Ich selbst habe soetwas noch nicht geschafft. *g* Versuchs mal mit chroot und dem Rescue Mode.


    Ansonsten bleibt Dir nur eine Neuinstallation.

    Zu SVN selber kann ich leider nur wenig bis gar nichts sagen. Kenne ich nicht.


    Zitat von masterchris_99;10061

    Nun ist die Frage reicht der vServer aus als SVN?

    So lange der SVN nicht von 100 Clients auf einmal benutzt wird sollte das gehen, denke ich.


    Zitat von masterchris_99;10061

    Der SVN auf Windows ist so ein schönes 1-Click-Setup was es hier wahrscheinlich nicht geben wird... ;)

    Kein One-Click, sondern One-Command. ;)

    Code
    apt-get install <ein svn dienst deiner wahl>


    Zitat von masterchris_99;10061

    Bei ser Sicherung des vServers hätte ich jetzt gedacht alle Ports bis auf http, svn und ssh zu blocken. ssh natürlich auf einen anderen Port und überall unterschiedliche sichere Passwörter sind klar.

    Dazu gab es schon tausende Beiträge hie rim Forum. Optimum sollte bei SSH das nutzen von Pubkeys sein. Und dann halt Passwort Login verweigern. Ansonsten halt die openVCP Firewall vom Support freischalten lassen, und alle anderen Ports blocken. iptables direkt hast Du auf dem vServer nicht zur Verfügung.


    //edit
    Hier noch mal eine Liste was es so zum Thema SVN direkt von Debian gibt:

    Ich habe ja auch nicht behauptet, dass Du irgendetwas falsch gemacht hast. ;)


    Es ist aber einfach so, das die Crack-Server immer gerissener werden. Da muss man ja irgendwie gegen vorgehen. Und mein Vorschlag ist ja auch nur einer von vielen denke ich. Fakt ist jedenfalls, dass ein reiner Passwort-Login nicht mehr sicher ist.

    Man sollte sich vielleicht überlegen, die Images sicherer zu machen.


    Zum Beispiel könnte man von Default aus nur Zugang mit Pubkeys zulassen. Den passenden Key dazu könnte man dann im CCP/VCP zum Download anbieten. Via Email werden dann nur noch die Zugangsdaten zum CCP verschickt.


    So sind auch Neulinge gezwungen, entweder sich ein eigenes Passwort auszudenken, oder sich gar mit der ganzen Materie eines SSH Servers zu beschäftigen.
    Letztendlich ist natürlich der Kunde für die Sicherheit verantwortlich, keine Frage. Aber ich denke das allein diese Aktion das Aufkommen solcher Vorfälle senken würde.

    Zitat von LoOni3r;9962

    bei apt-get install php-gd sagt er mir packete nicht gefunden o.0

    Ein bissl Eigeninitiative bitte. Das Paket heißt php5-gd.


    Code
    </> aptitude search php5-gd
    i   php5-gd                                   - GD module for php5

    Ob du nun Etch oder Lenny nimmst ist völlig egal. Es ist eine reine Konfigurationssache.
    Versuche die Logs mal mit scp oder ftp runterzuladen. Das es ein Timeout beim anzeigen gibt, kann ich mir schon gut vorstellen, ja nach dem wie groß die Datei ist.


    Wie gesagt. So lange Du keine Logs hast ist es unmöglich zu sagen was und wie es passiert ist.

    Wie hier schon mal in einem anderem Forum gesagt wurde, ist Fail2ban Quatsch. Es bringt nichts, solange es auf dem selben Rechner installiert ist, den es schützen soll.


    Viel wichtiger ist die Absicherung der Dienste. Sprich bei SSH Port verschieben, Passwort und root Login verbieten, nur SSH Keys verwenden. Beim Apache open_base_dir in php verwenden, usw.


    Und mindestens ein mal die Woche alle Logs durchschauen.


    Aber erst mal solltest du fLoo's Aussage nachkommen, und schauen wie es zu dem Angriff kommen konnte. Was bringt es Dir alles neu aufzusetzen, wenn die selbe Lücke wieder geöffnet wird?

    Die Tools bringen sowieso nichts.
    Tools wie denyhosts und fail2ban müssten auf einem anderen System installiert werden. Bei DOS Angriffen ist zB die Last trotzdem auf dem Server. Das Paket muss ja erst mal angenommen werden, damit es geblockt werden kann.


    Und solang man bei SSH brav nur Keys zulässt, ist es sowieso sinnlos.

    Zitat von fLoo;9815

    Korrekt. Man kann sich das vorstellen wie ein Screenshot im Browser.


    Also Du macht mich immer interessierter.
    Kannst Du wenigstens mal einen Link zu einer Funktionierenden Version posten? :)

    Nimm bitte den Anhang vom Thread und ändere alle Passwörter. Du kannst doch nicht einfach die shadow veröffentlichen! :eek:


    Zu Deinem Problem:
    Mit den geposteten Dateien kann man nichts anfangen. Boote den Server im Rescue Mode und schau in die Logs von SSH. Evtl kannst Du die Passwörter via chroot ändern.


    Außerdem solltest Du dir überlegen ob ein vServer wirklich etwas für Dich ist.