Passwörter verschlüsseln / AES / headless Debian

[ddlab]

Hallo, ich hoffe, daß ich mit meinem ersten Beitrag hier richtig bin und auf gleichgesinnte "sicherheitsaffine" Freaks stoße, die mir weiterhelfen können. Danke vorab.

Folgendes Szenario: Seit geraumer Zeit programmiere ich an einem Kassensystem (POS), das zunächst lokal ohne login als Webserver läuft, also komplettes System installiert: wheezy mit apache2 / mysql / webmin / phpmyadmin / smb / curl / printserver...
Die Bedienung erfolgt über jedes x-beliebige verfügbare Gerät per LAN/WLAN und Browser, kann ein iPad oder android-Tablet oder ein PC sein. Die Drucker (Label und Bon) und die Kassenschublade sind dabei an den Server angeschlossen, der apache-Benutzer www-data hat alle notwendigen Rechte. Die Barcodescanner sind per BT oder USB an das Endgerät gekoppelt. Das Login der Bediener läuft komplett über AES256, wobei sämtliche Anfragen an den Server grundsätzlich verschlüsselt sind (da auch die Authentifizierung jeder Anfrage per AES läuft), bei den Antworten verschlüssele ich wegen der Performance nur sensible Daten, nicht aber z.b. html / css und js.
Dieses System läuft derzeit stabil im ersten praktischen Einsatz, völlig lokal, ohne notwendige Internetverbindung.

Jetzt das Problem und die Fragestellung: Im nächsten Schritt arbeite ich jetzt an einer internetbasierten Erweiterung. Um das System und die Umsätze (Ein- und Ausgaben) nach den GDPdU-Vorschriften einerseits für potentiell vor der Tür stehende Finanzamts-Prüfer zugänglich zu machen, andererseits die produzierten Daten gegen nachträgliche Manipulation von externen Stellen signieren zu können, brauche ich also eine abgesicherte Kommunikation, damit meine ich nicht nur SSL für den Transport, sondern eben auch die Authentifizierung gegen unbefugte Benutzung. Von der tief im System verwurzelten AES-Verschlüsselung möchte ich unter keinen Umständen abstand nehmen.
Dazu kommt dann noch eine Artikelstammdaten-GUI, die Einrichtung eines dashboards für sämtliche Auswertungen etc. liegt dann auch nahe.
Die Daten zwischen dem lokalen Webserver und dem Internetserver werden per cURL und JSON hinundhergeschickt. Soweit so gut, jetzt kommt aber die Verschlüsselung ins Spiel.

1. Die mögliche Lösung, die ich aber umgehen möchte: Sämtliche mögliche Benutzer auf beiden Systemen anlegen (im Web und lokal), um sämtliche Kommunikation mit deren Schlüsseln durch sämtliche Stationen durch zu routen. Hat den Nachteil, daß jeder zukünftige Mitarbeiter sich sowohl am Webserver als auch am lokalen Server mit den gleichen etwas umfangreichen Prozeduren registrieren muß. Per Zufall vom Server generierte Passwörter, aus denen der AES-Key erstellt wird, werden in Teile zerlegt über mehrere zeitlich versetzte Emails bzw. als sms zugestellt, der Benutzer muß diese in der richtigen Reihenfolge bei seinem ersten Login wieder zusammensetzen. Wenn dies geklappt hat, steht die Verschlüsselung und er kann über diesen "Tunnel" sein eigenes neues Passwort vergeben.

2. Die gesuchte Lösung: Ich vergebe ein (kundenspezifisches) Standard-Passwort für den User www-data (damit meine ich nicht das Linux-Kennwort), das ab dann für sämtliche Kommunikation zwischen Lokal- und Webserver genutzt wird.

Das Problem: Der (lokale) Kassenserver unterliegt im Ernstfalle dem physischen Zugriff eines böswilligen Angreifers, sei es bei einem Einbruch wird die Kiste gestohlen, oder jemand startet den Rechner über Nacht mit einem Fremdsystem (Live-USB-Stick). Wie und wo kann ich das Kommunikations-Passwort für www-data möglichst verschlüsselt ablegen, daß es im normalen Betrieb zur Verfügung steht (der Server läuft wie gesagt headless ohne Login), daß es aber beim externen Zugriff nicht herauszubekommen ist ?

Oh mann, ein halber Roman, aber ich denke zum Verständnis der Situation war das nötig.
Ich danke für Eure Hilfe.

[ddlab]

Versuch einer Selbstantwort:

Wenn mir jemand sagt: "Da wirst Du wohl nicht um dm-crypt und Passworteingabe zum booten herumkommen" und derjenige weiß was er sagt, bin ich zwar nicht ganz an meinem Ziel, die Kiste ohne Bildschirm und Tastatur zu betreiben, aber ich würde es verstehen. Dann würde sich zwangsläufig die nächste Frage anschließen: Um die Performance so hoch wie möglich zu halten, also den Verschlüsselungsaufwand so gering wie nötig, würde ich gern wissen, wie ich mysql während oder nach der Installation beibringe, die Tabellen- (respektive die eigene Ordner-) Struktur auf diese verschlüsselte Partition zu packen. Dann kann das oben erwähnte Master-Passwort einfach in der DB liegen.

Danke für Antworten vorab.

[gehrke]

Vorweg: Ich bin nicht so tiel in Dein spezielles Anforderungsszenario eingestiegen. Ob das alles sinnvoll ist, kann ich demnach nicht sagen.

Ich möchte nur auf den zuletzt von Dir eingebrachten Aspekt betreffend LUKS eingehen, dass Du nämlich für eine Festplattenverschlüsselung mit LUKS nicht zwingend Tastatur + Monitor benötigst. Du hättest unterschiedliche alternative Möglichkeiten, die Passphrase bzw. den Schlüssel über das Netz einzugeben, wenn die Security Policy Netzwerk erlaubt:

Entweder verschlüsselst Du nur den Teil des Systems mit den Daten. Dann könnte das OS inkl. Netzwerk und SSH ohne weiteres Zutun booten und würde die Möglichkeit bieten, den Crypt-Container manuell in einer Remote-Session zu entschlüsseln.

Oder Du verschlüsselst das ganze System und bootest über IPMI inkl. manueller Eingabe der Passphrase.

Beides setzt sicherlich den Einsatz einer vertrauenswürdigen Firewall und möglicherweise eines VPNs voraus und birgt nicht unerhebliche Risiken (wie alles, was irgendwie mit dem Netz zu tun hat). Auch ist die Verwendung von SSH mit verschlüsseltem pubkey ratsam.

Wenn es innerhalb dieser Infrastruktur einen als ausreichend sicher anzusehenden Server gibt, dann könntest Du ein Szenario implementieren, in welchem dieser Server per SSH die Entschlüsselung auf den jeweiligen Clients aktiv vornimmt. In diesem Fall ginge das ohne manuelle Eingriffe, nur müssten die Schlüssel auf diesem Server abgelegt werden, wodurch diesem eine elementare Rolle im Sicherheitskonzept zufällt.

Ob das alles bei einem Kassensystem sinnvoll und sicher genug ist, kann ich nicht beurteilen. Jedenfalls hast Du damit die Möglichkeit, das System remote zu administrieren und hast den Schlüssel für den LUKS-Container nicht unverschlüsselt auf der Platte des/der Clients liegen.

Wenn Du aus guten Gründen kein Netzwerk haben willst, könntest Du auch die gute alte serielle Schnittstelle verwenden, um das System lokal zu administrieren und die Passphrase einzugeben. Dafür ist dann ebenfalls keine Tastatur und Monitor notwendig, lediglich ein Notebook für den Admin.

Aber bedenke bitte, dass ein solcher LUKS-Container prinzipiell nur einen bestimmten Sicherheitsaspekt abdeckt: LUKS bildet eine Zwischenschicht, welche absolut transparent ist, solange der Schlüssel für den Container vorliegt. Typischerweise ist das der Fall unmittelbar nach dem Booten und von da an ist der Container online bis das System runterfährt. Für einen angemeldeten User gibt es bei einem entsperrten LUKS-Container demnach kaum Unterschiede zum Betrieb ohne LUKS (weswegen Du für den Spezialfall mysql auch nichts besonderes unternehmen musst) und für Online-Attacken auch keinen Schutz. Dagegen schützt LUKS die Daten des Containers verlässlich gegen Offline-Attacken, wenn beispielsweise das System geklaut wird und dabei stromlos gemacht wird. An einem verschlossenen LUKS-Container dürfte sich AFAIK nahezu jeder Angreifer die Zähne ausbeißen, wenn er nicht auf anderem Wege an den Schlüssel kommt.

Und weiter: Verschlüsselung (nicht nur mit mit LUKS) erfordert prinzipbedingt mehr Ressourcen bei der CPU. Bei üblicher PC-Hardware ist das schon seit vielen Jahren kein nennenswertes Thema mehr. Anders mag das aussehen bei spezieller Embeded-Hardware, welche zwar oft kostengünstig und energieeffizient ist, aber meist auch schwachbrüstig und/oder stark spezialisiert.

[NAB]

Öhm ... du könntest das "Kommunikationspasswort" einfach auf einem Webserver hinterlegen, verschlüsselt, und der Server holt es sich und entschlüsselt es beim Start. Im Falle eines unqualifizierten Eingriffs in den Server muss das Passwort nur ganz schnell aus dem Netz verschwinden.

Aber mal ne andere Frage ... wenn du schon erwartest, dass jemand einfach in den Serverraum spaziert und den Server mitnimmt ... wäre dann nicht vielleicht eine Investition in einen anderen Sicherheitsbereich sinnvoller? Ne Tür zum Beispiel?

Ein ausreichend versierter Angreifer kann den Server nämlich durchaus im laufenden Betrieb mitnehmen und dann zuhause in aller Ruhe analysieren ... und kommt ggf. auch an ein dm-crypt-Passwort heran. Einfacher wäre es, dir einen modifizierten Bootloader unterzuschieben.

Ein Prozessor mit Hardware-AES-Beschleunigung ist bei Festplattenverschlüsselung übrigens dringend zu empfehlen. Spätestens bei einer SSD wird auch ein aktueller Prozessor sonst gut ausgelastet.

[gehrke]

Aber mal ne andere Frage ... wenn du schon erwartest, dass jemand einfach in den Serverraum spaziert und den Server mitnimmt ... wäre dann nicht vielleicht eine Investition in einen anderen Sicherheitsbereich sinnvoller? Ne Tür zum Beispiel?

Zur Architektur der Anwendung in diesem konkreten Fall kann und will ich gar nichts sagen. Aber zur Sicherheit gehört natürlich auch die physische Sicherheit, was hiermit gemeint war:

Wenn es innerhalb dieser Infrastruktur einen als ausreichend sicher anzusehenden Server gibt, [...]

Nur lässt sich so ein Server natürlich viel leichter physisch absichern als die Clients, die ja wahrscheinlich exponiert im Laden stehen. Von daher sollte man sich genau überlegen, was wo liegt und wie abgesichert wird.

[ddlab]

Erst mal vielen Dank an gehrke und NAB für die Antworten.

Kurz noch zur Erläuterung der Hardware und der Funktion des genannten "lokalen Servers": Dieser steht also nicht in einem Serverraum, sondern ist im Ladengeschäft unter der Theke, da an ihn die Drucker angeschlossen sind, die räumlich unmittelbar zum Betrieb nötig sind. Die Bezeichnung "Server" mag hier etwas irritieren. Da er aber eben per apache etc. das Programm ausliefert, habe ich ihn so genannt. Die Bedienung erfolgt wie gesagt über "Terminals" / "Endgeräte", die eben ein iPad oder ein normaler vorhandener PC sein können.
Die Hardware des "Servers" ist ein ITX-Board mit INTEL atom D525 2x1,8GHz, dazu 4GB DDR3 und 4x256GB-Platten als RAID10.
Bei der AES-Verschlüsselung und Auslieferung von über Tausend Datensätzen hatte er schon einige Male die Latte des Ajax-Timeouts von 2sec gerissen. Er hat es sogar bis auf 8sec geschafft Seit ich nur noch die sensiblen Daten in einem eigenen Tag

Code: Alles auswählen

<encrypted>aes-codierter Inhalt</encrypted>

codiert sende, ansonsten html unverschlüsselt, wurde es schon deutlich besser. Noch besser wurde es, nach dem ich html völlig separat lade, und den sensiblen Inhalt in einem komplett separat verschlüsselten JSON, was ich dann clientseitig mit js auspacke und in das html parse, bzw. den html-code mit den entschlüsselten Daten von js erstellen lasse.

Zurück zum Thema: Ich bin vorerst zu folgendem Schluß gekommen: Ich muß mit dem Kunden über seinen Sicherheitsanspruch sprechen. Sämtliche Daten, die mittels des "Kommunikationsschlüssels" geschützt werden sollen, gegen m-i-t-m-Angriffe unterwegs oder gar am Webserver abgelauscht zu werden, sind ja identisch, mit den Daten, die auf dem lokalen Server liegen. Also gegen diese Angriffe außerhalb des Ladens ist es nach wie vor sinnvoll. Gegen physischen Zugriff zum lokalen Server schützt meines Erachtens nur ein komplett verschlüsseltes System mit dm-crypt / LUKS. Solange ich das nicht mache, kann ich auch den "Kommunikationsschlüssel" sozusagen blank in der config-php liegenlassen. Ich glaube, die Wahrscheinlichkeit, daß der Kunde seinen USB-Stick mit dem Backup in der Kassenschublade liegenlässt, ist weitaus größer, als daß der Computer entwendet wird.

Soweit dazu.
Weitere Meinungen herzlich willkommen, schönen Sonntach erst mal.

[NAB]

Dieser steht also nicht in einem Serverraum, sondern ist im Ladengeschäft unter der Theke, da an ihn die Drucker angeschlossen sind, die räumlich unmittelbar zum Betrieb nötig sind.

Die Begründung klingt drollig, angesichts der Tatsache, dass Drucker ganz ohne Kabel angeschlossen werden können, oder bei Netzwerkdruckern auch über 100 meter lange Kabel.

Soweit ich dich verstehe, hätte eh das gesamte Tresenpersonal Zugang zu dem Server. Da könnte auch der erste Mitarbeiter den Server mit einem USB-Stick "aufschließen", und der letzte schließt ihn wieder ab, ebenso wie die Ladentür.

Alternativ wäre ein "Server im Safe"-Konzept denkbar.

Die Hardware des "Servers" ist ein ITX-Board mit INTEL atom D525 2x1,8GHz, dazu 4GB DDR3 und 4x256GB-Platten als RAID10.

Bei dem Prozessor kannst du AES-Festplattenverschlüsselung vergessen. Eventuell hat AMD was mit Hardware-Beschleunigung in ähnlicher Preis/Leistungsklasse.

Gegen physischen Zugriff zum lokalen Server schützt meines Erachtens nur ein komplett verschlüsseltes System mit dm-crypt / LUKS.

Eben nicht - siehe Angriffsszenarien oben. Die Konkurrenz könnte sich freuen, einen Bootloader auf dem System unterzubringen um Daten abzuschnorcheln.

Du hast Recht ... die konkrete Bedrohung kann hier niemand abschätzen ... du musst dem Kunden die Entscheidung überlassen. Purer Vandalismus sollte auch in Betracht gezogen werden - von Baseballschläger bis "Datenbank manipulieren".

[ddlab]

Die Begründung klingt drollig, angesichts der Tatsache, dass Drucker ganz ohne Kabel angeschlossen werden können, oder bei Netzwerkdruckern auch über 100 meter lange Kabel.

Über einen kleinen Printserver hab ich schon nachgedacht. Netzwerk-/ WLAN-Drucker sind im Moment nicht im Budget. Da gab es schon ein Kassensystem und dzf. verwendbare Hardware. Wie lang ein Parallel- oder USB-Kabel zum Drucker sein kann, habe ich noch nicht getestet.

Da könnte auch der erste Mitarbeiter den Server mit einem USB-Stick "aufschließen", und der letzte schließt ihn wieder ab, ...

Beziehst Du Dich auf die Stick-Lösung von LUKS ? Das würde Sinn machen. Aber siehe Hardware...

Bei dem Prozessor kannst du AES-Festplattenverschlüsselung vergessen.

Hab ich vermutet, angesichts des erlebten Ajax-timeouts.

Gegen physischen Zugriff zum lokalen Server schützt meines Erachtens nur ein komplett verschlüsseltes System mit dm-crypt / LUKS.

Eben nicht - siehe Angriffsszenarien oben. Die Konkurrenz könnte sich freuen, einen Bootloader auf dem System unterzubringen um Daten abzuschnorcheln.

Den part hab ich nicht verstanden, aber das wird sicher noch. So wie ich das verstehe, ist dagegen aber garkein Kraut gewachsen, solange der Rechner nicht im Tresor ist und bleibt. Aber gesetzt den Fall, es gäbe den besagten manipulierten Bootloader, was würde er können? Wäre da nicht auch dm-crypt oder sogar eine verschlüsselte Virtualbox sinnlos ?

[ddlab]

Ich denke jetzt mal "laut" (Vorsicht, kann Unsinn enhalten):
- sensible Daten direkt in der Datenbank AES-verschlüsselt ablegen
- dm-crypt verwenden um /tmp mit einem random-Passwort für die session zu verschlüsseln.

Code: Alles auswählen

crypttmp  /dev/hda8  /dev/urandom  tmp

- wenn Internetconnection, dann Mitarbeiter loggt sich ein und zieht vom Webserver in seinem AES-"Tunnel" das Masterpasswort, das für Kommunikation mit dem Webserver und für die DB-Verschlüsselung da ist. Dieses wird als Datei in /tmp gespeichert.
- wenn keine Internetconnection, dann Mitarbeiter holt den Master-USB-Stick aus dem Safe, der vorher über udev registriert wurde, script zum Übertragen in /tmp wird gestartet.
- wenn kein Safe-Schlüssel zur Hand und Chef im Urlaub, dann mich anrufen. Ich sende Email (auf das Smartphone des Mitarbeiters, weil ja kein Internet) oder sms mit neuem Einmal-(disposal)-Schlüssel, den ich vorher auf dem Webserver hinterlegt habe. Dieser verfällt entweder, wenn das nächste Mal Internet da, oder wenn Rechner ausgeschaltet -> weil liegt in /tmp. (disposal deshalb, damit die Email mit dem Schlüssel später wertlos ist)

Wie wäre der ?

[ddlab]

Wie gesagt, Vorsicht Unsinn. Natürlich kann ein neuer Schlüssel nicht die vorhandenen Daten in der DB entschlüsseln

[NAB]

Ich denke jetzt mal "laut" (Vorsicht, kann Unsinn enhalten):

Wogegen willst du jetzt absichern? Das hilft weder gegen "geklauten Server" noch gegen "booten per USB-Stick", um ein kleines Script in den Bootprozess zu integrieren.

Dieses wird als Datei in /tmp gespeichert.

Wie wär's mit ner Ramdisk?

Wie gesagt, Vorsicht Unsinn. Natürlich kann ein neuer Schlüssel nicht die vorhandenen Daten in der DB entschlüsseln

Bei LUKS z.B. kannst du mehrere Schlüssel hinterlegen. Sie passen alle. Das dient zum Beispiel dazu, dass der Admin noch an die Daten rankommt, wenn ein Mitarbeiter das Passwort geändert hat und dann vom LKW überfahren wird. Schlüsselmanagement, auch mit zeitlicher Begrenzung, ist machbar..

Wie lang ein Parallel- oder USB-Kabel zum Drucker sein kann, habe ich noch nicht getestet.

Für Parallel hab ich das längst vergessen. USB-Kabel dürfen 5 m lang sein, wobei auch 10 m Kabel funktionieren können. Für USB gibt es allerdings "Repeater", mit denen du theoretisch beliebig lange Kabelstrecken basteln könntest.

Beziehst Du Dich auf die Stick-Lösung von LUKS ?

Nein, nicht zwangsläufig. Du fragtest doch oben, wo du dein "Kommunikations-Passwort" sicher ablegen kannst. Zum Beispiel auf _einem_ USB-Stick (der Chef kriegt natürlich eine Kopie). Der Stick ist dann ähnlich wichtig wie der Schlüssel zum Geschäft ... ohne ihn läuft das Kassensystem nicht. Eine kurzzeitige Entfernung würde sofort auffallen. Morgens muss ihn ein Mitarbeiter einstecken, und den Rechner starten, und Abends wird das Kassensystem heruntergefahren und der Schlüssel abgezogen. Der Server sollte noch die Seriennummer des Sticks abfragen, um Kopien zu verhindern, und der Stick sollte randvoll mit sinnlosen Daten sein.

Das ist natürlich keine absolut sichere Lösung, aber Diebstahl des Sticks (tagsüber) würde auffallen, und bei Diebstahl des Rechners (nachts) ... öhm ... naja ... soweit ich dich verstanden habe, liegt auch die Datenbank in Klartext vor. Eventuell wäre über ein Verschlüsseln derselben beim Herunterfahren nachzudenken.

Den part hab ich nicht verstanden, aber das wird sicher noch. So wie ich das verstehe, ist dagegen aber garkein Kraut gewachsen, solange der Rechner nicht im Tresor ist und bleibt. Aber gesetzt den Fall, es gäbe den besagten manipulierten Bootloader, was würde er können? Wäre da nicht auch dm-crypt oder sogar eine verschlüsselte Virtualbox sinnlos ?

dm-crypt verschlüsselt nicht die gesamte Festplatte. Der Inhalt von /boot liegt unverschlüsselt auf der Platte. Du kannst also nach Herzenslust Kernel oder Initramdisk manipulieren, um z.B. ein kleines Script einzuschleusen, das beim Entschlüsseln des Systems das Passwort abfängt und an eine Mailadresse schickt.

Auch dagegen gibt es Mittel ... zum Beispiel /boot auf eine CD-ROM zu brennen, die dann auch überwacht werden müsste, oder "Secureboot". Es wird nur immer komplizierter.

Wer Zugriff auf die Hardware hat, kann das System immer manipulieren, so dass es nachher unsicher ist. Überleg dir lieber, wie du das System physisch sicherst. Das kann bei BIOS-Passwort, Kensington-Lock und gesperrten USB-Buchsen anfangen. Einen Geldautomaten kannst du ja auch nicht einfach mit einem USB-Stick booten. Den Pfandflaschenautomaten bei Aldi auch nicht.

[gehrke]

dm-crypt verschlüsselt nicht die gesamte Festplatte. Der Inhalt von /boot liegt unverschlüsselt auf der Platte. Du kannst also nach Herzenslust Kernel oder Initramdisk manipulieren, um z.B. ein kleines Script einzuschleusen, das beim Entschlüsseln des Systems das Passwort abfängt und an eine Mailadresse schickt.

Auch dagegen gibt es Mittel ... zum Beispiel /boot auf eine CD-ROM zu brennen, die dann auch überwacht werden müsste, oder "Secureboot". Es wird nur immer komplizierter.

Ergänzung 1: Oder ein USB-Stick für /boot, welcher nach dem Booten abgezogen und 'am Mann' verbleibt. Mein persönlicher Favorit, weil damit auch System-Updates mit Neubau von initram oder grub2 sehr einfach sind (weil beschreibbar).
Ergänzung 2: Ist relativ sicher, solange man kein UEFI hat. Damit besteht schon vorher ein weiterer Angriffsvektor, der sogar relativ mächtig zu sein scheint.

[NAB]

Ergänzung 2: Ist relativ sicher, solange man kein UEFI hat. Damit besteht schon vorher ein weiterer Angriffsvektor, der sogar relativ mächtig zu sein scheint.

Die Angriffe auf UEFI basieren darauf, dass du trotz aktiviertem SecureBoot das UEFI manipulieren kannst, falls du Administrator-Rechte erlangst.

Bei einem gewöhnlichen BIOS kannst du mit Admin-Rechten so oder so das BIOS flashen.

Aber mit Admin-Rechten kommst du eh an alle Daten ran, musst also gar nicht die Firmware manipulieren.

[ddlab]

An dieser Stelle leg ich mal ne Schreibpause ein, und versuch das alles mal zu verdauen, und natürlich Pläne zu schmieden.
Vielen Dank an gehrke und NAB für die Mühe, wo finde ich Euren "buy me a coffee"-Button ?
Ich meld mich ggf. später noch mal.

[gehrke]

Über einen kleinen Printserver hab ich schon nachgedacht. Netzwerk-/ WLAN-Drucker sind im Moment nicht im Budget. Da gab es schon ein Kassensystem und dzf. verwendbare Hardware. Wie lang ein Parallel- oder USB-Kabel zum Drucker sein kann, habe ich noch nicht getestet

Nur noch ein Hinweis dazu, keine Ahnung ob es Dich weiterbringt: Ein Raspberry Pi für unter 50€ kann auch als Printserver (oder allgemein als Proxy) eingesetzt werden. Das könnte evtl. die Reichweite erheblich erhöhen, weil damit dann Ethernet oder gar WLAN für die Drucker möglich werden. Mit allen Risiken und Nebenwirkungen...