Security scanner design am beispiel von httprecon
This presentation is the property of its rightful owner.
Sponsored Links
1 / 23

Security Scanner Design am Beispiel von httprecon PowerPoint PPT Presentation


  • 59 Views
  • Uploaded on
  • Presentation posted in: General

Security Scanner Design am Beispiel von httprecon. Marc Ruef www.scip.ch. Agenda  Security Scanner Design. Einführung Analysetechniken Test-Module Architektur Reporting Zusammenfassung. Übersetzung. Einführung I: Vorstellung. Einführung II: Präsentation.

Download Presentation

Security Scanner Design am Beispiel von httprecon

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Security scanner design am beispiel von httprecon

Security Scanner Designam Beispiel von httprecon

Marc Ruef

www.scip.ch


Agenda security scanner design

Agenda  Security Scanner Design

  • Einführung

  • Analysetechniken

  • Test-Module

  • Architektur

  • Reporting

  • Zusammenfassung


Einf hrung i vorstellung

Übersetzung

Einführung I: Vorstellung


Einf hrung ii pr sentation

Einführung II: Präsentation

  • Grundlegende Funktionsweise von Security Scanner

  • Ideale Umsetzung einer entsprechenden Lösung

  • Konkreter Vergleich zum httprecon project mit seinen Vor- und Nachteilen


Einf hrung iii security scanner

Quelle: http://www.scip.ch/?labs.20091106

Einführung III: Security Scanner

  • Ein Security Scanner wird eingesetzt, um automatisiert, semi-automatisiert oder begleitet die Sicherheit einer Komponente zu ermitteln.

  • Im weitesten Sinn gehören dazu Lösungen wie:

    • Portscanner

    • Auswertungs-Utilities

    • Vulnerability Scanner

    • Exploiting Frameworks


Analysetechniken i ableitung

Analysetechniken I - Ableitung

  • Beschreibung

    • Anhand einer allgemein identifizierten Gegebenheit wird die potentielle Existenz einer Schwachstelle abgeleitet.

      • HTTP-Fingerprint Apache <2.0.51 mod_dav LOCK Denial of Service

      • OS-Fingerprint Windows 95 Out of Band Denial of Service

  • Problem

    • Schwachstellen werden nur erahnt und nicht verifiziert. False-Positives sind genauso möglich wie False-Negatives.


Analysetechniken ii scanning

Analysetechniken II - Scanning

  • Beschreibung

    • Anhand einer gezielt identifizierten Eigenschaft/Objekt wird die potentielle oder effektive Existenz einer Schwachstelle ermittelt.

      • Webserver bietet /FormMail.pl an Redirect Parameter Cross Site Scripting

      • Server benutzt ausschliesslich SSLv2 Kryptografisch unsichere Verbindung

  • Problem

    • Zugriffe müssen dediziert umgesetzt werden.

    • Die Qualität der Resultate ist massgeblich von der Intelligenz dieser abhängig.


Analysetechniken iii exploiting

Analysetechniken III - Exploiting

  • Beschreibung

    • Anhand einer gezielt ausgenutzten Sicherheitslücke wird die existente Schwachstelle ermittelt.

      • Microsoft IIS 6.0 Authentisierung umgehen WebDAV Remote Authentication Bypass

      • Citrix XenCenterWeb inkludiert Script-Code console.php Cross Site Scripting

  • Problem

    • Intrusive Tests können Manipulationen erzwingen und Schäden anrichten.

    • Stetige Entwicklung verlässlicher Exploits ist sehr aufwendig.


Test module i datenbank

Test-Module I: Datenbank

  • Sämtliche Beschreibungen zu Tests und Schwachstellen werden in einer Datenbank dokumentiert.

    • Titel der Schwachstelle

    • Beschreibung des Problems

    • Einstufung des Risikos

    • Vorgehen zur Ausnutzung/Verifikation

    • Liste mir Gegenmassnahmen

    • Quellenangaben und Links

  • Manche Lösungen verwenden eine relationale Datenbank, andere pflegen Dateien zu nutzen.


Test module i datenbank httprecon fdb datei

Test-Module I: Datenbank (httprecon fdb Datei)


Test module i datenbank nessus nasl datei

Test-Module I: Datenbank (Nessus NASL Datei)


Test module i datenbank scip pentest db

Test-Module I: Datenbank (scip PenTest DB)


Test module ii plugins

Test-Module II: Plugins

  • Die einzelnen Tests werden modular mit dedizierten Plugins realisiert.

  • Das Ausführen von Plugins ist zeitintensiv. Durch Abhängigkeiten sollten sie bestmöglich nur dann ausgeführt werden, wenn es „Sinn“ macht.

  • Tests sollten in Plugin-Familien gruppiert werden (z.B. Webserver, Mailserver, SNMP, Windows, …)

  • Plugins sollten quelloffen und/oder gut dokumentiert sein, um das Vorgehen nachvollziehen, adaptieren oder querprüfen zu können.


Test module iii test sprache

Test-Module III: Test-Sprache

  • Für das Umsetzen der Tests/Plugins muss eine simple Sprache genutzt werden.

  • Die Sprache sollte klare Schnittstellen für immer wiederkehrende Funktionen haben (z.B. Tests offener Ports, HTTP-Zugriffe, etc.)

  • Die Sprache sollte das Einbinden externer Skripte erlauben (z.B. Exploits).


Test module iii test sprache atk asl

Test-Module III: Test-Sprache (ATK/ASL)


Test module iii test sprache nessus nasl

Test-Module III: Test-Sprache (Nessus/NASL)


Architektur i standalone

Architektur I - Standalone

  • Beschreibung

    • Simple Scanning-Lösungen agieren standalone.

  • Problem

    • Direktzugriffe auf Systeme/Dienste sind in topologisch komplexen Umgebungen (Routing/Firewalling) nicht ohne weiteres Möglich.


Architektur ii multi tier

Architektur II - Multi-Tier

  • Beschreibung

    • Erweiterte Scanning-Lösungen für das professionelle Umfeld bieten eine Multi-Tier Architektur an.

  • Problem

    • Die Installation, Wartung und Nutzung wird mit jeder zusätzlichen Komponente erschwert.


Reporting

Reporting

  • Mit dem Reporting steht und fällt die konkrete Nützlichkeit einer Analyse.

  • Reports müssen modular, detailliert und dennoch übersichtlich sein.

  • Verschiedene Darstellungsformen machen eine gute Lösung aus:

    • Listen und Tabellen zur Übersicht

    • Statistiken und Diagramme zwecks Analysen

    • Prosatext für umfassenden Einblick

    • Bildschirmausgaben mit technischen Details

  • Report-Dokumente sollten sich in verschiedenen Formaten generieren lassen (PDF, XML, CSV, …)


Reporting1

Reporting


Reporting qualys

Reporting (Qualys)


Zusammenfassung

Zusammenfassung

  • Security Scanner helfen beim Finden von Schwachstellen.

  • Verschiedene Auswertungsmechanismen garantieren unterschiedliche Zuverlässigkeit.

  • Eine pluginbasierte Architektur erleichtert eine modulare Erweiterung von Tests.

  • Architektonische Eigenschaften helfen dem Einbinden im Unternehmensnetzwerk.

  • Das Reporting stellt den zentralen Übergangspunkt zur weiteren Absicherung dar.


Fragen

Fragen?

  • „Man hört nur die Fragen, auf welche man imstande ist, eine Antwort zu geben.“– Friedrich Nietzsche

  • Kontaktieren Sie mich am besten per Email: [email protected]


  • Login