Beiträge von frostschutz

  • einrichten einer neuen ipv4 adresse

    *blinzel* 10 Jahre alte Anleitung? Steht so auch im Wiki? Hrmmm.

    Was EIGENTLICH funktionieren sollte ist "address ersteip zweiteip dritteip" aber bei Debian kann das nochmal 10 Jahre dauern. ;) Bei Ubuntu scheinbar schon passiert.

    Evtl. auch noch interessant:

    https://wiki.debian.org/NetworkConfigu…n_one_Interface

    Ich bin da ganz unten beim Manual Approach nur ohne das Alias/Label-Zeug. Also für jede IP ein up/down ip addr add/del 1.2.3.4/32 dev dings

    Aliase haben oft für Missverständnisse gesorgt (sieht aus wie ein eigenes Netzwerkinterface, ist aber keins) und sind offiziell obsolet. Steht so auch in linux/Documentation/networking/alias.txt """ IP-aliases are an obsolete way to manage multiple IP-addresses/masks per interface.

    Aber es funktioniert ja und das ist dann wohl die Hauptsache...

  • Ist utf8 nicht gleich utf8?

    utf8 ist utf8, aber bei (mysql) Datenbanken gibts den Sonderfall, daß dort utf8 historisch nur bis 3 bytes geht, aber neue Zeichen 4 bytes brauchen. und dafür hat die Datenbank dann einen neuen Zeichensatz erfunden, utf8mb4. Was effektiv bedeutet, daß du eigentlich alle Datenbanken auf utf8mb4 umstellen musst, weil utf8 nicht mehr reicht und dann komische Sachen passieren, wenn die Leute mit ihren neumodischen Emojis ankommen.

    Wenn du statt einem Umlaut zwei komische Zeichen siehst, dann hat irgendwas anderes in der Kette utf8 nicht unterstützt sondern z.B. latin1 gesehen und somit den utf8-Umlaut (ein Zeichen zwei Bytes) als zwei Zeichen verstanden. Da muss man dann einfach suchen. Manchmal ist es schon der mysql-Dump selber, der zwar richtig in UTF-8 kodiert ist aber dann trotzdem nicht UTF-8 (als Zeichensatz für die Übertragung) setzt.

    Wenn man mysqldump o.ä. Tools verwendet um die Datenbank zu sichern, müssen das auch neue Versionen sein die utf8mb4 unterstützen, sonst werden alle utf8mb4 Zeichen stillschweigend zu Fragezeichen. Ganz ohne Fehlermeldung, merkt man erst wenns zu spät ist. Das kann passieren wenn man mit altem Debian, CentOS unterwegs ist, für utf8mb4 sich ein MariaDB irgendwo her organisiert hat, aber mysqldump noch das Tool vom alten mysql ist das von utf8mb4 nie was gehört hat...

  • Welche Linux-Distribution setzt Ihr ein?

    Server: früher Debian, heute ArchLinux. Hat sich bei der Systemd-Umstellung so ergeben, es war bei Debian eine Zeit lang nicht klar ob das reibungslos klappt, ArchLinux ausprobiert die das schon länger verwenden und dabei geblieben.

    Für Familie, Laptop, ohne große Anforderungen, Hauptsache mal eben schnell ein Linux installiert: Ubuntu.

    Eigener Desktop: seit Ewigkeiten Gentoo. Versuche, hier auch auf ArchLinux zu wechseln, sind bislang gescheitert.

    Auf der einen Seite brauche ich das, was Gentoo bietet, eigentlich schon lange nicht mehr (Compilerflags und Useflags, geh bitte) und mir gefällt das Paketmanagement bei ArchLinux viel besser (auch Rolling Release aber nicht Ewigkeiten warten bis der ganze Schlamassel compiliert ist).

    Auf der anderen Seite renne ich bei ArchLinux als Desktop immer in mysteriöse Probleme. Wenn ich bei einer frischen ArchLinux Installation im Xorg mit xterm/urxvt als allererstes mit vollkommen unlesbar verpixelten Schriften begrüßt werde, habe ich schon fast keine Lust mehr. ArchLinux ist eben mehr so eine Debian debootstrap Minimal-Installation, prädestiniert für Serveranwendungen. Wenn man das auf einen vollen Desktop hochziehen will, hat man was zu tun.

    Das hängt natürlich auch damit zusammen, daß ich im GUI-Bereich eklatante Wissenslücken habe. Ich arbeite sehr viel mit dem Terminal und habe mir nie sonderlich die Mühe gemacht, GUI-spezifische Sachen wie fontconfig & Co zu durchschauen. Wenn ich dann auf der grafischen Oberfläche ein Problem mit Schriftdarstellung habe, weiß ich schlichtweg nicht, wo ich da anfangen soll nach der Ursache zu suchen.

    Und solange man wieder mit 1 Klick ins alte Gentoo gebootet hat wo der Hase einfach läuft, dann ist die Motivation auch gering, sich damit auseinanderzusetzen.

    Wenn man lange eine Distro eingesetzt hat, dann ist man davon abhängiger, als man denkt. Ich bin immer wieder überrascht wenn in anderen Distros irgendein Konzept ein anderes ist (Initramfs, cron, ...). Und Tricks die man in einer Distro kennt, sind eben auf andere nicht so unbedingt übertragbar. Und manche Programme verhalten sich im Detail anders, ohne daß man jetzt unmittelbar weiß, woher das kommt, weil da irgendeine Default-Konfiguration je nach Distro abweicht. Und dann geht die Sucherei eben los...

  • SSH Port ändern lohnt sich - die Statistik

    Zitat

    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.

    Zitat von julian-w

    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.

  • SSH Port ändern lohnt sich - die Statistik

    Zitat von julian-w

    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.


  • SSH Port ändern lohnt sich - die Statistik

    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. ;)

  • Umgang mit Sicherheitslücken in CPUs (Meltdown & Spectre)

    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" ?

  • Umgang mit Sicherheitslücken in CPUs (Meltdown & Spectre)

    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
    Jan 05 22:37:52 KVM systemd-logind[446]: Power key pressed.
Jan 05 22:37:52 KVM systemd-logind[446]: Powering Off...
Jan 05 22:37:52 KVM systemd-logind[446]: System is powering down.
...

  • Umgang mit Sicherheitslücken in CPUs (Meltdown & Spectre)

    Zitat von MisterQuatsch

    Werden die Neustarts jetzt auch noch in der Nacht durchlaufen oder sind diese jetzt erstmals pausiert?

    Mein vServer ist gerade down.

    Von außen betrachtet (hatte in einer offenen SSH ein dmesg --follow laufen) war er einfach so plötzlich weg. Kann ja trotzdem sauber runtergefahren worden sein (nachdem das Netzwerk schon down war). Muss ich mal in die Logs spicken wenn er wieder da ist.

  • bootloader GRUB kaputt

    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. ;)

  • monatliches Fullbackup, tägliches inkrementelles Backup

    Zitat von casati
    Code
    # 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.

    Zitat von casati


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

    Code
    [NETCUP:USER]$ sudo visudo


    Folgende Zeile anfügen:

    Code
    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.

  • Performance der Bildschirmdarstellung

    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.

  • Netcup Cup

    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 :)

    :thumbup:

  • Weihnachtskalender 2015

    Zitat von fibis

    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.