[php/htaccess] Gebruikers bannen

[xilent_xage]

Hoi,

Ik ben mijn framework een beetje aan het doorlichten qua security na de recente publiciteitsgolf over kwetsbare gemeentesites etc. Sinds een van mijn klanten actief is in de beveiligingssector leek me dat wel zo verstandig. Natuurlijk zoek je eerst naar unprepared SQL statements etc, maar ik vind het ook altijd een goed idee om wat algemene checks toe te voegen, omdat je daarmee een hoop shit kunt afvangen.

Een van de checks die ik wil toepassen is IDS + gebruikers bannen. Ik heb nu een aantal checks in mijn framework ingebouwd:

• Een scan op verdachte userinput middels PHPIDS
• Een onzichtbaar linkje op elke pagina dat is gedisallowed in robots.txt
• Een javascript-kunstje om formulieren te beveiligen
• Een check om GET requests te matchen langs een lijst met bekende exploits, om die bots tegen te houden die je site scannen op phpmyadmin etc

Nu wil ik al deze gevallen doorsturen naar een waarschuwingspagina die je vertelt dat je iets verdachts hebt gedaan, misschien een linkje naar een virusscanner oid, en de melding dat je gebanned bent en dat je kunt mailen met de admin als dat onterecht is oid.

vraag 1: wat vinden jullie van deze extra laag? nuttig? overkill?

Stap 2 is natuurlijk om gebruikers ook te gaan bannen van de website. Ik wil dat graag zo vroeg mogelijk in het framework inbouwen om het framework zo min mogelijk te belasten. Ben nu bezig om de bans gewoon in een simpel textfiletje te laten zetten en elke user van wie geen sessie openstaat langs dit lijstje te leggen.

vraag 2: heeft iemand ervaring met performance bij bijv 100 IPs om te matchen? of 500? (snap dat dit afhangt van je code, maar even in het algemeen

Nog mooier zou het zijn als ik de bans in de .htaccess zet. Maar aangezien alles automatisch moet lopen (ook bijv via het CMS bannen/unbannen) betekent dit dat ik de htaccess moet gaan parsen en aanpassen via PHP. Enerzijds vindt ik dit wel een mooi idee omdat het niet alleen een efficiente maar ook wel een nette plek is om bans af te handelen. Anderzijds heb ik natuurlijk gelijk een hoop bedenkingen als PHP de htaccess gaat aanpassen.

vraag 3: iemand hier ervaring mee? slim of stom? iemand een tip hoe ik dit parsen zou moeten aanpakken?

vraag 4: hoe doen jullie dit? hoe doen goeie professionele websites dit? nog tips?

[ Voor 0% gewijzigd door RobIII op 17-10-2011 20:48 . Reden: Link gefixed, was: hhtp://phpids.org ]

[pedorus]

Het lijkt me niet erg nuttig om hier energie in te gaan steken. Al die extra code betekent vooral extra plaatsen waarop het mis kan gaan. Het lijkt me beter om je vooral te verdiepen in het schrijven van goede code, een simpele code scanner op de boel los te laten, en de code te laten reviewen. Alleen bij 3rd party software kan ik me hier iets bij voorstellen.

Het bannen lijkt me al helemaal niet zo heel nuttig, aangezien er waarschijnlijk een botnet gebruikt wordt en je dus vooral legitieme gebruikers dwars zit. .htaccess aanpassen is een interessante vector voor problemen. Qua performance zou ik maar een bloom filter gaan toepassen, dat gaat anders natuurlijk nooit lukken (just kidding, 500 is niks mits normaal geprogrammeerd).

[xilent_xage]

pedorus schreef op maandag 17 oktober 2011 @ 20:05:
Het bannen lijkt me al helemaal niet zo heel nuttig, aangezien er waarschijnlijk een botnet gebruikt wordt en je dus vooral legitieme gebruikers dwars zit. .

Dit snap ik niet. Een systeem zonder IDS is toch net zoiets als een pinautomaat waar je oneindig mag proberen om de pincode te raden? Als een gebruiker ongein uithaalt en je bant em dan maak je het toch een stuk lastiger?

[Ventieldopje]

Wat pedorus bedoelt is dat een hacker nooit vanuit 1 pc en zeker niet vanuit zijn eigen probeert aan te vallen. Dan zal je htaccess lijstje zoals je het wil doen wel schrikbarend snel groot worden

Er is niks mis met IDS maar als je code zelf al zo lek als een mandje is heeft IDS ook geen zin. Ik zal het nog maar eens herhalen, laat je code eens nakijken door iemand anders

[Gomez12]

Sowieso dat onzichtbare linkje, die zou ik gelijk invoeren. En dan niet handmatig bannen, maar idd direct bannen als iemand dat linkje raakt.

Dat is echt the way to go om zoekmachine spiders te bannen, klanten met browsers / proxy's die alvast prefetchen heb je natuurlijk ook niet nodig...

Ik neem tenminste aan dat je geen bezoekers op je site wilt hebben...

En een IDS in enkel php is vrij waardeloos, wat jij beschrijft is veel simpeler op te lossen door simpelweg een vertraging van 100ms oid na elke inlogpoging te geven. Geen enkele gebruiker zal het merken en bots houd je er perfect mee tegen.

[Avalaxy]

Als je gewoon zorgt dat je prepared statements gebruikt (tegen SQL injections), nooit zomaar gebruikersdata output (tegen XSS en dergelijken) en forms beveiligt tegen CSRF ben je al een heel eind. Als je dan ook nog zorgt dat je wachtwoorden goed hasht, foute inlog attempts blockt en dergelijken dan heb je wel een vrij goed beveiligde website.

[xilent_xage]

@ventieldopje / Avalaxy: Uiteraard besteed ik ook de nodige zorg aan de code zelf. Het gaat hier dus om een extra laag, niet dat ik daarmee geloof veilig te zijn en de rest maar lekker slordig ga programmeren. Code reviewing / auditing lijkt me heel gaaf maar is altijd zo vreselijk duur dat ik het nu nog even niet doe.

@Gomez12: Lekker kort door de bocht maar ik snap je punt. Vwb zoekmachine spiders: De pagina waar het linkje naar verwijst staat natuurlijk gedisallowed in robots.txt. Spiders die zichdaar niet aan houden vertrouw ik voor geen meter en ben ik inderdaad liever kwijt dan rijk. Het prefetchen van proxies is nieuw voor me en een zeer valide punt. Ik heb hierop gegoogled en vindt veel hits met vooral theoretische onderzoeken. Komt dit ook al in de praktijk voor en is het inderdaad iets om rekening mee te houden?

@Avalaxy:CSRF is nieuw voor me, en zeer interessant, veel dank. Hoewel ik betwijfel of zoiets ooit gaat voorkomen op mijn sites denk ik dat het goed is om hier toch rekening mee te houden. Vraagje: Al mijn formulieren worden gegenereerd en afgehandeld doormijn eigen formbuilder, waar uiteraard al de nodige checks overheen gaan. Ik zie twee manieren om CSRF tegen te gaan: referer checken en bij ieder formulier een random code meegeven in een hidden input. Dat laatste is uiteraard het veiligst, maar zorgt er ook voor dat de formulieren niet meer serverside gecached kunnen worden. Mijn gevoel zegt dat ik met een referer-check het probleem voor 80% afvang - klopt dat? Ik zou dan checken op OF een referer vanaf het eigen domein OF geen referer (voor clients die dat ding om wat voor reden dan ook verbergen).

Edit: nog even over CSRF: Behalve mijn site search werken al mijn formulieren met POST. Ik neem aan dat ik dan sowieso redelijk veilig ben?

[ Voor 4% gewijzigd door xilent_xage op 19-10-2011 09:08 ]

[Joolee]

Gomez12 schreef op dinsdag 18 oktober 2011 @ 19:32:
En een IDS in enkel php is vrij waardeloos, wat jij beschrijft is veel simpeler op te lossen door simpelweg een vertraging van 100ms oid na elke inlogpoging te geven. Geen enkele gebruiker zal het merken en bots houd je er perfect mee tegen.

Dat is ook geen goede oplossing. Bij je statement ga je er vanuit dat de "aanvaller" telkens maar 1 sessie open heeft staan waarbij dus iedere request 100ms vertraagd. In dit geval zou deze methode inderdaad zeer effectief zijn tegen een brute-force aanval.

Maar wat nou als ik als aanvaller simpelweg 1000 verbindingen met je server open? Of beter nog, ik gebruik een botnet zodat je mijn IP adressen niet eens kan blokkeren.

[Andre-85]

Check the referrer. The HTTP referrer, or HTTP "referer" as it is now permanently misspelled, should always come from your own domain. You could reject any form posts from alien referrers. However, this is risky, as some corporate proxies strip the referrer from all HTTP requests as an anonymization feature. You would end up potentially blocking legitimate users. Furthermore, spoofing the referrer value is extremely easy. All in all, a waste of time. Don't even bother with referrer checks.

bron: http://www.codinghorror.c...st-forgeries-and-you.html

[xilent_xage]

Andre-85 schreef op woensdag 19 oktober 2011 @ 09:42:
bron: http://www.codinghorror.c...st-forgeries-and-you.html

wat vreemd. ik zou niet weten hoe je in een CSRF de referer kun spoofen. Dat mensen zelf hun browser middels een plugin of whatever een andere referer laten meegeven - tuurlijk. Maar beweren ze nu in dit artikel dat het eenvoudig is om middels een link de referer van een ander aan te passen??? Ben ik nou zo dom? Iemand die kan uitleggen hoe dat werkt?

Joolee schreef op woensdag 19 oktober 2011 @ 09:27:
[...]
Dat is ook geen goede oplossing. [...]

Even voor de duidelijkheid - het gaat hier om een generieke functie, niet om een loginpagina specifiek

En nog even in het algemeen: Valt me toch wel op dat veel tegenmaatregelen hier worden afgedaan als 'niet waterdicht'. Is dat niet ook een beetje en drogreden? Geen enkele maatregel is nl waterdicht. Is het niet ook gewoon een kwestie van 'moeilijk maken'?

Ik snap dat iemand met een groot botnet er niet veel om geeft dat ik 10% van zijn bots ban. Maar als ik met een maatregel de eenvoudiger scriptkiddies tegen weet te houden is dat toch winst?

Voorbeeldje: Iemand die een URL met daarin "w00tw00t" of bijv "<script" request wordt gebanned. Ik snap dat je daarmee geen sophisticated hacker buiten de deur gaat houden, maar mijn gevoel zegt dan: Dit irritante botje is toch in ieder geval weg, en daarmee hou ik 90% van de aanvallen buiten de deur. Das dan toch een mooi startpunt qua beveiliging? (en nogmaals: ik snap dat dat me geenszins van de plicht ontslaat om mn code op orde te hebben!)

[Cartman!]

xilent_xage schreef op woensdag 19 oktober 2011 @ 09:04:
Edit: nog even over CSRF: Behalve mijn site search werken al mijn formulieren met POST. Ik neem aan dat ik dan sowieso redelijk veilig ben?

Fout, alle vormen van requests zijn gevoelig voor CSRF.

[pedorus]

xilent_xage schreef op woensdag 19 oktober 2011 @ 09:59:
wat vreemd. ik zou niet weten hoe je in een CSRF de referer kun spoofen. Dat mensen zelf hun browser middels een plugin of whatever een andere referer laten meegeven - tuurlijk. Maar beweren ze nu in dit artikel dat het eenvoudig is om middels een link de referer van een ander aan te passen??? Ben ik nou zo dom? Iemand die kan uitleggen hoe dat werkt?

Aanpassen naar iets willekeurigs is lastig (zou ook een bug zijn, maar daar zijn er een aantal van). Aanpassen naar niks is echter vrij eenvoudig. Een iframe met de body gevuld door javascript die een post request doet bijvoorbeeld: er is geen bron-url, dus ook geen referer. Als je vervolgens lege referers blokkeert, dan blokkeer je ook legitieme bezoekers achter bepaalde proxies of virusscanners...

[Gomez12]

xilent_xage schreef op woensdag 19 oktober 2011 @ 09:59:
[...]
En nog even in het algemeen: Valt me toch wel op dat veel tegenmaatregelen hier worden afgedaan als 'niet waterdicht'. Is dat niet ook een beetje en drogreden? Geen enkele maatregel is nl waterdicht. Is het niet ook gewoon een kwestie van 'moeilijk maken'?

Het punt is meer dat je mogelijkheden bij de gebruiker weghaalt en er enkel schijnveiligheid voor terugkrijgt.

Bijv.

Voorbeeldje: Iemand die een URL met daarin "w00tw00t" of bijv "<script" request wordt gebanned. Ik snap dat je daarmee geen sophisticated hacker buiten de deur gaat houden, maar mijn gevoel zegt dan: Dit irritante botje is toch in ieder geval weg, en daarmee hou ik 90% van de aanvallen buiten de deur.

Nee, de maker van het irritante botje dat leest ook sites als phpids en die heeft zijn botje dus aangepast dat die nu w33tw33t stuurt.
Enkel de gebruiker die een blogpost wil maken over hoe mooi zijn "w00tw00t" dag in de efteling was, die verliest lezers want iedereen die die post aanklikt wordt gebanned.

De irri-botmaker/gebruiker zal het geen fluit interesseren of hij nu w00tw00t,w33tw33t,wO0twO0t of wat dan ook verstuurt, die past zijn botje in 2 sec aan en jij hebt weer xxx posts die je kan verwijderen en je kan weer je dis aanpassen en het wordt weer ingewikkelder voor je gebruikers wat ze nu precies wel en niet mogen posten.

[xilent_xage]

Gomez12 schreef op woensdag 19 oktober 2011 @ 19:14:
[...]
Het punt is meer dat je mogelijkheden bij de gebruiker weghaalt en er enkel schijnveiligheid voor terugkrijgt.

Geen enkele ;gewone gebruiker zal 'per ongeluk' naar de URL "/phpMyAdmin/setup.php" gaan. Geen enkele gebruiker zal in een formulier '<script type=...' typen. Dus afgezien van mijn hidden-link idee pak je hier geen gewone bezoekers mee.

Gomez12 schreef op woensdag 19 oktober 2011 @ 19:14:
Nee, de maker van het irritante botje dat leest ook sites als phpids en die heeft zijn botje dus aangepast dat die nu w33tw33t stuurt.
Enkel de gebruiker die een blogpost wil maken over hoe mooi zijn "w00tw00t" dag in de efteling was, die verliest lezers want iedereen die die post aanklikt wordt gebanned.

De irri-botmaker/gebruiker zal het geen fluit interesseren of hij nu w00tw00t,w33tw33t,wO0twO0t of wat dan ook verstuurt, die past zijn botje in 2 sec aan en jij hebt weer xxx posts die je kan verwijderen en je kan weer je dis aanpassen en het wordt weer ingewikkelder voor je gebruikers wat ze nu precies wel en niet mogen posten.

w00tw00t is niet random gekozen maar wordt gebruikt in de de dirs van een bekende exploit oid. De irri-botmaker kan dit dus niet veranderen. Nogmaals: dat wil niet zeggen dat er niet veel meer manieren zijn om een server te hacken. Maar in mijn ogen maak je het hackers moeilijker door een fout te bestraffen met een ban.

BTW sorrie als ik soms wat eigenwijs overkom - ik probeer hier een goeie afweging te maken en jullie argumenten te snappen

[ Voor 3% gewijzigd door xilent_xage op 19-10-2011 21:03 ]

[Ventieldopje]

Nogmaals: dat wil niet zeggen dat er niet veel meer manieren zijn om een server te hacken. Maar in mijn ogen maak je het hackers moeilijker door een fout te bestraffen met een ban.

Een ban op gebruikersnaam pak je hoe dan ook onschuldige gebruikers mee, zo zou ik met plezier een paar keer via een paar anon proxies je admin wachtwoord fout willen raden zodat je er zelf niet meer in komt

Een ban op IP is alleen handig om valide/echte gebruikers te bannen die zich niet houden aan de regelementen. Hackers zullen altijd via een ander IP aanvallen en blijf je dus maar aan het bannen

[ Voor 19% gewijzigd door Ventieldopje op 19-10-2011 21:06 ]

[X_lawl_X]

xilent_xage schreef op woensdag 19 oktober 2011 @ 21:02:
[...]

Geen enkele ;gewone gebruiker zal 'per ongeluk' naar de URL "/phpMyAdmin/setup.php" gaan. Geen enkele gebruiker zal in een formulier '<script type=...' typen. Dus afgezien van mijn hidden-link idee pak je hier geen gewone bezoekers mee.


[...]

Klopt, maar de gebruikers die zoiets typen die zullen ook wel weten hoe je een IP ban moet omzeilen. Niet doen dus.

[T-MOB]

xilent_xage schreef op woensdag 19 oktober 2011 @ 21:02:
Geen enkele ;gewone gebruiker zal 'per ongeluk' naar de URL "/phpMyAdmin/setup.php" gaan. Geen enkele gebruiker zal in een formulier '<script type=...' typen. Dus afgezien van mijn hidden-link idee pak je hier geen gewone bezoekers mee.

Maar wat boeit het dat iemand naar /phpMyAdmin/setup.php gaat? Ik mag toch aannemen dat daar niets te vinden is. Als je server op orde is dan kunnen al die pogingen geen kwaad. Volgens mij ben je hier dus een niet-bestaand probleem aan het op te lossen.

Het tweede kan wel nuttig zijn om spam tegen te gaan op reactiesystemen / contactformulieren. De inhoud van het bericht scan je dan op verdachte content (overdadig veel links, html of ubb waar dat niet ondersteund is, dat soort zaken). Is het verdacht dan toon je een melding met wat globale uitleg wat er wel en niet kan.
Dat pas ik zelf meestal toe in combinatie met een time window: je kunt het formulier versturen tussen de 5s en tot 1 uur nadat je de pagina hebt opgevraagd. Daarmee filter je de bots die direct posten en de bots die eerst spideren en dan posten er uit. Echte gebruikers krijgen er nauwelijks mee te maken, en dan hebben ze nog de globale uitleg. Aardige trade-off om niet alle gebruikers een CAPTCHA door de strot te duwen