Login Script

[Beat]

Ist es nicht so, dass du mit deiner Methode ja gar nicht darauf angewiesen bist, ob ich nun schlafe oder nicht?

Doch, Dein sleep() macht mir den Angriff wesentlich leichter. Wenn ich Dir mit falschem Input komme, blockiert Dein Prozess für 5 Sekunden einen Prozess bzw. Thread. Antwortest Du dagegen sofort, ist der Prozess wieder frei und ich muß mir wesentlich mehr Mühe geben, Deinen Server zu blockieren.

na also , anderer Vorschlag:
Voraussetzung im Script: Ein Loginversuch ist nur auf der Basis einer existierenden sid-rid möglich.

Der Aufwand dazu ist in meiner Architektur eine Zeile Code.

Was bedingt das für deinen Angriff?
Damit du einen Angriff auf mein Script starten kannst, muss du dir zuerst eine sid-rid holen.
Das heisst an diesem Punkt darfst du den Output nicht mehr vernachlässigen:
Fakt: sid-rid ist eine One-Time ID.

Aber ich gebe dir recht, insofern, dass ich dich zu einem billigen Angriff verleite.
Nun aber die Frage nach dem geeigneten Rezept. Du machst eine Wörterbuchattacke. Ich schlafe nicht. Irgendwo gibt es auf jeden Fall einen Flaschenhals (Stichwort Filelocking)

Wozu brauchst Du Filelocking bei einem Login? OK, wenn Du auf Krampf ein RDBMS vermeiden willst und stattdessen das Rad neu erfindest, wäre ein Lock hilfreich. Weder für SELECT ... FROM users WHERE name=? AND matchPassword(pwhash,?)=true noch für INSERT INTO sessions ... brauchst Du file locking. Und mit einer persistenten DB-Connection gibt es auch kein langsames, aufwendiges Connect für jeden Login-Versuch. Ganz im Gegenteil, die notwendigen SQL-Statements können gecacht werden und sind dann rattenschnell.

Den kurz abgehandelt: No SQL... no PHP ;)

Was ich tun kann ist, abfragen gegen das Loggin Formular kontrollieren.
Nun logge ich. Ich logge IPs. Du sendest mir immer eine neue IP. Du hast so ziemlich viele Testmöglichkeiten, ohne dass ich mit dem Loggen irgenwo hin komme.
Indem ich allgemein unabhängig von der IP schlafe, verhindere ich das was ich kann: Angriffe gegen das Login Formular.
Andere Angriffsmöglichkeiten kann ich nicht abwehren.

Du kannst versuchen, mir den DoS so schwer wie möglich zu machen, in dem Du möglichst schnell entscheidest, dass ein Request durch einen Angriff und nicht durch einen schusseligen Benutzer zustande gekommen ist.

Diese Analyse bedingt das Loggen und analysieren mehrerer Requests.
Das kann sich reduzieren, wenn es nur bei Login oder anderen Authentifizierungs-Aufgaben betreiben wird.
Die Frage ist nur, welche Information verwerte ich? Wenn ich zum Schluss komme, dass der Angriff sich nicht auf IPs einschränken lässt, dann sind wir wieder am gleichen Punkt.

OK Meistens ist die zahl der IPs irgendwo schon beschränkt und ich habe da auch mal einen Logger geschrieben, welcher IP/16 und IP/24 Bereiche in eine Queue schiebt und andere wieder befreit. Aber auc damit machst du mir den laden dicht.
Wenn ich diese Queue regelmässig lösche, ist das auch das selbe wie dein folgendes Szenario.

Gut, ich überlege mir eine andere Variante. Den Selbstmord:
Nach so und so vielen Versuchen macht das Script via .htaccess den Laden dicht und deaktiviert sich selbst. Ich muss es dann explizit wieder starten.

Juchu! 10.000 Requests und Dein Server ist dauerhaft tot, bis Du ihn explizit wieder reanimierst. Rate mal, wie ich Dich dann in Pippi-Langstrumpf-Socken bekomme:

Wir haben uns noch nicht darüber unterhalten wann und wie ich den Laden dicht mache, bis zu deinem sleep(3)

pseudo-perl, parallel auf ein paar Maschinen

while (!$beat->wearsLangstrumpfSocks()) {
    if (post($login_url,{ name => random_string(), password => random_string() })!=HTTP_OK) {

Willst du mir jetzt Socken andrehen, oder pws hacken?
Nach obiger Ergänzung wird deine Aufgabe etwas schwieriger.
Setze einen normalen Request ab, Lese die sid-rid aus dem Content aus und sende sie zusammen mit den erforderlichen Feldern.

dein !=HTTP_OK könnte ich ganz schön narren.

# noch tot
        sleep(30);

Danke, danke, 30 Sekunden Lebensfrist... im besten Fall.

} else {
        # bald tot
        for (1..1e6) {
            last if post($login_url,{ name => random_string(), password => random_string() })!=HTTP_OK; # schlage keinen toten Gaul ... ;-)

Warum denn nicht? Ich habe schon genug, die es versuchen.

Ein script dass so viele Requests absetzt ist ziemlich auffällig, auch wenn du es auf das absolut notwendigste zu reduzieren vermagst.
Gut, du kannst das von deinem Badewannenserver aus machen. Hoffentlich badest du schnell.

Nehmen wir das revidierte Szenario, wonach du zuerst die sid-rid erhalten musst. Damit muss bei dir ein einzelner Prozess länger am Leben sein als mein Scriptzyklus. Willst du deinen Angriff von einem einzigen Server aus starten.

Das eröffnet dann die Frage, wer wird eigentlich gebremmst?

}
        # sehr wahrscheinlich tot, spätestens nach ein paar Runden durch die while-Schleife
    }
}

>   
> Das starte ich und warte ab, bis Dir der Kaffee oder die Geduld beim minütlichen Reanimieren des Servers ausgeht. Deine Kunden sehen währenddessen nahezu komplett in die Röhre, es sei denn, sie greifen während meines sleep(30) auf den frisch reanimierten Server zu.  
  
Ok ich erspare dir den Rewrite nach der obigen Ergänzung. Er wird nicht sonderlich schwer sein. Du wirst dich aber den typischen Bot-Netz Strategien nähern müssen. Ich zweifle nicht dass kleiner Botnetze auch mal kostenlos zu haben sind. Grössere hingegen werden dich dann etwas kosten.  
  
mfg Beat

-- 

><o(((°>           ><o(((°>  

   <°)))o><                     ><o(((°>o