Je account beveiligen

Je hostingaccount geeft toegang tot je websites, je e-mail en je gegevens. Deze pagina beschrijft wat je kunt instellen om dat af te schermen, in de volgorde waarin het de moeite waard is: een passkey, daarna herstelcodes, daarna de rest.

Alles hieronder staat in het paneel onder Mijn account — je vindt het onder je eigen naam, linksonder in het menu. (Tot 0.17.14 heette die plek "Instellingen"; dat woord is nu voor de instellingen van het platform, zie Instellingen van het platform.)

Een passkey: het belangrijkste dat je kunt doen

Een passkey is een sleutel die in je telefoon, laptop of hardwaretoken zit. Je gebruikt hem met je vingerafdruk, je gezicht of je pincode. Er is niets om te onthouden en niets om te typen — en dat is precies waarom hij veilig is: een nepwebsite kan je passkey niet ontfutselen, want de sleutel werkt alleen op het adres waarvoor hij is gemaakt.

1. Ga naar Mijn account → Passkeys.
2. Klik op Passkey toevoegen en volg wat je browser vraagt.
3. Geef hem een naam die je herkent ("iPhone", "werklaptop").

Drie dingen om te weten:

• Een passkey hoort bij één adres. Meld je aan op panel1.corecp.dev én op het adres van je reseller, dan registreer je op allebei een passkey. Dat is geen omissie: het is precies wat een passkey onvervalsbaar maakt.
• Zodra je er hier één hebt, is hij hier verplicht. Een code uit je authenticator-app wordt daarna geweigerd op dít adres. Op een adres waar je nog geen passkey hebt verandert er niets.
• Registreer er twee als je kunt — je telefoon én je laptop. Eén apparaat kwijt is dan geen probleem meer.

Herstelcodes: het vangnet

Bij je eerste passkey krijg je tien herstelcodes. Je ziet ze één keer. Bewaar ze buiten je browser: geprint in een la, of in je wachtwoordmanager.

Elke code werkt één keer en vervangt bij het aanmelden je passkey. Raakt het vel kwijt of heb je het gevoel dat iemand meekijkt? Vraag onder Aanmelden & beveiliging een nieuwe set aan — daarmee is het oude vel meteen waardeloos.

Ben je én je apparaten én je codes kwijt, dan is je hostingpartij de enige weg terug. Zie "Voor beheerders" onderaan; dat is een handeling op de server, geen knop op een website.

Tweestapsverificatie met een app

Heb je (nog) geen passkey, dan beveilig je je account met een authenticator-app: je scant een QR-code en vult daarna bij het aanmelden een code van zes cijfers in. Dat is duidelijk beter dan alleen een wachtwoord, en duidelijk zwakker dan een passkey — een code kun je namelijk aan de verkeerde website geven.

Zolang je geen passkey hebt, staat er in het paneel een melding die je vraagt er één te registreren. Die verdwijnt vanzelf zodra je dat doet.

Uitzetten

Bij Mijn account → Tweestapsverificatie staat sinds 0.17.14 ook een knop om hem weer uit te zetten. Er zitten twee drempels voor:

1. Een bevestiging. Het paneel vertelt wat er gebeurt — je meldt je daarna aan met alleen je wachtwoord, en je herstelcodes vervallen — en de knop in dat venster heet Uitzetten, niet Ja.
2. Een verse code. Ook al ben je al aangemeld: je tweede factor weghalen is de enige handeling aan je eigen account die hem zwakker maakt, dus het paneel vraagt je nog één keer te bewijzen dat jij het bent. Je wachtwoord wijzigen krijgt die extra vraag met opzet niet — dat maakt je account sterker, niet zwakker.

Ben je beheerder of serverbeheerder, dan kan het niet. Voor die rollen is tweestapsverificatie verplicht; de knop staat er dan niet en het scherm zegt waarom. Ook rechtstreeks via de API lukt het niet: de server weigert het, ongeacht wat het scherm laat zien.

Je wachtwoord

Eén wachtwoord hoort bij je e-mailadres, niet bij een account of een hostingpartij. Werk je bij twee partijen die allebei CoreCP gebruiken, dan is dat hetzelfde wachtwoord — maar wat je op elk adres ziet, blijft strikt gescheiden.

Bij het instellen van een nieuw wachtwoord let het paneel op twee dingen, en op niets anders:

• De lengte. Minstens 15 tekens voor een gewoon account, 20 voor beheerders. Geen eisen aan hoofdletters, cijfers of leestekens, en geen verplichte vernieuwing om de zoveel maanden: dat duwt mensen naar Zomer2026! en is precies wat de norm (NIST SP 800-63B rev.4) afraadt. Lengte is wat telt.
• Of het al gelekt is. Het paneel controleert of je nieuwe wachtwoord in bekende datalekken voorkomt. Zo ja, dan wordt het geweigerd — dat is geen oordeel over hoe ingewikkeld het is, maar over of het al ergens op straat ligt. Van je wachtwoord verlaat daarbij niets je hostingomgeving: er gaan vijf tekens van een berekende vingerafdruk naartoe, en het vergelijken gebeurt hier. Ligt die dienst er even uit, dan wordt je wachtwoord gewoon geaccepteerd; een storing bij iemand anders mag jou niet tegenhouden.

Wat er precies wordt afgedwongen kan per platform verschillen: je hostingpartij stelt de minimumlengte in. Is je wachtwoord al ouder en korter dan het nieuwe minimum, dan blijft het gewoon werken — de regel geldt pas als je hem verandert.

We laten het je weten als er iets aan je inlog verandert

Verander je je wachtwoord, of zet je de tweestapsverificatie uit, dan krijg je daar een e-mail over — ook als je verder alle meldingen hebt uitgezet. Dat is met opzet: als jíj het niet was, is dat bericht het eerste wat je erover hoort, en dan kun je meteen je wachtwoord veranderen en je sessies beëindigen.

Berichten over je beveiliging kun je daarom niet uitzetten. Op Mijn account → Meldingen zie je die rij met een slotje erbij; alle andere groepen mag je wél stilzetten. Op Mijn account staat ook meteen hoeveel groepen je hebt stilgezet, zodat "ik hoor nooit iets" een antwoord heeft. Zie Meldingen en e-mail instellen.

Die keuze hoort bij jóu en niet bij je browser: zet je iets stil op je laptop, dan is het ook stil op je telefoon.

Actieve sessies

Op Mijn account → Sessies staat elk apparaat waarop je op dit moment bent aangemeld: welke browser en welk besturingssysteem, vanaf welk IP-adres, wanneer die sessie begon en wanneer hij voor het laatst iets deed. De sessie waarmee je nú kijkt is gemarkeerd.

Herken je er één niet? Klik Beëindigen. De volgende handeling van die browser komt uit op het aanmeldscherm — dat is geen vertraging van een minuut, het is meteen. Bij je eigen sessie staat met opzet geen knop: die beëindigen is afmelden, en daar zit een menu-item voor.

Twee dingen die het paneel bewust niet doet:

• Het vraagt je niet om een extra bevestiging met je passkey. Jezelf afmelden op een laptop die je bij een klant hebt laten liggen is het meest beveiligingsverhogende dat je kunt doen, en een extra vraag ervoor is een vraag die mensen om drie uur 's nachts wegklikken.
• Er staat geen token of sleutel in de lijst. Alles wat je ziet is beschrijvend; er is niets wat iemand zou kunnen hergebruiken.

Verander je je wachtwoord, dan worden al je andere sessies sowieso beëindigd — dat blijft de snelste weg als je iets helemaal niet vertrouwt.

Als je hostingpartij in je account kijkt

Je hostingpartij of reseller kan zich, als support daarom vraagt, als jou aanmelden. Dat is zichtbaar en begrensd:

• er staat dan een balk boven in beeld die zegt wie er meekijkt, met één knop om die sessie te beëindigen;
• zo'n sessie duurt maximaal een uur en verlengt zichzelf niet;
• er zijn dingen die zo'n sessie niet mag: je wachtwoord, je e-mailadres, je tweestapsverificatie of je passkeys wijzigen, geheimen tonen, facturatie, of andere mensen toegang geven;
• alles wat er gebeurt komt in het logboek te staan — onder jouw naam én onder die van degene die meekeek.

Dit is niet iets waar je toestemming voor geeft per keer. Wil je weten of het is gebeurd, kijk dan in het activiteitenoverzicht van je account.

Voor beheerders

Op het paneel zelf horen nog drie dingen bij dit onderwerp.

Niet iedereen mag inloggen als een klant. Het is een expliciet recht per persoon, standaard uit:

ssh root@panel1.corecp.dev
corecp-panel admin impersonation list
corecp-panel admin impersonation allow support@voorbeeld.nl
corecp-panel admin impersonation deny  support@voorbeeld.nl

Zware handelingen vragen een verse sleutel. Uitrol naar de vloot, join-tokens, rol- en beheerderswijzigingen, API-sleutels en huisstijl vragen om een factor die je in de laatste tien minuten hebt gebruikt. Het paneel vraagt er zelf om; je hoeft niets in te stellen.

Dat vragen gaat overal in het paneel hetzelfde: er verschijnt een venster Bevestig wie je bent, je vult je code in, en de handeling gaat daarna vanzelf door — je hoeft niets opnieuw in te vullen. Klik je het venster weg, dan gebeurt er niets en blijft je scherm precies zoals het was; er verschijnt geen foutmelding, want er is niets misgegaan. Op schermen die hier vaak om vragen staat het er van tevoren bij: "Je wordt om een verse bevestiging gevraagd zodra je hier iets opslaat."

Eén uitzondering sinds deze ronde: de huisstijl van je eigen groep bewerken vraagt er niet meer om. De huisstijl van het platform — waar iedereen op terugvalt die zelf niets heeft ingesteld — nog wel.

Een adres van de IP-lijst halen vraagt om een bevestiging, en het antwoord blijft in dat venster. Op Instellingen → Platformbeveiliging staat achter elk adres Verwijderen; het venster dat opengaat noemt wat je kwijtraakt en pas als de server het heeft uitgevoerd sluit het. Weigert de server het — bijvoorbeeld omdat je daarmee jezelf zou buitensluiten — dan blijft het venster staan met de reden erin, in plaats van dicht te gaan en de melding op de pagina erachter te laten.

Break-glass draait op de server, nooit via het web. Zit je zelf buiten door de IP-lijst, of is een beheerder al zijn factoren kwijt:

ssh root@panel1.corecp.dev
corecp-panel admin unlock-ip 203.0.113.10/32     # dit adres mag er weer bij
corecp-panel admin disable-allowlist             # de lijst helemaal uit
corecp-panel admin reset-2fa beheer@voorbeeld.nl # álle factoren van deze persoon weg

reset-2fa haalt de app-koppeling, de passkeys, de herstelcodes én de sessies weg. Dat is expres alles: een halve reset is hoe iemand buitengesloten blijft. Elk van deze commando's schrijft een regel in het auditlogboek en markeert die als pagineerbaar, dus het blijft nooit onopgemerkt.

Het auditlog filteren, en er naartoe linken

Op de pagina Auditlog staat elke handeling die iemand in jouw omgeving heeft gedaan. De keuzelijst rechtsboven filtert op afloop: alles, gelukt, geweigerd of mislukt. Sinds de eindcontrole van ronde 2 staat die keuze ook in het webadres, en dat is handiger dan het klinkt:

• /audit?result=error — alleen wat er misging;
• /audit?result=denied — alleen wat is geweigerd (iemand probeerde iets waar die geen recht op had);
• /audit — alles.

Zo'n adres kun je bewaren of doorsturen; wie erop klikt ziet dezelfde selectie. Het dashboard gebruikt hem zelf ook: de melding "104 taken mislukt op de vloot" brengt je nu naar precies die regels in plaats van naar het hele logboek.

Vanaf de terminal komt hetzelfde eruit:

ssh panel1.corecp.dev 'corecp-panel audit list --result error --limit 20'

Staat er een filter aan, dan zegt de pagina dat met een label bovenaan en een knop om het weg te halen. Een lijst die stiekem maar een deel toont is vervelender dan geen filter.

Zoeken in het logboek, en doorklikken naar wat er gebeurde

Sinds ronde 2b doorzoekt het zoekveld boven het logboek het hele logboek op de server en niet alleen de regels die je al binnengehaald had. Je zoekt op de technische naam van de handeling (mailbox.create), op wie hem deed, op waar hij over ging en op de reden van een weigering. Onder de tabel staat hoeveel regels er in totaal aan je zoekopdracht voldoen — bij een druk logboek staat er 10000+, want dan is het paneel gestopt met tellen en is verfijnen sneller dan wachten.

Belangrijker nog: elke regel wijst nu ergens naartoe. De kolom Doel brengt je naar het account, de server of het pakket waar de handeling over ging. Ging het over een mailbox of een website, dan kom je op het zoekscherm voor die naam uit — dat scherm weet bij welke klant hij hoort, en dat is de stap die je anders zelf met knippen en plakken deed. Regels waar niets bij hoort blijven gewoon tekst; een link die op een foutmelding uitkomt is vervelender dan geen link.

# hetzelfde over de API: de teller zit in een header, het antwoord blijft een lijst
curl -si -b cookies.txt 'https://panel1.corecp.dev/api/v1/audit?limit=50&q=mailbox' \
  | grep -i '^x-corecp-total'

Hoe zoeken, sorteren en bijladen in élke lijst werken staat in Werken met lange lijsten.

De limiet op uitgaande post hoort hierbij

Een website met een lek verstuurt duizenden berichten voordat iemand het merkt, en wat dat kost zijn niet die berichten — het is de hele server die op een blokkadelijst belandt, waardoor je gewone post nergens meer aankomt.

Daarom zit er een plafond op: 100 berichten per uur per mailbox, 500 per account. Er wordt niets geweigerd; post boven de limiet wordt vastgehouden en later bezorgd, en je mailprogramma probeert het vanzelf opnieuw. Post die je website met PHP verstuurt telt mee in datzelfde plafond, want dat is precies het verkeer dat een gekraakte site produceert.

Loopt een mailbox van jou tegen de limiet aan, dan krijg je daar die dag één bericht over — en dat is de moeite waard om te lezen, want een mailbox die ineens vijfhonderd berichten per uur wil versturen is meestal een wachtwoord dat iemand anders ook heeft.

De knoppen die je zonder wachtwoord ergens binnenlaten

Webmail en phpMyAdmin openen in een nieuw tabblad waarin je al bent ingelogd. Dat voelt als een achterdeur, en daarom staat hier wat er precies gebeurt.

• Het paneel geeft nooit een wachtwoord door. Het vraagt de server om een eenmalig toegangsbewijs en stuurt dat door naar het tabblad. Meer dan dat reist er niet mee.
• Dat bewijs geldt één keer en anderhalve minuut. Vernieuw je het tabblad, dan krijg je "deze inloglink is al gebruikt" — dat hoort zo.
• Het geldt standaard alleen vanaf het netwerk waarop je zat toen je klikte. Je beheerder kan dat strenger of losser zetten.
• Wat je binnenlaat is een sleutel die maar één ding opent: bij webmail alleen die ene mailbox (en hij werkt níet als wachtwoord in een mailprogramma), bij phpMyAdmin een tijdelijke databaselogin die alleen bij de geopende database mag en daarna wordt opgeruimd.
• Elke uitgifte en elk gebruik komt in het logboek van de server te staan, dus achteraf is te zien wie wanneer waar naar binnen ging.

Ziet iemand anders dan jij zo'n link? Doe niets: hij is bijna zeker al gebruikt of verlopen. Meld het wel bij je hostingpartij, dan kunnen zij het in het logboek terugzien.

Zie ook

• Meldingen en e-mail instellen
• Aanmelden, wisselen en je weg vinden
• Iemand toegang geven

Wie mag een IP-adres verplaatsen

Het vervangen van een IP-adres van een server is voorbehouden aan een server-admin: het raakt elke klant op die machine tegelijk. Een reseller kan wél een eigen adres aan zijn eigen klanten geven — dat telt mee in zijn pakketruimte — maar niet aan een klant van iemand anders.

Het beheeradres van een server, het adres waarop de server zelf bereikbaar is, kun je überhaupt niet vanuit het paneel wisselen. Daar hangen de agent en het servercertificaat aan, dus dat gebeurt op de machine zelf. Zie Een IP-adres vervangen.