Security through obscurity: Unterschied zwischen den Versionen
| Zeile 31: | Zeile 31: | ||
|- | |- | ||
| [[Portscan]]s ignorieren || Konfiguration einer [[Firewall]], so dass Anfragen auf [[Port (Netzwerkadresse)|Ports]] still verworfen (''DROP'') statt ablehnend beantwortet (''REJECT'') werden | | [[Portscan]]s ignorieren || Konfiguration einer [[Firewall]], so dass Anfragen auf [[Port (Netzwerkadresse)|Ports]] still verworfen (''DROP'') statt ablehnend beantwortet (''REJECT'') werden | ||
* Dies hat | * Dies hat den Nebeneffekt, dass auf sendender Seite [[Timeout (Netzwerktechnik)|Timeouts]] auftreten, die z. B. automatisierte [[Brute-Force-Methode|Brute-Force]]-Angriffe über Netzwerke sehr stark verlangsamen oder gar unmöglich machen sollen | ||
|- | |- | ||
| Netzwerkdienste verstecken || Dienste wie die [[Secure Shell]] oder [[MySQL]] nicht auf ihren [[Liste der Portnummern|standardisierten Ports]], sondern auf anderen Ports laufen lassen | | Netzwerkdienste verstecken || Dienste wie die [[Secure Shell]] oder [[MySQL]] nicht auf ihren [[Liste der Portnummern|standardisierten Ports]], sondern auf anderen Ports laufen lassen | ||
* Bei einem automatisierten Angriff mit der Frequenz von 50 Millisekunden auf dem Niveau einer [[Paketumlaufzeit]] im Internet dauert das Ausprobieren aller 65.535 Ports knapp eine Stunde. Übliche Portscanner wie [[Nmap]] unterstützen meist einen parallelen Angriff ([[Multithreading]]) auf die einzelnen Ports, dadurch lässt sich der Zeitaufwand ohne weiteres auf unter 5 Minuten verkürzen | * Bei einem automatisierten Angriff mit der Frequenz von 50 Millisekunden auf dem Niveau einer [[Paketumlaufzeit]] im Internet dauert das Ausprobieren aller 65.535 Ports knapp eine Stunde. Übliche Portscanner wie [[Nmap]] unterstützen meist einen parallelen Angriff ([[Multithreading]]) auf die einzelnen Ports, dadurch lässt sich der Zeitaufwand ohne weiteres auf unter 5 Minuten verkürzen | ||
|- | |- | ||
| Ausgabe von Fehlinformationen || Die auf eingehende Verbindungen folgende reguläre Antwort ändern, beispielsweise Namen oder Versionsnummern der Programme, um Angreifern eine andere Software vorzugaukeln, die uninteressant ist | | Ausgabe von Fehlinformationen || Die auf eingehende Verbindungen folgende reguläre Antwort ändern, beispielsweise Namen oder Versionsnummern der Programme, um Angreifern eine andere Software vorzugaukeln, die uninteressant ist. Dieses Verfahren verwenden auch [[Honeypot]]s | ||
|- | |- | ||
| Closed-Source-Software || Wie sich [[Open Source]] und [[Closed Source]] unter dem Aspekt der Sicherheit verhalten, wird teilweise kontrovers diskutiert | | Closed-Source-Software || | ||
Wie sich [[Open Source]] und [[Closed Source]] unter dem Aspekt der Sicherheit verhalten, wird teilweise kontrovers diskutiert | |||
* Betriebssysteme mit öffentlich einsehbarem Quellcode wie [[Berkeley Software Distribution|BSD]], [[OpenSolaris]] oder [[Linux]] profitieren davon, dass der Quelltext von vielen Programmierern durchgesehen werden kann und so auch [[Programmfehler]] gefunden werden | * Betriebssysteme mit öffentlich einsehbarem Quellcode wie [[Berkeley Software Distribution|BSD]], [[OpenSolaris]] oder [[Linux]] profitieren davon, dass der Quelltext von vielen Programmierern durchgesehen werden kann und so auch [[Programmfehler]] gefunden werden | ||
In diesem Zusammenhang wird oft [[Eric Raymond]] zitiert: "Given enough eyeballs, all bugs are shallow" | |||
Wichtig ist der Aspekt des zugänglichen Quellcodes bei allen konkreten Algorithmen der Kryptographie ([[Kerckhoffs’ Prinzip]]) – dies ist selbst unter Microsoft Windows 10 nicht gewährt, weswegen das [[Bundesamt für Sicherheit in der Informationstechnik|BSI]] vom Einsatz in sicherheitskritischen Bereichen abrät | |||
|} | |} | ||
Version vom 1. November 2024, 13:48 Uhr
Security through obscurity - Sicherheit durch Verheimlichung
Beschreibung
- Sicherheit durch Geheimhaltung der Funktionsweise
Es versucht, die Sicherheit eines Systems oder eines Verfahrens zu gewährleisten, indem seine Funktionsweise geheim gehalten wird
- Security through obscurity
- Security by obscurity
- Verwirrung
- Unklarheit
- Dunkelheit
- Security Through Obscurity ist NICHT empfohlen
- Ungeeignetes Sicherungsprinzip
National Institute of Standards and Technology (NIST) rät Sicherheitssysteme nicht auf dieser Basis zu konzipieren
- "System security should not depend on the secrecy of the implementation or its components"
- Nachteile
Solche Systeme sind
- Intransparent
- Kundenfeindlich
- Wenig geeignet, Vertrauen in Sicherheit zu schaffen
Beispiele
| Beispiel | Beschreibung |
|---|---|
| Ping ignorieren | Einige Hosts sind so konfiguriert, dass sie kein Gesuch um ein Echo erfüllen
|
| Portscans ignorieren | Konfiguration einer Firewall, so dass Anfragen auf Ports still verworfen (DROP) statt ablehnend beantwortet (REJECT) werden
|
| Netzwerkdienste verstecken | Dienste wie die Secure Shell oder MySQL nicht auf ihren standardisierten Ports, sondern auf anderen Ports laufen lassen
|
| Ausgabe von Fehlinformationen | Die auf eingehende Verbindungen folgende reguläre Antwort ändern, beispielsweise Namen oder Versionsnummern der Programme, um Angreifern eine andere Software vorzugaukeln, die uninteressant ist. Dieses Verfahren verwenden auch Honeypots |
| Closed-Source-Software |
Wie sich Open Source und Closed Source unter dem Aspekt der Sicherheit verhalten, wird teilweise kontrovers diskutiert
In diesem Zusammenhang wird oft Eric Raymond zitiert: "Given enough eyeballs, all bugs are shallow" Wichtig ist der Aspekt des zugänglichen Quellcodes bei allen konkreten Algorithmen der Kryptographie (Kerckhoffs’ Prinzip) – dies ist selbst unter Microsoft Windows 10 nicht gewährt, weswegen das BSI vom Einsatz in sicherheitskritischen Bereichen abrät |
Gegenkonzept
Sicherheit durch weitestgehende Transparenz
Ausgehend von der Kryptologie wird hierbei vorgeschlagen
- so wenig wie möglich geheim zu halten
- um dieses dann umso leichter schützen
- gegebenenfalls ersetzen zu können