[squid-users] Multi-clients VPS - Authentication been shared.

Thu Nov 18 20:54:26 UTC 2021

Tks for the answers.

Considerations:

1- "Please note that you are allowing authenticated clients to send traffic
to unsafe ports. For example, they can CONNECT to non-SSL ports. You may
want to reorder the above rules if that is not what you want."

ANSWER:
Tks for the advice, I already had it changed.

2- "However, you should also ask yourself another question: "Why am I using
multiple http_ports if all I care about is who uses which
tcp_outgoing_address?". The listening ports have virtually nothing to do
with tcp_outgoing_address..."

ANSWER:
Because I have to route each http_port to specific tcp_outgoing_address.
I have several customers per VPS.
Each one uses like 10 different ports to direct connections through
different IPv6s.

3- "Use http_access to deny authenticated users connected to wrong ports."

ANSWER:
So, in this scenario, how can I prevent users in the same users list to
access ports that not belong to them.
How to deny it in http_access rules?

Marcelo

-----Mensagem original-----
De: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] Em nome
de squid-users-request at lists.squid-cache.org
Enviada em: terça-feira, 16 de novembro de 2021 15:23
Para: squid-users at lists.squid-cache.org
Assunto: squid-users Digest, Vol 87, Issue 19

Send squid-users mailing list submissions to
	squid-users at lists.squid-cache.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.squid-cache.org/listinfo/squid-users
or, via email, send a message with subject or body 'help' to
	squid-users-request at lists.squid-cache.org

You can reach the person managing the list at
	squid-users-owner at lists.squid-cache.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of squid-users digest..."

Today's Topics:

   1. Multi-clients VPS - Authentication been shared. (Graminsta)
   2. Re: Too many ERROR: Collapsed forwarding queue overflow for
      kid2 at 1024 items (Lou?ansk? Luk??)
   3. Re: Stable Squid Version for production on Linux (David Touzeau)
   4. Re: Too many ERROR: Collapsed forwarding queue overflow for
      kid2 at 1024 items (Alex Rousskov)
   5. Re: Multi-clients VPS - Authentication been shared.
      (Alex Rousskov)

----------------------------------------------------------------------

Message: 1
Date: Tue, 16 Nov 2021 13:53:52 -0300
From: "Graminsta" <marcelorodrigo at graminsta.com.br>
To: <squid-users at lists.squid-cache.org>
Subject: [squid-users] Multi-clients VPS - Authentication been shared.
Message-ID: <005e01d7db0a$8ab2ab80$a0180280$@graminsta.com.br>
Content-Type: text/plain; charset="us-ascii"

Hello friends,

I'm using these user authentication lines in squid.conf based on user's
authentication list:

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/users

auth_param basic children 5

auth_param basic realm Squid proxy-caching web server

auth_param basic credentialsttl 2 hours

auth_param basic casesensitive off

http_access allow localhost

acl clientes proxy_auth REQUIRED

http_access allow clientes

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localhost manager

http_access deny manager

http_access deny all

#List of outgoings (all IPs are fake)

http_port 181.111.11.111:4000 name=3

acl ip3 myportname 3

tcp_outgoing_address 2804:1934:2E1::3D6 ip3

http_port 181.111.11.112:4001 name=4

acl ip4 myportname 4

tcp_outgoing_address 2804:1934:3a8::3D7 ip4

The problem is that everyone whom is in the users file are allow to use all
tcp_outgoing_address.

If a smarter client scans for open IPs and ports will be able to find these
outgoings.

How can I restrict each user to their own tcp_outgoing_address output?

Tks.

Marcelo

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.squid-cache.org/pipermail/squid-users/attachments/20211116/69f
b0a22/attachment-0001.htm>

------------------------------

Message: 2
Date: Tue, 16 Nov 2021 18:00:56 +0100
From: Lou?ansk? Luk?? <Loucansky.Lukas at kjj.cz>
To: "Alex Rousskov" <rousskov at measurement-factory.com>, "Squid Users"
	<squid-users at lists.squid-cache.org>
Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue
	overflow for kid2 at 1024 items
Message-ID:
	<72DD5D5CF661B5459DC08A060BF26B53010897A8 at kjj-server.KJJ.local>
Content-Type: text/plain;	charset="windows-1250"

Ok - I will try to backport it from that patch into the v5 tree I've
downloaded today. As we were using the mentioned build I came across these
new assertions:

2021/11/16 10:29:46 kid1| assertion failed: StoreMap.cc:241:
"anchorAt(anchorId).reading()"
2021/11/16 11:32:51 kid2| assertion failed: Transients.cc:221: "old == e"
2021/11/16 13:02:09 kid2| assertion failed: Transients.cc:221: "old == e"
2021/11/16 13:52:05 kid2| assertion failed: Transients.cc:221: "old == e"
2021/11/16 14:29:41 kid2| assertion failed: store.cc:1108: "store_status ==
STORE_PENDING"
2021/11/16 15:26:15 kid1| assertion failed: Transients.cc:221: "old == e"
2021/11/16 17:40:21 kid1| assertion failed: cbdata.cc:372: "c->locks > 0"
2021/11/16 17:40:44 kid1| assertion failed: cbdata.cc:115: "cookie ==
((long)this ^ Cookie)" 

(no config changes)

My 1w cache.log is about 300MB - without elevated debug options (debug
options ALL,1) - so it?s not easy to find something relevant with "9"
options enabled...

LL

-----Original Message-----
From: Alex Rousskov [mailto:rousskov at measurement-factory.com]
Sent: Tuesday, November 16, 2021 3:42 PM
To: Lou?ansk? Luk??; Squid Users
Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue
overflow for kid2 at 1024 items

On 11/16/21 4:38 AM, Lou?ansk? Luk?? wrote:
> is it going to be patched only in the v6 version? 

I hope the existing fix applies to v5 cleanly, and I am ready to help with
backporting if it does not. Beyond that, it is in the maintainer hands. I
cannot predict whether or when the fix will be officially merged into v5
because I do not understand how those decisions are made.

> Anyway - in the morning I run debug with 20,9 to see:
> ...
> 2021/11/16 09:02:06.496 kid2| assertion failed: Transients.cc:221: "old ==
e"

Unfortunately, I cannot see the cause of the assertion in this short/partial
trace -- the problematic actions happened before the trace or were not
logged during the trace.

Patching your Squid with commit 5210df4 is the best next step IMO. If that
patch does not help, then there are probably other bugs that we need to fix
in v5 (at least).

HTH,

Alex.

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov at measurement-factory.com]
> Sent: Monday, November 15, 2021 5:17 PM
> To: Squid Users
> Cc: Lou?ansk? Luk??
> Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue 
> overflow for kid2 at 1024 items
> 
> On 11/15/21 7:43 AM, Lou?ansk? Luk?? wrote:
> 
>> 2021/11/14 10:13:30 kid2| assertion failed: Transients.cc:221: "old == e"
>> 2021/11/15 08:37:36 kid2| assertion failed: Transients.cc:221: "old == e"
>> 2021/11/15 11:54:14 kid1| assertion failed: Transients.cc:221: "old == e"
>> 2021/11/15 12:16:27 kid1| assertion failed: Transients.cc:221: "old == e"
> 
> I recommend ignoring queue overflows until the above assertions are fixed
because worker deaths cause queue overflows. Your Squid is buggy, and those
bugs essentially cause queue overflows.
> 
> The assertion itself is known as Bug 5134:
> https://bugs.squid-cache.org/show_bug.cgi?id=5134
> 
> That bug has a speculative fix (master/v6 commit 5210df4). Please try it
if you can.
> 
> 
> HTH,
> 
> Alex.
> 
> 
>> -----Original Message-----
>> From: Alex Rousskov [mailto:rousskov at measurement-factory.com]
>> Sent: Friday, November 12, 2021 5:24 PM
>> To: Lou?ansk? Luk??; squid-users at lists.squid-cache.org
>> Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue 
>> overflow for kid2 at 1024 items
>>
>> On 11/11/21 10:19 AM, Lou?ansk? Luk?? wrote:
>>
>>> recently I'm facing too many ERROR: Collapsed forwarding queue 
>>> overflow for kid2 at 1024 items lines in my Squid 5.2 log files.
>>
>> We see those overflows when kids die. Do you see any FATAL messages,
assertions, or similar deadly errors in cache.log?
>>
>>
>>> Could someone elaborate how the queue is filled - what is clogging it?
>>
>> The sender/writer sends messages faster than the recipient/reader is 
>> reading them, eventually exceeding the queue capacity (i.e. 1024 
>> messages). These messages are about Store entries that may need 
>> synchronization across workers. Each message is very sm
> all.
>>
>>
>>> I don't mind too much if I have to turn collapsed forwarding off
>>
>> Most likely, the problem is not tied to collapsed forwarding. These 
>> queues were used for collapsed forwarding when they were added, but 
>> they are used for regular traffic as well in modern SMP Squids. We 
>> need to change the queue names (and related code/m
> essage text) to reflect the expanded nature of these queues.
>>
>>
>> HTH,
>>
>> Alex.
>>

------------------------------

Message: 3
Date: Tue, 16 Nov 2021 18:33:30 +0100
From: David Touzeau <david at articatech.com>
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Stable Squid Version for production on
	Linux
Message-ID: <60b9c5c9-202c-ad3c-c90d-a78f45f6c89c at articatech.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hi,

For us it is Squid v4.17

Le 16/11/2021 ? 17:40, Graminsta a ?crit?:
>
> Hey folks ?;)
>
> What is the most stable squid version for production on Ubuntu 18 or 20?
>
> Marcelo
>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.squid-cache.org/pipermail/squid-users/attachments/20211116/5b3
1cc34/attachment-0001.htm>

------------------------------

Message: 4
Date: Tue, 16 Nov 2021 13:09:12 -0500
From: Alex Rousskov <rousskov at measurement-factory.com>
To: Lou?ansk? Luk?? <Loucansky.Lukas at kjj.cz>, Squid Users
	<squid-users at lists.squid-cache.org>
Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue
	overflow for kid2 at 1024 items
Message-ID:
	<369d5766-b6ab-f4cd-8cef-64b298d84638 at measurement-factory.com>
Content-Type: text/plain; charset=windows-1250

On 11/16/21 12:00 PM, Lou?ansk? Luk?? wrote:

> I will try to backport it from that patch into the v5 tree I've 
> downloaded today. As we were using the mentioned build I came across 
> these new assertions:

> 2021/11/16 10:29:46 kid1| assertion failed: StoreMap.cc:241:
"anchorAt(anchorId).reading()"
> 2021/11/16 11:32:51 kid2| assertion failed: Transients.cc:221: "old == e"
> 2021/11/16 14:29:41 kid2| assertion failed: store.cc:1108: "store_status
== STORE_PENDING"

I hope that at least some of the above assertions are fixed by master/v6
commit 5210df4.

> 2021/11/16 17:40:21 kid1| assertion failed: cbdata.cc:372: "c->locks > 0"
> 2021/11/16 17:40:44 kid1| assertion failed: cbdata.cc:115: "cookie ==
((long)this ^ Cookie)" 

This is probably an unrelated bug. I recommend filing a bug report in Squid
bugzilla and posting the corresponding "bt full" backtrace there.

Alex.

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov at measurement-factory.com]
> Sent: Tuesday, November 16, 2021 3:42 PM
> To: Lou?ansk? Luk??; Squid Users
> Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue 
> overflow for kid2 at 1024 items
> 
> On 11/16/21 4:38 AM, Lou?ansk? Luk?? wrote:
>> is it going to be patched only in the v6 version? 
> 
> I hope the existing fix applies to v5 cleanly, and I am ready to help with
backporting if it does not. Beyond that, it is in the maintainer hands. I
cannot predict whether or when the fix will be officially merged into v5
because I do not understand how those decisions are made.
> 
> 
>> Anyway - in the morning I run debug with 20,9 to see:
>> ...
>> 2021/11/16 09:02:06.496 kid2| assertion failed: Transients.cc:221: "old
== e"
> 
> Unfortunately, I cannot see the cause of the assertion in this
short/partial trace -- the problematic actions happened before the trace or
were not logged during the trace.
> 
> Patching your Squid with commit 5210df4 is the best next step IMO. If that
patch does not help, then there are probably other bugs that we need to fix
in v5 (at least).
> 
> 
> HTH,
> 
> Alex.
> 
> 
>> -----Original Message-----
>> From: Alex Rousskov [mailto:rousskov at measurement-factory.com]
>> Sent: Monday, November 15, 2021 5:17 PM
>> To: Squid Users
>> Cc: Lou?ansk? Luk??
>> Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding queue 
>> overflow for kid2 at 1024 items
>>
>> On 11/15/21 7:43 AM, Lou?ansk? Luk?? wrote:
>>
>>> 2021/11/14 10:13:30 kid2| assertion failed: Transients.cc:221: "old ==
e"
>>> 2021/11/15 08:37:36 kid2| assertion failed: Transients.cc:221: "old ==
e"
>>> 2021/11/15 11:54:14 kid1| assertion failed: Transients.cc:221: "old ==
e"
>>> 2021/11/15 12:16:27 kid1| assertion failed: Transients.cc:221: "old ==
e"
>>
>> I recommend ignoring queue overflows until the above assertions are fixed
because worker deaths cause queue overflows. Your Squid is buggy, and those
bugs essentially cause queue overflows.
>>
>> The assertion itself is known as Bug 5134:
>> https://bugs.squid-cache.org/show_bug.cgi?id=5134
>>
>> That bug has a speculative fix (master/v6 commit 5210df4). Please try it
if you can.
>>
>>
>> HTH,
>>
>> Alex.
>>
>>
>>> -----Original Message-----
>>> From: Alex Rousskov [mailto:rousskov at measurement-factory.com]
>>> Sent: Friday, November 12, 2021 5:24 PM
>>> To: Lou?ansk? Luk??; squid-users at lists.squid-cache.org
>>> Subject: Re: [squid-users] Too many ERROR: Collapsed forwarding 
>>> queue overflow for kid2 at 1024 items
>>>
>>> On 11/11/21 10:19 AM, Lou?ansk? Luk?? wrote:
>>>
>>>> recently I'm facing too many ERROR: Collapsed forwarding queue 
>>>> overflow for kid2 at 1024 items lines in my Squid 5.2 log files.
>>>
>>> We see those overflows when kids die. Do you see any FATAL messages,
assertions, or similar deadly errors in cache.log?
>>>
>>>
>>>> Could someone elaborate how the queue is filled - what is clogging it?
>>>
>>> The sender/writer sends messages faster than the recipient/reader is 
>>> reading them, eventually exceeding the queue capacity (i.e. 1024 
>>> messages). These messages are about Store entries that may need 
>>> synchronization across workers. Each message is very sm
>> all.
>>>
>>>
>>>> I don't mind too much if I have to turn collapsed forwarding off
>>>
>>> Most likely, the problem is not tied to collapsed forwarding. These 
>>> queues were used for collapsed forwarding when they were added, but 
>>> they are used for regular traffic as well in modern SMP Squids. We 
>>> need to change the queue names (and related code/m
>> essage text) to reflect the expanded nature of these queues.
>>>
>>>
>>> HTH,
>>>
>>> Alex.
>>>

------------------------------

Message: 5
Date: Tue, 16 Nov 2021 13:23:00 -0500
From: Alex Rousskov <rousskov at measurement-factory.com>
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Multi-clients VPS - Authentication been
	shared.
Message-ID:
	<7d3ac49b-d2f7-fffa-cb2d-e2377b8ada5e at measurement-factory.com>
Content-Type: text/plain; charset=windows-1252

On 11/16/21 11:53 AM, Graminsta wrote:
> Hello friends,
> 
> ?
> 
> I'm using these user authentication lines in squid.conf based on 
> user?s authentication list:
> 
> ?
> 
> auth_param basic program /usr/lib/squid/basic_ncsa_auth 
> /etc/squid/users
> 
> auth_param basic children 5
> 
> auth_param basic realm Squid proxy-caching web server
> 
> auth_param basic credentialsttl 2 hours
> 
> auth_param basic casesensitive off
> 
> ?
> 
> http_access allow localhost
> 
> acl clientes proxy_auth REQUIRED
> 
> http_access allow clientes
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost manager
> http_access deny manager
> http_access deny all

Please note that you are allowing authenticated clients to send traffic to
unsafe ports. For example, they can CONNECT to non-SSL ports. You may want
to reorder the above rules if that is not what you want.

> #List of outgoings (all IPs are fake)
> 
> http_port 181.111.11.111:4000 name=3
> acl ip3 myportname 3
> tcp_outgoing_address 2804:1934:2E1::3D6 ip3
> 
> ?
> 
> http_port 181.111.11.112:4001 name=4
> acl ip4 myportname 4
> tcp_outgoing_address 2804:1934:3a8::3D7 ip4
> 
> ?
> 
> The problem is that everyone whom is in the users file are allow to 
> use all tcp_outgoing_address.
> 
> If a smarter client scans for open IPs and ports will be able to find 
> these outgoings.
> 
> ?
> 
> How can I restrict each user to their own tcp_outgoing_address output?

I suspect you are asking the wrong question. A better question is "How do I
restrict each user to their own http_port?". The answer is "Use http_access
to deny authenticated users connected to wrong ports."

However, you should also ask yourself another question: "Why am I using
multiple http_ports if all I care about is who uses which
tcp_outgoing_address?". The listening ports have virtually nothing to do
with tcp_outgoing_address...

I suspect you want something like this instead:

    http_port ...
    tcp_outgoing_address ...:3D01 user1
    tcp_outgoing_address ...:3D02 user2
    tcp_outgoing_address ...:3D03 user3
    ...

...where userN is an ACL that matches an authenticated user N.

HTH,

Alex.

------------------------------

Subject: Digest Footer

_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

------------------------------

End of squid-users Digest, Vol 87, Issue 19
*******************************************