Van Der Linde Media

Ik heb klanten die vaak een oudere website nog draaien, en waarbij updates naar zoal een laatste versie vaak al niet mogelijk is zonder chrash of niet werkende website meer. Het is te incompatible en alles gaan debuggen waarom het niet werkt is tijdrovend. De klant kiest uit vaak financieel belang ervoor de website maar te laten zoals het is, en deze niet te upgraden. Het nadeel? Deze loopt risico tegen aanvallen en kan een serieus probleem veroorzaken inzage dataverlies of erger.

Nja, wat doe je dan? Ik heb natuurlijk geen zin in gehackte websites op mijn netwerk en vindt het belangrijk dat de security en veiligheid op orde is. Echter ontkome je er niet (meer) aan wanneer je een verouderd pakket draait, lekken tegenwoordig overal te vinden zijn als je de versie nummer van een software pakket maar weet. Ik ben vroeger zo ook begonnen, het zoeken naar beveiligingsgaten in websites. Toen was het anders, waar tegenwoordig heel erg veel geautomatiseerd afgestruind wordt.

Omdat ik Custombuild gebruik van Martynas Bendorius, is het relatief eenvoudig de software configuratie op maat in elkaar te klikken. Zo kwam er dus ineens CWAF als potentieele nieuwe update. Veel kon ik er niet over vinden dan behalve dat het een software gebaseerde firewall is. Het schijnt bepaalde exploits en posts naar de server toe, te blokkeren. Ik heb het een tijdje gedraaid, soms moet je het e.a whitelisten bij bijv. een website dat een betaalpagina aanroept, maar in de regel werkt het goed.

Een klant heb ik recent geholpen met de verhuizing van een andere webmaster naar mij toe. Hij was (ontevreden) over de manier van zaken en dat klanten als niet gast niet konden bestellen. Ik zag al direct waar het aan lag. De webmaster bleef een website voeren dat lek was maar koos ervoor om met mappenrechten, bepaalde hack exploits tegen te gaan. Ik vertrouwde het niet helemaal en durfde niet te stellen of het al gehacked was. Dat het onveilig was was zeker. De laatste versie stamde nog uit 2017.

Op het moment dat ik de website overzette en deze zover dat nog lukte, update naar de laatst mogelijke versie, was ik benieuwd naar de werking van CWAF in dit geval. Een paar dagen later, stond de error log vol met CWAF meldingen waarvan bepaalde exploits, geblocked waren. In het bovenstaande gaat het om een SQL exploit waar gegevens kunnen worden ingevoerd of gedownload worden. Dit werkt supergoed momenteel en het gaf me meer inzage in hoe bots tewerk gaan.

Apart van dat ik dit soort block nu geautomatiseerd heb en kan configureren om geblacklist te worden in de firewall, zou ik iedereen met een eigen server en in combinatie met Directadmin, Cwaf te installeren en in te zetten. Let wel dat bepaalde rules experimenteel zijn, en hier en daar een error zullen gaan gooien. Websites kunnen ineens stoppen met werken als een bepaalde call geblocked wordt. Geen zorg. Hier leg ik je uit hoe je een false positive kunt whitelisten en toelaten voor werking.

Bij iedere block gooit CWAF in de error log van het domein, een unique ID eruit. Dit is een 6 cijferig nummer en ziet er zo uit: "211650" > echter dit is wel een exploit en deze moet je absoluut niet gaan whitelisten. Om te voorkomen dat CWAF positive ID's per ongeluk gaat blocken, kan je deze whitelisten via "Custom HTTPD Configurations" > selecteer het domein, bovenin bij Httpd.conf Customization for domein.xyz, vul je de volgende entry / waarde in, je moet wel het ID weten van de false positive.

< IfModule mod_security2.c > SecRuleRemoveById 211650 < /IfModule >