Was ist die beste verteilte Brute-Force-Gegenmaßnahme?

150

Zunächst ein kleiner Hintergrund: Es ist kein Geheimnis, dass ich ein auth + auth-System für CodeIgniter implementiere, und bis jetzt gewinne ich (sozusagen). Aber ich bin auf eine ziemlich nicht triviale Herausforderung gestoßen (eine, die die meisten Auth-Bibliotheken völlig vermissen, aber ich bestehe darauf, sie richtig zu handhaben): Wie man intelligent mit großen, verteilten Brute-Force-Angriffen mit variablem Benutzernamen umgeht .

Ich kenne alle üblichen Tricks:

  1. Begrenzung der Anzahl fehlgeschlagener Versuche pro IP / Host und Verweigerung des Zugriffs des Täters (z. B. Fail2Ban) - was nicht mehr funktioniert, da Botnets intelligenter geworden sind
  2. Kombinieren Sie das oben Genannte mit einer schwarzen Liste bekannter "schlechter" IPs / Hosts (z. B. DenyHosts) - was darauf beruht, dass Botnets auf Platz 1 fallen, was sie zunehmend nicht tun
  3. IP / Host-Whitelists kombiniert mit herkömmlicher Authentifizierung (leider nutzlos bei dynamischen IP-Benutzern und der hohen Abwanderung auf den meisten Websites)
  4. Festlegen eines landesweiten Limits für die Anzahl fehlgeschlagener Versuche innerhalb eines Zeitraums von N Minuten / Stunde und Drosseln (Anhalten) aller Anmeldeversuche danach für einige Minuten / Stunden (mit dem Problem, dass DoS, das Sie angreift, zum Kinderspiel des Botnetzes wird)
  5. Obligatorische digitale Signaturen (Public-Key-Zertifikate) oder RSA-Hardware-Token für alle Benutzer ohne Anmelde- / Kennwortoption (ohne Frage eine solide Lösung, aber nur praktisch für geschlossene, dedizierte Dienste)
  6. Erzwungene ultrastarke Passwortschemata (z. B.> 25 Unsinnzeichen mit Symbolen - wiederum zu unpraktisch für Gelegenheitsbenutzer)
  7. Und schließlich CAPTCHAs (die in den meisten Fällen funktionieren könnten, aber für Benutzer ärgerlich und gegen einen entschlossenen, einfallsreichen Angreifer praktisch nutzlos sind )

Dies sind nur die theoretisch umsetzbaren Ideen. Es gibt viele Müllideen, die die Site weit öffnen (z. B. für triviale DoS-Angriffe). Was ich will, ist etwas Besseres. Und besser gesagt, ich meine:

  • Es muss sicher (+) gegen DoS- und Brute-Force-Angriffe sein und darf keine neuen Sicherheitslücken einführen, die es einem etwas hinterhältigeren Bot ermöglichen könnten, unter dem Radar weiter zu arbeiten

  • Es muss automatisiert werden. Wenn ein menschlicher Bediener jedes Login überprüfen oder verdächtige Aktivitäten überwachen muss, funktioniert dies in einem realen Szenario nicht

  • Es muss für die Mainstream-Webnutzung machbar sein (dh hohe Abwanderung, hohes Volumen und offene Registrierung, die von Nicht-Programmierern durchgeführt werden kann).

  • Es kann die Benutzererfahrung nicht so stark beeinträchtigen, dass Gelegenheitsbenutzer verärgert oder frustriert werden (und möglicherweise die Website verlassen).

  • Es können keine Kätzchen beteiligt sein, es sei denn, sie sind wirklich sehr, sehr sichere Kätzchen

(+) Mit "sicher" meine ich mindestens so sicher wie die Fähigkeit eines paranoiden Benutzers, sein Passwort geheim zu halten

Also - lass es uns hören! Wie würdest du das machen ? Kennen Sie eine Best Practice, die ich nicht erwähnt habe (oh, bitte sagen Sie, dass Sie dies tun)? Ich gebe zu, dass ich eine eigene Idee habe (Ideen aus 3 und 4 kombinieren), aber ich werde die wahren Experten sprechen lassen, bevor ich mich in Verlegenheit bringe ;-)

Jens Roland
quelle

Antworten:

68

In Ordnung, genug Abwürgen; Folgendes habe ich mir bisher ausgedacht

(Entschuldigung, langer Beitrag voraus. Sei mutig, Freund, die Reise wird sich lohnen.)

Kombinieren Sie die Methoden 3 und 4 aus dem ursprünglichen Beitrag zu einer Art "Fuzzy" - oder dynamischer Whitelist und blockieren Sie dann - und hier ist der Trick - nicht IPs ohne Whitelist, sondern drosseln Sie sie nur in die Hölle und zurück .

Beachten Sie, dass diese Maßnahme nur dazu gedacht ist, diese sehr spezifische Art von Angriff zu vereiteln. In der Praxis würde dies natürlich in Kombination mit anderen Best-Practice-Ansätzen zur Authentifizierung funktionieren: Drosselung fester Benutzernamen, Drosselung pro IP, Code-erzwungene Richtlinie für strenge Kennwörter, nicht gedrosselte Cookie-Anmeldung, Hashing aller Kennwortäquivalente vor dem Speichern, niemals mit Sicherheitsfragen usw.

Annahmen zum Angriffsszenario

Wenn ein Angreifer auf variable Benutzernamen abzielt, wird die Drosselung unserer Benutzernamen nicht ausgelöst. Wenn der Angreifer ein Botnetz verwendet oder Zugriff auf einen großen IP-Bereich hat, ist unsere IP-Drosselung machtlos. Wenn der Angreifer unsere Benutzerliste vorab überprüft hat (normalerweise bei Webdiensten mit offener Registrierung möglich), können wir keinen laufenden Angriff anhand der Anzahl der Fehler "Benutzer nicht gefunden" erkennen. Und wenn wir eine restriktive systemweite Drosselung (alle Benutzernamen, alle IPs) erzwingen, wird jeder solche Angriff unsere gesamte Site für die Dauer des Angriffs plus der Drosselungsperiode betreffen.

Also müssen wir etwas anderes tun.

Der erste Teil der Gegenmaßnahme: Whitelisting

Wir können ziemlich sicher sein, dass der Angreifer die IP-Adressen mehrerer tausend unserer Benutzer (+) nicht erkennen und dynamisch fälschen kann. Das macht Whitelisting möglich. Mit anderen Worten: Für jeden Benutzer speichern wir eine Liste der (gehashten) IPs, von denen aus sich der Benutzer zuvor (kürzlich) angemeldet hat.

Daher fungiert unser Whitelist-Schema als verschlossene "Haustür", an der ein Benutzer von einer seiner anerkannten "guten" IPs aus verbunden sein muss, um sich überhaupt anzumelden. Ein Brute-Force-Angriff auf diese 'Haustür' wäre praktisch unmöglich (+).

(+) Wenn der Angreifer nicht entweder den Server, alle Boxen unserer Benutzer oder die Verbindung selbst "besitzt" - und in diesen Fällen haben wir kein "Authentifizierungs" -Problem mehr, haben wir ein echtes Franchise-Unternehmen -Stecker FUBAR Situation

Der zweite Teil der Gegenmaßnahme: Systemweite Drosselung nicht erkannter IPs

Damit eine Whitelist für einen Webdienst mit offener Registrierung funktioniert, bei dem Benutzer häufig den Computer wechseln und / oder eine Verbindung über dynamische IP-Adressen herstellen, müssen wir eine "Katzentür" offen halten, damit Benutzer eine Verbindung von nicht erkannten IP-Adressen herstellen können. Der Trick besteht darin, diese Tür so zu gestalten, dass Botnets hängen bleiben und legitime Benutzer so wenig wie möglich gestört werden .

In meinem Schema wird dies erreicht, indem eine sehr restriktive maximale Anzahl fehlgeschlagener Anmeldeversuche durch nicht genehmigte IPs über einen Zeitraum von beispielsweise 3 Stunden festgelegt wird (je nach Art des Dienstes kann es sinnvoller sein, einen kürzeren oder längeren Zeitraum zu verwenden) diese Einschränkung global machen , dh. für alle Benutzerkonten.

Selbst eine langsame (1-2 Minuten zwischen den Versuchen) Brute Force würde mit dieser Methode schnell und effektiv erkannt und vereitelt. Natürlich könnte eine wirklich langsame Brute Force immer noch unbemerkt bleiben, aber zu langsame Geschwindigkeiten machen den eigentlichen Zweck des Brute Force-Angriffs zunichte.

Was ich mit diesem Drosselmechanismus erreichen möchte, ist, dass bei Erreichen der Höchstgrenze unsere "Katzentür" für eine Weile zugeschlagen wird, unsere Vordertür jedoch für legitime Benutzer offen bleibt, die auf übliche Weise eine Verbindung herstellen:

  • Entweder durch Herstellen einer Verbindung von einer ihrer erkannten IPs
  • Oder indem Sie ein dauerhaftes Login-Cookie verwenden (von überall)

Die einzigen legitimen Benutzer, die während eines Angriffs betroffen wären - dh. während die Drosselung aktiviert war - wären Benutzer ohne dauerhafte Anmelde-Cookies, die sich von einem unbekannten Ort oder mit einer dynamischen IP anmelden. Diese Benutzer können sich erst anmelden, wenn die Drosselung nachgelassen hat (was möglicherweise eine Weile dauern kann, wenn der Angreifer sein Botnetz trotz Drosselung am Laufen hält).

Um dieser kleinen Gruppe von Benutzern zu ermöglichen, sich durch die ansonsten versiegelte Katzentür zu quetschen, selbst wenn noch Bots darauf hämmerten, würde ich ein 'Backup'-Anmeldeformular mit einem CAPTCHA verwenden. Wenn Sie also die Meldung "Entschuldigung, aber Sie können sich derzeit nicht von dieser IP-Adresse aus anmelden" anzeigen, fügen Sie einen Link mit der Aufschrift " Sichere Backup-Anmeldung - NUR MENSCHEN ( Bots: kein Lügen ) " hinzu. Scherz beiseite, wenn sie auf diesen Link klicken, geben Sie ihnen ein reCAPTCHA-authentifiziertes Anmeldeformular, das die Site-weite Drosselung umgeht. Auf diese Weise wird ihnen , wenn sie menschlich sind UND das richtige Login + Passwort kennen (und CAPTCHAs lesen können), niemals der Dienst verweigert, selbst wenn sie eine Verbindung von einem unbekannten Host herstellen und das Autologin-Cookie nicht verwenden.

Oh, und nur zur Klarstellung: Da ich CAPTCHAs im Allgemeinen als böse betrachte, wird die Anmeldeoption "Backup" nur angezeigt, wenn die Drosselung aktiv war .

Es ist nicht zu leugnen, dass ein solcher anhaltender Angriff immer noch eine Form von DoS-Angriff darstellt, aber mit dem beschriebenen System würde es nur das beeinflussen, was ich für eine winzige Untergruppe von Benutzern halte, nämlich Leute, die das nicht verwenden Cookie "Erinnere dich an mich" UND melde dich zufällig an, während ein Angriff stattfindet UND melde dich nicht von einer ihrer üblichen IP-Adressen an UND wer CAPTCHAs nicht lesen kann. Nur diejenigen, die zu ALLEN dieser Kriterien Nein sagen können - insbesondere Bots und wirklich unglückliche behinderte Menschen - werden während eines Bot-Angriffs abgewiesen.

BEARBEITEN : Eigentlich habe ich mir eine Möglichkeit überlegt, selbst von CAPTCHA herausgeforderte Benutzer während einer Sperrung durchzulassen: Anstelle oder als Ergänzung zum Backup-CAPTCHA-Login kann der Benutzer eine Option für die einmalige Verwendung erhalten , benutzerspezifischer Sperrcode, der an seine E-Mail gesendet wird und mit dem er dann die Drosselung umgehen kann. Dies überschreitet definitiv meine "Ärger" -Schwelle, aber da es nur als letzter Ausweg für eine winzige Untergruppe von Benutzern verwendet wird und es immer noch besser ist, von Ihrem Konto ausgeschlossen zu werden, wäre es akzeptabel.

(Beachten Sie auch, dass nichts davon passiert, wenn der Angriff weniger ausgefeilt ist als die böse verteilte Version, die ich hier beschrieben habe. Wenn der Angriff nur von wenigen IPs ausgeht oder nur wenige Benutzernamen trifft, wird er viel früher vereitelt und ohne standortweite Konsequenzen)


Das ist also die Gegenmaßnahme, die ich in meiner Authentifizierungsbibliothek implementieren werde, sobald ich überzeugt bin, dass es solide ist und dass es keine viel einfachere Lösung gibt, die ich verpasst habe. Tatsache ist, dass es so viele subtile Möglichkeiten gibt, Dinge in Bezug auf Sicherheit falsch zu machen, und ich bin nicht überfordert, falsche Annahmen oder hoffnungslos fehlerhafte Logik zu treffen. Daher sind alle Rückmeldungen, Kritik und Verbesserungen, Feinheiten usw. sehr willkommen.

Jens Roland
quelle
1
Vielleicht könnten Sie für jeden Benutzer ein "spezielles" Passwort generieren, das im Sperrmodus verwendet werden kann (und das eine Verbindung von einer neuen IP usw. herstellt). Dieses spezielle Passwort ist so kompliziert, dass es nicht brutal erzwungen werden kann?
Douglas Leeder
1
Das könnte funktionieren, aber nur, wenn sich die Benutzer an diese Passwörter erinnern, auch wenn sie sie noch nicht verwendet haben (diese Arten von Angriffen sind nicht alltäglich, und kein Botmaster, der sein Salz wert ist, würde sich die Mühe machen, eines lange nach dem Drosseln am Laufen zu halten). Das Risiko ist zu groß, als dass sie sich einfach nicht erinnern könnten.
Jens Roland
1
Eine Methode, die definitiv funktionieren könnte, besteht darin, diesen Benutzern einen Link zum Senden eines Sperrcodes bereitzustellen, über den sie eine E-Mail mit einem benutzerspezifischen Einweg-Token erhalten, mit dem sie sich unter Umgehung des Codes anmelden können Drosselung.
Jens Roland
1
@Abtin: Gute Idee, außer dass dies "Eintritt in das Wettrüsten" wäre - dh. Starten eines "Wer kann wen überlisten?" mit den Personen, die Kennwortlisten für Wörterbuchangriffe erstellen. Ich denke , eine bessere Möglichkeit , eine starke Kennwortrichtlinie durchzusetzen wäre , so gibt es keine schwachen Passwörter
Jens Roland
1
@OrestisP.: Sie verpassen den Punkt des verteilten Angriffs - Die Anzahl der ungültigen Versuche von jeder IP ist minimal, sodass die Blockierung pro IP nicht funktionieren kann. Außerdem beschreibt die Frage speziell einen automatisierten Brute-Force-Angriff. 1) Der Angreifer ist kein Mensch, sondern ein Botnetz von Zombiemaschinen (die das Captcha-Login nicht verwenden können). und 2) die Brute-Force-Natur des Angriffs erfordert eine sehr hohe Anzahl von Anmeldeversuchen, um den Erfolg sicherzustellen, was bedeutet, dass es nicht möglich ist, die Captcha-Lösung in einem Sweat-Shop irgendwo zu betreiben (obwohl dies möglich ist, wenn der Angreifer gut finanziert und entschlossen ist genug).
Jens Roland
17

Ein paar einfache Schritte:

Setzen Sie bestimmte gebräuchliche Benutzernamen auf die schwarze Liste und verwenden Sie sie als Honeypot. Administrator, Gast usw. Lassen Sie niemanden Konten mit diesen Namen erstellen. Wenn also jemand versucht, sie anzumelden, wissen Sie, dass jemand etwas tut, das er nicht tun sollte.

Stellen Sie sicher, dass jeder, der echte Macht auf der Site hat, ein sicheres Passwort hat. Admins / Moderatoren müssen längere Passwörter mit einer Mischung aus Buchstaben, Zahlen und Symbolen haben. Lehnen Sie trivial einfache Passwörter von normalen Benutzern mit einer Erklärung ab.

Eines der einfachsten Dinge, die Sie tun können, ist, den Leuten mitzuteilen, wann jemand versucht hat, sich in ihr Konto einzuloggen, und ihnen einen Link zu geben, um den Vorfall zu melden, wenn sie es nicht waren. Eine einfache Nachricht, wenn sie sich anmelden wie "Jemand hat versucht, sich um 4:20 Uhr in Ihrem Konto anzumelden. Mittwoch bla bla. Klicken Sie hier, wenn Sie es nicht waren." Hier können Sie einige Statistiken zu Angriffen aufbewahren. Sie können die Überwachungs- und Sicherheitsmaßnahmen verstärken, wenn Sie feststellen, dass die Anzahl betrügerischer Zugriffe plötzlich zunimmt.

Patros
quelle
Schöne Gedanken. Ich hatte definitiv vor, eine automatische Kennwortrichtlinie zu implementieren, die sich dynamisch mit der Berechtigungsstufe des Benutzers ändert. Die Honeypot-Idee funktioniert möglicherweise für einige Arten von Angriffen. Wenn der Angriff jedoch verteilt wird, ist es nicht effektiv, die darauf fallenden IPs zu blockieren.
Jens Roland
In Bezug auf die 'Letzte versuchte Anmeldezeit' ist dies eine gute Strategie für Power-User (was ich wette, warum SO dies tut), aber es hat zwei Schwächen: (a) Es geht nicht auf das Problem des Eindringens ein berichtet nur, dass es passiert sein könnte, und (b) die meisten Benutzer erinnern sich einfach nicht / kümmern sich nicht
Jens Roland
1
Ja, im Honeypot und in der Benutzerberichterstattung geht es mehr um das Sammeln von Informationen. Sie können einige wertvolle Messdaten liefern, mit denen Sie wissen, ob / wann ein langsamer Brute-Force-Angriff stattfindet.
Patros
2
Wäre es für den Honeypot nicht besser , einen nicht vorhandenen Benutzernamen als verdächtig zu behandeln, als nur eine feste Liste von bekanntermaßen fehlerhaften Benutzernamen zu verwenden? Sie möchten vermeiden, Benutzer auszusperren, die ihren Benutzernamen falsch eingegeben haben und den Tippfehler nicht bemerkt haben, während sie ihr Passwort mehrmals wiederholt haben, aber ich denke immer noch, dass es Möglichkeiten gibt, wie es wertvoll sein könnte. Sie können sogar einige "Fehlalarme" vermeiden, indem Sie einen großen Bloom-Filter oder eine ähnliche Datenstruktur mit Varianten gültiger Benutzernamen, Vornamen, Nachnamen, E-Mail-Namen usw. erstellen, wenn Benutzer hinzugefügt werden.
R .. GitHub STOP HELPING ICE
11

Wenn ich das MO von Brute-Force-Angriffen richtig verstehe, werden ein oder mehrere Benutzernamen kontinuierlich ausprobiert.

Es gibt zwei Vorschläge, die ich hier noch nicht gesehen habe:

  • Ich habe immer gedacht, dass die Standardpraxis darin besteht, nach jedem falschen Login für jeden Benutzer eine kurze Verzögerung (etwa eine Sekunde) zu haben. Dies verhindert Brute-Force, aber ich weiß nicht, wie lange eine Verzögerung von einer Sekunde einen Wörterbuchangriff in Schach halten würde. (Wörterbuch mit 10.000 Wörtern == 10.000 Sekunden == ungefähr 3 Stunden. Hmm. Nicht gut genug.)
  • Anstelle einer Verlangsamung der gesamten Website können Sie auch eine Drosselklappe für Benutzernamen verwenden. Das Gas wird mit jedem falschen Versuch immer härter (bis zu einem gewissen Grad, denke ich, damit sich der echte Benutzer immer noch anmelden kann).

Bearbeiten : Als Antwort auf Kommentare zu einem Benutzernamen-Gas: Dies ist ein Benutzername-spezifisches Gas ohne Rücksicht auf die Quelle des Angriffs.

Wenn der Benutzername gedrosselt wird, wird sogar ein koordinierter Angriff auf den Benutzernamen (Multi-IP, einmalige Vermutung pro IP, gleicher Benutzername) abgefangen. Einzelne Benutzernamen sind durch das Gas geschützt, auch wenn die Angreifer während des Timeouts einen anderen Benutzer / Pass ausprobieren können.

Aus der Sicht eines Angreifers können Sie während des Timeouts möglicherweise zum ersten Mal 100 Kennwörter erraten und schnell ein falsches Kennwort pro Konto ermitteln. Möglicherweise können Sie für denselben Zeitraum nur 50 Sekunden lang raten.

Aus Sicht eines Benutzerkontos ist immer noch die gleiche durchschnittliche Anzahl von Vermutungen erforderlich, um das Kennwort zu brechen, selbst wenn die Vermutungen aus mehreren Quellen stammen.

Für die Angreifer ist es bestenfalls die gleiche Anstrengung, 100 Konten zu brechen wie für 1 Konto. Da Sie jedoch nicht auf einer Site-weiten Basis drosseln, können Sie die Drossel ziemlich schnell erhöhen.

Zusätzliche Verfeinerungen:

  • IPs erkennen, die mehrere Konten erraten - 408 Request Timeout
  • Erkennen von IPs, die dasselbe Konto erraten - 408 Anforderungszeitlimit nach einer großen Anzahl (z. B. 100) von Vermutungen.

UI-Ideen (in diesem Zusammenhang möglicherweise nicht geeignet), die möglicherweise auch Folgendes verfeinern:

  • Wenn Sie die Kontrolle über die Passworteinstellung haben und den Benutzer anzeigen, wie stark sein Passwort ist , werden Sie aufgefordert, ein besseres auszuwählen.
  • Wenn Sie die Kontrolle über das Login sind Seite , nach einem kleinen (etwa 10) Anzahl der Vermutungen eines einzigen Benutzernamen, bieten eine CAPTCHA.
Jamesh
quelle
Ein Benutzername-Gas und ein IP-Gas sind gut gegen Angriffe mit festem Benutzernamen oder festem IP und machen herkömmliche Wörterbuchangriffe unmöglich. Wenn der Angreifer jedoch ständig die Benutzernamen ändert, kommt er vorbei, ohne eine Drosselung des Benutzernamens auszulösen. Das möchte ich kontern
Jens Roland
2
Danke für die Bearbeitung, Jamesh. Jetzt reden wir. Ich liebe die Idee des 408. Selbst bei strikter Drosselung des Benutzernamens würde ein Botnetz, das mehrere Benutzer angreift, immer noch funktionieren. Und das Überprüfen der Top 5000 Passwörter gegen einen Benutzer ist WENIGER erfolgreich als das Überprüfen des Top 1 Passworts bei 5000 Benutzern
Jens Roland
Nichts wie das Geburtstagsparadoxon. In einer großen Gruppe verwenden viele unsichere Passwörter, und es ist wahrscheinlich, dass eines davon ein beliebtes verwendet. Es wird auch eine ganze Reihe von Leuten wie mich geben, die von einem solchen Angriff nicht erwischt werden.
David Thornley
2
Tatsächlich muss ich möglicherweise die Mathematik meiner vorherigen Aussage erneut überprüfen. Sobald Sie die Top N der häufigsten Passwörter ausgeschlossen haben, kann sich die Wahrscheinlichkeit erhöhen, dass der Benutzer das Passwort # (N + 1) hat, um den Unterschied auszugleichen. Obwohl die Kurve wahrscheinlich steil genug ist, um nicht der Fall zu sein
Jens Roland
9

Es gibt drei Faktoren für die Authentifizierung:

  1. Ein Benutzer weiß etwas (dh ein Passwort)
  2. Ein Benutzer hat etwas (dh einen Schlüsselanhänger)
  3. Ein Benutzer ist etwas (dh Retina-Scan)

Normalerweise setzen Websites nur die Richtlinie 1 durch. Selbst die meisten Banken setzen nur Richtlinie 1 durch. Stattdessen verlassen sie sich bei der Zwei-Faktor-Authentifizierung auf einen "Weiß etwas anderes" -Ansatz. (IE: Ein Benutzer kennt sein Passwort und den Mädchennamen seiner Mutter.) Wenn Sie in der Lage sind, ist es nicht allzu schwierig, einen zweiten Authentifizierungsfaktor hinzuzufügen.

Wenn Sie ungefähr 256 Zufallszeichen generieren können, können Sie diese in einer 16 × 16-Tabelle strukturieren und dann den Benutzer bitten, Ihnen beispielsweise den Wert in der Tabelle von Zelle A-14 anzugeben. Wenn sich ein Benutzer anmeldet oder sein Passwort ändert, geben Sie ihm die Tabelle und fordern Sie ihn auf, sie auszudrucken und zu speichern.

Die Schwierigkeit bei diesem Ansatz besteht darin, dass Sie, wenn ein Benutzer sein Passwort wie gewünscht vergisst, nicht einfach den Standard "Beantworten Sie diese Frage und geben Sie ein neues Passwort ein" anbieten können, da dies auch für Brute-Force anfällig ist. Sie können es auch nicht zurücksetzen und ihnen eine neue E-Mail senden, da auch ihre E-Mail-Adresse gefährdet sein könnte. (Siehe: Makeuseof.com und ihre gestohlene Domain.)

Eine andere Idee (die Kätzchen betrifft) ist das, was BOA SiteKey nennt (ich glaube, sie haben den Namen als Marke eingetragen). Kurz gesagt, Sie lassen den Benutzer ein Bild hochladen, wenn er sich registriert, und wenn er versucht, sich anzumelden, bitten Sie ihn, sein Bild aus 8 oder 15 (oder mehr) zufälligen Bildern auszuwählen. Wenn ein Benutzer ein Bild seines Kätzchens hochlädt, weiß theoretisch nur er genau, welches Bild ihm von allen anderen Kätzchen (oder Blumen oder was auch immer) gehört. Die einzige wirkliche Gefahr, die dieser Ansatz hat, ist der Man-in-the-Middle-Angriff.

Eine weitere Idee (allerdings keine Kätzchen) besteht darin, IPs zu verfolgen, mit denen Benutzer auf das System zugreifen, und sie zu verpflichten, eine zusätzliche Authentifizierung durchzuführen (Captcha, Kitty auswählen, Schlüssel aus dieser Tabelle auswählen), wenn sie sich von einer Adresse aus anmelden, die sie haben nicht vorher. Ermöglichen Sie dem Benutzer ähnlich wie bei GMail auch, anzuzeigen, wo er sich kürzlich angemeldet hat.

Bearbeiten, neue Idee:

Eine andere Möglichkeit, Anmeldeversuche zu überprüfen, besteht darin, zu überprüfen, ob der Benutzer von Ihrer Anmeldeseite stammt oder nicht. Sie können Überweiser nicht überprüfen, da sie leicht gefälscht werden können. Sie müssen einen Schlüssel in der Variablen _SESSION festlegen, wenn der Benutzer die Anmeldeseite anzeigt, und dann überprüfen, ob der Schlüssel vorhanden ist, wenn er seine Anmeldeinformationen übermittelt. Wenn der Bot nicht von der Anmeldeseite sendet, kann er sich nicht anmelden. Sie können dies auch vereinfachen, indem Sie Javascript in den Prozess einbeziehen, indem Sie es entweder zum Setzen eines Cookies verwenden oder dem Formular nach dem Laden einige Informationen hinzufügen. Oder Sie können das Formular in zwei verschiedene Übermittlungen aufteilen (dh der Benutzer gibt seinen Benutzernamen ein, übermittelt, gibt dann auf einer neuen Seite sein Passwort ein und sendet es erneut.)

Der Schlüssel ist in diesem Fall der wichtigste Aspekt. Eine übliche Methode, um sie zu generieren, ist eine Kombination aus den Daten des Benutzers, seiner IP und der Zeit, zu der sie übermittelt wurden.

davethegr8
quelle
Ich bin mir sicher, dass mehr dahinter steckt, aber wenn die SiteKey-Idee genau das ist, was Sie erwähnt haben, muss ein Angreifer kein MITM sein, er kann nur zwei oder drei Anmeldeversuche für diesen Benutzer ausführen und das Bild auswählen, das wiederholt sich unter den zufälligen. Auch wenn der Satz von 8-15 Bildern für Benutzer X statisch ist,
Jens Roland
(Fortsetzung) Es wäre wahrscheinlich nicht allzu schwierig, das richtige auszuwählen, da die Leute dazu neigen, vorhersehbare Bildtypen auszuwählen (sogar Bilder aus ihren eigenen Flickr-Alben!)
Jens Roland
2
Ja, ich dachte an den Punkt, den du letzte Nacht angesprochen hast, nachdem ich nach Hause gegangen war. Ich denke, der Weg, dies zu beheben, ist: Wenn sich ein Benutzer anmeldet und ein korrektes Passwort angibt, zeigen Sie sein Bild und einige andere zufällige an. Wenn sie nicht das richtige Passwort
angeben
1
Bilder + 1, die möglicherweise ein eigenes Bild enthalten oder nicht. Außerdem hatte ich eine andere Idee, siehe die Bearbeitung im Beitrag. Aber ja, diese Ideen sind etwas schwierig / kompliziert.
davethegr8
1
Das "könnte" funktionieren, aber ich sehe ein paar Probleme. Was passiert, wenn der Fotobesitzer das Bild entfernt? Wie können Sie sicher sein, dass zurückgegebene Bilder Ihren Benutzer nicht beleidigen? Wie erinnert sich ein Benutzer, wo er geklickt hat? (Es scheint schwer zu vergessen)
davethegr8
7

Ich hatte vorher eine sehr ähnliche Frage über bei beantwortet Wie kann ich Benutzer - Login - Versuche in PHP drosseln . Ich werde die vorgeschlagene Lösung hier wiederholen, da ich glaube, dass viele von Ihnen es informativ und nützlich finden werden, einen tatsächlichen Code zu sehen. Bitte beachten Sie, dass die Verwendung eines CAPTCHA aufgrund der immer genaueren Algorithmen, die heutzutage in CAPTCHA-Bustern verwendet werden, möglicherweise nicht die beste Lösung ist:

Sie können DoS-Angriffe nicht einfach verhindern, indem Sie die Drosselung auf eine einzelne IP oder einen Benutzernamen verketten. Zum Teufel, mit dieser Methode können Sie schnelle Anmeldeversuche nicht wirklich verhindern.

Warum? Weil der Angriff mehrere IPs und Benutzerkonten umfassen kann, um Ihre Drosselungsversuche zu umgehen.

Ich habe an anderer Stelle gesehen, dass Sie im Idealfall alle fehlgeschlagenen Anmeldeversuche auf der Website verfolgen und sie möglicherweise einem Zeitstempel zuordnen sollten:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Entscheiden Sie sich für bestimmte Verzögerungen basierend auf der Gesamtzahl der fehlgeschlagenen Anmeldungen in einer bestimmten Höhe der Zeit. Sie sollten dies auf statistischen Daten basieren, die aus Ihrer failed_loginsTabelle abgerufen werden, da sie sich im Laufe der Zeit ändern, basierend auf der Anzahl der Benutzer und der Anzahl der Benutzer, die ihr Kennwort abrufen (und eingeben) können.


10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Fragen Sie die Tabelle bei jedem fehlgeschlagenen Anmeldeversuch ab, um die Anzahl der fehlgeschlagenen Anmeldungen für einen bestimmten Zeitraum zu ermitteln, z. B. 15 Minuten:


SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Wenn die Anzahl der Versuche über den angegebenen Zeitraum Ihr Limit überschreitet, erzwingen Sie entweder die Drosselung oder zwingen Sie alle Benutzer, ein Captcha (dh reCaptcha) zu verwenden, bis die Anzahl der fehlgeschlagenen Versuche über den angegebenen Zeitraum unter dem Schwellenwert liegt.

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Die Verwendung von reCaptcha bei einem bestimmten Schwellenwert würde sicherstellen, dass ein Angriff von mehreren Seiten minimiert wird und normale Site-Benutzer keine signifikante Verzögerung für legitime fehlgeschlagene Anmeldeversuche erfahren. Ich kann keine Prävention garantieren, da bereits erweitert wurde, dass CAPTCHAs kaputt gehen können. Es gibt alternative Lösungen, vielleicht eine Variante von "Name this animal", die als Ersatz recht gut funktionieren könnte.

Corey Ballou
quelle
6

Ich muss fragen, ob Sie eine Kosten-Nutzen-Analyse dieses Problems durchgeführt haben. Es hört sich so an, als würden Sie versuchen, sich vor einem Angreifer zu schützen, der über genügend Webpräsenz verfügt, um eine Reihe von Passwörtern zu erraten, und möglicherweise 3-5 Anforderungen pro IP senden (da Sie die IP-Drosselung abgelehnt haben). Wie viel (ungefähr) würde diese Art von Angriff kosten? Ist es teurer als der Wert der Konten, die Sie schützen möchten? Wie viele gigantische Botnetze wollen, was Sie haben?

Die Antwort könnte nein sein - aber wenn ja, hoffe ich, dass Sie Hilfe von einem Sicherheitsexperten erhalten. Programmierkenntnisse (und StackOverflow-Punktzahl) korrelieren nicht stark mit dem Sicherheits-Know-how.

ojrac
quelle
(Sie wollen sagen, wenn die Antwort "Nein" lautet - dh dass die Kosten eines Botnet-Angriffs im Verhältnis zu den Konten NICHT zu hoch sind)
Jens Roland
Aber trotzdem sprechen Sie einen wichtigen Punkt an. Für meine eigenen Zwecke erwarte ich nicht, dass sich ein Botnetzbetreiber im geringsten darum kümmert, aber ich veröffentliche den Quellcode für alle, die angemessene Sicherheit für ihre Web-App wünschen, und ich kann nicht wissen, was andere versuchen könnten schützen, oder wer ihre Feinde sind
Jens Roland
Es wird keine nationalen Geheimnisse schützen, egal was passiert (offizielle Systeme benötigen eine spezielle Zertifizierung, und ich bin mir ziemlich sicher, dass nichts, was auf PHP basiert, qualifiziert werden kann), aber alle Webanwendungen benötigen eine sichere Authentifizierung. Wenn ich dies veröffentliche, ist es ' Es wäre unglaublich verantwortungslos, keine Best Practices zu verwenden, wo immer ich kann
Jens Roland
1
Meine kurze Antwort lautet also: Ich baue dies, weil 99,9% der Websites und Apps eine entsetzliche Sicherheit bieten (selbst in den großen Ligen: AOL, Twitter und Myspace wurden bereits zuvor kompromittiert) und in den meisten Fällen, weil sie es sind mit schlampigen Auth-Bibliotheken.
Jens Roland
Lesen Sie auch das Papier "To Catch A Predator" von Niels Provos et al. aus dem USENIX-Verfahren 2008 (Link: usenix.org/events/sec08/tech/small.html ) Es ist ein Augenöffner: 2 Monate, ein Honeypot: 368.000 Angriffe von fast 30.000 verschiedenen IPs, die von mehr als 5.600 Botnetzen stammen!
Jens Roland
5

Um Jens 'Schema in einem Pseudo-Zustandsübergangsdiagramm / einer Regelbasis zusammenzufassen:

  1. Benutzer + Passwort -> Eintrag
  2. Benutzer +! Passwort -> verweigert
  3. Benutzer + bekanntes_IP (Benutzer) -> Haustür, // never throttle
  4. user + unknown_IP (user) -> catflap
  5. (#denied> n) über Catflaps (Site) -> Catflaps (Site) drosseln // slow the bots
  6. Catflap + Gas + Passwort + Captcha -> Eintrag // humans still welcome
  7. Catflap + Gas + Passwort +! Captcha -> verweigert // a correct guess from a bot

Beobachtungen:

  • Drosseln Sie niemals die Vordertür. Die elbonische Staatspolizei hat Ihren Computer in Ihrem Haus, kann Sie jedoch nicht verhören. Brute Force ist ein praktikabler Ansatz von Ihrem Computer aus.
  • Wenn Sie ein "Passwort vergessen?" Link, dann wird Ihr E-Mail-Konto Teil der Angriffsfläche.

Diese Beobachtungen decken eine andere Art von Angriff ab als die, denen Sie entgegenwirken möchten.

Jamesh
quelle
Absolut das E-Mail-Konto ist Teil der Angriffsfläche. Ich habe eine Reihe von Obergrenzen für die Sicherheit, die meine Strategie bietet, und die Untergrenze ist die E-Mail-Sicherheit des Benutzers. Wenn ein Angreifer gegen die E-Mail-Adresse eines Benutzers verstößt, sind alle Wetten ungültig.
Jens Roland
Ich denke auch, dass Ihr Zustandsübergangsdiagramm einige Details benötigt: # 3 und # 4 sollten ein Passwort enthalten; # 1 und # 2 sollten unknown_IP (Benutzer) enthalten, da ein Login immer entweder eine bekannte oder eine unbekannte IP hat. und # 6 ist "Eintrag trotz Gas"
Jens Roland
4

Sieht so aus, als würden Sie versuchen, sich gegen langsam verteilte rohe Gewalt zu verteidigen . Nicht so viel kann man dagegen tun. Wir verwenden eine PKI und keine Passwort-Logins. Es hilft, aber wenn Ihre Kunden gelegentlich zufällige Workstations haben, ist dies nicht sehr zutreffend.

Björn Raupach
quelle
Eigentlich auch schnelle Brute Force. Ich hatte gehofft, mit Brute Force mit festem Benutzer (Drosselung nur 20 Sekunden) etwas nachsichtig zu sein, aber auf einer Site mit 50.000 Benutzern würde dies eine schnelle Brute Force mit variablem Benutzer ermöglichen (unter der Annahme, dass mehr als 20 Sekunden durch die Benutzer laufen). Und das, wie sie sagen, würde saugen ..
Jens Roland
Nun, schnelle Brute Force von einem einzelnen Host verwendet Iptables oder eine andere Firewall, die Sie verwenden.
Björn Raupach
Ich bezog mich auf verteilte schnelle rohe Gewalt. Es ist selten, aber es ist möglicherweise sehr böse
Jens Roland
3

Haftungsausschluss: Ich arbeite für ein Zwei-Faktor-Unternehmen, bin aber nicht hier, um es anzuschließen. Hier sind einige Beobachtungen.

Cookies können mit XSS- und Browser-Vulns gestohlen werden. Benutzer wechseln häufig den Browser oder löschen ihre Cookies.

Quell-IP-Adressen sind gleichzeitig dynamisch variabel und fälschbar.

Captcha ist nützlich, authentifiziert jedoch keinen bestimmten Menschen.

Mehrere Methoden können erfolgreich kombiniert werden, aber ein guter Geschmack ist sicherlich angebracht.

Die Komplexität der Passwörter ist gut. Alles, was auf Passwörtern basiert, hängt entscheidend von Passwörtern mit ausreichender Entropie ab. Meiner Meinung nach ist ein sicheres Passwort, das an einem sicheren physischen Ort notiert ist, besser als ein schwaches Passwort im Speicher. Menschen wissen, wie sie die Sicherheit von Papierdokumenten viel besser bewerten können, als wie sie die effektive Entropie im Namen ihres Hundes ermitteln können, wenn sie als Passwort für drei verschiedene Websites verwendet werden. Erwägen Sie, Benutzern die Möglichkeit zu geben, eine große oder kleine Seite mit einmaligen Passcodes auszudrucken.

Sicherheitsfragen wie "Was war dein Highschool-Maskottchen?" Sind meistens eine andere miese Form von "etwas, das du weißt". Die meisten von ihnen sind leicht zu erraten oder direkt öffentlich zugänglich.

Wie Sie bereits bemerkt haben, ist das Drosseln fehlgeschlagener Anmeldeversuche ein Kompromiss zwischen der Verhinderung von Brute-Force-Angriffen und der einfachen Durchführung eines Kontos. Aggressive Sperrrichtlinien können ein mangelndes Vertrauen in die Kennwortentropie widerspiegeln.

Ich persönlich sehe den Vorteil der Durchsetzung des Passwortablaufs auf einer Website sowieso nicht. Der Angreifer erhält Ihr Passwort einmal, kann es dann ändern und diese Richtlinie genauso einfach wie möglich einhalten. Möglicherweise besteht ein Vorteil darin, dass der Benutzer dies möglicherweise früher bemerkt, wenn der Angreifer das Kontokennwort ändert. Noch besser wäre es, wenn der Benutzer irgendwie benachrichtigt würde, bevor der Angreifer Zugriff erhält. Nachrichten wie "N fehlgeschlagene Versuche seit der letzten Anmeldung" sind in dieser Hinsicht nützlich.

Die beste Sicherheit ergibt sich aus einem zweiten Authentifizierungsfaktor, der im Vergleich zum ersten außerhalb des Bandes liegt. Wie Sie sagten, sind Hardware-Token in "etwas, das Sie haben" großartig, aber viele (nicht alle) haben einen echten Verwaltungsaufwand, der mit ihrer Verteilung verbunden ist. Ich kenne keine biometrischen "Something You Are" -Lösungen, die für Websites gut sind. Einige Zwei-Faktor-Lösungen funktionieren mit OpenID-Anbietern, andere verfügen über PHP / Perl / Python-SDKs.

Marsh Ray
quelle
Alles hervorragende Punkte - mehr kann ich nicht sagen. Der Punkt über die Unsicherheit von Cookies ist sehr gültig, aber ohne einen zweiten Faktor für physische Token oder Einmalkennwörter (verteilt über eine sichere Leitung) können Sie sich wirklich nicht vor einem anfälligen Endpunkt schützen. Wenn die Box / der Browser des Benutzers gefährdet ist, sind auch seine Anmeldungen gefährdet.
Jens Roland
1

Meine höchste Empfehlung ist es, einfach sicherzustellen, dass Sie Benutzer über schlechte Anmeldeversuche in ihren Konten auf dem Laufenden halten. Benutzer werden die Stärke ihres Passworts wahrscheinlich viel ernster nehmen, wenn ihnen Beweise dafür vorgelegt werden, dass tatsächlich jemand versucht, in ihr Konto zu gelangen .

Ich habe tatsächlich jemanden erwischt, der sich in das MySpace-Konto meines Bruders gehackt hat, weil er versucht hat, in das für ihn eingerichtete Google Mail-Konto zu gelangen, und die Funktion "Passwort per E-Mail zurücksetzen" verwendet hat, die in meinen Posteingang ging.

nvuono
quelle
1
  1. Wie wäre es, wenn Sie ein Einmalpasswort benötigen, bevor Sie Ihr normales Passwort eingeben? Das würde es sehr offensichtlich machen, dass jemand angegriffen hat, bevor er viele Möglichkeiten hatte, das Hauptpasswort zu erraten?

  2. Behalten Sie eine globale Anzahl / Rate von Anmeldefehlern bei - dies ist der Indikator für einen Angriff - während eines Angriffs sollten Sie Anmeldefehler strenger behandeln, z. B. IPs schneller verbieten.

Douglas Leeder
quelle
1) Wie würden Sie ein Einmalkennwort in einer unsicheren, nicht authentifizierten Leitung implementieren? Mit anderen Worten, wann legt der Benutzer diese Einmalkennwörter fest? 2) Ja, das ist der Kern von # 4 auf meiner Liste, das landesweite Limit für fehlgeschlagene Versuche. Der Nachteil ist die DoS-Gelegenheit, die es eröffnet.
Jens Roland
0

Ich glaube nicht, dass es eine perfekte Antwort gibt, aber ich würde mich gerne nähern, um zu versuchen, die Roboter zu verwirren, wenn ein Angriff wahrgenommen wird.

Aus dem Kopf:

Wechseln Sie zu einem alternativen Anmeldebildschirm. Es gibt mehrere Leerzeichen für Benutzernamen und Kennwörter, die tatsächlich angezeigt werden, aber nur eines davon befindet sich am richtigen Ort. Die Feldnamen sind RANDOM --a Sitzungsschlüssel zusammen mit dem Anmeldebildschirm gesendet wird, kann der Server dann herausfinden, welche Felder sind was. Erfolgreich oder fehlgeschlagen wird dann verworfen, sodass Sie keinen Wiederholungsangriff versuchen können. Wenn Sie das Kennwort ablehnen, erhalten sie eine neue Sitzungs-ID.

Es wird angenommen, dass jedes Formular, das mit Daten in einem falschen Feld gesendet wird, von einem Roboter stammt - die Anmeldung schlägt fehl, Punkt, und diese IP wird gedrosselt. Stellen Sie sicher, dass die zufälligen Feldnamen niemals mit den legitimen Feldnamen übereinstimmen, damit jemand, der sich Kennwörter merkt, nicht irreführt.

Als nächstes wie wäre es mit einer anderen Art von Captcha: Sie haben eine Reihe von Fragen, die für einen Menschen keine Probleme verursachen. Sie sind jedoch NICHT zufällig. Wenn der Angriff beginnt, erhält jeder die Frage Nr. 1. Nach einer Stunde wird Frage 1 verworfen, um nie wieder verwendet zu werden, und jeder erhält Frage 2 und so weiter.

Der Angreifer kann die Datenbank nicht herunterladen, um sie in seinen Roboter zu laden, da die Fragen verfügbar sind. Er muss innerhalb einer Stunde neue Anweisungen an sein Botnetz senden, um irgendetwas tun zu können.

Loren Pechtel
quelle
Der alternative Anmeldebildschirm klingt so, als würde er Menschen ehrlich gesagt mehr verwirren als Maschinen. Wir gehen natürlich davon aus, dass der Angreifer unsere Sicherheitsmaßnahmen vorher überprüft hätte. Er hätte seinen Schaber leicht optimieren können, um die richtig platzierten Felder zu finden.
Jens Roland
Die Fragen zur Überprüfung des Menschen wurden bereits zuvor gestellt und sind nicht sehr effektiv. Für einen menschlichen Botnetzbetreiber wäre es durchaus machbar, während eines Angriffs eine Frage pro Stunde zu beantworten (wonach sich die neue Antwort auf die Bots ausbreiten würde).
Jens Roland
Sie verpassen den Punkt. Der Angreifer kann dies nicht im Voraus überprüfen, da die zusätzlichen Verteidigungen nur angezeigt werden, wenn ein Angriff auftritt.
Loren Pechtel
Sicher, der Mensch konnte sehen, was die Frage war - aber er muss das allen seinen Bots mitteilen. Dies ist ein Kommunikationspfad, der es einfacher macht, das Botnetz herunterzufahren.
Loren Pechtel
Ich glaube nicht, dass mir der Punkt fehlt. Ich meine nicht, dass er zuvor einen Angriff ausgeführt hätte, um unsere Sicherheitsmaßnahmen zu überprüfen. Ich meine, er hätte diesen Thread gelesen und den (offenen) Quellcode überprüft, um nach Weknesses zu suchen :)
Jens Roland
0

Da einige Leute CAPTCHA als menschlichen Fallback-Mechanismus aufgenommen haben, füge ich eine frühere StackOverflow-Frage und einen Thread zur Wirksamkeit von CAPTCHA hinzu.

Wurde reCaptcha geknackt / gehackt / OCR / besiegt / gebrochen?

Die Verwendung von CAPTCHA schränkt die Verbesserungen Ihrer Drosselung und anderer Vorschläge nicht ein, aber ich denke, die Anzahl der Antworten, die CAPTCHA als Ersatz enthalten, sollte die menschenbasierten Methoden berücksichtigen, die Personen zur Verfügung stehen, die die Sicherheit verletzen möchten.

Matthew Glidden
quelle
0

Sie können auch basierend auf der Stärke eines Benutzerkennworts drosseln.

Wenn ein Benutzer sein Passwort registriert oder ändert, berechnen Sie eine Stärkebewertung für sein Passwort, beispielsweise zwischen 1 und 10.

So etwas wie "Passwort" erhält eine 1, während "c6eqapRepe7et * Awr @ ch" eine 9 oder 10 erzielt. Je höher die Punktzahl, desto länger dauert es, bis die Drosselung einsetzt.

Joseph W.
quelle
2
Ich verstehe die Idee, aber das würde indirekt Informationen über das Passwort verlieren und einen Angreifer wissen lassen, ob ein Passwort einen Hack wert ist oder nicht. Das mag ein bisschen theoretisch erscheinen, aber viele Benutzer verwenden Passwörter wieder. Wenn ich also in Strong_Throttling_Website.com einbrechen möchte, kann ich einfach (privilegierte) Konten nach dem Zufallsprinzip angreifen, bis ich einen Benutzer finde, 'Freddy', der ein schwaches Passwort hat (dh frühes Drosseln), gehen Sie dann zu Less_Secure_Website.edu und führen Sie dort einen einfachen Wörterbuchangriff auf Freddys Konto durch. Es ist ein wenig kompliziert, aber in der Praxis durchaus machbar.
Jens Roland
0

Die erste Antwort, die ich normalerweise gehört habe, wenn ich diese Frage stelle, ist, die Ports zu wechseln, aber vergessen Sie das und deaktivieren Sie einfach IPv4. Wenn Sie nur Clients aus IPv6-Netzwerken zulassen, beten Sie nicht mehr für einfaches Netzwerk-Scannen, und Angreifer greifen auf DNS-Lookups zurück. Laufen Sie nicht unter derselben Adresse wie Ihr Apache (AAAA) / Sendmail (MX-> AAAA) / was Sie an alle weitergegeben haben (AAAA). Stellen Sie sicher, dass Ihre Zone nicht xferd sein kann. Warten Sie, bis Ihre Zone von irgendjemandem heruntergeladen werden kann.

Wenn die Bots feststellen, dass Ihr Server neue Hostnamen eingerichtet hat, stellen Sie Ihren Hostnamen einfach etwas Kauderwelsch voran und ändern Sie Ihre Adresse. Lassen Sie die alten Namen und richten Sie sogar ** Honeypot-Namen ein, damit das Bot-Netz eine Zeitüberschreitung aufweist.

** Testen Sie Ihre Reverse (PTR) -Datensätze (unter ip6.arpa.), Um festzustellen, ob sie verwendet werden können, um Ein / 4 mit Datensätzen gegen VS / 4s auf Null zu setzen, die dies nicht tun. IE Normalerweise hat ip6.arpa ~ 32 "." S in einer Adresse, aber wenn Sie versuchen, die letzten paar fehlenden zu verwenden, können Sie sich den Netzwerkblöcken entziehen, die Datensätze enthalten, im Vergleich zu anderen, die dies nicht tun. Wenn Sie dies weiter verfolgen, können Sie große Teile des Adressraums überspringen.

Im schlimmsten Fall müssen Benutzer einen IPv6-Tunnel einrichten. Es ist jedoch nicht so, als müssten sie bis zum VPN in eine DMZ gehen ... Obwohl man sich fragt, warum dies nicht die erste Option ist.

Auch Kerberos ist cool, aber IMHO LDAP bläst (Was ist technisch falsch mit NISPlus? Ich habe gelesen, dass Sun entschieden hat, dass Benutzer LDAP wollten und aus diesem Grund NIS + fallen ließen). Kerberos funktioniert ohne LDAP oder NIS einwandfrei. Sie müssen Benutzer nur Host für Host verwalten. Mit Kerberos erhalten Sie eine einfach zu verwendende, wenn nicht automatisierte PKI.

Mike Mestnik
quelle
0

Etwas spät hier, aber ich dachte, ich nehme einen schwierigen Fall an - der Angreifer verwendet viele zufällige IPs, zufällige Benutzernamen und ein zufälliges Passwort, das beispielsweise aus einer Liste der 10.000 beliebtesten ausgewählt wurde.

Eine Sache, die Sie tun könnten, insbesondere wenn das System angegriffen zu werden scheint, weil es viele falsche Passwortversuche auf dem System gibt, und insbesondere wenn das Passwort eine niedrige Entropie aufweist, besteht darin, eine sekundäre Frage zu stellen, wie zum Beispiel die Vornamen Ihrer Eltern . Wenn ein Angreifer eine Million Konten trifft, die das Passwort 'password1' versuchen, besteht eine gute Chance, dass er viel bekommt, aber seine Chancen, auch die Namen richtig zu machen, würden die Erfolge dramatisch reduzieren.

Tim 333
quelle