Bekijk Volledige Versie : Htaccess bug in apache en nginx of niet?
Bij toeval ontdekt ik iets wegens gepruts met de regex.custom.pm van CSF.
Het lijkt er op dat zowel in Apache alsook in Nginx iets gewijzigd is of dat er een bug ontstaan is.
Als ik ergens op een .htaccess ga inloggen, krijg ik normaliter na 3x een foute login een authentication error.
Dat is niet meer het geval. Het login schermpje blijft opduiken, ongeacht hoe vaak je ook probeert.
Dus maar eens in de logfile gekeken en daar zie je dan een aantal keren het volgende:
[Tue Feb 25 16:40:10 2014] [error] [client 84.26.xxx.xxx] user dkdk not found: /test/testdir/
Van wat ik mij herinner stond er het volgende normaliter:
Failed web page login from .... etc.
Er is dus klaarblijkelijk iets in nadelige vorm veranderd, hetgeen een mogelijkheid geeft tot onbeperkt bruteforcen.
Lijkt mij een bug, toch?
Dit heeft niets met .htaccess of de webserver te maken. Als je een beveiligde pagina bezoekt, zal de server een 401 unauthorized status code teruggeven, waarop de browser het schermpje zal laten zien. Bij een foutieve login zal het systeem wederom een 401 unauthorized weergeven. Voor de server is elke request een nieuwe request, dus die houdt helemaal niet bij hoe vaak je al foutief hebt aangemeld. Het is dus de browser die kiest hoe vaak je het kadertje te zien krijgt, niet de server.
Vroeger was dat inderdaad vaak 3 keer, maar op een bepaald moment hebben de meeste browsers er voor gekozen om dit gewoon te herhalen net zolang de gebruiker er zin in heeft.
Vroeger? Nou ik weet niet wat je onder vroeger verstaat, maar zo lang geleden is dat nog niet verandert.
Als het werkt zoals jij zegt (en dat geloof ik best), dan hebben ze dat in de browsers in nadelige wijze verandert. Eerlijk gezegd zie ik ook niet in waarom het nodig zou zijn om dat te herhalen zolang de gebruiker er zin in heeft, want op die wijze werken browsers dus mee aan bruteforce pogingen.
Is er een manier om dat op te vangen, of is de enige methode maar weer een regexp.custom.pm aan te maken voor CSF?
Als je wilt bruteforcen dan kun je natuurlijk heel eenvoudig zelf een scriptje in elkaar zetten dat HTTP babbelt, daar heb je helemaal geen browser voor nodig. De browser faciliteert hooguit de gebruiker die 10 keer wil proberen ipv 3 keer.
Als je meer controle wilt over het authenticatieproces dan gebruik je beter een eigen systeem (met cookies oid) ipv HTTP-authenticatie.
systemdeveloper
25/02/14, 21:00
Dat komt omdat lfd.pl de 401 error niet checked en er dus ook niet op reageert. Na een paar keer hoor je een 403 te krijgen en daarop reageert lfd wél.
In principe kun je lfd wel snel aanpassen om ook op een 401 te reageren, maar hou dan wel in gedachten dat IEDEREEN die op zo'n htaccess beveiligde page komt, minimaal 1 keer een 401 voor zijn kiezen krijgt.
Er is een wezenlijk verschil tussen een 401 en een 403. 401 wil zeggen dat de authenticatie mislukt is (verkeerde login). Een 403 wil zeggen dat je een resource probeert te raadplegen waar je geen rechten toe hebt (en dat kan perfect gebeuren als je wel een correcte login hebt ingegeven).
Als je een directory listing probeert op te vragen als dat niet mag, dan krijg je een 403. Ik denk niet dat je daar op wil blocken, want als iemand tijdens een onderhoud toevallig de webroot leeg maakt, heb je waarschijnlijk de helft van je trouwe bezoekers (die uiteraard een paar keer refreshen) aan een ban geholpen...
Wil je toch blocken bij foutieve logins, laat dan de applicatie die boven op je HTTP server draait dit afhandelen. Daar kan je allicht veel meer logica in kwijt om zo gepast op te kunnen treden.
systemdeveloper
25/02/14, 21:33
Een 401 en 403 zijn eigenlijk functioneel redeljk gelijk aan elkaar behalve dat de 401 een trigger is om de browser een popup te tonen.
Geen access = geen access tenslotte. Of dat nu is omdat je weigert te authoriseren of omdat er een deny from all ergens in een htaccess staat of omdat er ergens de directorylisting in de apache conf is uitgezet.
Dat is lood om oud ijzer. Het gaat erom dat je mensen die linksom of rechtsom geen access ergens op hebben en dit toch proberen te forceren, gewoon (tijdelijk) voor een gesloten deur zet.
Maar als je te maken hebt met een extreem snuggere webmaster de webroot leeggooit, moet je hem op de flikker geven :P
Er wordt overigens nergens gezegd dat je al na 1 keer moet blokken op een 403. Dat kun je ook op 50 keer doen. Die mogelijkheid heeft lfd maar niet op een 401.
Het gekke is dat ik geen 401 in de log zie alleen [error] en geen error nummer erbij.
Nja, als het goed is gaan ze bij CSF een wijziging aanbrengen voor de volgende versie. Ben benieuwd.
Die mogelijkheid heeft lfd maar niet op een 401.
Misschien een zelf maken via de regexp.custom.pm ofzo?
systemdeveloper
25/02/14, 23:46
Het gekke is dat ik geen 401 in de log zie alleen [error] en geen error nummer erbij.
Nja, als het goed is gaan ze bij CSF een wijziging aanbrengen voor de volgende versie. Ben benieuwd.
Misschien een zelf maken via de regexp.custom.pm ofzo?
Och, je kunt alles waar _403 in staat in lfd.pl uitbreiden met een _401 als je echt echt wilt natuurlijk.
Maar zoals al door Cakkie is gezegd, kun je het met een paar regels php een stuk netter oplossen (plus dat je dan niet hoeft te wachten totdat lfd je logs eens een keer gescanned heeft).
Pffff... never mind, schijnt toch te werken... Kennis van me had mijn ip in de csf.allow gezet. LoLz.:)
In apache 2.4.x schijnt er wel een probleempje te zijn maar dat wordt dus met de volgende versie opgelost volgens CSf.