Update Toolauswahl
parent
b38e45395c
commit
7b23f6239a
@ -1,11 +1,17 @@
|
|||||||
## Verwendete Tools
|
## 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 ist ein weitverbreiteter Vulnerability Scanner, der auch sehr aktuell gehalten wird. Für ihn sprechen knapp 8000 Sterne auf GitHub, viele Contributer und das Alter des Programms bei hoher Aktualität.
|
Lynis ist ein weitverbreiteter Vulnerability Scanner, der auch sehr aktuell gehalten wird. Für ihn sprechen knapp 8000 Sterne auf GitHub, viele Contributer und das Alter des Programms bei hoher Aktualität. Deshalb war uns schnell klar, dass wir auf jeden Fall 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.
|
||||||
|
Mit Testssl.sh haben wir die Ports angeschaut. Welche sind offen und sind steht eine Verschlüsselung dahinter. Es 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.
|
||||||
|
Um ein kleineres Tool auszuprobieren haben wir uns noch für otseca entschieden. Es ist nicht so bekannt und der letzte Commit liegt schon etwas in der Vergangenheit. Dennoch macht es einen soliden Eindruck mit vielen Features.
|
||||||
|
Ähnliches dachten wir uns auch bei dem JShielder. Der ist nochmal ne Spur älter und hat ungefähr gleich viele Sterne auf GitHub. Außerdem soll er laut Beschreibung nahezu alle Systembereiche abdecken. Das wollten wir auf jeden Fall überprüfen. 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.
|
||||||
|
|
||||||
### Vuls
|
### Vuls
|
||||||
|
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 der letzten Jahrzehnte herunter. Bei 18 virtuellen Maschinen dauert das viel zu lange und macht den ganzen Prozess träge. Deshalb ist Vuls für größere Maschinen oder Server geeignet, auch weil es das System kontinuierlich scannt.
|
||||||
|
|
||||||
## Prozess
|
## Prozess
|
||||||
|
In der Liste unten sind 32 Tools aufgeführt, die wir uns alle angeschaut haben. Nachdem wir definiert haben nach welchen Kriterien wir uns die Tools anschauen, haben wir uns die Tools aufgeteilt. Dabei haben wir auf die Akualität (letzter Commit in GitHub), Beliebtheit (GitHub Stars) und die Beschreibung geachtet. Punlte 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 ddann die Entscheidungen getroffen welche wir auswählen.
|
||||||
|
|
||||||
## Alle Tools
|
## Alle Tools
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user