Op onze Joomla site gebruiken wij nog steeds Joomla! 1.0.13 Stable [ Sunglow ] + JDefender security component (www.joomlaequipment.com/). Vele malen geprobeerd om te kraken/breken maar tot nu toe niet gelukt <ff afkloppen>.

.htaccess en iedereen buitensluiten behalve jouw eigen IP(range) op de Administrator pagina.

Bedankt voor jullie reacties! ik ga er verder mee aan de slag!

zie http://www.govcert.nl/render.html?it=146#wp

Alhoewel er wel bijgezegd moet worden, dat ivm het gebruik van Joomla als onderliggend systeem Brute-Force attacks waarschijnlijk je minste zorg is. Er zijn nogal wat kwetsbaarheden in Joomla die niet of niet goed zijn opgepakt. Ik denk dat je meer problemen gaat krijgen met zaken als SQL-injections e.d. dan met brute forcing van user passwords.

Zeker op het moment dat de betrokken webserver public-facing gaat worden (dus Internet, geen Intranet) raad ik je aan van een ander CMS gebruik te maken.
Afhankelijk van de gewenste en geboden functionaliteit kunnen dat er diverse zijn overigens.

Is drupal geen betere oplossing!!!

Hugo, sleep() zal niet helpen.
Een bruteforcer gaat niet via zijn browser het formulier invullen.
Nee, die laat een script het formulier invullen, waarbij er meerdere requests naast elkaar lopen.

"Met behulp van brute force is alles te kraken, als je maar genoeg tijd hebt. "

Volslagen onzin. Indien een account een lockout krijgt na enkele pogingen, dan heeft brute force weinig zin. Daarnaast kan dergelijke activiteit gemakkelijk worden opgemerkt d.m.v. security monitoring waarna er maatregelen genomen kunnen worden om verdere pogingen te blokkeren. Ook kan je brute force hacking voorkomen door gebruik van multi-factor authenticatie en/of one time password tokens. Enkel slecht beveiligde systemen zijn met genoeg tijd via brute force te kraken.

Daar ben ik weer;) ik heb weer veel bijgeleerd en heb ook even na sql-injection gekeken klopt als ik een ' teken invoer achter mijn webadres en hij geeft geen foutmelding dat mijn site sql-injection proof is? of id een sql-injection dan als nog mogelijk?

Dat is wel heel theoretisch. Immers, in de praktijk is de server al lang overleden en applicatie uitgefaseerd.

"Niet volslagen onzin. Ik doelde op het theoretische geval van 'genoeg tijd' in de orde van duizenden jaren.

Jouw account lockout is daarbij 'gevaarlijk', omdat ik dan de website kan DoS-en. ""

Het feit dat je een account lockout als gevaarlijk kan beschouwen, wil niet zeggen dat account lockouts niet gebruikt worden om brute force attacks tegen te gaan. Gebruik van dit soort maatregelen is de normaalste zaak van de wereld. Daarnaast brengt multifactor authenticatie en OTP's niet het gevaar met zich mee wat jij nu noemt.

Aan duizenden jaren heb je niets wanneer een systeem goed beveiligd is tegen brute force attacks.

"En dat is dus niet waar. Zelfs het zwaarste cryptografisch algoritme is met genoeg tijd te brute-forcen."

Dat hangt dus nog altijd af van de genomen maatregelen. Je kan wel ongelimiteerd tijd hebben, maar je gaat er nog steeds vanuit dat je ongelimiteerd pogingen kan uitvoeren, en dat is bij een degelijk beveiligd systeem dus niet het geval. Verder kan je bij goede security monitoring ook nog eens adressen van aanvallers simpelweg blokkeren zodat ze het systeem niet meer kunnen benaderen, ervanuit gaande dat de aanvaller geen grootschalig botnet heeft om vanaf willekeurige clients de pogingen uit te voeren.

Dat veel systemen niet goed beveiligd zijn, waardoor dergelijke aanvallen wel kunnen slagen is een andere zaak. Redenen hiervoor zijn het ''DDoS'' scenario wat jij noemt, als ook de kosten die eraan verbonden zijn om accounts weer te unlocken (bedenk maar wat het zou kosten voor Microsoft om dergelijke ondersteuning te bieden aan honderden miljoenen gratis hotmail klanten) ;)

Ik denk jij een verkeerd beeld hebt van blind SQL injections. Kijk eens hier: http://en.wikipedia.org/wiki/SQL_injection#Blind_SQL_injection. Hier kun je lezen dat een blind SQL injection een conditionele aanval is. Hiermee wordt bedoeld dat de hacker wel degelijk kan zien of de query uitgevoerd is (foutmelding, geen rijen, één of meer rijen). Het grote verschil tussen een "gewone" SQL injection t.o.v. een "blind" SQL injection is dat je bij de laatste variant de data niet direct op het scherm weer kunt geven.

Brute force aanvallen zijn minder relevant bij Joomla dan gebruik van de vele lekken. Tegen brute force kun je prima maatregelen nemen. De lekken zijn een stuk lastiger. Kijk eens bij modsecurity van apache om wat veiliger te werken. Moet alleen de administrator wel weten wat hij doet. ;)

EJ

Je kunt modsecurity toepassen