Hoe je website te beveiligen tegen aanvallen!

[nubro01]

Begin Juli 2026 werden diverse van mijn Joomla websites aangevallen vanwege de JCE editor kwetsbaarheid CVE-2026-48907. Dit resulteerde in aan aantal dagen elke dag restoren van alle websites. Gelukkig werden de databases niet aangetast en hoefde ik alleen maar de folder html terug te zetten en kon ik de database restores skippen. Natuurlijk had ik geen parate kennis over aanvallen, met 50 jaar ICT ervaring nog nooit te maken gehad met aanvallen waar ik zelf last van had. Nu op 74 jarige leeftijd, moest ik dus noodgedwongen kennis vergaren, hoe te handelen. De kwetsbaarheid was natuurlijk snel geregeld met een aantal updates, maar tot mijn verbazing bleef ik maar last houden. De JCE profielen die aangemaakt waren had ik al verwijderd en ook de meeste folders met rare php bestanden in tmp en image folder verwijderd.
Al met al ben ik hier nu 2 weken mee bezg en heden morgen gaf mijn NGINX error.log eindelijk geen fouten meer. De aanvallers zijn met vakantie of ik heb e.a. nu eindelijk zo dicht getimmerd dat het ze niet meer lukt.
Ik vond geen topic over dit onderwerp en geen van mijn kennissen hebben mijn interesse en uitdaging.
Ik hoop via dit topic mijn ervaring te kunnen delen en ook wat te leren van anderen.

[nubro01]

Ter eerste, mijn 8 websites draaien op een Raspberry Pi 5 met 8 gig geheugen en ik gebruik NGINX als webserver. Ze zijn totaal onbelangrijk, want ze zijn bedoelt als voorbeeld voor Stichtingen die van WordPress over willen naar Joomla en verder Nextcloud test sites en zaken voor de wijk Gaasperdam in Amsterdam.
Zoals mijn computer Club https://hccinloop.nl .

Wat heb ik als eerste gedaan?
Nou als eerste alle linux permissies vernieuwd met de commando's
sudo find /var/www -type d -exec chmod 755 {} \;
sudo find /var/www -type f -exec chmod 644 {} \;
Vervolgens alle tmp en administrator/tmp leeg gemaakt en alle cache geflushed.

Vervolgens op zoek gegaan naar een tool om de NGINX access.log en error.log, naast elkaar te kunnen leggen, om zo te proberen te achterhalen wat men zoal probeerde en wanneer het dan fout ging.
Onder Linux kon ik niet veel, dus toch maar Samba geïnstalleerd en van \var\log\nginx een share gemaakt, zodat ik onder Windows 11 met Notepad++ beide bestanden handmatig kon bestuderen.
Wat mij als eerste opviel was dat de meeste aanvallen via het oude http/1.1 verliepen en nadat ik vervolgens via het iptables commando, "sudo iptables -A INPUT -p tcp --dport 80 -j DROP" had uitgevoerd, zag ik via elk uur uitvoeren van "sudo iptables -nvL INPUT --line-numbers" wat het resultaat was. Moet nog wel uitleggen dat elk ip adres wat een fout aanmaakte, waar meerdere regels achter elkaar verschenen, ik ze via "sudo iptables -A INPUT -s ip-adres -j DROP" had toegevoegd. Zo zie ik het aantal drops via poort 80 nu met 4000 per dag oplopen!
Vervolgens via NGINX.conf regels toegevoegd en mijn sites NGINX definities zo geregeld dat al het https verkeer via http1.1 geweigerd wordt, met als, voorlopig resultaat, dat mijn error.log vanmorgen geen noemenswaardige fouten bevatte.
Tot zo ver mijn verslag en ik wacht het vervolg af.

[Bartske]

Bij mij doet de link hccinloop het niet. Misschien heb je de site iets te veel dichtgetimmerd?

[MarkyB]

Ik denk niet dat het handig is om je URL te noemen in combinatie met je exacte webserver instellingen.

[nubro01]

Mijn laatste aanpassing heeft meer gevolgen dan ik dacht. Vandaar dat ik geen error's meer heb ;-)
Rara is dat google via 66.49.x.x nog steeds http/1.1 verkeer laat zien in access.log.
Opniew alles nakijken. Bedankt.

[Room42]

Goed bezig. Ja, de beste bescherming is toch het up-to-date houden van de extension. En hoe minder je er hebt, hoe kleiner de 'attack surface'. Je kunt nog de installatie 'hardenen' door de directories en bestanden niet schrijfbaar te maken voor de www-user. Dan kan een lekke extensie geen bestanden aanpassen, buiten de user content, zoals afbeeldingen. Dat maakt wel het installeren en updaten van add-ons moeilijker omdat dat dan via (S)FTP(S) moet, via een andere gebruiker met schrijfrechten.

Maar check je code nog even goed, of er geen eval(...)'s meer in staan. Dat is een standaard truck om code voor het oog onleesbaar te maken.

[Room42]

nubro01 schreef op woensdag 15 juli 2026 @ 11:54:
Mijn laatste aanpassing heeft meer gevolgen dan ik dacht. Vandaar dat ik geen error's meer heb ;-)
Rara is dat google via 66.49.x.x nog steeds http/1.1 verkeer laat zien in access.log.
Opniew alles nakijken. Bedankt.

Ziet eruit als een klassieke reverse proxy error, waarbij je in Joomla hebt ingesteld dat ie altijd naar https moet redirecten terwijl nginx een http backend gebruikt en Joomla dus altijd http binnen ziet komen, en dus weer redirect naar https.

[Room42]

nubro01 schreef op woensdag 15 juli 2026 @ 11:21:
Ter eerste, mijn 8 websites draaien op een Raspberry Pi 5 met 8 gig geheugen en ik gebruik NGINX als webserver. Ze zijn totaal onbelangrijk, want ze zijn bedoelt als voorbeeld voor Stichtingen die van WordPress over willen naar Joomla en verder Nextcloud test sites en zaken voor de wijk Gaasperdam in Amsterdam.
Zoals mijn computer Club https://hccinloop.nl .

Dit soort details zijn echt niet relevant, zéker niet als je security issues hebt. Dat zou een doorgewinterde ICT'er toch moeten weten.

Wat heb ik als eerste gedaan?
Nou als eerste alle linux permissies vernieuwd met de commando's
sudo find /var/www -type d -exec chmod 755 {} \;
sudo find /var/www -type f -exec chmod 644 {} \;

Dit geeft de eigenaar van de bestanden schrijfrechten op alles. De vraag is alleen wie de eigenaar is. Die moet je ook nog even resetten met `chown`. En zoals ik aangaf, is het misschien slim om dat niet de user van de webserver te maken. Maar dat vergt wel wat verdieping. Je moet dan weten wat je doet en hoe je er omheen werkt. Allemaal wat meer beheerslast.

Vervolgens alle tmp en administrator/tmp leeg gemaakt en alle cache geflushed.

administrator? Het is geen Windows.

Onder Linux kon ik niet veel, dus toch maar Samba geïnstalleerd en van \var\log\nginx een share gemaakt, zodat ik onder Windows 11 met Notepad++ beide bestanden handmatig kon bestuderen.

Oef, hier ben ik echt geef fan van. Gebruik dan gewoon SSH, desnoods met root (gebruik een private key i.p.v. een wachtwoord). Met tools als FileZilla kun je dan heel simpel over je filesystem browsen en direct openen in Notepad.

Wat mij als eerste opviel was dat de meeste aanvallen via het oude http/1.1 verliepen

HTTP/1.1 is prima als je maar over HTTPS (TLS) gaat.

en nadat ik vervolgens via het iptables commando, "sudo iptables -A INPUT -p tcp --dport 80 -j DROP" had uitgevoerd, zag ik via elk uur uitvoeren van "sudo iptables -nvL INPUT --line-numbers" wat het resultaat was. Moet nog wel uitleggen dat elk ip adres wat een fout aanmaakte, waar meerdere regels achter elkaar verschenen, ik ze via "sudo iptables -A INPUT -s ip-adres -j DROP" had toegevoegd. Zo zie ik het aantal drops via poort 80 nu met 4000 per dag oplopen!

Poort 80 blokkeren slaat echt nergens op. Dat maakt je site en server niet veiliger. Op poort 80 moet je gewoon een redirect naar 443 zetten.

Vervolgens via NGINX.conf regels toegevoegd en mijn sites NGINX definities zo geregeld dat al het https verkeer via http1.1 geweigerd wordt, met als, voorlopig resultaat, dat mijn error.log vanmorgen geen noemenswaardige fouten bevatte.

http/1.1 over TLS is niet per se minder secure.

Tot zo ver mijn verslag en ik wacht het vervolg af.

Sowieso denk ik dat je het hier compleet op de verkeerde plek zoekt. Je zit nu de transport te beveiligen terwijl de applicatie het issue is. Je moet dus de hosting beveiligen. Zorgen dat aanvallers de applicatie niet kunnen misbruiken om op de host aanpassingen te doen.

[nubro01]

Sudo NGINX -t gaf een aantal fouten en het bleek, dat er meerdere server{} blockken waren die blijkbaar door certbot gemaakt waren. Ik heb ze allemaal gisteren avond naar een server{} veranderd en NIET getest!
Dat was de reden dat ze allemaal niet meer bereikbaar waren. Al die certbot regels verwijderd en alles doet het nu weer.
Bedankt voor alle commentaar, daar kan ik verder mee.

[MasterL]

@nubro01 Ik begrijp dat de intentie van dit topic goed is maar beveiliging van een website hangt van zoveel dingen af dat ervaringen delen betreft 1 specifieke configuratie niet echt heel zinvol is.
Ik gooi hem voor nu dicht i.v.m. het feit dat er niet een specifieke vraag is. Mocht je ergens tegenaanlopen kun je een nieuw topic opnemen met de specifieke vraag duidelijk omschreven.