In dit artikel vertellen we hoe je voor te bereiden op hackers, hoe je aanvallen kunt tegengaan en hoe je een gehackte site terug gezond kan krijgen. Dit artikel is wellicht het meest volledige en praktische in het Nederlandstalig taalgebied.

Inhoudstafel

  1. Hacken: wat & waarom
  2. Hacken voorkomen
  3. De verdediging
  4. Mijn site is gehackt
  5. Herstellen van jouw gehackte site
  6. Vergeet ook niet ... de nazorg
  7. Herstellen van verloren data
  8. Afsluiter
  9. Annex

 

 

A Hacken: wat & waarom?

Net zoals je pc of Mac zijn web-sites doelwitten van programmeurs met slechte bedoelingen. Ze hebben een verschillende kennis en bedoelingen, de ene al wat onschuldiger dan de andere, maar ze zijn allen best te vermijden.

1. Waarom? 

Enkele redenen waarom zij jouw site willen besmetten:

  • invoegen van advertenties (viagra), linken naar andere sites
  • invoegen van bestanden die de analytics van andere websites beïnvloeden (en alzo de SEO-ranking beïnvloeden) (bron: http://www.bluebridgedev.com/hacked-joomla-changes )
  • jouw server gebruiken voor spam-mails waardoor jouw domein geblacklist kan worden
  • PCs van surfers infecteren
  • stelen van gevoelige data zoals email-adressen, credit card nummers
  • stelen van jouw traffiek en je surfers naar andere web-site doorverwijzen
  • politieke motieven
  • zo maar, de kick
  • met als nieuwste mode: losgeld vragen om je bestanden terug vrij te geven (bron: http://www.bluebridgedev.com/hacked-joomla-changes )

 

2. Wat, hoe … enkele termen

Enkele termen nader belicht:

Spammen is bekend als het versturen van een mail naar een grote massa mensen (email-adressen) waar deze niet om gevraagd hebben.
Gebeurt deze verzending vanaf jouw server, dan riskeer je niet alleen een tragere page-load (en slechtere SEO-ranking) maar ook dat jouw mailings verstuurd vanuit jouw server als spam aanzien zullen worden. (Als er een groot aantal mails in een zeer korte tijd verstuurd worden vanuit 1 machine, dan beantwoord dit aan het gedrag van een spammer).

Blacklist Hier bedoelen we de zwarte lijst van web-sites die beschouwd worden als onveilig of kwaadaardig. Hoewel een site van oorsprong goede bedoelingen heeft, kan die op de zwarte lijst komen doordat ze gehackt is (en daardoor onveilig voor surfers wordt).
Als Google tijdens het crawlen van je site ontdekt dat je site gehackt is, dan is er een grote kans dat hij die site op de blacklist zet. Deze lijst deelt Google met Twitter, desktop antivirus programma's, ... . Maar er zijn nog andere firma's die een (eigen) blacklist beheren.
Die blacklists worden geconsulteerd door (veiligheidsprogramma's of add-ons van) browsers die aan de eindgebruiker een verwittigen tonen als de bezochte site geblacklist staat.

Drive-by-downloads Hierbij is het doelwit niet zozeer jouw site als wel de computer van jouw surfers om daarop kwaadaardige programma's te downloaden. Als de computer  van de surfer niet genoeg beveiligd is zal deze bij een bezoek aan jouw site geïnfecteerd worden met een virus, malware of zoals nu meer gebeurt ransomeware. Ransomware blokkeert de toegang tot de bestanden op de computer, mits betaling van losgeld zal de blokkade opgegeven worden.

Data Exfiltratie Hier wil de hacker gegevens stelen die hij zelf kan gebruieken / uitbuiten. Dit kan gaan van emails (voor spamming), persoons-identicatie-gegevens tot kredietkaart-gegevens.

Defacing verandert je home-pagina zodat je site-bezoekers een andere inhoud, boodschap te zien krijgen. Dit wordt ook wel hacktavism genoemd.

Phishing simuleert een webpagina van een firma (bank!) om van de onschuldige surfer persoonlijke informatie op te vragen. Net zoals bij data exfiltratie is het doel de verkregen gegevens te misbruiken.
Jouw site kan gehackt zijn om die valse webpagina te herbergen. Jouw site lijkt dus te werken zoals het hoort, maar uw server is wel gehackt. Dit misbruik zal je misschien niet zo snel zien maar mischien wel voelen door de traagheid van page-load als de valse web-pagina veel resource vraagt (en/of veel trafiek aantrekt).

Terwijl bovenstaande termen de bedoeling van de hackers illustreren, komen hieronder de manieren van hacken aan de beurt.

Vulnerability Exploitation behelst alle manieren van hacken waarbij een zwakheid in de programma-code of functionaliteit ervan misbruikt wordt. Hieronder zijn enkele van dergelijke misbruiken nader beschreven.

Code injection verandert de executie van een programma doordat de hacker eigen code injecteert in de programma-code. Dit is niet mogelijk met programmeer-talen die gecompileerd moeten worden maar in een web-omgeving worden er genoeg script-talen gebruikt, die dat wel toelaten, zoals PHP en SQL-querying. Hieronder bespreken we 2 types.

Met SQL-injection probeert de hacker een SQL-commando uit te voeren, niet in een database-interface zoals phpMyAdmin maar door dit commando mee te geven in een url-query of een web-form-veld. Als de webpagina die input van het veld of url-query naar zijn database stuurt dan wordt de geïnjecteerde SQL-commando van de hacker mee naar de database gestuurd en mee uitgevoerd (waarop de hacker hoopt). Het geïnjecteerde SQL-commando is vaak een creatie van een administrator account waarmee de hacker dan volledige toegang heeft tot je content management systeem. Een ander doel dat bereikt kan worden door de database te infecteren:

  • in artikels Javascript invoegen zodat bij een bezoek aan die pagina een andere pagina (door de hacker gespecifieerd) getoond wordt,
  • downloaden van je database-gegevens,
  • je gegevens wijzigen of zelfs vernietigen.

Command-injection werkt op een gelijkaardige manier, alleen is het niet de bedoeling dat de database het meegegeven commando opneemt maar de server . Dit is een vorm van Remote Code Execution, de hacker laat zijn kwaadaardige commando's uitvoeren zonder dat hij toegang heeft tot het systeem.

Als de code niet op de server maar op de client wordt uitgevoerd dan spreekt men van Cross Site Scripting of XSS. Als de surfer  met zijn browser jouw site bezoekt zal die kwaadaardige code (in Javascript) uitgevoerd worden. Deze code kan bijvoorbeeld verstopt zitten onder een onschuldig lijkende URL-link. Op het moment dat de surfer daarop klikt, zal de kwaadaardige code uitgevoerd worden op zijn PC.

File Inclusion Sommige programmeertalen laten het toe dat tijdens een executie van een programma de commando's uit een ander bestand, wiens naam tijdens de uitvoering bepaald wordt, ook mee uitgevoerd worden , ook gekend als “dynamic file include” mechanisme. De hacker zal van dit principe gebrik maken om zijn bestand mee te laten uitvoeren. Als hij dit bestand al op jouw server staat dan noemt men dit een Local File Inclusion, als het bestand op een andere server staat, noemt men dergelijk Remote File Inclusion.

Backdoor is een stuk code dat de hacker geplaatst heeft op je site. Deze zal zo goed mogelijk verstopt zitten om het detecteren (en saneren) te verhinderen. Verstopt in een bestand met een onschuldige naam (zodat onwetende denken dat het bestand essentieel is, een voorbeeld main.php zoals gemeld in http://www.joomlacommunity.eu/nieuws/gebruikersgroepen/983-website-hack-via-xmlrpc-backdoor-script.html ), gecrypteerd door speciale code (eval base64_decode) , op een plaats waar men niet zo snel aan denkst (zoals tijdelijke bestanden of plugins) , ... Enkele voorbeelden vind je op een blog-artikel van Sucuri (Engelstalig).

SEO Spam wordt grotendeels gebruikt door spammers om de positie van hun klanten in zoekmachines, zoals Google, te vergroten. Hierbij worden zelfs iFrames, sitemaps, ... gegenereerd om de zoekmotoren Google, Bing, ... ranking te verhogen ten voordele van de aanvallers' site. 

Privilege Escalation Door een fout concept, functionaliteit of bug in de site-software heeft een gebruiker meer rechten dan oorspronkelijk bedoeld, zodat hij meer kan doen en bereiken dan geoorloofd. Een hacker kan hiervan misbruik maken.

Image hotlinking is in feite geen aanval op jouw site maar eerder een misbruik van jouw materiaal. Je afbeeldingen worden namelijk opgeroepen in/door een ander site. Als die veel bezoekers heeft, dan kan jouw server leiden onder diens traffiek ten nadele van je eigen bezoekers (en je S.E.O.).

Distributed Denial of Service Bij een DDoS is het de bedoeling om de beschikbaarheid van je site te verstoren door je site te overbelasten met een overdaad aan fake bezoeken, je server te belasten met een overweldigende hoeveelheid verzoeken t.t.z. taken die via jouw site aangevraagd zijn. Hierdoor komt de server er nog nauwelijks toe jouw site weer te geven en zullen jouw surfers hun bezoek opgeven, zelfs het open van de backoffice zal geduld vragen, als het nog wel lukt.

Brute Force Attack duidt op het herhaaldelijk proberen in te loggen op je site als administrator. De hacker zal via een programma alle mogelijke combinaties van gebuikersnaam en paswoord uitproberen. Hierbij kan het programma de meest voorkomende paswoorden gebruiken of zelfs een heel woordenboek. Hoe langer je paswoord, hoe langer het zal duren dat een dergelijk programma de juiste combinatie zal gevonden hebben.

In onderstaande grafiek van Sucuri kan je de trends zien van de laatste jaren:

Trends van infecties 2014 2016 Q1

Cijfers die heel 2016 beslagen werden niet gepubliceerd bij Sucuri maar hieronder krijg je een idee van de evolutie in 2016 en 2017:

Trends van infecties 2016

Types malware infecties voor het jaar 2017 zoals gedetecteerd door Sucuri:

type malware besmettingen

 

Mag het een magere troost heten dat wat betreft infecties Joomla! beter scoort dan WordPress,
ook rekening houdend met het aantal websites die op de respectievelijke CMS draaien:

gehackte websites per CMS

De 3 werkterreinen voor jou

Om je site te beveiligen en voorbereid te zijn op een hacker, zijn er 3 gebieden die je inzet vragen:

  1. het versterken, veilig stellen van de eigen digitale elementen (software, configuraties en infrastructuur)
  2. inzetten van tools die de aanvallen afweren en/of ontdekken
  3. het nemen van voorzorgen die een sanering van de site vergemakelijken (met o.m. Backups)

Deze 3 werkterreinen komen in de volgende hoofdstukken uitgebreid aan bod.


 

B. Hacken voorkomen

Om je site veilig te houden zodat ze goed weerstand kan bieden tegen aanvallen van buitenaf, kom je met volgende aanbevelingen al ver:

  • Update jouw Joomla! CMS alsook alle extensies en templates
  • Wees zeker dat de server-software up to date is
  • Wees zeker dat de (server en site) configuratie optimaal is
  • Zorg dat de bestands- & folder-permissies juist staan
  • Laat jouw site regelmatig scannen (virus, malware, WAF, ...)
  • Gebruik sterke paswoorden en verander de standaard admin gebruikersnaam
  • Neem regelmatig backups en verzeker je ervan dat je deze kan restoren
  • Wees op de hoogte door veiligheidsberichten te lezen
  • Ondanks alles blijf waakzaam

In de volgende hoofdstukken gaan we dieper in op elke van de punten.

1. Joomla!-installatie

Sommige Joomla! versies zijn niet genoeg beveiligd. Zo volgden versies 3.4.5 , 3.4.6 en 3.4.7 elkaar snel op vanwege gevaar op SQL-injection (opgelost in versie 3.4.7) en remote code executie (te wijten aan een zwakheid in PHP). Het is dan zaak om een upgrade niet uit te stellen!
Andere voorbeelden:

  • In de Joomla versies 2.5.13 en kleiner alsook in 3.1.4 en kleiner, was de kontrole op verdachte bestanden te zwak. De sites waar je als geregistreerd gebruiker toegang tot de media-beheerder had, waren super kwetsbaar. Je kon een uitvoerbaar bestand uploaden als je achter de naam maar een punt zette. Eenmaal opgeladen kon je dat bestand dan uitvoeren ( https://blog.sucuri.net/2013/08/joomla-media-manager-attacks-in-the-wild.html  https://www.siteground.com/blog/joomla-vulnerability/ ).
  • In de Joomla! bijeenkomst van 20-03-2016 toonde Karel hoe hij dankzij een bug eender welk bestand kon opladen. Op die werkwijze kan een indringer toegang tot Joomla! en bijhorende gebruikersomgeving bekomen.

Omdat bij de release van een Joomla! versie er kort nadien weer een andere versie opduikt die een veiligheidslek moet dichten (versies 3.4.5 - 3.4.7 en versie 3.7.0 - .3.7.2) is het aangeraden om bij een nieuwe (major) versie van Joomla! niet onmiddelijk te upgraden... tenzij er duidelijk een veiligheidsreden is! Zo vermijd je meerdere updates te moeten doen in zeer korte tijd.

2. Extensions

Behoud de discipline om enkel extensies te installeren die noodzakelijk zijn voor jouw site.
Bij het kiezen van extensies probeer ook een idee te krijgen van de reputatie & het niveau van de developer en zijn producten (wanneer is de laatste update uitgevoerd, is de developer eerder een hobbyist dan een professional, ...).

Neem enkel extensies via de JED, i.e. extensions.joomla.org , zo ben je er steeds zeker van dat er geen infecties in de download-bestanden zouden zitten.
Hoe komt het dat ondanks alle updates je site toch nog gehackt kan worden? Vanaf het moment dat een probleem ontdekt is tot de release van de verbeterde versie, verloopt er enige tijd: de developer heeft namelijk zijn tijd nodig om in zijn programma het veiligheidslek te vinden en te dichten.

Het updaten van extensies en modules, plugins, ... is een vaak gehoord beveiligingsadvies. Maar ondergetekende vindt dit niet zo evident: er is vaak geen mogelijkheid om de relevantie van updates na te gaan. Bovendien blijken niet alle Joomla! extensies gebruik te maken van de update-melder. Dit kon Manu ondervinden met BreezingForms wiens bestanden gehackt werden eind 2015. Hij heeft daarom nu een document gemaakt waarin alle extensies vermeld zijn die geen automatische melding tonen als er een nieuwe versie beschikbaar is. Die lijst bevat de URL naar de Joomal Extension Directory (JED) - om met een click de meest recente versie in de JED te kunnen verifiëren - en daarnaast staat in de lijst de versie die geïnstalleerd is in de site. Dan is het enkel een discipline om elke N maanden die lijst af te lopen en de versies vermeld in JED te vergelijken met die op de site.
Dit opvolgingswerk van versies kan ook uitgevoerd worden door extensies en services: dit doet bijvoorbeelde de extensie https://www.akeebabackup.com/products/admin-tools.html en een extra service bij Watchful.li https://watchful.li/tools/ (daar kan je alle gecheckte extensies opgelijst zien).

Desinstalleer extensies die je niet meer gebruikt, zeker als je ze niet meer update. Daardoor zijn er al minder bestanden op de server en dus minder kans op infectie. Voor extensies die uit de JED verwijderd zijn, is ook aangeraden ze te verwijderen, ze te vervangen door andere.

3. Themes

Een template bevat niet louter grafische elementen maar ook code en is daarmee ook kwetsbaar. Nicholas Dionysopoulos verwoordt het zo: “I've seen many sites getting hacked because of a dated template with a SQL injection or XSS vulnerability.”
Een voorbeeld was SQL injection in een van de modules van RocketTheme (tweede helft 2013).

4. Paswoorden

Ter illustratie een getuigenis van provider Siteground:
Op 9 april 2013 werden bij hun meerdere Joomla-sites aangevallen. Bots gebruikten meer dan 1000 verschillende IP's per server om door te dringen. Siteground blockeerde meer dan 92.000 Ips en in 12 uur blokkeerden ze 15 millioen login requests.
In een daarop ovlgende onderzoek rond admin-paswoorden ontdekte Siteground dat 40% zeer zwakke paswoorden gebruikt!

Vandaar volgende raadgevingen:

Gebruik als paswoord iets kryptisch of waarom niet een volledige zin zoals “niets beters dan werken bij ons”, “leef met vlag en wimpel, maar hou het simpel”. Als de hacker een random-generator gebruikt om het paswoord te ontdekken, dan zal voor elk character méér in het paswoord het aantal combinatiemogelijkheden met 40 (of meer) toenemen. Dit feit lijkt te weinig vespreid terwijl het een goede combinatie is van veiligheid (lang paswoord dus langere detectietijd nodig) en gebruiksvriendelijkheid (gemakkelijk te onthouden).

Wijzig de gebruikersnaam van de administrator (bijv. “rege1neef_j@n” , maar niet zoiets als “admin2”).

Een extra beveiliging kan er ook in bestaan om inloggen met mijnsite/administrator te verhinderen. Hiervoor biedt de plug-in-extensie AdminExile de meeste opties.

Als Joomla het mocht toelaten dan zou een captcha in de login goed zijn daar het een login door (hacking)programma’s verhindert.
In je cPanel kan je ook een extra paswoord voor je Joomla-administrator definiëren (cPanel > Password directories > Administrator ) (slde 18 http://www.slideshare.net/siteground/joomla-security-webinar ).
Een meer omslachtige maar bestaande methode voor Joomla-Admin login die super veilig is: de 2-key-authenticated log-in.

Wil je checken hoe veilig je paswoord bevonden wordt: https://howsecureismypassword.net/ 

Wil je een paswoord beheerder (op eender welk toestel)? Bekijk dan https://lastpass.com/

Je zou er ook aan kunnen denken om enkel bepaalde IP-adressen toegang te verlenen aan de administrator-console.

Overweeg een "secret url parameter". Met de klassieke URL voor de Joomla! back-end kan men dan niet meer inloggen tenzij er een extra parameter wordt meegegeven, me name de "secret parameter". Als bijvoorbeeld je geheime secret parameter gelijk is aan "w81seven", dan kan men enkel inloggen de back-end met de unieke url: http://www.jewebsitenaam.be/administrator/index.php?w81seven . Dus nog meer gis-werk voor een hacker. Afhankelijk van de server (Linux, Windows, ...) zouden er enige beperkingen, qua lengte van het woord enz... kunnen gelden.

5. Server software en configuratie

Dit is een domein dat je niet volledig in je hand hebt, maar er zijn zaken die toch voor jouw als site-beheerder relevant zijn.

Enkele voorbeelden van veiligheidslekken in server-software:
PHP 5.3 door in de query “?-s” mee te geven, kon je commandline argumenten meegeven waardoor php-commandos vanaf eender welke browser gelanceerd konden worden ( http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/ ).

MySQL 62bit versies tot 5.1.61, 5.2.11, 5.3.5, 5.5.22: als je herhaaldelijk probeerde in te loggen met bijv. usernaam “root” en eender welk paswoord, dan zou je na meerdere pogingen toch toegelaten worden (http://blog.sucuri.net/2012/06/security-vulnerability-in-mysql.html)

Als je in je htaccess volgende hebt staan:
    Options Indexes FollowSymLinks
dan kan een hacker een symbolic link creëren naar de root-folder om dan in de gecreëerde link vrije toegang tot alle folders & bestanden. ( Apache Symlinks bug http://seclists.org/fulldisclosure/2013/Aug/81 )
Wil je gebruik maken van symbolic links, voeg dan in je htacces-bestand ook volgende lijn toe:
    SymLinksIfOwnerMatch

Dus net zoals voor het CMS: zorg er voor dat je server-software up to date is!
Spijtig genoeg is dit bij kleine providers vaak niet het geval en heb je je er maar bij neer te leggen.

Als je een dedicated server hebt of VPS, bekijk dan je server-logs. Denk erover om OSSEC te installeren. Het gebruikt niet alleen de logs om verdacht gedrag te detecteren, maar zou ook rootkits kunnen ontdekken, het doet aan bestands-controle, e.a. (uit https://blog.sucuri.net/2016/03/how-sucuri-cleans-hacked-sites.html ).

Hoogstwaarschijnlijk zal men met je server geen FTP-connectie kunnen maken als Anonymous, maar check toch maar of het wel effectief verhinderd is.

Vermijd in MySQL DB de klassieke “jos_”prefix voor tabellen alsook de standaard administrator gebruikersnaam. Eenmaal je site geïnstalleerd is, kan je dit niet meer veranderen. Bij een volgende installatie moet je er dus wel op letten.

Overweeg een extra barrière op je login pagina's. Dit zou kunnnen door middel van een optie in de WAF (voor zover je er toegang tot krijgt) met name de “Protected Page”.

Je kan eventueel toegang beperken tot bepaalde IP-adressen (maar dan moet je zeker weten dat je steeds vanuit hetzelfde IP-adres werkt!).  Dergelijke beperkingen zou je ook via htaccess kunnen configureren.


Als je zoals de meesten een server moet delen met andere site-eigenaars ("hosted on shared" of "shared hosting" genoemd) dan zou je kunnen kiezen voor een "account isolation", tussen de verschillende websites (klanten) zit er een soort isolatie. Dit verhoogt uiteraard de veiligheid, want bij infectie van 1 website is de kans veel kleiner dat die infectie over gaat naar de naastliggende websites.

6. Mappen en bestanden

Verifiëer de toegangsniveaus, permissies, van je bestanden en folders. Volgende settings zijn voor Joomla! van toepassing (op server die draaien op Linux zoals bij de meeste providers):

  • mappen: 755
  • bestanden: 644
  • configuration.php 444

Incorrect is alles wat voor de bestands- & map-permissie een hogere waarde heeft dan 755.

In de basismap van je Joomla!-site staat ook een map met de naam /tmp . Dit is folder die gebruikt wordt om tijdelijk bestanden te stockeren ter ondersteuning van een proces zoals upgraden en installeren. Als je geen specifieke processen op je site aan het uitvoeren bent, dan kan je de daar geplaatste bestanden verwijderen op het bestand index.html na. Er zijn beheers-extensie van waaruit je deze simpele opkuis kunt laten uitvoeren.

Hackers infecteren niet noodzakelijk de Joomla-bestanden, ze kunnen - eenmaal toegang tot je server - eigen bestanden plaatsen van waaruit ze verder werken. Dit zijn zogenaamde backdoors, ze komen via deze achterdeur binnen in je systeem.
Enige voorbeelden van die backdoors en hoe ze te herkennen, kan je lezen op

Merkwaardig maar waar, volgens sommige bronnen kan jouw site geïnfecteerd worden doordat jouw bestanden die je hebt geupload, al besmet waren op jouw geïnfecteerde PC.
Dus niet alleen voor de beveiliging van jouw PC maar ook voor jouw site, is het gebruik van een malware detectie tool met een anti-virus software op jouw PC nodig.

Ben je vertrouwd met Github of een andere versioning of softwarebeheerapplicatie, dan zou je jouw gezonde site daar kunnen inchecken en de versies beheren. Als je dan vermoedt dat jouw site gehackt is, dan zou je met die applicatie de site kunnen vergelijken met de laatste ingecheckte versie.

7. Blijf ingelicht

Ben je niet elke dag of week bezig met je sites of Joomla, houd je op de hoogte of laat je inlichten van mogelijke gevaren.

Hieronder enkele sites en feeds die je hierbij kunnen helpen:

Je kan dergelijke berichten zelfs laten verschijnen in je Administrator controlepanel:

AddModuleFeed

Hoe dit te doen, kan je lezen op https://docs.joomla.org/Screen.modulesadministrator.edit.15#Feed_Display


 

C. De verdediging

1. Scannen & Firewall

Ook al is de interne beveiliging zoals hiervoor beschreven optimaal uitgevoerd, je vijand blijft inventief en zoekt naar nieuwe lekken. Virus- & malware-scanners zijn daarom net zoals firewalls noodzakelijk.

Voor web-applicaties is er een speciale firewall die niet allen het netwerk-traffiek controleert maar ook weet heeft van internet-protocollen, hoe applicaties met alkaar communiceren (OSI_layers) en daardoor een diepere controle kan uitvoeren. Dit zijn zogenaamde Web Application Firewalls,  WAF. Deze worden beheerd, geconfigureerd door je web-provider. De kracht ervan hangt niet alleen af van de gekozen WAF maar ook hoe deze geconfigureerd is, welke regels er in gedefinieerd zijn. Dus een grote provider, één die in Joomla gespecialiseerd is, zal daar meer expertise in hebben. Om je een idee te geven: personeel van SiteGround updaten hun firewall tot 200 keer per week met extra controle regels.

Zoals je kunt vermoeden heeft de keuze van provider ook een impact op de weerbaarheid van je site tegen hackers. Spijtig genoeg zijn er geen statistieken beschikbaar van hoeveel sites bij een provider al gehackt zijn. En mochten die cijfers bekend zijn, dan zou men ze ook met enige reserve moeten interpreteren: een kleine provider herbergt misschien te weinig sites die voor hackers een doelwit zijn wat een vals veiligheidsgevoel zou geven. Op voorhand goed inlichten welke services er geleverd worden tegen welke prijs, is zeker de moeite waard.

Vraag jouw provider of er een automatische scan kan gepland worden. Bij Siteground kost deze service 2 Euro/maand, bijkomende backups voor 2 Euro/maand (en 24 Euro voor een restore te laten utivoeren).

Maar je kan ook extra beveiligings services aanschaffen bij derden zoals

Joomla extensies die extra beveiligen toevoegen:

https://myjoomla.com/ biedt ook een audit-tool aan waarvoor je eerst op hun site een connecting-plug-in moet van downloaden. Dit staat uitgelegd in https://www.themexpert.com/blog/how-to-fix-a-hacked-joomla-website . Maar enkel de 1° audit is gratis! Dus waarom niet als je voor de eerste keer gehackt wordt?

De computer waarmee je updates van je site doet of waarvan je bestanden naar je site uploadt, moet ook vrij zijn van infecties! ( https://www.stopbadware.org/prevent-badware-basics ).

Enkele technische tips zoals de PHP-configuratie van je site / server kan je vinden op www.joomlatools.com/blog/2017/05/10-tips-to-improve-joomla-website-security 

2. Backups om te restoren 

Maak backups van jouw site en ... check of je ze kan restoren!
Vooraleer gehackt te zijn, moet je al uitgetest hebben hoe je een restore van je backup uitvoert en of die wel degelijk (en rimpelloos) werkt.

Hiervoor kan je de Akeeba Backup tool als extensie installeren en gebruiken . Deze heeft het voordeel dat je jouw backups zelfs op een andere server (provider) kan installeren en dit op een zeer gecontroleerde manier. Nadeel is dan wel de iets uitvoerigere = omslachtigere manier van restoren. Er is geen Restore-knop . Er is wel een link naar een video die uitlegt hoe men een restore kan doen (maar deze bleek bij Manu foutief te zijn, hij kon daarin wel de juiste link in ontdekken). Dus je moet ofwel al kennis hebben hoe een restore te doen, of de handleiding induiken. Deze laatste behandelt alle mogelijke gevallen en problemen, met het nadeel dat in een crisis-situatie je overdonderd wordt door de hoeveelheid tekst. Dus eens trainen op een restore (en neerschrijven hoe dit werkt) kan van pas komen op het krisis-moment.

Een backup en restore kan je ook doen met een software installer oplossing zoals Installatron en Softaculous. Deze zijn eenvoudiger in gebruik maar niet toegespitst op een restore bij een andere locatie. Let op, bij sommige providers zouden deze niet altijd probleemloos werken. Zo heeft Manu ondervonden bij Siteground. De server-settings zouden (in de goedkopere licentie) zo strikt zijn, dat Softaculous daar vaak strandt (ervaring van Manu). Een alternatief kan dan een externe service zijn (waarvan Installatron Remote een simpele gratis service is).

Het is geen onzin om meerdere backups te houden! Beter 1 te veel dan te weinig.

Hou zeker goed orde in al je backups!
Als je site gehackt is en je wil een restore doen, dan kunnen de zenuwen zo hoog gespannen zijn, dat een duidelijke ordening van al je backups fouten vermijdt en de stress niet verhoogt. Idealiter heb je meerdere backups (en misschien ook op verschillende manieren gemaakt), en dan is orde en duidelijkheid in naamgeving (van mappen en bestanden) noodzakelijk.

Sommige hackers gaan zo driest te werk dat ze zelf je backup-bestanden zouden verwijderen. Daarom is het aangeraden om ze op een andere plaats dan jouw site-server te bewaren. Dit kan lokaal of in de cloud zijn (Installatron laat een backup in Dropbox toe). Met Akkeeba Backup kan je de download op je site houden maar deze ook gemakkelijk downloaden naar je PC.

Een ander reden om backups op een andere plaats te bewaren, is ingegeven door de mogelijkheid dat hackers email-adressen, login/account-gegevens, ... uit de backup-bestanden halen. Als je de backup-bestanden op je site bijhoudt, check dan of de gebruikte tool hiermee rekening houdt. ( https://blog.sucuri.net/category/ask/page/2/ )

Backups kunnen we ook minder technisch benaderen, zeker voor blogs en sites waar veel inhoud op gepubliceerd wordt. Als daar de teksten om online te publiceren niet direct in het Joomla-CMS geschreven worden, dan moeten de auteurs, publiceerders, ... hun tekstbestanden die ze on-line gaan zetten, goed beheren. Mocht er dan een back-up terug gezet moeten worden waardoor de de laatste publicaties verloren zijn gegaan, dan is het een kwestie van uitzoeken welke tekstbestanden er terug online gepubliceerd moeten worden.  Dit idee had ik voor ogen maar vond ik niet de moeite om te vermelden. Toen deze site in juni 2016 gehackt werd, had ik spijt dat ik dit principe niet ten volle toegepast had. Dan was er minder schrijfinspanning verloren gegaan.


 

D. Mijn site is gehackt?

Hoe kan je weten of je site gehackt is? Hieronder enkele symptomen.

  • Meest opzichtige is wanneer jouw site andere pagina’s toont dan je verwacht.
  • Als je bij het bezoeken van jouw webpaginas op andere sites terrecht komt.
  • Als de frontend fouten geeft of zich abnormaal gedraagt. Let wel, dit kan evengoed ongewild zijn door een update van de server of de CMS-software.
  • Je krijgt een bericht (van jouw provider) dat jouw site gehackt is, dat ze off-line genomen is of dat er abnormaal veel  mails verstuurd worden.
  • Wanneer je een pagina van jouw site bezoekt, meldt jouw browser dat een download gestart wordt, terwijl je weet dat die pagina dit niet hoort te doen.
  • Bij het browsen van jouw site waarschuwt de malware of virusscanner op je pc dat surfen op die site niet betrouwbaar is. 
  • Of het zijn bezoekers van jouw site die dergelijk probleem melden.
  • Google kan bij het crawlen van je site merken dat die gehackt is.
  • Het aantal bezoekers die van Google naar jouw site komen, zakt ineens (want ze worden omgeleid naar andere sites)  

Je kan je site laten controleren op besmetting zoals je in het volgende hoofdstuk kan lezen. Er is alvast 1 snelle en simpele check : zie of je site al op een blacklist staat. De meest populaire zwarte lijsten verzamelen hun informatie uit verschillende bronnen.
Enkele linken waar je deze controle m.b.t. Blacklistskan uitvoeren:

Staat jouwe site in de lijst, dan mag je je zeker zorgen maken. Als je site er (nog) niet op staat, wil dit niet zeggen dat je site zuiver is, de andere hierboven aangehaalde signalen blijven van belang.

 

E. Het herstellen van jouw gehackte site

Ontdek je dat jouw site gehackt is, bewaar dan in ieder geval je kalmte. Daardoor zul je minder snel fouten maken in het sanerings-proces.

Saneren in een notedop

  • Na de vaststelling
    • overweeg om jouw site al of niet off-line te zetten (en later zelfs evt. door je provider in een quarantaine plaatsen)
    • verifieer welke acties, support je van je provider mag verwachten
    • begin een diagnose om de plaats van infectie te bepalen,
  • Als je de bron van infectie gevonden hebt, saneer je deze:
    • verwijderen van hackers-bestanden
    • updaten van Joomla en zijn extensies & templates
  • Blijft de infectie doorzweren, overweeg dan
    • een volledige opkuis van folders en bestanden om dan een (gezonde) backup te restoren.
    • assistentie door experts
    • of zelfs eventueel een switch naar een professionele provider.

Saneren, herstellen van een besmette site in detail

Onderstaande lijst van acties houdt niet in dat je ze allen moet uitvoeren. Wat je wel of niet doet hangt af van de context, van jou specifieke voorkeuren.

1. Contacteer je web provider en zie wat zij als hulp aanbieden.
Kom ook overeen of je tijdelijk over de toegelaten file-space mag gaan (mocht je al er dicht tegen zitten).

2. Scan je site om de infectie te lokaliseren:
Zoek in backoffice tools van je provider, zoals bijv. cPanel, of er geen scanner ter beschikking staat. Als je provider al een scan op je site gelanceerd heeft, sla je deze stap over om de server niet onnodig te belasten. Overweeg eventueel een scan- & diagnose-dienst specifiek voor Joomal zoals https://myjoomla.com/ .
Google detecteert tijdens het crawlen van sites dat ze gehackt of besmet zijn. Of dit gebeurd is met jouw site kan je nagaan via volgende URL waar je jouw site als parameter meegeeft:
http://www.google.com/safebrowsing/diagnostic?site=http://www.uwdomein.xy Je krijgt het antwoord onmiddellijk, dit is dus de status van de laatste keer dat Google je site bezocht heeft.
Als hier positief nieuws uitkomt, kan het nog altijd zijn dat je site besmet is.
Volgende on-line tools kan je ook gebruiken:

Start niet meerdere scans terzelfdertijd op want dan belast je de server onnodig.
Het is uiteraard niet gegarandeerd dat deze scanners alles detecteren, maar ze kunnen er veel uit halen.
Scan ondertussen ook je PC omdat je die wellicht nodig zult hebben voor bestanden te vergelijken, om een verse Joomla-versie te installeren of om backups te restoren, ...

3. Beslis om je site of-line te zetten. Sommige gehackte sites infecteren de PC van bezoekers!
Beslis in overleg met je provider om jouw site eventueel in quarantaine te zetten. Dit verhindert dat jouw hacker zich propageert naar de andere websites op die server. De provider zou jou dan daartoe specifieke FTP toegang moeten geven zodat je alles kan nazien en de infecties kan verwijderen of een zuivere backup kan terugzetten.

4. Heb je geen tijd of geen expertise, zoek dan contact met vrijwillige helpers (uit je netwerk) of  een bedrijf zoals https://myjoomla.com/site/is/hacked (voor £88)

5. Verander je paswoorden.
Uit de speciale sessie die we over beveiliging hadden bleek deze actie echter geen soelaas te brengen. Caroline heeft zo meerdere keren al haar paswoorden veranderd en toch kwam de hacker na een paar dagen terug. Een extra login om tot de administrator-module te komen, werd wel aanbevolen.

6. Probeer uit te zoeken welke bestanden geïnfecteerd zijn.
Denk wel even na vooraleer je tot deze actie overgaat: je kan hiermee toch wel wat tijd mee verliezen. Het vereist ook enig technisch inzicht. Een uitgebreid artikel met concrete informatie (en links voor meer details):
http://www.bluebridgedev.com/hacked-joomla-files .
Is je database geïnfecteerd dan zou je een export van de database kunnen doen en op dit bestand een scanner kunnen loslaten. Hierover hebben we echter geen specifieke overtuigende getuigenis gevonden en zijn we geneigd om eerder een restore aan te raden (zie verder).

7. https://myjoomla.com/ biedt een audit aan. Hiervoor moet je eerst een connecting-plug-in downloaden van hun site en die dan in jouw Joomla! installeren. Meer uitleg in https://www.themexpert.com/blog/how-to-fix-a-hacked-joomla-website .
Installeer een veiligheidsextensie mocht je die nog niet hebben.
Zo ontdekte Manu dankzij (een weliswaar late aanschaf) RSFirewall dat de infectie in de extensie BreezingForms gebeurde, wat na een update verholpen zou zijn. ( Deze veiligheidslek werd pas 2 maanden later in Joomla! Vulnerable Extension List vermeld https://vel.joomla.org/resolved/1821-breezing-forms-full-and-lite ).
Lees Step 4 van https://www.joomshaper.com/blog/my-joomla-site-was-hacked-what-to-do

8. Update alvast de geïnfecteerde extensie en zie of de hacker dan nog binnenkomt.
Verifiëer ook alle andere extensies en templates en overweeg ook daaravoor updates.

9. Als je site gehackt wordt om te spammen, vraag je provider of hij verzendingen kan stopzetten en wat te doen met de gebouncte mails (mails die terugkomen in je site-mailbox wegens “niet bestaand email-adres” of andere leverings-problemen). Bij de gehackte site van Manu waren dit tot 100 mails per minuut waardoor de mailtool op de server soms crashte.

10. Als je site on-line blijft staan, laat dan Google je site niet meer indexen om te vermijden dat hij je site als “gehackt” catalogiseert, wat voor surfers erger klinkt dan een site off-line. (in Joomla backend Algemene settings >  Website: Robots = “Geen index, no follow”). Je zou er aan kunnen denken om in die Algemene settings onder Server de setting Disable Mass Mail =”Ja” te zetten om het spammen door de hacker te verhinderen, maar de hacker gebruikt niet de Joomla-verzendings modules.

11. Blijft de hacker toeslaan na de update van de extensie(s), dan kan je proberen om de site terug te zetten naar een tijdstip van voor de infectie.
Vooraleer dit te doen is het goed als je een backup neemt van je site zoals die nu is. Maak het duidelijk voor jou dat die backup  geïnfecteerde bestanden bevat (geef een duidelijke naam of plaats hem in een aparte folder). Maak zeker een apart export van de data base. Dit zal later toelaten om hieruit (de meest recente) gegevens te halen en die later in jouw herstelde site te importeren (indien nodig, hangt ook af van welke backup voor een restore genomen wordt).

12. Zoek uit welke backup van je site nog niet geïnfecteerd zou zijn en alzo in aanmerking komt voor een restore.
Er zijn dan 2 scenarios die je kan volgen voor een restore:

  • de gekozen backup installeer je lokaal om daarop updates te doen van de extensies & templates waarna je deze gezonde, lokale site verhuist naar de server ,
  • of je doet de restore onmiddelijk on-line om dan daarop de updates te doen.

Vooraleer on-line te restoren moet je wel alle Joomla-site-mappen deleten zodat ook niet-Joomla-bestanden verwijderd zijn (als de hacker zijn eigen bestanden op de server gezet heeft, dan zouden deze met een restore kunnen blijven staan omdat ze niet overschreven zouden worden).
Hou orde in je backups & restore, schrijf dus op welke restore je doet. Het kan namelijk blijken dat de gekozen backup ook al geïnfecteerd was zodat je een nog oudere backup moet restoren.

13. Blijft de infectie doorduren ondanks de restores, overweeg dan professionele hulp in te schakelen of het switchen naar een professionelere web provider. Dit is een beslissing die Manu en Caroline genomen hebben met goed gevolg. Beiden zijn nu bij Siteground en hun WAF blijkt dus met succes hackers te kunnen afweren.

 

F. Vergeet niet ...

Mocht jouw site op een blacklist geraakt zijn, lees dan op http://www.bluebridgedev.com/remove-joomla-blacklist hoe je een herziening van je site kan aanvragen (om van de blacklist afgehaald te worden).

Ben je van provider overgestapt, vergeet dan niet bepaalde backoffice settings over te nemen zoals:

  • Email Forwarders en Autoresponders
  • Spam-settings
  • Email Address Book en indien nodig de berichten zelf
  • URL-redirects
  • FTP-settings

Denk ook aan het opzeggen van je contract bij je oude provider.
Verifieer of het officiële (contact)adres voor je domeinnaam juist is (het mag zeker niet verwijzen naar de oude provider).

Is je site terug gezond, verzoek dan in Google Webmaster Tools om je site terug te crawlen. Dit herindexeren van je site gebeurt uiteraard niet onmiddellijk, maar na een paar dagen zou je met een zoek-opdracht in Google niets abnormaals van je site mogen merken.

Ben je ongeduldig en is je site gehackt voor (linken naar) ongepaste reklame, dan kan je eventueel surfers komende van Google Search hiervoor kortsluiten door aanpassing van htaccess-bestand:

  • RewriteRule \S*viagra+\S* - [G]
  • RewriteRule \S*cialis+\S* - [G]
  • RewriteRule \S*pharmacy+\S* - [G]
  • RewriteRule \S*propecia+\S* - [G]
  • RewriteRule \S*drugs+\S* - [G]

(post #7 op http://www.joomlacommunity.eu/nieuws/gebruikersgroepen/983-website-hack-via-xmlrpc-backdoor-script.html )

Als je een restore gedaan hebt, dan zullen op je site zaken ontbreken die gepost zijn in de periode tussen de datum van de gerestored backup en nu. Dit kunnen gegevens uit de data base zijn alsook bestanden. Om die te recupereren kan het zeer handig zijn mocht je over de gegevens beschikken op het laatste moment van de site. Alzo moet je de auteurs en publiceerders van de site hun publicatie-werk van de periode niet herdoen. Die recuperatie van gegevens kan je doen uit de meeste recente backup (zelfs die van de gehackte site). Uit deze backup kan je (na ontzippen) de database-export extraheren alsook content-gerelateerde bestanden. Je hoeft dus daarvoor niet per se die backup (lokaal) te restoren tot een site.

De recuperatie van gegevens uit de database wordt in het volgend hoofdstuk besproken. Deze recuperatie doe je het best eerst (toch zeker als je een dead-link check gaat gebruiken om ontbrekende bestanden te ontdekken).

Voor de recuperatie van bestanden moet je zeker weten dat deze niet geïnfecteerd zijn.
Welke afbeeldingen en andere bestanden er ontbreken, kan je ondermeer ontdekken door je site te checken op dead-links.
Maar er zijn ook bestanden die zo niet gedecteerd kunnen worden. Denk maar aan deze die door een Javascript opgeroepen worden (zoals o.m. bij KML-kaart-bestanden die via extensies opgeroepen worden in javascripts) of bestanden waar in de gepubliceerde content geen link naar is.

 

G. Herstellen van verloren data

Inhoud:

 

Als je een restore doet, dan zal de herstelde site gegevens missen die in de database ingevoerd zijn in de periode die ligt tussen het maken van de gebruikte backup en het moment dat je de gehackte site verwijderd of off-line gezet hebt. Deze periode wordt verder in de tekst hieronder steeds aangeduid als de tussenperiode.

Als je beschikt over een database die recenter is dan de herstelde site (bijvoorbeeld doordat je van de gehackte site de database lokaal gerecoverd hebt), dan kan je daaruit de gegevens exporteren die niet voorkomen in de herstelde database omdat deze afstamt van een oude backup t.t.z. van een eerdere datum. De eerste zullen we verder aanduiden als bron-database en de tweede , de online versie, als doel-database.
In dit hoofdstuk tonen we aan hoe je dergelijke gegevens kunt recupereren, ze invoegen in de herstelde site.

Het manueel invoegen van verloren data is best te doen als er weinig records betrokken zijn, zoals bij categorieën of sjablonen / templates van nieuwsbrieven.
Een transfer van data zal handiger zijn als er veel records aan te pas komen, of bij records met veel in te vullen waarden.
Hiervoor kan je hulpmiddelen gebruiken die in de betreffende extensies voorzien zijn, of je kan eigenhandig een export & import doen via een database-interface zoals phpMyAdmin.
Hulpmiddelen die we hier niet zullen bespreken zijn extensies specifiek voor datatransfer die je in de Joomla Extensions Directory kan vinden onder Migration & Conversion http://extensions.joomla.org/category/migration-a-conversion met ondermeer Jupgrade en SP Upgrade.

We bespreken hier enkele de gevallen die we effectief hebben uitgeprobeerd zoals mail-extensie AcyMailing, RSForms, JEvents.
Mocht je ervaring hebben met andere methoden of specifieke van de extensies zelf, laat niet na je ervaring te delen door het ons op te sturen.

Export/import via PhpMyAdmin

Hoewel je zelf een SQL-query kunt schrijven die als output SQL-query commando's heeft die enkel die records invoegt die je effectief nodig hebt, gaan we hier eenvoudiger te werk door de te starten met exporteren van tabellen  (om in dat resultaat dan te filteren wat we effectief nodig hebben).

In de beschrijving hieronder wordt de tabel-prefix weergeven door # welke je dient te vervangen door de prefix die jij in jouw database hanteert.

Export van 1 tabel

In de meest volledige database die je ter beschikking hebt, selecteer je in de linkernavigatie-boom de gewenste tabel.
Rechts zie je dan de daarbij horende records, rangschik de rijen naar creatie-datum of ID (dalende volgorde). Als er heel veel records in de data base staan (of ze bevatten heel veel gegevens), zoek dan vanaf welke rij er nieuwe records bijgekomen zijn die in aanmerking komen voor jouw data-recuperatie. Let wel, het rijnummer is niet noodzakelijk gelijk aan de record-ID, je moet het rijnummer vinden.
Kies dan uit het menu Export (als titel van de pagina krijg je dan Exporting rows from “....” table).

Als Export Method ga je voor een Custom methode waarin je bij Dump some rows kan specifiëren vanaf welke rij je de export wil doen (en voor hoeveel rijen). Als je niet alle records wil exporteren vul dan hierin vanaf welke rij je de records wil exporteren (row, niet te verwarren met het sequentieel ID dat misschien in de gekozen tabel aanwezig is).
Omdat in de bron-database alle tabellen al bestaan moet er geen commando voor tabel-creatie in de export staan: kies in Format-specific options: onder Dump table voor de radiobutton data. Mocht de tabel in de bron-database een veld minder hebben, dan moet je die manueel creëren of je kiest hier voor "Dump table:" de optie "structure and data".
Voor Data creation options: kan je volgende settings nemen:

phpMySql export Options

De REPLACE zal bestaande records overschrijven wat ideaal is als er enige eigenschap in de tussenperiode gewijzigd was. De REPLACE methode zal ook een insert doen indien het geëxporteerde record nog niet in de doel database staat, handig niet? Nadeel van de REPLACE is dat deze records zal overschrijven als er na de restore online nieuwe records zijn ingevoerd. Deze riskeren te worden overschreven door de import. Als je kiest voor een INSERT dan zal botsen op een primary key constraint probleem:


Door te kiezen voor de syntax both of the above zal in het SQL-commando de kolomnamen gespecificeerd worden met daarachter dan de overeenkomqtige waarden. Niet alleen handig om te interpreteren wat het commando zal doen, maar mocht de tabel in je doel database gewijzigd zijn (door upgrades te doen van een extensie of het CMS) dan zal de import nog lukken omdat de te gebruiken kolomnamen gespecifieerd zijn.

Export van meerdere tabellen

Vele extensies hebben meerdere tabellen in de database geassocieerd en tussen die tabellen kan er een verband bestaan dat voor een import van belang kan zijn, in bijzonder de parent - child relationship. Bij MySQL  blijkt dit tot nu soepel te werken (een record van de child-tabel kan gecreëerd met een foreign key nog voor deze in de parent tabel gedefinieerd is), maar we gaan er toch even dieper op in (mocht de volgende versies van MySQL hiermee wel rekening houden).

Het gebeurt dat een kolom van een tabel verwijst naar een (record in een) andere tabel. Dit zijn zogenaamde foreign keys = een ID waarvan de eigenschappen in een andere tabel gespecifieerd zijn. De ID in die andere tabel wordt de primary key genoemd en moet uniek zijn (unique key). Het record van de primary key (de parent) zou dus moeten eerder moeten gecreëerd zijn dan het (child) record dat ernaar verwijst (d.m.v. de foreign key). Dus bij een import zou eerst de parent(table) geüpdated moet worden, zodat alle unique keys daar in aanwezig zijn. Dan pas kunnen de children (met hun foreign keys) gecreëerd worden.
De export via phpMyAdmin gebeurt alfabetische en houdt hiermee geen rekening. Maar uit onze import experimenten blijkt dit geen bezwaar te zijn.
Mocht hierover toch nog een import-foutmelding uitkomen, editeer dan je export-bestand en zet dan de insert-commando's voor elke tabel op de juiste plaats, zodat eerst de parent en dan de child gegevens geüpdated worden.
Voor alle zekerheid worden in de voorbeelden hieronder de child – parent relaties wel aangehaald. Zo zijn de Artikelen zelf maar in 1 tabel geregistreerd, maar hebben zij als verwante tabellen : de categorieën, de gebruikers, de tags, … We gaan in een volgend hoofdstuk hier dieper op in, de werkwijze kan inspireren voor andere gerelateerde tabellen & gegevens.
Er is 1 tabel die je zou kunnen tegenkomen in je onderzoek naar parent – child relationship en die speciale aandacht vraagt: de tabel #_assets. In het hoofdstuk van Artikelen importeren wordt hierop in gegaan.

Het is belangrijk om weten wat de parent & forreign keys zijn en waarvoor ze staan. Je moet steeds nagaan of de meest reccente parent keys in bron én in doel-databases verwijzen naar dezelfde records. Het kan namelijk gebeuren dat er in de tussenperiode parents zijn geccreëerd (die dus in de bron-database voorkomen) en dat er na de restore online (die die parent mist) er een andere parent gecreëerd werd. Als de (unique key voor de) parent key een numerisch veld is, dan is de kans groot dat na een import de child-records wel naar een bestaande parent verwijzen maar niet de oorspronkelijke (metaforisch zouden we kunen zeggen dat de ehte vader ingeruild is voor een stiefvader). Hier zal vaak een manuel interventie vereist zijn.

Hoe ga je tewerk in MyPhpAdmin?

In phpMyAdmin selecteer je de database, in je navigatie-boom is dit net boven je tabellen.
Kies dan uit het menu de optie Export  (als titel van de pagina komt dan Exporting tables from “....” database).
Als Export Method gaan we voor Custom om dan in de lijst Tables de tabellen te selecteren.

Voor Object creation options ontvink je best alles zodat het exportbestand lichter wordt. Waarom? De tabellen zouden al bestaan in de doel-database en je export-bestand moet je niet onnodig vergroten (je gaat het allicht nadien nog nazien en evt. aanpassen, vandaar).

Net zoals bij een enkelvoudige tabel-export kies je hier bij "Function to use when dumping data:" de methode REPLACE.

En GO !

Het bestand dat je dan downloadt kan je editeren. Je kan hier de lijnen (records) uit verwijderen die je onnodig acht (bijvoorbeeld lijnen voor records die al lange tijd geleden gecreëerd zijn en tijdens de tussenperiode ongewijzigd gebleven zijn).

Import

Het kan nooit kwaad om eerst het import-bestand met een editor te verifiëren, dan weet je wat je gaat importeren.

In de doel-database selecteer in de linker navigatieboom de database waarin je gaat importeren.
Kies in het menu Import en selecteer dan je bestand en GO!

Wat kan er mislopen?

Als je lijnen uit het export bestand verwijderd hebt (bijvoorbeeld om enkel essentiële udpates te doen), let er dan voor op dat het einde van het commando toch nog met een punt-comma eindigt. Als je de laatste lijnen van een commando verwijderd dan zal de overgebleven lijn waarschijnlijk eindigen op een komma (omdat er normaal een volgende lijn met record-waarden opvolgde). Dit geeft volgende fout en is op te lossen door de komma te vervangen met een komma-punt wat het einde van MySQL-query commando beduidt.

import quote Error

Als je een import doet en in de doel-database zijn er al nieuwe records gecreëerd, dan riskeer je dat je door de REPLACE deze records overschrijft met de net iets oudere gegevens. Als je inplaats van een REPLACE een INSERT gekozen hebt, dan zal je dit mogelijk conflict ontdekken door volgende foutmelding:

import syntaxError DuplicateKey

Dan kan je de unique key in je import-bestand aanpassen (verhogen) maar zorg er dan wel voor dat alle verwijzingen hiernaar ook aangepast zijn (foreign keys !). Andere mogelijkheid bestaat er  uiteraard in om deze gegevens manueel in te voeren.
 

Artikelen

Als we de verloren artikelen willen importeren dan zijn er aanverwante gegevens die misschien ook mee moeten gecreëerd worden. Meest voor de hand liggende zijn categoriën, maar er zijn ook gebruikers en tags.

Je kan categoriën handmatig creëren in je doel database maar ze moeten zeker hetzelfde ID hebben als deze waaruit je de artikels exporteert!

Als we rekening houden met parent & child relationship dan zou de import in volgende orde moeten gebeuren:

  1. gebruikers    indien er ondertussen nieuwe gecreëerd zijn:
    • #_usergroups
    • #_users
    • #_user_keys, #_user_notes, #_userprofiles, #_user_group_map
  2. categoriën    indien er ondertussen nieuwe gecreëerd zijn:
    • #_categories
  3. tags    
    • #_tags
    • #_contentitem_tag_map
  4. artikels    
    • #_content
    • #_content_rating, #_content_frontpage

Tabel #_content_types wordt bepaald door de extensies en we veronderstellen dat daar geen verandering in zit (enkel upgrades).

In de tabel #_content verwijst het asset_id naar een record in de tabel  #_assets. In assets worden de access-rights gespecificeerd. Maar niet alleen #_content maakt gebruik van de tabel #_assets. Daarmee is het riskant om de foreign keys (van de bron-database) zomaar over te nemen, het kan namelijk goed zijn dat je op de online site updates hebt gedaan waardoor in de bron-database nieuwe #_asset-records gecreëerd zijn. Dan riskeer je dat in de bron-database het asset_id dat bij  #_content staat in de bron-database een bestaand record gaat overschrijven dat voor een ander element nodig is.
Dit kan je oplossen door in je import-bestand in de lijnen met records voor  #_content het asset_id op 0, zero, te zetten, dit beduidt dat er in de (partent) tabel #_assets nog geen overeenkomstig record voor bestaat.

import articles asset id

Na de import kan je in de front-end verifiëren of dit enig probleem geeft voor het tonen/lezen van de content. Als je de geïmporteerde artikels opent in Artikelbeheer en ze dan bewaart (zonder enige wijziging te doen), dan zal Joomla! het #_asset-record hiervoor creëren zodat de juiste accessrights in de database staan.
Mocht het nodig zijn, weet dan dat de extensie ACL Manager een correctie voor de gegevens in de asset-tabel voorziet.

Jevents

Als we voor de extensie Jevents de parent-child relations ship zoeken, om de volgorde van import te kennen, komen we tot volgende volgorde:

  1. 1. waarschijnlijk niet nodig:
    • #_jev_defaults, #_jev_users ,
    • #_jevents_filtermap  , #_jevents_icsfile , #_jevents_translation
    • #_jevents_catmap
  2. #_jevents_vevdetail
  3. #_jevents_vevent
  4. #_jevents_rrule
  5. #_jevents_repetition
  6. #_jevents_exception

Als je naar de records in de tabellen gaat kijken, dan zal je merken dat je de export in feite kan beperken tot een paar tabellen (zeker 2 en 3 en misschien ook 4 tot 5).
Je kan proberen om alles te importeren zoals het in de exportbestand stond zonder op bovenstaande volgorde te letten. Dit lukte in onze test (maar in de JEvents-kalender stonden geen repetitieve events geboekt).

AcyMailing

Als er een nieuwe nieuwsbrief gecreëerd was, dan is het een kleine moeite om dit manueel te doen.

Voor de email-adressen, onder AcyMailing Gebruikers genoemd, biedt AcyMailing een handige export & import functie.

AcyMailing toont je een hele lijst van velden die je mee kan exporteren. In onze test was er een update gebeurd in de online site waarbij er een tabel-wijziging gebeurd was. De foutmelding die er dan bij een import getoond werd, maakte het gemakkelijk om de juiste velden voor export & import te kiezen.

Ga zeker na of er recent nog nieuwe nieuwsbrieven aangemaakt zijn in de bron-database en in de doel-database. Mocht dat het geval zijn in de doel-database, dan is er een risiko dat dat record overschreven zal worden door de parent uit de bron terwijl het toch om 2 verschillende nieuwsbrief-instanties gaat! En dat kan niet de bedoeling zijn. Hier zal dan een manuel interventie nodig zijn.

Bij de import moet je in het scherm eerst de standaard settings wijzigen opdat jouw import de (oudere) gegevens wel zou overschrijven met de (recentere) import-gegevens zoals in onderstaande afbelding getoond.

AcyMailing Importeer

De reeds bestaande nieuwsbrieven zie je opgelijst onder de hoofding Schrijf de geïmporteerde gebruikers in
Je kan de settings daaronder op “Nee” laten staan.

Het is de (mail)list-id die in je csv-bestand staat, die met de import gebruikt wordt bij het updaten van de gegevens (wat effectief de bedoeling is in deze context).

AcyMailing laat ook export & import toe van Templates, Statistieken, ...

RSForms

Bij RSForms kan je een export & import uitvoeren via hun Backup en Restore waarbij de volledige web-form genomen wordt en waarbij je zeker niet mag vergeten om aan te duiden dat je de geposte records , submissions genoemd, ook mee wil nemen.
Ben je alleen geïnteresseerd in de submissions dan kan je werken met de export van volgende tabellen:

  • #_rsform_submissions
  • #_rsform_submission_values

Mocht je niet zeker weten of je formulier gewijzigd werd, neem dan ook mee:

  • #_rsform_submission_columns

Je zal merken dat in #_rsform_submissions de datum staat wanneer het record gecreëerd werd. Daarmee kan je  eventueel enkel die reccords selecteren die je wil. Voor de daar vermelde SubmissionId zal je in #_rsform_submission_values de gereliëerde records vinden en dit voor elk invulveld van het betreffende formulier.

Vergeet niet te verifiëren of in jouw formulieren de mogelijkheid geboden werd om bestanden op te laden. Zo ja, dan moet je daarvan de map opzoeken (gespecificeerd in het formulier bij de eigenschap van het  oplaad-veld) om daar de missende bestanden op te zoeken.


 

H. Afsluiter

Een gehackte website desinfecteren heeft geen vast patroon. Niet elke infectie is dezelfde, het zijn niet altijd dezelfde bestanden die geïnfecteerd zijn en ook de manier waarop ze geïnfecteerd zijn wijzigt. De hostingbedrijven en website eigenaars passen hun strategie aan na een hack, maar ook de hackers passen hun strategie aan. Het is net zoals met virussen. Je kan pas een bescherming maken of instellen zodra je weet waartegen. Dus de makers van antivirus programma’s lopen steeds een beetje achter. Daarom ook dat nieuwe virussen zich soms zo snel kunnen verspreiden. Gelukkig zijn de meeste virussen , trojans enz.  een variatie op bestaande en worden ze vrij snel ontdekt.  Dit gaat zo evenzo met het hacken van websites. Je kan enkel proberen om het de hackers zo moeilijk mogelijk te maken zodat ze een andere website gaan hacken … en hopelijk die dan van je concurrent ;-) Onze tips hiervoor hopen je hierbij te helpen.

De 2 leden van JUG-Vlaanderen wiens site gehackt werd in 2015, hebben hun site terug kunnen veilig stellen door een restore te doen inclusief (extensie)updates. Zij hebben gezocht naar de infectiehaard via geïnstalleerde veiligheidsextensies (dus geen manuele bestandsvergelijking). Tevens zijn ze naar een (duurdere) professionele provider overgeschakeld zodat er een regelmatig scan gebeurd. Het wisselen van het wachtwoord bracht geen soelaas. Voor de ongelukkige hobbyist was het ontbreken van tools en software (zoals malware-scanner) op zijn persoonlijke PC een stress-factor, alsook geen raad weten "wat nu? hoe ga ik dit te lijf?" terwijl de web-provider geen steun boodt en zwak communiceerde.

Ten laatste nog deze wijze raad: “Gratis en goedkoop” is bijna altijd en overal synoniem voor “minder goed en of betrouwbaar”. Het hangt ook af van welke soort website je wil beschermen. Commerciële sites hebben meestal meer financiële mogelijkheden dan hobby sites… enz...

i. Annex

1. Weetjes

Wil je weten met welke sites je server deelt? Vul je domeinnaam bij www.robtex.org zoals in https://www.robtex.org/?dns=www.mynsite.be
Een ideale htaccess zou er uit kunnen zien als https://github.com/nikosdion/master-htaccess/blob/master/htaccess.txt
Een laagdrempelige uitleg over gehackte sites in het algemeen, wat ertegen te doen, kan je volgen in de video-lessen van Google https://www.google.com/webmasters/hacked/?hl=nl
Op https://support.google.com/webmasters/answer/2600721 vind je in het tekstgedeelte enkele commando's om bestanden te doorzoeken

Je kan de veiligheids aankondigingen als een feed in je Administrator cPanel tonen. In Module beheer kies je voor backend. Klik dan op Nieuw en selecteer een Feedweergave module. De URL = http://feeds.joomla.org/JoomlaSecurityNews en Positie= cPanel. De Feedbeschrijving geeft enkel een titel weer in de vorm van [datum] – type – titel zoals:
    [20151207] - Core - SQL Injection
    [20151206] - Core - Session Hardening
    [20151201] - Core - Remote Code Execution Vulnerability
    [20151205] - Session - Remote Code Execution Vulnerability
Als je de Itembeschrijving aanzet, krijg je geen korte beschrijving maar een heel pak tekst waardoor je het overzicht op je cPanel verliest.

2. Tekstbronnen en bijkomende literatuur

Veel van onderstaande links zijn geraadpleegd bij het schrijven van dit artikel. Het zijn vooral de eerst vermelde links waarop je weinig nieuwe zaken tegen komen.

Top artikel is zeker https://www.joomshaper.com/blog/my-joomla-site-was-hacked-what-to-do
en voor het opkuisen van de hack, lees ook (iets technischer dan dit artikel) https://sucuri.net/guides/how-to-clean-hacked-joomla (jan. 2018)

In het Nederlands is er een handig artikel dat een veiligheids-checklist (met enige uitleg) aanbiedt dat ook in PDF-formaat te verkrijgen is op https://www.vaneldijk.nl/artikelen/de-ultieme-securitychecklist-voor-je-website .

Goede uitleg SQL-injection: http://searchsoftwarequality.techtarget.com/definition/SQL-injection met daaronder een link naar een Microsoft artikel waar een simpel maar duidelijk voorbeeld aangehaald wordt: https://technet.microsoft.com/en-us/library/ms161953(v=sql.105).aspx  

Bespeking van dabatase hack in de tabellen van Joomla!: http://www.itoctopus.com/database-hacks-on-joomla-the-worst-kind-of-hacks
Ander voorbeeld: https://www.packtpub.com/books/content/preventing-sql-injection-attacks-your-joomla-websites

Voorbeeld van backdoor (en waar het zoeken naar eval of base64 niets zal opleveren): http://ottopress.com/2009/hacked-wordpress-backdoors/

In een Engelstalig artikel over het beveiligen van je Joomla-site worden er zeer technische tips vermeld zoals o.m. je PHP-configuratie.

Zelf op zoek naar de infectiehaard? Lees dan zeker http://www.bluebridgedev.com/hacked-joomla-files

Web Application Firewalls:

Ander detectiesysteem: OSSEC http://dcid.me/ossec.html

Over backups: https://blog.sucuri.net/2015/06/websites-hacked-via-website-backups.html


 Auteur: Manu Ampe, met dank aan Karel Mertens voor het nalezen.