Beiträge von Scaleo

    Darf ich mal fragen warum du nicht einfach das feritge debian etch x64 SYSCP immage verwendest, nach der installtion ein upgrade machst und gut ist.


    Hab ich auch gemacht und bei mir kommen keine Fehlermeldungen.


    Achja und das auf dem VServer Bronze


    :):)Das immer jeder das Rad neu erfinden will....:):)

    bei lighthttpd wirst du kaum ne chance haben. und mysql wenn du die innodb bereits aus hast auch kaum.


    Wenn ich dir einen Tipp geben darf und du warten kannst dann warte, denn es kommt eine neue Vserver Generation von Netcup

    also ich persönlich würde dir das update empfehlen. (evtl geht ja was auf kullanz) denn du hast nicht irgendwelche Ausreiser Programme die den Speicher fressen sondern einfach die Summer die das Problem darstellt.


    Wie gesagt ist meine Meinung und so würde ich handeln.

    Zitat

    Der Grundgedanke ist gut, aber die erwähnten Leute schauen sich weder davor noch danach in Foren um, um sich zu informieren. Falls überhaupt ein Forum aufgesucht wird, dann meistens nur, wenn das Kind schon im Brunnen liegt; sprich nichts mehr geht, Fehlermeldungen auftreten, usw.


    Ja das ist ja das Traurige.




    Gute Idee werde ich mit in das Tutorial einfügen.


    Ich denke wenn noch mehr so gute Ideen kommen wird das Ding richtig brauchbar.

    Dankeschön.


    Ich sag mal so ich halte es für sehr wichtig, dass es solche Beiträge gibt: Als ich damals meinen ersten Server hatte, hatte ich keine Ahnung von der Materie. Heutzutage empfinde ich das als gröbst fahrlässig. Ich würde nie mehr so anfangen. Aber es gibt genug die es machen. Ich war ja schließlich auch so doof.


    Mein einziger Vorteil war, das ich ein System mit Confixx hatte bei einem anderen Hoster der zwar einen scheiß support hatte aber dafür eine sehr gute Grundkonfiguration zur Verfügung gestellt aht.


    Heute mag ich Confixx nicht mehr, da es mir zu viel im System verändert.
    Wie gesagt. Ich will mit diesem Thread einfach Neuadmins davor bewahren aufgrund einer unüberlegten Handlung (Anmietung eines Servers) sich ihr Leben zu versauen, weil sie riesige Summen Strafe zahlen müssen.


    Ich hatte selbst das Glück, dass mir soetwas nie passiert ist, aber dieses Glück hat sicherlich nicht jeder.

    Da Sicherheit bei einem Server kein uninteressantes Thema sein sollte, ist es für Admins sehr wichitg ein gewisses Grundwissen zu haben, bzw sich anzueigenen da man ja bekantlicherweil in einem gewissen Bereich für seinen Server haftbar gemacht weredn kann.


    Ich möchte hier einmal eine Anleitung erarbeiten wie man seinen Server grundsätzlich absichern sollte um ungewünschte Hackerangriffe abzuwehren.


    Diese ist keinenfalls als vollständig anzusehen, aber mit Sicherheit ein guter Anfang.
    Dies ist nicht alles auf meinem Mist gewachsen, sondern ist eine Sammlung von Informationen

    Einleitung:


    Zunächst solltet man sein System immer aktuell halten:


    Bei Debiandistributionen:


    Zitat

    apt-get update dann apt-get (dist-)upgrade

    Die Firewall (im V-Server Controll Panel) sollte so konfiguriert sein, dass nur die Ports erreichbar (offen) sind, die man wirklich braucht. D.h. man Sperrt alle Ports außer SSH*, FTP*, Web, POP/SMTP Ports.


    Zitat

    * Der SSH-Port sowie der FTP Port kann auch gesperrt werden, da man ihn bei Bedarf innerhalb vion 30 Sekunden entsperren kann

    Sichere Passwörter verwenden:


    ein sicheres Passwort ist nicht:

    Zitat

    test123

    ein sicheres passwort wäre:

    Zitat

    !<t31!carolin77>&<t83!werner75>!

    Natürlich ist das schwer zu merken, dafür aber auch schwer zu knacken.


    Weitere Informationen über Linux und Serveradministration die man sich auf jeden Fall durchlesen sollte findet ihr hier:



    So nun aber zum eigentlichen Tutorial



    1. Regelmäßige Prüfung eurer Log Files.


    Eure Logs findet ihr meist unter /var ,weitere unter /var/log
    Diese müssen regelmäßig, am besten täglich auf irgendwelche Auffälligkeiten hin geprüft werden.


    Man kann sich auch die Logfile per Mail zusenden lassen (=> Google)


    2. Rootlogin verbieten und SSH-Port ändern


    2.1 SSH Port ändern


    Obwohl das ändern des SSH Ports nur eine Scheinsicherheit ist, lassen sich damit jedoch sehr gut automatisierte angriffe abwehren, den den Hackbots ist es zu viel Aufwand jeden Port zu scannen.
    Ich persönlich empfehle Ports ab 40000.

    2.2 Rootlogin


    Dieser sollte nicht für Root erlaubt sein, sondern für einen unpreviligierten User, mit einem vernünftigen Passwort, eventuell einem Key, der auf dem lokalen Rechner liegt


    Man verbietet den Root Login indem man in der /etc/ssh/sshd_config die option

    Zitat

    PermitRootLogin yes


    auf no setzt.


    Schaut dabei auch gleich ob ihr in der sshd_conf euer SSH auf
    Protokoll 2 gestellt habt.
    (Das ist bei Netcup eigentlich automatisch der Fall)


    Ein weiterer Punkt wäre den SSH-Port per Firewall zu sperren, wenn man ihn nicht benötigt.



    3. Der Mailserver


    Dieser sollte kein offenes Relay darstellen. Bei einem offenen Relay kann jeder über deinen Server irgendwas verschicken, eben auch Spam.


    Ausserdem sollten die bestehenden Zugänge vernünftig abgesichert werden, und die Passwörter sauber gesetzt werden.


    Zum Schluss kann man sich überlegen, ob man den Zugang nur noch über SSL erlauben will, denn sonst könnte jemand den gesammten Netzwerkverkehr mitlesen.


    Wie das funktioniert, ist bei den einzelnen Mail-Servern unterschiedlich.
    Hier mal ein Beispiel für den meist verbreiteten MailServer Postfix


    Zitat

    Hier findet ihr alles was dazu notwenig ist.


    Überprüfen sollte man abschließend ob ein offenes Relay existiert. Das kann an auf folgender Website machen:


    http://www.abuse.net/relay.html


    Sollte das der Fall sein, ist eurer Server auf dem besten Weg dazu eine Spamschleuder zu werden. Also alle offenen Relays sofort schließen



    3. Der Webserver


    Hier sollten die Zugriffsrechte für Verzeichnisse sauber gesetzt sein, so dass man nicht einfach irgendwohin auf dem Server gelangen kann.


    Des Weiteren sollten wichtige Bereiche, wie Adminbereiche, SysCP oder phpmyAdmin, mit einem Passwort geschützt werden; Stichwort HtAccess.
    http://de.selfhtml.org/servercgi/server/htaccess.htm
    Eine Weitere Möglichkeit besteht in der
    Änderung eurer Konfigurationsdatei des Webservers. Indem man einen Alias in der Config setzt und einen ungewöhnlichen Namen benutzt, wird PHPmyAdmin deutlich schwerer zu erreichen.

    Ausserdem sollte man darauf achten, dass einzelne Skriptsprache wie bespielsweise PHP richtig abgesichert sind.
    Hier gibt es Konfigurationen die das System nicht wirklich sicher machen.


    Bei PHP beispielsweile sollten folgende Punkte in der PHP.ini folgendermaßen konfigueriert sein:


    Zitat

    disable_functions = show_source, exec, shell_exec, system, popen, proc_open, proc_nice, ini_restore, passthru, dl
    register_globals = Off
    allow_url_fopen = Off
    display_errors = Off
    open_basedir = [path to the directory of the web server / virtual host]
    safe_mode = On


    Safe_Mode ist immer eine kritische Sache!, ich zitiere hier jetzt einfach mal killerbees19:


    Zitat

    Der Safe Mode bietet eigentlich nur eine halbe Sicherheit und verursacht mehr Probleme als er bringt. Denn in vielen Modulen ist er falsch oder unvollständig integriert. Mit PHP 6 wird er übrigens auch entfernt werden, nicht ohne Grund...
    Empfehlenswert ist auf jeden Fall die Fehlerausgaben von PHP so hoch wie möglich zu stellen (E_STRICT wäre ja ideal :p )


    hier möchte ich noch den folgenden Link mit anhängen:


    http://www.strassenprogrammier…hern-hacker_tipp_497.html




    3.1 MySQL Server


    Ich persönlich habe den MySQL Port von außen per Firewall gesperrt. Ich denke das ist die einfachste Lösung. Wichtig ist hier wieder die korrekte Konfiuration von Webserver und PHP, denn durch Fehleinstellungen, gelangt der Angreifer sehr schnell an eure MySQL Zugangsdaten und kann beispielsweise eine Datenbank mit Kinderpornolinks anlegen.
    Das würde euch mit Sicherheit nicht gefallen.




    4. FTP-Server


    Ich persönlich empfehle hier vsftp. Ein einfacher uns sicherer FTP-Server
    Was wichtig ist, Wenn ihr den FTP nicht braucht sperrt eueren FTP Port (21) per Firewall.


    [B]Richtige Konfiguration:[/B] sftpd ist von Haus aus so konfiguriert, dass anonyme Benutzer sich einloggen dürfen. Sie dürfen in der Standardkonfiguration jedoch nur in /home/ftp lesen. Sie dürfen dieses Verzeichnis nicht verlassen und auch nirgends schreiben. Möchte man anonyme Logins komplett deaktivieren, so müsste man hier

    Code
    # Allow anonymous FTP? (Beware - allowed by default if you comment this out).
    anonymous_enable=YES

    das YES in NO ändern.


    Als nächstes sollte man Lokalen Benutzern den Login erlauben:

    Code
    local_enable=YES

    Damit geschrieben werden kann ist diese Zeile hier wichtig:

    Code
    write_enable=YES

    Die letzte wichtige Option wäre es die lokalen Benutzer auf ihr Homeverzeichnis - also /home/benutzername - zu beschränken.
    Dies macht man folgendermaßen:


    Code
    chroot_local_user=YES

    Bitte auch hier noch weiterlesen: http://wiki.ubuntuusers.de/vsftpd






    5. Nützliche Tools
    Das System sollte regelmäsig geupdatet werden, und immer auf dem neuesten Stand sein.


    Nützlich kann immer sein:





    6. Die Programme am besten per Cronjob ausführen


    Es ist wichitg, dass Ihr so früh wie möglich von einer Infektion erfahrt und darauf reagieren könnt.
    Dieses Skript (Ursprung) führt ClamAV aus (der dann die Verzeichnisse /root, /home und /tmp scannt), chkrootkit und rkhunter -- und mailt Euch dann die Logfiles.


    --> E-Mail Adresse ersetzen, und ggf. die Logfile Pfade ändern. Der Ordner muss exisitieren, die Dateien selbst werden dann erstellt, wenn das Script ausgeführt wird (nach Datum sortiert).



    7. Keine schlecht programmierte unsichere Scripte verwenden




    So. Ich denke mit diesen Informationen ist für jeden der ein bisschen bereit ist weiterzulesen und Interesse hat möglich seinen vServer ersteinmal eine gewisse Grundsicherheit zu geben. Einwas muss man sich jedoch bewusst sein. Ein Server kann nie 100% sicher sein, das wurde erst in den letzten Tagen wieder deutlich.



    Ich wollte jetzt hier mal nachfragen wie es denn nun eigentlich mit den fertigen Gameserverimages aussieht?

    Das ganze wurde vor mehr als einem Jahr angestoßen und man hört nichts mehr.

    Schade eigentlich.

    Ich würde mich hier über eine offenere Informationspolitik freuen.

    Wenn Netcup natürlich den großen C(o)up macht und mit den neuen vServern die Gameserver einführt wäre dies richtig richtig klasse.

    Also lasst mal was hören. Auch wenn das Projekt eingeschlafen ist.

    Was noch ein Anliegen wäre, wäre ein Webinterface einzubauen um die Server zu starten und zu stoppen.

    ------------------------------------------------------------------
    Ich persönlich brauch keine fertigen Images, aber es wäre eine nette Erleichterung.

    So nach einigen Tagen Testlauf kann ich hier heute berichten wie meine neue und wahrscheinlich Endgültige Konfiguration aussieht.


    Beide CS:S



    • GG_Mini_Mario_2 20 Slot Deathmatch Tickrate 100


    [INDENT]Plugins:


    • MetaMod:Source (per VDF geladen) (aktuelle Version)
    • Sourcemod (per VDF) (aktuelle Version)
    • Deathmatch, QuakeSounds, FakeBot, Deathbeam, Autojoin


    [/INDENT]2. DUST2MarioStyle 20 Slot D/E Tickrate 100[INDENT]Plugins:


    • MetaMod:Source (per VDF geladen)
    • Sourcemod (per VDF)(aktuelle Version)
    • QuakeSounds, FakeBot, Deathbeam


    [/INDENT]Die "Kiste" läuft rund und ich bin überrascht wie niedrig die Auslastung ist. Trotzdem will ich nicht mehr mehr Server draufpacken, da ich einfach Kapazitäten für Lastspitzen freihaben möchte. Und gerade bei einem Deathmatch kommt das öfters Vor wenn mehrere Player gleichzeitig respawnen.

    Guten Morgen,


    Generell kann man glaube ich trotzdem sagen das vServer, auf denen NUR!! Gameserver (und evtl. TS) laufen, lange nicht so anfällig für einen Angriff sind wie vServer auf denen das ganze "Webhosting Programm" arbeiten muss, da es einfach wesentlich weniger Angriffsstellen gibt.


    Wie gesagt generell ist von ManiAdminPlugIn abzuraten, da es von nur einer Person entwickelt wurde und teilweise buggy gecoded ist, zusätzlich noch unter der gpl2 :confused: steht und der Code damit für jeden einsichtbar ist. Somit können Sicherheitslücken noch leichter gefunden werden.


    Ich persönlich bin der Meinung das unter der Vorraussetzung, dass nur Sichere Plugins verwendet werden (Damit schließe ich auf jedenfall Mani und evtl Eventscripts aus) man seine SSH absichert (am besten Port mit Firewall sperren, solange er nicht gebraucht wird), regelmäßig chkrootkit laufenlässt und einfach seine Logs im Auge behält der Gameserverbetrieb relativ sicher ist.


    Was ich persönlich noch empfehen würde ist ein SFTP Server, da man ja meist FTP verwendet um Mpas, Plugins etc einspielt. (Ubuntuusers Wiki wird wohl jeder fündig werden).
    Und wichtig: Den FTP Server RICHTIG konfigurieren ein Anonymus global Write Enable ist 100% tödlich ;);). Ich denke ihr wisst was ich damit sagen will.


    So ich will hier nicht die Datenbank des Forums sprengen, deshalb höre ich hier nun einmal auf.


    Grüße


    Flo

    Dazu hätte dann gleich mal eine Frage großer Servermeister Preuß :):)


    Können auch Bestandskunden an der Betaphase teilnehmen? Es wäre sicherlich für diejenigen Interessant die Gameserver hosten. (Ich z.B.)
    Denn wenn man euch glauben dar (und davon gehe ich mehr als aus), dann wird die kommende Generation ja alles in den Schatten stellen und wenn die Preislich genauso liegen dann glaube ich das damit einiges im Bereich Gameserver möglich sein sollte, denn auch die jetztige Generation ist da schon sehr gut.


    Ich habe z.B. 40 Slots auf einem Gold laufen und es läuft wirklich rund.
    Man wird zwar manchmal blächelt wenn die Leute mitbekommen das man auf einem vServer hosted aber nachdem sie 2 Stunden auf dem Server waren sind sie nicht mehr so überheblich und es kommen Kommentare wie: Ne das ist kein V-Server, das ist mit Sicherheit ein Root^^. Ja genau das habe ich gestern Abend erlebt. Ich wusste nicht mehr was ich darauf nur sagen sollte. Denn eigentlich ist das das beste lob was man als Administrator von einem vServer bekommen kann und das muss ich natürlich auch an euch weitergeben, denn duch eure genialen Angebote macht ihr das ganze erst möglich.


    Ehrlich gesagt glaube ich das NetCup im Bereich GamesVserver Monopolstellung hat.:D:D


    So das wurde ein ätzend langes Ding

    klar ist der ssh port noch da aber die ganzen skriptkiddies sind erst mal ausgeschaltet.
    Wer nach dem Port sucht, wird ihn natürlich trotzdem finden. Aber der Port ist natrülich im normalbetrieb per Firewall gesperrt.