Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Encryptie achter load balancer
20-01-2023, 09:11 door Anoniem, 10 reacties
Hallo allemaal,
Ik zit in dubio omtrent het encrypten van data achter een loadbalancer die ik draai.
De voorkant van de LB is voorzien van een certificaat en het verkeer dat daarop landt is netjes versleuteld.
Op dit moment is dat aan de achterkant van de LB ook zo, waar de webservers ook voorzien van een certificaat.
Echter geeft dit wel richting de 20% extra overhead en performance is een belangrijke factor in de omgeving.
Daarnaast is het ook een administratieve kwestie, des te meer plekken waar certificaten draaien des te meer dat er stuk kan gaan, dat wordt na een server of 50 ook wel vervelend (en ja dit is deels al automatisch)
Het netwerk waarin de webservers draaien is dedicated voor de omgeving waarin alleen machines draaien die direct nodig zijn voor de dienst.
Oftewel dit zou als trusted kunnen worden gezien waardoor unencrypted data acceptabel zou kunnen zijn.
Hier vloeit geen hele gevoelige data overheen echter wel authenticatie gegevens.
Mocht er onverhoopt toch een server gecomprimiteerd zijn dan kan dit voor verdere problemen zorgen.
Een alternatief dat ik overweeg is om zelf een CA te draaien achter de LB met een wat lichtere versleuteling als compromie tussen security en performance, voordeel is ook dat ik zelf de geldigheid kan bepalen.
Hoe denken jullie hier over?
Ik zit in dubio omtrent het encrypten van data achter een loadbalancer die ik draai.
De voorkant van de LB is voorzien van een certificaat en het verkeer dat daarop landt is netjes versleuteld.
Op dit moment is dat aan de achterkant van de LB ook zo, waar de webservers ook voorzien van een certificaat.
Echter geeft dit wel richting de 20% extra overhead en performance is een belangrijke factor in de omgeving.
Daarnaast is het ook een administratieve kwestie, des te meer plekken waar certificaten draaien des te meer dat er stuk kan gaan, dat wordt na een server of 50 ook wel vervelend (en ja dit is deels al automatisch)
Het netwerk waarin de webservers draaien is dedicated voor de omgeving waarin alleen machines draaien die direct nodig zijn voor de dienst.
Oftewel dit zou als trusted kunnen worden gezien waardoor unencrypted data acceptabel zou kunnen zijn.
Hier vloeit geen hele gevoelige data overheen echter wel authenticatie gegevens.
Mocht er onverhoopt toch een server gecomprimiteerd zijn dan kan dit voor verdere problemen zorgen.
Een alternatief dat ik overweeg is om zelf een CA te draaien achter de LB met een wat lichtere versleuteling als compromie tussen security en performance, voordeel is ook dat ik zelf de geldigheid kan bepalen.
Hoe denken jullie hier over?
Reacties (10)
Als er een server gecompromitteerd is dan gaat (TLS) encryptie je toch niet helpen!
Er zijn vele installaties waarbij loadbalancers met TLS offloading draaien met unencrypted data erachter.
Is uiteraard iedereens eigen overweging.
Er zijn vele installaties waarbij loadbalancers met TLS offloading draaien met unencrypted data erachter.
Is uiteraard iedereens eigen overweging.
Hallo Anoniem,
Je stelt een vraag waar geen direct ja of nee antwoord op past; het hangt helemaal van de omstandigheden af of het een goed idee is. Ik zou je graag nog een paar extra vragen stellen:
- Verwerk je persoonsgegevens die wettelijke bescherming vereisen?
- Verwerk je andere gevoelige informatie?
- Hoe is de fysieke beveiliging van je serverpark, inclusief de netwerkkabels? Kunnen derden bij servers en kabels komen?
- Hoe is de netwerkstructuur qua firewalls, managed switch configuratie?
Een goede monitoring en response kan veel problemen klein houden. Draai je een IDS? Er bestaan ook netwerkkaarten met hardware ondersteuning voor encryptie....
Persoonlijk ben ik van mening dat versleuteling van de "nos.nl" of "nu.nl" nieuwssites op het publieke Internet niet zo privacy-relevant is (maar voor andere websites wel). Belangrijkste criterium is: voldoet jouw oplossing aan de redelijke verwachtingen van een gemiddelde gebruiker?
Je stelt een vraag waar geen direct ja of nee antwoord op past; het hangt helemaal van de omstandigheden af of het een goed idee is. Ik zou je graag nog een paar extra vragen stellen:
- Verwerk je persoonsgegevens die wettelijke bescherming vereisen?
- Verwerk je andere gevoelige informatie?
- Hoe is de fysieke beveiliging van je serverpark, inclusief de netwerkkabels? Kunnen derden bij servers en kabels komen?
- Hoe is de netwerkstructuur qua firewalls, managed switch configuratie?
Een goede monitoring en response kan veel problemen klein houden. Draai je een IDS? Er bestaan ook netwerkkaarten met hardware ondersteuning voor encryptie....
Persoonlijk ben ik van mening dat versleuteling van de "nos.nl" of "nu.nl" nieuwssites op het publieke Internet niet zo privacy-relevant is (maar voor andere websites wel). Belangrijkste criterium is: voldoet jouw oplossing aan de redelijke verwachtingen van een gemiddelde gebruiker?
Door Anoniem: Als er een server gecompromitteerd is dan gaat (TLS) encryptie je toch niet helpen!
Er zijn vele installaties waarbij loadbalancers met TLS offloading draaien met unencrypted data erachter.
Is uiteraard iedereens eigen overweging.
Er zijn vele installaties waarbij loadbalancers met TLS offloading draaien met unencrypted data erachter.
Is uiteraard iedereens eigen overweging.
Dat zou in zoverre helpen dat verkeer tussen andere machines minder kwetsbaar zouden zijn voor bijv. een MITM.
Door Anoniem: Hallo Anoniem,
Je stelt een vraag waar geen direct ja of nee antwoord op past; het hangt helemaal van de omstandigheden af of het een goed idee is. Ik zou je graag nog een paar extra vragen stellen:
- Verwerk je persoonsgegevens die wettelijke bescherming vereisen?
- Verwerk je andere gevoelige informatie?
- Hoe is de fysieke beveiliging van je serverpark, inclusief de netwerkkabels? Kunnen derden bij servers en kabels komen?
- Hoe is de netwerkstructuur qua firewalls, managed switch configuratie?
Een goede monitoring en response kan veel problemen klein houden. Draai je een IDS? Er bestaan ook netwerkkaarten met hardware ondersteuning voor encryptie....
Persoonlijk ben ik van mening dat versleuteling van de "nos.nl" of "nu.nl" nieuwssites op het publieke Internet niet zo privacy-relevant is (maar voor andere websites wel). Belangrijkste criterium is: voldoet jouw oplossing aan de redelijke verwachtingen van een gemiddelde gebruiker?
Je stelt een vraag waar geen direct ja of nee antwoord op past; het hangt helemaal van de omstandigheden af of het een goed idee is. Ik zou je graag nog een paar extra vragen stellen:
- Verwerk je persoonsgegevens die wettelijke bescherming vereisen?
- Verwerk je andere gevoelige informatie?
- Hoe is de fysieke beveiliging van je serverpark, inclusief de netwerkkabels? Kunnen derden bij servers en kabels komen?
- Hoe is de netwerkstructuur qua firewalls, managed switch configuratie?
Een goede monitoring en response kan veel problemen klein houden. Draai je een IDS? Er bestaan ook netwerkkaarten met hardware ondersteuning voor encryptie....
Persoonlijk ben ik van mening dat versleuteling van de "nos.nl" of "nu.nl" nieuwssites op het publieke Internet niet zo privacy-relevant is (maar voor andere websites wel). Belangrijkste criterium is: voldoet jouw oplossing aan de redelijke verwachtingen van een gemiddelde gebruiker?
- Het verwerkt geen persoonsgegevens.
- Behalve zaken als API key's niet hele gevoelige data maar manipulatie zou wel drastische gevolgen kunnen hebben.
- Het betreft een dedicated virtuele omgeving met eigen VLANs en algeheel beheer over virtuele appliances.
- Het netwerk heeft een eigen dedicated virtuele firewall met daarachter eigen VLANs, helaas geen controle over de virtuele switching laag, zodoende kan ik op die layer niet zo veel doen.
De servers worden gemonitored en gecontroleerd op kwetsbare packages naast wat andere faciliteiten.
Een IDS staat op de planning maar helaas nog niet echt tijd voor gehad.
Verder is er relatief weinig attack surface omdat het niet naar het web open staat maar de stakes zijn wel erg hoog.
Indien OFFLOADING (layer 7) geen vereiste is kun je de LB als SSLBRIDGE (layer 4) configureren. SSL terminatie vervolgens op servers zelf afhandelen.
Dank voor de antwoorden tot dusverre, ik heb over twee punten specifieke vragen:
- Behalve zaken als API key's niet hele gevoelige data maar manipulatie zou wel drastische gevolgen kunnen hebben.
Moet ik bij de "drastische gevolgen" denken aan alleen schade of zijn er ook mogelijkheden dat personen zich kunnen verrijken door manipulatie van gegevens? Dit voor het dreigingsmodel: vandalisme of fraude/diefstal. (Hoef je niet publiekelijk te beantwoorden.)
- Het betreft een dedicated virtuele omgeving met eigen VLANs en algeheel beheer over virtuele appliances.
Mijn vraag was gericht op de fysieke beveiliging van de fysieke machines. Als een aanvaller fysiek toegang heeft tot de hardware (of toegang tot de hypervisor) is een VM niet veilig meer. Wat voor jouw voorgestelde wijziging een hele belangrijke vraag is: "Hoe makkelijk kan een aanvaller bij de fysieke kabel om daar een fysieke tap (of manipulator) in te zetten?" Kan iemand fysiek via een switch verkeer aftappen?
Als je die fysieke netwerkveiligheid onvoldoende kunt borgen creëer je na je wijziging een probleem.
- Behalve zaken als API key's niet hele gevoelige data maar manipulatie zou wel drastische gevolgen kunnen hebben.
- Het betreft een dedicated virtuele omgeving met eigen VLANs en algeheel beheer over virtuele appliances.
Als je die fysieke netwerkveiligheid onvoldoende kunt borgen creëer je na je wijziging een probleem.
Door Anoniem: Dank voor de antwoorden tot dusverre, ik heb over twee punten specifieke vragen:
- Behalve zaken als API key's niet hele gevoelige data maar manipulatie zou wel drastische gevolgen kunnen hebben.
Moet ik bij de "drastische gevolgen" denken aan alleen schade of zijn er ook mogelijkheden dat personen zich kunnen verrijken door manipulatie van gegevens? Dit voor het dreigingsmodel: vandalisme of fraude/diefstal. (Hoef je niet publiekelijk te beantwoorden.)
- Het betreft een dedicated virtuele omgeving met eigen VLANs en algeheel beheer over virtuele appliances.
Mijn vraag was gericht op de fysieke beveiliging van de fysieke machines. Als een aanvaller fysiek toegang heeft tot de hardware (of toegang tot de hypervisor) is een VM niet veilig meer. Wat voor jouw voorgestelde wijziging een hele belangrijke vraag is: "Hoe makkelijk kan een aanvaller bij de fysieke kabel om daar een fysieke tap (of manipulator) in te zetten?" Kan iemand fysiek via een switch verkeer aftappen?
Als je die fysieke netwerkveiligheid onvoldoende kunt borgen creëer je na je wijziging een probleem.
- Behalve zaken als API key's niet hele gevoelige data maar manipulatie zou wel drastische gevolgen kunnen hebben.
- Het betreft een dedicated virtuele omgeving met eigen VLANs en algeheel beheer over virtuele appliances.
Als je die fysieke netwerkveiligheid onvoldoende kunt borgen creëer je na je wijziging een probleem.
Op je eerste vraag, ja dit zou inderdaad voor fraude of ernstige interruptie in bedrijfscontinuiteit kunnen zorgen, iets dat heel snel in de kosten zou kunnen lopen.
De fysieke beveiliging voldoet aan de allerhoogste standaarden, iets waar ik mij allerminst zorgen over maak.
(En ja ook daar zou potentieel iets te halen kunnen zijn maar dan hebben we grotere zorgen op dat moment!
Door Anoniem: Indien OFFLOADING (layer 7) geen vereiste is kun je de LB als SSLBRIDGE (layer 4) configureren. SSL terminatie vervolgens op servers zelf afhandelen.
)Dat is inderdaad iets om te overwegen, ik ga daar eens wat mee testen!
Bedankt!
Door Anoniem:
[..]
Dat is inderdaad iets om te overwegen, ik ga daar eens wat mee testen!
Bedankt!
[..]
Door Anoniem: Indien OFFLOADING (layer 7) geen vereiste is kun je de LB als SSLBRIDGE (layer 4) configureren. SSL terminatie vervolgens op servers zelf afhandelen.
)Dat is inderdaad iets om te overwegen, ik ga daar eens wat mee testen!
Bedankt!
Realiseer je heel goed dat als je de servers zelf SSL laat doen, je heel actief de regelmatige OpenSSL vulnerabilities moet tracken en patchen op je hele server farm .
Op veel LBs heb je daar toch minder (acuut) omkijken naar - zelfs al is de code misschien ook afkomstig van OpenSSL is de CPU en/of OS architectuur meestal anders dan (Lin/Win) x86 en zijn er stuk minder snel exploits beschikbaar .
Feitelijk *breng* je een behoorlijke attack surface direct van Internet naar je servers als je dat doet .
Met wat je in 20-1 15:08 schrijft zou ik geen SSL gaan doen in dat segmentje maar mijn tijd en energie steken in iets met meer rendement .
tja, je kunt makkelijker scannen op unencrypted data.
maar persoonlijk zou ik een eigen cert gebruiken met een levensduur van 1 jaar ofzo.
is de data toch gecrypt en is er niet zoveel adminstratie.
maar persoonlijk zou ik een eigen cert gebruiken met een levensduur van 1 jaar ofzo.
is de data toch gecrypt en is er niet zoveel adminstratie.
Door Anoniem:
Realiseer je heel goed dat als je de servers zelf SSL laat doen, je heel actief de regelmatige OpenSSL vulnerabilities moet tracken en patchen op je hele server farm .
Op veel LBs heb je daar toch minder (acuut) omkijken naar - zelfs al is de code misschien ook afkomstig van OpenSSL is de CPU en/of OS architectuur meestal anders dan (Lin/Win) x86 en zijn er stuk minder snel exploits beschikbaar .
Realiseer je heel goed dat als je de servers zelf SSL laat doen, je heel actief de regelmatige OpenSSL vulnerabilities moet tracken en patchen op je hele server farm .
Op veel LBs heb je daar toch minder (acuut) omkijken naar - zelfs al is de code misschien ook afkomstig van OpenSSL is de CPU en/of OS architectuur meestal anders dan (Lin/Win) x86 en zijn er stuk minder snel exploits beschikbaar .
Ja die F5 loadbalancers hebben een hardstikke goede naam wat vulnerabilities betreft!
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
