Zugschlusbeobachtungen

Tasmota ist eine freie Firmware, mit deren Hilfe man günstige Cloud-only-Devices entgegen des Produktmanagements ihrer Hersteller cloudfrei im Heimnetz betreiben kann. Ursprünglich mit einem IR-Sender hier eingezogen, habe ich inzwischen sechs Devices (davon eins vermutlich nur noch als Briefbeschwerer tauglich) zusammen mit einem eingedockerten MQTT-Broker im Haus und bin so weit, Euch einen Bericht darüber zu schreiben.

Wie Ihr vielleicht wisst, leben wir seit 2014 in einem KNX-Haus. KNX ist ein international standardisierter, herstellerübergreifender Bus für die Hausautomatisierung, der sich im Bereich gewerblicher Immobilien seit vielen Jahren nahezu alternativlos durchgesetzt hat und dem ein ähnlicher Erfolg in Privathäusern aufgrund der zwischen abenteuerlich und unverschämt einzustufenden Preispolitik bis heute versagt geblieben ist. Um weiterhin herstellerunabhängig zu bleiben, haben wir die klassische Variante des KNX-Busses mit dem speziellen, parallel zur 230-V-Verkabelung verlegten Kabel gewählt. Aber ehe ich hier jetzt erstmal einen Artikel über KNX-Grundlagen schreibe, merke ich mir das für einen zukünftigen Artikel und komme zum für heute geplanten Thema zurück.

So, nachdem ich die letzte Woche mit "Voraussetzungen aufbauen" verbracht habe, und wegen Zeitmangel am Wochenende sogar einen vorbereiteten Füller-Artikel posten musste, kommen wir heute (endlich) zu dem, was ich eigentlich mit Euch diskutieren wollte. Zu diesem Artikel sind mir Eure Kommentare besonders wichtig; ich weiß aber, dass es nach dem Absenden eines Kommentars im Browser einen Timeout hagelt. Das ändert aber nichts dran, dass der Kommentar ordentlich gepostet wurde.

Heute soll es nun endlich darum gehen, wie man Konfigurationsarbeiten ermöglicht und unterstützt, bei denen sich derjenige, der die Arbeiten ausführt, aktiv auf den zu bearbeitenden Systemen einlogged. Dabei schließe ich ausdrücklich das manuelle Arbeiten mit ssh oder mehrfach-ssh wie mssh und cssh ein, meine aber auch semiautomatisierte Arbeiten wie xargs --max-procs oder parallel(1) bis hin zum vollautomatischen Prozess, z.B. mit Ansible.

Auf meinen Systemen bin ich im wesentlichen der einzige Shell-Benutzer. Die hier vorgeschlagenen Methoden können natürlich auch auf eine größere Menge von Accounts angewendet werden, wobei ab einer gewissen Grenze manche Verfahren nicht mehr skalieren.

lokaler Login

Lokaler Login auf der Konsole ist bei meiner Arbeitsweise die Ausnahme. Das passiert im Wesentlichen nur bei Störungen, wenn Netz und/oder ssh nicht mehr funktionieren. Die bei weitem häufigste Methode des Zugriffs auf die Shell erfolgt via ssh über das Netz. Da ich auf meinen Systemen natürlich sudo-berechtigt bin, benötige ich das zum Account gehörende Passwort (außer zum Konsolen-Login im Störungsfall) nur, um mich bei sudo zu authentifizieren um root werden zu können.

Wenn man sich die Konfiguration seiner Systeme (managed systems) von einem Automaten (Konfigurationsmanagement-System, KMS) abnehmen lassen möchte, muss man ihm dazu die notwendigen Rechte geben. Da beißt die Maus keinen Faden ab.

Aber was sind die notwendigen Rechte, wie gibt man sie dem Automaten, und welche Implikationen für die Systemsicherheit (im Sinne von security) haben sie?

In diesem Artikel und seinen weiteren Teilen stelle ich ein paar Methoden vor, versuche ihre Vor- und Nachteile herauszuarbeiten und bitte euch um Kommentare und eure Meinung dazu. Dieser Teil 1 beschäftigt sich mit dem, dem ich eigentlich nur einen Absatz widmen wollte, und aus dem dann ein eigener Artikel geworden ist: Dem Pull-Prinzip mit einem Agenten.

Oftmals hat man die Aufgabe, einen maschinenübergreifenden Zugriff automatisiert stattfinden zu lassen, ohne dass man der einen Seite gleich "vollwertige" Credentials für einen interaktiven Login auf der anderen Seite geben möchte. Wenn der Zugriff automatisiert stattfinden soll, fällt auch noch die Sicherheitsstufe eines ssh passphrases weg, da niemand da ist um diesen einzugeben.

ssh forced commands bieten eine Möglichkeit, einen solchen Zugriff zu erlauben, ohne gleich die Büchse der Pandora zu öffnen. Selbst ein automatischer Zugriff mit root-Rechten ist auf diese Weise "reasonably secure" realisierbar.

Yes, You Should Not discard cached ssh host keys without looking. An unexpected change of an ssh host key is always a reason to step back from the keyboard and think. However, there are situations when you know that a systems' ssh host key has changed, for example when the system reachable under this host name has been redeployed, which happens increasingly often proportionally to the devopsness of your environment, or for example in test environments.

Later versions of ssh offer you the ssh-keygen -R command line to paste from the error message, so that you can abort the connection attempt, paste the command and reconnect again. This will still ask for confirmation of the new host key though.

Almost every sysadmin has an alias or wrapper to make handling of this situation easier. Solutions range from using "StrictHostKeyChecking no" and/or "UserKnownHostsFile /dev/null", turning off this layer of securit altogether either globally or usually too broadly, to more-or-less sophisticated solutions that involve turning off know-host file hashing, parsing client output and/or grep-sed-awk magic. grml even comes with an insecssh script that is rather neat and that I used until I developed my own.

Starting with OpenSSH 7.2, a new "restrict" option for authorized_keys lines has become available. It sets all available restrictions that the current OpenSSH version can do (like no-agent-forwarding, no-x11-forwarding etc). One can individually turn on those features again by corresponding new options.

This saves one from sorrows when a new capability of OpenSSH is introduced through an update which is enabled by default, since one has to remember that restricted authorized_keys lines are in unse and then to manually add the restrictions.

On the downside, Debian jessie and CentOS 7 don't have a recent enough OpenSSH. So we'll have to continue worrying about new features being inadvertendly enabled for a while.

P.S.: Yes, I haven't blogged about Linux and Debian in English in a while.

Wenn eine Applikation über das Netz kommuniziert, funktioniert sie natürlich nur dann, wenn das Netz zwischen den beteiligten Maschinen diese Kommunikation auch durchleitet. Das ist im Internet üblicherweise der Fall; beim Übergang zwischen privaten Netzen und dem Internet in aller Regel nicht: Dort ist eine Firewall im Einsatz, die üblicherweise nach der Deny-all-Strategie alle Kommunikation blockiert, die nicht explizit freigegeben ist.

Auf diese Weise wird man im allgemeinen für eine neue Applikation eine Anpassung an der Firewall vornehmen müssen - es sei denn, die Applikation gibt sich Mühe, wie ein Dienst auszusehen, der üblicherweise freigegeben ist. Das tun zunehmend viele Applikationen und geben sich durch Benutzung von http als Transportprotokoll als Webclient und Webserver aus, was in vielen Firewalls direkt freigegeben ist. Doch dies ist Stoff für einen anderen Artikel.

In diesem Artikel möchte ich davon schreiben, wie die Spezifikation aussehen soll, damit der Firewalladmin auch weiß, was er für eine neue Applikation in seiner Firewall freischalten soll. In vielen Dokumentationen über (freie oder kommerzielle) Software findet man Listen von Ports, die mehr oder weniger vollständig und mehr oder weniger korrekt sind. Leider trifft in den meisten Fällen das "weniger" zu.

Dadurch, dass mein Mailsystem in seiner Eigenschaft als Nichtwindows nicht besonders anfällig gegen Malware ist und ich auch nicht blind auf jeden Anhang klicke, leiste ich mir seit einigen Jahren den Luxus, dass der Clamav auf meinem Mailserver nur die Malware ablehnt, die ich explizit konfiguriert habe. So werde ich die lästigsten Störer automatisch los und habe trotzdem einen Überblick darüber, was im Moment so an Malware unterwegs ist, weil der Clamav natürlich auch Malware, die nicht auf der Reject-Liste steht, markiert.

Es gab zwischendrin eine Zeit, da kam ungefähr gar nichts. So wenig jedenfalls, dass ich ernsthaft darüber nachgedacht habe, die CPU-Zyklen für den Scan eingehender Mail auf Malware einzusparen und den Mailvirenscanner abzuschalten.

Gut, dass ich das nicht gemacht habe, denn in den letzten zwei bis drei Wochen kommt durchaus wieder Malware per Mail in signifikanter Menge (also mehr als zwanzig pro Tag). So hat der Clamav wieder ein wenig mehr zu tun, und ich werde in Zukunft nicht mehr so schnell darüber nachdenken, einen nicht störenden Sicherheitsmechanismus wegen "irrelevant, braucht man heutzutage nicht mehr" abzuschalten.

Auf einem Webserver möchte ich nicht, dass phpmyadmin, das Dokumentations-Wiki und das awstats von überall verfügbar sind. Andererseits möchte derjenige, der das CMS auf eben dieser Maschine betreut, genau diese Webapplikationen jederzeit und von überall benutzen können. Was tun?

Wer einen Server in einschlägig bekannten Netzwerksegmenten (sprich: Bei den großen Housing-Anbietern) betreibt und wenigstens von Zeit zu Zeit mal in dessen Logs guckt kennt es: Irgendwelche Rechner aus Fernost oder anderswo werfen dem ssh-Daemon wild zusammengewürfelte Kombinationen aus Username und Passwort zu und tun dies mit einer bemerkenswerten Persistenz. Und wenn man auf dem System "fremde" User hat, lebt man als Admin stets mit der Angst, dass einer der Versuche der Angreifer irgendwann mal Erfolg hat.

Gegen diesen Typ der Brute-Force-Angriffe sind einige Wässerchen gewachsen, und ich möchte eine kleine Auswahl davon in diesem Artikel vorstellen.

Florian hat im April 2007 eine Notiz über PKI-loses TLS unter Verwendung von selbstsignierten Zertifikaten veröffentlicht. Er ist ja immer für provokative Aussagen gut, und in der Notiz erklärt er seine Beweggründe gut und hat bei mir einen Denkprozess ausgelöst.

Ich werd das in den nächsten Monaten mal für den einen oder anderen Dienst, z.B. OpenVPN, ausprobieren und gucken, ob dieser Ansatz in der Praxis funktionieren könnte. Für die Anwendung im Webumfeld sehe ich ja eher schwarz, weil dank der verDAUung des Internets ein https-Server mit selbstsigniertem Zertifikat gemeinhin als unsicherer angesehen wird wie ein Server mit unverschlüsseltem http. Weil bei Ersterem der Browser weint, und bei Zweiterem nicht.

Funktastaturen sind dafür, dass sie gegenüber klassischen Tastaturen eigentlich nur Nachteile haben, erschreckend weit verbreitet. Sie sind nur unwesentlich weniger unhandlich wie kabelgebundene TastBaturen, fressen dafür Batterien wie blöde, verringern den Kabelsalat nicht - und unsicher sind sie oft auch.

Funktastaturen sind besonders im Firmenumfeld fast ausschließlich dort zu finden, wo mit vertraulichen Strategiedaten umgegangen wird, nämlich in der Chefetage. Dort sind die Informationen, die tagein, tagaus in die Tastaturen gehämmert werden, in aller Regel sensibler als dort, wo es aus Kostengründen keine Funktastaturen gibt (sie aber eventuell sinnvoller wären). Schließlich erwartet man gerade von den großen Herstellern mit L und mit M, dass sie sich ein Mindestmaß über die Vertraulichkeit der über die meist proprietären Funkstrecken Gedanken machen.

Schon vor fünf Jahren konnten meine Kollegen mit ihren L-Tastaturen die Eingaben der Firma eine Etage höher abgreifen, und laut heise online hat es jetzt die mit einem dem Stand der Technik von 1540 entsprechenden 8-Bit-XOR-Schlüssel gesicherten Funktastaturen von M erwischt. So eine "Verschlüsselung" reicht gerade, um dem Laien zu zeigen, dass da keine Klartextdaten über die Luftschnittstelle gehen; einem mit unterdurchschnittlicher Energie ankommenden Angreifer hält so eine "Sicherheit" geschätzt dreieinhalb Sekunden stand, und dann liegen alle getippten Passworte und Buchhaltungsdaten dem Mithörer weit offen.

Und so muss meine Empfehlung weiterhin lauten: Finger weg von Funktastaturen. Und wenn es partout ein Statussymbol sein muss, oder der Einsatz einer Funktastatur ausnahmsweise mal Sinn und Zweck haben (z.B. bei einem Entertainment-PC, den man auch vom Sofa aus bedienen können will), sollte man wenigstens das Geld für eine Bluetooth-Tastatur in die Hand nehmen: Das ist ein offener Standard, dessen Sicherheit zwar nicht berauschend gut ist, aber eine derartige Peinlichkeit, wie sie sich Vendor M mit seinen Produkten geleistet hat, ist dort eher nicht zu erwarten.

Ach ja, übrigens: Wenn Ihr mich richtig ärgern wollt, nehmt mir meine kabellose Maus weg. Besonders mit Bluetooth ist das Klasse, wenn das Notebook das Bluetooth-Interface bereits eingebaut hat und man am Notebook überhaupt nichts einstöpseln muss und die Maus trotzdem einfach funktioniert. Aber das Konzept war wohl zu einfach und nicht proprietär genug, denn Vendor L hat die MX 900 schon vor vielen Monaten aus dem Programm genommen.

Hallo Dirk, zu Deinem Artikel möchte ich noch hinzufügen, dass Serendipity 1.0.2 ein Security-Update ist, das XSS Vulnerabilities behebt.

Man möchte dieses Update also nicht verzögern, sondern unverzüglich installieren!

Das Bundesministerium der Justiz bereitet einen Gesetzentwurf vor, der den Schutz vor Computerkriminalität mit strafrechtlichen Maßnahmen verbessern soll. Und handelt Deutschland erneut den Verlust von zahlreichen hochqualifizierten Arbeitsplätzen im Hochtechnologiesektor ein.