Goedkoop gekocht in India, de rekening betaald in Nederland

Een WordPress opdracht uitbesteden in India kan natuurlijk gewoon goed gaan. Maar het ging onlangs goed fout bij een opdrachtgever, die werd verleid tot het goedkope Indiase tarief en onze dienstverlening ‘beperkte’ tot slechts hosting. Het liep anders.

Lees en leer van onderstaande ervaringen, het kan iedereen overkomen en ook in ons land

De website draaide eigenlijk in aanvang probleemloos en we besteedden er eigenlijk geen aandacht aan. Er was immers geen sprake van een onderhoudsovereenkomst. De afgenomen dienst was inderdaad beperkt tot ‘kale hosting’.

Disable All WordPress Updates

Vanuit onze interesse voor de in India gebouwde ‘vergelijkingswebsite’ keken we (met toestemming) zo af en toe mee tijdens de bouw van de site. Er viel iets op. Er was een plug-in geïnstalleerd met bovenstaande naam. We vroegen ons het nut van zo een voorziening af en belden de website eigenaar. We gaven aan dat het blokkeren van de zichtbaarheid van updates de veiligheid van de site ernstig zou kunnen schaden. Immers updates zijn er niet voor niets. De plug-in werd door ons verwijderd en vroegen of de noodzakelijke plug-in updates uitgevoerd konden worden. We spraken af dat de eigenaar dat in India liet uitvoeren. En dat leek te geschieden. Een paar dagen later leek dat inderdaad het geval te zijn, er waren geen meldingen meer van ‘openstaande’ updates.

Afgelopen maand

Half augustus deed zich een vervelend verschijnsel voor. Het domein werd overspoeld door spam-mails, de queue liep vol, omdat de vele mails niet afgeleverd konden worden. Na diverse tests bleek de queue in een uur vol te lopen en nauwelijks onder controle te houden. Boven de 2000 mails, was ons control panel Plesk niet meer in staat de queue langs normale wijze te legen. Dat kon alleen nog via de command line interface in Linux. De site werd dientengevolge door ons ‘on-hold’ gezet. Een uitgebreid onderzoek volgde en er werden talloze besmette bestanden (scripts) ontdekt en verwijderd. Ook waren rechten/eigenaar/groep van diverse mappen/bestanden ‘beschadigd’ met o.a. 777 (volledige toegang voor aanvallen van buitenaf). Een flinke klus om alles op te knappen, maar uiteindelijk beschouwden we de site weer als clean en installeerden de Sucuri Security plug-in om de zaak in de gaten te houden. Maar ook deze plug-in ontdekte onderstaande truc niet.

Truc

Een fake versie 5.3.9 van een plug-in

Aanvankelijk leek de strijd gestreden. De queue bleef leeg en de site-eigenaar was tevreden met het resultaat, maar moest wel een factuur betalen tegen een Nederlands tarief. Zo een vijf keer hoger dan in India. Daar snapten ze er ‘niets’ en zeiden dat alles up-to-date was. Dat ‘up-to-date’ bleek een truc te zijn. Na pakweg anderhalve week rust, begonnen de mails weer binnen te komen, echter in een lager tempo, dus geen redenen om de site weer ‘on-hold’ te zetten. Maar merkwaardig was het wel, het geheel was immers clean. ‘Waar komt dit vandaan’, was onze vraag samen met de website-eigenaar, die natuurlijk pro-actief meewerkte in de zoektocht naar een oplossing, verhuizen leek geen optie. Immers een vollopende queue is vrijwel altijd de oorzaak van malware of lekken in plug-ins of thema bestanden. Maar de site leek ‘clean’. Dus wat was de oorzaak? Een truc.

Ook de in eind 2014 aangevallen plug-in Rev Slider bleef steken op een versie 4.3.2 (25 maart 2014) , terwijl 5.3.2 werd verondersteld

India

In India had men kennelijk geen zin om plug-ins te updaten. Na het verwijderen van de ‘Disable All WordPress Updates’ plug-in bedachten ze een wel heel creatieve manier om het kleine beetje update werk te omzeilen. Van de ongeveer 20 plugins werden de meeste handmatig voorzien van een veel hoger versie nummer, waardoor updates niet meer werden herkend. Een 1.1 plugin kreeg bijvoorbeeld 3.0. Dan kan je een tijdje vooruit. Het gevolg laat zich raden, talloze plug-ins verouderden, zonder dat iemand het nog opmerkte. Wij kwamen erachter door ons onderhoudssysteem MainWP. De websites die we met dat systeem onderhouden moeten worden voorzien van een zogenaamde ‘child plug-in’. Daarvan kennen we natuurlijk het versienummer. Dat was in ons geval 2.0.27, maar vanuit India had men versie 2.3.4 ‘bedacht’. Deze stond in de header van de plug-in. U raadt het al, dat was dus bij vele plug-ins het geval. ‘India’ had de ‘WordPress Eco-Structuur’ om zeep geholpen met alle gevolgen van dien. Onderzoek wees uit dat ca. 10 plug-ins (hopeloos) waren verouderd. Meteen de oorzaak van de problemen? 100% zeker is dat natuurlijk op voorhand nooit, maar plug-ins die ‘meegaan’ tot versie 3.8 vormen zeker een risico. Samen met de opdrachtgever overleggen we nu over de maatregelen.

Raar bouwsel

Wat zouden de argumenten kunnen zijn geweest? De site-eigenaar vertelde dat ‘ze’ in India een vergelijkingtool hadden ontwikkeld. Wij dachten aan een plug-in (konden we al niet ontdekken), maar ze bleken (achteraf) in een thema- Classified Engine – te hebben ‘gewerkt’. Ze namen niet de moeite hun bouwsel in een ChildTheme te ontwikkelen, maar ‘programmeerden’ rechtsreeks in het ParentTheme. Wederom een grote fout, welke voorkomen had kunnen worden. Maar de site-eigenaar had onvoldoende kennis en vertrouwde de bouwers in India.

Hoe nu verder?

Natuurlijk kunnen de plug-ins worden ‘opgeknapt’ met de meeste actuele versies. Maar de site-eigenaar blijft zitten met een thema (had versie 1000 ‘gekregen’) welke eigenlijk nooit meer ge-update kan worden, immers daarmee zouden alle ‘custom-made’ aanpassingen verloren gaan. Juist om dat argument wilde men in India voorkomen dat iemand ooit ergens de ‘update’ knop zou indrukken. En zo wordt goedkoop toch duurkoop. De site blijft draaien totdat het thema niet meer draait onder nieuwe versies van WordPress. Dat kan best nog wel even duren, dus de angst is zeker even ‘uit de lucht’. Maar een site met die onzichtbare onzekerheid zou u toch niet willen hebben?