1 / 23

Security Scanner Design am Beispiel von httprecon

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.

huy
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Scanner Designam Beispiel von httprecon Marc Ruef www.scip.ch

  2. Agenda  Security Scanner Design • Einführung • Analysetechniken • Test-Module • Architektur • Reporting • Zusammenfassung

  3. Übersetzung Einführung I: Vorstellung

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

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

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

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

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

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

  10. Test-Module I: Datenbank (httprecon fdb Datei)

  11. Test-Module I: Datenbank (Nessus NASL Datei)

  12. Test-Module I: Datenbank (scip PenTest DB)

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

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

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

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

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

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

  19. 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, …)

  20. Reporting

  21. Reporting (Qualys)

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

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

More Related