WordPress login URL aanpassen? Security of obscurity?

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • jrswgtr
  • Registratie: Juli 2017
  • Laatst online: 08-05 15:32
Ik had een discussie met een collega over het wel of niet veranderen van de standaard WordPress admin / login URL's in het kader van veiligheid. Er zijn veel blogs en tutorials die dit aanraden.

Het argument is dat de /wp-login.php en /wp-admin/ URL's natuurlijk makkelijk te raden zijn door "hackers" die dan brute force aanvallen kunnen gaan doen.

Een tegenargument is dat het compatibiliteitsproblemen op kan leveren. Zeker bij plugins die "hard" naar de bovenstaande paden verwijzen. Ook kan het verwarrend zijn als verschillende installaties andere paden hebben, zeker als je grote hoeveelheden WordPress websites beheert zoals wij.

Bovendien zijn er ook oplossingen tegen brute force aanvallen. De hostingprovider die wij het meest gebruiken heeft brute force detectie ingebouwd en blokkeert IP adressen automatisch, buiten WordPress om. En bij hosting die dit niet heeft is het alsnog in te bouwen met een beetje programmeerwerk.

Zien jullie nog andere argumenten om de standaard WordPress URL's wel te veranderen?

Acties:
  • +2 Henk 'm!

  • WeHoDo
  • Registratie: Augustus 2014
  • Laatst online: 27-02 20:18
Plugins die uberhaupt hardcoded zijn naar URLs blijf ik liever weg.
Betreft admin urls, deze zijn toch wel te achterhalen.

IP block en bruteforce tools zijn wel het minimale.
Ook standaard root / admin usernames niet gebruiken.

PSN: plexforce (ps4)


Acties:
  • 0 Henk 'm!

  • sypie
  • Registratie: Oktober 2000
  • Niet online
Op zich is het aanpassen van de URL maar een begin.

Kun je niet de standaard bestanden zo instellen dat die niet direct van buitenaf benaderd kunnen worden maar bijvoorbeeld wel met een redirect vanaf een andere URL (op hetzelfde domein)? (geen inhoudelijke kennis van dus vandaar mijn vraag)

Wat zeker een aanrader is: blokkeer het "administrator" account en werk onder andere accounts die volledige toegang hebben. Administrator (of vergelijkbaar) worden vaak en veel gebruikt waardoor die ook makkelijk te raden zijn, net als op een NAS.

Acties:
  • +1 Henk 'm!

Anoniem: 111246

En MFA implementeren voor het inloggen.

Acties:
  • +1 Henk 'm!

  • Stroopwafels
  • Registratie: September 2009
  • Laatst online: 21:08
Dit ligt ook aan hoeveel plugins je hebt geïnstalleerd. Als het een vrij kale WordPress installatie is dan zou ik het persoonlijk niet nodig vinden. Als er veel plugins zijn geïnstalleerd (en dus er op moet vertrouwen dat deze plugins "veilig" zijn) dan zou ik het persoonlijk fijner vinden als er een IP restrictie op wp-login.php zit.

Echter helpt dat alleen tegen bepaalde aanvallen, als er een kwetsbaarheid in een plugin zit waarmee iemand automatisch als admin kan inloggen buitenom wp-login.php (en ja dat komt best vaak voor) dan zal het alsnog geen nut hebben.

[ Voor 3% gewijzigd door Stroopwafels op 21-09-2021 20:50 ]


Acties:
  • 0 Henk 'm!

  • jrswgtr
  • Registratie: Juli 2017
  • Laatst online: 08-05 15:32
@Stroopwafels
De WordPress websites die wij bouwen zijn met ons eigen ontwikkelde thema. We gebruiken minimaal plugins.

Mijn punt is dat het "verbergen" van de admin URL geen zin heeft als het probleem dat het op moet lossen geen probleem is.

Brute force is makkelijk te voorkomen. Een "script kiddie" komt er toch wel achter dat het WordPress is aan de hand van andere kenmerken en kan dan gebruik maken van andere kwetsbaarheden als die er zijn.

Toch kan ik alleen maar blogjes vinden over waarom je het wél moet doen en nergens over waarom niet, terwijl mijn verstand zegt dat het onzin is.

Acties:
  • 0 Henk 'm!

  • brtk
  • Registratie: November 2006
  • Laatst online: 10-05 09:06
Een wat serieuzere aanvaller vindt zo'n aangepaste admin URL ook vrij gemakkelijk.
Er zijn echt enorm veel manieren om WP plugins te exploiten, ook zonder gebruik van brute force. Dagelijks up-to-date houden van WP, de gebruikte plugins en de backend (OS, PHP e.d.) is denk ik een betere duit in 't zakje van de beveiliging dan veranderen van de admin URL.

[ Voor 5% gewijzigd door brtk op 21-09-2021 21:03 ]


Acties:
  • +1 Henk 'm!

  • Stroopwafels
  • Registratie: September 2009
  • Laatst online: 21:08
Wat ook mogelijk is voor sommige websites die niet met de backend moet communiceren is een static generator tool zoals https://wordpress.org/plugins/simply-static/

Je host je WordPress site ergens achter de schermen waar niemand bij kan en dan genereer je de statische bestanden die je vervolgens ergens kunt uploaden, bijvoorbeeld op een AWS S3 bucket. Er zijn hier ook hosting providers voor zoals HardyPress en Strattic. In dat geval ben je afhankelijk van de beveiliging van de hosting provider.

[ Voor 8% gewijzigd door Stroopwafels op 21-09-2021 21:05 ]


Acties:
  • 0 Henk 'm!

  • jrswgtr
  • Registratie: Juli 2017
  • Laatst online: 08-05 15:32
@Stroopwafels
Al vind ik het een leuk idee, statisch is voor ons meestal geen optie.

Beter zou zijn om de frontend helemaal los te koppelen. Bijvoorbeeld Angular + WordPress REST-API, al is in dat geval de URL van WP alsnog publiek.

[ Voor 7% gewijzigd door jrswgtr op 21-09-2021 21:14 ]


Acties:
  • +2 Henk 'm!

  • Foamy
  • Registratie: November 2006
  • Laatst online: 01-05 16:38

Foamy

Fulltime prutser

Het veranderen van de inlog url van de site is geen beveiliging. Het enige dat je er mee buiten de deur houd zijn aanvallers die geautomatiseerd te werk gaan en grote hoeveelheden sites geautomatiseerd aflopen. En gelukkig zijn dit nou ook net de aanvallers die je het makkelijkste kunt weren voordat ze uberhaupt op je WP site geraken.
Beveiliging is imho niet iets dat je op WP/site niveau moet willen regelen. Dat wil je al een stap eerder in de pijplijn doen, bijvoorbeeld door middel van een WAF. Dat zorgt er ook direct voor dat je webserver zich bezig kan houden met het serveren van een website, in plaats van druk te zijn met beveiliging.

Dat een hoop blogjes dit soort zaken wel aanraden is ook goed te verklaren: mensen willen plugins verkopen die dat voor de (niet technische) WP gebruiker kunnen doen. Deze zullen dus zelf blogposts schrijven en laten schrijven waarin hun plugin wordt aangeraden. Vervolgens komt een andere (niet zwaar technisch onderlegde) blogger aan, en ziet "overal" dat dit wordt aangeraden. Drie keer raden wat deze dan schrijft als hij hier over zou gaan bloggen. Iedereen raad het aan, en het klinkt best logisch. Moet wel kloppen toch?

blub


Acties:
  • 0 Henk 'm!

  • jrswgtr
  • Registratie: Juli 2017
  • Laatst online: 08-05 15:32
@Foamy
Klinkt best logisch inderdaad :)

Het vervelende is dat (een klein beetje technisch onderlegde) klanten dit soort blogjes ook lezen en dan denken dat hun website niet "veilig" is. Dan moeten wij dat gaan weerleggen, wat moeilijk kan zijn met klanten die maar een klein beetje technisch onderlegd zijn.

Misschien is het eens tijd voor een blogje om WP security "mythes" te "busten". Met goed onderlegde argumenten en ook wat je dan wél kan doen om je WP website goed te beveiligen. Wie weet volgt in de toekomst een linkje..

Acties:
  • +8 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 10-05 09:40
Beetje een pet-peeve van mij omdat zoveel mensen dit niet begrijpen. De term is "Security through obscurity" en dit hele kleine stukje grammatica is nogal belangrijk. Waar het om gaat is dat security alleen door obscurity een slecht idee is.

Oftewel; alleen je geld verstoppen maar niet je voordeur op slot doen is geen goed idee. Maar dat betekent niet dat als je voordeur wel op slot zit, het geen quick win kan zijn je geld ook te verstoppen.

Er is helemaal niks mis met het aanvallers lastig te maken en iedereen die dan "Ja maar security by obscurity" gaat roepen heeft het op meerdere niveaus niet begrepen. An sich zou je site secure moeten zijn zelfs als de aanvaller exact je wordpress versie weet, maar ondanks dat is het best een goed idee om gewoon zaken als de versie van wordpress, PHP en apache niet zichtbaar te maken. Veel frameworks hebben dit overigens als default.

Oftewel; defense in depth. Hoe langer het duurt voor een aanvaller om binnen te komen, hoe groter de kans is dat 'ie gespot wordt.

https://niels.nu


Acties:
  • +1 Henk 'm!

  • jrswgtr
  • Registratie: Juli 2017
  • Laatst online: 08-05 15:32
@Hydra
Security through obscurity
Ik weet dat dat de term is, maar ik bedoelde het meer in de zin van: is het security of is het obscurity?(antwoord wist ik stiekem al). Maar dat Nederlandse woord staat misschien een beetje gek tussen die twee Engelse woorden.

Ik denk dat het niet echt iets toevoegt om de admin URL te verbergen. Zoals ik hier boven al aangaf is brute force makkelijk af te weren op server niveau, een ander doel dat dat kan het volgens mij niet dienen. Gevoelige serverinformatie zoals WP, PHP en Apache versie worden sowieso niet prijsgegeven.

  • orillion
  • Registratie: April 2006
  • Laatst online: 10-05 10:45
Wij kozen er soms voor om /wp-admin en /wp-login.php alleen toegankelijk te maken vanaf bepaalde ip-adressen. Dat kan je eigen adres zijn, maar vaak hielp alleen Nederlandse adressen ook al een berg.

  • Hydra
  • Registratie: September 2000
  • Laatst online: 10-05 09:40
jrswgtr schreef op woensdag 22 september 2021 @ 11:16:
Ik weet dat dat de term is, maar ik bedoelde het meer in de zin van: is het security of is het obscurity?
Punt is dat dat niet uitmaakt. De vraag is simpelweg alleen maar of dit soort dingen verbergen het leven van een aanvaller zodanig lastig maakt dat het ze significant meer tijd kost. Dat is de vraag die je jezelf zou moeten stellen.

https://niels.nu


  • Maks
  • Registratie: September 2005
  • Laatst online: 09-05 10:24
jrswgtr schreef op woensdag 22 september 2021 @ 11:16:
Ik denk dat het niet echt iets toevoegt om de admin URL te verbergen. Zoals ik hier boven al aangaf is brute force makkelijk af te weren op server niveau, een ander doel dat dat kan het volgens mij niet dienen. Gevoelige serverinformatie zoals WP, PHP en Apache versie worden sowieso niet prijsgegeven.
Ik heb het wel gedaan om zo de logs wat leesbaarder te houden. Ik heb het idee dat er gewoon zoveel domme bots zijn die wp-login.php gebruiken voor standaard dictionary attacks (schijnbaar is er toch heel veel te halen denk ik).

  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Ik ben het eens met @Hydra, op zich is het "verbergen" van de login pagina geen goede laag security waar je op zou moeten vertrouwen, maar het kan wel net een kleine extra beperking zijn voor geautomatiseerde systemen, en bij een zero-day exploit kan het mogelijk net die extra tijd opleveren om een patch uit te rollen voordat er misbruik van gemaakt wordt.

Dus ik zie ook geen probleem om af en toe wat extra obscurity toe te voegen, het moet alleen niet zo zijn dat je daar ook daadwerkelijk afhankelijk van bent voor je security.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


Acties:
  • +1 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 10-05 09:40
Maks schreef op woensdag 22 september 2021 @ 11:38:
Ik heb het wel gedaan om zo de logs wat leesbaarder te houden. Ik heb het idee dat er gewoon zoveel domme bots zijn die wp-login.php gebruiken voor standaard dictionary attacks (schijnbaar is er toch heel veel te halen denk ik).
We zien dat ook sterk op onze services die uberhaupt niet in PHP zijn: heel veel automatische scans op typische PHP vulnerabilities. O.a. wp-admin pages zie je veel terugkomen.

https://niels.nu


  • Drs_Ben
  • Registratie: November 2019
  • Laatst online: 16:59
Ik zet altijd een .htacces login voor de admin pagina.
Is erg veilig en zorgt voor minder load op je pagina.
Ook plugins etc die bruteforce tegenhouden kost resources.

  • jrswgtr
  • Registratie: Juli 2017
  • Laatst online: 08-05 15:32
@Drs_Ben
Ik zet altijd een .htacces login voor de admin pagina.
Dat is er misschien nog 1 om te onthouden.
Ook plugins etc die bruteforce tegenhouden kost resources.
Plugins zou ik daar ook niet voor gebruiken. Maar onze hosting partner heeft een geavanceerde WAF die het op serverniveau voor ons afhandelt.

https://www.combell.com/n...hield-webhosting-klanten/

[ Voor 8% gewijzigd door jrswgtr op 22-09-2021 11:58 ]


  • Emgeebee
  • Registratie: December 2009
  • Laatst online: 16-02-2023
Het kan imo net dat extra zetje zijn wat je minder interessant maakt voor hackers.

Vergelijk het met je fiets in een fietsenstalling op Amsterdam Centraal. Een tweede slot van €10 gaat een echt goede fietsendief niet stoppen, maar het maakt jouw fiets wel nét iets lastiger dan de 1000 andere fietsen in de stalling zónder tweede slot van €10.

Zo ook bij WordPress; het is zo populair onder hackers vanwege de schaal en uniformiteit. Maak je het net wat minder uniform, dan kan je zomaar net onder de radar duiken van veel hackers.

Acties:
  • +1 Henk 'm!

  • SinergyX
  • Registratie: November 2001
  • Laatst online: 22:10

SinergyX

____(>^^(>0o)>____

Emgeebee schreef op woensdag 22 september 2021 @ 11:58:
Het kan imo net dat extra zetje zijn wat je minder interessant maakt voor hackers.

Vergelijk het met je fiets in een fietsenstalling op Amsterdam Centraal. Een tweede slot van €10 gaat een echt goede fietsendief niet stoppen, maar het maakt jouw fiets wel nét iets lastiger dan de 1000 andere fietsen in de stalling zónder tweede slot van €10.
Niet helemaal het goede voorbeeld, een dief kan daar met verschillende doelen komen. Selectief 'dure' fietsen zoeken, random de 'simpele' sloten pakken, of gewoon 'en masse' los gaan op alles wat je tegenkomt. Als jouw tweede slot dezelfde 'knip en open' methode heeft, dan zal die nog eerder de keuze zijn dan die cilindergehardsuperdupermegasloten.

Standaard methodes bij 'en masse' zie je veel bij CTF's, waar gewoon diverse tools worden losgelaten op websites, ook al weten ze meteen dat het een WP is, gaan ze nog op (automatisch) op zoek naar andere subdirectories met wordlists van 10k, 100k, of meer. Of je kiest een admin url die compleet random is, of je pakt alsnog een woord uit zo'n lijst en is de meerwaarde (en potentiele problemen) van wijzigen van een URL vrijwel nul.

Het is alsof je je voordeur verplaatst van de 'normale' locatie naar ergens in de schuur in de achtertuin, als jij de enige bent in de stad die dat doet, prima.. maar als iedereen juist aanraad de voordeur naar 'minder zichtbare' locaties te verplaatsen, zal een dief zich simpel aanpassen en vrijwel elke poging er van uit gaan dat jouw voordeur op een andere locatie zal zitten.

Nog 1 keertje.. het is SinergyX, niet SynergyX
Im as excited to be here as a 42 gnome warlock who rolled on a green pair of cloth boots but was given a epic staff of uber awsome noob pwning by accident.


  • Emgeebee
  • Registratie: December 2009
  • Laatst online: 16-02-2023
SinergyX schreef op woensdag 22 september 2021 @ 12:06:
[...]

Niet helemaal het goede voorbeeld, een dief kan daar met verschillende doelen komen. Selectief 'dure' fietsen zoeken, random de 'simpele' sloten pakken, of gewoon 'en masse' los gaan op alles wat je tegenkomt. Als jouw tweede slot dezelfde 'knip en open' methode heeft, dan zal die nog eerder de keuze zijn dan die cilindergehardsuperdupermegasloten.

Standaard methodes bij 'en masse' zie je veel bij CTF's, waar gewoon diverse tools worden losgelaten op websites, ook al weten ze meteen dat het een WP is, gaan ze nog op (automatisch) op zoek naar andere subdirectories met wordlists van 10k, 100k, of meer. Of je kiest een admin url die compleet random is, of je pakt alsnog een woord uit zo'n lijst en is de meerwaarde (en potentiele problemen) van wijzigen van een URL vrijwel nul.

Het is alsof je je voordeur verplaatst van de 'normale' locatie naar ergens in de schuur in de achtertuin, als jij de enige bent in de stad die dat doet, prima.. maar als iedereen juist aanraad de voordeur naar 'minder zichtbare' locaties te verplaatsen, zal een dief zich simpel aanpassen en vrijwel elke poging er van uit gaan dat jouw voordeur op een andere locatie zal zitten.
Goede toevoeging, de aanpassing moet er natuurlijk wel voor zorgen dat je je onderscheidt van de massa. :)

  • Tsurany
  • Registratie: Juni 2006
  • Niet online

Tsurany

⭐⭐⭐⭐⭐

De vraag is vooral wat de meerwaarde is van een URL aanpassen als je al zeer sterke wachtwoorden gebruikt, niet de standaard admin user gebruikt en zorgt dat je geen accounts hebt die overal bij kunnen.
Als jij geen 'admin' of een deel van je eigen naam als user gebruikt voorkomt het al een heel stuk brute forcing. Neem een admin username als U50378 en dan moeten ze daar eerst achter komen voordat ze aan je password beginnen. Als je password dan ook nog eens heel lang is en een combinatie is van allerlei cijfers, letters en leestekens dan gaan ze dat niet bruteforcen. Dan nog wat extra methoden om brute force überhaupt te ontmoedigen en je bent al heel ver.

En als je zo ver bent, en een aanvaller deze methoden dus niet kan gebruiken, wat voor nut heeft een ander admin URL dan nog?

Aan de andere kant, waarom niet? Wat kan er werkelijk mis gaan bij het veranderen van die URL? Pas hem van /wp-admin aan naar /7097845 en niemand gaat het ooit raden. Mocht ooit de username en password uitlekken zonder dat iemand weet waar hij bij hoort gaan ze weer minder snel die credentials proberen op deze site.

[ Voor 7% gewijzigd door Tsurany op 22-09-2021 12:25 ]

SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N


  • Luc45
  • Registratie: April 2019
  • Laatst online: 30-04 23:52
Wellicht zul je er wat geautomatiseerde aanvallen mee tegen kunnen gaan, maar ik vind het inderdaad ook meer obscurity. Als je echt kwaad wilt kom je er toch wel achter. Je hebt er m.i. veel meer aan om 2FA te gebruiken en nog liever de admin gedeeltes op IP basis te beperken vanaf de locaties waar beheer echt nodig is.

  • jrswgtr
  • Registratie: Juli 2017
  • Laatst online: 08-05 15:32
@Tsurany
Aan de andere kant, waarom niet? Wat kan er werkelijk mis gaan bij het veranderen van die URL? Pas hem van /wp-admin aan naar /7097845 en niemand gaat het ooit raden.
Dat is hem nou juist. Het is niet gemakkelijk om de URL aan te passen zonder de WordPress core bestanden te wijzigen of ingewikkelde plugins te gebruiken, aangezien wp-login.php een bestand is waar ook in de core van WordPress hard naar verwezen wordt. Er zijn wel plugins die het via omwegen kunnen regelen, maar het voegt een hoop complexiteit toe die niet nodig is imo.

Acties:
  • +1 Henk 'm!

  • Tsurany
  • Registratie: Juni 2006
  • Niet online

Tsurany

⭐⭐⭐⭐⭐

jrswgtr schreef op woensdag 22 september 2021 @ 12:27:
@Tsurany

[...]


Dat is hem nou juist. Het is niet gemakkelijk om de URL aan te passen zonder de WordPress core bestanden te wijzigen of ingewikkelde plugins te gebruiken, aangezien wp-login.php een bestand is waar ook in de core van WordPress hard naar verwezen wordt. Er zijn wel plugins die het via omwegen kunnen regelen, maar het voegt een hoop complexiteit toe die niet nodig is imo.
De vraag is in hoeverre dit te automatiseren is. Als het veel handmatig werk is en weer extra (risicovolle) plugins vereist dan zou ik het simpelweg niet doen.

SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N


  • Nemean
  • Registratie: Juni 2008
  • Laatst online: 10-05 11:16

Nemean

ᵀᴴᴱ ᴷᴵᴺᴳ, ᵀᴴᴱ ᴸᴱᴳᴱᴺᴰ

Ik heb een langere tijd deze plug-in (betaald) gebruikt voor diverse Wordpress sites waar veel bezoekers op afkwamen. Daar zitten diverse functies in omtrent beveiliging van Wordpress of het verbergen van Wordpress. Het is de vraag of je dit alles allemaal nodig hebt of dat je het liever zonder plug-in doet.

Acties:
  • +1 Henk 'm!

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

Iets overdreven misschien, maar bij mijn vorige werk, deden wij de hosting voor een klant. Een derde partij ontwikkelde dan de WordPress website. Deze site draaide eigenlijk met 2 WordPress installaties op 1 database. Bij een van die twee sites, was het admin gedeelte gewoon helemaal verwijderd (de public facing website uiteraard) en op een aparte "redactieserver" was dan de admin wel beschikbaar, die alleen op het interne netwerk van de klant bereikbaar was (of anders via hun VPN). Deze redactieserver was dus niet publiek toegankelijk.

Dit klinkt wellicht als overkill, maar zo weet je wel dat het admin gedeelte alleen beschikbaar is vanuit het gedeelte waar je wilt dat het beschikbaar is. Hoe dat verder onderhuids (je zit toch ook met cookies bijvoorbeeld lijkt me) allemaal geregeld werd, geen idee, daar was de derde partij verantwoordelijk voor, gelukkig.

  • Hydra
  • Registratie: September 2000
  • Laatst online: 10-05 09:40
Tsurany schreef op woensdag 22 september 2021 @ 12:23:
De vraag is vooral wat de meerwaarde is van een URL aanpassen als je al zeer sterke wachtwoorden gebruikt
Veel van dit soort scanners gebruiken dit om te kijken of je uberhaupt wordpress draait. Als ze dat niet weten, komen ze ook minder snel binnen om te kijken of je misschien een versie draait met een (voor hen en niet voor jou) bekende vulnerability. Da's de voornaamste reden om zo min mogelijk informatie weg te geven.

Als je voordeur gewoon doodleuk meldt dat je Wordpress versie X.Y.Z. gebruikt heeft dit natuurlijk geen zin :)

https://niels.nu


  • Hydra
  • Registratie: September 2000
  • Laatst online: 10-05 09:40
Als 'java dev' klinkt dit als de normaalste zaak van de wereld.

https://niels.nu


Acties:
  • +1 Henk 'm!

  • jrswgtr
  • Registratie: Juli 2017
  • Laatst online: 08-05 15:32
@Hydra
Als je voordeur gewoon doodleuk meldt dat je Wordpress versie X.Y.Z. gebruikt heeft dit natuurlijk geen zin
Dat is dan ook niet het geval, de WP login pagina toont geen versienummers.

[ Voor 15% gewijzigd door jrswgtr op 22-09-2021 14:26 ]


Acties:
  • +2 Henk 'm!

  • Oon
  • Registratie: Juni 2019
  • Niet online

Oon

Ik zou gewoon netjes gebruik maken van fail2ban (dus op firewall niveau bannen bij mislukte WP logins), MFA afdwingen (op z'n minst TOTP, als client certificaten of FIDO2 geen optie is), en indien nodig zelfs een captcha (zonder user interact, dus bijv. reCaptcha v3) op het login scherm gooien.

Je kan de URL wel verbergen maar ze komen er toch achter als ze willen. Je stopt wel een groot deel van de geautomatiseerde aanvallen, maar ook alleen als je redirect pagina niet ook gewoon laat weten dat het om een WP site gaat. Veel van die plugins laten wel een lege pagina zien op wp-login.php, maar laten genoeg andere opties over voor scanners.

[ Voor 27% gewijzigd door Oon op 22-09-2021 14:27 ]


Acties:
  • +1 Henk 'm!

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

Hydra schreef op woensdag 22 september 2021 @ 14:23:
Als 'java dev' klinkt dit als de normaalste zaak van de wereld.
Nou ja, schematisch is het zo:
code:
1
[admin] <----> [database] ----> [website]
Met de pijlen geef ik de communicatie richtingen aan. Vanuit admin kon je dus zowel lezen als schrijven uiteraard. Website dus alleen lezen. Lijkt me niet helemaal ook de normaalste zaak in Java, maar ik ben dan idd geen Java, maar PHP dev (geweest).

Waarbij in dit geval de admin/redactieserver een andere machine was dan zowel database als website, alles is een eigen machine (en website dan twee, een met WordPress voor ophalen content en andere voor Varnish cache). De website kon dus ook alleen als read-only naar de database toe etc. Al was de daadwerkelijke infra eigenlijk nog anders, met Varnish er nog tussen naar de bezoekers toe.

[ Voor 25% gewijzigd door CH4OS op 22-09-2021 14:38 ]


  • evadnl
  • Registratie: Augustus 2010
  • Laatst online: 10-05 12:04
Wij gebruiken hier een betaalde plugin voor genaamd Wordfence. Als je een X aantal pogingen doet om in te loggen word je IP gewoon geblokkeerd voor een X periode. Kan wat gedoe opleveren als je kantoor IP bijvoorbeeld geblokkeerd word, maar bij goede configuratie krijgt de admin hier een melding van en kan deze de blokkaade opheffen.

Daarnaast maken we nu op sommige sites ook gebruik van SAML op basis van Azure AD. Is ook een optie, dan is de hele WP-admin login 'foetsie'.

  • jrswgtr
  • Registratie: Juli 2017
  • Laatst online: 08-05 15:32
@evadnl
Wij gebruiken hier een betaalde plugin voor genaamd Wordfence.
Ben inderdaad bekend met die plugin. Alleen wil ik nou juist zo veel mogelijk plugins vermijden. Zelfs een security plugin kan een security issue zijn :) en vaak voegen dergelijke plugins veel meer toe dan je nodig hebt. Aangezien brute force dus ook op server niveau te bestrijden is hou ik het liever daar maar bij. Maar ieder zijn keus natuurlijk!
Daarnaast maken we nu op sommige sites ook gebruik van SAML op basis van Azure AD. Is ook een optie, dan is de hele WP-admin login 'foetsie'.
Daar heb ik me ook in verdiept, maar dat is behoorlijk complex om te configureren. Zeker om het zelf te bouwen, of je komt al snel uit bij betaalde plugins, zeker als je multisite support wil. Bovendien moet je voor iedere site weer een Enterprise AD application aanmaken in Azure. En dan moet je nog individuele klanten toegang gaan geven tot hun eigen website.

Wat is jullie werkwijze hierin en gebruiken jullie een plugin zoals deze? https://wordpress.org/plu...e-saml-20-single-sign-on/

Acties:
  • +1 Henk 'm!

  • crypt0rr
  • Registratie: Juni 2010
  • Laatst online: 09-05 15:57
Zoek ook eens naar Wordpress user enumeratie, er zijn namelijk meerdere dingen die hierin voorzien. Bijvoorbeeld de standaard beschikbare API. Dan kan je nog zo mooi ‘random’ je usernames maken, liggen ze voor het oprapen onder je deurmat.

AdGuard Home


  • jrswgtr
  • Registratie: Juli 2017
  • Laatst online: 08-05 15:32
@CH4OS
Waarbij in dit geval de admin/redactieserver een andere machine was dan zowel database als website, alles is een eigen machine (en website dan twee, een met WordPress voor ophalen content en andere voor Varnish cache). De website kon dus ook alleen als read-only naar de database toe etc. Al was de daadwerkelijke infra eigenlijk nog anders, met Varnish er nog tussen naar de bezoekers toe.
Best interessant.

Een modernere aanpak hiervan zou zijn om de tweede WordPress site te vervangen door een JS frontend en dan content op te halen via de REST-API van de eerste. Al is dan het adres van de backend altijd zichtbaar voor de cliënt.

Door PHP, in jouw geval WP, te gebruiken hou je het adres van de backend (in jouw geval de database) geheim, wat op zich best slim is.

Acties:
  • +1 Henk 'm!

  • boswandeling
  • Registratie: Oktober 2001
  • Laatst online: 00:42
Ik heb een .htaccess op /wp-admin gezet met user/pass simpel en effectief, had veel last van brute force aanvallen, nu niets meer.

  • evadnl
  • Registratie: Augustus 2010
  • Laatst online: 10-05 12:04
jrswgtr schreef op woensdag 22 september 2021 @ 18:26:
@evadnl


Wat is jullie werkwijze hierin en gebruiken jullie een plugin zoals deze? https://wordpress.org/plu...e-saml-20-single-sign-on/
Wij gebruiken inderdaad die plugin, en ze zijn niet goedkoop met de betaalde versie. We gebruiken inderdaad ook een multisite installatie. Maar we hebben de afweging gedaan van de kosten om op iedere site iemand toe te voegen aan de hand van een script (handmatig want ja, je wil niet iedereen teogang geven tot elke site) en dmv een groepje in de AD. Dat laatste is toch net wat sneller en makkelijker.

Wat betreft Wordfence, je kunt een hoop uitschakelen, en zelfs 2FA instellen, echter alleen de keus uit Google Authenticator. Op server level kan je ook een hoop doen, we hebben naar Fail2ban gekeken, dit werkte ansich prima, alleen je moet dan om 'snel' te unblocken wederom inloggen op de server om de iptable rule eruit te jassen.

Het security through obscurity stuk hebben wij ook bekeken maar liepen al gauw tegen vervelende issues aan, niet eens enkel door plugins. Dit was echter wel rond wordpress versie 4. Wellicht dat het nu beter gaat :+.

  • Waarnemer
  • Registratie: November 2013
  • Laatst online: 06-05 17:09
Joomla heeft een plugin AdminExile, daar kun je een url param query als vereiste voor de /administrator toevoegen.. /administrator?token=bladibla
Er zijn er wat meer. Er kan een eigen (re)direct worden aangegeven bij een verkeerde token.. bijvoorbeeld een 404 pagina.. voor de "obfuscation" werkt het perfect. Token is een soort extra password dan.

Maar de fail2ban van @Oon is echt wel mijn voorkeur als het gaat om BruteForce.. wel moet je dan wel controle hebben over je server setup.

Ik gebruik het graag.. heel handig.. een uitgesloten bezoeker kan meteen ook niet meer naar al het andere dat ik host. Ik bedien ook meteen mijn CloudFlare blocklist met Fail2Ban.. heel handig.

Acties:
  • +1 Henk 'm!

  • P-Storm
  • Registratie: September 2006
  • Laatst online: 09-05 12:04
Ik denk dat je heel erg snel naar een algemene hoe bescherm ik een website komt. Je moet dan ook per laag kijken van, heb je daar toegang toe, en hoe kan je het afvangen.
  • Fail2Ban: Op server niveau afvangen
  • .htacces: Zorgen dat er een extra inlog plaatsvind
  • MFA: Zorgen dat er meer factoren nodig zijn
  • Admin/Password aanpassen: Indien het mogelijk gebruikersnaam maar ook zeker password aanpassen. Om een lang verhaal kort te houden, gebruik hiervoor een secure password.
  • Login URL afschermen: Kan bijvoorbeeld door een andere locatie te gebruiken.
  • View van Edit scheiden: Zorgen dat je alleen van een gewhiteliste IP een mogelijke edit kan doen.Zie de uitleg van @CH4OS .
  • Plugins: alleen gebruiken als je geaudit hebt
  • Automatic updates: Gebruik hier een policy in. Soms worden security gaten al direct misbruikt en moet je hier voor mogelijk updaten.
  • Pen Tests: Mogelijk ben je blind aan het staren voor een security flaw, en kan dit door een 3e party gevonden worden.
  • ...
De vragen die je ook wilt stellen zijn:
  • Welke aanvallen wil ik mijzelf voor beschermen? High profile website?
  • Welke manier kan je zelf recoveren, indien je jezelf geband hebt
  • Wat is je update policy, monitor je alle code die in de site gaat of niet. Is dit hetzelfde voor plugins?
  • Zelfde voor de database en server waar het op gehost wordt.
  • Versions verbergen: Hoe minder je aan een aanvaller verteld, hoe 'moeilijker' het wordt. 'Apache 2.4.49' zegt al veel meer dan 'Apache' of zelfs niets.
  • HTTPS/CORS/X-Frame-Options/... Op header niveau veiligheid strakker zetten.
  • Hoeveel geld heb ik er voor over om security stap X te waarborgen?
Vaak bij de goedkopere pakketen kan je niet alle lagen inzetten. Door bovenstaande punten in kaart te brengen heb je al meer gedaan dan 80% van de andere sites [citation needed]. Het is dan ook iets waar veel tijd in kan zitten. Er zijn sites zoals onder andere OWASP die voornamelijk proberen te informeren bij de valkuilen.

offtopic:
Dit is nu voornamelijk een algemene opsomming geworden in plaats voor specifiek WordPress, maar is ook zeker wel van toepassing daarvoor

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

Waarnemer schreef op woensdag 22 september 2021 @ 19:22:
Joomla heeft een plugin AdminExile, daar kun je een url param query als vereiste voor de /administrator toevoegen.. /administrator?token=bladibla
Er zijn er wat meer. Er kan een eigen (re)direct worden aangegeven bij een verkeerde token.. bijvoorbeeld een 404 pagina.. voor de "obfuscation" werkt het perfect. Token is een soort extra password dan.
Ik begrijp alleen niet helemaal wat je hiermee zeggen wilt, gezien het in dit topic om WordPress gaat. Ja, voor WordPress zijn dit soort plugins ook beschikbaar, maar zoals gezegd, zitten wat zaken ook hardcoded in WordPress, waardoor dit soort plugins eerder een schijn beveiliging is en potentieel zelfs nieuwe gaten introduceert: niet wenselijk dus.

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

jrswgtr schreef op woensdag 22 september 2021 @ 18:46:
Een modernere aanpak hiervan zou zijn om de tweede WordPress site te vervangen door een JS frontend en dan content op te halen via de REST-API van de eerste. Al is dan het adres van de backend altijd zichtbaar voor de cliënt.
De JS front-end praat dan met de REST API van WordPress, niet direct met de backend dus, tenzij die twee bij elkaar staan uiteraard, maar dat hoeft dus niet. Krijg je wel volledige vrijheid van hoe de website eruit komt te zien, waar je anders aan de WordPress templating engine vast zit.
Door PHP, in jouw geval WP, te gebruiken hou je het adres van de backend (in jouw geval de database) geheim, wat op zich best slim is.
Sterker nog, uiteindelijk werd het meeste opgevangen door de Varnish cache. Vroeg je een webpagina op, werd die vanuit de cache opgehaald indien beschikbaar (en nog valide). Zo nee (of niet meer valide) werd de pagina via de webserver opnieuw opgehaald / gerenderd en wederom in de cache opgeslagen. :)

  • Waarnemer
  • Registratie: November 2013
  • Laatst online: 06-05 17:09
CH4OS schreef op donderdag 23 september 2021 @ 10:35:
[...]
...zitten wat zaken ook hardcoded in WordPress, waardoor dit soort plugins eerder een schijn beveiliging is en potentieel zelfs nieuwe gaten introduceert: niet wenselijk dus...
er zijn inderdaad redenen om gewoon beter geen Wordpress te gebruiken.

en nee.. de url param query methode gaat echt geen gaten erbij maken die er al niet waren.
grote voordeel van die url param query is dat je die toepast op alle paden van de admin omgeving, of zoals de J! plugin doet, het hangt aan de sessie.

Maar ja de beste tegen bruteforces en script kiddies is nog steeds fail2ban.. alleen kan niet iedereen dat gebruiken. Dan is obfuscation the next best thing.

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

Waarnemer schreef op donderdag 23 september 2021 @ 11:59:
en nee.. de url param query methode gaat echt geen gaten erbij maken die er al niet waren.
grote voordeel van die url param query is dat je die toepast op alle paden van de admin omgeving, of zoals de J! plugin doet, het hangt aan de sessie.
Je zal toch ergens logica moeten hebben om dat af te handelen. Ook daar kan een fout in zitten.

  • Waarnemer
  • Registratie: November 2013
  • Laatst online: 06-05 17:09
CH4OS schreef op donderdag 23 september 2021 @ 12:01:
[...]
Je zal toch ergens logica moeten hebben om dat af te handelen. Ook daar kan een fout in zitten.
Deze redenatie maakt alles een potentiele methode om niet te gebruiken.. een foute fail2ban is ook niet goed.
Een foute .htaccess enzovoorts, enzovoorts... kortom beter geen website maken dan maar.. ook geen fouten.

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

Waarnemer schreef op donderdag 23 september 2021 @ 12:05:
Deze redenatie maakt alles een potentiele methode om niet te gebruiken.. een foute fail2ban is ook niet goed.
Een foute .htaccess enzovoorts, enzovoorts... kortom beter geen website maken dan maar.. ook geen fouten.
Nou ja, meer omdat in WordPress plugins best vaak security leaks zitten, vaker dan in een fout geconfigureerde fail2ban of .htaccess. Daar heb je zelf veel meer de controle over dan zo'n plugin. Aanpassingen die je zelf in een plugin aanbrengt, kunnen dan later immers door een update vanuit de ontwikkelaar ervan overschreven worden waardoor eea verdwijnt.

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Met een eenvoudige regel in .htaccess kan je een extra auth instellen, of een 404 doen op dat path en een nieuw path naar wp-login rewriten etc etc. Dat is foolproof te doen en wordt niet beinvloed door php code.

Het ‘obscurity’ argument wordt vaak te ruim gebruikt: Dit moet op zichzelf gewoon niet als kritieke beveiligingslaag gezien worden. Maar als je alle automatische scanners in 1x zonder logs een 404 geeft, vallen de echte aanvallen, of uberhaupt goedbedoelde hits naar buggy pagina’s etc tenminste beter op.

[ Voor 10% gewijzigd door Voutloos op 23-09-2021 12:34 ]

{signature}


  • Waarnemer
  • Registratie: November 2013
  • Laatst online: 06-05 17:09
CH4OS schreef op donderdag 23 september 2021 @ 12:07:
[...]
Nou ja, meer omdat in WordPress plugins best vaak security leaks zitten
Tja, dan moet je beter wegblijven bij WorpPress.
Dat is wel los van de afweging of je op wat voor manier dan ook obfuscation toepast.


Voro het merendeel van de WP gebruikers (maar ook Joomla of Drupal) is het dat ze op een shared hosting zitten. Ze hebben eigenlijk niet heel veel andere keuze dan een stukje obfuscation.

Plugins zijn eenvoudig en laagdrempelig. Dat er problemen ontstaan met de inner URLs in WP, dat ligt voornamelijk aan WP developers en/of de plugin developers.. jammer. Maar het is helaas zo. Dat maakt de methode an sich niet minder goed. Het zou je wellicht wel kunnen laten overwegen geen WP meer te gebruiken als het probleem werkelijk zo groot is.

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

Waarnemer schreef op donderdag 23 september 2021 @ 15:03:
Tja, dan moet je beter wegblijven bij WorpPress.
Dat is wel los van de afweging of je op wat voor manier dan ook obfuscation toepast.
Snap ik. Zelf gebruik ik tegenwoordig liever iets custom made, aan de hand van een van de bekendere frameworks. :)
Pagina: 1