Archiv der Kategorie: Software

Alles was mit Software zu tun hat

OSTicket: Ticketerstellung über Python

OSTicket ist ein freies Ticketsystem, also System zur Sammlung und Dokumentation von Aufgaben. Ab und an kann es praktisch sein solche Aufgaben auch per Software zu generieren, z.B. für wiederkehrende Aufgaben oder wenn Systeme Störungen automatisiert erkennen. Da die Doku bisher eher dünn ist anbei ein kleines Python-Script, welches über die API Tickets erstellen kann. Hierzu muss erst im Admin-Bereich ein passender API-Zugang angelegt werden. Zu beachten ist, dass ein solcher API-Zugang auf eine IP limitiert ist.

Hinweise:

  • Der verify-Parameter ist nur nötig, wenn man HTTPS mit einer im System unbekannten CA nutzt
  • Die Telefonnummer wird bei source=API wohl nicht angezeigt
  • Der Name wird bei erster Nutzung mit der E-Mail-Adresse verknüpft, wenn man weitere Tickets mit der selben E-Mail anlegt scheinen diese alle den zuerst genutzten Namen anzuzeigen

Weitere Doku

[NextCloud/EN] No login possible after Update to 13.0.4 due to encryption app

I ran into some trouble while Updating to NC 13.0.4 regarding encryption. As long as Encryption was installed and enabled no login was possible – WebDAV and Clients received HTTP/503, WebUI didn’t show the login form but only “Bad Signature”. Also occ failed with the same error – “bad signature”. The previously working version was afair 13.0.1, since downgrading isn’t supported I can’t say much for .2 and .3. Inside the log (see below) I could see the error being caused by the encryption module. There might be the odd encrypted folder still present in old accounts, but since it never worked for me reliably it’s disabled for everything currently in use. External solutions are IMO the way to go.

The usual literature suggests to disable the encryption module using occ – not quite helpful in my case. Deleting the encryption app on FS-level did revive occ and Web but the App now failed due to missing encryption. My solution was to disable encryption using SQL instead of just deleting it:

Windows RDP: “Die angeforderte Funktion wird nicht unterstützt” (CredSSP)

Zugegeben, ich bin etwas spät dran, aber heute bin ich bei einer Stelle mit CredSSP und RDP dann auch mal auf die Schnauze gefallen. Da mir das – dank sonst gepflegter Infrastruktur – bisher nicht begegnet ist hier nochmal zum Nachlesen. Und mich als Gedächtnisstütze.

Vorgeschichte

Verursacher der ganzen Misere ist CredSSP, der Credential Security Support Provider. Dieses Windows-Modul ist unter Anderem für die Authentifizierung von Nutzern bei Verbindungen über RDP (Remote Desktop Protocol) und WinRM (Windows Remote Management) zuständig. Durch einen Fehler im Umgang mit den Sitzungen (CVE-2018-0886) können Angreifer einen Man-in-the-Middle-Angriff ausführen und so die bestehende Sitzung übernehmen. Da RDP und WinRM häufig für administrative Zwecke genutzt wird, können sich so Unbefugte ggf. weitrechende Zugriffe auf die verwalteten Systeme beschaffen. Betroffen ist so ziemlich alles – vom einfachen Windows 7 über die Server-Produkte bis hin zum aktuellen 10 sowie Server 2016.

Fixing

Microsoft hat den Fix in mehreren Stufen ausgerollt. Erstmals erschienen passende Updates im März, welche das Problem prinzipiell beheben. Sofern sie überall installiert werden. Zwei Monate später, im Mai, zog der Hersteller dann die Sicherheitsschrauben an: Ab diesem Patch ist die Nutzung der Mitigation zwingend erforderlich.

Wer nicht plant guckt in die Röhre

Wer seine Systeme im Griff hat wird nicht viel merken – ist alles auf einem aktuellen Patchstand wird man von den Umstellungen nichts merken. Anders sieht es aus, wenn man bei den Updates nachlässig handelt. Hat der eigene Rechner bereits aktuelle Patches installiert, das Zielsystem jedoch seit März keine Wartung erfahren, hat man Pech: Der RDP-Client bzw. WinRM verweigern die Verbindung mit dem Zielsystem. “Die angeforderte Funktion wird nicht unterstützt”. Selbes dürfte auch für die andere Richtung gelten.

Und nu?

Was folgt sind zwei Dinge: Erst mal sollte man dem Verantwortlichen Admin des Zielsystems eine Schulung zu IT-Sicherheit verpassen, denn inzwischen mehr als ein halbes Jahr lang keine Updates installieren ist – zumindest meiner Meinung nach – grob fahrlässig. Danach sollte das Zielsystem natürlich auf einen aktuellen Stand gebracht werden – für den Zugriff mindestens notwendig ist der entsprechende CredSSP-Patch, welcher sich auch einzel im dazugehörigen Artikel finden lässt. Da für den nur ein Dopelklick notwendig ist kann das ggf. auch ein Poweruser mit passenden Zugriffen vor Ort erledigen. Hat man keine Möglichkeit das System selbst zu verändern muss man am Client ran: Hier kann man über die Registry oder per GPO auch unsichere Verbindungen zulassen und somit eine Verbindung zu den betroffenen Zielen wieder ermöglich. Dies sollte immer nur temporär geschehen – umstellen, verbinden, Fix installieren und wieder zurück. Keinesfalls sollte man während die Lockerung aktiv ist Verbindungen zu anderen Systemen aufbauen.

Registry

Hierzu liegt man unter HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters ein neues REG_DWORD mit dem Namen “AllowEncryptionOracle” an und gibt diesem den Wert “2“.

GPO

Das Pendant in GPO-Form findet sich unter Computerkonfiguration\Administrative Vorlagen\System\Delegierung von Anmeldeinformationen\Encryption Oracle Remediation. Diese muss aktiviert und die Schutzebene auf “Vulnerable” eingestellt werden.

EOF

Patchmanagement etablieren. Systeme zeitnah Patchen. Spart Arbeit. Und Axteinsätze bein den zuständigen Systembetreuern.

Docker: Start mit aktivem IPv6 nicht möglich

Docker kann bei mir nach wie vor zwei Lager bedienen: Die Idee von Containern klingt gut, die mangelnde Stabilität und viele Konzepte der Implementierung lassen mich aber nur den Kopf schütteln. Heutiges Thema: IPv6. Prinzipiell nicht wirklich nutzbar, da die meisten Orchestration-Systeme wie Kubernetes oder Swarm bisher laut Doku und Bugtrackern bestenfalls rudimentäre Unterstützung bieten. Docker selbst soll – laut Anleitung – jedoch mit wenigen Handgriffen IPv6-fähig gemacht werden können.

Klingt einfach? Tja, nach einem Neustart ließ sich der Docker-Daemon nicht mehr starten. Im Log fand sich folgendes:

dockerd: Error starting daemon: Error initializing network controller: Error creating default "bridge" network: could not find an available, non-overlapping IPv6 address pool among the defaults to assign to the network

Die Abhilfe ist recht einfach: Ein festes Netz vergeben. Hierzu in der daemon.json einen passenden fixed-cidr-v6-Eintrag machen:

{
"ipv6": true,
"fixed-cidr-v6": "2a01:1234:5678:9abc:def0::/112"
}

VMWare vCenter Server Appliance mit Proxy aktualisieren

Die Aktualisierung einer VCSA ist eigentlich ja recht einfach: Man geht über den Port 5480 auf das Appliance-Management (aka MUI, VAMI), klickt auf Update und das drunterliegende Linux wird samt aller Programme auf den aktuellen Release aktualisiert. Die Programme kommen dabei direkt von den Updateservern – zumindest wenn man eine direkte Internetverbindung hat. Steht das System in einem Netz, welches keinen direkten Zugang bietet und nicht über einen transparenten Proxy verfügt, lässt die UI die nötige Konfiguration einfach erscheinen: Unter Netzwerk -> Verwalten findet sich ein Menüpunkt “Proxy-Einstellungen”, welcher die direkte Eingabe ermöglicht. Theoretisch.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2018/01/vcsa.png

Die Praxis sieht leider anders aus: Dieses GUI-Element setzt lediglich die Umgebungsvariable http_proxy, welche ausschließlich für unverschlüsselte Verbindungen gültig ist. Da der Update-Download inzwischen per HTTPS läuft wird der Proxy praktisch ignoriert und der Download-Versuch läuft ins Leere. Dieses Problem tritt mindestens zwischen der Version 6.0 und der aktuellen 6.5U1 auf.

Zur Abhilfe muss man selbst Hand anlegen: In der Datei /etc/sysconfig/proxy findet sich neben der, von der GUI bereits gesetzten, Variable HTTP_PROXY auch ein passendes HTTPS_PROXY. Füllt man dies manuell aus ist der Update-Download fehlerfrei möglich. Wer vSAN einsetzt, sollte hier auch gleich noch die lokalen Server als Ausnahme definieren um den VMWare-Bug #2150523 zu umgehen.

Es zeigt sich wie so oft: Der Texteditor ist mächter als die Maus.

Danke an Andrew Richardson/VirtualSlices für das Aufklären des ursprünglichen Fehlers.

Keepass: Crash durch kaputte Mountpoints

Keepass ist ein quelloffener Passwortmanager, welcher Zugangsdaten verschlüsselt in einer Datei sammelt. Heute musste ich auf einem Gerät feststellen, dass sich die Software nicht mehr starten ließ: Der Passwortdialog erschien kurz, dann verschwand das ganze Programm vom Desktop. Über die Konsole ist ein absturz mit folgendem Trace zu erkennen:

Die Ursache ist etwas schwer zu finden, da nicht direkt ersichtlich: Netzwerkstörungen und Dateisysteme. Keepass durchsucht offenbar beim Start alle eingehangenen Partitionen, tritt hierbei ein Fehler auf kommt es zum Absturz. Dies betrifft nicht nur jene Speicherorte, auf denen Datenbank und ggf. Keyfile hinterlegt sind. In meinem Fall war durch einen Server-Neustart ein NFS-Mount abhanden gekommen (stale file handle), ähnliches war jedoch auch mit sshfs & co zu sehen. Eine Liste der aktuell genutzten Partitionen findet sich unter /etc/mtab, kaputte Dateisysteme lassen sich auch ohne Verbindung mit “umount -l” oder “fusermount -u” aushängen, hierbei kann jedoch möglicherweise Datenverlust entstehen, wenn noch Dinge im Schreibcache liegen. Nach Beseitigung des Fehlers lässt sich Keepass wieder regulär starten.

Firefox statt IE im Unternehmen – Deployment, Konfiguration und Co

In vielen Firmen gilt noch immer Microsoft Edge bzw. der Internet Explorer als Standardbrowser für Inter- und Intranet. Einer der wichtigsten Gründe ist die Verwaltbarkeit: Updates werden über die Systemfunktionen automatisch installiert, Eintellungen lassen sich komfortabel über Gruppenrichtlinien zuweisen. Was viele IT-Abteilungen nicht auf dem Schirm haben ist, dass es auch mit alternativen Browsern nicht vollkommen unmöglich ist eine solch zentrale Konfiguration einzurichten. Hier möchte ich ein paar Kniffe für den Einsatz von Firefox in größeren Installationen geben.

Deployment und Updates

Fangen wir kurz mit Deployment und Updates an: In vielen Firmen laufen Updates des IE über WSUS. Dieser ermöglicht es Aktualisierungen erst in einem Laborumfeld auf unerwünschte Nebenwirkungen zu testen und im Anschluss an die Clients zu verteilen. Prinzipitell gut, jedoch ist WSUS hauptsächlich für Microsoft-Produkte ausgelegt, wird vom Hersteller etwas stiefmütterlich behandelt und ist – zumindest nach meiner Erfahrung – nur mäßig zuverlässig. Nicht zuletzt weil nahezu kein Unternehmen ohne Drittanbietersoftware auskommt, wird in vielen Firmen ein weiteres Deployment-System wie z.B. SCCM oder das kostenfreie OPSI zum Einsatz. Über diese kann man auch Firefox recht schnell ausrollen. Hierzu benötigt man statt dem kleinen Stub-Installer, welcher für Windows üblicherweise ausgeliefert wird, den Offline-Installer, welcher z.B. auf der Sprachübersicht zu finden ist. Wer neue Funktionen gegen seltenere Wartung tauschen möchte kann alternativ auf den Extended Service Release” (ESR) zurückgreifen. Hierbei handelt es sich um eine spezielle Version von Firefox, welche über einen längeren Zeitraum mit Sicherheitsaktualisierungen versorgt wird. Im Gegensatz zur Desktop-Version werden bei diesen Updates – soweit mögich – keine Funktionen verändert. Der Befehl für eine Silent-Installation lautet

Achtung: Beim Download haben 32- und 64-Bit-Varianten aktuell, trotz unterschiedlichem Inhalt, den selben Dateinamen. Über den selben Weg kann man neuere Versionen zur Aktualisierung installieren. Möchte man die Software später wieder löschen findet sich im Installationsverzeichnis eine passende Datei

Konfiguration

Bleibt die Konfiguration. Hier lässt sich ein Überbleibsel aus der Netscape-Zeit nutzen, welche die Ausführung von Scripten beim Start des Browsers erlaubt. Im ersten Schitt legt man eine neue Datei im Ordner “%PROGRAMFILES%\Mozilla Firefox\defaults\pref\” an. Der Name kann frei gewählt werden, jedoch erfolgt die Ausführung alphabetisch. Als inoffizielle Konvention hat sich “autoconfig.js” durchgesetzt. Erste Falle: Die erste Zeile. Diese wird automatisch übersprungen, dort hinterlegte Befehle also ignoriert. Als Workarround sollte man in dieser folglich besser einen Kommentar unterbringen. Zweite Falle: Zwar können in dieser Datei bereits Konfigurationen gesetzt werden, jedoch wird sie während des Browserstarts zu einem Zeitpunkt geladen, an dem noch nicht alle Subsysteme verfügbar sind. Um dies zu umgehen wird stattdessen ein Verweis auf eine weitere Konfiguration hinterlegt, welche am Ende des Starts geladen wird. In diesem Beispiel nenne ich diese “mycompany.js“. Standardmäßig sind diese nachgeladenen Dateien mir ROT13 (sic!) codiert um neugierige Blicke und Änderungen von Nutzerseite zu erschweren. Da Ersteres ohnehin auch über die Browserfunktionen möglich ist und sich Schreibzugriffe über die Berechtigungen des Dateisystems effektiver verhindern lassen, schalte ich diese Funktion aus, so sind Änderungen einfacher.

Nun geht es daran die eigentliche Konfiguration zu erstellen. Die zuvor referenzierte “mycompany.js” wird im Programmverzeichnis, also “%PROGRAMFILES%\Mozilla Firefox\“, erwartet. Für das Setzen von Konfigurationen stehen uns verschiedene Befehle zur Verfügung – hier die wichtigsten:

Befehle

pref()

So gesetzte Einstellungen sind identisch zu jenen, die der Nutzer in der GUI oder about:config vornimmt. Die Änderungen werden als “vom Benutzer eingestellt” angezeigt. Benutzer können diese weiterhin ändern, da das Konfigurationsscript jedoch bei jedem Browserstart läuft werden die Änderungen nach dem Neustart des Browsers wider auf den vorgegebenen Wert zurückgesetzt.

defaultPref()

Hiermit wird die Standardeinstellung geändert. Der Nutzer hat auch hier die Möglichkeit diese selbstständig zu ändern, jedoch sind Benutzeranpassungen bei dieser Variante persistent und werden bei einem Neustart nicht automatisch zurückgesetzt.

lockPref()

Hiermit wird eine Einstellung gesetzt und gleichzeitig gesperrt. Sie kann im Anschluss nicht mehr vom Nutzer geändert werden, entsprechende Konfigurationsfelder werden ausgegraut.

unlockPref()

Hebt die Sperre wieder auf. Interessant wenn man z.B. mit einer globalen Konfiguration arbeitet, bestimmten Benutzergruppen jedoch Funktionen über eine weitere Konfigurationsdatei wieder freigeben möchte.

getPref()

Liest die Konfiguration – z.B. um ein “identisch zu X” umzusetzen.

clearPref()

Löscht die Konfiguration

getenv()

Liest eine Umgebungsvariable

Wie am Namen zu erkennen handelt es sich um Javascript, man kann also auch eigene Logik einbringen. Auch hier nutze ich die erste Zeile zur Sicherheit als Kommentar. Die Bezeichnungen der Konfigurationsfelder kann man im Browser zu großen Teilen in about:config finden.

Beispiele

Automatische Updates ausschalten

Da Updates, wie oben erwähnt, über das zentrale Deployment laufen sollen, wird der Auto-Updater des Browsers ausgeschaltet. So wird der Nutzer nicht mit entsprechenden Aufforderungen konfrontiert und Änderungen können vor einem breiten Rollout in einer überwachten Umgebung auf Kompatibilität mit den Unternehmensanforderungen geprüft werden. Achtung: Einige der Updater-Einstellungen lassen sich nur mit lockPref() setzen.

Branding und Telemetrie

Je nach Firmen-Policy kann ein Branding oder der Upload von Telemetrieinformationen an Mozilla unerwünscht sein.

Startseite

Wenn ein Intranet-Portal o.Ä. automatisch geladen werden soll kann dies als Startseite hinterlegt werden

Zertifikate

SSL-Zertifikate sind bei Drittbrowsern immer eine Qual. Statt den Systemzertifikatspeicher zu verwenden bringen die meisten Browser einen eigenen Zertifikatspeicher mit. Firmen, welche interne CAs verwenden müssen hier eine separate Konfiguration erzeugen und können sich nicht auf die Verteilung per GPO o.Ä. verlassen. Bei Firefox gibt es hier die Möglichkeit über certutil Zertifikate per Script zu importieren.
Bei neueren Installationen kann man Firefox jedoch instruieren auch Zertifikate zu akzeptieren, welche im Windows-Zertifikatspeicher hinterlegt sind.

Proxy-Server

Verwendet die Firma einen Proxyserver, welcher nicht über den Router als “transparenter Proxy” betrieben wird, kann dieser ebenfalls hier hinterlegt werden.

Lesezeichen

Das Erstellen von Lesezeichen ist etwas komplizierter, da man hier mit Datenbank und GUI interagieren muss, welche erst am Ende des Browserstarts zur Verfügung stehen. Um sicherzugehen, dass hier alle Module verfügbar sind, wird das Erstellen in eine eigene Funktion ausgelagert und mit einem Hook des Browsers verknüpft. Das Erstellen erfolgt über den nsINavBookmarksService. Dieser ermöglicht auch das Verwalten von Ordnern oder das Löschen von Elementen.

Alternativen

Wer weniger administriert und lieber herumklickt eine GUI der Textkonfiguration vorzieht kann einen Blick auf CCK2 werfen, welches die Konfiguration grafisch aufbereitet.

Linux: Gerät wacht nach Suspend sofort wieder auf

Narf. Akku leer. Nur warum?
Tja, mein Laptop hatte sich entschieden nach meinem Klick auf “Suspend” sofort wieder aus dem Standby-Modus aufzuwachen. Reproduzierbar. Erste Vermutung: Die GUI ist Schuld. Wie immer. Aber auch ein systemctl suspend zeigt nicht wirklich eine Besserung. Auch die Logs zeigen nichts verwertbares. Na dann graben wir etwas tiefer:

Erst mal zur Klarstellung: Standby funktioniert – der Laptop schaltet die Geräte aus, die Power-LED blinkt wie erwartet, doch nach knapp einer Sekunde wacht wer direkt wieder auf. Entsprechend des Fehlers dürfte also die Aufwachquelle am ehesten Verantwortlich sein. Eine Liste aller Quellen findet sich in /proc/acpi/wakeup:

Die Liste sieht natürlich je nach Verbauter Hardware anders aus, hier die Zuordnung meines Gerätes:

Wie wir sehen können diverse Geräte ein Aufwachen verursachen, lediglich EXP2 ist nicht aktiv. Um das Ganze einzugrenzen heißt es also nun: Aufwachquelle abschalten, Suspend testen und hoffen, dass es was bringt. Über ein gezieltes echo kann der Zustand zwischen enabled und disabled gewechselt werden:

In meinem Fall stellte sich USB als Fehlerteufel heraus. Offenbar störte sich das System an einem USB-Stick – egal ob gemountet oder nicht. Wie auch immer, USB brauche ich ohnehin nicht zum aufwachen, Deckel und/oder Power-Button sollten ausreichen. Den “bösen” USB schalte ich beim Boot per Script nun ab.

[Gentoo] Apache 2.4.26 + WordPress: Invalid post type

Hmk? After the latest system updates on Gentoo I noticed WordPress was no longer able to open any kind of post list (“invalid post type”), edit posts (you do not have access to this kind of post) or create posts (form shown, but right sidebar missing). Not quite uncommon, but this time it was no broken plugin – I could reproduce the same behavior with several other WordPress instances with different versions – even a fresh install. That’s a new one.

After some probing around I’m fairly certain Apache 2.4.26 is the culprit, after downgrading to 2.4.25 the problem disappeared. All other downgrades like PHP 7.0.15 instead of PHP 7.0.19 didn’t show any effect. I yet have to confirm which combination ultimately triggers the error (FPM? Event-MPM?), but if you have similar errors: Here is your starting point…

Windows: Wo ist Java?

Ich bin von Linux ja irgendwie verwöhnt: Alle Binärdateien sind üblicherweise unter /usr/bin und lassen sich direkt über den Namen des Programms aufrufen. Unter Windows gibt es mit $PATH zwar eine ähnliche Funktion, jedoch ist dort meist nur der Systempfad eingetragen. Da es für fast jedes Programm ein eigenes Verzeichnis gibt hat man so keine direkte Möglichkeit ein Programm zu starten ohne an den Systemvariabeln herumzueditieren.

In vielen Fällen nicht wirklich ein Problem – einmal gefunden kann man den Pfad in seinen Scripten hinterlegen und so die Software ansprechen. Leider ist das bei Programmen wie Java nicht so einfach: Diese legen ein Verzeichnis mit der Versionsnummer an, z.B. C:\Program Files\Java\jre_8.0.121\bin\java.exe. Ergebnis: Nach jedem Update versteckt sich die gesuchte EXE an einer anderen Stelle.

Hier ein Quick&Dirty CMD, welches die Java-Binary aufspüren sollte. Nicht Ideal, da z.B. nur das Systemlaufwerk unterstützt wird und diverses Errorhandling fehlt, aber immerhin zuverlässiger als hardcoded…