[squid-users] Multi-clients VPS - Authentication been shared.
NgTech LTD
ngtech1ltd at gmail.com
Fri Nov 19 09:06:41 UTC 2021
I have created an example how to use and match usernames to
tcp_outgoing_ports
https://github.com/elico/vagrant-squid-outgoing-addresses
its better to use a single port with different user names (if possible).
Let me know what do you think about the solution I am offering and if the
example is understandable.
Eliezer
בתאריך יום ה׳, 18 בנוב׳ 2021, 22:56, מאת Graminsta <
marcelorodrigo at graminsta.com.br>:
> 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
> <http://lists.squid-cache.org/pipermail/squid-users/attachments/20211116/69fb0a22/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
> <http://lists.squid-cache.org/pipermail/squid-users/attachments/20211116/5b31cc34/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
> *******************************************
>
> _______________________________________________
> 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/20211119/e3693b49/attachment-0001.htm>
More information about the squid-users
mailing list