De firewall van een server

Elke CoreCP-machine heeft één firewallbeheerder. Standaard is dat CoreCP zelf — geen CSF, geen ufw ernaast — en dat is een bewuste keuze: twee programma's die aan dezelfde regels trekken geven een uitkomst die niemand kan voorspellen. Alles wat je van CSF gewend bent zit in dit scherm.

Een server kan in principe aan een ándere firewallbeheerder worden overgedragen; dan trekt CoreCP zich volledig terug en is dit scherm alleen te lezen. Voor cPGuard wordt zo'n overdracht geweigerd, met de reden erbij — zie De firewallbeheerder wijzigen onderaan.

Servers → de server → Firewall.

Wat het scherm laat zien

Van boven naar beneden, in de volgorde waarin je het meestal nodig hebt:

• Blokkades op dit moment — adressen met een aflopende teller, met erbij waar de blokkade vandaan komt: de naam van de bewaker die hem zette, of "met de hand". Dit is het lijstje waar je naar kijkt als iemand belt met "ik kan er niet meer bij".
• Vaste lijsten — adressen en reeksen die altijd worden toegestaan of altijd worden geweigerd.
• Ingebouwde bescherming — drie verdedigingen die in de kernel zelf draaien: SYN-flood, verbindingen per adres, poortscans.
• Geblokkeerde landen — met per land hoeveel adresreeksen er daadwerkelijk geladen zijn.
• Bewakers — de processen die de logboeken van de server meelezen en zelf blokkeren, met per bewaker wat hij leest, of hij draait en wat hij gevangen heeft.
• Open poorten — de poorten die de rollen en de addons van deze server openen, zoals de actieve firewallbeheerder ze kent. Een poort met "from" erachter staat alleen open voor die adressen.
• Gegenereerde regelset — onder Geavanceerd, precies wat de machine geladen heeft.

Iemand tijdelijk blokkeren

Klik op Adres blokkeren, vul het adres in, kies een geldigheid (15 minuten, 1 uur, 24 uur, 7 dagen of permanent) en schrijf op waarom. Die reden is over een half jaar de enige uitleg die er nog is.

Een tijdelijke blokkade verloopt vanzelf. Niet omdat er een taak op de klok staat te wachten, maar omdat de kernel de regel zelf loslaat als de tijd om is — er hoeft niets te draaien, en het werkt ook als de server intussen opnieuw is ingericht.

Op de commandoregel is het hetzelfde:

root@stck1:~# corectl firewall deny 203.0.113.7 --ttl 15m --comment "zes foute IMAP-logins"
[corecp] 203.0.113.7 denied for 15m

root@stck1:~# corectl firewall list --temp
ADDRESS       ACTION KIND       EXPIRES IN   COMMENT
203.0.113.7   deny   temporary  14m56s       zes foute IMAP-logins

De bewakers: blokkeren zonder dat jij kijkt

De server leest zijn eigen logboeken mee. Wie te vaak een verkeerd wachtwoord probeert — op de mail, op FTP, op SSH, op het paneel — wordt vanzelf geblokkeerd. Standaard: vijf mislukte pogingen binnen tien minuten, dan een uur eruit.

Die blokkades komen in dezelfde lijst als de blokkades die je zelf zet. Er is dus niet "een lijst van het systeem" en "een lijst van jou": er is één antwoord op de vraag wie er op dit moment geblokkeerd is, en in de kolom Herkomst staat wie hem daar heeft gezet.

Welke bewakers er draaien hangt af van wat de server doet:

Op de commandoregel:

root@stck1:~# corectl firewall watch
watchers    running
policy      5 failures in 10m, then banned for 1h
banned      1 address right now

JAIL             STATE      FAILED     BANNED     WATCHES
sshd             watching   0          0          ssh, sshd
dovecot          watching   3          1          dovecot
proftpd          watching   0          0          /var/log/proftpd/proftpd.log

Let op: een blokkade geldt voor alles van dat adres, niet alleen voor de dienst waar het misging. Een kantoor dat vijf keer een verkeerd mailwachtwoord probeert, verliest ook de website en SSH. Daarvoor is de vaste toestemmingslijst hieronder: een toegestaan adres wordt nooit geblokkeerd.

Ook webmail telt nu mee

Tot voor kort was er één gat in dit verhaal, en het zat op de plek waar de meeste klanten hun mail lezen. Webmail draait op de server zelf, dus als iemand daar het wachtwoord van een postbus stond te raden, zag de mailserver zijn eigen machine als de bezoeker — en zijn eigen machine wordt nooit geblokkeerd, want dan lag elke website op die server er tegelijk uit. Wie het via een mailprogramma probeerde werd na vijf pogingen buitengesloten; wie hetzelfde via webmail deed, kon eindeloos doorgaan.

Dat is dicht. De webmail geeft nu het echte adres van de bezoeker door aan de mailserver, en de bewaker dovecot blokkeert dát adres — dezelfde drempel, dezelfde lijst, dezelfde knop om het op te heffen. Je hoeft er niets voor in te stellen.

Let op, dit is de keerzijde: een klant die zijn webmailwachtwoord vijf keer verkeerd intikt, blokkeert daarmee zijn eigen adres voor alles van die server — mail, website en SSH. Achter een kantoor- of mobiel netwerk deelt hij dat adres met anderen. Zie hieronder hoe je zo'n blokkade opheft; het is één handeling en het duurt een seconde.

Een blokkade opheffen

Klik op Blokkade opheffen in de rij en bevestig. Dat werkt voor beide soorten: het maakt niet uit of het adres tijdelijk of permanent geblokkeerd was, want dat is niet iets wat je hoeft te weten om iemand weer binnen te laten.

Kwam de blokkade van een bewaker, dan wordt die bewaker er ook bij verteld. Dat klinkt als een detail maar is het niet: zonder dat onthoudt de bewaker de eerdere pogingen, en is de volgende mislukte poging meteen de vijfde. Je zou de blokkade opheffen en hem binnen een minuut terug zien komen.

# een blokkade die een bewaker zette
root@stck1:~# corectl firewall unban 198.51.100.7 --jail dovecot
[corecp] 198.51.100.7 is no longer banned (dovecot)

# een adres dat helemaal niet geblokkeerd was, zegt dat
root@stck1:~# corectl firewall unban 203.0.113.222
corectl: 203.0.113.222 is not banned on this node

# een vaste regel haal je van de lijst af
root@stck1:~# corectl firewall remove 203.0.113.7
[corecp] 203.0.113.7 removed from the firewall's lists

Klanten zichzelf laten deblokkeren

Standaard komt elke opheffing van jou. Dat kan anders: per server kun je de zelfservice aanzetten, en dan mag een klant die zichzelf buitengesloten heeft zijn eigen adres weer vrijgeven zonder dat er een ticket aan te pas komt.

# root@stck1:~# corectl node set firewall.watch.selfservice_unblock on
# of, in node.yaml:
firewall:
    watch:
        selfservice_unblock: "on"

Uit tenzij je hem aanzet — de omgekeerde volgorde van alle andere instellingen hier, en met opzet: dit is een deur uit een verdediging, en zoiets zet je zelf aan of niemand heeft het besloten.

Wat een klant er precies mee kan, is veel minder dan wat jij kunt:

• alleen zijn eigen adres, en alleen als hij de link opent vanaf de verbinding die geblokkeerd is;
• alleen op de servers waar zijn eigen hostingaccounts staan;
• alleen een blokkade die een bewaker zette. Een adres dat jij op de vaste lijst hebt gezet, of met firewall deny --ttl tijdelijk hebt geblokkeerd, wordt geweigerd — dat is een besluit van een mens en blijft van jou;
• drie keer per dag. De vierde keer wordt geweigerd en maakt een beheerder wakker: een adres dat drie keer per dag geblokkeerd raakt heeft een verouderd of een gestolen wachtwoord achter zich.

De klant ziet nergens welke machine hij op staat, welke bewaker de blokkade zette of hoeveel servers er gekeken hebben. Elke opheffing staat in het beveiligingslogboek, met het adres en de inlog erbij.

De uitleg voor de klant zelf staat in Je internetadres is geblokkeerd — zo kom je er weer in.

Wie er is geweest, teruglezen

Elke blokkade en elke opheffing staat in het beveiligingslogboek. Klik op Gebeurtenissen in het logboek bij de bewakers, of ga naar Logboeken en kies de bron security. Daar staan de aanmeldpogingen, de blokkades van de bewakers en de handelingen van het paneel bij elkaar — één kolom in plaats van drie bestanden.

root@stck1:~# corectl logs tail security --lines 20 --grep 198.51.100.7
2026-08-13 03:55:11Z warning fail2ban: [dovecot] Ban 198.51.100.7
2026-08-13 03:55:23Z warning fail2ban: [dovecot] Unban 198.51.100.7
2026-08-13 03:55:23Z notice  unbanned 198.51.100.7 (dovecot)

Een adres altijd toestaan

Adres toestaan zet een adres of een reeks op de vaste lijst. Een toegestaan adres wordt geaccepteerd voordat er ook maar iets naar de blokkades kijkt: een geblokkeerd land, een snelheidslimiet of een poortscan-ban raken het niet. Gebruik het voor je eigen kantoor, je monitoring en je backupserver.

Sommige regels zet CoreCP er zelf op. Die krijgen het label automatisch en kun je niet met de hand weghalen — ze worden bij elke toepassing opnieuw bepaald. Het bekendste geval is de mailgateway: staat er een PMG voor deze server, dan komen zijn adressen automatisch op de toegestaan-lijst, want álle mail van de wereld komt bij die server vandaan en een limiet die dat als één lastige bezoeker behandelt gooit de post van je klanten weg.

De ingebouwde bescherming

De standaardwaarden staan aan en zijn ruim gekozen: een firewall die het verkeer van een drukke klant weggooit is een grotere storing dan de aanval die hij voorkwam. Per server verhogen, verlagen of uitzetten:

root@stck1:~# corectl firewall protect --connlimit 250 --portscan-ban 1h
root@stck1:~# corectl firewall protect --synflood off

De databasepoort van een databaseserver

Draait deze machine databases voor websites op een andere server, dan staat er een extra regel in de lijst met open poorten: 3306/tcp database (1 peer machine). Die poort staat open voor precies die andere machine en voor niemand anders — niet voor het internet.

Je hoeft daar niets voor te doen. Het paneel zet hem open op het moment dat het eerste account met zo'n gesplitste plaatsing wordt aangemaakt, en weer dicht zodra de koppeling tussen die twee machines verdwijnt.

Een land blokkeren

Land blokkeren vraagt om een landcode van twee letters. CoreCP haalt de adresreeksen van dat land op bij ipdeny.com — gratis, dagelijks vernieuwd, en zowel IPv4 als IPv6 — en zet ze in de firewall.

Let op het verschil tussen op de lijst en geblokkeerd: een land staat op de lijst zodra je het toevoegt, maar er wordt pas iets geweigerd als de reeksen binnen zijn. Het scherm zegt per land welke van de twee het is. Een dagelijkse taak haalt de zones opnieuw op; met Landzones nu ophalen doe je dat meteen.

root@stck1:~# corectl firewall country add cn
[corecp] country cn added to the block list
[corecp] country cn: 8221 IPv4 ranges, 2145 IPv6 ranges

root@stck1:~# corectl firewall geoip sync
COUNTRY  IPV4       IPV6       RESULT
cn       8221       2145       synced 2026-08-13T04:11:07Z

Een land blokkeren raakt iedereen die daar vandaan komt, ook de bezoekers die je klant misschien wél wil. Een adres op de toegestaan-lijst blijft er overigens gewoon doorheen komen.

Wat er met de regels gebeurt bij onderhoud

Als CoreCP de firewall opnieuw schrijft — na een rolwijziging, na het installeren van een addon, of gewoon met Toepassen — worden de tijdelijke blokkades bewaard, mét de tijd die ze nog te gaan hebben. Je hoeft dus nooit te kiezen tussen "de server bijwerken" en "de bans van vanmiddag houden".

Wat een herstart wél wist zijn de tijdelijke blokkades: die leven in de kernel en niet op schijf. De vaste lijsten en de geblokkeerde landen blijven staan.

Als er iets misgaat

• Een klant kan er niet meer bij. Zoek het adres in Tijdelijke blokkades. Staat het er, klik Opheffen; zet het daarna op de vaste toegestaan-lijst als het vaker gebeurt.
• De mailgateway staat er niet bij. Controleer of de servernaam van de gateway oplost. Doet hij dat niet, dan slaat CoreCP de regel over en zegt dat in het takenlogboek.
• Een land blokkeert niet. Kijk of er reeksen staan in de kolom Reeksen. Staat er 0, dan is de zone nog niet opgehaald — gebruik Landzones nu ophalen.

De firewallbeheerder wijzigen

Draait er op een server al een andere firewall die je wilt houden, dan hoef je in principe niet te kiezen tussen dat programma en CoreCP: je draagt de firewall over, in één handeling, en er is geen moment waarop de machine zonder firewall zit.

Voor cPGuard kan dat niet, en CoreCP weigert het. Gemeten op 22 augustus 2026: het poortfilter van cPGuard kent één lijst met toegestane poorten en geen manier om te zeggen "deze poort, alleen vanaf dit adres". Elke CoreCP-server heeft minstens één zo'n poort — de agentpoort staat open voor het paneel en voor niemand anders — dus een overdracht zou die beperking weggooien of het paneel buitensluiten. Zie cPGuard: wat wél en wat niet hieronder.

Wat een overdracht doet, in deze volgorde en als één handeling op de server:

1. De nieuwe beheerder krijgt eerst het volledige model: de poorten van de rollen en de addons, de vaste lijsten, de landen en de bescherming.
2. Daarna trekt CoreCP zich terug. De CoreCP-tabel gaat uit de kernel, het bestand dat die tabel bij het opstarten laadt wordt vervangen door een bestand dat níéts laadt, en de dagelijkse taak die landreeksen ophaalt stopt.
3. De bewaker verhuist mee: fail2ban stopt en de bewaker van de nieuwe beheerder begint. Er draait er altijd precies één.

Stap 2 is de stap die anders later pijn doet. De regelset van CoreCP begint met het legen van de kerneltabellen; blijft dat bestand in het opstartpad staan, dan is de firewall van de nieuwe beheerder na de eerstvolgende herstart weg — maanden later, zonder dat iets in een logboek dat verband legt.

Zo doe je het:

1. Ga naar Servers → de server → Firewall.
2. Klik rechtsboven op Meer acties → Firewallbeheerder wijzigen.
3. Kies de beheerder en lees het gele blok: daar staat wat er gaat gebeuren.

Kan de gekozen beheerder het poortmodel van deze server niet dragen, dan krijg je een weigering in plaats van een halve overdracht, met de poorten erbij die het probleem zijn:

root@stck1:~# corectl firewall provider set cpguard
corectl: cpguard cannot carry this node's port model: 22/tcp from
185.117.226.120, … and 16 more are open only to named sources, and this backend
has one flat list of ports for every source — enforcing it would either put
those ports on the internet or stop the panel reaching this node

Er verandert dan niets: de server blijft op nftables, de regels blijven in de kernel staan en fail2ban blijft meelezen.

cPGuard: wat wél en wat niet

cPGuard blijft gewoon bruikbaar op een CoreCP-server — als addon, naast de firewall van CoreCP. Zijn WAF, zijn malwarescanner en zijn reputatielijsten doen hun werk en raken niets van het pakketfilter aan. Wat cPGuard níét wordt, is de beheerder van de poorten:

• zijn poortfilter kent alleen een algemene poortlijst; een poort die maar voor een paar adressen open hoort te staan bestaat daar niet;
• een adres op zijn witte lijst mag voorbij zijn automatische blokkades (DoS, reputatie, brute force) — maar dat opent geen poort die het poortfilter dichthoudt. Dat is precies waar de vorige versie van CoreCP op rekende, en het klopte niet;
• CoreCP zet dat poortfilter daarom nooit aan, en zet hem weer uit als iemand hem met de hand aanzet. Op 22 augustus maakte één zo'n schakeling een testserver onbereikbaar vanaf élk adres, over IPv4 én IPv6.

CoreCP schrijft nog steeds regels op de witte lijst van cPGuard voor het paneel en de jumphost, want die vrijstelling van de automatische blokkades is echt nuttig. In het scherm staan ze als vrijstelling, niet als open poort.

Wat een beheerder níét kan

Onder Ingebouwde bescherming staat op een overgedragen server een lijstje met wat de actieve beheerder niet kan. Voor cPGuard zijn dat er vier:

• geen poort die alleen voor bepaalde adressen open staat — de reden dat de overdracht wordt geweigerd;
• geen begrenzing van gelijktijdige verbindingen per adres (cPGuard stelt die per doelpoort in, en dat is een ander beleid);
• geen poortscandetectie (cPGuard blokkeert op reputatie van het adres);
• een looptijd telt in hele minuten, dus een blokkade van dertig seconden wordt een blokkade van een minuut.

Dat lijstje staat er zodat een scherm nooit drie verdedigingen belooft waarvan er één bestaat.

Terugdraaien

Kies nftables en CoreCP schrijft de regelset weer zelf. Die regelset is byte voor byte dezelfde als vóór de overdracht: het model stond al die tijd in node.yaml en verandert niet als de machinerie verandert.

root@stck1:~# corectl firewall provider
root@stck1:~# corectl firewall provider set nftables

De SSH-poort volgt de server

De regel die SSH doorlaat is geen vast poortnummer meer. Hij komt uit dezelfde instelling als de SSH-server zelf, dus verzet je de poort dan verhuist het gat in de firewall mee — en tijdens een poortwissel staan beide poorten open, precies zolang als het bevestigingsvenster duurt. Zo kan het niet gebeuren dat de server op een nieuwe poort luistert waar de firewall niets doorlaat.

Ook de bewaker (fail2ban) leest hetzelfde nummer, dus mislukte aanmeldingen op de nieuwe poort worden net zo goed geteld. Zie Serverinstellingen en diensten.

Wie er bij SSH mag (ronde 3)

De regel voor poort 22 kent sinds ronde 3 ook een lijst met bronnen. Staat die lijst leeg, dan is poort 22 open voor het hele internet — precies zoals het altijd was. Zet je er één adres op, dan mag alleen dat adres nog bij de SSH-server; al het andere verkeer wordt weggegooid vóórdat de SSH-server het ziet.

Waarom dat nodig was, in één getal: op 19 augustus 2026 telde de paneelserver 709 mislukte aanmeldingen in één uur. Dat is niet alleen ruis — de wachtrij van de SSH-server liep vol en gooide onze eigen automatisering eruit.

De lijst hoort bij de server, niet bij het hele platform: iedere machine heeft zijn eigen bezoekers. Vanaf de terminal van die server:

corectl sshd allow list
corectl sshd allow add --address 203.0.113.7 --comment "kantoor"
corectl sshd allow remove --address 203.0.113.7

Je kunt jezelf er niet uitzetten. Een wijziging die het adres waar je nu vandaan werkt buiten de lijst zou laten, wordt geweigerd met dat adres erbij. Wil je het tóch (omdat je een andere weg naar binnen hebt), dan zeg je dat met --force.

En er is altijd een weg terug. Zet je --window 10m achter een wijziging die toegang wegneemt, dan zet de server de vorige lijst er vanzelf weer op als je binnen dat kwartier niets bevestigt. Een verbinding die al openstaat wordt nooit verbroken door zo'n wijziging.

Het scherm hiervoor komt in ronde 4; vandaag is dit een terminalhandeling.

De balk bovenaan

Dit scherm is geen eigen tabblad van de server, maar de serverbalk staat er wel bovenaan — met niets geselecteerd. Zo ga je na het deblokkeren van een adres direct door naar de logboeken of naar Beheer, in plaats van eerst terug naar het overzicht te moeten. Het pijltje terug naar de server blijft gewoon staan.

Zie Een server beheren voor de zeven onderdelen en wat er achter elk zit.