Wat REMOTE_ADDR van PHP je achter een VPN werkelijk vertelt
Het is een waarde die je webserver heeft aangeleverd, geen blik in de tunnel. Loop het aanvraagpad na, controleer wie het mag herschrijven en houd identiteit in de applicatie.
Iemand vraagt waarom een VPN-gebruiker in het applicatielogboek opduikt met een adres dat bij de gateway hoort, of met een adres dat na de lunch is veranderd. Het antwoord begint bij wat die waarde is: een invoer die de webserver in de aanvraagomgeving heeft gezet. Het is geen opvraging in de tunnel, geen certificaatidentiteit en geen belofte dat het nummer bij één persoon hoort. Wie het als een van die drie leest, krijgt zelfverzekerde antwoorden die op verschillende manieren fout zijn.
De waarde komt van de server, niet uit de tunnel
PHP ontvangt de aanvraagomgeving van wat het script heeft uitgevoerd. De naslag over PHP-servervariabelen beschrijft deze invoer als door de webserver gemaakt, met een beschikbaarheid die afhangt van hoe de aanvraag binnenkwam.
Een script dat als commandoregel-hook van de VPN draait, is een volledig andere uitvoeringscontext. Het heeft geen webaanvraag, geen clientsocket en geen REMOTE_ADDR, en daarom levert gekopieerde webcode in een hook lege waarden op in plaats van verkeerde. De hook heeft zijn eigen omgeving, gevuld door de daemon, en die is apart gedocumenteerd. Daar naar REMOTE_ADDR grijpen is grijpen naar een variabele die nooit is gezet.
Houd dat onderscheid voor ogen voordat je twee logboeken vergelijkt. Misschien vergelijk je een pagina-aanvraag met een hook, en dat is helemaal geen vergelijking. Controleer eerst de uitvoeringscontext en daarna het adres.
Loop het aanvraagpad na voordat je het nummer vertrouwt
Het gerapporteerde adres is de peer van de verbinding die de webserver zag. Zet iets tussen de client en die server en de peer verandert. Vertaling, terminatie en balancing schuiven elk de waarneming een hop verder van de gebruiker.
Vier gangbare paden leveren vier verschillende waarnemingen op.
| Path to the listener | What can be reported |
|---|---|
| Client routed straight to the private listener, no translation | The client's tunnel address |
| Gateway translates the source before forwarding | The gateway's translated address |
| Reverse proxy terminates the client and opens its own backend connection | The proxy's backend address |
| Load balancer in front of two proxies | Whichever hop the server treats as its peer |
Schrijf het pad op met de naam van de bestemming, de adresfamilie en elk vertaalpunt. Zonder die kaart zien een juiste en een onjuiste waarde er in een logregel identiek uit. Twee regels diagram besparen een middag discussie.
Vervanging gebeurt alleen waar die is geconfigureerd
Een server of framework kan het clientadres bewust vervangen. De remote-IP-module van Apache en de real-IP-module van NGINX doen dat allebei, en de waarde die PHP ontvangt hangt af van die configuratie plus de parameters die aan de scripthandler worden meegegeven.
REMOTE_ADDR is dus niet universeel de onaangetaste TCP-peer. Het is de peer zoals de server die na toepassing van zijn eigen beleid heeft willen rapporteren. Dat onderscheid bepaalt of de waarde bewijs of versiering is.
Vraag de servereigenaar welk veld in deze installatie gezaghebbend is en hoe de oorspronkelijke peer bewaard blijft wanneer er wordt vervangen. Kan niemand dat beantwoorden, dan is het logboek nog nergens bewijs van.
Lees doorstuurheaders niet op goed vertrouwen
Een aanroeper kan zelf doorstuurheaders meesturen. De eerste komma-gescheiden invoer als geverifieerd gebruikersadres behandelen, is besluiten iedereen te geloven die verbinding maakt, precies het tegenovergestelde van waar de header voor dient. De header beschrijft een keten, en alleen een vertrouwde laag kan voor die keten instaan.
Gebruik de trusted-proxy-ondersteuning van de server of het framework met de werkelijke proxyketen geconfigureerd, en laat die waarden van bronnen buiten die keten weggooien. Handmatig geschreven parsing is waar de meeste interessante fouten zitten.
Een door een proxy gerapporteerd adres verandert ook niet de pakketbron die een bovenliggende firewall ziet. Houd HTTP-metadata en netwerkfiltering als afzonderlijke waarnemingen, want ze beantwoorden verschillende vragen.
Gebruik applicatie-identiteit voor beslissingen
Voor toegang tot de gegevens van een gebruiker vertrouw je op de geauthenticeerde principal en op de autorisatieregels van de applicatie. Een intern adres kan opnieuw worden toegewezen, en één vertaald adres kan voor honderden gelijktijdige gebruikers staan. Geen van beide eigenschappen kan een adrescontrole repareren.
Als de operatie een aanvraag aan een VPN-sessie moet koppelen, verbind dan het waargenomen adres en de tijdstempel met de gezaghebbende sessiegegevens volgens het vertaalmodel dat je hebt gedocumenteerd. Dat levert een verdedigbare associatie op; een adres alleen niet.
Log voor diagnose de paar velden die je nodig hebt in plaats van de hele serverarray, die headers en authenticatiemateriaal kan bevatten. De bruikbare conclusie zegt wat deze waarde in deze installatie betekent, niet welke waarde het meest op een client lijkt.