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

Update Unsere Idee

Marcel Schwarz 2021-02-05 03:00:43 +00:00
parent 758ce025aa
commit bd927edea4
1 changed files with 42 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
Unsere-Idee.md

@ -1,18 +1,47 @@
Die Leitfrage, mit der sich das Projekt beschäftigt ist "Wie sicher ist meine VM?" und "Woher bekomme ich die sicherste?" Die Leitfrage, mit der sich das Projekt beschäftigt ist **"Wie sicher ist meine VM?"** und **"Woher bekomme ich die sicherste?"**
Um diese Fragen zu beantworten, haben wir 18 virtuelle Maschinen auf verschiedenen Plattformen mit verschiedenen Betriebssystemen und Versionen überprüft. Dabei haben wir die Cloud-Anbieter: Amazon Webservice, Google Cloud Plattform und Hetzner ausgewählt, sowie die lokale Alternative mit VMware. Genaueres zu den getesteten Systemen, im Kapitel [Testauswahl](Testauswahl).
Um die Sicherheit zu messen und quantifizieren, haben wir Vulnerability Scanner verwendet. Diese bewerten anhand eines Index und sonstigen Logs die Sicherheit des Systems und zeigen Schwachstellen auf. Hier verwendeten wir die drei Scanner Lynis, Testssl.sh und otseca. Weiteres zu den Tools und zur Auswahl im Kapitel [Toolauswahl](Toolauswahl).
In unserem finalen Vorgehen haben wir pro VM insgesamt dreimal die drei Scanner ausgeführt.
1. Auf der komplett frischen VM
2. Nach einem `apt-upgrade` und Aktualisierung der sonstigen Komponenten
3. Nach dem Ausführen eines automatischen Verbesserungstools
Mit der ersten Stufe wollen wir sehen, wer das sicherste Image liefert ohne, dass man sich um Updates gekümmert hat. Und was es für einen Unterschied macht zu der aktualisierten Version. Mit dem letzten Schritt testen wir das Tool JShielder, das eine Reihe an Verbesserungen verspricht. Dies empfanden wir als interessant, da das Tool eher unbekannt ist und seit August 2019 nicht mehr upgedatet wurde (Stand: 28.01.21). Um diese Fragen zu beantworten, haben wir 18 virtuelle Maschinen auf verschiedenen Plattformen mit verschiedenen Betriebssystemen und Versionen dieser überprüft. Dabei haben wir die Cloud-Anbieter: Amazon Web Services, Google Cloud Plattform und Hetzner ausgewählt, außerdem wurde die lokale Alternative VMware benutzt, um ältere Images zu testen. Genaueres zu den getesteten Systemen, im Kapitel [Testauswahl](Testauswahl).
Zum Schluss folgt natürlich die Auswertung der gesammelten Daten. Da dies bei 18 Maschinen mit je drei Läufen und je drei Tools eine Menge an Dateien und Daten liefert, haben wir einen Parser geschrieben und eine Datenbank verwendet.
Um die Sicherheit messen und quantifizieren zu können, haben wir Open-Source Vulnerability-Scanner verwendet. Diese bewerten das System anhand vieler kleiner Tests. Beispiele hierfür sind etwa:
* Kernelparameter Tests
* Korrekte Einstellungen der Berechtigungen
* Offene Ports
* Veraltete Software
* uvm.
Weiter geben viele Tools einen Index an, der eine vergleichbare Zahl darstellt, womit verschiedene Systeme verglichen werden können. Außerdem werden Unmengen an Logdateien sowie Konsolenoutput generiert. In dieses stehen Beispielsweise die durchgeführten Tests oder auch Vorschläge, wie die Sicherheit des Systems verbessert werden kann. Hier verwendeten wir die drei Scanner Lynis, Testssl.sh und otseca. Weiteres zu den Tools und zur Auswahl im Kapitel [Toolauswahl](Toolauswahl).
In unserem finalen Vorgehen haben wir pro VM insgesamt dreimal die drei Scanner ausgeführt.
```mermaid
graph LR
A[Frische VM] ==> B[Testdurchlauf 1]
B ==> |Upgrade über den Packagemanager| C[Testdurchlauf 2]
C ==> |Ausführen des JShielders| D[Testdurchlauf 3]
```
Mit der ersten Stufe wollen wir sehen, wer das sicherste Image liefert ohne, dass man sich um Updates gekümmert hat. Weiter kann es interessant sein, zu sehen, ob eine Aktualisierung eine Verbesserung bringt. Mit dem letzten Schritt testen wir das Tool JShielder, das eine Reihe an Verbesserungen verspricht. Dies empfanden wir als interessant, da das Tool eher unbekannt ist und seit August 2019 nicht mehr upgedatet wurde (Stand: 28.01.21).
Zum Schluss folgt die Auswertung der gesammelten Daten. Da dies bei 18 Maschinen mit je drei Läufen und je drei Tools eine Unzahl an Dateien und Daten liefert, haben wir einen Parser geschrieben und eine Datenbank verwendet.
## Verlauf der Projektidee ## Verlauf der Projektidee
Diese Idee war jedoch nicht von Anfang an geplant. Der Verlauf lässt sich wie folgt darstellen. Diese Idee war jedoch nicht von Anfang an geplant. Der Verlauf lässt sich wie folgt darstellen.
![Verlauf](uploads/2ae362cb51a0beb385ac5b9f33d678aa/Verlauf.jpg)
Initial haben wir geplant selbst ein Tool zu schreiben, das unsere VM testet. Dabei sollte von außen die VM nach offenen Ports und sonstigen Angriffsvektoren überprüft werden. Geplante Programmiersprache war Python und das Zielsystem Ubuntu. ```mermaid
Bei intensiveren Überlegungen haben wir uns entschieden unsere VM von innen heraus zu testen. Also das Tool auf der VM auszuführen. Das hat zum Vorteil, dass wir mehr Aspekte überprüfen können, was das Ergebnis interessanter macht. Außerdem entspricht das eher dem uns ausgedachten Use Case. graph LR
Im weiteren Verlauf wurde uns der Aufwand bewusst, der erbracht werden muss, um ein solches Tool zu schreiben. Denn es muss so genau arbeiten, dass Unterschiede bei gleichem Betriebssystem auf unterschiedlichen Anbietern deutlich werden. Also haben wir uns informiert welche Tools existieren und sind auf eine Vielzahl gestoßen. Nachdem wir alle durchgeschaut hatten, haben wir uns überlegt, dass es interessant wäre die Tools untereinander zu vergleichen. Die ausgewählten Tools wurden also auf den Testmaschinen ausgeführt und die Ausgaben verglichen. Dabei fiel auf, dass der Vergleich sich aufgrund unterschiedlicher Ausgabeformate schwierig gestaltet. Außerdem testen nicht alle Tools die gleichen Bereiche der VM. Zusätzlich entpuppte sich der JShielder nicht als Scanner, sondern als Hardening-Tool, der gleich Einstellungen vornimmt. A[Projektbeginn] ==> B[Von außen testen]
subgraph Eigenes Tool schreiben
B ==> C[Von innen testen]
end
subgraph Open-Source Tools benutzen
C ==> D[Vergleich existierender Tools]
D ==> E[Mehrstufiger Vergleich der VMs]
end
E ==> F[Finales Projekt]
```
Initial haben wir geplant selbst ein Tool zu schreiben, das unsere VM testet. Dabei sollte von außen die VM nach offenen Ports und sonstigen Angriffsvektoren überprüft werden. Geplante Programmiersprache war Python und das Zielsystem Ubuntu. Bei intensiveren Überlegungen haben wir uns entschieden unsere VM von innen heraus zu testen. Also das Tool auf der VM auszuführen. Das hat zum Vorteil, dass wir mehr Aspekte überprüfen können, was das Ergebnis interessanter macht. Außerdem entspricht das eher dem uns ausgedachten Use Case.
Im weiteren Verlauf wurde uns aber der Aufwand bewusst, der erbracht werden muss, um ein solches Tool zu schreiben. Denn es muss so genau arbeiten, dass Unterschiede bei gleichem Betriebssystem auf unterschiedlichen Anbietern deutlich werden.
Also haben wir uns informiert welche Tools existieren und sind auf eine Vielzahl gestoßen. Nachdem wir ca. 30 überprüft hatten, haben wir uns überlegt, dass es interessant wäre die Tools untereinander zu vergleichen. Die ausgewählten Tools wurden also auf den Testmaschinen ausgeführt und die Ausgaben verglichen. Dabei fiel auf, dass der Vergleich sich aufgrund unterschiedlicher Ausgabeformate schwierig gestaltet. Außerdem testen nicht alle Tools die gleichen Bereiche der VM. Zusätzlich entpuppte sich der JShielder nicht als Scanner, sondern als Hardening-Tool, der das System verbessern soll.
Somit entschieden wir uns für den oben beschriebenen Weg mit den drei Stufen. Somit entschieden wir uns für den oben beschriebenen Weg mit den drei Stufen.