Beiträge von dswd

Das ist eine philosophische Frage. Der Gedanke hinter Docker ist ja gerade dass das gesamte System über eine kleine Config-Datei (Dockerfile) beschrieben ist und sich jederzeit ohne Probleme neu bauen lässt. Dadurch hat man alle möglichen Vorteile aber man sollte dann natürlich auch keine Änderungen (z.B. Updates) per Hand außerhalb des Dockerfiles vornehmen.

Außer diesem philosophischen Unterschied sehe ich keine großen technischen Unterschiede (beides basiert auf LXC), oder hab ich da was übersehen?

Zitat von Gymnae

Was ich aber noch nicht ganz verstehe: Wenn nun noch z.B. ein wordpress dazu kommt, eine webmailer paket oder eine gallerie, dann bringen die alle u.U. andere base images mit und ihre eigenen Webserver. Die idlen dann die ganze Zeit und cachen RAM. Festplattenplatz ist die eine Sache, aber wie ist das mit cycles, RAM und Pagefiles?

Teilen sich Docker container alle Resourcen fair auf, d.h. wenn in einem Container ein Webserver nichts zu tun hat, nimmt ihm Docker dann die Ressourcen weg und gibt diese frei?

Ja, genau so läuft das. Docker Container sind keine VMs sondern nur eigene Namespaces. Alle Prozesse im Container sehen ihr eigenes Dateisystem, ihren eigenen Speicher und nur Prozesse innerhalb des Containers aber im Prinzip sind das einfach nur Prozesse auf dem Host.

Wenn du viele Webserver laufen hast frisst das schon etwas mehr Speicher als wenn du nur einen hast. Nginx sollte etwas schlanker sein als Apache, damit kannst du das ein wenig abspecken. Ram, Cycles und Swap (Pagefile gibt es nur unter Windows) werden alle brüderlich geteilt, da gibt es keinen Overhead.

Hallo,

ich habe auf meiner VM mehrere Container laufen ohne spürbaren Overhead. Wenn dir die normalen Images zu fett sind kannst du dir auch einfach eigene bauen, ich empfehle Alpine Linux als Basis. Bei den Containern solltest du nur darauf achten dass sie automatisch starten weil die VMs ja gelegentlich rebootet werden. Außerdem brauchst du bei mehreren Web-Containern noch einen eigenen Proxy davor.

Kleiner Tipp: Lieber per GlusterFS mouten

Ich hatte beim mounten per NFS immer wieder Probleme. Mein Storage war ständig voll ohne dass ich den Platz wirklich verbraucht hatte. Der Support hat behauptet das läge an Hardlinks oder temporären Dateien, kann ich aber beides ausschließen, hat ja 8 Monate ohne Probleme funktioniert. Seit ich das Volume per GlusterFS mounte geht das jetzt ohne Probleme. Anscheinend gab es da Ende Oktober eine Änderung die bei mir zu dem Fehler führte.

Hi, ganz wichtig bei einem solchen Umzug ist dass du vorher die TTL von deiner Domain runterschraubst (5 Minuten oder so). Ansonsten ist der Eintrag noch lange im Cache und es wird gleichzeitig auf beider Server zugegriffen.
Ansonsten empfehle ich schon vorher alles rüber zu kopieren und beim Umschalten dann nur Änderungen per rsync zu Übernehmen. Ich weiß aber nicht ob das bei deinen Angeboten geht.
Wichtig ist auch noch den alten Server zu deaktivieren damit da nicht doch noch drauf zugegriffen wird (evtl. über IP oder so).

Zitat von [netcup] Felix

das wird nur auf eigenen Nameservern möglich sein. Eine niedrige TTL erhöht die Anfragen auf Nameserver. Da unsere Nameserver für viele tausende Domains zuständig sind, hätte es drastische Auswirkungen auf die Verfügbarkeit der Nameserver wenn hier viele Domains eine niedrige TTL gesetzt hätten.

Ja, ich hatte schon damit gerechnet, macht ja auch Sinn.

Zitat

Eventuell wird es ein Feature geben, dass temporär die TTL herunter gesetzt werden kann. So etwas wäre denkbar.

Das wäre für meinen Use Case völlig ausreichend. Dann vergisst man das auch nicht zurückzusetzen. Beim letzten mal musste ich halt gleich zwei mal den Support bemühen, einmal für die kurze TTL und einmal für den Reset auf die normale. Das ist halt schon aufwändig und die Support-Mitarbeiter haben ja auch genug zu tun.

Hallo,

es wäre praktisch wenn man für die Einträge auch die TTLs setzen könnte.
Dann könnte man Domains umbiegen ohne den Support zu bemühen oder längere Downtimes durch Caching zu riskieren.

Wenn die Nutzer nicht die volle Kontrolle über die TTLs bekommen sollen, würde auch eine Option reichen um die TTL für ein paar Tage auf 5 Minuten runterzusetzen.

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.

Zitat

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.

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.

Zitat von TPIT-Service

Das Paket heißt nur unattended-UPGRADES, in Wirklichkeit geht es ausschließlich um Security-Updates und dabei ändert sicht normalerweise nicht mal die Minor-Version geschweige denn die Major-Version. Wer versucht per Hand mit Security-Updates hinterher zu kommen ist im Schnitt für deutlich längere Zeit im Jahr verwundbar. Und oft sind zwischen Fix und Exploit nur wenige Tage oder sogar Stunden.

Erfährst du immer von allen Sicherheitlücken in selbstinstallierten Anwendungen sofort und hast umgehend Zeit die upzudaten? Dann herzlichen Glückwunsch, 99% der Admins (und ich rede hier nicht nur von Amateuren) schaffen das nicht schnell genug.

Das ist bei Linux normalerweise so. Auf einem normalen Server ist nur SSH vorinstalliert, das will man dann auch nicht sperren. Firewalls braucht man meistens nur dann wenn man einen Port auf bestimmte IPs beschränken will oder einen Dienst auf localhost beschränken will bei dem man das nicht konfigurieren kann.

Fail2ban ist mit Vorsicht zu genießen. Es scannt mit diversen Filtern in Logdateien nach verdächtigen IPs und sperrt diese. Viele Dienste loggen auch noch neben den IPs unbekannte Benutzernamen und erlauben so den Angreifern einen Teil der Logeinträge selbst zu bestimmen. Fail2ban parst das dann und stolpert immer mal wieder über speziell präparierte Einträge. Schau dir mal die CVEs zu Fail2ban an.
Gegen die meisten DDoS-Attacken hilft Fail2ban auch nichts. Das erste D steht für "distributed", das bedeutet dass du zwar Tausende gesperrte IPs hast aber immer noch angegriffen wirst. Außerdem verwenden viele DDoS-Attacken Zugriffsmuster die nicht verdächtig sind und von Fail2ban garnicht erkannt werden können.
Für Bruteforce auf gute Passwörter ist das Netz normalerweise zu langsam. Wer da aber Angst vor hat sollte lieber eine spezielle Firewall-Regel zum drosseln der Anfragen pro IP verwenden.

Ja, deshalb hab ich das nicht erwähnt. Damit hat Otto-Normal-User nur Probleme.

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.

Alles anzeigen

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.