Security Scanner Design am Beispiel von httprecon Marc Ruef www.scip.ch
Agenda    Security Scanner Design <ul><li>Einführung </li></ul><ul><li>Analysetechniken </li></ul><ul><li>Test-Module </l...
Einführung I: Vorstellung „ Die Kunst des Penetration Testing“ (2007), Computer & Literatur Böblingen, ISBN  3-936546-49-5...
Einführung II: Präsentation <ul><li>Grundlegende  Funktionsweise  von Security Scanner </li></ul><ul><li>Ideale  Umsetzung...
Einführung III: Security Scanner <ul><li>Ein Security Scanner wird eingesetzt, um automatisiert, semi-automatisiert oder b...
Analysetechniken I - Ableitung <ul><li>Beschreibung </li></ul><ul><ul><li>Anhand einer allgemein identifizierten Gegebenhe...
Analysetechniken II - Scanning <ul><li>Beschreibung </li></ul><ul><ul><li>Anhand einer gezielt identifizierten Eigenschaft...
Analysetechniken III - Exploiting <ul><li>Beschreibung </li></ul><ul><ul><li>Anhand einer gezielt ausgenutzten Sicherheits...
Test-Module I: Datenbank <ul><li>Sämtliche Beschreibungen zu Tests und Schwachstellen werden in einer  Datenbank  dokument...
Test-Module I: Datenbank (httprecon fdb Datei)
Test-Module I: Datenbank (Nessus NASL Datei)
Test-Module I: Datenbank (scip PenTest DB)
Test-Module II: Plugins <ul><li>Die einzelnen Tests werden modular mit dedizierten  Plugins  realisiert. </li></ul><ul><li...
Test-Module III: Test-Sprache <ul><li>Für das Umsetzen der Tests/Plugins muss eine  simple Sprache  genutzt werden. </li><...
Test-Module III: Test-Sprache (ATK/ASL)
Test-Module III: Test-Sprache (Nessus/NASL)
Architektur I - Standalone <ul><li>Beschreibung </li></ul><ul><ul><li>Simple Scanning-Lösungen agieren  standalone . </li>...
Architektur II - Multi-Tier <ul><li>Beschreibung </li></ul><ul><ul><li>Erweiterte Scanning-Lösungen für das professionelle...
Reporting <ul><li>Mit dem Reporting  steht und fällt  die konkrete Nützlichkeit einer Analyse. </li></ul><ul><li>Reports m...
Reporting
Reporting (Qualys)
Zusammenfassung <ul><li>Security Scanner  helfen  beim Finden von Schwachstellen. </li></ul><ul><li>Verschiedene  Auswertu...
Fragen? <ul><li>„ Man hört nur die Fragen, auf welche man imstande ist, eine Antwort zu geben. “ – Friedrich Nietzsche </l...
Upcoming SlideShare
Loading in …5
×

Security Scanner Design am Beispiel von httprecon

633 views
582 views

Published on

Am 24. September 2009 hielt Marc Ruef (CTO der scip AG) einen Vortrag an der OpenExpo 2009 in Winterthur. Dieser trug den Titel Security Scanner Design am Beispiel von httprecon und sollte drei Aspekte besprechen:

* Grundlegende Funktionsweise von Security Scanner
* Ideale Umsetzung einer entsprechenden Lösung
* Konkreter Vergleich zum httprecon project mit seinen Vor- und Nachteilen

Link: http://www.scip.ch/?labs.20090925

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
633
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Security Scanner Design am Beispiel von httprecon

  1. 1. Security Scanner Design am Beispiel von httprecon Marc Ruef www.scip.ch
  2. 2. Agenda  Security Scanner Design <ul><li>Einführung </li></ul><ul><li>Analysetechniken </li></ul><ul><li>Test-Module </li></ul><ul><li>Architektur </li></ul><ul><li>Reporting </li></ul><ul><li>Zusammenfassung </li></ul>
  3. 3. Einführung I: Vorstellung „ Die Kunst des Penetration Testing“ (2007), Computer & Literatur Böblingen, ISBN 3-936546-49-5 Letztes Buch http://www.computec.ch Private Webseite CTO, scip AG, Zürich Beruf Marc Ruef Name Übersetzung
  4. 4. Einführung II: Präsentation <ul><li>Grundlegende Funktionsweise von Security Scanner </li></ul><ul><li>Ideale Umsetzung einer entsprechenden Lösung </li></ul><ul><li>Konkreter Vergleich zum httprecon project mit seinen Vor- und Nachteilen </li></ul>
  5. 5. Einführung III: Security Scanner <ul><li>Ein Security Scanner wird eingesetzt, um automatisiert, semi-automatisiert oder begleitet die Sicherheit einer Komponente zu ermitteln . </li></ul><ul><li>Im weitesten Sinn gehören dazu Lösungen wie: </li></ul><ul><ul><li>Portscanner </li></ul></ul><ul><ul><li>Auswertungs-Utilities </li></ul></ul><ul><ul><li>Vulnerability Scanner </li></ul></ul><ul><ul><li>Exploiting Frameworks </li></ul></ul>Quelle: http://www.scip.ch/?labs.20091106
  6. 6. Analysetechniken I - Ableitung <ul><li>Beschreibung </li></ul><ul><ul><li>Anhand einer allgemein identifizierten Gegebenheit wird die potentielle Existenz einer Schwachstelle abgeleitet. </li></ul></ul><ul><ul><ul><li>HTTP-Fingerprint Apache <2.0.51  mod_dav LOCK Denial of Service </li></ul></ul></ul><ul><ul><ul><li>OS-Fingerprint Windows 95  Out of Band Denial of Service </li></ul></ul></ul><ul><li>Problem </li></ul><ul><ul><li>Schwachstellen werden nur erahnt und nicht verifiziert . False-Positives sind genauso möglich wie False-Negatives. </li></ul></ul>
  7. 7. Analysetechniken II - Scanning <ul><li>Beschreibung </li></ul><ul><ul><li>Anhand einer gezielt identifizierten Eigenschaft/Objekt wird die potentielle oder effektive Existenz einer Schwachstelle ermittelt. </li></ul></ul><ul><ul><ul><li>Webserver bietet /FormMail.pl an  Redirect Parameter Cross Site Scripting </li></ul></ul></ul><ul><ul><ul><li>Server benutzt ausschliesslich SSLv2  Kryptografisch unsichere Verbindung </li></ul></ul></ul><ul><li>Problem </li></ul><ul><ul><li>Zugriffe müssen dediziert umgesetzt werden. </li></ul></ul><ul><ul><li>Die Qualität der Resultate ist massgeblich von der Intelligenz dieser abhängig. </li></ul></ul>
  8. 8. Analysetechniken III - Exploiting <ul><li>Beschreibung </li></ul><ul><ul><li>Anhand einer gezielt ausgenutzten Sicherheitslücke wird die existente Schwachstelle ermittelt. </li></ul></ul><ul><ul><ul><li>Microsoft IIS 6.0 Authentisierung umgehen  WebDAV Remote Authentication Bypass </li></ul></ul></ul><ul><ul><ul><li>Citrix XenCenterWeb inkludiert Script-Code  console.php Cross Site Scripting </li></ul></ul></ul><ul><li>Problem </li></ul><ul><ul><li>Intrusive Tests können Manipulationen erzwingen und Schäden anrichten. </li></ul></ul><ul><ul><li>Stetige Entwicklung verlässlicher Exploits ist sehr aufwendig . </li></ul></ul>
  9. 9. Test-Module I: Datenbank <ul><li>Sämtliche Beschreibungen zu Tests und Schwachstellen werden in einer Datenbank dokumentiert. </li></ul><ul><ul><li>Titel der Schwachstelle </li></ul></ul><ul><ul><li>Beschreibung des Problems </li></ul></ul><ul><ul><li>Einstufung des Risikos </li></ul></ul><ul><ul><li>Vorgehen zur Ausnutzung/Verifikation </li></ul></ul><ul><ul><li>Liste mir Gegenmassnahmen </li></ul></ul><ul><ul><li>Quellenangaben und Links </li></ul></ul><ul><li>Manche Lösungen verwenden eine relationale Datenbank , andere pflegen Dateien zu nutzen. </li></ul>
  10. 10. Test-Module I: Datenbank (httprecon fdb Datei)
  11. 11. Test-Module I: Datenbank (Nessus NASL Datei)
  12. 12. Test-Module I: Datenbank (scip PenTest DB)
  13. 13. Test-Module II: Plugins <ul><li>Die einzelnen Tests werden modular mit dedizierten Plugins realisiert. </li></ul><ul><li>Das Ausführen von Plugins ist zeitintensiv. Durch Abhängigkeiten sollten sie bestmöglich nur dann ausgeführt werden, wenn es „Sinn“ macht. </li></ul><ul><li>Tests sollten in Plugin-Familien gruppiert werden (z.B. Webserver, Mailserver, SNMP, Windows, …) </li></ul><ul><li>Plugins sollten quelloffen und/oder gut dokumentiert sein, um das Vorgehen nachvollziehen, adaptieren oder querprüfen zu können. </li></ul>
  14. 14. Test-Module III: Test-Sprache <ul><li>Für das Umsetzen der Tests/Plugins muss eine simple Sprache genutzt werden. </li></ul><ul><li>Die Sprache sollte klare Schnittstellen für immer wiederkehrende Funktionen haben (z.B. Tests offener Ports, HTTP-Zugriffe, etc.) </li></ul><ul><li>Die Sprache sollte das Einbinden externer Skripte erlauben (z.B. Exploits). </li></ul>
  15. 15. Test-Module III: Test-Sprache (ATK/ASL)
  16. 16. Test-Module III: Test-Sprache (Nessus/NASL)
  17. 17. Architektur I - Standalone <ul><li>Beschreibung </li></ul><ul><ul><li>Simple Scanning-Lösungen agieren standalone . </li></ul></ul><ul><li>Problem </li></ul><ul><ul><li>Direktzugriffe auf Systeme/Dienste sind in topologisch komplexen Umgebungen (Routing/Firewalling) nicht ohne weiteres Möglich. </li></ul></ul>
  18. 18. Architektur II - Multi-Tier <ul><li>Beschreibung </li></ul><ul><ul><li>Erweiterte Scanning-Lösungen für das professionelle Umfeld bieten eine Multi-Tier Architektur an. </li></ul></ul><ul><li>Problem </li></ul><ul><ul><li>Die Installation, Wartung und Nutzung wird mit jeder zusätzlichen Komponente erschwert. </li></ul></ul>
  19. 19. Reporting <ul><li>Mit dem Reporting steht und fällt die konkrete Nützlichkeit einer Analyse. </li></ul><ul><li>Reports müssen modular, detailliert und dennoch übersichtlich sein. </li></ul><ul><li>Verschiedene Darstellungsformen machen eine gute Lösung aus: </li></ul><ul><ul><li>Listen und Tabellen zur Übersicht </li></ul></ul><ul><ul><li>Statistiken und Diagramme zwecks Analysen </li></ul></ul><ul><ul><li>Prosatext für umfassenden Einblick </li></ul></ul><ul><ul><li>Bildschirmausgaben mit technischen Details </li></ul></ul><ul><li>Report-Dokumente sollten sich in verschiedenen Formaten generieren lassen (PDF, XML, CSV, …) </li></ul>
  20. 20. Reporting
  21. 21. Reporting (Qualys)
  22. 22. Zusammenfassung <ul><li>Security Scanner helfen beim Finden von Schwachstellen. </li></ul><ul><li>Verschiedene Auswertungsmechanismen garantieren unterschiedliche Zuverlässigkeit. </li></ul><ul><li>Eine pluginbasierte Architektur erleichtert eine modulare Erweiterung von Tests. </li></ul><ul><li>Architektonische Eigenschaften helfen dem Einbinden im Unternehmensnetzwerk. </li></ul><ul><li>Das Reporting stellt den zentralen Übergangspunkt zur weiteren Absicherung dar. </li></ul>
  23. 23. Fragen? <ul><li>„ Man hört nur die Fragen, auf welche man imstande ist, eine Antwort zu geben. “ – Friedrich Nietzsche </li></ul><ul><li>Kontaktieren Sie mich am besten per Email: maru@scip.ch </li></ul>

×