Basic-Auth gegen Brute-Force schützen

[Andreas Korthaus]

Hallo!

Ich habe ein Admin-Verzeichnis, und ich möchte das gerne per .htaccess(Basic-Auth) schützen. Nur kenne ich hier keine Möglichkeit, dieses gegen Brute-Forece Angriffe zu schützen. Ich würde gerne 2 Dinge implementieren:

1. nach Eingabe falsche Zugangsdaten 5 Sekunden mit der Antwort warten
2. Nach x falschen Eingaben Account für eine Gewisse Zeit sperren.

Ich denke das lässt sich mit .htacess nicht realisieren, oder?
Ich müsste aber das ganze VErzeichnis schützen, weil ich einige Scripte in die ich nicht eingreifen will, und auch HTML im Verzeichnis verwende.

Wie würdet Ihr das realisieren?
Oder per Rewrite-Rule die alle Anfragen an ein PHP-Script leitet, welches did Authentifizierung durchführt so wie ich mir das vorstelle, und ggfs. per Location-Header weiterleitet?

Was gäbe es für Alternativen, auch unter dem Gesichtspunkt mögicher DOS-Angriffe? Denn ein PHP-Script ist ja schon eine ganz schöne Bremse. Hätte es Sinn statt dessen ein C-Script per CGI zu verwenden? Wobei ich eigentlich CGI deaktiviert habe, aber das ließe sich zur Not ändern. Das ganze läuft übrigens auf Linux mit Apache 1.3.

Oder vielleicht ein eigenes Apache-Modul schreiben? Aber davon habe ich Null Ahnung.

Grüße
Andreas

[Tom]

Hello,

das gleiche hätte ich gerne noch für ssh.

Beide Fragen habe ich vor über einem Jahr hier schon mal gestellt. Damals konnte auch keiner helfen. Würde mich freuen, wenn sich das geändert hätte. Ich weiß leider bis heute keine Lösdung dafür.

Grüße

Tom

[Andreas Korthaus]

Hi!

Beide Fragen habe ich vor über einem Jahr hier schon mal gestellt. Damals konnte auch keiner helfen. Würde mich freuen, wenn sich das geändert hätte. Ich weiß leider bis heute keine Lösdung dafür.

Hm, man könnte auch irgendein Programm schreiben, welches die Logfiles beobachtet, und wenn x Anfragen mit einem REMOTE_USER mit einem 401 beantwortet werden diesen User aus der Passwort-Tabelle temporär löschen. Das ist eigentlich schon das wichtigste. Nur - wie macht man das? Ich habe mal gehört dass man ein Programm schreiben kann welches sich irgendwie an die Logfiles "hängt", aber wie funktioniert das? Mir würden nur reichlich ineffiziente Wege einfallen so ein Logfile ständig zu beobachten. Man bräuchte einen Dämon-Prozess der automatisch die neuen Einträge bekommt, wie auch immer das aussieht, aber wie geht das? Also immer nur die geänderten Daten einlesen? Und das am besten automatisch und nicht alle paar Sekunden von alleine, oder?
Naja man könnte sich vielleicht die letzte Stelle merken wo letztesmal EOF war, und dann von da anfangen die Datei auszulesen, in PHP könnte da vielleicht fseek() helfen. Aber das Problem sind ja dann die konkurrierenden Zugriffe des Apachen, das heißt man müsste den FP wohl andauernd neu herstellen, Rest auslesen und wieder schließen. Und dann muss man aufpassen dass man sich nicht ohne Ende Daten in den RAM schaufelt, also am besten wohl immer Daten in einen String lesen, analysieren und am ende = '' setzen, oder?

Naja, wie würdet Ihr das machen, oder würdet Ihr ganz woanders ansezten?

Im Moment stelle ich mir sowas vor(kann es leider gerade nicht testen):
<?php
$last_position = 0;
while(TRUE) {
  $fp = fopen ('/path/to/error-log','r'); // 401 kommt glaube ich auch da rein, oder?
  fseek($fp, $last_position);
  while(($line = fgets($fp)) !== false) {
    check_auth($line); // was auch immer da gemacht wird
  }
  $last_position = ftell($fp);
  fclose($fp);
  sleep(10);
}
?>

Grüße
Andreas

[Tom]

Hello,

für das Anmelden auf einer Linux-Konsole gibt es eine eisntellbare Wartezeit bei Falscheingabe. Sowas muss es doch auch für die verbindungsorentierten Prozesse geben.

Bei Basic Auth sehe ich da eher schwarz. Da könnte man nur einen Handler drauflegen (vielleicht beitet der Apache dafür sogar einen Trigger) und zählen, wie oft innerhalb einer gewissen Zeit auf einen Usernamen zugegriffen wurde mit unterschiedlichem Passwort oder umgekehrt. Man könnte bestimmt auch einen Prozess in den Hintergrund legen, der die .htpasswd im Focus hat und jeden Zugriff piped.

Grüße

Tom

[Henryk Plötz]

Moin,

das gleiche hätte ich gerne noch für ssh.

Also für SSH ist das mit Linux nun gar kein Problem: http://www-uxsup.csx.cam.ac.uk/~pjb1008/project/pam_delay/pam_delay/pam_delay.html. Und wenn man http://pam.sourceforge.net/mod_auth_pam/ benutzt, hat man das gleich auch für den Apache.

[Dieter Raber]

Hallo Andreas,

wir hatten vor ein paar Tagen kurz die Rede von Deiner Beschaeftigung mit neuen Konzepten bezgl. PHP, wo Du auch eine Reihe Links gepostet hast. Leider finde ich den Thread nicht mehr, hast Du vielleicht noch die Thread-ID?

Danke und schoenen Abend noch.
Dieter

[Andreas Korthaus]

Hallo!

wir hatten vor ein paar Tagen kurz die Rede von Deiner Beschaeftigung mit neuen Konzepten bezgl. PHP, wo Du auch eine Reihe Links gepostet hast. Leider finde ich den Thread nicht mehr, hast Du vielleicht noch die Thread-ID?

Da habe ich leider zu lange gewartet mit dem antworten, dir wird gerade irgendwo ins Archiv unterwegs sein, von wegen Links

http://phparch.com/
http://phppatterns.com/
http://php.weblogs.com/

waren glaube ich die wichtigsten

Grüße
Andreas

[Dieter Raber]

Danke nochmal!
Dieter

[wahsaga]

hi,

Ich denke das lässt sich mit .htacess nicht realisieren, oder?

nein, aber HTTP AUTH ist ja nicht nur über .htaccess realisierbar.

über php und header() geht's ja auch.

du könntest also die zu schützenden dateien ausserhalb des webroots ablegen, und über eine php-script ausliefern.

dieses script überprüft dann auch die HTTP AUTH daten.
und damit hast du ja auch möglichkeiten, die loginversuche von bestimmten IP-adressen mitzuzählen, und ggf. nach x versuchen ganz auf verweigerung zu schalten o.ä.

gruss,
wahsaga

[Christian Seiler]

Hallo Andreas,

Oder vielleicht ein eigenes Apache-Modul schreiben?

Ja, das wäre das sinnigste.

Eine Verzögerung ist bei HTTP eigentlich Schwachsinn, wenn man gegen Brute-Force absichern will, da man einfach parallel eine neue Anfrage stellen kann und sich um die Verzögerung einen feuchten Dreck scheren kann. Daher würde ich Verzögerung lassen und lieber Benutzer für längere Zeit komplett sperren bei Brute Force.

Das Modul müsste halt irgendwo Protokoll führen über die letzten fehlgeschlagenen Einloggversuche. Und wenn nun wieder ein Versuch kommt und innerhalb der letzten x Minuten/Stunden/Tage y fehlgeschlagene Einloggversuche passiert sind, dann müsstest Du den Versuch von vornerein verweigern (am besten mit 403 statt 401), egal, ob dieser Erfolg hätte, oder nicht. (Achtung! Wenn Du nur erfolglose Versuche verweigerst, dann wäre Brute Force dennoch möglich, weil dann der Schutz komplett unnütz wäre!)

Viele Grüße,
Christian

[Henryk Plötz]

Moin,

Ich denke das lässt sich mit .htacess nicht realisieren, oder?

Was gäbe es für Alternativen, auch unter dem Gesichtspunkt mögicher DOS-Angriffe?

Wieso? Mit dem Lockout nach einigen Fehlversuchen hast du doch schon mehr als klar gemacht, dass du gerne geDoSt werden willst.

[Andreas Korthaus]

Hi Henryk!

Was gäbe es für Alternativen, auch unter dem Gesichtspunkt mögicher DOS-Angriffe?

Wieso? Mit dem Lockout nach einigen Fehlversuchen hast du doch schon mehr als klar gemacht, dass du gerne geDoSt werden willst.

Wie muss ich das verstehen? Von "wollen" kann keine Rede sein.
An Benutzernamen kommt man doch vermutlich erheblich einfacher als an Passwörter.

Grüße
Andreas

[Christian Kruse]

Hallo Andreas,

Was gäbe es für Alternativen, auch unter
dem Gesichtspunkt mögicher DOS-Angriffe?

Wieso? Mit dem Lockout nach einigen
Fehlversuchen hast du doch schon mehr als
klar gemacht, dass du gerne geDoSt werden
willst.

Wie muss ich das verstehen? Von "wollen" kann
keine Rede sein.
An Benutzernamen kommt man doch vermutlich
erheblich einfacher als an Passwörter.

Eben. Ich besorg mir die Benutzernamen und sperre
sie mal eben alle zusammen indem ich die
Funktionalitaet deines Moduls benutze und einfach
10x das Passwort falsch sende. Und schon kann dein
Tool keiner mehr benutzen.

Gruesse,
 CK

[Andreas Korthaus]

Hi Christian!

Eben. Ich besorg mir die Benutzernamen und sperre
sie mal eben alle zusammen indem ich die
Funktionalitaet deines Moduls benutze und einfach
10x das Passwort falsch sende. Und schon kann dein
Tool keiner mehr benutzen.

OK, das sehe ich ein. Dann würde ich also lieber ein Frühwarn-System haben welches mit nach 10 Fehlversuchen eine mail/sms zuschickt. Wo würdest Du das implementieren?

Im Prinzip müsste das ja mit meinem unten skizzierten PHP-Code funktionieren, oder? Oder würdest Du das anders machen?

Grüße
Andreas

[Sven Rautenberg]

Moin!

OK, das sehe ich ein. Dann würde ich also lieber ein Frühwarn-System haben welches mit nach 10 Fehlversuchen eine mail/sms zuschickt. Wo würdest Du das implementieren?

Und dann? Was willst du dann tun, wenn du die Information erhälst?

- Sven Rautenberg

[Andreas Korthaus]

Hi!

OK, das sehe ich ein. Dann würde ich also lieber ein Frühwarn-System haben welches mit nach 10 Fehlversuchen eine mail/sms zuschickt. Wo würdest Du das implementieren?

Und dann? Was willst du dann tun, wenn du die Information erhälst?

Ich gucke mir an was los ist und entscheide dann. Das problem ist, dass ich das ganze nicht wie hier für ein paar nette Features in einem Forum mache, sondern um einige Dinge auf einem produktiven Server einstellen zu können und auch einige Dinge zu sehen, die sonst niemand zu Gesicht bekommen soll. Wenn jemand hierauf Zugriff erhalten würde wäre das der Super-Gau. Wenn der Admin-Account gesperrt ist wirkt sich das nicht auf den Rest aus, da kann ich mir auch eben einen 2. Benutzernamen geben und schon kann ich weiter arbeiten, außerdem arbeitet man daran nicht ständig, sondern wie der Name schon sagt nur zwischendurch zu administrativen Zwecken.

Die Sache ist nur die, wenn jemand ganz unbehelligt Passwörter ausprobieren kann, der Server schafft sicher einige 100 Versuche in der Sekunde, und wenn man nichts dagagan tut steigt mit jedem Versuch die Wahrscheinlichkeit vielleicht doch mal einen Glückstreffer zu landen. Das mit der statistischen Wahrscheinlichkeit ist zwar alles schön und gut, man kann aber auch beim 1. Versuch Glück haben, oder beim 1000000. Wenn jemand in den ersten 3 Versuchen Glück hat ist das halt extremes Pech für mich.

Aber ich habe eine neue Idee. Wie wäre es mit einer Authentifizierung per SSL? Das habe ich zwar schonmal versucht und nicht geschafft, aber vielleicht ja diesmal ;-)

Grüße
Andreas

[Sven Rautenberg]

Moin!

Die Sache ist nur die, wenn jemand ganz unbehelligt Passwörter ausprobieren kann, der Server schafft sicher einige 100 Versuche in der Sekunde, und wenn man nichts dagagan tut steigt mit jedem Versuch die Wahrscheinlichkeit vielleicht doch mal einen Glückstreffer zu landen.

Aber was willst du dagegen tun? Klar, du kannst Username und Passwort auswechseln. Mit Glück führt der Angreifer Buch und probiert Kombinationen, die schon mal dranwaren, nicht nochmal aus. Und du weißt vielleicht, welche Kombinationen schon probiert wurden, und könntest so das Passwort "passend" ändern.

Aber welches Risiko gehst du tatsächlich ein. Rechne dir doch mal aus, wie lange man ausprobieren müßte, um ein Passwort der Länge X per Probieren herauszufinden. Wenn dir die Sicherheit durch ein so langes Passwort nicht genügt: Mach es doppelt so lang. Niemand hindert dich daran, ein 32 Zeichen langes Passwort zu nehmen. Zusammen mit MD5-Codierung dieses Passwortes in der .htpasswd-Datei dürfte es unmöglich sein, per Zufall einzubrechen. Die normale crypt-Codierung erlaubt nur maximal 8 Zeichen, das wäre wahrscheinlich schlecht.

Und wenn du wirklich einen Hochsicherheitsbereich brauchst, dann gib keinen Zugriff über HTTP (das ist unverschlüsselt und abhörbar), sondern nur über SSH, mit IP-Sperre für den Rest des Internets (erfordert aber eine feste IP deinerseits) und doppelter Passwortsperre, bis man root werden kann (also erstmal einloggen auf einem normalen Useraccount, und dann "su -", um root zu werden).

Du hast gegen BruteForce keine Chancen - außer der, dass man den möglichen Einbruch durch entsprechende Gegenmaßnahmen, die aber schon im Vorfeld getroffen werden müssen, lange abwehren kann. Und zentraler Punkt einer solchen Abwehrmaßnahme ist eben ein langes Passwort.

Das mit der statistischen Wahrscheinlichkeit ist zwar alles schön und gut, man kann aber auch beim 1. Versuch Glück haben, oder beim 1000000. Wenn jemand in den ersten 3 Versuchen Glück hat ist das halt extremes Pech für mich.

Niemand wird bei einem 32-Zeichen-Passwort in den ersten 3, 3000 oder 3 Milliarden Versuchen Glück haben. Er wird entweder scheitern, oder beim ersten Mal reinkommen, weil er das Passwort kennt.

Aber ich habe eine neue Idee. Wie wäre es mit einer Authentifizierung per SSL? Das habe ich zwar schonmal versucht und nicht geschafft, aber vielleicht ja diesmal ;-)

Das würde auch helfen. Ist von der Wirkungsweise allerdings auch nichts anderes, als ein sehr sehr langes Passwort.

- Sven Rautenberg

[Alain]

Hallo,

Du hast gegen BruteForce keine Chancen -

doch siehe [pref:t=64420&m=366520]
Gruss vom Alain

[Sven Rautenberg]

Moin!

Hallo,

Du hast gegen BruteForce keine Chancen -

doch siehe [pref:t=64420&m=366520]

Nein, siehe [pref:t=64420&m=366488]. BruteForce muß nicht zwingend immer von derselben IP aus geschehen. IP != Benutzer. Man sperrt damit IPs aus, die teilweise auch unschuldig sind. Es reicht ja ein einziger AOL-User, der angreift, und nach einiger Zeit sind die gesamten AOL-Proxys ausgesperrt.

- Sven Rautenberg

[Alain]

Hallo,

Du hast gegen BruteForce keine Chancen -

doch siehe [pref:t=64420&m=366520]

Nein, siehe [pref:t=64420&m=366488]. BruteForce muß nicht zwingend immer von derselben IP aus geschehen. IP != Benutzer. Man sperrt damit IPs aus, die teilweise auch unschuldig sind. Es reicht ja ein einziger AOL-User, der angreift, und nach einiger Zeit sind die gesamten AOL-Proxys ausgesperrt.

naja das sind doch eh nur proxys die sie benutzen für solche attacken.
Natürlich werden die nicht für ewig weggesperrt,
nur für ein paar stunden oder tage.
Und dazu muss ich auch sagen,dass die requests meist gar nicht auf das login.cgi direkt richten sondern
auf das denied.cgi welches nicht denied.cgi heisst,weil die nicht mal wissen,dass das cgi gar nicht
die htpasswd liste überprüft,sondern nur loggt.
Auch das login.cgi ist mit diversen schalter geschaltet,bevor der die passwortliste abklappert,damit sichergestellt ist,
dass sich der user auch wircklich von meiner login seite einloggt und nicht mit einem programm wie bruteforce von seinem lokalen rechner.
Das einzige was man könnte ist den server exploiden,
aber was nützt ihm das,wenn der name zum memberverzeichniss z.B. "/we23BzuIHjk/" heisst
und nicht /members wie bei den meisten?
Man könnte den namen fürs memberverzeichniss natürlich noch länger schreiben beliebig versteht sich.
Gruss vom Alain

[Sven Rautenberg]

Moin!

naja das sind doch eh nur proxys die sie benutzen für solche attacken.
Natürlich werden die nicht für ewig weggesperrt,
nur für ein paar stunden oder tage.

Das reicht ja schon aus, um für berechtigte Benutzer den Zugang zu sperren. Das ist genau das mögliche Problem bei sowas.

Natürlich kannst du dich selbst beruhigen und sagen: "Ist ja noch nie vorgekommen, hat noch nie Schaden angerichtet." Klar. Genauso häufig kommen BruteForce-Attacken ja auch vor, weil Angreifer sehr wohl wissen, dass man mit BruteForce eher sehr selten Zugriff erlangt, damit aber heftig auffällt. BruteForce lohnt sich nur, wenn man es anwenden kann, ohne dass es auffällt. Also in der Regel, wenn man eine Passwortdatei mit verschlüsseltem Passwort darin bekommen hat.

Wenn man aber als Anbieter irgendwelche Sperrmaßnahmen als automatische Reaktion auf BruteForce eingebaut hat, und das wird bekannt, ist das eine herrliche Einladung für alle möglichen DoS-Attacken. DoS kommt auch nicht so häufig vor, weil es in der Regel keine wirklich interessanten Ziele gibt. Microsoft ist beispielsweise ein interessantes Ziel, aber sehr schwer zu treffen, weil die einfach riesige Mengen an Kapazität bereitstellen. Da müßte schon das gesamte Internet mitmachen.

Wenn aber ein Anbieter auf sehr leichte Art und Weise dichtzumachen ist, so dass man dafür kaum mehr als einen einzigen Rechner plus Modemleitung braucht, dann wird der als Ziel natürlich schon interessant.

Dein Mechanismus mag für den einfachen Fall funktionieren: Skriptkiddies oder Hobbyhacker mit der typischen Neugierde, die man schnell aufhalten kann. Er birgt aber das Potential, dass man deine Site mit weig Aufwand für reguläre Benutzer unzugänglich machen kann.

Und dazu muss ich auch sagen,dass die requests meist gar nicht auf das login.cgi direkt richten sondern
auf das denied.cgi welches nicht denied.cgi heisst,weil die nicht mal wissen,dass das cgi gar nicht
die htpasswd liste überprüft,sondern nur loggt.

Wie die Dateinamen heißen, ist irrelevant. Ein vernünftiger Angreifer nimmt genau das CGI, welches vom Login-Formular angesprochen wird.

aber was nützt ihm das,wenn der name zum memberverzeichniss z.B. "/we23BzuIHjk/" heisst
und nicht /members wie bei den meisten?

Das ist auch egal. Ein erfolgreicher Login-Vorgang wird den Angreifer genau dorthin bringen, wo er hin will. Solche kryptischen Namen sind nur dann von Interesse, wenn du das Verzeichnis unzureichend geschützt hast und man ohne Login reinkommen würde.

- Sven Rautenberg

[Alain]

Hallo,

naja das sind doch eh nur proxys die sie benutzen für solche attacken.
Natürlich werden die nicht für ewig weggesperrt,

Das reicht ja schon aus, um für berechtigte Benutzer den Zugang zu sperren. Das ist genau das mögliche Problem bei sowas.

ok,aber trotzdem sind es kaum proxys von aol sondern meistens sog. anonym proxys die selbst nur ein paar tage gültig sind.

Das ist auch egal. Ein erfolgreicher Login-Vorgang wird den Angreifer genau dorthin bringen, wo er hin will. Solche kryptischen Namen sind nur dann von Interesse, wenn du das Verzeichnis unzureichend geschützt hast und man ohne Login reinkommen würde.

Also ums nochmal zu erläutern,ein Angriff auf das login.cgi ist schon gar nicht möglich,weil Bruteforce eigentlich auf 401 request/antworten reagiert und nicht auf
200er antworten vom server,was ja sowieso immer der fall ist bei normalen anfragen.
Das heisst er braucht das htaccess verzeichniss oder url nun mal um seine user:pass liste durchklappern zu lassen.
Aber wo kein htaccess geschützes verzeichniss ist bzw. wenn keines gefunden wird,kann er es auch nicht anwenden,seine anfragen mit bruteforce.

Gruss vom Alain

[Sven Rautenberg]

Moin!

Also ums nochmal zu erläutern,ein Angriff auf das login.cgi ist schon gar nicht möglich,weil Bruteforce eigentlich auf 401 request/antworten reagiert und nicht auf
200er antworten vom server,was ja sowieso immer der fall ist bei normalen anfragen.

Wieso das? Wo immer ein Login-Feld besteht, sei es aufgrund von 401 oder Formularen, kann man ansetzen.

Und was heißt "BruteForce _reagiert_"? Da reagiert üblicherweise nichts, da setzt man als Angreifer wissentlich ein Skript drauf an, weil man ein Login, dessen Position man kennt, überwinden will. Das bedeutet: Dem Angreifer ist sein Ziel bekannt - entweder das supergeheime Verzeichnis (auf das er beispielsweise aufgrund seiner Referrer-Auswertung gekommen ist), oder dein Login-Formular (sofern es eins gibt).

Das heisst er braucht das htaccess verzeichniss oder url nun mal um seine user:pass liste durchklappern zu lassen.

BruteForce ist mehr als das Abklappern einer Liste. Aber damit kann man natürlich mal anfangen.

Aber wo kein htaccess geschützes verzeichniss ist bzw. wenn keines gefunden wird,kann er es auch nicht anwenden,seine anfragen mit bruteforce.

Wenn du natürlich die URL so geheim hälst, dass sie auf deiner Site nicht auftaucht, und niemandem bekannt ist, und auch sonst keiner drauf zugreifen kann - dann kann man natürlich nicht angreifen, klar.

- Sven Rautenberg

[Alain]

Hallo,

Wieso das? Wo immer ein Login-Feld besteht, sei es aufgrund von 401 oder Formularen, kann man ansetzen.

na gut Du denkst eventuell etwas zu weit hergeholt.
Das login.cgi ist natürlich nicht in dem geschützten verzeichniss und da
(solltest du eigentlich am besten wissen) ein perl.cgi ein server seitiges ablauf script ist
kann auch nur der server in dem verzeichniss htpasswd nachgucken und bei bedarf freischalten und nicht das
bruteforce-Programm das kein skript ist (jedenfalls seh ich das so)

Und was heißt "BruteForce _reagiert_"? Da reagiert üblicherweise nichts, da setzt man als Angreifer wissentlich ein Skript drauf an, weil man ein Login, dessen Position man kennt, überwinden will. Das bedeutet: Dem Angreifer ist sein Ziel bekannt - entweder das supergeheime Verzeichnis (auf das er beispielsweise aufgrund seiner Referrer-Auswertung gekommen ist), oder dein Login-Formular (sofern es eins gibt).

Das heisst er braucht das htaccess verzeichniss oder url nun mal um seine user:pass liste durchklappern zu lassen.

BruteForce ist mehr als das Abklappern einer Liste. Aber damit kann man natürlich mal anfangen.

klar so ähnlich wie der accessdiver,den ich selbst schon probiert habe.

Wenn du natürlich die URL so geheim hälst, dass sie auf deiner Site nicht auftaucht, und niemandem bekannt ist, und auch sonst keiner drauf zugreifen kann - dann kann man natürlich nicht angreifen, klar.

Na klar ist der geheim,
da bruteforce nicht in einem perl.cgi (nach pfaden) selbst suchen kann und darf(glücklicherweise:-))
Gruss vom Alain

[Sven Rautenberg]

Moin!

Wenn du natürlich die URL so geheim hälst, dass sie auf deiner Site nicht auftaucht, und niemandem bekannt ist, und auch sonst keiner drauf zugreifen kann - dann kann man natürlich nicht angreifen, klar.

Na klar ist der geheim,
da bruteforce nicht in einem perl.cgi (nach pfaden) selbst suchen kann und darf(glücklicherweise:-))

Aber wie kommen dann reguläre Benutzer auf deine Seiten, die geschützt sind, wenn niemand die Adresse kennt?

Dass man etwas, was niemand sehen und auf das niemand zugreifen darf, sehr gut schützen kann, ist klar. Aber Zugriffsschutz bedeutet ja üblicherweise, die Leute, die zugreifen dürfen, von denen zu unterscheiden, die es nicht dürfen.

- Sven Rautenberg

[Alain]

Hallo,

Aber wie kommen dann reguläre Benutzer auf deine Seiten, die geschützt sind, wenn niemand die Adresse kennt?

Dass man etwas, was niemand sehen und auf das niemand zugreifen darf, sehr gut schützen kann, ist klar. Aber Zugriffsschutz bedeutet ja üblicherweise, die Leute, die zugreifen dürfen, von denen zu unterscheiden, die es nicht dürfen.

ein beispiel:
der member url ist http://www.domain.de/234567/geschützt.html
ich habe ein html formular das auf /cgi-bin/login.cgi zeigt.
Der berechtigte user geht nun auf das formular gibt seine daten ein und schickt es
an das login.cgi.das login.cgi checkt erst mal durch diverse tests,ob erstens
die daten von der berechtigten domain kommen,ob das password oder username grösser als 4 ist sowie das passwort
 und ob die daten nicht länger als 15 sind und wenn das alles zutrifft dann erst öffnet es die htpasswd datei und
klappert die liste ab,ob die eingaben auf ein user:verschlüsseltespassword passt,wenn ja gibt das login eine html seite aus mit
einem direkt link zum geschützten bereich,wenn nein dann leitet das login.cgi den client (bruteforce z.B.) direkt auf das logins.cgi,was dann prüft
wieviel mal dieselbe ip auf dieses logins.cgi zugreift.Falls die zahl höher als 3 ist dann wird in die htaccess deny from IPsowieso eingetragen.
Ich selbst gucke mir ab und an den errorlog an (ob mal wieder gescannt wird z.B. mit Bruteforce)und falls nötig ändere ich den pfad
von http://www.domain.de/234567/geschützt.html auf
http://www.domain.de/abcdef/geschützt.html
und ändere das login.cgi dementsprechend auf den neuen pfad.
Es ist klar das berechtigte member den wahren url kennen und vielleicht später,wenn sie nicht mehr mebers sind,versuchen
mit dem bruteforce reinzukommen,aber wie gesagt von zeit zu zeit ändert sich der pfad eben und somit sehen die einfach nur noch
404 not found.
Gruss vom Alain

[Sven Rautenberg]

Moin!

ein beispiel:

Fein.

Ich reduziere das mal auf den relevanten Teil.

der member url ist http://www.domain.de/234567/geschützt.html

Da will man hin.

ich habe ein html formular das auf /cgi-bin/login.cgi zeigt.

Das Formular kriegt man. Das Formularziel ist bekannt.

Der berechtigte user [blahblah...] dann wird in die htaccess deny from IPsowieso eingetragen.

Im Grunde genommen erzählst du nichts neues: Du prüfst, ob die eingegebenen Authentifizierungsdaten in Ordnung sind und gibst im Erfolgsfall den Zugang frei.

Wer auch immer die passenden Daten hat, kommt rein. Wer unpassende Daten hat, kommt nicht rein. Wer es mit unpassenden Daten häufiger versucht, wird IP-basiert gesperrt.

Egal was für ein Umleitungstheater du veranstaltest: Dein Login läßt sich für reguläre User sperren, indem man einfach nur von genügend vielen IP-Adressen aus Login-Versuche startet.

Ich selbst gucke mir ab und an den errorlog an (ob mal wieder gescannt wird z.B. mit Bruteforce)und falls nötig ändere ich den pfad
von http://www.domain.de/234567/geschützt.html auf
http://www.domain.de/abcdef/geschützt.html

Genausogut kannst du die Passwörter der User ändern. Ist auch egal. Da man, _wenn_ man ein Passwort (warum auch immer) herausgefunden hat, ja einen legalen Zugang kriegen und das Zielverzeichnis bekommen kann, ist deine Umbenennerei lediglich ein Herumdoktoren an Symptomen. Es bringt keinen zusätzlichen Schutz.

Auf der positiven Seite hast du ein System, was zu häufiges Falscheingeben der Daten durch komplettes Aussperren verhindert.

Auf der negativen Seite hast du ein System, was es Angreifern erlaubt, reguläre Benutzer durch Benutzung der Sperrfunktion auszusperren.

Das ist genau der Punkt, den ich die ganze Zeit diskutiere. Es gibt Systeme, die sollen eben genau diese negative Seite nicht haben, weil es inakzeptabel wäre, wenn reguläre Benutzer ausgesperrt würden. Außerdem würde sowas einen gewissen Verwaltungsaufwand verursachen.

Es ist klar das berechtigte member den wahren url kennen und vielleicht später,wenn sie nicht mehr mebers sind,versuchen mit dem bruteforce reinzukommen,aber wie gesagt von zeit zu zeit ändert sich der pfad eben und somit sehen die einfach nur noch 404 not found.

Das ist irrelevant. Es ist egal, ob ein Ex-Benutzer, dessen Passwort nicht mehr gilt, direkt auf die Ressource zugreifen will, oder ob er den offiziellen Eingang nimmt. Ein abgelaufenes Passwort ist ein abgelaufenes Passwort.

Deine Schilderungen beweisen eines: Du hast nicht das Supersystem erfunden. Du hast dich für eine Zugangssicherung entschieden, die man zuungunsten regulärer Benutzer angreifen kann, damit du einen höheren Level an Sicherheit erhälst. Als Preis bezahlst du einen höheren Verwaltungsaufwand und eine höhere notwendige Serverperformance (denn auch das Durchlesen einer IP-Sperrliste ist nicht kostenlos zu haben - insbesondere, wenn sie als .htaccess-Datei vorliegt und bei jedem Request neu geparst werden muß). Du machst dich also, auch wenn BruteForce nicht zum Ziel führt (aufgeklärte Angreifer wissen, dass sie damit nur sehr selten zum Ziel kommen), angreifbarer für DoS-Attacken.

Wenn ich die Wahl hätte, entweder ein kompliziertes, performancefressendes und Benutzer aussperrendes System zu benutzen, oder ein einfaches, schnelles und prinzipiell bruteforce-bares (was ich durch das Vorschreiben bzw. Selbstgenerieren von Passworten gut im Griff haben kann), dann wähle ich lieber die zweite Variante.

Wir können die Diskussion an dieser Stelle gerne abbrechen - vielleicht ja sogar beenden. Ich behaupte ja schließlich nicht, dass man in dein System mit BruteForce reinkommt. Ich behaupte nur, dass man durch den Versuch, so reinzukommen, dir bzw. den regulären Benutzern mehr Schaden oder Ärger zufügen _könnte_, als mit einem "normalen" .htacces-Schutz.

Wenn du jetzt argumentierst, dass du noch nie Probleme gehabt hattest - dann hattest du bis jetzt Glück gehabt, dass du kein sonderlich attraktives Ziel abgibst.

- Sven Rautenberg

[Alain]

Hallo,

Wir können die Diskussion an dieser Stelle gerne abbrechen - vielleicht ja sogar beenden. Ich behaupte ja schließlich nicht, dass man in dein System mit BruteForce reinkommt. Ich behaupte nur, dass man durch den Versuch, so reinzukommen, dir bzw. den regulären Benutzern mehr Schaden oder Ärger zufügen _könnte_, als mit einem "normalen" .htacces-Schutz.

ich hab einen normalen htaccess schutz nur der login führt über ein cgi dort hin und nicht mit
einem direkt link ins htaccess geschützte verzeichniss,welche bruteforce benutzter benötigen,um
ihre 401 (bis zum eventuellen 200) abfragen am server durchscannen zu lassen.

Wenn du jetzt argumentierst, dass du noch nie Probleme gehabt hattest -

am Anfang schon,aber man lernt ja immer zu,auch durch cracken ;-)
Und übrigens wenn Du denkst,dass in der htaccess datei 100e von gesperrten ips sind dann irrst Du.
Ist mir auch klar dass der server dadurch an perfomance beeinträchtigt wird.

dann hattest du bis jetzt Glück gehabt, dass du kein sonderlich attraktives Ziel abgibst.

am Anfang hatte ich täglich mehrere mails von meinem sicherheits cgi gekriegt,dass wieder mal eine ip gesperrt wurde und jetzt sind es
im monat 1 mail vielleicht,was für mich heisst,dass mein prinzip sehr wirksam ist.

Gruss vom Alain

[Christian Kruse]

Hallo Sven,

Und wenn du wirklich einen
Hochsicherheitsbereich brauchst, dann gib
keinen Zugriff über HTTP (das ist
unverschlüsselt und abhörbar),

Schonmal was von HTTP over SSL gehoert? :)

Gruesse,
 CK

[Sven Rautenberg]

Moin!

Und wenn du wirklich einen
Hochsicherheitsbereich brauchst, dann gib
keinen Zugriff über HTTP (das ist
unverschlüsselt und abhörbar),

Schonmal was von HTTP over SSL gehoert? :)

Nein, was ist das? Klingt interessant. Hast du irgendwo mehr Informationen dazu?

:)

- Sven Rautenberg

[Christian Kruse]

Hallo Sven,

Und wenn du wirklich einen
Hochsicherheitsbereich brauchst, dann gib
keinen Zugriff über HTTP (das ist
unverschlüsselt und abhörbar),

Schonmal was von HTTP over SSL gehoert? :)

Nein, was ist das? Klingt interessant. Hast du
irgendwo mehr Informationen dazu?

:)

*platsch* ;)

Gruesse,
 CK

[Christian Kruse]

Hallo Andreas,

Dann würde ich also lieber ein Frühwarn-System
haben welches mit nach 10 Fehlversuchen eine
mail/sms zuschickt. Wo würdest Du das
implementieren?

Gar nicht. Sven hat schon ganz recht: was bringt
dir das? Du kannst eh nichts gegen tun. Sorg
dafuer, dass deine User vernuenftige Passwoerter
waehlen, mehr kannst du letztenendes nicht tun.

Gruesse,
 CK

[Tom]

Hello,

Eben. Ich besorg mir die Benutzernamen und sperre
sie mal eben alle zusammen indem ich die
Funktionalitaet deines Moduls benutze und einfach
10x das Passwort falsch sende. Und schon kann dein
Tool keiner mehr benutzen.

Das geht mit Kontonummern und eBanking auch ganz gut. Ich hoffe, Du hast noch Bargeld im Haus.

Grüße

Tom

[Tom]

Hello,

Wie muss ich das verstehen? Von "wollen" kann keine Rede sein.
An Benutzernamen kommt man doch vermutlich erheblich einfacher als an Passwörter.

Das liegt ja daran, dass Du die Denkmacke, die die Banken auch lange Zeit hatten, einfach übernimmst. Ein Loginname ist genau so ein Schlüssel, wie ein PIN oder Passwort. Sollte also weder identisch mit dem Usernamen noch mit der Kontonummer o.ä. sein und auch verdeckt behandelt (Eingabe, Transport) werden. Außerdem sollte er über einen genügend großen Vorrat Verfügen, sodass Fehleingaben deutlich werden. Wenn mehrfach hintereinander ein Loginname eingegeben wird, den es nicht gibt, dann muss die rote Lampa an Deinem Serverschrank angehen...

Und dann kannst Du ja bepbachten und feststellen, ob es ein Einbruchsversuch ist oder nur ein betrunkener User.

Grüße

Tom

[Sven Rautenberg]

Moin!

Ich habe ein Admin-Verzeichnis, und ich möchte das gerne per .htaccess(Basic-Auth) schützen. Nur kenne ich hier keine Möglichkeit, dieses gegen Brute-Forece Angriffe zu schützen.

Es gibt keinen Schutz gegen BruteForce, außer die notwendige Suchdauer durch geschickte Wahl von Username und Passwort so auszudehnen, dass vorher das Universum zerfällt.

Ich würde gerne 2 Dinge implementieren:

1. nach Eingabe falsche Zugangsdaten 5 Sekunden mit der Antwort warten
2. Nach x falschen Eingaben Account für eine Gewisse Zeit sperren.

Die 5 Sekunden bedeuten, dass eine Instanz deines Webservers die 5 Sekunden durch Zeitverbraten (sleep()) abwartet. Der Webserver selbst hat aber eine maximale Anzahl von Instanzen, die für die Webseitenauslieferung zuständig ist. Wenn du also 5 Sekunden warten willst, braucht ein DOS-Angriff nur entsprechend viele Requests innerhalb der 5 Sekunden zu stellen, und der gesamte Server ist down. Die Zahl paralleler Prozesse liegt typischerweise in der Gegend von 150, ohne Änderung des Apache-Quelltextes ist das absolute Limit bei 255. Und in 5 Sekunden 255 Requests zu stellen, ist kein Problem.

Das zweite Problem: Um einen Account zu sperren, muß natürlich ein korrekter Username benutzt worden sein. Wenn du "Admin-Bereich" schreibst, dann haben dort in der Regel nur wenige Benutzer Zugriff. Willst du dich gerne durch BruteForce aussperren lassen?

Du kannst gegen BruteForce nur eine Methode anwenden: Die regulären Benutzer müssen sichere Passworte verwenden (also Usernamen und Passworte mit einer Mindestlänge von 8 Zeichen, und aus einem Zeichenvorrat, der möglichst groß ist, also kleine und große Buchstaben, Zahlen und Sonderzeichen, und auch eine erzwungene Mischung dieser Zeichen - idealerweise generierst du die Passworte und setzt sie deinen Benutzern vor, anstatt dass sie sich selber welche ausdenken), und eine inkorrekte Anfrage sollte den Server so wenig wie möglich belasten.

- Sven Rautenberg

[Andreas Korthaus]

Hi!

Es gibt keinen Schutz gegen BruteForce, außer die notwendige Suchdauer durch geschickte Wahl von Username und Passwort so auszudehnen, dass vorher das Universum zerfällt.

Das geht nicht. Man kann auch ein 14567 Zeichen langes Paswort im ersten Versuch raten - wenn man ein bisschen Glück mitbringt ;-)
Aber Du hast schon Recht.

Die 5 Sekunden bedeuten, dass eine Instanz deines Webservers die 5 Sekunden durch Zeitverbraten (sleep()) abwartet.

Ja, war ne dumme Idee, gebe ich zu.

Das zweite Problem: Um einen Account zu sperren, muß natürlich ein korrekter Username benutzt worden sein. Wenn du "Admin-Bereich" schreibst, dann haben dort in der Regel nur wenige Benutzer Zugriff. Willst du dich gerne durch BruteForce aussperren lassen?

Und auch das ist ein Aspekt den ich noch nie gesehen habe. Aber ich frage mich was schlimmer ist, wenn der Admin-Zugang gesperrt ist, oder wenn die Software kompromittierten werden konnte?
Aber da das sicher keien gute Lösung ist habe ich wie unen erwähnt über dei Verwendung einer Client-Authentification per SSL nachgedacht, dann kombiniert mit der HTTP-Authentification(vielleicht sogar Digest?) und https.

Aber kann das überhaupt ohne echte von einer CA authorisierte Zertifikate funktinieren? Ich meine kann ich mit einer eigenen CA das selbe Sicherheitsniveau erreichen?

Du kannst gegen BruteForce nur eine Methode anwenden: Die regulären Benutzer müssen sichere Passworte verwenden (also Usernamen und Passworte mit einer Mindestlänge von 8 Zeichen, und aus einem Zeichenvorrat, der möglichst groß ist, also kleine und große Buchstaben, Zahlen und Sonderzeichen, und auch eine erzwungene Mischung dieser Zeichen - idealerweise generierst du die Passworte und setzt sie deinen Benutzern vor, anstatt dass sie sich selber welche ausdenken), und eine inkorrekte Anfrage sollte den Server so wenig wie möglich belasten.

Ja, das werde ich auf alle Fälle machen.

Grüße
Andreas

[Henryk Plötz]

Moin,

Aber da das sicher keien gute Lösung ist habe ich wie unen erwähnt über dei Verwendung einer Client-Authentification per SSL nachgedacht, dann kombiniert mit der HTTP-Authentification(vielleicht sogar Digest?) und https.

Ich hatte mich eh schon gefragt warum du Basic Auth nehmen willst wenn es doch so wichtig ist.

Aber kann das überhaupt ohne echte von einer CA authorisierte Zertifikate funktinieren? Ich meine kann ich mit einer eigenen CA das selbe Sicherheitsniveau erreichen?

Nein. Du kannst höchstens ein besseres Niveau erreichen. Der Sicherheit ist es vollkommen egal wer das Zertifikat erstellt oder signiert (ausser vielleicht er benutzt schlechten Zufall), aber wenn du demjenigen nicht vertraust, dann ist das alles für die Katz.

[Alain]

Hallo,
man könnte es mit einem perl.cgi login realisieren.
Das login.cgi such in der htpasswd nach dem richtigen user:pass und leidet die seite
auf eine denied.cgi weiter.Diese denied.cgi seite loggt die ip und zählt sie hoch.
wenn eine zahl von 3 überschritten wurde,dann bekommt der webmaster ne mail und die ip wird
über die htaccess gesperrt.
Das gute an dem login.cgi wäre dass man den durch htaccess geschützen member/url nicht kennt und somit
mit bruteforce gar nicht durch scannen kann.
Wenn das login.cgi den user:pass findet,dann zeigt er erst den richtigen member/url an.
Ich habs so realisiert und es funtzt tadellos.
Keine unnötigen 401 request mehr seither.

Gruss vom Alain