security scanner design am beispiel von httprecon n.
Download
Skip this Video
Download Presentation
Security Scanner Design am Beispiel von httprecon

Loading in 2 Seconds...

play fullscreen
1 / 23

Security Scanner Design am Beispiel von httprecon - PowerPoint PPT Presentation


  • 83 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Security Scanner Design am Beispiel von httprecon' - huy


Download Now 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
agenda security scanner design
Agenda  Security Scanner Design
  • Einführung
  • Analysetechniken
  • Test-Module
  • Architektur
  • Reporting
  • Zusammenfassung
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 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).
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, …)
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: maru@scip.ch