*WPS hide login is een handige plugin om wp-admin link aan te passen
*Sowieso Wordfence
*admin niet admin heten maar anders

Met WP All In One Security kun je de login hernoemen, heb je een firewall en kun je de bestandsrechten fixen (en nog veel meer). Ik gebruik ook vaak nog een 'mathematical captcha' op het inlogscherm, en een Honeypot. Ook kan ik je het gebruik van Cloudflare aanraden, zelfs met de gratis account daarvan heb je al aardig wat extra bescherming. Bovendien wordt de website er ook sneller van. Inloggen in WP is soms wat lastig als je Cloudflare combineert met een security-plugin, en helemaal als jouw hostingprovider ook al wat extra veiligheidsmaatregelen heeft getroffen.

Origineel gepost door markh

Dank voor alle tips en adviezen!

- reseller pakket klinkt als een goede om te voorkomen dat 1 rotte site alle andere doet besmetten
- inlogpagina (.../wp-login.php) onvindbaar maken --> Hoe kan dat op een goede manier?
- map/bestandrechten --> is dit verstandig aan te passen?
- opnieuw installeren beste optie --> WordFence instellen, wachtwoorden aanpassen (FTP, database, Wordpress login, hosting account) en alle rotzooimappen en scripts verwijderen is niet voldoende en nog steeds een risico?

Bedenk wel dat login url verbergen en/of 2FA maar een klein gedeelte van beveiliging is.

En voor wie doe je dit hoofdzakelijk? Voor toevallige passanten en voor de beginnende hacker/cracker.


Maar zolang je bijvoorbeeld via de xml rest api nog brute force kunt inloggen, en/of tientallen plugins en/of extra (onnodige) theme installaties hebt, etc....

Origineel gepost door markh

Nieuw inzicht van de hack:
Blijkbaar was er een "spam" script dat "gravityforms" mappen aanmaakte. Die map bevatte op een heel diep niveau een paar scripts die rotzooiden in de website (eval() functie?). Die gravityforms map bevatte echter 8 andere mappen, telkens "a", "b", "c" etc. En die mappen bevatten op hun beurt weer "a", "b", "c" etc.

Uiteindelijk kwam het dus op vele duizenden mappen neer, bijv.:

- site.nl/wp-content/gravityforms/d/a/b/b/e/....script.php

De rechten van alle mappen en de sceripts in die mappen waren zo ingesteld dat ik ze niet zomaar kon verwijderen of aanpassen. Daarvoor moesten eerst alle duizenden mappen worden geüpdatet naar 755 rechten en dan pas kon ik ze verwijderen. Gelukkig kon het in Filezilla in bulk, maar het verwijderen van die paar scripts kostte daardoor veel tijd.

Kan best zijn dat ze via een andere plugin of via theme of via ander domein! zijn binnengekomen en een andere directory (in jouw geval gravityforms) hebben gebruikt om zo ingang van de hack te maskeren.


Hopelijk voor je niet nodig, maar een volgende keer kun je via Cpanel filemanager proberen de directories- en bestandsrechten in bulk aan te passen, kan dacht ik ook in bulk voor onderliggende directories en bestanden.