Zugriffsbeschränkung - Aussperren von Usern?

Ich würde gerne mal Ideen sammeln, wie man effektiv "User" vom System aussperren kann, die bsw. auf einen Account versuchen zuzugreifen mit zig mal falschem Passwort, denn alle Methoden per Session Zugriffssperre, Cookies, IP, usw. können ja umgangen werden. Gibt es eine Möglichkeit einen User, der sich bsw. 5x "falsch" einloggt für eine bestimmte Zeit zu sperren ohne den Account zu sperren? (D.h. nur diesen PC.)

[onemorenerd]

Re: Zugriffsbeschränkung - Aussperren von Usern?

Original geschrieben von hasch
(D.h. nur diesen PC.)

Das ist der Knackpunkt, du willst einen (entfernten) Rechner blocken, keinen User. Entfernte Rechner identifizieren sich im Netz durch IP-Nummer und MAC-Adresse.
Sperrst du diese, ist der Angriff abgewehrt.

Die Frage ist aber nicht, wie man blockiert, sondern wann. Woran erkennt man einen Angriff?
Ich gehe mal davon aus, dass du schon irgendwie merkst, dass da jemand versucht was zu knacken. Wie unterscheidet dein Server nun, ob es 10 mißglückte Logins von 10 verschiedenen Usern sind oder alle von ein und dem selben Deppen?

Die IP hilft dabei wenig - Stichwort dynamische IP, Reconnect. Aber auch die MAC kann der Benutzer des Rechners jederzeit ändern. Zuverlässiges Erkennen allein anhand von IP/MAC ist nicht möglich.

Aber der Benutzer kann nicht mal eben seinen Provider wechseln und hat meistens auch nur einen. Das kannst du nutzen, denn nach Ändern seiner MAC und einem Reconnect hängt der Rechner immernoch an der selben Strippe wie vorher, connected zum selben (Sub-)Netz des selben Providers. Dadurch ergeben sich gewissen Parallelen zur vorherigen Verbindung, die allerdings schwierig zu erfassen und nicht eindeutig verwertbar sind. Die - ich nenne es mal so - "Netzsignatur" kann als Indiz herhalten, mehr aber auch nicht.

Es gibt noch weitere Parallelen: Der Rechner wird ziemlich zeitnah nach dem du ihn geblockt hast oder er ungezwungen seine IP/MAC geändert hat, wieder auftauchen und das fortsetzen, was er angefangen hatte. Du erkennst ihn erstmal nicht eindeutig als den selben Rechner, aber die Art, wie er auf deine Seite losgeht, hat sich evtl. nicht geändert (z.B. weil es ein Script ist). Diese "Request-Signatur" ist natürlich auch kein eindeutiges und damit unzuverlässiges Erkennungsmerkmal.

Fazit: Es gibt imho keinen 100%igen Schutz, aber man kann es der Gegenseite sehr sehr schwer machen (in der Hoffnung, dass diese sich dann leichteren Opfern zuwendet).

Anmerkung: Sperre niemals ganze Subnetze, denk an die unschuldigen Nachbarn.

[hasch]

OK danke für deine Worte.
Das war ja mein Problem, dass man anhand der IP und Mac den User nicht eindeutig identifizieren kann.

Wäre denn der Check, ob der Referer die eigene Domain ist eine Sicherheit (oder kann man den auch fälschen?)?

[onemorenerd]

Ja, den kann man fälschen. Mit Request-Signatur meinte ich übrigens nicht nur den Inhalt bestimmter HTTP-Header sondern auch sowas wie die zeitliche Verteilung der Anfragen oder ob der selbe Host gerade auch andere Resourcen von deinem Server anfordert.

[hasch]

Ja danke. So habe ich deine Antwort auch aufgefasst gehabt

Ich habe jetzt ein kleines Script geschrieben, dass überprüft, ob eine IP vom Grundmuster (selber provider) mit dem gleichen Account schon in der Sperrliste ist und dementspreched wird dann seine Anfrage garnicht weiter bearbeitet. Ich danke dir für deine Hinweise.

[onemorenerd]

Was meinst du bitte mit "Grundmuster einer IP"?
Ich hoffe, du blockst trotzdem nur eine spezifische IP, kein ganzes Subnetz.

[hasch]

Nein, ich blocke kein Subnetz.
Ich habe mal bei mir getestet, in wiefern sich meine IP beim Reconnecten verändert. Die ersten beiden Blöcke bleiben gleich: 123.45.xxx.xxx demnach schaue ich in der Datenbank, ob dieser Rechner von dem Provider schon mehr als die erlaubte Anzahl (unmöglich über Webinterface den Status zu erreichen) Logins auf dem selben Account innerhalb einer bestimmten Sperrzeit verursacht hat.

Demnach besteht immer noch das Risiko, dass sich der echte User in dem Providernetz befindet, aber es wurde ja schon etwas gemindert.

Wenn ich aber so recht darüber nachdenke, hat dieser Methode wenig Sinn, denn wenn der "Hacker" intelligent ist, surft er ja über Proxies.

[onemorenerd]

"Schlaue" Hacker geben aber auch nicht dutzende bis tausende Passwörter manuell ein. Sie benutzen Scripte, die alle möglichen Passwörter generieren oder aus einem Dictionary durchprobieren. Die besseren dieser Brute Force Tools warten eine zufällig gewählte Zeitspanne zwischen zwei Versuchen, die meisten aber nicht. Dadurch ergibt sich bis auf die netzüblichen Latenzen ein regelmäßiges Muster. D.h. zwischen einer und der nächsten Anfrage vergeht immer ungefähr gleich viel Zeit. Imho ein guter Anhaltspunkt, um auf einen Angriff zu schließen, denn ein Mensch wird sich erstmal wundern, überlegen, warum sein Passwort nicht akzeptiert wurde und erneut tippen. Das dauert. Ein Script läßt sich sicher nicht so viel Zeit bis zum nächsten Versuch, denn dann würde es Jahre brauchen.

[jmc]

Original geschrieben von hasch
Nein, ich blocke kein Subnetz.
Ich habe mal bei mir getestet, in wiefern sich meine IP beim Reconnecten verändert. Die ersten beiden Blöcke bleiben gleich: 123.45.xxx.xxx demnach schaue ich in der Datenbank, ob dieser Rechner von dem Provider schon mehr als die erlaubte Anzahl (unmöglich über Webinterface den Status zu erreichen) Logins auf dem selben Account innerhalb einer bestimmten Sperrzeit verursacht hat.

Wie ich unterdessen leider lernen musste kannst du deine IP auch ziemlich einfach verändern nud sogar falsche schicken oder dafür sorgen, dass mit remote_addr sogar gar keine angezeigt wird.

[hasch]

Ein Script läßt sich sicher nicht so viel Zeit bis zum nächsten Versuch, denn dann würde es Jahre brauchen. [/B]

Danke, werde ich mit berücksichtigen. Es ist aber nicht möglich, dass ein Script verwendet wird, da ein spezieller Code für die Session in der DB gespeichert wird und nur wenn dieser korrekt mitgesendet wird geht es, habe es selbst probiert, somit sollten Scripts erhebliche Schwierigkeiten bekommen.

[jmc]

Wie machst du dies genau und warum kann man den mit einem Script nicht mitschicken?

[hasch]

Beim Aufruf wird ein Code generiert vom Server und zusammen mit der session id in der Datenbank abgelegt. Beim Login wird anhand der Session-ID überprüft, ob der mitgesendte Code dem in der DB entspricht, ansonsten Abbruch (mit mehreren Teilfunktionen ob Session in DB usw.)... da das Login-System sowieso nur für Cookie-akzeptierte User zugänglich ist, scheint mir dies eine ziemlich sichere Methode, bzw. eine Erschwerung des Angriffes.

Am Ende (beim Loginversuch - egal ob Erfolg oder Misserfolg wird der Datenbankeintrag gelöscht, d.h. ein Reload nötig - somit auch kein mehrfaches Senden mit gleichem Code möglich.)

[3DMax]

Re: Re: Zugriffsbeschränkung - Aussperren von Usern?

Original geschrieben von onemorenerd Aber auch die MAC kann der Benutzer des Rechners jederzeit ändern.

seit wann kommt denn die mac des benutzerrechners beim webserver an? ich denke, das ist die mac des letzten routers.

oder wie meintest du das?

[the_wh0]

Original geschrieben von hasch
Beim Aufruf wird ein Code generiert vom Server und zusammen mit der session id in der Datenbank abgelegt. Beim Login wird anhand der Session-ID überprüft, ob der mitgesendte Code dem in der DB entspricht, ansonsten Abbruch (mit mehreren Teilfunktionen ob Session in DB usw.)...

das ist aber auch nicht unbedingt sicher. der "hacker" kann ja den code den er sich vorher durch einen seitenaufruf geholt hat, einfach per post oder get mitschicken und dann scheint der request auch wieder gültig.

[hasch]

ja somit könnte er genau 1x einen Loginversuch starten.
Denn bei jedem Aufruf der Login-Date wird der DB Eintrag mit dem Code gelöscht und der Hacker müsste die Loginseite aktualisieren und dort den neuen Code nehmen.