© Baloncici / 123RF.com

Container sind keineswegs intrinsisch sicherer als Anwendungen, die direkt auf dem System laufen. Löchrige Software und falsche Einstellungen machen in beiden Fällen Probleme. Doch es gibt Werkzeuge, die dem Administrator in Sachen Container-Sicherheit unter die Arme greifen.

Seit Jahren kennen Hersteller wie Anbieter nur noch einen Trend: Container. Ganz gleich, bei wem man ins Portfolio schaut: Überall stapeln sich die Ansätze und Lösungen, um die Software auf den Systemen der Kunden möglichst schnell in Docker- oder sonstige Container zu verpacken. Längst schicken die Softwarebehälter sich an, die Welt des klassischen Enterprise-Linux zu verändern. Wo heute noch direkt auf dem System installierte Anwendungen den Ton angeben, werden RHEL, SLES und Konsorten bald schon bloße Abspielwerkzeuge sein und nur noch aus einem minimalen Systemkern und einer Laufzeitumgebung für Container bestehen.

Ein Argument, das Red Hat & Co. dabei gern ins Feld führen, ist die vorgeblich höhere Sicherheit von Containern. Ganz von der Hand zu weisen ist das im ersten Augenblick nicht: Der Einbruch in eine Anwendung, die im Container läuft, verursacht aus Sicht der Systemadministration zunächst tatsächlich weniger Probleme. Planer und Administratoren tun an dieser Stelle aber auch gut daran, nicht allzu schnell einen geistigen Haken hinter das Thema Container-Sicherheit zu setzen. Auch in diesem Umfeld bleiben Sicherheitslöcher weiter ein Thema, zumal sich das typische Angriffsszenario in den letzten Jahren merklich verändert hat. Ging es früher meist darum, die Kontrolle über ein ganzes System zu erlangen, um es für eigene Zwecke zu missbrauchen, spielt heute der Diebstahl von Daten eine wesentlich größere Rolle. Dabei ist es unerheblich, ob beispielsweise eine MySQL-Instanz im Container läuft oder nicht: Gelingt ein Angriff von außen, sind die Daten weg.

Der Administrator reibt sich bei Containern allerdings regelmäßig verwundert die Augen, erhöhen sie doch faktisch den Administrationsaufwand erheblich. Das demonstriert schon ein kleiner Versuch: Damit MySQL aus einem Container heraus laufen kann, muss man es erst einmal in einen solchen verpacken, was per se die administrativen Spielregeln ändert. Bei direkt auf dem Server laufenden Datenbanken etwa kann man üblicherweise per »mysql -u root« in eine SQL-Shell gelangen. Bei Containern funktioniert das so zumindest ab Werk meist nicht mehr. Stattdessen bedarf es einer Port-Weiterleitung und auf dem Host einer Konfigurationsdatei für den SQL-Client, die den Zugriff mit der richtigen Kombination aus Passwort und Benutzernamen ermöglicht.

Noch wilder gerät die Sache, greift der Administrator zu OpenShift, Rancher und dergleichen. Diese Werkzeuge verpacken Anwendungen in einen Container und den Container dann seinerseits noch in einen Kokon aus Bind-Mounts, um Konfigurationsdateien und die Datenverzeichnisse wo nötig dynamisch einzubinden. Die Konfiguration eines Diensts findet sich dann an einem nicht gerade intuitiven Ort wie »/var/lib/container-puppet/neutron-api/etc/neutron/neutron.conf«. Der Monster-Pfad stammt übrigens aus einem Beispiel aus der realen Welt, und zwar aus Red Hats OpenStack-Distribution, die ebenfalls komplett in Container-Form daherkommt. Wie soll ein Admin bei derartigem Wildwuchs die Kontrolle über laufende Anwendungen in Containern behalten und dabei auch noch Sicherheitsprobleme in seine Überlegungen einbeziehen?

Kein Problem, versprechen viele Hersteller, und wollen dem Administrator diverse Werkzeuge an die Hand geben, um eine Container-Flotte automatisiert im Hinblick auf Sicherheitsprobleme zu überwachen. Das Versprechen ist dabei nicht weniger als das All-in-Paket: Die angebotenen Werkzeuge überprüfen einzelne Container oder docken gleich an ein lokales CI/CD-System an, um entstehende Container und ihre Abbilder komplett automatisiert zu prüfen und zu überwachen. Bunte Schnittstellen mit tollen Statistiken gehören selbstredend ebenfalls dazu. Wie man es auch dreht und wendet: Hat der Administrator es mit einem Setup zu tun, das quasi nur noch aus Containern besteht, braucht er eine solche Lösung in irgendeiner Form.

Wir wagen dazu eine kleine Marktübersicht. Das Kandidatenfeld umfasst Clair (Abbildung 1), Anchore, Dagda, Falco, Harbor, Xray sowie Qualys Container Security. All diese Werkzeuge versprechen mehr oder minder dasselbe: Sie wollen dem Administrator die lästige Aufgabe des umfassenden Sicherheits-Monitorings für den lokalen Container-Zoo abnehmen. Schon ein kurzer Vergleich mit wenigen Proben ergibt allerdings, dass bei den Anbietern keineswegs alles Gold ist, was im Prospekt glänzt. Welche Werkzeuge taugen also tatsächlich etwas, und bei welchen war eher das Marketing des Gedankens Ursprung?

Abbildung 1: Clair gehört zu Quay und gelang über den Umweg von CoreOS zu Red Hat. Die Komponente untersucht Images im Hinblick auf bekannte Sicherheitsprobleme. Quelle: Red Hat

Clair

Wollte man im Sicherheitszirkus rund um Container alte Hasen ausmachen, wäre Clair [1] sicherlich ein Kandidat. Clair ist allerdings keine eigenständige Softwarekomponente, sondern gehört zum Quay-Projekt, also zu jener Container-Registry, die Red Hat einst zusammen mit CoreOS erwarb, um sie später unter eine freie Lizenz zu stellen.

Mit der Akquisition bewiesen die Red-Hat-Leute seinerzeit gehörig Weitblick: Als der Kauf über die Bühne ging, begnügten viele Administratoren sich noch damit, beliebige Container-Abbilder aus dem Internet herunterzuladen und lokal auszuführen. Dem Sicherheitsverantwortlichen rollten sich dabei naturgemäß die Fußnägel hoch, denn eine derartige Blackbox in der eigenen Umgebung zu betreiben, ist sehr gefährlich. Das Linux-Magazin hat bei etlichen Gelegenheiten vor genau diesem Ansatz gewarnt.

Quay bot die Möglichkeit, eigene Container-Registries zu betreiben und sie mit eigenen auditierten und handverlesenen Abbildern zu betanken. Implizit trug es damit bereits zu einem Sicherheitskonzept für Container bei. Clair ist die logische Erweiterung: Es agiert als Security-Scanner für jene Abbilder, die in Quay liegen. Der Name leitet sich vom französischen Wort “clair” ab, das so viel wie Klarheit bedeutet. Setzt der Administrator auf Clair, so die Suggestion, hat er eine klare Sicht auf die Sicherheit seiner Container.

Unter der Haube besteht Clair aus einer Datenbank, einem Dienst zum Indizieren von Abbildern, einem weiteren für das Erkennen von Sicherheitslücken sowie einem dritten für das Aussenden von Benachrichtigungen über gefundene Probleme. Ganz im Stil einer Mikroarchitekturanwendung lassen sich sämtliche Komponenten dabei ebenfalls in einzelnen Containern betreiben und skalieren in die Breite. Performance-Probleme gibt es mit Clair mithin selbst in großen Umgebungen nicht.

Das Überprüfen von Containern ist dann relativ simpel: Über einen einzelnen Kommandozeilenbefehl weisen Sie Clair an, ein Abbild unmittelbar zu prüfen. Dazu greift es auf eine zentrale, anbietergepflegte Datenbank aus Sicherheitslücken zu und vergleicht die im Abbild vorhandene Software mit den dort angegebenen Versionsnummern und Dateien. Findet es eine Übereinstimmung, schlägt Clair Alarm. Zudem generiert es eine grafische Übersicht der nach Priorität geordneten gefundenen Sicherheitslücken. Für jeden einzelnen Test zeigt hier ein Mausklick auf den jeweils zum Test gehörenden Schalter genauere Informationen zur Sicherheitslücke an, darunter die CVE-Nummer.

Aufgrund der relativ simplen Aufrufsyntax lässt sich Clair zudem gut in CI/CD-Prozesse integrieren. Dazu legen Sie etwa fest, dass ein lokaler Bauvorgang jedes erzeugte Container-Abbild vor dem Hochladen in die Registry erst durch Clair prüfen lässt. Clair eignet sich damit für Unternehmen, die ihre Container-Abbilder prüfen wollen, ohne sich gleich ein umfassendes Framework ins Haus zu holen.

Anchore

Deutlich umfassender ans Werk geht da schon Anchore (Abbildung 2), eine Plattform, die unter der Haube wieder aus mehreren Komponenten besteht, namentlich aus Syft und Grype [2]. Der Hersteller bewirbt sein Produkt vollmundig als SBOM-basiert. Dabei steht SBOM als Abkürzung für Software Bill of Materials und beschreibt ein Format, anhand dessen sich eine Software mit sämtlichen sie bestimmenden Details genau beschreiben lässt. Wer sich schon mal mit CI/CD beschäftigt hat, merkt schnell, wo die Reise hingeht: Anchore dockt als Plattform bevorzugt an CI/CD-Umgebungen an und klinkt sich in den Entwicklungsprozess ein. Syft und Grype greifen dabei ineinander.

Abbildung 2: Eine umfassende Lösung für einen Security- und Audit-Trail in Kubernetes bietet Anchore, das dann allerdings viel eigene Infrastruktur benötigt. Quelle: Anchore

Ganz im Stil einer App auf Basis des Mikroarchitekturansatzes inventarisiert Syft zunächst die vorliegende Software. Es erstellt eine komplette Liste der gegebenen Abbilder, der sich darin befindlichen Dateien sowie der Versionen der im Abbild genutzten Software. Der eigentliche Sicherheitsscanner Grype erstellt dann auf Grundlage der Daten aus Syft eine Zusammenfassung der Bedrohungslage. Dabei greift es wie Clair im Hintergrund auf bestehende, anbietergepflegte Bedrohungsdatenbanken zurück.

Grype beherrscht allerdings einen deutlich größeren Funktionsumfang als Clair. So ist es beispielsweise in der Lage, anhand vom Admin vorgegebener Regeln auch Quelltext sowie Dateien mit Textinhalt in Containern zu überprüfen. Die Regeln, die es dabei anwendet, können beispielsweise Programmiergrundsätze festlegen. Obendrein beherrscht Grype auch das Scannen von Quelltextverzeichnissen. Die Idee dahinter ist offensichtlich: Würde der Container-Bau ein Image produzieren, das eine Komponente mit Sicherheitslücken enthält, ist es unnötig, das Image überhaupt zu bauen. Stattdessen muss es bereits im Lauf des Bauprozesses eine entsprechende Fehlermeldung geben: Das erspart dem Build-System unnötigen Traffic und überflüssige Last. Das fertige Abbild könnte man wegen des Security-Problems sowieso nicht verwenden. Im Gegensatz zu Clair bietet Anchore mit seinen Komponenten Grype und Syft also die Möglichkeit, schon früh im Prozess auf Sicherheitsprobleme hinzuweisen und nicht erst dann, wenn ein Abbild vorliegt.

Der Anbieter bezeichnet diese Vorgehensweise als End-to-End-Security. Auf der Kehrseite der Medaille handelt man sich allerdings eine hohe Komplexität schon auf der Ebene des Security-Scanners ein. Während sich Clair relativ schnell ausrollen lässt und flugs erste Checks vornimmt, befasst sich der Admin bei Anchore erst einmal mit dessen Eigenheiten und Deployment-Mechanismen. Freilich steht auch für Anchore eine fertige Integration in Kubernetes, Docker und dergleichen zur Verfügung. Das erfordert dann aber auch lokale Werkzeuge, die weit über das übliche Kubectl hinausgehen. Mal eben so bringt man Anchore also nicht an den Start. Der Mühe Lohn ist ein deutlich umfassenderes Security Scanning, das auch Faktoren der Compliance einbeziehen kann. So findet das Syft-Grype-Gespann beispielsweise bei Bedarf auch Software, die nicht erwünschte Lizenzen nutzt.

Einen großen Haken im Vergleich mit Clair hat die Lösung allerdings: Syft und Grype stehen zwar unter einer freien Lizenz und lassen sich einfach installieren und nutzen. Anchore vertreibt zusätzlich aber auch eine Plattform mit zentralen Steuermöglichkeiten und der Option, gefundene Probleme in grafischer Manier aufzubereiten. Diese integrierte Plattform gibt es allerdings nur gegen Geld. Anchore eignet sich also eher für größere Umgebungen, in denen man die Themen Security und Compliance umfassend zentral abdecken möchte.

Dagda

Patenter, aber auch deutlich eingeschränkter geht da Dagda [3] ans Werk, das in Form und Umfang eher an Clair als an Anchore erinnert. Das in Python geschriebene Werkzeug funktioniert denkbar einfach: Sie initialisieren die lokale Datenbank mit Verwundbarkeiten und versehen sie mit den aktuellsten verfügbaren Daten. Dann übergeben Sie »dagda.py« den Namen eines Abbilds, die zu prüfende Version sowie den Prüfmodus. Fertig ist der Lack: Dagda lädt das Abbild herunter, analysiert die darin installierte Software und gibt schließlich eine Liste der darin gefundenen Verwundbarkeiten im JSON-Format aus.

Wer nun allerdings die Hoffnung hegt, Dagda sei tatsächlich ein auf die lokale Nutzung beschränktes Werkzeug, irrt gewaltig. Dagda besteht zumindest aus einem ReST-Dienst und einer MongoDB-Datenbank im Hintergrund, die das Tool dazu nutzt, Abbilder zu prüfen. Freilich lässt Dagda selbst sich in Form eines Docker-Containers betreiben und ausrollen, sodass zumindest das initiale Setup leicht von der Hand geht. Damit kommt man deutlich schneller an den Start als etwa mit Anchore.

Durchaus bemerkenswert: Dagda kann Abbilder nicht nur auf Sicherheitslücken hin untersuchen, sondern erkennt auch unerwünschte Software in Form von Malware oder Trojanern. Hier hat man offensichtlich aus dem beliebten Angriffsmuster aus der Frühzeit der Cloud gelernt, Bitcoin-Miner in Containern zu verstecken und so fremde Rechenleistung zu stehlen. Dagda schiebt dem einen Riegel vor und sorgt dafür, dass keine Abbilder starten, die unerwünschte Inhalte enthalten.

Für seine Tests setzt Dagda im Hintergrund auf die Trojaner- und Antivirendatenbank von ClamAV, dem bekannten Tool aus dem Mailserver-Kontext. Stirnrunzeln allerdings verursacht die Update-Policy von Dagda: Die letzte Version des Werkzeugs datiert auf Mitte 2021, seither hat sich im Git-Verzeichnis nichts mehr getan. Auch die letzte veröffentlichte Version fällt in diesen Zeitraum. Weil hinter Dagda keine große Firma steckt, liegt die Befürchtung nahe, dass die ursprünglichen Autoren möglicherweise das Interesse an ihrem Werk verloren haben.

Auf der anderen Seite stapeln sich im Git-Repo des Tools keine unbearbeiteten Problemanfragen. Dort finden sich lediglich ein paar Fälle offensichtlicher Fehlbenutzung, auf die allerdings jede Reaktion ausblieb. Für den Moment funktioniert Dagda gut, auch weil die Datenbanken für die Heuristik des Werkzeugs von anderen gepflegt werden.

Falco

Auch bei Falco (Abbildung 3) handelt es sich eher um ein Werkzeug nach dem Zuschnitt von Clair oder Dagda und weniger um eine umfassende Plattformlösung wie Anchore. Die grundlegenden Funktionen sind schnell erklärt: Die zu Falco [4] gehörenden Dienste laufen in eigenen Containern etwa innerhalb von Kubernetes und lassen sich dort über den K8s-Paketmanager Helm schnell ausrollen.

Abbildung 3: Falco untersucht keine bestehenden Container auf Abbilder, sondern klinkt sich in deren Netzwerkkommunikation ein und überprüft diese im Hinblick auf verschiedene Faktoren. Quelle: Falco

Zum Lieferumfang gehört wie heute üblich eine ReST-API, zur Steuerung dient ein externer Client. Unter der Haube unterscheidet Falco sich allerdings erheblich von der Konkurrenz: Es setzt auf der Netzwerkebene an und liest je nach Konfiguration auf Grundlage von eBPF den durchfließenden Datenverkehr von und zu Containern mit. Das bedeutet freilich auch, dass man eine Plattform zentral für die Verwendung von Falco vorbereiten muss, denn den entsprechenden Zugriff auf den gesamten Datenverkehr aller Container erhält man in Kubernetes nicht automatisch. Ist das Werkzeug aber einmal eingerichtet, steht der Sicherheitsüberwachung nichts mehr im Weg.

Sicherheitslücken in der Software von bestehenden Containern erkennt Falco anders als die Konkurrenz nicht durch Abgleich mit einer CVE-Datenbank. Stattdessen nimmt das Tool Anomalien im Datenverkehr wahr. Die Lösung beansprucht zudem für sich, besonders kommunikativ zu sein. Gemäß der Prämisse, dass eine Problemerkennung nichts hilft, wenn niemand die resultierenden Benachrichtigungen sieht, bietet Falco Anbindungen zu über 30 SIEM- und Kommunikationssystemen. Es lässt sich also nahtlos in die Mehrzahl der bestehenden Lösungen integrieren. Das freut nicht nur die Compliance-Abteilung, sondern auch den Admin, der in Sachen Benachrichtigung für Falco keine Sonderkonstrukte bauen muss.

Obendrein steht Falco unter einer freien Lizenz und lässt sich kostenlos nutzen. Damit eignet es sich ideal als Ergänzung zu einem Verwundbarkeitsscanner wie Clair oder Dagda und eingeschränkt als Komplement zu einem Werkzeug wie Anchore, das vergleichbare Funktionen teils anders implementiert.

Harbor

Aus einer gänzlich anderen Richtung nähert sich Harbor (Abbildung 4) dem Thema Container-Sicherheit. Es fungiert als Container-Registry mit Sicherheitschecks auf der Registry-Ebene. Falco [5] prüft also vor allem die Images, die in einer zentralen Registry liegen, statt diese Aufgabe den Admins und Entwicklern zu überlassen. Folglich spricht Harbor eher die Security- und Compliance-Abteilung in Unternehmen an, die den Beschäftigten in Sachen Sicherheit ein Rahmenwerk vorgeben wollen. Zudem beherrscht Harbor mehrere Möglichkeiten, um Abbilder zu signieren und Image-Signaturen zu validieren. Das wiederum geht in jene Richtung, die Anchore als Ende-zu-Ende-Sicherheit apostrophiert.

Abbildung 4: Harbor geht das Sicherheitsthema auf einer eigenen Ebene an und fungiert als Registry mit eingebauten Security-Features. Allerdings hat es viel eigene Infrastruktur im Schlepptau, die es zu betreiben und zu warten gilt. Quelle: Harbor

Dabei beherrscht Harbor verschiedene praktische Funktionen. So beschränkt sich das Werkzeug nicht auf die Abbilder eines Projekts, sondern ist mandantenfähig. Möchten Sie etwa unterschiedliche Clients im Unternehmen für den Zugriff auf die Registry mit unterschiedlichen Zugangsdaten ausstatten, können Sie das mit Harbor tun. Das trägt letztlich auch zu einem Audit-Trail bei, weil nachvollziehbar bleibt, welcher Client wann welches Abbild aus der Registry heruntergeladen hat. Die Kehrseite der Medaille: Die Installation gestaltet sich recht aufwendig, da Harbor selbst aus einigen Komponenten besteht und etliche weitere im Hintergrund benötigt, beispielsweise eine Datenbank. Anders als Clair oder Dagda vergrößert Harbor also den administrativen Aufwand auf der Ebene der Plattformverwaltung erheblich.

Einmal ausgerollt, leistet das Tool aber gute Dienste. Unter der Haube nutzt es Trivy, ein separates Tool für das Erkennen von Verwundbarkeiten in Container-Abbildern. Dabei schreibt es im Hintergrund fleißig mit und legt eine umfassende Dokumentation im Hinblick auf die ausgeführten Arbeitsschritte an. Harbor ist damit zwar kein Selbstläufer, aber eine frei nutzbare Open-Source-Software, deren Einsatz sich insbesondere in größeren Umgebungen lohnt.

Qualys und JFrog

Die letzten beiden Probanden im Test lassen sich zusammen abhandeln, denn sie folgen sehr ähnlichen Ansätzen und versprechen Anwendern und Administratoren in etwa dasselbe. Sowohl Qualys Container Security [6] als auch JFrog Xray [7] sind Plattformlösungen, die sich in bestehende Container integrieren und daran anbinden lassen. Der Funktionsumfang fällt recht ähnlich aus: Beide Produkte versprechen das Aufspüren von Verwundbarkeiten in Container-Abbildern, das Erstellen von kuratierten Katalogen mit bekanntermaßen sicheren Abbildern und – zum Teil – das Prüfen des durchfließenden Verkehrs.

Der Ansatz ist dabei typisch US-amerikanisch: Buzzwords, so weit das Auge reicht, etwa bezüglich des automatischen Erkennens von Problemen auf Basis von KI und Machine Learning. Immerhin gibt es eine übersichtliche GUI, die das Erstellen von Reports und von Übersichten der gefundenen Probleme ermöglicht und eine Live-Ansicht bietet. Qualys Container Security integriert sich dabei sogar noch in den Kontext von TotalCloud, einer kompletten Container-Plattform des Anbieters.

Es liegt auf der Hand, dass sich weder JFrog (Abbildung 5) noch Qualys nebenbei in bestehende Umgebungen integrieren lassen. Hier steht stattdessen der Gedanke im Fokus, sich eine schlüsselfertige Lösung ins Haus zu holen. Entsprechend lässt sich der gesamte Leistungsumfang an dieser Stelle nur unzureichend beschreiben. Ziehen Sie die Nutzung dieser Lösungen in Betracht, führt kein Weg daran vorbei, sich das Produkt vom Hersteller umfassend erklären und vorführen zu lassen. Selbst dann ist die Einführung keine schnelle Nummer, sondern eher ein größeres Projekt.

Abbildung 5: Die umfassenden Plattformlösungen JFrog Xray und Qualys Container Security kommen als Wunschlos-glücklich-Pakete daher und versprechen dem Administrator eine schnelle Lösung für seine Probleme. Quelle: JFrog

Sowohl JFrog als auch Qualys wollen Geld für ihre Lösung sehen. Das ist per se keineswegs verwerflich, doch ist eine entsprechende Investition im Kontext der Infrastruktur eines Unternehmens nur sinnvoll, wenn man die Werkzeuge danach auch nutzt und ihre Verwendung zentral vorschreibt. Suchen Sie also eher ein Werkzeug, um bestehende Plattformen abzusichern, sind Sie bei diesem umfassenden Ansatz vermutlich nicht so gut aufgehoben.

Fazit

Grob unterteilen sich die vorgestellten Lösungen in zwei Klassen. Auf der einen Seite stehen kleine Werkzeuge, die sich an bestehende Umgebungen anschließen oder darin integrieren lassen. Die andere Seite besetzen umfassende Plattformen, die das Thema Sicherheit quasi nebenbei mit abhandeln.

Sinnvoll erscheint die Kombination aus Clair oder Dagda mit Falco. Damit lassen sich sowohl bestehende Verwundbarkeiten in Abbildern identifizieren als auch laufende Angriffe. Mögen Sie es eher umfassend, sehen Sie sich am besten Anchore an, müssen dabei aber einen entsprechenden Aufwand für die Einführung und die fortlaufende Wartung der Plattform einkalkulieren. Ähnliches gilt für Harbor, das selbst einiges an Infrastruktur im Gepäck hat. Als Container-Registry mit Ende-zu-Ende-Sicherheit und diversen eigenen Compliance-Funktionen sticht es aber aus dem Testfeld heraus.

Sie sollten sich der Tatsache bewusst sein, dass die Sicherheit von Containern und der Dienste darin keine Frage einzelner Werkzeuge ist. Nur eine kluge Kombination aus Scannern und Überwachung führt hier zum Erfolg. Dafür eignen sich einige Werkzeuge aus dieser Übersicht. Das Ziel besteht aus Sicht des Administrators darin, jeden einzelnen Teil des Deployments von Containern und Diensten mit einem separaten Werkzeug oder einer Kombination daraus abzusichern.

Erfreulicherweise haben Sie dabei eine echte Wahl zwischen umfassenden kommerziellen Ansätzen, die als Wunschlos-glücklich-Paket daherkommen, und genuin quelloffenen Werkzeugen aus der Open-Source-Community, die operative Freiheit und Flexibilität bieten. Dagda, das einfachste Werkzeug zum Scannen, verursacht allerdings hinsichtlich seiner Aktualität und der Aktivität seiner Entwickler etwas Stirnrunzeln. In Form von Clair steht aber durchaus brauchbarer Ersatz zur Verfügung. (jcb/jlu)