WP site gehacked tips gevraagd

Status
Niet open voor verdere reacties.

damnsharp

Terugkerende gebruiker
Lid geworden
6 jan 2012
Berichten
1.385
Goedemiddag,
Op een shared hosting server zijn diverse WP sites van mij gehacked.
Er staan security plug-ins op sites zoals MalCare of WordFence maar heeft niet genoeg geholpen.
Is er wat anders te doen dan alle bestanden te verwijderen, databases leegmaken en back-ups terugzetten?
Zie plaatje wat voor bestanden / mappen er nu staan bij diverse sites.

2018-08-10 15_52_17-FlashFXP.jpg

Alvast bedankt!
 
Ga eerst eens met je hosting uitzoeken of de hack via jouw site komt. De log-files moeten uitsluitsel geven. Ga ook na of al je plugins up-to-date waren.

Een backup terugzetten moet zeker gebeuren, maar zorg ervoor dat deze schoon is, en dat je weet waar het lek zit, anders ben je morgen weer aan de beurt.
 
Laatst bewerkt:
Hieronder een aantal tips voor beveiliging.

1. Zorg dat de website en de uitbreidingen up-to-date zijn. In de laatste versies zijn recente bugs opgelost.

2. Informeer bij je provider of de php versie recent is. Dit kun je bij sommige providers in het .htaccess bestand of in het control panel instellen. Controleer ook of de website software geschitk is voor deze recentere php versie.

3. Gebruik verschillende sterke wachtwoorden voor: control panel (provider), website beheer (cms), database user (cms), FTP user, en voor de mailbox die je website gebruikt.

4. Gebruik als het mogelijk is nergens "admin" of "beheerder" als gebruikersnaam.

5. Wijzig als het mogelijk is de naam van je cms-beheer map.

6. Permissies van mappen maximaal 755, van bestanden 444, tenzij het niet anders kan. Als je een schrijfbaar bestand nodig hebt, probeer dan de permissies van dit bestand in deze volgorde in te stellen tot het werkt: 644, 664, 666.
Een alternatief is om de gehele inhoud van een map af te schermen. Dit doe je door in de betreffende map een .htaccess bestand te zetten met de volgende inhoud.
Code:
<Files ~ "\.(php|php3|php4|php5|phtml|pl|cgi)$">
order deny,allow
deny from all
</Files>

7. Zet in mappen die geen index.html of index.php hebben een dummy bestand met de naam index.html zonder tekst (bestandgrootte 0 bytes)

8. Als je een cms of blog met rechtenbeheer voor de beheerders hebt, neem dan voor het dagelijks beheer een inlognaccount met minder rechten.

9. Zorg dat bezoekers nooit bij een php bestand kunnen komen waar de opdracht phpinfo() in staat. Als je dit toch gebruikt, scherm het dan af met een .htpasswd bestand. Gebruik hiervoor een online "htpasswd generator" en volg de aanwijzingen. Gebruik geen voor de hand liggende naam zoals "admin".

10. Zet in de root een bestand robots.txt met als enige inhoud: User-agent: *

11. Configureer een backup cyclus, meestal kan dit in het control panel.

12. Betere Authenticatie bij inloggen in website applicaties (cms, blog, enz)
a) Single-Factor Authenticatie controleert 1 factor, bijv. een sterk wachtwoord. Belangrijk is dat dit moeilijk door anderen is te raden, te achterhalen of te klonen.
b) Veiliger is de Two-Factor Authenticatie waarbij 2 verschillende factoren worden gecontroleerd, bijv. eigen wachtwoord én code via smartphone.

Authenticatie Factoren zijn
iets dat je weet (wachtwoord, pincode, toegangszin)
iets dat je hebt (smartcard, smartphone)
iets dat je bent (iris-patroon, vingerafdruk, stemherkenning)

13. Je kunt in een .htaccess bestand goede beveiling regelen. Regels die met een # beginnen zijn commentaar regels voor wat extra info. De onderstaande code staat in een bestand met de naam .htaccess in de root van je domein (www.example.nl/.htaccess). De provider heeft ervoor gezorgd dat dit bestand niet te lezen is voor de buitenwereld.
Code:
### page not found (check the name of your 404 file)
ErrorDocument 404 https://www.example.nl/404.html

### rewrite on
RewriteEngine on

### no index, no server info
Options -Indexes
ServerSignature Off

### base (in root / or in direcory /subdir)
RewriteBase /

### force https (only with https)
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

### wordpress: block include files
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]

### wordpress: rewrites urls as /parent/child
RewriteRule ^index.php$ - [L]
RewriteRule ^login/?$ /wp-login.php [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

### wordpress: block config
<Files wp-config.php>
Order allow,deny
Deny from all
</Files>

### deny cgi, perl, python
<FilesMatch "\.(cgi|pl|py)">
Order allow,deny
Deny from all
</FilesMatch>

### block file extensions
<FilesMatch "(^#.*#|.(bak|config|dist|htm|inc|ini|log|sh|sql)|~)$">
Order allow,deny
Deny from all
Satisfy All
</FilesMatch>

### security
<IfModule mod_headers.c>
# disable ETags
Header unset ETag
FileEtag None
# same origin, for example no iframes on other sites
Header set X-Frame-Options "SAMEORIGIN"
</IfModule>

### security enhancements
# if the uri contains http:
RewriteCond %{QUERY_STRING} http\: [OR]
# or if the uri contains [ or ]
RewriteCond %{QUERY_STRING} \[ [OR]
RewriteCond %{QUERY_STRING} \] [OR]
# or if the uri contains <script>
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# or if the script trying to set a php globals variable via url
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# or if any script is trying to modify a _request variable via url
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
# or if the uri contains union
RewriteCond %{QUERY_STRING} UNION [OR]
# or if the uri contains double slash
RewriteCond %{QUERY_STRING} // [OR]
# or if the request contains /proc/self/environ (lfi hack)
RewriteCond %{QUERY_STRING} proc\/self\/environ [OR]
# or if the uri contains asterisk
RewriteCond %{QUERY_STRING} \*
# then 403 deny request
RewriteRule ^.*$ - [F,L]
 
Laatst bewerkt:
Goede tips! Ben gisteren hele dag bezig geweest om sites naar eigen plek te verhuizen.
Verschillende sites (veelal testsites) stonden onder 1 account dus waren alle doelwit.

MalCare heeft van alles gevonden en lastige nu is dat het opgelost lijkt te zijn maar dat er op een gegeven moment er toch weer een ongewenst bestand komt dat weer aan het spammen is.

Heb ftp wachtwoorden en user wachtwoorden gewijzigd.

Zal andere tips van jou @bron in gaan voeren zoals beter de bestandsbeveiliging en ook htaccess aanpassingen.
Verschillende dingen die je opnoemt had ik al gedaan.

Tip 5 en 7 snap ik niet overigens. Wat bedoel je met wijzig root naam CMS map en waarom een html bestandje plaatsen in lege directory en bedoel je echt elke lege directory?
En tip 10 wat helpt dat voor hackers?


De oorzaak is overigens nog niet gevonden... vermoedelijk 1 site die toch wat achter liep (door vakantie) met updates.
 
5) Bij WP is het voor zover ik weet niet mogelijk om de map "wp-admin" te hernoemen tenizj je in de php gaat editen (niet aanbevolen). Bij andere cms'en en webshops is het soms wel mogelijk om de admin map te hernoemen zodat hackers de admin map niet makkelijk kunnen vinden. Je kan wp-admin wel afschermen in een .htaccess zodat alleen jouw eigen IP adres toegang heeft tot deze map.

7) Niet elke provider gaat netjes om met een volle- of lege map waar geen index bestand in staat. Af en toe kom ik een provider tegen waar ik de mapstructuur kan inzien door te browsen naar een map waar geen index in staat. In de meeste cms'en en webshops is tegenwoordig standaard elke (sub)map zonder index voorzien van een dummy index.html (of dummy index.php).

10) Het is netjes om een robots.txt bestand in de root te plaatsen voor zoekmachines. In dit bestand staat beschreven welke mappen niet geindexeerd mogen worden maar een zoekmachine hoeft zich hier niet aan te houden. Stel, in robots.txt staat "Disallow: /backups/" dan weet iedereen dat je daar je backups bewaart. In het algemeen kan je beter zo weinig mogelijk vertellen over je mapstructuur.
 
Laatst bewerkt:
@bron dank je wel voor de duidelijke uitleg. Daar kan ik fijn weer wat mee. Ik zet de vraag op opgelost.
 
Wordfence zet ook bestanden in je .htaccess die te maken hebben met veiligheid.
Verder zet ik dat bestand samen met config.php op 444 (rechten).

Op een aantal van mijn websites heb ik als veiligheid iThemes Security. Die vind ik beter dan Wordfence (en makkelijker).
Op andere heb ik dus Wordfence, maar dat ga ik toch veranderen naar iThemes Security.

Verder Limit Login Attempts plug-in en two-factor authenticatie inschakelen. https://webwereld.nl/security/93249-5-dingen-die-je-moet-weten-over-two-factor-authentication
 
@femke, de Two-Factor Authenticatie miste inderdaad in mijn lijstje hierboven. Ik heb dit als punt 12 erbij gezet, thanx.
Je aanvulling over de Permissies stond er al in als puntje 6.

Een plugin is voor velen van ons makkelijk in gebruik, anderen doen de beveiliging liever met de hand. Eén ding is zeker, geen enkele website is 100% waterdicht.
 
Fijn zo nog meer aanvullingen :thumb: @femke en @bron.
Die plugin heb ik vaker van gehoord maar was weer uit mijn geheugen zeg maar ;-) WordFence vind ik niet zo fijn dus ga zeker die andere proberen en die is in developer licentie ook betaalbaar.
De rechten zal ik ook beter gaan aanpassen op bestanden, 444 op htaccess en wp-config is logisch (alleen read).
 
Ikzelf heb de gratis iThemes Security.
Ik vind deze ruimschoots voldoende, omdat je dus zelf ook nog een boel kan doen. Je kan altijd de gratis doen en als je toch wilt betalen voor iets meer, kan je dat zo regelen via de plug-in zelf.
Het is maar een tip.
 
Laatst bewerkt:
Als je twijfelt over welke bestanden je op 444 kan/mag zetten, zet dan in ieder geval alle bestanden in de root op 444 en alle bestanden in wp-admin op 444 en doe verder niets met de permissies in de submappen hiervan. Zet 444 alleen op de bestanden, niet op de mappen.
 
Laatst bewerkt:
Het mooie van iThemes Security is dat deze aangeeft welke rechten je op welke mappen moet zetten, zodat het veiliger is.
Zij geven dus ook die 444 aan voor die 2 bepaalde mappen die ik al aangaf. Wordfence vind ik zelf wat moeilijker te "lezen".

Een nadeel van iThemes Security is dat de logbestanden niet meer tegelijk kan verwijderen, in de gratis versie.
Je kan wel instellen dat je bijv. 2 log bestanden wilt behouden, dan overschrijft hij de oudere steeds en wordt je logbestand niet te groot.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan