security scanner design am beispiel von httprecon
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


  • 81 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


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: [email protected]
ad