habt ihr noch tipps für mich

  • hallo leute,
    wie einige von euch besimmt schon mitbekommen haben bin ich noch ein rechter anfänger in sachen linux...
    ich habe mich aber in den letzten tagen mehr damit beschäftigt und mal den server abgesichert also ssh, fail2ban, apache, usw....


    habt ihr noch tipps für mich oder programme wie fail2ban,
    weil im internet finde ich nicht sehr viel mehr

    Wer Rechtschreibfehler findet, darf sie behalten

  • Bitte... Bitte...
    Ich kann das ja verstehen, ich war auch mal jung und neugierig, aber nicht auf Server die von außen erreichbar sind Systemintegration lernen.
    Setzt was irgendwo bei Dir zuhause auf... Debian kannst Du sogar auf 'nem Taschenrechner installieren, sollte es an Rechnern mangeln.


    Du kannst Dir mit falsch konfigurierten Servern eine menge Probleme einheizen.


    Aber, ich will hier jetzt mal nicht vollständig die pädagogische Keule rausholen, weil Du ja eh nicht auf mich hörst, daher hier:


    Absicherung eines Debian Servers – Thomas-Krenn-Wiki
    open_basedir « Daniels Blog
    Automatischer Virenscan mit ClamAV (Ubuntu Server) | Log & Doc
    ZENDAS Erstellung anonymisierter Apache Logfiles (Datenschutz in der Hochschule)
    Postfix: optimierte Konfiguration gegen Spam und Missbrauch | WE ARE ROOT


    Das ist mehr Spielkram:
    Hochleistungs-Apache: Performance-Tuning @ huschi.net
    Postfix: fine tuning @ huschi.net

    "Hmm, wo ist denn die Any-Key-Taste? Naja, ich bestell mir erst einmal ein Bier!" - Homer Simpson

  • den 1. link hab ich schon durch alles mit ssh
    und link 2 auch, die anderen hab ich jetzt eben nicht durchgeschaut


    und was meinst du damit mit falsch konfiguriert ?


    mir geht es nur noch um die restlichen absicherungen....


    ... und ja ich benutze auch einen lokalen test server für ein paar sachen

    Wer Rechtschreibfehler findet, darf sie behalten

  • und was meinst du damit mit falsch konfiguriert ?


    Das Du als Serverbetreiber (außer managed) im vollem Umfang haftbar bist.
    Wenn Du was falsch machst und irgendwer missbraucht den Server, bist Du dafür verantwortlich.

    "Hmm, wo ist denn die Any-Key-Taste? Naja, ich bestell mir erst einmal ein Bier!" - Homer Simpson

  • das ist mir schon klar das einzige was aber auf meinem server lauft sind mc server und ein ts server....


    und mit den konfigs bin ich eig. soweit durch und an den absicherungen bin ich noch dran

    Wer Rechtschreibfehler findet, darf sie behalten

  • Es ist wohl obsolet, dass ich Marcoo hier nicht groß zustimmen muss..


    Da Du jetzt aber wohl kaum den Server kündigen wirst und alles abschalten wirst und es dann erstmal auf deinem Heim-Server probierst, hier mal ein paar Anleitungen speziell für den Apache:
    (Die Anleitungen habe ich nur überflogen, mir fiel dabei jetzt nichts direkt falsches auf)
    (Die Anleitungen solltest Du bitte als Gesamtanleitung und sich ergänzend betrachten)


    Apache2 absichern | Debian-Blog.org
    http://www.paramind.info/data/archiv/apache2_absichern.pdf (Sah am informativsten aus)
    Webserver mit Apache PHP und MySQL – DebianforumWiki (PhpMyAdmin ist NIEMALS NIEMALS von außen erreichbar! (SSH-Tunnel -> localhost) Das ist 'n Fehler in der Anleitung. Anstelle von Logwatch, kannst Du lieber Monit (für deine Vorhaben sollte das reichen) verwenden. Btw. Die Warnhinweise in der Anleitung sind hier besonders passend : ) )
    Apache absichern mit Mod_security » LinuxCommunity
    Apache Webserver absichern (Hier hat schon mal jemand solch eine Frage gestellt und es gab wohl einige die zu viel Zeit hatten)


    Lies' Dir davon bitte alles durch und führe die Maßnahmen Ergänzend zu je Anleitung durch.



    Marcoo: Siehe ersten Satz, aber das Problem ist, abhalten könnten wir ihn eh nicht, also können wir nur verhindern, dass er in den Brunnen fällt. (Das ist wie mit den Drogen und der Jugend von heute... : P - Das ist ein tiefgründig satirischer und sarkastischer Scherz)

    "Hmm, wo ist denn die Any-Key-Taste? Naja, ich bestell mir erst einmal ein Bier!" - Homer Simpson

  • Da Du jetzt aber wohl kaum den Server kündigen wirst und alles abschalten wirst und es dann erstmal auf deinem Heim-Server probierst

    mache ich eh ich mache auf dem root nichts bevor ich es nicht so getestet habe...


    und ich bin imoment eh dabei alle anleitungen durchzugehen
    aber danke

    Wer Rechtschreibfehler findet, darf sie behalten

  • Hallo, hier meine Security-Tipps für Linux:


    Dienste schützen:

    • netstat -tulp checken
    • Nicht benötigte Dienste deaktivieren/deinstallieren
    • Nur lokal benötigte Dienste (z.B. Datenbanken) auf loopback binden (Lokale Adresse: localhost:PORT statt *:PORT)
    • Privat genutzte Dienste beschränken (z.B. mit IPTables auf einzelne IPs begrenzen oder VPNs benutzen)
    • Dienste wenn möglich nicht als root ausführen, pro Dienst ein Account, Rechte möglichst einschränken
    • Verzeichnisse von privat genutzten Web-Anwendungen (z.B. PHP-Skripte) per .htaccess mit Passwort sichern statt über den Login von der Anwendung. Dadurch können Fehler in den Skripten nur mit Passwort ausgenutzt werden.

    Software immer updaten:

    • Für Debian-Systeme: unattended-upgrades
    • Möglichst alles über Pakete installieren (z.B. phpmyadmin) auch wenn man da nicht die aktuellste Version hat, hat man immer alle Security-Updates.
    • Den Rest häufig aktualisieren und Security-Mailinglisten abonnieren

    Sichere Passwörter:

    • Immer sichere Passwörter verwenden, verschiedene Passwörter pro Dienst (Ich empfehle SuperGenPass)
    • Passwörter immer über SSL übertragen

    Andere Tipps:

    • /tmp noexec mounten und gelegentlich auf eigenartige Dateien prüfen (Viele automatisierte Angriffe legen ihren Schadcode in /tmp ab und führen ihn da aus weil da jeder schreiben darf.)
    • Eigene Daten-Partition (einziger schreibbarer Ort für Dienst-Accounts) die mit noexec gemountet ist. Das sollte man nur machen wenn man weiß was man tut, sonst funktionieren hinterher Programme nicht und man hat keine Ahnung warum.


    Wovon ich nicht so viel halte:

    • Firewalls als Allheilmittel, die Dienste dahinter sollten stattdessen gesichert werden
    • Fail2ban, etc. Das ist nur zusätzlicher Code der mit Angreifern in Kontakt kommt und eine weitere Möglichkeit sich selbst auszusperren. Wenn der Dienst sicher ist und das Passwort stark ist braucht man vor den üblichen Loginversuchen keine Angst zu haben. Und einen echten Einbruch bekommt man so auch nicht mit.
  • Quote

    Für Debian-Systeme: unattended-upgrades

    Niemals!


    Wer das macht sollte den Klammeraffen ganz weit wegwerfen, sonst läuft er Gefahr damit Gepudert zu werden!

    Niemals und ich meine niemals unbeaufsichtigte Installationen laufen lassen, schon gar keine Upgrades.


    Dann ändert sich mal beiläufig die PHP-Version und schwuppst funktioniert unter Umständen der schicke, mit viel Mühe zusammen gestrickte, PHP-Code nicht mehr.
    Und das ist nur ein simples Beispiel für solch einen Unfug.


    Wer so etwas macht und dann noch davon redet, dass fail2ban unsinnig sei, dem sollte man in seinen Worten lieber nicht folgen.


    Sorry, aber das ist verdammt gefährlich.

    Quote

    Möglichst alles über Pakete installieren (z.B. phpmyadmin) auch wenn man
    da nicht die aktuellste Version hat, hat man immer alle
    Security-Updates.

    Auch Quatsch, es gibt durchaus bessere und aktuellere Communitys, die weit besser organisiert, bzw. schneller sind als original Quellen. Selbst kompilieren gehört genauso zum Handwerk und man versteht später viel besser was wirklich auf einer Kiste passiert.


    Ein Server ist mit allen zur Verfügung stehenden Mitteln abzusichern.


    Erster Anlaufpunkt ist iptables.
    Pauschal alles sperren und nur das Nötigste öffnen.
    Ports ändern, entsprechende Passwörter verwenden und und und.


    Mit fail2ban kann man sich aussperren, richtig, aber dann hat man auch keine Ahnung wie man das Ding bedienen muss.
    Ich möchte mal sehen, wie man Brutforce oder DDoS-Attacken ohne solche Hilfsmittel abfangen möchte, ohne sich nur auf den Anbieter zu verlassen


    Ein schöner Punkt ist SELinux!
    Oh je, oh je, das Unwort SELinux. Etwas Schickes wenn man damit umzugehen weiß. :)
    Aber sicherlich nichts für Dows.


    Das ist natürlich bei Weitem nicht alles.


    Aber ganz ehrlich, wer angeblich seit längerem Server Beaufsichtigt und sich damit noch nie wirklich damit beschäftigt hat, der hat entweder eine bescheidene Arbeitseinstellung oder einfach nur auf die bunten Graphen des Monitorings geschaut und nach einem fähigen Admin geschrien, wenn es mal zum Gau kam.


    Schon mal CentOS angesehen?
    Mal was anderes als Debian, Ubuntu oder Suse, vor allem von vornherein wesentlich besser abgesichert. Allerdings muss man da viel lernen und es gibt nicht ganz so viele Beschreibungen und HowTo's. Allerdings sind Debian HowTo's auch nicht wirklich die Aktuellsten und man verwendet doch wieder eine Menge Zeit und muss Fehler ausbügeln.


    Ja, so ein Webserver-Admin hat es schon nicht einfach und ohne *RTFM* sollte man auch nicht arbeiten.


    Für die, die nichts mit RTFM anfangen können: RTFM = read the fucking manpage (manuel)


    Viel Erfolg noch beim Lernen.

    Schöne Grüße aus der Lüneburger Heide!
    Thomas

  • dswd Sorry, aber ich glaube ich habe noch nie (!) so viele schwachsinnige und falsche Aussagen in einem Forenpost gelesen ... und Du bist ganz bestimmt nicht der erste hier der sich mit relativ geringem (Halb-)Wissen einen Server holt.


    Du solltest nicht arrogant auf andere Leute herabschauen die du nicht kennst blos weil sie eine andere Meinung haben. Ich habe genug Ahnung von Linux um mir eine Meinung zu bilden und mir zu erlauben diese zu äußern.

    Dass Du die helfenden User als arrogant bezeichnest zeigt eigentlich nur, dass Du keine wirkliche Ahnung hast. Mit fundiertem Fachwissen würdest Du gelassener und sachlicher an eine solche Diskussion herangehen.

  • Ringelnatz: Ich stehe weiter zu meiner Meinung, auch wenn die anscheinend nicht von allen geteilt wird. Ich wollte eigentlich einem Nutzer der um Security-Tipps gebeten hat meine Tipps geben und nicht in einen ideologischen Kampf zum Thema Security einsteigen.


    Ich finde es schade dass anscheinend in diesem Forum keine sachliche Diskussion möglich ist. Du bist bereits der zweite User der meine Sachkenntnis anzweifelt ohne auch nur das geringste sachlich zur Diskussion beizutragen. Welcher von meinen Tipps ist denn "schwachsinnig" und welche meiner Aussagen ist denn sachlich falsch?


    Auch dich möchte ich darum bitten sachlich zu argumentieren und nicht einfach meine Sachkenntnis anzuzweifeln weil dir meine Aussagen nicht gefallen. Im Übrigen glaube ich auch nicht dass ich Nachhilfe in Security brauche aber ich lasse mich gerne in einer sachlichen Diskussion von anderen Standpunkten überzeugen wenn ich falsch liege.

  • Sehe grade, dass Du gar nicht der Threadersteller bist, darauf war der zweite Teil meines ersten Satzes bezogen. Der Rest bezog sich halt maßgeblich auf deine Antwort auf TPIT-Services Post. Dieser hat übrigens wohl - ganz im Gegensatz zu mir, das gebe ich zu - sachlich argumentiert. Und da ich seine Meinung teile halte ich Deine Antwort darauf größtenteils für Unfug. Fail2ban macht keinen Sinn, da die Firewall groß angelegte Angriffe eh nicht packen würde? Hmm.
    Zuletzt ärgert es mich einfach, dass Du (wie viele anderen) andere Meinungen direkt als persönlichen Angriff wertest und entsprechend pampig reagierst. So bekommst Du wirklich keine sachliche Diskussion.

  • Naja, so richtig sachlich hat er auch nicht argumentiert. Die Furcht vor zerstörerischen Versionssprüngen bei Security-Updates halte ich für unbegründet.


    Zu Fail2ban:
    Das Prinzip von Fail2Ban ist relativ einfach, Anwendungen loggen alles mögliche verdächtige und Fail2Ban sammelt das ein und sperrt die IPs die häufig auftauchen temporär. Hier gibt es aus meiner Sicht mehrere grundsätzliche Probleme:
    1) In den Logs tauchen auch Daten auf die die Angreifer definieren können (z.B. ungültige Benutzernamen, ungültige Hostnamen, etc.) und Fail2Ban parst diese Daten auch gleich mit. Damit gibt man Angreifern eine deutlich größere Angriffsfläche. In der Vergangenheit ist es auch schon häufiger vorgekommen dass Fail2Ban Fehler hatte durch die Angriffe erst möglich wurden. Da konnte man unter anderem beliebigen Code ausführen oder beliebige IPs auf die Sperrliste setzen.
    2) Fail2Ban sperrt IPs erst wenn sie mehrfach in den Logs auftauchen. D.h. Fail2Ban sperrt Angriffe erst nach ein paar Versuchen. Dadurch kann man nur eine bestimmte Klasse von Angriffen überhaupt verhindern, nämlich die die mehrfach ausgeführt werden müssen und dann doch irgendwann zum Ziel führen oder eben Angreifer die "rumprobieren".
    3) Fail2Ban läuft nur auf einem Host aber viele Angriffe werden auf ganze IP-Bereiche geführt. Hier kann der Netzbetrieber/Hoster die Muster besser erkennen und Angriffe schon nach wenigen Hosts stoppen. Ich bin mir sicher dass NetCup sowas macht und damit recht erfolgreich gegen viele Angriffe vorgeht.


    Quote

    Fail2ban macht keinen Sinn, da die Firewall groß angelegte Angriffe eh nicht packen würde? Hmm.


    Sowas habe ich nicht gesagt/gemeint. Ich habe mich spezielle auf DDoS bezogen. Bei DDoS wird man üblicherweise von Botnetzen mit mehreren Tausend IPs angegriffen. Oft sind die Botnetze so groß dass sie nicht einmal das komplette Botnetz für so einen Angriff brauchen. Außerdem verwenden die Botnetze für ihre Angriffe reguläre Anfragen die auch von normalen Usern kommen könnten aber auf deiner Seite viele Ressourcen binden.
    Dadurch hast du mehrere Probleme:
    1) Du eingesetzte Software müsste zu den Anfragen Logeinträge schreiben die es Fail2Ban ermöglichen auf einen Angriff zu schließen; die Anfragen sehen aber normal aus.
    2) Der angegriffene Dienst muss lange genug funktionieren um mehrere Logeinträge mit der gleichen IP zu schreiben damit Fail2Ban die IP auf die Sperrliste setzen kann.
    3) Du müsstest Tausende IPs sperren damit keine Anfragen mehr zu dem Dienst kommen. Vorher ist dein Dienst zusammengebrochen und logt nichts mehr oder dein Link ist so ausgelastet dass in dem Scanintervall keine 3 Anfragen von der gleichen IP durchkommen.
    4) Selbst wenn du alle 3 Hürden genommen hast, können selbst die blockierten Anfragen noch dazu führen dass dein Link total dicht ist.
    Deshalb halte ich von Fail2Ban gegen DDoS nicht viel. Gegen einfach gestrickte DoS-Angriffe mag es evtl. helfen aber nicht gegen echten DDoS.

  • Guten Tag,



    ich schließe diesen Beitrag. Hier im Forum ist ein respektvoller Umgang miteinander erwünscht. Nur weil jemand eine andere Meinung hat, ist dass kein Grund solche Ausdrucksweisen zu nutzen wie hier im Thread geschehen.


    Alles wesentliche ist denke ich gesagt worden, was der Threadopener wissen wollte.


    Ich wünsche Ihnen allen ein sonniges und erholsames Wochenende!



    Mit freundlichen Grüßen


    Felix Preuß