nginx proxy_set_header issue

vrijdag 3 juli 2020 14:11

Acties:

0 Henk 'm!

Topicstarter

Situatie

Laten we voor nu even stellen; we hebben de volgende domeinnamen abc001.nl t/m abc100.nl
Daarachter zitten vele applicatie-servers. Laten we voor nu stellen

code:

1
2
3

app01.abc001.nl
app02.abc001.nl
etc. etc.

Tussen het domein en de applicatieservers zit de F5 load balancer.
LET OP: DE EINDGEBRUIKER KAN NIET BIJ DE APPLICATIE-SERVERS. ALLEEN DE F5-LOADBALANCER KAN DAARBIJ.
Die regel heb ik niet bedacht, maar moet ik mij helaas wel aan houden.

en de volgende nginx setting:

code:

1	proxy_set_header Host $host;

Nginx:

code:

1	nginx version: nginx/1.14.1

Probleem:
Bij een fake host header gebeurd er zoiets als dit:

code:

1 2	curl --header "Host: example.com" https://abc001.nl <html><body>You are being <a href="https://exampe.com/sign_in">redirected</a>.</body></html>%

En dat willen we natuurlijk niet:

Wat hebben we geprobeerd
De volgende setting werkt wel, maar is heel k*t om te onderhouden:

code:

1
2
3

proxy_set_header Host abc001.nl;
proxy_set_header Host abc002.nl;
etc. etc.

Dit werkt helaas niet

code:

1	proxy_set_header Host $proxy_host;

Als ik dan in mijn browser naar abc001.nl ga, dan kom ik in mijn browser terecht op bijvoorbeeld

code:

1	app01.abc001.nl

En dan gaat het mis, want in je browser moet het abc001.nl blijven.

De Vraag
Wie weet een betere oplossing dan dit:

code:

a
proxy_set_header Host abc001.nl;
proxy_set_header Host abc002.nl;
etc. etc.

zaterdag 4 juli 2020 12:35

Acties:

0 Henk 'm!

amx

Waarom willen we dat niet en in welke situatie doet een fake host header zich voor?

reverse nginxproxy instellen met locations en proxy_pass(?)

Het antwoord is niet per se wat je zoekt, maar je probleemstelling is voor mij niet duidelijk (stageopdracht?)

maandag 6 juli 2020 09:54

Acties:

0 Henk 'm!

jeroeningen

Topicstarter

amx schreef op zaterdag 4 juli 2020 @ 12:35:
Waarom willen we dat niet en in welke situatie doet een fake host header zich voor?

In theorie kan een fake host header leiden tot een hack. Tsja.... zelf lig ik er ook niet zo wakker van, maar mijn baas wel en gezien hij mijn salaris betaalt...

reverse nginxproxy instellen met locations en proxy_pass(?)

Da's een optie, maar niet echt onderhoudbaar in de zin van een soort-van heel veel duplicated code. Voor elk (sub) domain moet ik dan een location gaan instellen

maandag 6 juli 2020 10:17

Acties:

0 Henk 'm!

amx

Persistent cookies?
https://serverfault.com/q...able-between-redirections

maandag 6 juli 2020 12:54

Acties:

0 Henk 'm!

jeroeningen

Topicstarter

amx schreef op maandag 6 juli 2020 @ 10:17:
Persistent cookies?
https://serverfault.com/q...able-between-redirections

Ik snap je niet helemaal.
Hoe zie je het voor je?

[ Voor 8% gewijzigd door jeroeningen op 06-07-2020 15:42 ]

dinsdag 7 juli 2020 13:07

Acties:

0 Henk 'm!

amx

Wat snap je niet?

dinsdag 7 juli 2020 17:08

Acties:

0 Henk 'm!

jeroeningen

Topicstarter

amx schreef op dinsdag 7 juli 2020 @ 13:07:
Wat snap je niet?

Volgens mij heeft dit niks te maken met een Persistent Cookie, maar dat de Host header genegeerd moet worden.

dinsdag 7 juli 2020 17:18

Acties:

0 Henk 'm!

DataGhost

iPL dev

jeroeningen schreef op maandag 6 juli 2020 @ 09:54:
[...]

In theorie kan een fake host header leiden tot een hack. Tsja.... zelf lig ik er ook niet zo wakker van, maar mijn baas wel en gezien hij mijn salaris betaalt...

Hoe zie je dat voor je? En hoe zie je meerdere hosts op hetzelfde IP gebeuren dan, wat echt extreem gangbaar is?

Ik neem aan dat je per abcXXX al een virtual host hebt, en om uberhaupt bij de config (en proxy-statements) van dat vhost aan te komen moet je een Host-header aanleveren die overeenkomt met een van die hosts. Als je dus example.com als host stuurt kom je als het goed is niet eens in een situatie dat je server ergens heen gaat proxyen, dus dan kan je prima een 404 ofzo serveren in een default vhost wat niks met je applicatieservers te maken heeft. Je hoeft daarom dus ook helemaal niks met de Host-header te doen, na het maken van de request kan die niet aangepast worden, omdat die er deel van uitmaakt.

jeroeningen schreef op vrijdag 3 juli 2020 @ 14:11:
Als ik dan in mijn browser naar abc001.nl ga, dan kom ik in mijn browser terecht op bijvoorbeeld
code:
1
app01.abc001.nl
En dan gaat het mis, want in je browser moet het abc001.nl blijven.

Dit gaat sowieso al mis. De Host-header is iets van client naar server, niet andersom. Als je op de client de host in de URL-balk aan wilt passen zal je dat moeten doen dmv een redirect. Ik neem aan dat je applicatieservers dit fout doen door te redirecten naar app01.abc001.nl als je naar abc001.nl connect.
In je voorbeeld heb je het over app01.abc001.nl en app02.abc001.nl. Welke van de twee moet je dan heen connecten als je naar abc001.nl gaat? Het kan er altijd maar eentje zijn.
Als het probleem is dat app01.abc001.nl bereikbaar is door de eindgebruikers zonder door de loadbalancer te gaan, moet je gewoon in je DNS regelen dat alle appXX.abcYYY.nl naar je loadbalancer verwijzen. In de loadbalancer zorg je dan voor andere hostnames ofzo, zodat 'ie de boel wel kan vinden. Dan boeit het ook niet meer wat er in de URL-balk staat.

Als je hier je oplossing nog niet uit kan halen zou het enorm schelen als je eerst even je probleem fatsoenlijk beschrijft. Mij is namelijk volstrekt onduidelijk welke eisen je precies hebt en waarom. Je begint wel direct over een bepaalde oplossingsrichting te praten die ik ook niet direct volg. Daardoor lijkt het al gauw op een XY-problem.
Dus wat moet je precies bereiken, waarom is het zo belangrijk wat er in de URL-balk staat, wat is het hele probleem precies, en daarna pas is het een keer interessant om te weten wat je geprobeerd hebt en waarom dat niet werkt.

[ Voor 48% gewijzigd door DataGhost op 07-07-2020 17:29 ]

dinsdag 7 juli 2020 20:59

Acties:

0 Henk 'm!

amx

DataGhost schreef op dinsdag 7 juli 2020 @ 17:18:
[...]

Hoe zie je dat voor je? En hoe zie je meerdere hosts op hetzelfde IP gebeuren dan, wat echt extreem gangbaar is?

Ik neem aan dat je per abcXXX al een virtual host hebt, en om uberhaupt bij de config (en proxy-statements) van dat vhost aan te komen moet je een Host-header aanleveren die overeenkomt met een van die hosts. Als je dus example.com als host stuurt kom je als het goed is niet eens in een situatie dat je server ergens heen gaat proxyen, dus dan kan je prima een 404 ofzo serveren in een default vhost wat niks met je applicatieservers te maken heeft. Je hoeft daarom dus ook helemaal niks met de Host-header te doen, na het maken van de request kan die niet aangepast worden, omdat die er deel van uitmaakt.

[...]
Als je hier je oplossing nog niet uit kan halen zou het enorm schelen als je eerst even je probleem fatsoenlijk beschrijft. Mij is namelijk volstrekt onduidelijk welke eisen je precies hebt en waarom. Je begint wel direct over een bepaalde oplossingsrichting te praten die ik ook niet direct volg. Daardoor lijkt het al gauw op een XY-problem.

De manier van topicstart doet me heel erg denken aan portfolio opdrachten van le voorlopleiding (IT security)

In theorie kan een fake host header leiden tot een hack. Tsja.... zelf lig ik er ook niet zo wakker van, maar mijn baas wel en gezien hij mijn salaris betaalt...

Dan is er mitigatie tegen, denk dat je je daar wel voor wil inzetten, niet?

Hoeveel resources heeft Nginx hier eigenlijk? Want de oplossingen (die zijn er namelijk wel met een beetje google-fu) worden terecht begeleid met de vraag in hoeverre dit rekenkracht van de reverse proxy vraagt en wat de load balancer dan nog moet doen.

maandag 27 juli 2020 13:59

Acties:

0 Henk 'm!

DataGhost

iPL dev

@jeroeningen is hier nog iets uitgekomen?

Vraag

Alle reacties