Open-Source, plattformübergreifendes, Mehrzweck-Sicherheitsaudit-Tool
Hinweis: DevAudit verwendet die OSS Index-Datenbank, die eine gewisse Ratenbegrenzung aufweist. Falls Ihnen auffällt, dass Sie die Grenze erreichen, melden Sie bitte ein Issue. Authentifizierte Benutzer erhalten eine höhere Grenze, und wir arbeiten daran, die Authentifizierung in DevAudit bald zu implementieren. Die meisten nicht authentifizierten Benutzer werden die Grenze wahrscheinlich für viele Anwendungsfälle nicht bemerken. Sie tritt normalerweise nur bei deutlich größeren Projekten oder höheren Projektvolumina in Kraft.
Holen Sie sich die neueste Version von der Releases Seite.
DevAudit ist ein quelloffenes, plattformübergreifendes, vielseitiges Sicherheitsaudit-Tool, das sich an Entwickler und Teams richtet, die DevOps und DevSecOps einführen, und Sicherheitslücken auf mehreren Ebenen des Lösungsstacks erkennt. DevAudit bietet eine breite Palette von Audit-Funktionen, die Sicherheitspraktiken und die Implementierung von Sicherheitsaudits im Softwareentwicklungslebenszyklus automatisieren. DevAudit kann Ihre Betriebssystem- und Anwendungspaketabhängigkeiten, Anwendungs- und Anwendungsserverkonfigurationen sowie Anwendungscode auf potenzielle Schwachstellen scannen, basierend auf Daten, die von Anbietern wie OSS Index und Vulners aus einer Vielzahl von Quellen und Datenfeeds wie dem National Vulnerability Database (NVD) CVE-Datenfeed, dem Debian Security Advisories-Datenfeed, Drupal Security Advisories und vielen anderen aggregiert werden.
DevAudit hilft Entwicklern, mindestens 4 der OWASP Top 10 Risiken für die Webanwendungsentwicklung zu adressieren:
sowie Risiken, die von MITRE im CWE-Wörterbuch klassifiziert wurden, wie CWE-2 Environment und CWE-200 Information Disclosure
Mit fortschreitender Entwicklung und zunehmender Reife der Fähigkeiten wird DevAudit in der Lage sein, die anderen Risiken der OWASP Top 10 und CWE-Listen wie Injection und XSS zu adressieren. Angesichts des Fokus auf Web-, Cloud- und verteilte Multi-User-Anwendungen ist die Softwareentwicklung heute zunehmend komplex, wobei Sicherheitsprobleme und potenzielle Schwachstellen auf allen Ebenen des Stacks auftreten, auf die Entwickler angewiesen sind, um Anwendungen bereitzustellen. Das Ziel von DevAudit ist es, eine Plattform zur Automatisierung der Implementierung von Sicherheitsüberprüfungen und Best Practices auf allen Ebenen des Lösungsstacks zu bieten – von Bibliothekspaketabhängigkeiten über Anwendungs- und Serverkonfiguration bis hin zum Quellcode.
Plattformübergreifend mit ebenfalls verfügbarem Docker-Image. DevAudit läuft unter Windows und Linux, mit geplanter Unterstützung für *BSD, Mac und ARM Linux. Für den Betrieb von DevAudit ist lediglich eine aktuelle Version von .NET oder Mono erforderlich. Ein DevAudit Docker-Image kann auch von Docker Hub bezogen und ohne Installation von Mono ausgeführt werden.
CLI-Schnittstelle. DevAudit verfügt über eine CLI-Schnittstelle mit einer Option für nicht-interaktive Ausgabe und kann problemlos in CI-Build-Pipelines oder als Post-Build-Befehlszeilenaufgaben in Entwickler-IDEs integriert werden. Die Arbeit an der Integration der Kern-Audit-Bibliothek in IDE-GUIs hat bereits mit der Audit.Net Visual Studio-Erweiterung begonnen.
Kontinuierlich aktualisierte Schwachstellendaten. DevAudit verwendet Backend-Datenanbieter wie OSS Index und Vulners, die kontinuierlich aktualisierte Schwachstellendaten aus einem breiten Spektrum von Sicherheitsdatenfeeds und -quellen wie den NVD CVE-Feeds, Drupal Security Advisories usw. bereitstellen. Die Unterstützung für zusätzliche Schwachstellen- und Paketdatenanbieter wie vFeed und Libraries.io wird hinzugefügt.
Audit von Betriebssystem- und Entwicklungspaketabhängigkeiten. DevAudit auditiert Windows-Anwendungen und -Pakete, die über Windows MSI, Chocolatey und OneGet installiert wurden, sowie Debian-, Ubuntu- und CentOS-Linux-Pakete, die über Dpkg, RPM und YUM installiert wurden, auf Schwachstellen, die für bestimmte Versionen der Anwendungen und Pakete gemeldet wurden. Für Entwicklungspaketabhängigkeiten und -bibliotheken auditiert DevAudit NuGet v2-Abhängigkeiten für .NET, Yarn/NPM- und Bower-Abhängigkeiten für nodejs und Composer-Paketabhängigkeiten für PHP. Die Unterstützung für andere Paketmanager für verschiedene Sprachen wird regelmäßig erweitert.
Audit von Anwendungsserverkonfigurationen. DevAudit auditiert die Serverversion und die Serverkonfiguration für die Server OpenSSH sshd, Apache httpd, MySQL/MariaDB, PostgreSQL und Nginx, viele weitere folgen. Die Konfigurationsaudits basieren auf der Alpheus-Bibliothek und erfolgen mittels vollständiger syntaktischer Analyse der Serverkonfigurationsdateien. Die Regeln für die Serverkonfiguration sind in YAML-Textdateien gespeichert und können an die Bedürfnisse von Entwicklern angepasst werden. Die Unterstützung für viele weitere Server und Anwendungen sowie Analysetypen wie Datenbankaudits wird regelmäßig erweitert.
Audit von Anwendungskonfigurationen. DevAudit auditiert Microsoft ASP.NET-Anwendungen und erkennt Schwachstellen in der Anwendungskonfiguration. Die Regeln für die Anwendungskonfiguration sind in YAML-Textdateien gespeichert und können an die Bedürfnisse von Entwicklern angepasst werden. Das Audit von Anwendungskonfigurationen für Anwendungen wie Drupal, WordPress und DNN CMS ist in Vorbereitung.
Audit von Anwendungscode durch statische Analyse. DevAudit unterstützt derzeit die statische Analyse von .NET CIL-Bytecode. Analysatoren befinden sich in externen Skriptdateien und können basierend auf den Bedürfnissen des Entwicklers vollständig angepasst werden. Die Unterstützung für C#-Quellcodeanalyse über Roslyn, PHP7-Quellcode und viele weitere Sprachen sowie externe statische Code-Analyse-Tools ist in Vorbereitung.
Remote-Agentless-Auditing. DevAudit kann über SSH eine Verbindung zu entfernten Hosts herstellen, wobei in entfernten Umgebungen identische Audit-Funktionen wie in lokalen Umgebungen zur Verfügung stehen. Für das Auditieren entfernter Hosts ist lediglich ein gültiger SSH-Login erforderlich. DevAudit, das unter Windows läuft, kann über SSH eine Verbindung zu Linux-Hosts herstellen und diese auditieren. Unter Windows kann DevAudit auch über WinRM eine Verbindung zu anderen Windows-Maschinen herstellen und diese auditieren.
Agentless Docker-Container-Auditing. DevAudit kann laufende Docker-Container vom Docker-Host aus auditieren, wobei in Container-Umgebungen identische Funktionen wie in lokalen Umgebungen zur Verfügung stehen.
GitHub-Repository-Auditing. DevAudit kann direkt eine Verbindung zu einem auf GitHub gehosteten Projekt-Repository herstellen und Paketquellen- und Anwendungskonfigurationsaudits durchführen.
PowerShell-Unterstützung. DevAudit kann auch innerhalb der PowerShell-Systemverwaltungsumgebung als Cmdlets ausgeführt werden. Die Arbeit an der PowerShell-Unterstützung ist derzeit pausiert, wird aber in naher Zukunft mit Unterstützung für plattformübergreifende PowerShell sowohl unter Windows als auch Linux wieder aufgenommen.
DevAudit ist eine .NET 4.6-Anwendung. Für die lokale Installation auf Ihrem Rechner benötigen Sie entweder die Microsoft .NET Framework 4.6-Laufzeit unter Windows oder Mono 4.4+ unter Linux. .NET 4.6 sollte auf den meisten aktuellen Windows-Versionen bereits installiert sein; falls nicht, ist es als Windows-Funktion verfügbar, die entweder über die Systemsteuerung „Programme und Funktionen“ unter Consumer-Windows oder über die Option „Rollen und Features hinzufügen“ im Server-Manager unter Serverversionen von Windows aktiviert oder installiert werden kann. Für ältere Windows-Versionen ist das .NET 4.6-Installationsprogramm von Microsoft hier zu finden.
Unter Linux wird mindestens Mono 4.4 unterstützt. Obwohl DevAudit unter Mono 4 läuft (mit einem bekannten Problem), wird die Installation von Mono 5 empfohlen. Mono 5 bringt viele Verbesserungen für die Build- und Laufzeitkomponenten von Mono, die DevAudit zugutekommen.
Die vorhandenen Mono-Pakete, die von Ihrer Distribution bereitgestellt werden, sind wahrscheinlich noch nicht Mono 5, daher müssen Sie Mono-Pakete manuell installieren, um Mono 5 nutzen zu können. Installationsanweisungen für die aktuellsten Pakete des Mono-Projekts für mehrere wichtige Linux-Distributionen finden Sie hier. Es wird empfohlen, das Paket mono-devel zu installieren, da dies die Wahrscheinlichkeit fehlender Assemblys verringert.
Alternativ können Sie unter Linux das DevAudit Docker-Image verwenden, wenn Sie Mono nicht installieren möchten und bereits Docker auf Ihrem Rechner installiert haben.
DevAudit kann auf folgende Weise installiert werden:
Voraussetzungen: Mono 4.4+ (Mono 5 empfohlen) und das Paket mono-devel, das den Compiler und andere Werkzeuge zum Erstellen von Mono-Anwendungen bereitstellt. Ihre Distribution sollte Pakete für mindestens Mono Version 4.4 und höher haben, ansonsten finden Sie hier manuelle Installationsanweisungen für die aktuellsten Pakete des Mono-Projekts für mehrere wichtige Linux-Distributionen: hier
Klonen Sie das DevAudit-Repository von https://github.com/OSSIndex/DevAudit.git
Führen Sie das Skript build.sh im Stammverzeichnis von DevAudit aus. DevAudit sollte ohne Fehler kompilieren.
Führen Sie ./devaudit --help aus. Sie sollten die DevAudit-Version und den Hilfebildschirm sehen.
Beachten Sie, dass NuGet unter Linux gelegentlich mit Error: NameResolutionFailure beendet wird, was anscheinend ein vorübergehendes Problem beim Kontaktieren der Server ist, die die NuGet-Pakete enthalten. Führen Sie einfach ./build.sh erneut aus, bis der Build normal abgeschlossen wird.
Voraussetzungen: Sie müssen eines der folgenden haben:
Klonen Sie das DevAudit-Repository von https://github.com/OSSIndex/DevAudit.git
Führen Sie das Skript build.cmd im Stammverzeichnis von DevAudit aus. DevAudit sollte ohne Fehler kompilieren.
Führen Sie ./devaudit --help aus. Sie sollten die DevAudit-Version und den Hilfebildschirm sehen.
Voraussetzungen: Sie müssen Mono 4.4+ unter Linux oder .NET 4.6 unter Windows haben.
Laden Sie die neueste Release-Archivdatei für Windows oder Linux von der Projekt-Releases-Seite herunter. Entpacken Sie diese Datei in ein Verzeichnis.
Führen Sie aus dem Verzeichnis, in das Sie das Release-Archiv entpackt haben, unter Windows devaudit --help oder unter Linux ./devaudit --help aus. Sie sollten die Version und den Hilfebildschirm sehen.
(Optional) Fügen Sie das DevAudit-Installationsverzeichnis zu Ihrer PATH-Umgebungsvariable hinzu
Der MSI-Installer für ein Release befindet sich auf der Github-Releases-Seite.
DevAudit ist auch auf Chocolatey verfügbar.
choco install devaudit ein.Holen Sie sich das DevAudit-Image von Docker Hub: docker pull ossindex/devaudit. Das mit ossindex/devaudit:latest (das ist das Standard-Image, das heruntergeladen wird) getaggte Image wird aus dem aktuellsten Release erstellt, während ossindex/devaudit:unstable auf dem Master-Zweig des Quellcodes basiert und die neuesten Ergänzungen enthält, wenn auch mit weniger Tests.
Stellt eine logische Gruppe von Audit-Funktionen dar. DevAudit unterstützt derzeit die folgenden Audit-Ziele:
Stellt eine logische Umgebung dar, in der Audits gegen Audit-Ziele ausgeführt werden. Audit-Umgebungen abstrahieren die E/A und Befehlsausführungen, die für ein Audit erforderlich sind, und ermöglichen identische Funktionen gegen Audit-Ziele unabhängig vom physischen oder Netzwerk-Standort der Dateien und ausführbaren Dateien des Ziels. Derzeit werden folgende Umgebungen unterstützt:
Dies sind verschiedene Optionen, die für das Audit aktiviert werden können. Sie können Optionen angeben, die für das DevAudit-Programm gelten, z. B. den nicht-interaktiven Modus, sowie Optionen, die für das Ziel gelten, z. B. wenn Sie die Option AppDevMode für das Auditieren von ASP.NET-Anwendungen auf „true“ setzen, werden bestimmte Audit-Regeln nicht aktiviert.
Die CLI ist die primäre Schnittstelle zum DevAudit-Programm und eignet sich sowohl für die interaktive Nutzung als auch für die nicht-interaktive Nutzung in geplanten Aufgaben, Shell-Skripten, CI-Build-Pipelines und Post-Build-Aufgaben in Entwickler-IDEs. Die grundlegende DevAudit-CLI-Syntax lautet:
devaudit TARGET [ENVIRONMENT] | [OPTIONS]
wobei TARGET das Audit-Ziel angibt, ENVIRONMENT die Audit-Umgebung und OPTIONS die Optionen für das Audit-Ziel und die Umgebung. Es gibt zwei Möglichkeiten, Optionen anzugeben: Programmoptionen und allgemeine Audit-Optionen, die für mehr als ein Ziel gelten, können direkt auf der Befehlszeile als Parameter angegeben werden. Zielspezifische Optionen können mit der Option -o im Format -o OPTION1=WERT1,OPTION2=WERT2,.... angegeben werden, wobei Kommas die einzelnen Options-Schlüssel-Wert-Paare trennen.
Wenn Sie die Programmausgabe in eine Datei umleiten oder pipen, sollten Sie immer die Option -n --non-interactive verwenden, um interaktive Benutzeroberflächenfunktionen und Animationen zu deaktivieren.
Bei der Angabe von Dateipfaden gibt ein @-Präfix vor einem Pfad für DevAudit an, dass dieser Pfad relativ zum Stammverzeichnis des Audit-Ziels ist. Z. B. wenn Sie angeben:
-r c:\meinprojekt -b @bin\Debug\app2.exe
Betrachtet DevAudit den Pfad zur Binärdatei als c:\meinprojekt\bin\Debug\app2.exe.
msi Führen Sie ein Paketaudit der Windows Installer MSI-Paketquelle auf Windows-Rechnern durch.
npm Führen Sie ein Paketaudit der NPM package.json durch.
choco Führen Sie ein Paketaudit von Paketen durch, die mit dem Choco-Paketmanager installiert wurden.
oneget Führen Sie ein Paketaudit der systemweiten OneGet-Paketquelle unter Windows durch.
nuget Führen Sie ein Paketaudit einer NuGet v2-Paketquelle durch. Sie müssen den Speicherort der NuGet-Datei packages.config, die Sie auditieren möchten, mit der Option -f oder --file angeben, andernfalls wird das aktuelle Verzeichnis nach dieser Datei durchsucht.
bower Führen Sie ein Paketaudit einer Bower-Paketquelle durch. Sie müssen den Speicherort der Bower-Datei packages.json, die Sie auditieren möchten, mit der Option -f oder --file angeben, andernfalls wird das aktuelle Verzeichnis nach dieser Datei durchsucht.- composer Führen Sie ein Paket-Audit einer Composer-Paketquelle durch. Sie müssen den Speicherort der composer.json-Datei mit der Option -f oder --file angeben, andernfalls wird das aktuelle Verzeichnis nach dieser Datei durchsucht.
dpkg Führen Sie ein Paket-Audit der System-Dpkg-Paketquelle auf Debian Linux und Derivaten durch.
rpm Führen Sie ein Paket-Audit der System-RPM-Paketquelle auf RedHat Linux und Derivaten durch.
yum Führen Sie ein Paket-Audit der System-Yum-Paketquelle auf RedHat Linux und Derivaten durch.
Für jede Paketquelle können die folgenden allgemeinen Audit-Optionen verwendet werden:
-f --file Geben Sie den Speicherort der Konfigurationsdatei des Paketmanagers an, falls erforderlich. Die Paketquellen NuGet, Bower und Composer erfordern diese Option.
--list-packages Nur die Pakete auflisten, die von DevAudit in der gescannten Paketquelle gefunden wurden.
--list-artifacts Nur die Artefakte auflisten, die auf OSS Index für die von DevAudit gescannten Pakete gefunden wurden.
Paketquellen mit dem Tag [Experimental] sind nur im Master-Branch des Quellcodes verfügbar und haben möglicherweise eingeschränkte OSS-Index-Unterstützung im Backend. Sie können jedoch jederzeit die gescannten Pakete und die auf OSS Index verfügbaren Artefakte mit den Optionen list-packages und list-artifacts auflisten.
aspnet Führen Sie ein Anwendungs-Audit einer ASP.NET-Anwendung durch. Die relevanten Optionen sind:
-r --root-directory Geben Sie das Stammverzeichnis der Anwendung an. Dies ist das oberste Anwendungsverzeichnis, das Dateien wie Global.asax und Web.config enthält.-b --application-binary Geben Sie die Anwendungsbinärdatei an. Dies ist die .NET-Assembly, die den .NET-Bytecode der Anwendung enthält. Diese Datei ist normalerweise eine .DLL und befindet sich im Unterordner bin des Stammverzeichnisses der ASP.NET-Anwendung.--config-file oder -o AppConfig=configuration-file Gibt die ASP.NET-Anwendungskonfigurationsdatei an. Diese Datei heißt normalerweise Web.config und befindet sich im Stammverzeichnis der Anwendung. Sie können den Standardwert @Web.config mit dieser Option überschreiben.-o AppDevMode=enabled Gibt an, dass der Anwendungsentwicklungsmodus für das Audit aktiviert sein soll. Dieser Modus kann verwendet werden, wenn eine Anwendung auditiert wird, die sich in der Entwicklung befindet. Bestimmte Konfigurationsregeln, die für den AppDevMode als deaktiviert markiert sind (z. B. Ausführen der Anwendung im ASP.NET-Debug-Modus), werden während des Audits nicht aktiviert.netfx Führen Sie ein Anwendungs-Audit einer .NET-Anwendung durch. Die relevanten Optionen sind:
-r --root-directory Geben Sie das Stammverzeichnis der Anwendung an. Dies ist das oberste Anwendungsverzeichnis, das Dateien wie App.config enthält.-b --application-binary Geben Sie die Anwendungsbinärdatei an. Dies ist die .NET-Assembly, die den .NET-Bytecode der Anwendung enthält. Diese Datei ist normalerweise eine .DLL und befindet sich im Unterordner bin des Stammverzeichnisses der ASP.NET-Anwendung.--config-file oder -o AppConfig=configuration-file Gibt die .NET-Anwendungskonfigurationsdatei an. Diese Datei heißt normalerweise App.config und befindet sich im Stammverzeichnis der Anwendung. Sie können den Standardwert @App.config mit dieser Option überschreiben.-o GendarmeRules=RuleLibrary Gibt an, dass der Gendarme-Statikanalysator für das Audit mit Regeln aus der angegebenen Regelbibliothek aktiviert werden soll. Zum Beispiel:
devaudit netfx -r /home/allisterb/vbot-debian/vbot.core -b @bin/Debug/vbot.core.dll --skip-packages-audit -o GendarmeRules=Gendarme.Rules.Naming
führt den Gendarme-Statikanalysator auf der Assembly vbot.core.dll unter Verwendung von Regeln aus der Bibliothek Gendarme.Rules.Naming aus. Die vollständige Liste der Regelbibliotheken (entnommen aus dem Gendarme-Wiki):drupal7 Führen Sie ein Anwendungs-Audit einer Drupal-7-Anwendung durch.
-r --root-directory Geben Sie das Stammverzeichnis der Anwendung an. Dies ist das oberste Verzeichnis Ihrer Drupal-7-Installation.drupal8 Führen Sie ein Anwendungs-Audit einer Drupal-8-Anwendung durch.
-r --root-directory Geben Sie das Stammverzeichnis der Anwendung an. Dies ist das oberste Verzeichnis Ihrer Drupal-8-Installation.Alle Anwendungen unterstützen außerdem die folgenden gemeinsamen Optionen zum Auditieren der Anwendungsmodule oder -Plugins:
--list-packages Nur die von DevAudit gescannten Anwendungs-Plugins oder -Module auflisten.
--list-artifacts Nur die auf OSS Index gefundenen Artefakte für gescannte Anwendungs-Plugins und -Module auflisten.
--skip-packages-audit Nur ein Audit der Anwendungskonfiguration oder -Code-Analyse durchführen und das Paket-Audit überspringen.
sshd Führen Sie ein Anwendungsserver-Audit eines OpenSSH-sshd-kompatiblen Servers durch.
httpd Führen Sie ein Anwendungsserver-Audit eines Apache-httpd-kompatiblen Servers durch.
mysql Führen Sie ein Anwendungsserver-Audit eines MySQL-kompatiblen Servers (wie MariaDB oder Oracle MySQL) durch.
nginx Führen Sie ein Anwendungsserver-Audit eines Nginx-Servers durch.
pgsql Führen Sie ein Anwendungsserver-Audit eines PostgreSQL-Servers durch.
Dies ist ein Beispiel für eine Befehlszeile für ein Anwendungsserver-Audit:
./devaudit httpd -i httpd-2.2 -r /usr/local/apache2/ --config-file @conf/httpd.conf -b @bin/httpd
welches einen Apache-Httpd-Server auditiert, der auf einem Docker-Container mit dem Namen httpd-2.2 läuft.
Die folgenden Audit-Optionen sind für alle Anwendungsserver gemeinsam:
-r --root-directory Gibt das Stammverzeichnis des Servers an. Dies ist die oberste Ebene Ihres Server-Dateisystems und standardmäßig /, es sei denn, Sie möchten ein anderes Server-Stammverzeichnis.--config-file Gibt die Server-Konfigurationsdatei an. Z. B. im obigen Audit befindet sich die Apache-Konfigurationsdatei unter /usr/local/apache2/conf/httpd.conf. Wenn Sie die Konfigurationsdatei nicht angeben, versucht DevAudit, die Konfigurationsdatei für den ausgewählten Server automatisch zu erkennen.-b --application-binary Gibt die Server-Binärdatei an. Z. B. im obigen Audit befindet sich die Apache-Binärdatei unter /usr/local/apache2/bin/httpd. Wenn Sie den Binärpfad nicht angeben, versucht DevAudit, die Server-Binärdatei für den ausgewählten Server automatisch zu erkennen.Anwendungsserver unterstützen außerdem die folgenden gemeinsamen Optionen zum Auditieren der Server-Module oder -Plugins:
--list-packages Nur die von DevAudit gescannten Anwendungs-Plugins oder -Module auflisten.
--list-artifacts Nur die auf OSS Index gefundenen Artefakte für gescannte Anwendungs-Plugins und -Module auflisten.
--skip-packages-audit Nur ein Server-Konfigurationsaudit durchführen und das Paket-Audit überspringen.
Derzeit werden 5 Audit-Umgebungen unterstützt: lokal, entfernte Hosts über SSH, entfernte Hosts über WinRM, Docker-Container und GitHub. Lokale Umgebungen werden standardmäßig verwendet, wenn keine anderen Umgebungsoptionen angegeben werden.
Die SSH-Umgebung ermöglicht Audits auf jedem entfernten Host, der über SSH zugänglich ist, ohne dass DevAudit auf dem entfernten Host installiert sein muss. SSH-Umgebungen sind plattformübergreifend: Sie können von einem Windows-Rechner, auf dem DevAudit läuft, eine Verbindung zu einem Linux-Remote-Host herstellen. Eine SSH-Umgebung wird durch die folgenden Optionen erstellt:-s SERVER [--ssh-port PORT] -u USER [-k KEYFILE] [-p | --password-text PASSWORD]
-s SERVER Gibt den entfernten Host oder die IP an, mit der über SSH verbunden werden soll.
-u USER Gibt den Benutzer an, mit dem Sie sich auf dem Server anmelden möchten.
--ssh-port PORT Gibt den Port auf dem entfernten Host an, mit dem verbunden werden soll. Der Standardwert ist 22.
-k KEYFILE Gibt die OpenSSH-kompatible private Schlüsseldatei an, die zur Verbindung mit dem entfernten Server verwendet werden soll. Derzeit werden nur RSA- oder DSA-Schlüssel in Dateien im PEM-Format unterstützt.
-p Stellt eine Eingabeaufforderung mit deaktiviertem lokalem Echo für die interaktive Eingabe des Server-Passworts oder der Passphrase der Schlüsseldatei bereit.
--password-text PASSWORD Geben Sie das Benutzerpasswort oder die Passphrase der Schlüsseldatei als Klartext in der Befehlszeile an. Beachten Sie, dass Sie unter Linux bei Passwörtern mit Sonderzeichen den Text in der Befehlszeile mit einfachen Anführungszeichen wie 'MyPa<ss' umschließen sollten, um zu verhindern, dass die Shell die Sonderzeichen interpretiert.
Die WinRM-Umgebung ermöglicht Audits auf jedem entfernten Windows-Host, der über WinRM zugänglich ist, ohne dass DevAudit auf dem entfernten Host installiert sein muss. WinRM-Umgebungen sind derzeit nur auf Windows-Rechnern verfügbar, auf denen DevAudit läuft. Eine WinRM-Umgebung wird durch die folgenden Optionen erstellt:-w IP -u USER [-p | --password-text PASSWORD]
-w IP Gibt die entfernte IP an, mit der über WinRM verbunden werden soll.
-u USER Gibt den Benutzer an, mit dem Sie sich auf dem Server anmelden möchten.
-p Stellt eine Eingabeaufforderung mit deaktiviertem lokalem Echo für die interaktive Eingabe des Server-Passworts oder der Passphrase der Schlüsseldatei bereit.
--password-text PASSWORD Geben Sie das Server-Passwort oder die Passphrase der Schlüsseldatei als Klartext in der Befehlszeile an.
Dieser Abschnitt behandelt, wie Docker-Images mit DevAudit auditiert werden, das auf dem lokalen Rechner installiert ist. Informationen zur Ausführung von DevAudit als containerisierte Docker-App finden Sie im folgenden Abschnitt zur Docker-Nutzung.
Eine Docker-Audit-Umgebung wird durch die folgende Option angegeben: -i CONTAINER_NAME | -i CONTAINER_ID
CONTAINER_(NAME|ID) Gibt den Namen oder die ID eines laufenden Docker-Containers an, mit dem verbunden werden soll. Der Container muss bereits laufen, da DevAudit nicht weiß, wie der Container mit dem von Ihnen benötigten Namen oder Zustand gestartet werden kann.
Die GitHub-Audit-Umgebung ermöglicht Audits direkt auf einem GitHub-Projekt-Repository. Eine GitHub-Umgebung wird mit der Option -g erstellt: -g "Owner=OWNER,Name=NAME,Branch=BRANCH"
OWNER Gibt den Besitzer des Projekts an
NAME Gibt den Namen des Projekts an
PATH Gibt den Branch des Projekts an, mit dem verbunden werden soll
Sie können die Optionen -r, --config-file und -f wie gewohnt verwenden, um die Pfade zu Dateisystem-Dateien und -Verzeichnissen anzugeben, die für das Audit erforderlich sind. Z. B. der folgende Befehl:
devaudit aspnet -g "Owner=Dnnsoftware,Name=Dnn.Platforn,Branch=Release/9.0.2" -r /Website --config-file @web.config
führt ein ASP.NET-Audit in diesem Repository https://github.com/dnnsoftware/Dnn.Platform/ durch, wobei der Quellordner /Website als Stammverzeichnis und die Datei web.config als ASP.NET-Konfigurationsdatei verwendet wird. Beachten Sie, dass Dateinamen in den meisten Umgebungen zwischen Groß- und Kleinschreibung unterscheiden.
-n --non-interactive Führen Sie DevAudit im nicht-interaktiven Modus aus, wobei alle interaktiven Funktionen und Animationen der CLI deaktiviert sind. Dieser Modus ist beispielsweise erforderlich, um DevAudit in Shell-Skripten auszuführen, da es sonst zu Fehlern kommt, wenn DevAudit versucht, interaktive Konsolenfunktionen zu verwenden.
-d --debug Führen Sie DevAudit im Debug-Modus aus. Dadurch werden verschiedene Informations- und Diagnosemeldungen ausgegeben. Dieser Modus wird zur Fehlerbehebung bei DevAudit-Fehlern und -Bugs verwendet.
DevAudit wird auch als Docker-Container-App ausgeliefert, sodass Linux-Benutzer DevAudit ausführen können, ohne Mono installieren und aus dem Quellcode erstellen zu müssen. So ziehen Sie das DevAudit-Docker-Image von Docker Hub:
docker pull ossindex/devaudit[:label]
Die aktuellen Images sind etwa 131 MB komprimiert. Standardmäßig wird das mit latest gekennzeichnete Image gezogen, das die aktuellste Version des Programms ist. Es ist auch ein unstable-Image verfügbar, das den Master-Branch des Quellcodes verfolgt. So führen Sie DevAudit als Container-App aus:
docker run -i -t ossindex/devaudit TARGET [ENVIRONMENT] | [OPTIONS]
Die Docker-Optionen -i und -t sind erforderlich, um DevAudit interaktiv auszuführen. Wenn Sie diese Optionen nicht angeben, müssen Sie DevAudit im nicht-interaktiven Modus mit der DevAudit-Option -n ausführen.
Sie müssen alle Verzeichnisse auf dem Docker-Host-Rechner, auf die DevAudit zugreifen muss, auf dem DevAudit-Docker-Container mit der Docker-Option -v einbinden. Wenn Sie Ihr lokales Stammverzeichnis unter einem Mount-Punkt namens /hostroot auf dem Docker-Image einhängen, kann DevAudit auf Dateien und Verzeichnisse auf Ihrem lokalen Rechner mit denselben lokalen Pfaden zugreifen. Zum Beispiel:
docker run -i -t -v /:/hostroot:ro ossindex/devaudit netfx -r /home/allisterb/vbot-debian/vbot.core
ermöglicht es dem DevAudit-Docker-Container, das lokale Verzeichnis /home/allisterb/vbot-debian/vbot.core zu auditieren. Sie müssen Ihr lokales Stammverzeichnis auf diese Weise einhängen, um andere Docker-Container vom DevAudit-Container aus zu auditieren, z. B.
docker run -i -t -v /:/hostroot:ro ossindex/devaudit mysql -i myapp1 -r / --config-file /etc/my.cnf --skip-packages-audit
führt ein MySQL-Audit auf einem Docker-Container namens myapp1 vom ossindex/devaudit-Container aus durch.
Wenn Sie nicht Ihr gesamtes Stammverzeichnis einhängen müssen, können Sie nur das für das Audit benötigte Verzeichnis einhängen. Zum Beispiel:
docker run -i -t -v /home/allisterb/vbot-debian/vbot.core:/vbot:ro ossindex/devaudit netfx -r /vbot -b @bin/Debug/vbot.core.dll
hängt das Verzeichnis /home/allisterb/vbot-debian/vbot.core schreibgeschützt als /vbot auf dem DevAudit-Container ein, sodass DevAudit es als Audit-Stammverzeichnis für ein netfx-Anwendungsaudit unter /vbot verwenden kann.
Wenn Sie private Schlüsseldateien auf dem lokalen Docker-Host für ein Audit über SSH verwenden möchten, können Sie Ihr Verzeichnis, das die benötigte Schlüsseldatei enthält, einhängen und DevAudit anweisen, diesen Dateipfad zu verwenden, z. B.
docker -i -t -v /home/allisterb/.ssh:/ssh:ro run ossindex/devaudit dpkg -s localhost -u allisterb -p -k /ssh/mykey.key
hängt das Verzeichnis mit den Schlüsseldateien unter /ssh ein und ermöglicht dem DevAudit-Container deren Verwendung.
Beachten Sie, dass es dem Docker-Container derzeit nicht möglich ist, Betriebssystem-Paketquellen wie dpkg oder rpm oder Anwendungsserver wie OpenSSH sshd auf dem lokalen Docker-Host zu auditieren, ohne Ihr lokales Stammverzeichnis wie oben beschrieben unter /hostroot einzuhängen. DevAudit muss vom Docker-Container aus in Ihr lokales Stammverzeichnis chrooten, wenn es ausführbare Dateien wie dpkg oder Server-Binärdateien wie sshd und httpd ausführt. Sie müssen Ihr lokales Stammverzeichnis auch wie oben beschrieben einhängen, um andere Docker-Container vom DevAudit-Container aus zu auditieren, da DevAudit auch in Ihr lokales Stammverzeichnis chrooten muss, um lokale Docker-Befehle zur Kommunikation mit Ihren anderen Containern auszuführen.
Für Audits über SSH vom DevAudit-Container aus ist es nicht erforderlich, das lokale Stammverzeichnis unter /hostroot einzuhängen.
Wenn Sie einen Fehler oder ein anderes Problem mit DevAudit feststellen, können Sie einige Dinge aktivieren, um uns bei der Lösung zu helfen:
-n --non-interactive verwenden, wenn Sie die Programmausgabe in eine Datei umleiten, da es sonst zu einem Absturz kommt. Dieses Verhalten kann in Zukunft geändert werden, um den nicht-interaktiven Modus zum Standard zu machen.