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

Update Toolauswahl

Tobias Wieck 2021-02-06 11:07:36 +00:00
parent a4be00bbbf
commit 0ce7a52778
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Toolauswahl.md

@ -34,7 +34,9 @@ otseca --ignore-failed --tasks system,kernel,permissions,services,network,distro
```
### JShielder
Ä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.
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.
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 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 eher für größere Maschinen oder Server geeignet, auch weil es das System kontinuierlich scannt.