<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Menlo-Regular;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi Carlos,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Correct, but that’s my problem. There are only two IPs in XFF: the original sender (and thus the one that can be spoofed) and the ALB’s IP, which is basically useless. I realize I can’t trust the first IP, but the client IP being the ALB
doesn’t help because I need to restrict by the actual source IP, which apparently (unless AWS support tells me differently) I can’t actually know for sure once the request is behind the ALB. If that is the case, then I’ll definitely have to go back to the
two ALB solution since then the special Varnish ACL can be handled once again by the ALB’s SG. I don’t like having two ALBs to manage, but it seems it’s probably the only way to handle this situation.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Justin<o:p></o:p></p>
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Carlos Abalde <carlos.abalde@gmail.com> <br>
<b>Sent:</b> Thursday, August 19, 2021 1:35 PM<br>
<b>To:</b> Justin Lloyd <justinl@arena.net><br>
<b>Cc:</b> varnish-misc@varnish-cache.org<br>
<b>Subject:</b> Re: Varnish and AWS ALBs<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi Justin,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">You cannot rely on the first IP in XFF (I guess you're doing that at the moment), but you can rely on the next-to-last. The last one is added to XFF by Varnish before entering 'vcl_recv', and the next-to-last is added by the ALB. That's
the client IP as seen by the ALB and cannot be forged by clients.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Best,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">--<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Carlos Abalde<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On 19 Aug 2021, at 22:11, Justin Lloyd <<a href="mailto:justinl@arena.net">justinl@arena.net</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hi all,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Is anyone else running Varnish behind AWS ALBs? I just encountered an issue today with how I have been using X-Forwarded-For to check against a Varnish ACL in that is more restrictive than the ALB’s security group, but I realized the hard
way that since X-Forwarded-For can be arbitrarily set, a malicious actor can set it to an address that is permitted by the Varnish ACL, whether through guessing or other knowledge. Since Varnish gets XFF from the ALB, which in turn trusts existing XFF headers,
you can’t then really trust client.ip since it’s just taken from XFF. Unless I’m missing something...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I’ve opened a support case with AWS to see if there’s a way to configure an ALB to not trust XFF and use the IP from the original TCP connection, but I’m not hopeful. I’ll likely have to go back to using two ALBs rather than one relatively
open one and one with a Varnish ACL for tigher controls to a certain subset of the web sites behind the single ALB.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Justin<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Menlo-Regular",serif">_______________________________________________<br>
varnish-misc mailing list<br>
</span><a href="mailto:varnish-misc@varnish-cache.org"><span style="font-size:10.5pt;font-family:"Menlo-Regular",serif">varnish-misc@varnish-cache.org</span></a><span style="font-size:10.5pt;font-family:"Menlo-Regular",serif"><br>
</span><a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc"><span style="font-size:10.5pt;font-family:"Menlo-Regular",serif">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>