11 Unsere Idee
Marcel Schwarz edited this page 2021-02-06 21:44:49 +00:00

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 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.

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 diesem 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.

In unserem finalen Vorgehen haben wir pro VM insgesamt dreimal die drei Scanner ausgeführt.

graph LR
  A[Frische VM] ==> B[Testdurchlauf 1]
  B ==> C[Upgrade über<br/>den Packagemanager]
  C ==> D[Testdurchlauf 2]
  D ==> E[Ausführen<br/>des JShielders]
  E ==> F[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.2021).

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

Diese Idee war jedoch nicht von Anfang an geplant. Der Verlauf lässt sich wie folgt darstellen.

graph LR
  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<br/>existierender Tools]
  D ==> E[Mehrstufiger<br/>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.