CMS Made Simple beveiligen — 10 stappen voor jouw site

CMS Made Simple bezet een unieke plek in het CMS-landschap. Klein genoeg om aan de aandacht van geautomatiseerde botnets te ontkomen, groot genoeg om bewust doelwit te zijn van gerichte aanvallers — vooral op verouderde installaties met inactieve modules. De Nederlandse community is klein maar gepassioneerd; veel CMSMS-sites zijn al jaren in productie, vaak met installaties die nooit grondig zijn gehardened.

Dit artikel veronderstelt CMSMS 2.2.x (de huidige stabiele tak). CMSMS 1.x ging in 2018 End of Life — als je daar nog op zit, is migratie naar 2.2 je #1 prioriteit, niet hardening.

Hoe CMS Made Simple verschilt qua security

Een paar fundamenten voor we de stappen ingaan:

• Modules: CMSMS heeft modules (functionaliteit) en Smarty templates (presentatie). Modules komen vaak van Forge, het officiële CMSMS-modulearchief op dev.cmsmadesimple.org. Niet elke Forge-module wordt actief onderhouden — dat moet je per module checken
• Smarty als templating: krachtig maar potentieel gevaarlijk. Een Smarty-template kan PHP uitvoeren via {php}-tags — een aanvaller die je templates kan wijzigen, kan code uitvoeren
• Permissions-systeem: meer granulair dan WordPress (vergelijkbaar met Joomla's ACL). Je kunt per content-type, per module en per actie permissies toekennen aan groepen
• config.php: in webroot, vergelijkbaar met WordPress' wp-config.php. Bevat database credentials én site-specifieke security-instellingen
• Standaard URL's: admin op /admin/, uploads in /uploads/ — beide aanvalsdoelwitten als ze niet beschermd zijn

1. Updates — core en modules apart

CMSMS heeft geen massaal Security Strike Team zoals Joomla, maar er zijn wel formele security-advisories. Drie acties:

• Abonneer op de CMSMS-announcements: via het officiële forum op forum.cmsmadesimple.org of de mailinglist
• Volg de Forge update-feed voor je geïnstalleerde modules — niet elke module heeft een actieve maintainer
• Update CMSMS core via Admin → Site Admin → System Information voor de huidige versie. Updaten zelf gaat via de CMSMS Update Wizard of handmatig via FTP

Voor moduleupdates: ga in admin naar Extensions → Module Manager → Available Updates. Test eerst op staging — sommige modules breken bij PHP-versie-incompatibiliteit (zie ook het staging artikel; principes gelden ook voor CMSMS).

2. Verwijder ongebruikte modules — niet alleen deactiveren

CMSMS' module-architectuur betekent: gedeactiveerde code zit nog steeds op je server en kan via direct request aanvalsroutes bieden. Echte cleanup:

1. Admin → Extensions → Module Manager
2. Klik op de module → Uninstall (verwijdert configuratie)
3. Vervolgens via FTP/SFTP de module-map daadwerkelijk verwijderen uit /modules/[ModuleName]/

Specifiek opletten:

• Test- en demo-modules uit ontwikkelfase
• Oude versies van modules die je vervangen hebt (handmatige installs uit Forge)
• Modules waarvan de Forge-pagina al jaren geen activiteit toont — ook als je 'm gebruikt, audit dan grondig of zoek alternatief

3. config.php hardening — vier essentiële instellingen

Het belangrijkste configuratie-bestand. Vier instellingen die moeten goed staan op productie:

3.1 — Database-prefix wijzigen

De default cms_ prefix is bekend bij elke geautomatiseerde scanner. SQL-injectie-aanvallen gebruiken vaak hardcoded tabel-namen. In config.php:

$config['db_prefix'] = 'cmsx7q_';

Voor bestaande sites: dit kan met de "Renamer" tool of handmatig via SQL RENAME TABLE + database-update. Maak altijd eerst een complete backup.

3.2 — Admin login verbergen

CMSMS heeft een ingebouwde optie om de admin URL te beschermen via een geheim "navsecret"-token:

$config['admin_dir'] = 'beheer-x7q9';

Standaard is de admin URL /admin/. Wijzig je deze naar /beheer-x7q9/, dan vinden geautomatiseerde scanners 'm niet meer. Belangrijk: bookmarken en intern delen — deze URL is je tweede wachtwoord-laag.

3.3 — Error reporting uit op productie

Voorkom dat fouten systeempaden of database-namen lekken naar bezoekers:

$config['debug'] = false;

Plus in php.ini of .htaccess:

php_flag display_errors Off
php_flag log_errors On
php_value error_log /pad/buiten/webroot/cmsms-errors.log

3.4 — File permissions van config.php

Het bestand mag niet wereld-leesbaar zijn op shared hosting:

chmod 444 config.php

Read-only voor iedereen. CMSMS heeft alleen schrijfrechten nodig als je via UI configuratie wijzigt — als je dat doet, tijdelijk 644, daarna terug naar 444.

4. Bescherm /uploads/, /tmp/ en /modules/ tegen PHP-uitvoering

CMSMS' upload-map staat in /uploads/. Bezoekers (en aanvallers) kunnen via formulieren of geüploade bestanden potentieel PHP-bestanden laten landen daar. Plaats een .htaccess in /uploads/:

<FilesMatch "\.(php|phtml|pl|py|jsp|asp|sh|cgi|inc)$">
    Require all denied
</FilesMatch>
Options -ExecCGI

Doe hetzelfde voor /tmp/ (waar CMSMS gecompileerde Smarty-templates schrijft) en /modules/'s assets-mappen. Zie ook het .htaccess artikel voor algemene context.

5. Smarty-templates veilig houden

Hier zit een onderschat risico. CMSMS gebruikt Smarty als templating engine — krachtig, maar Smarty kan via {php}-tags PHP uitvoeren. Een aanvaller die via een gehackt admin-account een template kan wijzigen, kan code uitvoeren op je server.

In config.php, schakel PHP-tags expliciet uit:

$config['permissive_smarty'] = false;
$config['php_in_smarty'] = false;

Plus: beperk wie templates kan bewerken via Admin → Users & Groups → Group Permissions. Alleen Site Admin moet "Modify Templates" hebben.

Voor extra zekerheid: set in Smarty configuration $smarty->setSecure(true) waar mogelijk — beperkt welke functies templates kunnen aanroepen.

6. Granulaire user-rechten — niet iedereen Site Admin

CMSMS heeft een fijnmazig permission-systeem dat veel mensen onderbenut. Aanbevolen rol-structuur voor een typische zakelijke site:

• Editor: Modify Pages voor specifieke content. Geen template-toegang, geen module-installatie
• Reviewer: idem + Approve Content (voor publicatie-flow)
• Site Manager: Modify Pages, Site Preferences, beheer van menus en navigatie. Maar GEEN Module Install of Group Permissions wijzigen
• Site Admin: één account, voor noodgevallen, met sterk wachtwoord en 2FA

Specifiek belangrijk: de permissies Modify Templates, Modify Stylesheets, Modify User Tags mogen uitsluitend bij Site Admin liggen — die kunnen alledrie tot code-execution leiden via Smarty (zie stap 5).

7. Tweefactor-authenticatie via Forge module

CMSMS heeft 2FA niet in core, maar er zijn Forge modules:

• CMSMS Yubikey Auth — voor hardware-keys
• TwoFactorAuth module — TOTP via Google Authenticator/Authy

Configureer 2FA als verplicht voor alle Site Admin accounts. Editors mogen optioneel — admins niet.

Maak na configuratie ook backup recovery codes en bewaar ze offline. Zonder die kun je jezelf permanent uitsluiten als je telefoon kwijt raakt.

8. Beperk login-pogingen via .htaccess

CMSMS heeft geen ingebouwde brute-force-bescherming op login zoals Joomla en moderne WordPress. Twee aanpakken:

Optie A: HTTP basic auth boven CMSMS-login

Plaats een tweede authenticatie-laag voor de CMSMS admin via .htaccess in je admin-map:

AuthType Basic
AuthName "Beveiligde sectie"
AuthUserFile /home/user/.htpasswd
Require valid-user

Resultaat: aanvallers krijgen eerst een browser-popup vóór ze überhaupt bij CMSMS' login komen. 99% van de bots geeft op.

Optie B: fail2ban op server-niveau

Vereist VPS/dedicated met SSH-toegang. Configureer fail2ban om CMSMS-login-failures te detecteren in access logs en het bron-IP tijdelijk te blokkeren.

9. Audit Forge-modules op security-status

Niet elke module op Forge is even goed onderhouden. Bij elke geïnstalleerde module check:

• Wanneer was de laatste release? Modules zonder release in 2+ jaar zijn risico
• Is de auteur nog actief op het forum?
• Staan er onopgeloste security-issues op de Forge-pagina van de module?
• Heeft de module recent commits in z'n source repository?

Speciaal opletten:

• FormBuilder: historisch een aanvalsvector — zorg voor laatste versie en CSRF-instellingen aan
• News module: ingebouwd, maar oudere versies hadden SQL-issues — zorg dat core up-to-date is
• Custom modules van eigen ontwikkelaar: laat ze auditten als je de code zelf niet kunt lezen

Modules van obscure GitHub-repositories of "premium" sites: vermijd helemaal. Alleen Forge of zelf-geschreven code.

10. Web Application Firewall (WAF)

Voor extra bescherming, drie opties:

• Cloudflare WAF: cloud-niveau, filtert vóór aanvallen je server bereiken. ~€10-20/maand. Heeft generieke OWASP-rulesets die ook tegen CMSMS-aanvallen werken
• Sucuri Firewall: alternatief, vergelijkbare prijs en functionaliteit
• ModSecurity met OWASP CRS: server-niveau, vaak standaard op shared hosting met DirectAdmin/Plesk. Vraag je hoster welke ruleset actief is

Voor CMSMS-sites die in productie draaien is een WAF op cloud-niveau geen luxe — juist omdat de community kleiner is en patches soms langer duren, biedt een WAF een belangrijke veiligheidsmarge.

Bonus: backups, monitoring en hosting-keuze

De extra's die het verschil maken bij een incident:

• Backups: dagelijks automatisch, naar externe locatie (geen webroot!). Tools: server-niveau backups via je hosting, of de BackupX module van Forge. Test minimaal jaarlijks of de restore werkt
• File integrity monitoring: detecteer ongeautoriseerde wijzigingen aan code. Tools: aide, tripwire of een externe service zoals Wordfence-equivalent (geen specifieke CMSMS oplossing)
• Activity log: CMSMS heeft een ingebouwde "Admin Log" — Admin → System Maintenance → Site Admin Log. Bewaar minimaal 90 dagen voor incident-analyse
• Hosting-keuze: shared hosting met goede ModSecurity-rules, geautomatiseerde malware-scans en 2FA op het control panel scheelt enorm. Niet alle hosters hebben specifieke CMSMS-rules — de algemene OWASP-set is meestal genoeg

Wat NIET te doen op CMSMS

Een paar dingen die in WordPress-tutorials voorkomen, maar in CMSMS overbodig of zelfs schadelijk zijn:

• "Hide Login Page" plugins zoeken: niet nodig — CMSMS heeft de admin-dir-renaming ingebouwd via config.php
• Database-prefix in oudere CMSMS 1.x sites wijzigen: kan installs breken, en CMSMS 1.x zou je sowieso niet meer moeten draaien
• Smarty {php} tags gebruiken voor "snel iets dynamisch": nee, schrijf een eigen User Tag of een module — dat blijft beheersbaar én veilig. {php} in templates is een security-rampje wachten te gebeuren
• Outdated CMSMS 1.x houden vanwege "het werkt nog": 1.x is sinds 2018 EOL. Bekende kwetsbaarheden worden niet meer gepatcht

CMSMS 1.x nog draaiend? Migreer.

CMS Made Simple 1.x ging in 2018 End of Life. Geen security updates, geen support. Bekende kwetsbaarheden in 1.x worden niet meer gepatcht. Een 1.x-site online houden is op termijn niet houdbaar.

De migratie naar 2.2 is geen update — het is fundamenteel een nieuwe site. Templates moeten gemoderniseerd worden, modules zijn deels niet compatible. Plan minimaal 1-3 dagen werk voor een gemiddelde site.

Wanneer schakel je hulp in?

• CMSMS 1.x site die nog draait — moet ASAP gemigreerd worden naar 2.2
• Site is gehackt en je weet niet via welke module het binnenkwam
• Custom modules of User Tags waarvan de oorspronkelijke ontwikkelaar niet meer beschikbaar is — security audit van eigen code
• Smarty-templates met legacy {php} tags — refactoring naar veilige alternatieven
• Migratie van CMSMS naar een ander platform (WordPress/Drupal) met behoud van content + URLs
• Performance + security balans op grotere CMSMS-sites — caching strategieën hebben security-implicaties

CMSMS heeft een loyaal, stabiel ecosysteem maar met minder massa-aandacht dan WordPress of Joomla. Dat betekent: minder geautomatiseerde aanvallen, maar ook minder ogen die naar je problemen kijken als je hulp nodig hebt. Eén ochtend besteden aan deze tien stappen zet je site fundamenteel sterker dan het overgrote deel van de CMSMS-installaties op het Nederlandse internet.