<div dir="ltr"><div>Hi Justin,</div><div><br></div><div>The URL you won't get, since it comes after the bad method, so varnish bails out before that. The IP you have in the session information. Update your command to</div><div><br></div><div>    
varnishlog -q 'RespReason ~ "Bad Request"'</div><div><br></div><div>However, the reported IP will most likely be the ALB's, since it's the one sending you the request.</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br></div><div>Guillaume Quintard<br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 16, 2024 at 10:01 AM Justin Lloyd <<a href="mailto:justinl@arena.net">justinl@arena.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I got a response but it hasn't been helpful so far, basically just saying "look at ALB an WAF logs". The problem is that the varnishlog output doesn't give me enough to use to filter the WAF logs (ALB logging is currently not enabled), and even during 1 minute the number of requests is too much to filter through via the AWS console (and I don't yet have a good system for parsing the actual logs via Splunk or some other tool). Is there any way, for example, to get Varnish to display the IP and/or URL requested in the type of bad request output I showed in my original message? The command I used for that output was just<br>
<br>
varnishlog -q 'RespReason ~ "Bad Request"'<br>
<br>
Thanks,<br>
Justin<br>
<br>
-----Original Message-----<br>
From: varnish-misc <varnish-misc-bounces+justinl=<a href="mailto:arena.net@varnish-cache.org" target="_blank">arena.net@varnish-cache.org</a>> On Behalf Of Justin Lloyd<br>
Sent: Tuesday, July 16, 2024 6:28 AM<br>
To: <a href="mailto:geoff@uplex.de" target="_blank">geoff@uplex.de</a>; Guillaume Quintard <<a href="mailto:guillaume.quintard@gmail.com" target="_blank">guillaume.quintard@gmail.com</a>><br>
Cc: <a href="mailto:varnish-misc@varnish-cache.org" target="_blank">varnish-misc@varnish-cache.org</a><br>
Subject: RE: 400 Bad Request and whitespace in headers<br>
<br>
> That should be intelligible to WAF support, without any reference to Varnish at all.<br>
<br>
I would hope so, I just wanted to cover all the bases.<br>
<br>
I do have a number of managed WAF rulesets in use, but maybe there's one that would cover this particular issue. I would think this should be checked for in all cases, but perhaps not. Hopefully Support can help explain why these would be getting through.<br>
<br>
As for the additional work, there is so much garbage that still gets through, despite my best efforts with the WAF configuration so far, the more obvious stuff I can reasonably block, the better.<br>
<br>
I appreciate the feedback! I'll respond once I get more info from Support, especially regarding the nul byte issue.<br>
<br>
Justin<br>
<br>
-----Original Message-----<br>
From: Geoff Simmons <<a href="mailto:geoff@uplex.de" target="_blank">geoff@uplex.de</a>><br>
Sent: Tuesday, July 16, 2024 1:19 AM<br>
To: Justin Lloyd <<a href="mailto:justinl@arena.net" target="_blank">justinl@arena.net</a>>; Guillaume Quintard <<a href="mailto:guillaume.quintard@gmail.com" target="_blank">guillaume.quintard@gmail.com</a>><br>
Cc: <a href="mailto:varnish-misc@varnish-cache.org" target="_blank">varnish-misc@varnish-cache.org</a><br>
Subject: Re: 400 Bad Request and whitespace in headers<br>
<br>
On 7/16/24 03:15, Justin Lloyd wrote:<br>
><br>
> I meant blocking them at the AWS WAF, before they even get to any of<br>
> the web servers, i.e. less work for Varnish. I'd need to get the raw<br>
> headers and I wasn't having luck with that so far in the WAF<br>
> CloudTrail logs, so I've opened up a support case about it, but I was<br>
> hoping to possibly get some insight here, as well, since I don't know<br>
> whether the WAF support specialists will know much about using Varnish.<br>
<br>
 From what you've described, there were evidently requests with whitespace in header field names, a violation of HTTP syntax. That should be intelligible to WAF support, without any reference to Varnish at all.<br>
<br>
Why isn't a WAF rejecting requests like that by default?<br>
<br>
The invalid header names, and also your previous Varnish log excerpt showing "GET" followed by a nul byte, have the whiff of someone attempting a request smuggling attack. But it could be just a de-synchronized HTTP client. Either way, I would have expected a WAF to filter such requests, without having to ask support.<br>
<br>
And to agree with what Guillaume said, Varnish is not getting much additional work when it rejects those requests. The one in your previous example was probably taken care of in single-digit microseconds. It is true that the client connection would be spared if the request hadn't been forwarded at all. And it helps to use connections efficiently at a heavily loaded site.<br>
<br>
<br>
Best,<br>
Geoff<br>
--<br>
** * * UPLEX - Nils Goroll Systemoptimierung<br>
<br>
Scheffelstraße 32<br>
22301 Hamburg<br>
<br>
Tel +49 40 2880 5731<br>
Mob +49 176 636 90917<br>
Fax +49 40 42949753<br>
<br>
<a href="http://uplex.de/" rel="noreferrer" target="_blank">http://uplex.de/</a><br>
<br>
_______________________________________________<br>
varnish-misc mailing list<br>
<a href="mailto:varnish-misc@varnish-cache.org" target="_blank">varnish-misc@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc" rel="noreferrer" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc</a><br>
</blockquote></div>