Afgelopen donderdag rook ik ‘s ochtends onraad. De server deed raar, reageerde traag en in mijn bewerkingsprogramma kreeg ik ineens een foutmelding die ik niet eerder was tegengekomen (over de verbinding met de server).

Ik dacht dat de server wellicht even een schopje nodig had en wou inloggen, maar dat ging ook al niet lekker. Na eindelijk in mogen loggen kreeg ik een bericht dat mijn IP op de blacklist gezet was (gebeurd na teveel inlogpogingen van 1 IP, tijdelijke ban).

Dus: hostingprovider gebeld. Zij gaven aan dat mijn server inderdaad in error-status stond vanwege vol geheugen.Dus deze werd vanuit hun opnieuw opgestart. Terwijl ik de medewerker aan de telefoon had ging de server meteen weer in error: geheugen weer vol.

De betreffende medewerker heeft toen in de robots.txt bots geweerd, want hier zou het door komen (bots van Google ed).

Ik vond die uitspraak erg vreemd. Ja, bots van o.a. Google kunnen nog weleens veel vragen van een server, maar ik kon me niet voorstellen dat het ineens zou gebeuren dat mijn server er door overbelast raakte (meteen na herstart nog wel). En daarnaast is het natuurlijk ook wel erg vreemd: de vindbaarheid van je website proberen te vergroten en dan de zoekmachine bots de toegang ontzeggen. Die wijziging in robots.txt heb ik dus weer teruggedraaid.

Vrijdagochtend kreeg ik van een opdrachtgever de vraag of ik toevallig op zijn website bezig was, want die was ineens offline. Mijn antwoord: nee. Dus hij bellen met zijn hostingprovider (toevallig dezelfde).

Het oordeel van de betreffende medewerker: geheugenprobleem. Er moest naar de cache’ing gekeken worden, want met de plugin die daar is geïnstalleerd (W3TC) hadden ze vaker gehoord dat de instellingen verkeerd stonden waardoor de site juist trager werd. Het geheugen van zijn hostingaccount werd tijdelijk verhoogd.

En ook daar had ik een vreemd gevoel bij.

Het was me té toevallig. Van meerdere kanten was ik tegengekomen dat er massaal DDoS attacks worden uitgevoerd over het internet. Internetbankieren die er uit liggen, andere providers die DDoS attacks op hun servers noemen.

Wat is een DDoS attack?

DDoS staat voor Distributed denial-of-service, een aanval vanaf meerdere computers om een dienst/computer onbruikbaar te maken voor de gebruiker. En dat lukt ze dus prima: internetbankieren ligt er steeds uit, websites van veel mensen liggen er uit, noem maar op.

Later kreeg ik van dezelfde opdrachtgever een bericht doorgestuurd dat op internet stond: Brute Force Attacks Build WordPress Botnet.

Een botnet is een netwerk van computers die wordt gebruikt voor het verspreiden van malware (virussen, spam etc.) en/of het hacken.

Wat doe ik er tegen?

Het daadwerkelijk tegenhouden dat de DDoS attacks worden afgeweerd is aan je hostingprovider, zij zullen hun best moeten doen om hun hardware (servers) veilig te stellen. Zie bijvoorbeeld wat TransIP hierover meldde in een nieuwsbrief:

Momenteel ondervindt TransIP wederom een zware DDoS-aanval. Deze aanval is de meest recente in een reeks die zondag 24 maart startte. Helaas zijn de aanvallen sindsdien in intensiteit toegenomen en richten zich inmiddels op al onze nameservers. Onze technische staf is er echter in geslaagd om ook de meest recente aanval succesvol af te wenden.

Maar: om ervoor te zorgen dat jouw website niet een slachtoffer is van deze DDoS attacks en gehackt wordt kun je zeker wat stappen ondernemen!

1. Zorg ervoor dat je geen admin als gebruikersnaam gebruikt

Deze gebruikersnaam werd in het verleden standaard ingesteld bij WordPress installaties, tegenwoordig kun je een eigen gebruikersnaam kiezen bij nieuwe installaties.

Heb je wel een gebruiker met de gebruikersnaam admin? Volg dan de volgende stappen:

  1. Maak een nieuwe gebruiker aan. Een lastiger te raden gebruikersnaam kan (bijvoorbeeld letters vervangen voor cijfers), maar aangezien die gebruikersnaam ook wordt gebruikt voor de author-URL zal dat niet 100% afweren.
  2. Geef deze gebruiker Beheerder / Admin rechten.
  3. Log in met deze nieuwe gebruiker.
  4. Verwijder de admin gebruiker.

2. Verander je wachtwoorden

We gebruiken vaak makkelijk te raden wachtwoorden en dan meestal ook datzelfde wachtwoord voor zo ongeveer alle services die we gebruiken. Dit is een van de minst veilige dingen die je doen kunt.

Wat je het best kan doen is een nieuw wachtwoord aanmaken voor elke site en deze opslaan in een password manager; Een speciaal programma dat je wachtwoorden veilig opbergt. Zelf gebruik ik hier al een paar jaar 1Passwordvoor en ik zou echt niet meer zonder kunnen!

Zorg ervoor dat je wachtwoorden zo lastig mogelijk te achterhalen zijn. Dus geen wachtwoorden als “welkom123″, “w8woord” of iets dergelijks, maar liever iets als “IUT*&%$%&EGVLI*%yioaf89y3r.45″. Langer en moeilijker dus.

3. Hou WordPress + updates/themes altijd up-to-date!

Veel updates bevatten veiligheidsupdates, oplossingen voor veiligheidslekken. Omdat WordPress open source software is en de gedichte lekken bij veiligheidsupdates worden genoemd is een oudere versie draaien gevaarlijk.Kwaaddoeners weten namelijk precies waar ze naar zoeken moeten.

Daarnaast is het zo dat als je website eenmaal gehackt is deze sneller weer gehackt word. En dat wil je voorkomen!

4. Zorg voor recente backups

Hackers zijn over het algemeen niet zo voorzichtig met de websites die ze hacken. Het kan dus maar zo zijn dat ze je complete website wissen en zonder een recente backup is al het werk dat je in de website hebt gestoken voor niks geweest. Zonde!

Als je website niet vaak bijgewerkt wordt (met nieuwe content) dan is maandelijks wellicht genoeg, maar veel websites zullen beter wekelijks/dagelijks geüpdatet kunnen worden. Op die manier wordt het verlies van content geminimaliseerd en kun je snel een backup terugzetten als dit nodig is.

5. Scan je website op wijzigingen

Er zijn meerdere plugins die de bestanden van je website scannen op mogelijke tekenen van hacks, een paar hiervan zijn:

6. Geef zo min mogelijk toegang tot je WP installatie / FTP

Het zal vast een inkopper zijn, maar daardoor niet minder belangrijk: kijk uit met wie je toegang tot je website/ftp verschaft. Ga er nooit zomaar vanuit dat de persoon niks ernstigs met je website uithaalt.

Is het toch nodig dat een bepaald persoon toegang krijgt (je webbouwer bijvoorbeeld)? Maak dan een aparte FTP gebruiker aan en ook een aparte WordPress gebruiker. Mocht je de toegang dan in moeten trekken dan hoef je de betreffende accounts alleen maar te verwijderen.

Andere plugins voor extra veiligheid

  • Limit Login Attempts zet een limiet op het aantal pogingen dat gedaan mag worden om in te loggen. Als er te vaak wordt geprobeerd dan wordt het betreffende IP-adres tijdelijk geblokkeerd (hetzelfde idee als de tijdelijke ban die ik in het begin van dit artikel al noemde).
  • Lockdown WP Admin geeft een 404 error aan gebruikers die niet zijn ingelogd en wp-admin rechtstreeks proberen te bereiken.

Deel Tweet Deel Deel

WooCommerce

Leave a Reply

Your email address will not be published. Required fields are marked *

Skip to content