Aus der Tiefe

Mon, 10 Jul 2023 13:28:00 +0200

	Updates, die von Attacken schwer zu unterscheiden sind, Teil II
	Am Donnerstag, dem 29. Juni, hat ein Microsoft-Patch für das Active-Directory
	vom RRZE unseren Netapp Filer für alle Windows-Userinnen unbenutzbar gemacht.
        Der Filer hat einige Jahre auf dem Buckel, war aber auch extrem teuer.
        Leider hat er kein ssh-fähiges Interface zu den Filesystemen, so dass
        etwas Gehacke nötig war, die Daten der Userinnen auf eine
        andere Maschine umzuziehen (keine Authentisierung...). Die Rechte-Struktur
        auf der Ersatzmaschine so nachzubaun, dass die Richtigen aufs Richtige
        von Windows aus zugreifen können, war nicht so einfach. Dass
        netapp für die älteren OnTAP Versionen keinen Patch zur
        Verfügung stellt, ist sehr enttäuschend.
        Und dass ich seit mehr als einer Woche noch drauf warte,
        dass mein Antrag auf Zugang zur netapp KnowledgeBase bearbeitet wird,
        auch...

Mon, 26 Jun 2023 00:00:00 +0200

advancedpersistentthreat upgrade Am 5. Mai hat ein Ubuntu Update von Ruby das Puppet zerschossen, weil die puppet:/// URLs ab da falsch geparst werden:

Wie ich das gemerkt hab, war meine erste Reaktion: "dann nageln wir die Ruby Version in /etc/apt/preferences.d fest und verhindern den Upgrade". Ja, aber wie krieg ich das auf die betroffenen Rechner, wenn Puppet nicht mehr geht? Zwei Tage später haben die Ubuntesen den Patch wieder zurückgerollert.

Gegen Angreifer gibt mir das System einige Werkzeuge, dass die da nicht root werden und Blödsinn machen. Gegen Package-Updates mit cronapt hilft nix, weil die über Nacht beliebige post-install Skripte als root ausführen. Und nicht Upgraden geht auch nicht, weil die CVEs im Stundentakt einschlagen. Und die Maintainer brauchen gar nicht bösartig oder inkompetent sein, bei 10⁶ Packages und Abhängigkeiten und schlecht zu testenden Nebeneffekten (wie den seltsamen puppet:/// URLs) haben die keine Chance, keine Fehler zu machen.

Fri, 17 Mar 2023 00:00:00 +0100

	Zabbix-Proxy auf Ubuntu
	   Nach dem Upgrade auf den neuen Zabbix Proxy kam 
             systemd[1]: zabbix-proxy.service: Can't open PID file /run/zabbix/zabbix_proxy.pid (yet?) after start: No such file or directory
	   Rumgesucht, den Pfad gibts, gehoert den Richtigen. Ists in unserer Config falsch???
	   In /etc/zabbix/zabbix_proxy.conf kann man ein PidFile angeben, das
	   ist der Pfad zum PID file. Kann man machen. Aber in /etc/init.d/zabbix-proxy:
                DIR=/var/run/zabbix
                PID=$DIR/$NAME.pid
           wird das hart druebercodiert. Fein, dann nehmen wir eben den Pfad.
           Hilft aber nix, weil auf PoetteringOS alles nochmal wo ganz anders stehen muss, 
           naemlich in /lib/systemd/system/zabbix-proxy.service:
                PIDFile=/run/zabbix/zabbix_proxy.pid
           Aber auch diesen Pfad gibts, gehoert den Richtigen, usw.
	   In den Logs steht dann aber statt was mit Pidfile:
		The proxy does not match Zabbix database. Current database version (mandatory/optional):
		05000000/05000004. Required mandatory version: 06000000.
	   Die Vehlermehldung selbst war also phalsch, nicht das Pidfile, sondern das
	   Datenbankschema ist das Problem. Nachdem der Proxy eh nur umschaufelt, reichte
	   es, das sqlite-file zu loeschen, damit eine neu schematisierte DB angelegt wird.

Tue, 07 Jun 2022 00:00:00 +0200

	Ubuntu Upgrades...
	Aus "Never change a running system!" folgt natuerlich "Never upgrade a running system!".
	Und die Kwalitätssoftware, die man in PoetteringOS so hat, macht das deutlich:
	Wenn man Ubuntu in zwei Schritten von xenial ueber bionic auf focal upgraded, dann aendert
	sich die Version von fail2ban (klar). Und verschiedene Versionen von fail2ban haben
	verschiedene Ideen was der loglevel bedeutet. In der alten Version war 
	  loglevel = 1
	ein sparsamer Logging-modus (INFO), unter der Version auf focal ist es 
	der "Erzaehl mir mehr von deiner Blinddarm-OP" Modus. Siehe:
	 https://github.com/fail2ban/fail2ban/issues/2008#issuecomment-355189381
	Dadurch ist die Platte mit /var/log vollgelaufen. 
	Und was macht fail2ban, wenns keine logs zum Regexp-Matchen mehr hat?
	Nix mehr blocken...

Thu, 12 May 2022 00:00:00 +0200

	
	SIGILL
	taucht wieder auf, und stoert meine Vorlesung! Die libopenblas, die
	von Sagemath 9.4 im eigenen Baum installiert wird, kompiliert mit den Defaults, d.h
	der Compiler sucht sich die exotischsten Features der CPU, auf der gebaut wird, und
	zementiert die Opcodes in die dynamische Bibliothek. Und die crasht dann auf allen
	anderen Intel CPUs, die irgendeins der Features nicht haben. Wuergaround:
	In $SAGEPATH/build/pkgs/openblas/spkg-install die Zeilen
	  
	  OPENBLAS_CONFIGURE="$OPENBLAS_CONFIGURE DYNAMIC_ARCH=1"
          OPENBLAS_CONFIGURE="$OPENBLAS_CONFIGURE TARGET=CORE2"
	  
	so einbaun, dass kein anderes TARGET definiert wird. Dann mit
        ./sage -p openblas 
	baun.  Das kompiliert die libopenblas mit den Features 
	eines Intel Core2, was effektiv ein Celeron ist (Baujahr 2007, TÜV seit 2013 abgelaufen). 
	Sollte auf allen Intelkisten hier im Gebaeude gehen, im CIP Pool getestet. Tut.