hft-informatik/it-security-2-deep-thought
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update Toolauswahl

Marcel Schwarz 2021-02-06 21:54:36 +00:00
parent 66e4e61c7b
commit af3b9f272c
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
Toolauswahl.md

@ -1,12 +1,12 @@
## Verwendete Tools
Letztendlich haben wir die drei Scanner Lynis, Testssl.sh und otseca verwendet, sowie den JShielder. Alle angeschauten Tools stehen Open Source zur Verfügung.
Letztendlich haben wir die drei Scanner Lynis, Testssl.sh und Otseca verwendet, sowie den JShielder. Alle angeschauten Tools stehen Open Source zur Verfügung.
### Lynis
Lynis ist ein weitverbreiteter Vulnerability Scanner, der auch sehr aktuell gehalten wird. 8000 Sterne auf GitHub, viele Contributer und das Alter des Programms bei hoher Aktualität sind Argumente, die für die Verwendung von Lynis sprechen. Deshalb war uns schnell klar, dass wir Lynis verwenden wollen.
Das generierte Ergebnis betrachtet umfangreiche Gebiete des Systems und berechnet einen Hardening-Index. Dieser zeigt auf einer Skala von 0 bis 100 wie sicher Lynis das System findet. Außerdem werden gefundene Warnungen und Vorschläge angezeigt mit direkter Issue-Nummer inklusive Anleitung zur Behebung des Problems.
Das generierte Ergebnis betrachtet umfangreiche Gebiete des Systems und berechnet einen Hardening-Index. Dieser zeigt auf einer Skala von 0 bis 100, wie sicher Lynis das System einschätzt. Außerdem werden gefundene Warnungen und Vorschläge angezeigt mit direkter Issue-Nummer, diese beinhaltet zudem Anleitungen zur Behebung des Problems.
Um Lynis zu starten, genügt es einen einzigen Befehl einzugeben.
Um Lynis zu starten, genügt es, einen einzigen Befehl einzugeben.
```shell
./lynis audit system
```
@ -14,9 +14,9 @@ Um Lynis zu starten, genügt es einen einzigen Befehl einzugeben.
*Ausschnitt des Lynis-Outputs*
### Testssl.sh
Mit Testssl.sh haben wir die Ports unserer VM unter die Lupe genommen. Welche sind offen und steht eine Verschlüsselung dahinter. Testssl.sh ist, wie Lynis, sehr beliebt und aktuell. Da es für das Scannen von Ports ausgelegt ist, kann man sich sicher sein, dass diese Aufgabe auch zuverlässig erledigt wird.
Mit Testssl.sh haben wir die Ports unserer VM überprüft. Welche sind offen und welche sind zusätzlich verschlüsselt? Testssl.sh ist, wie Lynis, sehr beliebt und aktuell. Da es für das Scannen von Ports ausgelegt ist, kann man sich sicher sein, dass diese Aufgabe auch zuverlässig erledigt wird.
Beim Starten von Testssl.sh können verschiedene Parameter mitgegeben werden. Beispielsweise wie das Log-File abgespeichert werden soll, welche Timeouts gesetzt werden und am Schluss welcher Port überprüft werden soll.
Beim Starten von Testssl.sh können verschiedene Parameter mitgegeben werden. Beispielsweise, wie das Log-File abgespeichert werden soll, welche Timeouts gesetzt werden und am Schluss welcher Port überprüft werden soll.
```shell
./testssl.sh --logfile "../outputs/testssl-$1.log" --append --connect-timeout 10 --openssl-timeout 10 -t ftp localhost:21
```
@ -25,25 +25,25 @@ Im Output werden die gescannten Ports aufgelistet. Ist der Port nicht geöffnet,
![image](uploads/771105cf9a7da646aa5f51e75fcf836a/image.png)
*Ausschnitt des Testssl.sh-Outputs*
### otseca
Um ein kleineres Tool auszuprobieren haben wir uns für otseca entschieden. Es ist weniger bekannt und der letzte Commit liegt schon etwas in der Vergangenheit. Dennoch macht es einen soliden Eindruck mit vielen Features.
### Otseca
Um ein kleineres Tool auszuprobieren, haben wir uns für Otseca entschieden. Es ist weniger bekannt und der letzte Commit liegt schon etwas in der Vergangenheit. Dennoch macht es einen soliden Eindruck mit vielen Features.
Startet man otseca, gibt es die Möglichkeit die verschiedenen Aspekte anzugeben, die getestet werden sollen.
Startet man Otseca, gibt es die Möglichkeit die verschiedenen Aspekte anzugeben, die getestet werden sollen.
```shell
otseca --ignore-failed --tasks system,kernel,permissions,services,network,distro,external
Otseca --ignore-failed --tasks system,kernel,permissions,services,network,distro,external
```
Im Gegensatz zu den anderen Tools erstellt otseca HTML-Seiten zu jedem angegebenen Aspekt. Also in unserem Fall: System, Kernel, Permissions, Services, Network, Distribution und External. Auf Unterseiten beinhalten nach einer kurzen Erklärung eine Auflistung der durchgeführten Tests. Je nachdem wie otseca die Ergebnisse sicherheitstechnisch einschätzt, wird der Hintergrund eingefärbt. Da die einzelnen Kommandos alleine recht wenig aussagen, muss recherchiert werden was kontrolliert wurde und warum die Farbe entsprechend ist.
Im Gegensatz zu den anderen Tools erstellt Otseca HTML-Seiten zu jedem angegebenen Aspekt. Also in unserem Fall: System, Kernel, Permissions, Services, Network, Distribution und External. Auf Unterseiten steht, nach einer kurzen Erklärung des Moduls, eine Auflistung der durchgeführten Tests. Je nachdem wie Otseca die Ergebnisse sicherheitstechnisch einschätzt, wird der Hintergrund eingefärbt. Da die einzelnen Kommandos alleine recht wenig aussagen, muss recherchiert werden, was kontrolliert wurde und warum die Farbe entsprechend gewählt wurde.
![image](uploads/4f6ecf2e71b7a85623b813daea4f7b81/image.png)
*Ausschnitt des otseca-Outputs*
*Ausschnitt des Otseca-Outputs*
### JShielder
Der Jashielder hat ungefähr gleich viele Sterne auf GitHub wie otseca. Allerdings liegt hier der letzte Commit im August 2019 (stand 6.2.21). Außerdem soll er laut Beschreibung nahezu alle Systembereiche abdecken. Aus diesen Gründen entschieden wir uns den JShielder zutesten.
Der Jashielder hat ungefähr gleich viele Sterne auf GitHub wie Otseca. Allerdings liegt hier der letzte Commit im August 2019 (stand 6.2.21). Außerdem soll er laut Beschreibung nahezu alle Systembereiche abdecken. Aus diesen Gründen entschieden wir uns den JShielder zu testen.
Beim ersten Ausführen des JShielders bemerkten wir, dass direkt Änderungen am System vorgenommen wurden. Dabei wurde nicht gefragt, ob diese Option überhaupt ausgeführt werden darf. Somit hat der Anwender bei der automatischen Reparatur keinen Einfluss und Information darüber was passiert. Deshalb kam es dazu, dass nach dem erforderten Neustart, wir uns nicht mehr auf die VM verbinden konnten. Wie sich später rausstellte lag das an eingerichtetem Portknocking und dem setzen eines Bootloader-Passwortes. Glücklicherweise bietet der JShielder jedoch die Möglichkeit nur spezielle Verbesserungen auszuführen. So konnten wir nur diese Ausführen, die uns nicht aus unserer VM ausschlossen.
Beim ersten Ausführen des JShielders bemerkten wir, dass direkt Änderungen am System vorgenommen wurden. Dabei wurde nicht gefragt, ob diese Option überhaupt ausgeführt werden darf. Somit hat der Anwender bei der automatischen Reparatur keinen Einfluss und Information darüber, was passiert. Deshalb kam es dazu, dass nach dem erforderten Neustart, wir uns nicht mehr auf die VM verbinden konnten. Wie sich später zeigte, lag das an eingerichtetem Portknocking und dem Setzen eines Bootloader-Passwortes. Glücklicherweise bietet der JShielder jedoch die Möglichkeit, nur spezielle Verbesserungen auszuführen. So konnten wir nur diese ausführen, die uns nicht aus unserer VM ausschlossen.
Der JShielder ist ein Komandozeilenprogramm, dem beim Aufruf keine Parameter mitgegeben werden können. Dadurch konnte wenig automatisiert werden und die 14 Optionen mussten händisch ausgewählt werden. Diese sind: 3, 8, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 30 und 31.
![JShielderChooseOption](uploads/d8e44766471c3d590e07c1fba5464822/JShielderChooseOption.png)
![JShielderChooseOption](uploads/d8e44766471c3d590e07c1fba5464822/JShielderChooseOption.png)
*JShielder Optionen*
Log-Files und anderer verwertbarer Output wird nicht generiert.
@ -52,11 +52,11 @@ Log-Files und anderer verwertbarer Output wird nicht generiert.
Vuls gehörte ursprünglich auch zu den ausgewählten Tools, bis wir es zum ersten Mal ausgeführt hatten. Denn Vuls lädt bei jeder Installation zwei bis drei Gigabyte CVEs (Common Vulnerabilities and Exposures) der letzten Jahrzehnte herunter. Bei 18 virtuellen Maschinen dauert das viel zu lange und macht den ganzen Prozess träge. Deshalb ist Vuls eher für größere Maschinen oder Server geeignet, auch weil es das System kontinuierlich scannt.
### Archery
Archery war auch ein Tool, das in der näheren Auswahl stand. Fiel jedoch auch aus der Auswahl heraus, da das Werkzeug lediglich eine Oberfläche bietet für verschiedene Scanner.
Archery war auch ein Tool, das in der näheren Auswahl stand. Fiel jedoch auch aus der Auswahl heraus, da das Werkzeug lediglich eine Oberfläche bietet für die zusammenfassung verschiedener anderer Scanner.
## Prozess
In der Liste unten sind 32 Tools aufgeführt, die wir uns alle angeschaut haben. Nachdem wir definiert hatten nach welchen Kriterien wir uns die Tools anschauen, haben wir uns die Tools aufgeteilt. Dabei haben wir auf die Aktualität (letzter Commit in GitHub), Beliebtheit (GitHub Stars) und die Beschreibung geachtet. Punkte wie: Welche Features werden angegeben? Wie ist das Erscheinungsbild? Wie lässt sich das Programm ausführen? spielten dabei eine Rolle für uns.
Die Ergebnisse der Recherchen wurden in einer gemeinsamen Tabelle zusammengetragen. Anhand derer haben wir dann die Entscheidungen getroffen welche wir auswählen.
In der Liste unten sind 32 Tools aufgeführt, die wir uns alle angeschaut haben. Nachdem wir definiert hatten, nach welchen Kriterien wir uns die Tools anschauen, haben wir uns die Tools aufgeteilt. Dabei haben wir auf die Aktualität (letzter Commit in GitHub), Beliebtheit (GitHub Stars) und die Beschreibung geachtet. Punkte wie: "Welche Features werden angegeben?", "Wie ist das Erscheinungsbild?", "Wie lässt sich das Programm ausführen?" spielten dabei eine Rolle für uns.
Die Ergebnisse der Recherchen wurden in einer gemeinsamen Tabelle zusammengetragen. Anhand derer haben wir dann die Entscheidungen getroffen, welche wir auswählen.
## Alle Tools