Lab: Debian 8

Heute einen Test-Server mit Debian 8.3 “jessie” auf Dell PE1850 eingerichtet. Alles unspektakulär.

Ich habe bewusst gewartet, wie sich Debian 8 entwickelt und ob grössere Probleme auftreten. Da ist diese “systemd” Sache, die ich eher skeptisch sehe. Und ich habe selbst Erinnerungen an Debian major-release Upgrades: schlechte (6 => 7) und schlimme (4 => 5). Und aktuelle Regression Bugs stärken das Vertrauen auch nicht.

Ich wollte auf meinen eigenen Servern mit Debian abschliessen und auf den RedHat Enterprise Clone CentOS umstellen, aber damit warte ich noch einen Moment, Core Infrastruktur sollte nicht ohne guten Grund umgestellt werden.

Praktische Erfahrungen mit Debian 8 brauche ich auch, weil einige Kunden Debian 7 einsetzen und in absehbarer Zeit upgraden müssen.

Ich werde mein Standard DevOps Werkzeug von Puppet auf Ansible umstellen, dafür ist der Test-Server perfekt.

Last not least soll der Server für Tests mit OpenStack und Docker verwendet werden.

Dell OpenManage on Dell R300 Server – network gone

After installing Dell OpenManage 7.4.0 (latest version from Dell apt repository) on a PE860 Server running Debian 7 worked without issues [lang:german] and proved to be useful [lang:german], I proceeded to do the same on an R300 Server. That didn’t go well..

Installing the packages went fine, next step was starting the OpenManage “dataeng” service. Right after that all hell broke loose: iSCSI connections were cut, VMs using iSCSI disks were hung, SSH connections were dropped. Lucky this wasn’t a remote server.

Console worked, no signs of kernel crash or kernel errors in the logs. But the system seemed to have lost network connectivity and could not ping anywhere except localhost, which explains the observed behavior.

As OpenManage wants to run its own SNMP Server, I figured the already running SNMP server might conflict with it. Disabled the Debian snmpd service, left OpenManage dataeng enabled. Reboot, same problem.

Disable OpenManage dataeng service, reboot, no problem. So OpenManage is part of the problem. Need to investigate.

I do not think Debian is part of the problem, because I have seen the same behavior about 3 years ago with bigger Dell servers (R710?) and Suse Linux Enterprise 11.

xmlrpc.php Angriff auf WordPress Blog

Ein Webserver mit mehreren virtuellen Hosts reagierte sehr zäh bei Browser-Aufrufen und auch bei SSH-Login. Ein schneller Blick mit top zeigte eine ungewöhnlich hohe System-Last, und der Apache Server war auffällig häufig bei den Top-Prozessen.

Ein Blick auf die Apache access.log Dateien zeigte, dass ein bestimmter Vhost (auf dem WordPress läuft) mit POST Anfragen auf /xmlrpc.php bombardiert wurde und dies zu hoher Systemlast und langsamen Web-Server Antworten führte.

Als Sofortmaßnahme die IP des Angreifers an der vorgelagerten Firewall gesperrt, daraufhin ging die Systemlast auf normale Werte zurück. Dies ist die gründlichste Lösung dieses Problems: eine Abwehr mittels Web-Server Konfiguration oder mittels WordPress Plugin erfordert weitaus mehr Ressourcen (RAM, CPU), als ein IP-basiertes Blocken des Angreifers. Das Problem ist, eine gerade entdeckte IP dynamisch in das Firewall Blocken aufzunehmen. Klassischer Fall für IPS (Intrusion Protection Systems), hat aber nicht jeder (teuer und/oder komplex).

Das IP-Blocking verschaffte aber Zeit zu recherchieren, was genau das Problem ist und wie wir vorgehen sollten.

Was ist das Problem mit xmlrpc.php?

Es geht um “Password Guessing”, also den Versuch, einen Benutzernamen mit gültigem Passwort zu erraten, um mit diesen Rechten einen fremden Server für eigene Zwecke zu mißbrauchen. Kennt jeder Admin eines im Internet exponierten Servers, egal ob es um FTP, POP/IMAP, SMTP AUTH, Apache htaccess, PHPMyAdmin, WordPress usw geht.

XMLRPC steht für “Remote Procedure Calls over XML”. Das bedeutet, dass ein beliebiger Client im Internet remote eine Prozedur mit selbst definierten Parametern auf unserem WordPress ausführen kann, indem eine korrekt formatierte XML-Datei mit POST an unseren WordPress Server übergeben wird.

Falls die roten Lampen beim letzen Satz noch nicht angegangen sind: jeder beliebige Internet Nutzer kann ohne Authentifizierung die Prozedur “prüfe-password” etwa so aufrufen:

wp.getUsersBlogs("admin", "test")

und kann anhand der Antwort erkennen, ob das Passwort “test” korrekt ist oder nicht. Das ist optimal für “Password Guessing” und vermeidet sogar auffällige Aufrufe von wp-login.php.

Kollege Mike Kuketz hat eine lesenswerte Beschreibung des Problems und bringt das auf den Punkt:

Die XMLRPC-Schnittstelle stellt ein[e] … fragwürdige Design-Entscheidungen dar …. Aufgrund ihres Funktionsumfangs … ist die xmlrpc.php nicht nur eine nützliche Bereicherung im Blogger-Alltag, sondern stellt auch für Angreifer ein interessantes Angriffsziel dar.

Dieses Angriffsziel ist ein Problem, weil die angegriffenen Server signifikante Last- und Stabilitäts-Probleme zeigen. Diese Schnittstelle sollte deaktiviert werden.

Seit WordPress 3.5.1 ist diese Schnittstelle per Default aktiviert, um eine API für Fremdsoftware anzubieten (etwa zum Publizieren von Beiträgen aus MS Word oder von einem iPhone), oder für Erweiterungen wie JetPack. Manche WordPress Plugins könnten nicht mehr wie erwartet funktionieren, dies sollte jeder Admin entsprechend prüfen.

Wir empfehlen, den Zugriff auf /xmlrpc.php abzuschalten. Dies kann auf 3 Arten geschehen:

  • IP-Blocking per Firewall
  • Webserver Blocking (zB Apache/htaccess)
  • WordPress Blocking (Plugin Disable XML-RPC)

Diese Techniken können unabhängig oder im Kombination (buzzword multi-layer security) verwendet werden.

IP-Blocking per Firewall

Dies ist die effizienteste Variante, da eine unerwünschte Anfrage gar nicht erst den Webserver erreicht und dort Ressourcen verbraucht. Der Nachteil ist, dass man die IP-Adresse des Angreifers mühselig aus den Logs extrahieren und manuell in der Firewall eintragen muss, oder ein dynamisches Firewalling erforderlich ist, welches eigene Probleme haben könnte (Stichwort false-positives). Dynamisches Firewalling wird in einem späteren Artikel beschrieben.

Webserver Blocking

In einer Apache Konfigurationsdatei oder .htaccess Datei kann mit der folgenden Anweisung der Zugriff auf xmlrpc.php und andere sensitive Dateien unterbunden werden:

# Disallow access to important WordPress files
<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php)">
  Order deny,allow
  Deny from all
</FilesMatch>

Ähnliche Lösungen gibt es für nginx und andere Webserver.

Apache mod_security bietet einen regelbasierten Ansatz, um unerwünschte Zugriffe zu sperren. Es ist allerdings recht komplex und muss gut verstanden werden, um false-positives zu vermeiden und damit legitime Anwender auszusperren.

WordPress Blocking

Als letzte Verteidigungslinie kann es sinnvoll sein, ein WordPress Plugin zu installieren, das den Zugriff auf xmlrpc.php unterbindet. Mit einer WordPress Plugin-Suche nach “disable xmlrpc” finden sich etliche Plugins, wir benutzen “Disable XMLRPC”.

WooCommerce variables Produkt, Probleme bei vielen Varianten

WooCommerce ist ein Shop-System Plugin für WordPress. Variable Produkte in WooCommerce sind Produkte, die in verschiedenen Ausführungen verfügbar sind.

Etwa ein bestimmtes T-Shirt Motiv, das in 9 Grössen und Zweifarben-Design erhältlich ist. Jede der beiden Farben kann frei aus 40 verschiedenen Farbtönen gewählt werden. Dadurch ergibt sich für dieses eine T-Shirt Produkt die Menge von 14.400 möglichen Produktvarianten (9 Größen * 40 Farbe1 * 40 Farbe2).

In WooCommerce würde dieses T-Shirt Produkt als “variables Produkt” definiert, und unter “Eigenschaften” die 9 Größen und die je 40 Farbe1 und Farbe2 eingetragen. Anschliessend kann unter “Varianten” ausgewählt werden “Generiere Varianten aus allen Attributen”, dies erzeugt automatisch alle kombinatorisch möglichen Varianten.

Dies ist sehr praktisch und funktioniert einwandfrei, solange die Menge der möglichen Varianten klein ist (etwa 3 Größen * 3 Farbe1 * 3 Farbe2 = 27). Mit 14.400 Varianten funktioniert das alles andere als gut. Das ist mathematisch die kombinatorische Explosion, die irgendwo im WooCommerce Programm-Code zuschlägt.

Die “normale” Vorgehensweise

Die sehr nützliche Option “Generiere Varianten aus allen Attributen” ist per Default auf 50 Varianten pro Durchlauf beschränkt. Dies geschieht sicher aus gutem Grund, je mehr Varianten in einem Rutsch erzeugt werden, desto mehr Speicher und Ausführungszeit werden benötigt, und das kann auf schwach ausgestatteten Servern zu Ausführungsfehlern und evtl. Dateninkonsistenz führen.

Wenn unser Besipiel T-Shirt 4 Größen * 4 Farbe1 * 4 Farbe2 = 64 Varianten hat, werden mit dem Aufruf von “Generiere Varianten aus allen Attributen” die ersten 50 Varianten erzeugt. Ein erneuter Aufruf erzeugt dann die restlichen 14. Soweit gut.

14.400 Varianten in 50er Häppchen zu erzeugen erfordert die Geduld für 288 einzelne Klicks. Must be a better way..

Hacking WooCommerce

Ein wenig Google-Suche und WooCommerce Code lesen führt zu der Variable WC_MAX_LINKED_VARIATIONS, welche bestimmt wie viele Varianten pro “Generiere Varianten” Aufruf erzeugt werden (Default 50). Vorausgesetzt dass die PHP Variablen memory_limit und max_execution_time großzügig gesetzt sind, kann die Variable WC_MAX_LINKED_VARIATIONS deutlich erhöht werden. Ich habe sie auf 3000 gesetzt, indem ich die folgende Zeile systemweit zu wp-config.php hinzugefügt habe.

define( 'WC_MAX_LINKED_VARIATIONS', 3000 );

Das hat schon mal 3.000 von 14.400 Varianten erzeugt und etwa 30min gedauert. Die nächten Portionen von 3.000 Varianten dauerten zunehmend länger, aber mit 5 Klicks und alle 1-2h nachschauen waren alle Varianten erzeugt. Übrigens meldet das Popup-Fenster weiterhin “Sie erzeugen 50 Varianten, weiter?”, obwohl tatsächlich 3.000 pro Durchlauf erzeugt werden.

Funktioniert leider nicht

Alle Varianten waren im Produkt-Menu sichtbar und konnten bearbeitet werden (z.B. Preis für alle setzen). Sie tauchten auch korrekt auf der für Kunden sichtbaren Produkt-Seite auf und konnten mit HTML Auswahlfeldern gewählt werden.

Allerdings erschien nach jeder ausgewählten Farbkombination nicht wie erwartet der Produkt-Preis, sondern ein Hinweis “dieses Produkt ist nicht lieferbar”. Auch nach expliziter Prüfung, ob für einzelne Varianten der Preis gesetzt und die Variante aktiv ist sowie ob Bestandsmengen Einstellungen im Weg sind, liess sich dieses Problem nicht lösen. Eine Google-Suche lieferte einige, teils obskure Ideen, aber ebenfalls keine funktionierende Lösung.

Die grosse Menge von Varianten scheint irgendwelche Programm-Limits zu sprengen.

Update 13.2.2016: Update auf WooCommerce 2.5.2 behob das Problem

Das scheint ein WooCommerce Bug gewesen zu sein, nach Update auf das aktuelle WooComerce 2.5.2 funktionierte alles genau wie es sollte.

RedHat Enterprise: SELinux verhindert Start des DHCP Server

Auf einem neu installierten RedHat Enterprise Linux (RHEL) 6.7 Server liess sich der DHCP Server Dienst nicht starten. Im Log war die folgende Fehlermeldung zu finden:

dhcpd: Can't open /daten/failover/dhcpd/dhcpd.conf: No such file or directory

Die Datei existierte, war nicht leer und hatte korrekte Dateisystem-Berechtigungen. Auch alle Verzeichnisse im Pfad hatte Rechte, die einen Zugriff auf die Datei nicht blockieren würden.

Nach kurzer Suche bestätigte sich der Verdacht, dass dies im Zusammenhang mit SELinux steht. SELinux (Security Enhanced Linux) ist ein erweitertes Rechte-Management, das über die Standard Benutzer- und Dateisystem-Rechte von Unix hinausgeht.

SELinux ist in RHEL per Default aktiviert, und dieses striktere Rechte-Management verhindert den Start des DHCP Server.

Es gibt zwei Möglichkeiten, dieses Problem zu umgehen: die strikten Einstellungen von SELinux generell zu deaktivieren, oder SELinux speziell für den DHCP Server abzuschalten.

SELinux deaktivieren

Da wir ähnliche Probleme bereits im Zusammenhang mit dem BIND DNS-Server erlebt hatten, haben wir uns entschieden, SELinux von “Security Policy erzwingen” auf “nur warnen” umzustellen. Dazu muss in der Datei /etc/selinux/config die Variable SELINUX von enforcing auf permissive gesetzt werden:

#SELINUX=enforcing
SELINUX=permissive

Anschliessend ist ein Reboot erforderlich.

SELinux für den DHCP Server deaktivieren

Alternativ kann SELinux nur für den DHCP Server abgeschaltet werden, indem das folgende Kommando ausgeführt wird:

/usr/sbin/setsebool -P dhcpd_disable_trans 1

Ref: Red Hat Enterprise Linux 6 Security-Enhanced Linux User Guide

Dell OpenManage auf Debian Linux installieren

Dell OpenManage ist eine Software-Suite zur Statusabfrage und Konfiguration von Dell Server Hardware. Damit kann per Kommandozeile oder Web Interface der Hardware- und Systemstatus ausgelesen werden, um z.B.die Hardware-Konfiguration zu ermitteln oder ausgefallene Festplatten, Systemlüfter usw. zu erkennen.

Die Software wird von Dell kostenfrei für Windows, VMware ESXi und einige Linux Distributionen angeboten, für Debian/Ubuntu Linux gibt es ein APT Repository, aus dem die OpenManage Software einfach installiert werden kann. Die Installationsanleitung von Dell kurz zusammengefasst:

  • Datei /etc/apt/sources.list.d/linux.dell.com.sources.list wird für das APT Repository angelegt. Hier muss der Name der installierten Debian/Ubuntu Version (z.B.”wheezy” für Debian 7) angegeben werden
  • GPG Key von Dell importieren und Repository initialisieren (“apt-get update”)
  • Pakete mit apt-get install installieren

Das Paket “srvadmin-all” installiert alle Software-Komponenten. Die Liste der neu zu installierenden Pakete ist recht lang und umfasst u.a. Java und etliche Libraries. Wenn auf die Web-GUI verzichtet werden kann, ist es evtl. ausreichend, nur das Paket “srvadmin-base” zu installieren.

Die Installation läuft problemlos. Um die OpenManage Funktionalität im Anschluss zu nutzen, muss der Server entweder rebootet werden, oder der neue Dienst “dataeng” einmal manuell gestartet werden (“service dataeng start”).

In Fehlersuche auf Dell Hardware mit OpenManage wird die Verwendung des OpenManage Kommandozeilen-Tools gezeigt. Dell OpenManage Web-Interface einrichten und benutzen beschreibt das OpenManage Web-Interface.

Win7 Firefox Sucheinstellungen gekapert

Heute $SWEETHEART am Computer über die Schulter gegauckt, und bemerkt dass man ihr eine andere Suchmaschine (“sm.de”) im Firefox untergejubelt hat.

MalwareBytes sagt “alles gesund”, auch der installierte Avast Antivirus hat nicht angeschlagen. Sm.de ist nach meiner Einschätzung Schadsoftware, habe die Suchmaschinen-Einstellung manuell repariert.

Es macht mir Sorgen, dass es möglich ist, trotz Auto-Update von Windows und Firefox von fremder Seite persönliche Einstellungen zu ändern. Not feel safe, no-no.

OpenBSD Driver for Moxa 8-port serial

Found a message from Craig on misc@openbsd.org, reporting Moxa 8-port serial PCI cards work fine. So I bought one on Ebay, plugged in, didn’t work.

Turned out I have a Moxa CP-168U card (devid: 0x1681), while Craig’s supported card was Moxa C168H (devid: 0x1680).

Googling along, I found this FreeBSD bug report , basically stating that CP-168U behaves just like C168H, only the devid is different. Trivial patch posted to tech@

EDAC Linux Kernel Messages

Noticed that an older Dell PE860 server filled the system log with lots of messages like these:

Jan 12 06:25:06 srv1 kernel: [390027.492118] EDAC MC0: CE page 0xb041c, offset 0x480, grain 128, syndrome 0x86, row 1, channel 1, label "": i3000 CE
Jan 12 06:25:09 srv1 kernel: [390030.492108] EDAC MC0: CE page 0xb041d, offset 0x0, grain 128, syndrome 0x86, row 1, channel 1, label "": i3000 CE
Jan 12 06:55:05 srv1 kernel: [391826.520108] EDAC MC0: CE page 0xb0494, offset 0x0, grain 128, syndrome 0x86, row 1, channel 1, label "": i3000 CE

Kernel messages are not something you like to see in your logs, and certainly not so many of them. But what the heck do they mean?

They come from the EDAC subsystem. From EdacWiki:

EDAC Stands for “Error Detection and Correction”. The Linux EDAC project comprises a series of Linux kernel modules, which make use of error detection facilities of computer hardware, currently hardware which detects the following errors is supported:

  • System RAM errors (this is the original, and most mature part of the project) – many computers support RAM EDAC, (especially for chipsets which are aimed at high-reliability applications), but RAM which has extra storage capacity (“ECC RAM”) is needed for these facilities to operate
  • RAM scrubbing – some memory controllers support “scrubbing” DRAM during normal operation. Continuously scrubbing DRAM allows for actively detecting and correcting ECC errors.
  • PCI bus transfer errors – the majority of PCI bridges, and peripherals support such error detection
  • Cache ECC errors

The particular error messages above mean that EDAC has detected problems with at least one ECC memory module in this server. Actually kind of pre-detected, because we did not notice any problems or crashes of applications or VMs on the server.

This EdacWiki page has more information about EDAC memory messages and how to diagnose and deal with these issues.

One particular interesting takeaway for me: The above page recommends

  • Don’t enable BIOS “quick boot”.
  • Don’t manually skip BIOS memory check

After enabling the BIOS memory check and reboot, the number of EDAC messages dropped massively. Not fully gone, though. This indicates that there is an issue with some memory module. Further Checking with Dell OpenManage [lang:german] confirmed a bad memory module.

Lab: OpenBSD-current

Habe auf einem Testserver OpenBSD snapshot Jan-12-2016 installiert, Source Code installiert und per CVS aktualisiert. Kernel kompiliert, Gesamtsystem kompiliert, alles perfekt, wie üblich.

Wird für Hardware/Treiber-Tests benötigt.