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?
Reacties (10)
20-01-2023, 10:15 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.
20-01-2023, 10:55 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?
20-01-2023, 11:17 door Anoniem
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.

Dat zou in zoverre helpen dat verkeer tussen andere machines minder kwetsbaar zouden zijn voor bijv. een MITM.
20-01-2023, 15:08 door Anoniem
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?

- 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.
20-01-2023, 15:17 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.
20-01-2023, 17:00 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.
24-01-2023, 10:33 door Anoniem
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.

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!
24-01-2023, 14:11 door Anoniem
Door Anoniem:
[..]
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 .
24-01-2023, 14:40 door Anoniem
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.
24-01-2023, 18:30 door Anoniem
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 .

Ja die F5 loadbalancers hebben een hardstikke goede naam wat vulnerabilities betreft!
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.