Re: [squid-users] Introducing delay to HTTP 407 responses

[Alex Rousskov]

On 10/05/2016 05:49 PM, squid-us...@filter.luko.org wrote:
>> See "early return"
>> statements in clientReplyContext::processReplyAccess(), including:
>>
>>> /** Don't block our own responses or HTTP status messages */
>>> if (http->logType.oldType == LOG_TCP_DENIED ||
>>> http->logType.oldType == LOG_TCP_DENIED_REPLY ||
>>> alwaysAllowResponse(reply->sline.status())) {
>>> headers_sz = reply->hdr_sz;
>>> processReplyAccessResult(ACCESS_ALLOWED);
>>> return;
>>> }

> It would be great if there was a way to slow
> down 407 responses; at the moment the only workaround I can think of
> is to write a log-watching script to maintain a list of offending
> IP/domain pairs, then write a helper to use that data to introduce
> delay when the request is first received (via http_access and the
> !all trick).  If anyone has a better option, I'm all ears.

An alternative idea: Change clientReplyContext::processReplyAccess() and
related code so that the http_reply_access ACL is always checked but,
under the conditions quoted above, the result of that check is forced to
be interpreted as ACCESS_ALLOWED.

This alternative requires a little bit of Squid development and testing,
of course, and I am not sure such a trick can be officially accepted.

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Introducing delay to HTTP 407 responses

[squid-users]

Alex,

> However, there is a difference between my August tests and this thread.
> My tests were for a request parsing error response. Access denials do not
> reach the same http_reply_access checks! See "early return"
> statements in clientReplyContext::processReplyAccess(), including:
> 
> > /** Don't block our own responses or HTTP status messages */
> > if (http->logType.oldType == LOG_TCP_DENIED ||
> > http->logType.oldType == LOG_TCP_DENIED_REPLY ||
> > alwaysAllowResponse(reply->sline.status())) {
> > headers_sz = reply->hdr_sz;
> > processReplyAccessResult(ACCESS_ALLOWED);
> > return;
> > }
> 
> I am not sure whether avoiding http_reply_access in such cases is a
> bug/misfeature or the right behavior. As any exception, it certainly
> creates problems for those who want to [ab]use http_reply_access as a
> delay hook. FWIW, Squid had this exception since 2007:

Thanks, makes sense.  It would be great if there was a way to slow down 407 
responses; at the moment the only workaround I can think of is to write a 
log-watching script to maintain a list of offending IP/domain pairs, then write 
a helper to use that data to introduce delay when the request is first received 
(via http_access and the !all trick).  If anyone has a better option, I'm all 
ears.

Luke


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Introducing delay to HTTP 407 responses

[Alex Rousskov]

On 10/04/2016 06:20 AM, Amos Jeffries wrote:
> On 5/10/2016 12:47 a.m., squid-users wrote:

>> I set this up as you suggested, then triggered a 407 response from
>> the cache.  It seems that way; I couldn't see aclMatchHTTPStatus or
>> http-response-407 in the log


> Strange. I was sure Alex did some tests recently and proved that even
> internally generated responses get http_reply_access applied to them.


Yes, see
http://lists.squid-cache.org/pipermail/squid-users/2016-August/012048.html

However, there is a difference between my August tests and this thread.
My tests were for a request parsing error response. Access denials do
not reach the same http_reply_access checks! See "early return"
statements in clientReplyContext::processReplyAccess(), including:

> /** Don't block our own responses or HTTP status messages */
> if (http->logType.oldType == LOG_TCP_DENIED ||
> http->logType.oldType == LOG_TCP_DENIED_REPLY ||
> alwaysAllowResponse(reply->sline.status())) {
> headers_sz = reply->hdr_sz;
> processReplyAccessResult(ACCESS_ALLOWED);
> return;
> }

I am not sure whether avoiding http_reply_access in such cases is a
bug/misfeature or the right behavior. As any exception, it certainly
creates problems for those who want to [ab]use http_reply_access as a
delay hook. FWIW, Squid had this exception since 2007:

> revno: 8474
> committer: hno
> branch nick: HEAD
> timestamp: Thu 2007-08-30 19:03:42 +
> message:
>   Bug #2028: FATAL error if using http_reply_access in combination with 
> authentication
>   
>   The attached patch bypasses http_reply_access on access denied messages
>   generated by this Squid, and also optimizes processing slightly in the
>   common case of not using any http_reply_access rules at all.


HTH,

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Introducing delay to HTTP 407 responses

[squid-users]

> > I set this up as you suggested, then triggered a 407 response from the
> cache.  It seems that way; I couldn't see aclMatchHTTPStatus or http-
> response-407 in the log:
> >
> 
> Strange. I was sure Alex did some tests recently and proved that even
> internally generated responses get http_reply_access applied to them.
> Yet no sign of that in your log.
> 
> Is this a very old Squid version?

It's a recent Squid version - 3.5.20 on CentOS 6, built from the SRPM kindly 
provided by Eliezer.

> Or are the "checking http_reply_access" lines just later in the log than
> your snippet covered?

There was nothing more in the log previously posted at the point the 407 
response was returned to the client.

That log did have a lot of other stuff in it though.  Using a much simpler 
squid.conf (attached), I tested for differences in authenticated vs 
unauthenticated requests, when "http_reply_access deny all" is in place.  When 
credentials are supplied, a http/403 (forbidden) response is provided, as you 
would expect.  But when credentials are not supplied, a http/407 response is 
provided.  The divergence seems to start around line 31 in cache_noauth.log:

Checklist.cc(63) markFinished: 0x331e4a8 answer AUTH_REQUIRED for 
AuthenticateAcl exception

Perhaps when answer=AUTH_REQUIRED (line 35), http_reply_access is not checked?  
Another difference is that Acl.cc(158) reports async when an authenticated 
request is in place, but not otherwise.  If someone could give me some pointers 
where to look in the source, I can start digging to see if I can find out more.

Luke



cache_auth.log
Description: Binary data


cache_noauth.log
Description: Binary data


squid.conf
Description: Binary data
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Introducing delay to HTTP 407 responses

[Alex Rousskov]

On 10/04/2016 05:18 AM, Amos Jeffries wrote:
> On 4/10/2016 11:53 p.m., squid-us...@filter.luko.org wrote:
>> Would the developers be open to adding a configuration-based throttle to 
>> authentication responses

> This helper is the mechanism that we accepted. Anything else would be
> far less useful.

For the record, I agree that the external ACL is the right solution for
now. However, supporting a general built-in "delay" ACL would be a
useful feature worth accepting IMO.

I know this does not help with the problem at hand. I just wanted to
make a note that there is certainly room for an improvement here if
somebody wants to work on it; the "anything else" phrase was too harsh.

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Introducing delay to HTTP 407 responses

[Amos Jeffries]

On 5/10/2016 12:47 a.m., squid-users wrote:
> Amos,
> 
>> This helper is the mechanism that we accepted. Anything else would be far
>> less useful.
> 
> Makes sense.
> 
>> I think the results you are getting show that the http_status ACL is not
>> working properly.
>>
>> Can you get a "debug_options 28,5" cache.log trace and see if
>> "aclMatchHTTPStatus" is matching anything or "http-response-407" even
>> being tested?
> 
> I set this up as you suggested, then triggered a 407 response from the cache. 
>  It seems that way; I couldn't see aclMatchHTTPStatus or http-response-407 in 
> the log:
> 

Strange. I was sure Alex did some tests recently and proved that even
internally generated responses get http_reply_access applied to them.
Yet no sign of that in your log.

Is this a very old Squid version?

Or are the "checking http_reply_access" lines just later in the log than
your snippet covered?

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Introducing delay to HTTP 407 responses

[squid-users]

Amos,

> This helper is the mechanism that we accepted. Anything else would be far
> less useful.

Makes sense.

> I think the results you are getting show that the http_status ACL is not
> working properly.
> 
> Can you get a "debug_options 28,5" cache.log trace and see if
> "aclMatchHTTPStatus" is matching anything or "http-response-407" even
> being tested?

I set this up as you suggested, then triggered a 407 response from the cache.  
It seems that way; I couldn't see aclMatchHTTPStatus or http-response-407 in 
the log:

2016/10/04 22:37:12.656 kid1| 28,3| Checklist.cc(70) preCheck: 0x7ffcaaa6a540 
checking fast rules
2016/10/04 22:37:12.656 kid1| 28,5| Checklist.cc(346) fastCheck: aclCheckFast: 
list: 0x1c3da68
2016/10/04 22:37:12.656 kid1| 28,5| Acl.cc(138) matches: checking snmp_access
2016/10/04 22:37:12.656 kid1| 28,5| Checklist.cc(400) bannedAction: Action 
'ALLOWED/0is not banned
2016/10/04 22:37:12.656 kid1| 28,5| Acl.cc(138) matches: checking snmp_access#1
2016/10/04 22:37:12.656 kid1| 28,5| Acl.cc(138) matches: checking localhost
2016/10/04 22:37:12.656 kid1| 28,3| Ip.cc(539) match: aclIpMatchIp: 
'127.0.0.1:34818' found
2016/10/04 22:37:12.656 kid1| 28,3| Acl.cc(158) matches: checked: localhost = 1
2016/10/04 22:37:12.656 kid1| 28,3| Acl.cc(158) matches: checked: snmp_access#1 
= 1
2016/10/04 22:37:12.656 kid1| 28,3| Acl.cc(158) matches: checked: snmp_access = 
1
2016/10/04 22:37:12.656 kid1| 28,3| Checklist.cc(63) markFinished: 
0x7ffcaaa6a540 answer ALLOWED for match
2016/10/04 22:37:12.656 kid1| 28,4| FilledChecklist.cc(66) ~ACLFilledChecklist: 
ACLFilledChecklist destroyed 0x7ffcaaa6a540
2016/10/04 22:37:12.656 kid1| 28,4| Checklist.cc(197) ~ACLChecklist: 
ACLChecklist::~ACLChecklist: destroyed 0x7ffcaaa6a540
2016/10/04 22:37:12.657 kid1| 28,3| Checklist.cc(70) preCheck: 0x7ffcaaa6a540 
checking fast rules
2016/10/04 22:37:12.657 kid1| 28,5| Checklist.cc(346) fastCheck: aclCheckFast: 
list: 0x1c3da68
2016/10/04 22:37:12.657 kid1| 28,5| Acl.cc(138) matches: checking snmp_access
2016/10/04 22:37:12.657 kid1| 28,5| Checklist.cc(400) bannedAction: Action 
'ALLOWED/0is not banned
2016/10/04 22:37:12.657 kid1| 28,5| Acl.cc(138) matches: checking snmp_access#1
2016/10/04 22:37:12.657 kid1| 28,5| Acl.cc(138) matches: checking localhost
2016/10/04 22:37:12.657 kid1| 28,3| Ip.cc(539) match: aclIpMatchIp: 
'127.0.0.1:34818' found
2016/10/04 22:37:12.657 kid1| 28,3| Acl.cc(158) matches: checked: localhost = 1
2016/10/04 22:37:12.657 kid1| 28,3| Acl.cc(158) matches: checked: snmp_access#1 
= 1
2016/10/04 22:37:12.657 kid1| 28,3| Acl.cc(158) matches: checked: snmp_access = 
1
2016/10/04 22:37:12.657 kid1| 28,3| Checklist.cc(63) markFinished: 
0x7ffcaaa6a540 answer ALLOWED for match
2016/10/04 22:37:12.657 kid1| 28,4| FilledChecklist.cc(66) ~ACLFilledChecklist: 
ACLFilledChecklist destroyed 0x7ffcaaa6a540
2016/10/04 22:37:12.657 kid1| 28,4| Checklist.cc(197) ~ACLChecklist: 
ACLChecklist::~ACLChecklist: destroyed 0x7ffcaaa6a540
2016/10/04 22:37:17.697 kid1| 28,3| Checklist.cc(70) preCheck: 0x7ffcaaa6a540 
checking fast rules
2016/10/04 22:37:17.697 kid1| 28,5| Checklist.cc(346) fastCheck: aclCheckFast: 
list: 0x1c3da68
2016/10/04 22:37:17.697 kid1| 28,5| Acl.cc(138) matches: checking snmp_access
2016/10/04 22:37:17.697 kid1| 28,5| Checklist.cc(400) bannedAction: Action 
'ALLOWED/0is not banned
2016/10/04 22:37:17.697 kid1| 28,5| Acl.cc(138) matches: checking snmp_access#1
2016/10/04 22:37:17.697 kid1| 28,5| Acl.cc(138) matches: checking localhost
2016/10/04 22:37:17.697 kid1| 28,3| Ip.cc(539) match: aclIpMatchIp: 
'127.0.0.1:34912' found
2016/10/04 22:37:17.697 kid1| 28,3| Acl.cc(158) matches: checked: localhost = 1
2016/10/04 22:37:17.697 kid1| 28,3| Acl.cc(158) matches: checked: snmp_access#1 
= 1
2016/10/04 22:37:17.697 kid1| 28,3| Acl.cc(158) matches: checked: snmp_access = 
1
2016/10/04 22:37:17.697 kid1| 28,3| Checklist.cc(63) markFinished: 
0x7ffcaaa6a540 answer ALLOWED for match
2016/10/04 22:37:17.697 kid1| 28,4| FilledChecklist.cc(66) ~ACLFilledChecklist: 
ACLFilledChecklist destroyed 0x7ffcaaa6a540
2016/10/04 22:37:17.697 kid1| 28,4| Checklist.cc(197) ~ACLChecklist: 
ACLChecklist::~ACLChecklist: destroyed 0x7ffcaaa6a540
2016/10/04 22:37:17.698 kid1| 28,3| Checklist.cc(70) preCheck: 0x7ffcaaa6a540 
checking fast rules
2016/10/04 22:37:17.698 kid1| 28,5| Checklist.cc(346) fastCheck: aclCheckFast: 
list: 0x1c3da68
2016/10/04 22:37:17.698 kid1| 28,5| Acl.cc(138) matches: checking snmp_access
2016/10/04 22:37:17.698 kid1| 28,5| Checklist.cc(400) bannedAction: Action 
'ALLOWED/0is not banned
2016/10/04 22:37:17.698 kid1| 28,5| Acl.cc(138) matches: checking snmp_access#1
2016/10/04 22:37:17.698 kid1| 28,5| Acl.cc(138) matches: checking localhost
2016/10/04 22:37:17.698 kid1| 28,3| Ip.cc(539) match: aclIpMatchIp: 
'127.0.0.1:34912' found
2016/10/04 22:37:17.698 kid1| 28,3| Acl.cc(158) matches: checked: localhost = 1
2016/10/04 22:37:17.698 kid1| 28,3| Acl.cc(158) matches: checked: snmp_access#1 
= 

Re: [squid-users] Introducing delay to HTTP 407 responses

[Amos Jeffries]

On 4/10/2016 11:53 p.m., squid-us...@filter.luko.org wrote:
> Eliezer,
> 
> Thankyou for your reply, I tried the following:
> 
>> Hey Luke,
>>
>> Try to use the next line instead:
>> external_acl_type delay ttl=1 negative_ttl=0 cache=0 %SRC %SRCPORT %URI 
>> /tmp/delay.pl
>>
>> And see what happens.
> 
> But it's not introducing a delay into the response.  Running strace across 
> the pid of each child helper doesn't show any activity across those processes 
> either.
> 

The purpose of that helper is to receive all lookups, and actively pause
responding to them. Having any TTL/cache values except "ttl=0
negative_ttl=0 cache=0" in those options bypasses the helper.


> I also tried the approach suggested by Amos:
> 
>> The outcome of that was a 'ext_delayer_acl helper in Squid-3.5
>>
>> 
>>
>> It works slightly differently to what was being discussed in the thread.
>> see the man page for details on how to configure it.
> 
> Using the following config:
> 
> external_acl_type delay concurrency=10 children-max=2 children-startup=1 
> children-idle=1 cache=10 %URI /tmp/ext_delayer_acl -w 1000 -d
> acl http-response-407 http_status 407
> acl delay-1sec external delay
> http_reply_access deny http-response-407 delay-1sec !all
> 
> Debug information from ext_delayer_acl is written to the cache log; I see the 
> processes start up but they are not hit with any requests by Squid.  I also 
> added %SRC %SRCPORT into the configuration, but that didn't seem to help 
> either.
> 
> Would the developers be open to adding a configuration-based throttle to 
> authentication responses, avoiding the need for an external helper?  Or 
> alternatively, is there another way to slow down auth responses?  It's 
> comprising about 90% of the log volume (450,000 requests/hr) in badly 
> affected sites at the moment.
> 

This helper is the mechanism that we accepted. Anything else would be
far less useful.

I think the results you are getting show that the http_status ACL is not
working properly.

Can you get a "debug_options 28,5" cache.log trace and see if
"aclMatchHTTPStatus" is matching anything or "http-response-407" even
being tested?

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Introducing delay to HTTP 407 responses

[squid-users]

Eliezer,

Thankyou for your reply, I tried the following:

> Hey Luke,
> 
> Try to use the next line instead:
> external_acl_type delay ttl=1 negative_ttl=0 cache=0 %SRC %SRCPORT %URI 
> /tmp/delay.pl
> 
> And see what happens.

But it's not introducing a delay into the response.  Running strace across the 
pid of each child helper doesn't show any activity across those processes 
either.

I also tried the approach suggested by Amos:

> The outcome of that was a 'ext_delayer_acl helper in Squid-3.5
> 
> 
> 
> It works slightly differently to what was being discussed in the thread.
> see the man page for details on how to configure it.

Using the following config:

external_acl_type delay concurrency=10 children-max=2 children-startup=1 
children-idle=1 cache=10 %URI /tmp/ext_delayer_acl -w 1000 -d
acl http-response-407 http_status 407
acl delay-1sec external delay
http_reply_access deny http-response-407 delay-1sec !all

Debug information from ext_delayer_acl is written to the cache log; I see the 
processes start up but they are not hit with any requests by Squid.  I also 
added %SRC %SRCPORT into the configuration, but that didn't seem to help either.

Would the developers be open to adding a configuration-based throttle to 
authentication responses, avoiding the need for an external helper?  Or 
alternatively, is there another way to slow down auth responses?  It's 
comprising about 90% of the log volume (450,000 requests/hr) in badly affected 
sites at the moment.

Luke


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Introducing delay to HTTP 407 responses

[Amos Jeffries]

On 14/09/2016 12:18 p.m., squid-us...@filter.luko.org wrote:
> Hi Squid users,
> 
> Seeking advice on how to slow down 407 responses to broken Apple & MS
> clients, which seem to retry at very short intervals and quickly fill the
> access.log with garbage.  The problem is very similar to this:
> 
> http://www.squid-cache.org/mail-archive/squid-users/201404/0326.html
> 

The outcome of that was a 'ext_delayer_acl helper in Squid-3.5



It works slightly differently to what was being discussed in the thread.
see the man page for details on how to configure it.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Introducing delay to HTTP 407 responses

[Eliezer Croitoru]

Hey Luke,

Try to use the next line instead:
external_acl_type delay ttl=1 negative_ttl=0 cache=0 %SRC %SRCPORT %URI 
/tmp/delay.pl

And see what happens.
I do not know why the helper is not delaying but if you have a specific logic I 
can convert one of my scripts to support concurrency and do this delay.

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of squid-us...@filter.luko.org
Sent: Wednesday, September 14, 2016 3:18 AM
To: squid-users@lists.squid-cache.org
Subject: [squid-users] Introducing delay to HTTP 407 responses

Hi Squid users,

Seeking advice on how to slow down 407 responses to broken Apple & MS
clients, which seem to retry at very short intervals and quickly fill the
access.log with garbage.  The problem is very similar to this:

http://www.squid-cache.org/mail-archive/squid-users/201404/0326.html

However the config below doesn't seem to slow down the response:

acl delaydomains dstdomain .live.net .apple.com
acl authresponse http_status 407
external_acl_type delay ttl=0 negative_ttl=0 cache=0 %SRC /tmp/delay.pl
acl delay external delay
http_reply_access deny delaydomains authresponse delay
http_reply_access allow all

The helper is never asked by Squid to process the request.  Just wondering
if http_status ACLs can be used in http_reply_access?

My other thinking, if this isn't possible, was to mark 407 responses with
clientside_tos so they could be delayed/throttled with tc or iptables.  Ie,

acl authresponse http_status 407
clientside_tos 0x20 authresponse

However, auth response packets don't get the desired tos markings.  Instead
the following message appears in cache.log:

2016/09/13 11:35:43 kid1| WARNING: authresponse ACL is used in context
without an HTTP response. Assuming mismatch.

After reviewing
http://lists.squid-cache.org/pipermail/squid-users/2016-May/010630.html it
seems like this has cropped up before.  The suggestion in that thread was to
exclude 407 responses from the access log.  Fortunately this works.  But I'm
wondering if there is a way to introduce delay into the 407 response itself?
Partly to minimise load associated with serving broken clients, and also to
maintain logging of actual intrusion attempts.  Any suggestions?

Luke


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Introducing delay to HTTP 407 responses

[Dan Charlesworth]

I just want to throw my support behind seeking a solution to this problem. 
Luke’s clearly considered it in way more detail than anyone so far, myself 
included.

The affects the squids under my purview every day.

Best,
Dan

> On 14 Sep. 2016, at 10:18 am, squid-us...@filter.luko.org wrote:
> 
> Hi Squid users,
> 
> Seeking advice on how to slow down 407 responses to broken Apple & MS
> clients, which seem to retry at very short intervals and quickly fill the
> access.log with garbage.  The problem is very similar to this:
> 
> http://www.squid-cache.org/mail-archive/squid-users/201404/0326.html
> 
> However the config below doesn't seem to slow down the response:
> 
> acl delaydomains dstdomain .live.net .apple.com
> acl authresponse http_status 407
> external_acl_type delay ttl=0 negative_ttl=0 cache=0 %SRC /tmp/delay.pl
> acl delay external delay
> http_reply_access deny delaydomains authresponse delay
> http_reply_access allow all
> 
> The helper is never asked by Squid to process the request.  Just wondering
> if http_status ACLs can be used in http_reply_access?
> 
> My other thinking, if this isn't possible, was to mark 407 responses with
> clientside_tos so they could be delayed/throttled with tc or iptables.  Ie,
> 
> acl authresponse http_status 407
> clientside_tos 0x20 authresponse
> 
> However, auth response packets don't get the desired tos markings.  Instead
> the following message appears in cache.log:
> 
> 2016/09/13 11:35:43 kid1| WARNING: authresponse ACL is used in context
> without an HTTP response. Assuming mismatch.
> 
> After reviewing
> http://lists.squid-cache.org/pipermail/squid-users/2016-May/010630.html it
> seems like this has cropped up before.  The suggestion in that thread was to
> exclude 407 responses from the access log.  Fortunately this works.  But I'm
> wondering if there is a way to introduce delay into the 407 response itself?
> Partly to minimise load associated with serving broken clients, and also to
> maintain logging of actual intrusion attempts.  Any suggestions?
> 
> Luke
> 
> 
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Introducing delay to HTTP 407 responses

[squid-users]

Hi Squid users,

Seeking advice on how to slow down 407 responses to broken Apple & MS
clients, which seem to retry at very short intervals and quickly fill the
access.log with garbage.  The problem is very similar to this:

http://www.squid-cache.org/mail-archive/squid-users/201404/0326.html

However the config below doesn't seem to slow down the response:

acl delaydomains dstdomain .live.net .apple.com
acl authresponse http_status 407
external_acl_type delay ttl=0 negative_ttl=0 cache=0 %SRC /tmp/delay.pl
acl delay external delay
http_reply_access deny delaydomains authresponse delay
http_reply_access allow all

The helper is never asked by Squid to process the request.  Just wondering
if http_status ACLs can be used in http_reply_access?

My other thinking, if this isn't possible, was to mark 407 responses with
clientside_tos so they could be delayed/throttled with tc or iptables.  Ie,

acl authresponse http_status 407
clientside_tos 0x20 authresponse

However, auth response packets don't get the desired tos markings.  Instead
the following message appears in cache.log:

2016/09/13 11:35:43 kid1| WARNING: authresponse ACL is used in context
without an HTTP response. Assuming mismatch.

After reviewing
http://lists.squid-cache.org/pipermail/squid-users/2016-May/010630.html it
seems like this has cropped up before.  The suggestion in that thread was to
exclude 407 responses from the access log.  Fortunately this works.  But I'm
wondering if there is a way to introduce delay into the 407 response itself?
Partly to minimise load associated with serving broken clients, and also to
maintain logging of actual intrusion attempts.  Any suggestions?

Luke


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users