Wordpress-website gehacked; wat nu?

[Daam]

Beste Tweakers,

Vandaag kwam ik er tot mijn verbazing achter dat mijn wordpress-website gehacked is. Mijn website is "vervangen" door een leeg Wp-theme en als ik naar Wp-admin surf word ik doorgestuurd naar de Wp-admin van een compleet vreemde site. Voor nu heb ik via de FTP alle bestanden en mappen die met Wordpress te maken hebben van mijn server af gegooid (ik heb ze tijdelijk lokaal opgeslagen).

Erg vervelend allemaal, ik weet wel het e.a. van webdesign af, maar niet voldoende dat ik mij hier raad mee weet. Ik heb al meerdere topics gelezen hier op tweakers, maar ik blijf toch met een aantal vragen zitten.

Hoe krijg ik alles weer up-and-running?
Van wat ik lees is het beste om een schone installatie te doen. Is het dan afdoende om alle files van de server te verwijderen (wat ik al heb gedaan) en de tabel (directAdmin?) te verwijderen? En hierna een schone installatie doen?

Hoe krijg ik de site (deels) terug?
Dat de site weg is is vervelend, al ben ik niet veel data kwijt. De site was nog in aanbouw en was letterlijk "leeg". Wel heb ik veel tijd gestoken in het instellen en customizen van een aangekocht Wp-theme. Van deze theme heb ik een backup, maar niet van mijn aanpassingen. Zijn deze instellingen nog te redden of zijn ze overschreven door de hacker?

Ik hoor het graag, alvast dank!

[CH4OS]

Als je goede backups hebt, kun je toch gewoon van de dag voordat de hack was terug zetten? Als de hoster de DirectAdmin omgeving goed heeft opgezet, dan heb je als het goed is een backup, misschien zelfs met een schaduwkopie. Dan verlies je het minste. Vraag het eventueel even na bij de hoster, geef hem daarbij een datum van welke datum je de bestanden dan hersteld wilt hebben.

En ja, het beste is om een schone installatie te doen met andere wachtwoorden en een betere beveiliging.

[ Voor 37% gewijzigd door CH4OS op 06-12-2019 01:18 ]

[PeeVv]

Daam schreef op vrijdag 6 december 2019 @ 01:09:
een aangekocht Wp-theme.

Wel van een legitieme site? Als je een theme van een minder legale bron hebt dan is de kans vrij groot dat er een backdoor in de theme zit.

Er is een mogelijkheid dat de hackers niet aan je database hebben gezeten, daar staan alle instellingen in. Dan kan je, als je zeker weet dat de problemen verholpen zijn, de bestanden weer terugzetten en dan heb je alle instellingen nog (als je een backup van de database hebt of de database niet verwijderd hebt). Maar je kan natuurlijk nooit zeker weten of ze wel of geen toegang hebben (gehad) tot de database, dus het beste is altijd vanaf 0 weer opnieuw beginnen.

[Nemean]

Ik zou als eerste controleren of je nog een goede backup configuratie gemaakt/ingesteld hebt. Je kunt dan een dag of een x-aantal dagen voor de hack terugplaatsen. Daarnaast kan ik niet helemaal uit je verhaal opmaken of je managed hosting hebt of bijvoorbeeld een eigen server/VPS. Indien je een managed hosting hebt kun je wellicht nog terugvallen op je hostingpartij.

Mocht je geen back-up hebben, zou ik jezelf wel afvragen of je nog wilt voortborduren op een omgeving welke recent "gehacked" is geweest. Je weet niet welke impact dit heeft gehad op je Wordpress omgeving en/of database. Ik zou het zekere voor het onzekere nemen en met een schone installatie beginnen.

Voor je volgende installatie zou je kunnen overwegen een plug-in als deze te gebruiken: Hide My WP. Met deze plug-in kun je o.a. verbergen dat je Wordpress gebruikt.

[Daam]

Dank voor de reacties! De website is gehost bij Versio. Wel onder een budget-pakket dus ik ben heel benieuwd of zij backups hebben gedraaid van mijn site. Morgen maar eens contact met de klantenservice opnemen.

Ik begrijp uit jullie reacties dat het in ieder geval het beste zal zijn om een schone installatie te doen, al ben ik veel knutsel- en probeertijd aan de website kwijt (custom CSS, enz.) Zelf heb ik nooit backups gemaakt. Erg stom, want van al mijn bestanden heb ik twee backups. Behalve van mijn website.

PeeVv schreef op vrijdag 6 december 2019 @ 01:20:
[...]

Wel van een legitieme site? Als je een theme van een minder legale bron hebt dan is de kans vrij groot dat er een backdoor in de theme zit.

Het theme is aangekocht via Themeforrest, dat is allemaal legitiem gebeurd.

Stél dat ik verder zou willen gaan met deze WordPress-installatie. (Of dat slim is even buiten beschouwing latend.) Is het dan een kwestie van via de FTP een schone WordPress installatie doen, het theme in kwestie installeren en dan pikt deze “zo” alle settings uit de table weer op? Of denk ik nu te makkelijk?

Vanzelfsprekend ga ik kijken hoe ik mijn volgende wordpress-installatie beter kan beveiligen. Las ergens al iets met een htacces wachtwoord, alleen nog niet voldoende in verdiept om te kijken of dit niet boven mijn pet gaat.

[Nemean]

Daam schreef op vrijdag 6 december 2019 @ 01:44:
Dank voor de reacties! De website is gehost bij Versio. Wel onder een budget-pakket dus ik ben heel benieuwd of zij backups hebben gedraaid van mijn site. Morgen maar eens contact met de klantenservice opnemen.

Ik begrijp uit jullie reacties dat het in ieder geval het beste zal zijn om een schone installatie te doen, al ben ik veel knutsel- en probeertijd aan de website kwijt (custom CSS, enz.) Zelf heb ik nooit backups gemaakt. Erg stom, want van al mijn bestanden heb ik twee backups. Behalve van mijn website.


[...]


Het theme is aangekocht via Themeforrest, dat is allemaal legitiem gebeurd.

Stél dat ik verder zou willen gaan met deze WordPress-installatie. (Of dat slim is even buiten beschouwing latend.) Is het dan een kwestie van via de FTP een schone WordPress installatie doen, het theme in kwestie installeren en dan pikt deze “zo” alle settings uit de table weer op? Of denk ik nu te makkelijk?

Als je geen wijzigingen in je database hebt aangebracht zou je in principe de bestanden uit de Wordpress ZIP kunnen uploaden naar je FTP en vervolgens de WP-config.php (staat in de root van je public_html) kunnen aanpassen en laten verwijzen naar de database van je vorige installatie. Let wel dat je plug-ins en thema's die je gebruikt hebt weer terug installeert.

Het gaat hierbij om de volgende regels in je WP-config:

code:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'XXXXXX' );

/** MySQL database username */
define( 'DB_USER', 'XXXXXX' );

/** MySQL database password */
define( 'DB_PASSWORD', 'XXXXXX' );

/** MySQL hostname */
define( 'DB_HOST', 'localhost' );

/** Database Charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8' );

/** The Database Collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );

Geen idee of Versio PHPMyAdmin heeft maar ik zou wel aanraden je de password van je database aan te passen maar ook die van je administrator account binnen Wordpress. Controleer daarnaast ook de user tabel om te zien of er geen extra users in de tussen tijd zijn aangemaakt.

Ik heb nog even op de website van Versio gekeken voor je, als je het goedkoopste pakket hebt, namelijk: Webhosting Brons NL. Heb je het volgende: Dagelijkse back-up met 60 dagen retentie. Wellicht is dat nog iets waard ;-).

Daam schreef op vrijdag 6 december 2019 @ 01:44:
Vanzelfsprekend ga ik kijken hoe ik mijn volgende wordpress-installatie beter kan beveiligen. Las ergens al iets met een htacces wachtwoord, alleen nog niet voldoende in verdiept om te kijken of dit niet boven mijn pet gaat.

Een .htaccess wachtwoord gaat niet het gewenste resultaat geven. Dit wordt vaker gebruikt om je volledige site achter een wachtwoord te verbergen. Kan het toevallig zijn dat je gratis plug-ins hebt gebruikt welke niet echt te vertrouwen zijn of mogelijk verkeerde access permissies (CHMOD) hebt gebruikt op folders?

[ Voor 14% gewijzigd door Nemean op 06-12-2019 01:56 ]

[Ed Vertijsment]

Ten eerste, als je er niet voldoende van af weet, laat iemand er naar kijken. Een lekke website is in zekere zin een gevaar voor het internet, en simpelweg terugzetten gaat 9/10 resulteren in exact hetzelfde.

Ik heb bij een hosting provider gewerkt en dit al superbaak gezien, WordPress is gewoon een geliefd doelwit, bij een gehackte site was het stappenplan wat we aanraden pretty much dit. De hosting werd afgesloten totdat de klant aangaf dat al de stappen qua veiligheid waren doorlopen.

1. Haal alles offline.

2. Wijzig al je wachtwoorden die mogelijkerwijs met je website/hosting in verband kunnen worden gebracht.

3. Zoek uit waar het lek zat, had je zwakke wachtwoorden, gebruik je een oude versie of een lekke plugin? Fix dat lek, update alles, verwijder alles wat je niet gebruikt.

4. Plaats de bijgewerkte versie online en zet eventuele backups terug.

[hackerhater]

Betreffende de wordpress installatie.
Heb je die uberhaupt wel geupdated na de installatie?

WP-installaties die niet up to date zijn worden geowned binnen uren als je pech hebt.
WP is een hele grote aanvals-factor en niet correct up to date en ingesteld is het zo lek als een mandje.

[jay123]

Naar mijn ervaring (over de loop van de jaren 50+ Wordpress websites up and running) komt dit meestal door een plugin die vervallen is (lees: niet geupdate!). Kijk vooral dat je alle plugins update; en dat de plugins die je gebruikt zeker nog 'regelmatig' vernieuwd blijven worden.

[Xaverius]

Als ik me niet vergis worden er in gekochte themes nogal regelmatig allerlei plugins in verwerkt waarbij alleen voor die versie een licentie meegeleverd wordt en dus niet geupdate kunnen worden. Toch?
Zou dit het geval kunnen zijn?

[Daam]

Ed Vertijsment schreef op vrijdag 6 december 2019 @ 09:08:
1. Haal alles offline.

2. Wijzig al je wachtwoorden die mogelijkerwijs met je website/hosting in verband kunnen worden gebracht.

3. Zoek uit waar het lek zat, had je zwakke wachtwoorden, gebruik je een oude versie of een lekke plugin? Fix dat lek, update alles, verwijder alles wat je niet gebruikt.

4. Plaats de bijgewerkte versie online en zet eventuele backups terug.

Stap 1 is reeds gebeurd, stap 2 ga ik zo mee aan de slag (wachtwoorden wijzigen van de FTP, phpMyAdmin, DirectAdmin en natuurlijk Wordpress (wanneer nodig)).
Stap 3 wordt een moeilijke mijn inziens, zie hieronder.

hackerhater schreef op vrijdag 6 december 2019 @ 09:24:
Betreffende de wordpress installatie.
Heb je die uberhaupt wel geupdated na de installatie?

WP-installaties die niet up to date zijn worden geowned binnen uren als je pech hebt.
WP is een hele grote aanvals-factor en niet correct up to date en ingesteld is het zo lek als een mandje.

jay123 schreef op vrijdag 6 december 2019 @ 09:37:
Naar mijn ervaring (over de loop van de jaren 50+ Wordpress websites up and running) komt dit meestal door een plugin die vervallen is (lees: niet geupdate!). Kijk vooral dat je alle plugins update; en dat de plugins die je gebruikt zeker nog 'regelmatig' vernieuwd blijven worden.

En daarom snap ik dus niet waar het mis is gegaan. Alles aan mijn Wordpress-installatie is geüpdatet. Dit inclusief Wordpress zelf, Themes en alle plugins (welke overigens op één hand te tellen zijn). Alles wat met Wordpress te maken heeft is beveiligd met sterke wachtwoorden (plusminus 20 karakters lang, hoofdletters, gekke tekens,...)

Afijn, ik ga zo eerst even chatten met Versio.

[Neomess]

Daam schreef op vrijdag 6 december 2019 @ 10:54:

En daarom snap ik dus niet waar het mis is gegaan. Alles aan mijn Wordpress-installatie is geüpdatet. Dit inclusief Wordpress zelf, Themes en alle plugins (welke overigens op één hand te tellen zijn). Alles wat met Wordpress te maken heeft is beveiligd met sterke wachtwoorden (plusminus 20 karakters lang, hoofdletters, gekke tekens,...)

Afijn, ik ga zo eerst even chatten met Versio.

Heb het zelf meegemaakt dat een site vrijdag up-to-date was, en maandag gehackt. Dit kwam omdat er op vrijdag avond een kritieke update was uitgebracht die pas op maandag ochtend door de klant werd doorgevoerd.

Het kan dus heel snel, en zelfs wanneer je denkt alles up-to-date te hebben.

[Daam]

Nemean schreef op vrijdag 6 december 2019 @ 01:53:

Geen idee of Versio PHPMyAdmin heeft maar ik zou wel aanraden je de password van je database aan te passen maar ook die van je administrator account binnen Wordpress. Controleer daarnaast ook de user tabel om te zien of er geen extra users in de tussen tijd zijn aangemaakt.

[...]

Ik heb zojuist gekeken naar de tabel in phpMyAdmin en deze lijkt onaangetast te zijn. Alle gegevens die erin staan herken ik als eigen gegevens of settings van mijn thema. Bij de User-tabel zie ik enkel een regel met mijn eigen inloggegevens.

Ik zie nog wel een andere tabel genaamd "information_schema" maar dit ziet eruit als iets wat bij de hosting hoort?

[Neomess]

Ook gekeken naar de content van alle pagina's en gekeken of hier niet toevallig vreemde (javascript) bestanden worden ingeladen of javascript functies in staan?

Ik zou alle bestanden en database velden hier goed op controleren

[ Voor 18% gewijzigd door Neomess op 06-12-2019 11:15 ]

[RBH]

Dat doorsturen naar andere websites heb ik ook al heel vaak meegemaakt met Wordpress sites. Vaak zit er dan malicious code in bestanden verwerkt. Vaak helemaal bovenaan of onderaan in de bestanden. Ik begin altijd met het kijken naar de datum waarop bepaalde folders/bestanden zijn aangepast, dat geeft mij al een indicatie welke folders/bestanden zijn "gehackt".

Ik gebruik overigens ManageWP om Wordpress sites te beheren en daar kun je ze ook laten scannen op Malware en ook backups op laten maken, zodat je niet aan je hostingpartij gebonden zit. (Niet dat je daar nu veel aan hebt, maar wellicht een tip voor in de toekomst. )

[PdeBie]

Daam schreef op vrijdag 6 december 2019 @ 01:44:
Dank voor de reacties! De website is gehost bij Versio. Wel onder een budget-pakket dus ik ben heel benieuwd of zij backups hebben gedraaid van mijn site. Morgen maar eens contact met de klantenservice opnemen.

Ik zou vandaag al contact opnemen met de host. Voor hetzelfde geldt heb je maar een 24 uurs backup, waardoor de backup dus je 'lege website' bevat.

[Daam]

Ik heb vanochtend een chatbericht uitgezet, maar tot op heden geen reactie.

EDIT:
Zojuist nog eens door de bestanden gegaan welke afkomstig zijn van de server. Het viel mij op dat er werkelijk niks aan is gepast is aan al mijn bestanden (dit kijkend naar de wijzigingsdatum van alle files), op één file na. De wp-config.php file is gisteravond rond 19:50 aangepast.

De verwijzing van de MySQL Hostname is veranderd van "local host" naar een of ander extern (?) IP-nummer. Een IP-lookup leert dat het hier gaat om een Russisch IP-adres. Ook zijn de logingegevens hier veranderd in een voor mij onbekende gebruikersnaam en wachtwoord.

[ Voor 79% gewijzigd door Daam op 06-12-2019 15:41 ]

[Thijsmans]

Je wordt vanuit jouw wp-admin geredirect, zeg je. Voer een recursieve zoekopdracht uit op de nieuwe hostname. Er is namelijk wél wat aangepast: die redirect komt niet uit de lucht vallen.

[Daam]

Thijsmans schreef op vrijdag 6 december 2019 @ 16:23:
Je wordt vanuit jouw wp-admin geredirect, zeg je. Voer een recursieve zoekopdracht uit op de nieuwe hostname. Er is namelijk wél wat aangepast: die redirect komt niet uit de lucht vallen.

Thanks of je reactie, wat houdt een recursieve zoekopdracht in? En hoe voer ik deze uit op deze bestanden (welke lokaal staan)? Van wat ik begrijp ga ik de bestanden doorzoeken op het genoemde IP-nummer?

[Thijsmans]

Recursief is inderdaad een zoekopdracht in alle bestanden. Als je niet naar een domein wordt geredirect, maar naar een IP, inderdaad op dat IP-adres zoeken. En natuurlijk ook de mysql-inlog weer wijzigen. Ik weet niet hoe Wordpress precies werkt, maar het kan natuurlijk ook zijn dat er nare dingen vanuit die externe database worden geladen.

Goed nieuws, stylesheets zullen geen doelwit zijn geweest van een hacker (daar kun je helemaal niks mee), dus je theme-aanpassingen zijn vast nog steeds bruikbaar

[CH4OS]

@Daam Wanneer je de site opnieuw hebt, kun je het beste ook enkel leesrechten op dat wp-config.php bestand zetten, dan weet je 100% zeker dat er niet zomaar iets mee kan gebeuren.

[Ed Vertijsment]

CH4OS schreef op zaterdag 7 december 2019 @ 01:23:
@Daam Wanneer je de site opnieuw hebt, kun je het beste ook enkel leesrechten op dat wp-config.php bestand zetten, dan weet je 100% zeker dat er niet zomaar iets mee kan gebeuren.

Dat is leuk voor de buurman op de server maar dit is iets wat de host waarschijnlijk al heeft afgevangen op andere manier. Een aanvaller komt meestal binnen via een zwak wachtwoord of lek in een of andere plug-in/template. Dan ben je binnen als een valide bezoeker, regardless je bestandsrechten. Als je een VPS hebt zou je kunnen proberen de bestanden op immutable te zetten. Dat is (misschien) ook maar foppen maar vereist net iets meer know how dan simpel chmod command om te doen of om te ontdoen.

https://www.tecmint.com/chattr-command-examples/

Tip: vraag logbestanden op van de host en check met name alle POST records van het moment dat het gebeurd is. Het is niet ongebruikelijk dat het exacte lekke bestand in de log staat. Ook zie je wellicht of er andere personen langs de login zijn gekomen en dat misschien dat sterke wachtwoord toch is geraden.

[CH4OS]

@Ed Vertijsment Dat er ook andere manieren zijn om binnen te komen, betekent niet dat je zaken kan verzuimen. Ook door een openstaande raam kan ingebroken worden terwijl de deur op slot zit.

[Josk79]

Welk theme en welke plugins had je? Welke versies?

[Daam]

CH4OS schreef op zaterdag 7 december 2019 @ 01:23:
@Daam Wanneer je de site opnieuw hebt, kun je het beste ook enkel leesrechten op dat wp-config.php bestand zetten, dan weet je 100% zeker dat er niet zomaar iets mee kan gebeuren.

Ik ga dit even googlen hoe ik dit doe. Maar klinkt in ieder geval als 'baat het niet, dan schaad het niet'.

Ed Vertijsment schreef op zaterdag 7 december 2019 @ 11:35:
[...]


Dat is leuk voor de buurman op de server maar dit is iets wat de host waarschijnlijk al heeft afgevangen op andere manier. Een aanvaller komt meestal binnen via een zwak wachtwoord of lek in een of andere plug-in/template. Dan ben je binnen als een valide bezoeker, regardless je bestandsrechten. Als je een VPS hebt zou je kunnen proberen de bestanden op immutable te zetten. Dat is (misschien) ook maar foppen maar vereist net iets meer know how dan simpel chmod command om te doen of om te ontdoen.

https://www.tecmint.com/chattr-command-examples/

Tip: vraag logbestanden op van de host en check met name alle POST records van het moment dat het gebeurd is. Het is niet ongebruikelijk dat het exacte lekke bestand in de log staat. Ook zie je wellicht of er andere personen langs de login zijn gekomen en dat misschien dat sterke wachtwoord toch is geraden.

Bij mijn weten heb ik geen VPS server; het betreft hier het standaard "Brons-pakket" van Versio. Ik ga eens kijken of ik iets van logbestanden kan vinden. Volgens mij heb ik deze wel eens voorbij zien flitsen op mijn FTP. Dan zal het in die logbestanden een kwestie zijn van zoeken op het Russische IP-nummer neem ik aan.

Josk79 schreef op zaterdag 7 december 2019 @ 12:22:
Welk theme en welke plugins had je? Welke versies?

Het gaat hier om het theme "Pinecone". Zie ThemeForrest.

Ik heb de volgende Plugins geinstalleerd (gebaseerd op wat ik in de Wp-content-map vind. De versies kan ik niet zo achterhalen.)

• Contactform 7 (meegekomen met theme)
• IgniteUp
• Portfolio Installer (meegekomen met theme)
• ThemeWorm Pagebuilder (meegekomen met theme)
• Wordpress reset
• WP Optimize

EDIT:
Ik heb zojuist van Versio begrepen dat ik zelf een backup via DirectAdmin kan opvragen en deze zelf terug kan zetten. Om er zeker van te zijn dat ik geen geïnfecteerde backup terugzet pak ik een image van een week geleden. Dit gaat natuurlijk een beetje in tegen al jullie adviezen om een schone installatie te doen, maar het zou mij veel tijd en ellende schelen als ik dit zo werkend krijg.

[ Voor 7% gewijzigd door Daam op 07-12-2019 13:06 ]

[Ed Vertijsment]

Daam schreef op zaterdag 7 december 2019 @ 12:57:
Bij mijn weten heb ik geen VPS server; het betreft hier het standaard "Brons-pakket" van Versio. Ik ga eens kijken of ik iets van logbestanden kan vinden. Volgens mij heb ik deze wel eens voorbij zien flitsen op mijn FTP. Dan zal het in die logbestanden een kwestie zijn van zoeken op het Russische IP-nummer neem ik aan.

Dat ip adres, maar dat kunnen er een hele hoop zijn (pretty much elke website krijgt botjes langs voor wp-admin.php, ook al is het een asp website).

Om dingen te muteren op een website stuur je (meestal) POST requests. Die wil je dus bekijken, bij voorkeur met een statuscode die impliceert dat een actie is geslaagd, want dat betekent dat iemand is binnen gekomen. Daarvan moet je dan je eigen ip(s) negeren et voila, een kandidatenlijst.

In die lijst staan bestanden, statuscodes request methods etc. etc. Als iemand wp-admin.php heeft lopen opvragen met heel veel 403’s en uiteindelijk een 200 heeft iemand wss lopen brute forcen en is dat gelukt. Als er allemaal posts gaan naar een raar plug-in pad zit daar waarschijnlijk een lek, updaten of weggooien.

Ohja scan ff __all__ je bestanden op “eval” en “base64_decode”, in het bijzonder “eval(base64_decode(“. Exacte match op de laatste? 99% kans op backdoor.

[CH4OS]

Base65 ken ik niet, neem aan dat dat ook base64 moet zijn.

Eval zou wat mij betreft ook deprecated moeten worden in PHP.

[ Voor 34% gewijzigd door CH4OS op 07-12-2019 13:18 ]

[Ed Vertijsment]

Whoops

[ Voor 99% gewijzigd door Ed Vertijsment op 07-12-2019 13:20 ]

[Daam]

Ik heb zojuist een logboek gevonden op mijn FTP. Het lijkt erop dat dit logboek alleen van gisteren is. Ik zie wel telkens dit soort entries voorbij komen. Genoemd IP is overigens anders dan het eerdere Russische IP.

code:

<BUITENLANDS IP> - - [06/Dec/2019:23:36:23 +0100] "GET /wp-login.php HTTP/1.1" 404 454 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
<BUITENLANDS IP> - - [06/Dec/2019:23:36:23 +0100] "POST /wp-login.php HTTP/1.1" 404 454 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

Betekent dit dan een hacker "contact" heeft proberen te maken met mijn Wordpress? Wat niet is gelukt omdat ik alle bestanden offline heb gehaald, gezien de 404? Of zijn dit soort entries normaal?

[Ed Vertijsment]

Daam schreef op zaterdag 7 december 2019 @ 13:35:
Ik heb zojuist een logboek gevonden op mijn FTP. Het lijkt erop dat dit logboek alleen van gisteren is. Ik zie wel telkens dit soort entries voorbij komen. Genoemd IP is overigens anders dan het eerdere Russische IP.

code:

<BUITENLANDS IP> - - [06/Dec/2019:23:36:23 +0100] "GET /wp-login.php HTTP/1.1" 404 454 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
<BUITENLANDS IP> - - [06/Dec/2019:23:36:23 +0100] "POST /wp-login.php HTTP/1.1" 404 454 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

Betekent dit dan een hacker "contact" heeft proberen te maken met mijn Wordpress? Wat niet is gelukt omdat ik alle bestanden offline heb gehaald, gezien de 404? Of zijn dit soort entries normaal?

Ja, of waarschijnlijker een botje. Dit is “normaal” en omdat het niet gelukt is (404) geen probleem. Soms kun je van je host nog oudere logs krijgen, je wilt die van voor/tijdens de hack hebben.

[Daam]

Aha helder, ik heb nu de vraag bij Versio uitgezet of zij mij de logboeken van 5 december 's avonds kunnen sturen (op mijn FTP vind ik echt alleen maar logboeken van gisteren).

[Thijsmans]

Kun je niet via DirectAdmin bij de oudere logs, gezien je daarmee ook je back-up kunt herstellen?

[Daam]

Thijsmans schreef op zaterdag 7 december 2019 @ 14:23:
Kun je niet via DirectAdmin bij de oudere logs, gezien je daarmee ook je back-up kunt herstellen?

Ik heb even gekeken maar ik zie bij DirectAdmin niet de mogelijkheid om logs op te vragen.

Ed Vertijsment schreef op zaterdag 7 december 2019 @ 13:13:
[...]

Ohja scan ff __all__ je bestanden op “eval” en “base64_decode”, in het bijzonder “eval(base64_decode(“. Exacte match op de laatste? 99% kans op backdoor.

Dit heb ik zojuist gedaan. De eval(base64_decode( geeft in ieder geval geen enkele hit. Op eval en base64_decode krijg ik wel een aantal hits, maar dit is allemaal in php-files met een wijzigingsdatum ver voor eergisteren. De regels die ik vind waar eval in voor komt zijn praktisch allemaal op inactief gezet middels // ervoor (Tenminste, dan wordt de code toch gezien als comment, als ik op mijn beknopte code-kennis mag vertrouwen? )

[CH4OS]

@Daam Klopt helemaal. Overigens vind ik het wel lelijk om dergelijke code in comment te zetten, maar goed, WordPress heeft veel legacy nog en is niet altijd even netjes (imo).

[Eager]

Als je de boel straks weer werkend heb zou je WordFence erop kunnen installeren. Dat is een WordPress Application Firewall die vrij goed is in hackers buiten de deur te houden/te detecteren. Je kan hem ook een (handmatig) een scan laten doen op je site als de backup weer draait. Kijk verder goed in de instellingen/documentatie, de standaardinstellingen zijn een heel goed begin, er zijn daarnaast een paar opties die niet automatisch aangevinkt zijn.

Verder zou ik altijd, behalve de backups die de provider maakt, zelf ook altijd backups maken op en externe locatie. Ik gebruik zelf WPmanage en laat van alle sites die ik onder mijn beheer heb een dagelijkse of wekelijkse backup maken die 90 dagen bewaard wordt. Scheelt een hoop gedoe als er wat fout gaat, met één klik zet je een site terug.

[Verwijderd]

Aanrader voor de toekomst: installeer Wordfence, een excellente security plugin voor WP.

[Yucon]

Daam schreef op zaterdag 7 december 2019 @ 12:57:
[...]

EDIT:
Ik heb zojuist van Versio begrepen dat ik zelf een backup via DirectAdmin kan opvragen en deze zelf terug kan zetten. Om er zeker van te zijn dat ik geen geïnfecteerde backup terugzet pak ik een image van een week geleden. Dit gaat natuurlijk een beetje in tegen al jullie adviezen om een schone installatie te doen, maar het zou mij veel tijd en ellende schelen als ik dit zo werkend krijg.

Nu heb ik nauwelijks specifieke WordPress kennis, maar zou je dit wel doen? Je kunt misschien beter je backup naar een tweede website (= hoster, hosting pakket of webserver op je eigen pc) terugzetten en van daaruit je eigen wijzigingen terugzoeken. Die kun je dan vervolgens overzetten naar een schone installatie. Dat is wat knip en plakwerk maar je begint tenminste niet vanuit 0.

[edeboeck]

Yucon schreef op maandag 9 december 2019 @ 07:40:
[...]

Nu heb ik nauwelijks specifieke WordPress kennis, maar zou je dit wel doen? Je kunt misschien beter je backup naar een tweede website (= hoster, hosting pakket of webserver op je eigen pc) terugzetten en van daaruit je eigen wijzigingen terugzoeken. Die kun je dan vervolgens overzetten naar een schone installatie. Dat is wat knip en plakwerk maar je begint tenminste niet vanuit 0.

Dit lijkt me zeker interessant. Een absoluut hulpmiddel daarbij is Beyond Compare... daardoor kan je véél sneller opschieten... de verschillen tussen een nieuwe installatie en jouw back-up worden ogenblikkelijk uitgelicht (al zullen MySQL-databases hoogstwaarschijnlijk niet ondersteund worden - t.t.z. een snelle search op "mysql" op de pagina met ondersteuning voor extra bestandsformaten voor Beyond Compare leverde toch geen hits op). Veel succes!

[Daam]

Wellicht een korte update:
Afgelopen weekend heb ik een backup teruggezet van voor het hack-moment. Ik had toen eigenlijk gelijk weer de website werkend. Voordat ik dit heb gedaan ben ik eerst door alle files gegaan om te kijken of er
files tussen zaten die kort ervoor nog gewijzigd waren, dit was niet het geval.

Wel kwam ik toen erachter dat mijn Wordpress tóch al een hele tijd niet geupdate was geweest. Normaal gebeurde dit automatisch, maar omdat Wordpress sinds een bepaalde update een nieuwere versie van PHP nodig had (ik draaide blijkbaar nog 5.x) is die automatische update blijven hangen. Stom...

Wat ik nu heb gedaan:
- Uitgevonden hoe ik mijn PHP kon updaten en deze naar een hogere versie gezet (7.x)
- Vanzelfsprekend Wordpress geüpdate.
- Plugins geüpdate.
- Overbodige plugins verwijderd.
- Overbodige themes verwijderd.
- De volgende plugins geïnstalleerd en ingesteld:
- Login lockdown (blokkeren brute force aanvallen).
- WPS Hide login (zorgen dat WP-Admin niet meer via de standaard-link is te bereiken).

Ik ga nog even kijken naar WordFence, klinkt in ieder geval als iets wat ik even moet installeren.

Ik begrijp alle suggesties om Wordpress opnieuw te installeren, maar ik heb daar op dit moment de tijd niet
voor. Vooralsnog draait alles weer top.

[Robbie T]

Daam schreef op dinsdag 10 december 2019 @ 18:11:
Wellicht een korte update:
Afgelopen weekend heb ik een backup teruggezet van voor het hack-moment. Ik had toen eigenlijk gelijk weer de website werkend. Voordat ik dit heb gedaan ben ik eerst door alle files gegaan om te kijken of er
files tussen zaten die kort ervoor nog gewijzigd waren, dit was niet het geval.

Wel kwam ik toen erachter dat mijn Wordpress tóch al een hele tijd niet geupdate was geweest. Normaal gebeurde dit automatisch, maar omdat Wordpress sinds een bepaalde update een nieuwere versie van PHP nodig had (ik draaide blijkbaar nog 5.x) is die automatische update blijven hangen. Stom...

Wat ik nu heb gedaan:
- Uitgevonden hoe ik mijn PHP kon updaten en deze naar een hogere versie gezet (7.x)
- Vanzelfsprekend Wordpress geüpdate.
- Plugins geüpdate.
- Overbodige plugins verwijderd.
- Overbodige themes verwijderd.
- De volgende plugins geïnstalleerd en ingesteld:
- Login lockdown (blokkeren brute force aanvallen).
- WPS Hide login (zorgen dat WP-Admin niet meer via de standaard-link is te bereiken).

Ik ga nog even kijken naar WordFence, klinkt in ieder geval als iets wat ik even moet installeren.

Ik begrijp alle suggesties om Wordpress opnieuw te installeren, maar ik heb daar op dit moment de tijd niet
voor. Vooralsnog draait alles weer top.

Je geeft aan dat je een PHP 7.X hebt gebruikt. Zorg wel dat dit PHP 7.2+ is. 7.0 en 7.1 worden niet langer ondersteund.
Kijk gelijk even bij je plugins (via plugin details) of er plugins bij zitten die al geruime tijd niet zijn geupdate. Installeer tevens nog een backup plugin. Zelf goede ervaringen met WD Backup.

[Daam]

Robbie T schreef op donderdag 12 december 2019 @ 15:23:
[...]


Je geeft aan dat je een PHP 7.X hebt gebruikt. Zorg wel dat dit PHP 7.2+ is. 7.0 en 7.1 worden niet langer ondersteund.
Kijk gelijk even bij je plugins (via plugin details) of er plugins bij zitten die al geruime tijd niet zijn geupdate. Installeer tevens nog een backup plugin. Zelf goede ervaringen met WD Backup.

Goeie tips! Hier ga ik zeker even naar kijken. Ik draai op dit moment PHP 7.2 als het goed is.

[RoestVrijStaal]

Daam schreef op donderdag 26 december 2019 @ 11:41:
[...]


Goeie tips! Hier ga ik zeker even naar kijken. Ik draai op dit moment PHP 7.2 als het goed is.

Dan mogen ze bij Versio wel eens uit hun luie stoel komen. Versie 7.4 van PHP is al uit en versie 7.2 krijgt enkel beveiligingsupdates tot 6 december 2021.

Maar als ik het topic zo doorlees, krijg ik de indruk dat je beter ervan af bent door in plaats van een "generieke" webhosting dienst, een wordpress hosting dienst af te nemen, waar automatische updates van Wordpress en plugins door de dienstverlener uitgevoerd wordt en/of gemonitord wordt door bijvoorbeeld PatchMan.

[Matis]

@RoestVrijStaal dat gevoel krijg ik ook. Draai voor mijn klanten ook WordPress hosts bij TransIP.
Hun updates volgen altijd heel snel op de releases en ik heb er verder weinig tot geen omkijken naar. Daarnaast draait alles op de laatste stabiele versies van PHP.

Voor een paar euro's per maand scheelt dat een hele hoop zorgen.

[ Voor 11% gewijzigd door Matis op 28-12-2019 14:02 ]

[Daam]

RoestVrijStaal schreef op vrijdag 27 december 2019 @ 20:31:
[...]

Dan mogen ze bij Versio wel eens uit hun luie stoel komen. Versie 7.4 van PHP is al uit en versie 7.2 krijgt enkel beveiligingsupdates tot 6 december 2021.

Maar als ik het topic zo doorlees, krijg ik de indruk dat je beter ervan af bent door in plaats van een "generieke" webhosting dienst, een wordpress hosting dienst af te nemen, waar automatische updates van Wordpress en plugins door de dienstverlener uitgevoerd wordt en/of gemonitord wordt door bijvoorbeeld PatchMan.

Oké ik ga hier wel eens naar kijken; ik was niet op de hoogte dat er specifieke WordPress hosting bestaat.

Dat Versio zelf niet voor updates zorgt verbaast me overigens niks. In die jaren dat ik bij Versio zit zijn ze gegaan van een betrouwbare partij naar een partij waar op alles bezuinigd werd (zoals fatsoenlijke klantenservice). Maar dat terzijde.

[oadm]

Ik heb een vraag over de 2FA van Wordfence (WF). Ik had laatst een probleem met mijn website *snip* spam - niet relevant en dat kwam dacht ik door de 2FA van Wordfence. Als ik de 2FA inschakel scan ik een barcode met mijn smartphone die ik bij de plugin van WF zie. Op mijn smartphone zie ik dan een Code en die vul ik in het het daarvoor bestemde vakje en mijn site is beschermd. Na 2 dagen bleek mijn site ineens niet meer toegankelijk en moest ik een backup terug zetten, en die backups maak ik gelukkig regelmatig dus dat is het probleem niet. Vervolgens moest ik met een code die ik download als ik de 2FA activeer ingeven met het inloggen.

Uiteindelijk was mijn site weer bereikbaar maar ik begrijp niet zo goed hoe dit kan en of ik iets fout doe. Is het normaal dat ik iedere 2 dagen ofzo een nieuwe code moet ingeven ? en is dat de reden dat ik niet meer bij mijn site kan ?

[ Voor 5% gewijzigd door RobIII op 30-01-2020 22:08 ]

[RobIII]

oadm schreef op donderdag 30 januari 2020 @ 20:57:
maar ik begrijp niet [...] of ik iets fout doe.

In ieder geval kaap je nu een (oud) topic met een vraag die totaal ongerelateerd is behalve dat 't toevallig ook met Wordpress te maken heeft. Ik wil je vriendelijk verzoeken een eigen topic te openen en daarbij onze Quickstart te hanteren. Vraag je ook even af of Softwareontwikkeling wel de juiste plaats is (Waar hoort mijn topic?) en of je misschien niet beter kunt posten in Serversoftware en Windows Servers or Privacy & Beveiliging of één van de vele andere fora. Verder is 't voor je vraag natuurlijk ook totaal irrelevant hoe je site heet; laat dat dan ook achterwege a.u.b. Dat komt nogal spammerig over

[ Voor 14% gewijzigd door RobIII op 30-01-2020 22:12 ]