DNS hosting met dns validatie letsencrypt

rpr · Bericht 4 maanden geleden

Momenteel host ik mijn domeinen bij Combell en doe ik http validatie voor letsencrypt certificaten.
Omdat ik mijn attack surface area wil verkleinen zou ik mijn https sites alleen via Belgie bereikbaar willen maken.
Maar letsencrypt publiceert geen ip adressen vanwaar het zijn validatie doet. Vandaag wil ik dns validatie doen.
Alleen bij combell vereist dit een vast ip adres.

Iemand die een dienst kan aanraden om mijn domeinen naar te migreren?

Bericht 4 maanden geleden

Gewoon je dns (nameservers) verhuizen naar bvb cloudflare. Je domeinen zelf kan je laten bij combell.

(Ikzelf heb een paar domeinen bij vimexx zitten en doe de dns via cloudflare, en gebruik ook letsencrypt met dns validatie.)

JUD · Bericht 4 maanden geleden

devilkin schreef: 4 maanden geleden Gewoon je dns (nameservers) verhuizen naar bvb cloudflare. Je domeinen zelf kan je laten bij combell.

(Ikzelf heb een paar domeinen bij vimexx zitten en doe de dns via cloudflare, en gebruik ook letsencrypt met dns validatie.)

Ik was bij vimexx vertrokken omdat ik geen DNSSEC meer kon gebruiken in die setup. Bij OVH was dat wel vlot mogelijk.

CCatalyst · Bericht 4 maanden geleden

Als het echt over attack surface gaat: je kan voor $10/jaar een RapidSSL cert nemen dat een jaar geldig is en je telkens zelf vervangt met volledige controle erover. Validatie per email. Nog kleinere attack surface. Je moet domeinen niet verhuizen noch andere aanpassingen maken in je setup.

devilkin schreef: 4 maanden geleden Gewoon je dns (nameservers) verhuizen naar bvb cloudflare. Je domeinen zelf kan je laten bij combell.

En hoe verkleint hij dan z'n attack surface? Want verkeer gaat dan binnenkomen via de CloudFlare IP's (toch als je CloudFlare de certificaten naar de buitenwereld laat managen)?

Landen blokkeren in de CloudFlare WAF is enkel via een betalend plan dacht ik?

Zelf doen obv de info die CloudFlare doorstuurt over de connectie (via CF-IPCountry), voor zover dat betrouwbaar is?

Bovendien zal ie nog steeds de requests tussen CloudFlare en z'n eigen server beveiligd laten gebeuren ook, en daarvoor zal ie nog steeds z'n eigen certificaten moeten hebben, en als dat via Let's Encrypt blijft gaan zal ie z'n attack surface dus niet verkleinen, enkel wat verstoppen.

Bericht 4 maanden geleden

Zucht. Even lezen. Ik zeg nergens wat jij er daar allemaal bijsleurt.

Het gaat puur om DNS. Niks verplicht je om al je traffiek door cloudflare te laten afhandelen. Proxying afzetten, done.

Wat je wel kan - en wat ik op doelde - is perfect letsencrypt gebruiken met dns validatie tegen cloudflare. Je records pointen dan nog altijd gewoon naar de combell hosting.

Kost geen centje meer dan nu.

(en terzijde, waf met country block is perfect te gebruiken op een free cloudflare plan)

CCatalyst · Bericht 4 maanden geleden

devilkin schreef: 4 maanden geleden Wat je wel kan - en wat ik op doelde - is perfect letsencrypt gebruiken met dns validatie tegen cloudflare. Je records pointen dan nog altijd gewoon naar de combell hosting.

Dat kan inderdaad. Maar als dit het enige is dat nodig is, wat OP toch niet suggereert denk ik, waarom volstaat de oplossing van Combell zelf dan niet? Doet Combell hun eigen oplossing dan enkel met HTTP validatie oid?

En indien OP dit voor wat voor reden dan ook zelf moet doen, vereist het loutere toevoegen van een TXT record effectief een vast IP adres bij Combell? Dat betekent dus ook voor emails verzenden vanop dat domein, want SPF records etc. Of gaat het puur over API toegang tot DNS zodat hij volledig kan automatiseren (wat OP wel niet vermeldt, waarvoor je ook geen fixed IP nodig hebt maar wel een reseller account, en mogelijks betekent dat hij de API credentials dan op z'n server zet wat de attack surface niet verkleint). In dat geval, waarom niet via CNAME naar Cloudflare werken (of ergens anders)?

Splitter · Bericht 4 maanden geleden

CCatalyst schreef: 4 maanden geleden Dat kan inderdaad. Maar als dit het enige is dat nodig is, wat OP toch niet suggereert denk ik, waarom volstaat de oplossing van Combell zelf dan niet? Doet Combell hun eigen oplossing dan enkel met HTTP validatie oid?

als je naar die link kijkt, en ze duidelijk zeggen dat je voor een alias niet zomaar een cert kan hebben, lijkt me idd dat ze enkel http validatie doen (zal ook het eenvoudigste zijn voor hun, gezien ze daarvoor niet afhankelijk zijn van waar je dns staat etc, maar gewoon 1 wildcard in hun apache (of nginx) conf nodig hebben.

rpr schreef: 4 maanden geleden Omdat ik mijn attack surface area wil verkleinen zou ik mijn https sites alleen via Belgie bereikbaar willen maken.

Op zegt hier wel degelijk dat hij gewoon de attack surface wil verkleinen door zijn site enkel voor belgische IPs bereikbaar te maken,
wat effectief een deel van de attack surface kan verkleinen (granted, niet noodzakelijk erg veel, but still)

De door devilkin aangehaalde oplossing is 1 van de meeste eenvoudige: gewoon je DNS verhuizen naar cloudflare, kost niets,
en daar kan je dan vervolgens de verificatie effectief via dns laten verlopen.

bijkomend kan je dan ook nog gaan cachen, je echte hosting-ip verbergen, of zero trust gaan gebruiken - het is een prima manier om te beginnen en stilaan de attack surface nog verder te verkleinen, naargelang de noden en wensen van OP.
(alleen niet vergeten dat je, indien je oplossingen van cloudflare gebruikt, ook een bepaalde afhankelijkheid/vertrouwensrelatie met cloudlfare zal creeren)

CCatalyst · Bericht 4 maanden geleden

Splitter schreef: 4 maanden geledenen daar kan je dan vervolgens de verificatie effectief via dns laten verlopen.

Tenzij je dit elke 90 dagen manueel wilt doen, via de Cloudflare API met API credentials dan die je beter niet op je webserver zet als je je attack surface wilt verkleinen - anders heeft men ook toegang tot uw DNS config als men daar binnenraakt - alhoewel het certificaat daar dan wel zal moeten komen te staan.

Splitter schreef: 4 maanden geleden (alleen niet vergeten dat je, indien je oplossingen van cloudflare gebruikt, ook een bepaalde afhankelijkheid/vertrouwensrelatie met cloudlfare zal creeren)

Inderdaad, dat is waar ik ook aan dacht. Evenals het gebruik van meer diepgaandere oplossingen om de attack surface te verkleinen ipv botweg op land te gaan selecteren, wat een gedreven attacker natuurlijk meteen kan omzeilen en een vals gevoel van veiligheid kan geven. Om opportunistische aanvallen tegen te gaan kan het wel wat helpen (alhoewel die sowieso niet zouden moeten kunnen binnenraken, maar soit).

Splitter · Bericht 4 maanden geleden

CCatalyst schreef: 4 maanden geleden Tenzij je dit elke 90 dagen manueel wilt doen, via de Cloudflare API met API credentials dan die je beter niet op je webserver zet als je je attack surface wilt verkleinen -

als je de dns laat afhandelen door cloudflare (en caching/proxying laat doen), hoef je 0,0 te doen voor de ssl certs.
die worden dan uitgegeven en vernieuwd via cloudflare (en komen van google trust services)

CCatalyst schreef: 4 maanden geleden Evenals het gebruik van meer diepgaandere oplossingen om de attack surface te verkleinen ipv botweg op land te gaan selecteren, wat een gedreven attacker natuurlijk meteen kan omzeilen en een vals gevoel van veiligheid kan geven.

zoals de "under attack" aanzetten van cloudflare (captcha van "prove you are human" etc), de waf, zero trust, ....

het meest eenvoudige om te doen wat OP wil, ervan uitgaande dat ie bereid is de dns ergens anders te hosten (en dus records terug aan te maken/over te zetten - hoewel cloudflare ook een goede job doet met het automatisch ophalen ervan), is effectief gewoon de dns bij cloudflare te zetten.

je kan je server dan vervolgens ook nog mooi dichttimmeren, gezien je dan enkel de cloudflare IPs moet toelaten (als je proxying gebruikt).
en cloudflare is niet meer of minder betrouwbaar als AWS, OCI, of google...

zelf gebruik ik ondertussen ook al een aantal jaren cloudflare voor mijn dns van mijn domeinen - niet omdat dns moeilijk te onderhouden is (hell, ik draai nog steeds mijn eigen mailserver), maar omdat de extra's die cloudflare je kan bezorgen gewoon handig zijn.

also, de statistiekjes zijn ook best handig - en geven je ook aan hoeveel attacks cloudflare gedetecteerd en geblokkeerd heeft, alsook de landen van de requests.

dat gezegd zijnde is het natuurlijk nog altijd voor iedereen een persoonlijke keus, maar het is niet zo, zoals jij aangeeft, dat er dingen manueel hoeven te gebeuren,
of dat je iets op je server zou moeten zetten.

CCatalyst · Bericht 4 maanden geleden

Splitter schreef: 4 maanden geleden maar het is niet zo, zoals jij aangeeft, dat er dingen manueel hoeven te gebeuren,
of dat je iets op je server zou moeten zetten.

Als je hun proxy gebruikt (en dan ook de landenblokkering aan CF overlaat?) idd niet, maar dat is niet wat OP vraagt.

Als je zo zuiver mogelijk blijft bij wat OP vraagt, en DNS naar Cloudflare overzet zonder proxying, dan ga je daar wel met de API moeten werken om de Let's Encrypt renewals automatisch af te handelen, anders moet je het manueel doen. Als je het automatisch doet kan je best vermijden dat je de API credentials op je server die aan het internet hangt zet, hoewel je daar wel de certs uiteindelijk moet op krijgen. Dat is een risico dat ook in de Let's Encrypt documentatie inzake vermeld wordt.

Misschien kan OP de summiere openingspost nog uitbreiden met wat hij precies wil bereiken.

rpr · Bericht 4 maanden geleden

Zal Cloudflare deze week eens nader bekijken.
Reden dat de combell oplossing niet werkt is doordat het niet voor een website is maar een bepaalde dienst die via ssl communiceert.
Nu zie ik daar constant pogingen op welke falen omdat MFA vereist is maar de banlist van adressen begint ook performantie problemen met zich mee te brengen.
En 95% van de aanvallen komt uit US/China/India waar er geen gebruikers van de dienst zich bevinden.