Toon posts:

nginx proxy_set_header issue

Pagina: 1
Acties:

Vraag


Acties:
  • 0Henk 'm!

  • jeroeningen
  • Registratie: Juli 2020
  • Laatst online: 26-09 15:32
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:
1
2
3
4
a
proxy_set_header Host abc001.nl;
proxy_set_header Host abc002.nl;
etc. etc.

Alle reacties


  • amx
  • Registratie: December 2007
  • Laatst online: 15:30
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?)

Acties:
  • 0Henk 'm!

  • jeroeningen
  • Registratie: Juli 2020
  • Laatst online: 26-09 15:32
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

Acties:
  • 0Henk 'm!

  • amx
  • Registratie: December 2007
  • Laatst online: 15:30

Acties:
  • 0Henk 'm!

  • jeroeningen
  • Registratie: Juli 2020
  • Laatst online: 26-09 15:32
Ik snap je niet helemaal.
Hoe zie je het voor je?

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


Acties:
  • 0Henk 'm!

  • amx
  • Registratie: December 2007
  • Laatst online: 15:30
Wat snap je niet?

Acties:
  • 0Henk 'm!

  • jeroeningen
  • Registratie: Juli 2020
  • Laatst online: 26-09 15:32
Volgens mij heeft dit niks te maken met een Persistent Cookie, maar dat de Host header genegeerd moet worden.

Acties:
  • 0Henk 'm!

  • DataGhost
  • Registratie: Augustus 2003
  • Laatst online: 10:39

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]


Acties:
  • 0Henk 'm!

  • amx
  • Registratie: December 2007
  • Laatst online: 15:30
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.

  • DataGhost
  • Registratie: Augustus 2003
  • Laatst online: 10:39

DataGhost

iPL dev

@jeroeningen is hier nog iets uitgekomen?
Pagina: 1



Google Pixel 7 Sony WH-1000XM5 Apple iPhone 14 Samsung Galaxy Watch5, 44mm Sonic Frontiers Samsung Galaxy Z Fold4 Insta360 X3 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee