Posts by frostschutz

    Quote

    Du vermittelst den Eindruck, fail2ban zu benutzen wäre was für "Anfänger"


    Zunächst einmal ist das nicht der Eindruck den ich vermitteln möchte. Ich sag gar nichts gegen fail2ban. Ich sag auch nix gegen Portänderungen. Mach ich ja eh selber. Ich sag nur daß das im Prinzip beides in die gleiche Richtung geht, das eine wird verteufelt, das andere auf ein Podest gehoben. Das eine ist eben angesehener/akzpetierter als das andere. Viele Leute installieren Linux, haben ganz schräge Firewall-Sachen am Start und "ohne Firewall wirst du sofort gehackt" und... das ist eben nur sehr oberflächlich betrachtet so.


    Und da sind wir beim Punkt: 100% Sicherheit gibt es nie, was gerade die jüngste Vergangenheit gezeigt hat, sei es Spectre, Meltdown, Heartbleed oder sonst was. Und dann ist es doch besser, wenn man potentielle Angreifer frühzeitig aussperrt, anstatt sie "unendlich lange" probieren zu lassen.


    Ja, ist ja auch ein Argument für Portänderungen. Für den Fall daß mal eine unbekannte Sicherheitslücke alle SSHDs der Welt angreifbar macht, ist es doch besser, der SSHD läuft nicht auf dem Standardport sondern woanders, wo du dann vielleicht nicht so schnell gefunden wirst. Kann so passieren. Ändert nichts daran, daß das alles als Security by Obscurity anzusehen ist.


    Bei Sicherheitsmaßnahmen geht man immer von einem theoretischen Angreifer aus, dem maximale Resourcen zur Verfügung stehen. Bei Festplattenverschlüsselung investiert man X-hunderttausend Iterationen (und bald massenhaft RAM) in die Schlüsselableitung, um es rein rechnerisch und technisch unmöglich zu machen, das in sinnvoller Zeit zu knacken, auch mit 100-Millionen-Dollar Hardware. Bei SSH & Co analog mit Keys die soviel Entropie-Zufallsbits haben daß es schlichtweg völlig unmöglich ist, da durchzukommen. Bei IPv4 gibt es 4294967296 IPs, 1 davon gehört dir, der Rest dem Gegner. Dein Sicherheitskonzept muss dieses Szenario überleben und deswegen heißt es überall: mach SSH nicht mit Passwörtern sondern mit 4096-BIt-Keys. Auch wenn ein ausreichend langes Passwort (z.B. 12 Zufallswörter) genauso wenig zu knacken und praktisch kein Unterschied machen würde, man tut das einfach nicht weil es eine bessere Lösung gibt.


    fail2ban kann soll darf man ruhig machen. Aber man braucht sich nicht einbilden, daß es eine starke Sicherheitsmaßnahme ist. Wer das umgehen möchte der kann das einfach tun. Wer 100'000 geleakte Keys hat und weiß, einer davon gehört dir, dann wird der sich ein Botnetz mieten und von 100'000 IPs je eine Anfrage zu dir schicken, kein Ding. Wenn es jemand wirklich auf dich abgesehen hat und was in der Hand hat gegen dich, dann bringt das mit fail2ban gar nichts.

    Das ist eine echte Sicherheitsmaßnahme, die effektiv Brute-Force Attacken verhindert.





    Das System muss sicher sein, egal ob dein SSH auf Port 22 oder 222 läuft, egal ob du fail2ban benutzt oder nicht. Ist das so, dann hast du Security. Der ganze Rest ist Obscurity.


    Wenn du ausschließlich mit Key-Auth arbeitest und nicht mit "passwort123", und du deine Keys nicht vor X Jahren mit Debian erzeugt hast die da so einen lustigen Bug hatten in ihrem Zufallsgenerator mit nur 32768 möglichen Ergebnissen, dann ist Bruteforce von vorneherein ausgeschlossen.


    Umgekehrt kann man sich nicht darauf verlassen, daß mit fail2ban schwache Passwörter nicht trotzdem erraten werden können. Du musst immer davon ausgehen, daß ein Angreifer auf einen entsprechend großen IP-Pool zurückgreifen kann, mit dem ein Brute-Force dann keineswegs verhindert wird. Detailfragen kommen dann noch hinzu, wie gehst du mit IPv6 um, sperrst du da gleich ganze Subnetze, wenn ja in welcher Größe?


    Die einzige praktische Auswirkung von fail2ban ist eigentlich, daß man sich gelegentlich selbst aussperrt. Bei allen anderen ist es egal ob du sie sperrst oder nicht, solange dein System sicher ist, kommen die eh nicht rein. Das ist dann nur Schönung von Traffic/Logs/... aber keine echte Sicherheitsmaßnahme mehr.


    Das heißt nicht daß du auf fail2ban verzichten sollst. Im Gegenteil, kann jeder gerne machen. Ditto bei Portänderungen, jeder wie er will. Auf "Sicherheit" als solches hat das aber nur sehr begrenzt Auswirkung.


    Gefährlich wird es dann wenn man sich auf unwirksame Maßnahmen verlässt. Ein offener SSHD wird nicht sicher wenn er auf einem anderen Port läuft oder wenn fail2ban ins Log schaut. Der SSHD muss zuerst sicher sein und dann kannst du das andere Zeug machen wie dir beliebt.






    Es ist auch ein Unterschied ob du alleine am Server bist oder beliebige User darauf ihr Unwesen treiben. Wenn du "aus Gründen" unsichere Passwortlogins für Hinz und Kunz erlaubst, dann ist fail2ban natürlich der verzweifelte Versuch, Sicherheit herzustellen wo keine Sicherheit möglich ist.






    Ich ändere meinen SSH-Port auch, solange ich der einzige SSH-Nutzer bin. Nicht als Sicherheitsmaßnahme sondern einfach für die Übersicht.


    Ich würde gerne wissen, wenns jemand speziell auf meinen Server abgesehen hat, ich schaue also durchaus mal das sshd und andere Logs an, wer da so klingelt.


    Der Standardport wird sowas von sinnlos zugespammt, und das Logfile dementsprechend vollgemüllt. Mit geändertem Port ist das deutlich übersichtlicher.


    Andere sorgen mit fail2ban o.ä. Geschichten für diese Übersicht. Dabei ist fail2ban im Prinzip auch nur reine Obscurity. Wenn du eine Sicherheitslücke hast, dann kommen die beim ersten Versuch rein bzw. holen sich einfach eine neue IP, das ist ja kein Problem. Aber das ist halt "kulturell akzeptierte" Obscurity wogegen die Leute Hautausschlag bekommen wenn du nur anfängst, was von geändertem SSH-Port zu faseln. ;)

    Bodenhaltung : Auch mal ganz rausgegangen aus dem SCP? Bei mir war das zuerst auch so, neu eingeloggt und siehe da, Server war seit zig Minuten on aber hat den Bootvorgang einfach aus anderen Gründen nicht geschafft (verhauenes Kernelupdate).


    Auf meinem vServer funktioniert Spectre dann immer noch (gibts keinen Patch für) und Meltdown funktioniert, wenn vServer mit altem Kernel läuft bzw. der Kernel mit nopti gestartet wurde. Ich hatte ja gehofft, es würde reichen, wenn der Host das erledigt, aber scheinbar reicht das nicht (bei vServer mit dediziertem Core) und der Bug ist dann - zumindest innerhalb der VM - noch aktiv? Blickt da noch jemand durch...


    iLion : journalctl --since="1 day ago" ?

    Operation erfolgreich, Patient tot (ich hab natürlich das Kernelupdate zersägt und durfte so erst einen Abstecher ins Rescue machen). Server wurde sauber heruntergefahren und läuft jetzt wieder. Mein Dank an Netcup für die ganze Aktion so kurzfristig im Neuen Jahr.


    Code
    1. Jan 05 22:37:52 KVM systemd-logind[446]: Power key pressed.
    2. Jan 05 22:37:52 KVM systemd-logind[446]: Powering Off...
    3. Jan 05 22:37:52 KVM systemd-logind[446]: System is powering down.
    4. ...

    Beim [scheinbar etwas angestaubten] Rettungssystem bekomme ich meine Dateisysteme gar nicht erst gemountet (XFS, irgendein Unknown Flag error). Macht aber nix, man kann ja eine SystemRescueCD booten (und wenn die auch zu alt ist eine aktuelle ISO hochladen).


    Interessanter wäre warum OpenSuSE überhaupt das Grub beim Update zersägt. Ich kenne die Distribution nicht, aber bei Ubuntu gibts sowas, daß in irgendeiner vergrabenen Datei gespeichert wird auf welches Device GRUB installiert worden ist / werden soll und wenn dort das falsche hinterlegt ist, dann knallt es halt. Da braucht man dann ein dpkg-reconfigure grub-pc und das richtige Device auswählen und gut. Vielleicht ist das bei OpenSuSE ja sowas ähnliches. Wenn man keine Images benutzt sondern "selber" installiert hat man vielleicht eher Chancen daß solche Sachen automatisch richtig sind - wer weiß.


    Root-Passwort direkt im SCP ändern ist ganz lustig... wird ein Script sein das alle Dateisysteme/LVs durchmountet und schaut wo eine etc/{passwd,shadow}- liegt und die zu ändern ist ja dann mehr oder weniger systemübergreifender Standard? Gechrootet wird da eher nicht, das ist dann eigentlich schon eine Stufe zu haarig tatsächlich was von den installierten Binaries auszuführen. Mir ists eigentlich lieber wenn der Hoster die Finger von meinen Dateisystemen läßt, aber man muss das Feature ja nicht verwenden. ;)

    Code
    1. # cat ~/.ssh/id_rsa.pub | ssh USER@NETCUP-IP -p 12345 "mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"


    Dafür gibts den Befehl 'ssh-copy-id'. SSH will für .ssh/authorized_keys ganz bestimmte Rechte sehen, das geht bei deiner Variante womöglich schief.



    2. Einrichten 'rsync' auf NETCUP als 'sudoer" Prozess für NETCUP-User (USER)

    Code
    1. [NETCUP:USER]$ sudo visudo


    Folgende Zeile anfügen:

    Code
    1. USER ALL=NOPASSWD:/usr/bin/rsync


    sudo nopasswd auf rsync mag ich nicht so, ein User der rsync so nutzen darf ist damit effektiv selber root...


    Bei rsync wird ein Perlscript mitgeliefert, rrsync (restricted rsync), damit kann man einen SSH Key auf read-only rsync und bestimmte Unterverzeichnisse einschränken und damit ausschließlich zum Backups ziehen verwenden. Damit habe ich bislang ganz gute Erfahrungen gemacht.


    Anstelle des --exclude könnte man was mit bind-mount machen.

    Ich habe erst nicht gewusst was du meinst... weil ich so wie immer im VCP unterwegs war. Das SCP ist ja mal ein tolles Teil, endlich sieht man mal die Server-Nicknamen. ;)


    Die VNC-Konsole sieht aber immer noch genau gleich aus? Verzögerungen hab ich da keine, aber auch nichts grafisches am laufen.

    southy : Bei den normalen Sonderangeboten steht auch noch ein schöner Server mit dedizierten Kernen. Vielleicht ist das ja was für dich... wenn beim Adventskalender nichts dabei gewesen wäre, hätte ich es wahrscheinlich mit dem versucht.


    VPS sind es am Ende im Prinzip eh alle...

    Bei mir hat der Postbote heute (nicht) geklingelt (sondern vor der Tür abgestellt).


    Ich habe also heute die Überraschung erhalten vielen Dank dafür und eine Tasse lag als Beilage auch dabei :)


    :thumbsup:

    Die Kerne sind virtuell und nicht dediziert. Spürt man da eigentlich einen Unterschied?


    Nach einem Wechsel auf vServer mit virtuellen CPU-Kernen hatte ich heftige I/O-Performanz-Probleme... aber da ist auch irgendein Bug im Spiel, sei es im Host-KVM oder im Gast-Kernel. Ich glaub das Problem ist bis heute nicht behoben...


    Ob das direkt mit virtueller CPU zusammenhängt weiß ich natürlich auch nicht :) aber wenn mein jetziger Server ausläuft (Ende nächstes Jahr) werd ich auf jeden Fall schauen ob Netcup nicht was schönes im Angebot hat.

    Knud : Bei so tollen Adventskalenderangeboten rumheulen und mit ":thumbdown:" Smileys zu kommen ist voll daneben. Du hast den Sinn der Aktion wohl nicht so ganz verstanden...


    Endlich weiß ich was ein Johann ist. Brauchen tu ich ihn zwar nicht aber :thumbsup: von mir.

    Hallo,


    da heute im Adventskalender ja Domains angeboten werden habe ich heute für drei Domains DNS editiert. Dabei sind mir zwei Dinge aufgefallen:


    1)


    Wenn ich versuche einen MX Eintrag zu ändern in einen A / AAAA / sonstwas, dann wird das mit einer Fehlermeldung quittiert selbst wenn der Eintrag richtig ist. In dem Moment wo man statt MX irgendwas anderes ausgewählt hat, verschwindet das Eingabefeld für MX-Priorität. Der darin enthaltene Wert scheint aber immer noch Beachtung zu finden, die Fehlermeldung ist dann Fehler: Eintrag ungültig: test A 10 1.2.3.4 und die 10 war eben das was im nicht mehr sichtbaren MX-Priorität-Feld stand. Um den Eintrag doch editieren zu können muss ich wieder MX auswählen, in das Priorität-Feld eine 0 eintragen (leer lassen geht auch nicht), und dann wieder zurück zu dem was ich eigentlich haben wollte.


    Im gleichen Schritt gehen auch alle anderen Einträge/Änderungen verloren so daß man nicht einfach nur diesen einen Fehler korrigieren und weitermachen kann, sondern alles wieder neu schreiben muss. Solange das Formular Eingaben wegen Fehlern verliert ist es also besser jede Änderung einzeln zu speichern...


    2)


    Das ist mehr dem Perfektionismus geschuldet, aber wenn man neue Einträge hinzufügt landen die irgendwie wie Kraut und Rüben in der DNS-Liste und nicht entweder a) in der Reihenfolge in der ich hinzugefügt habe oder b) irgendwie sortiert. Wegen der Sortierung habe ich auch erst probiert Einträge zu editieren statt einfach zu löschen und neu hinzuzufügen.


    Konkretes Beispiel, in einem Schritt neu hinzugefügt:


    Code
    1. 01 A 1.2.3.4
    2. 02 A 1.2.3.4
    3. 03 A 1.2.3.4


    Ergebnis:


    Code
    1. ... Alte Einträge...
    2. 01 A 1.2.3.4
    3. ... Alte Einträge...
    4. 03 A 1.2.3.4
    5. 02 A 1.2.3.4


    Also 01 irgendwo zwischendrin und 03 02 falsch herum. Weiß nicht wie das kommt, werden da alte gelöschte Slots wiederverwendet oder sowas?


    Technisch spielt es ja weiters keine Rolle, aber solange die DNS Einträge von Menschen editiert werden wäre eine sortierte Darstellung der Einträge schön, oder gar die Möglichkeit im Formular die Reihenfolge der Einträge selbst ändern zu können...


    Gruss
    frostschutz