Re: [squid-users] Protecting squid

[Amos Jeffries]

On 18/03/21 2:54 am, Ben Goz wrote:

Hi Amos,

Sounds interesting.

Maybe I should modify the external_acl_type to talk with internal API 
inside my system.


You do not need to modify any Squid code.

You provide a helper process to translate between Squid APIs and some 
internal system API. see 
 for details on the 
Squid APIs.


Though as I posted, there are likely already some helpers you can find 
(maybe bundled with Squid) which interface with your internal systems.



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

Re: [squid-users] Protecting squid

[Ben Goz]

By the help of God.


Hi Amos,

Sounds interesting.

Maybe I should modify the external_acl_type to talk with internal API 
inside my system.


Can you please point me to some code examples and documentation?

Also if you can please point me to squid code that invokes the external 
ACL program?


Thanks,

Ben

On 15/03/2021 15:27, Amos Jeffries wrote:

On 15/03/21 2:26 am, Ben Goz wrote:


Can I configure squid authentication TTL per only source IP and 
ignores other parameters so authentication will be requested only 
once in TTL for all the sessions?




Not with just authentication. You will need to use a slightly more 
complicated system involving an external_acl_type helper as well and 
switch to an SQL database auth system.



The idea for that is that you have a database of authenticated users 
with their last-known IP address.


 Your auth_param helper is changed to one which takes client IP 
address in the auth_param key_extras setting, and adds records to the 
SQL database before telling Squid the login is OK.


 Use an ext_sql_session_acl helper which takes IP address and checks 
the database to find the username who last authenticated from there. 
This needs to be checked and permit existing sessions before the auth 
helper.


The config looks something like this:


  external_acl_type ipuser negative_ttl=0 ttl=7200 %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] Protecting squid

[Amos Jeffries]

On 15/03/21 2:26 am, Ben Goz wrote:


Can I configure squid authentication TTL per only source IP and ignores 
other parameters so authentication will be requested only once in TTL 
for all the sessions?




Not with just authentication. You will need to use a slightly more 
complicated system involving an external_acl_type helper as well and 
switch to an SQL database auth system.



The idea for that is that you have a database of authenticated users 
with their last-known IP address.


 Your auth_param helper is changed to one which takes client IP address 
in the auth_param key_extras setting, and adds records to the SQL 
database before telling Squid the login is OK.


 Use an ext_sql_session_acl helper which takes IP address and checks 
the database to find the username who last authenticated from there. 
This needs to be checked and permit existing sessions before the auth 
helper.


The config looks something like this:


  external_acl_type ipuser negative_ttl=0 ttl=7200 %http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Protecting squid

[Eliezer Croitoru]

Hey Ben,

Since you probably doesn’t have 100k users and there for passwords it wouldn't 
do a thing.
Nobody will feel you dropping the TTL.
The content of the credentials file will be in RAM so you should give it a try 
first and ask later.

All The Bests,
Eliezer


Eliezer Croitoru
Tech Support
Mobile: +972-5-28704261
Email: ngtech1...@gmail.com
Zoom: Coming soon


-Original Message-
From: squid-users  On Behalf Of Ben 
Goz
Sent: Sunday, March 14, 2021 3:26 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Protecting squid


On 12/03/2021 7:13, Amos Jeffries wrote:
> On 12/03/21 3:56 am, Ben Goz wrote:
>>
>> On 11/03/2021 16:44, Amos Jeffries wrote:
>>> On 12/03/21 3:37 am, Ben Goz wrote:
>>>>
>>>> On 11/03/2021 15:50, Antony Stone wrote:
>>>>> On Thursday 11 March 2021 at 14:41:11, Ben Goz wrote:
>>>>>
>>>>> Tell about your network setup and what you are trying to achieve - 
>>>>> we might be
>>>>> able to suggest solutions.
>>>>
>>>> End users machine using some client application while their system 
>>>> proxy points to the above squid proxy server.
>>>>
>>>
>>> Please also provide your squid.conf settings so we can check they 
>>> achieve your described need(s) properly. At least any lines starting 
>>> with the http_access, auth_param, acl, or external_acl_type 
>>> directives would be most useful.
>>>
>>> Do not forget to anonymize sensitive details before posting. PLEASE 
>>> do so in a way that we can tell whether a hidden value was correct 
>>> for its usage, and whether any two hidden values are the same or 
>>> different.
>>
>>
>> It's fork of default configuration with some changes.
>>
>> # Recommended minimum Access Permission configuration:
>> #
>> # Deny requests to certain unsafe ports
>> #http_access deny !Safe_ports
>>
>
>
> Please restore this security protection. It prevents malware abusing 
> HTTP's similarity to certain other protocols to perform attacks 
> *through* your proxy.
>
> The default Safe_ports list allows all ports not known to be 
> dangerous, and all ports above 1024. So it should not have any 
> noticeable effect on to any legitimate HTTP proxy clients - unless 
> there is something really dodgy happening on your network. If you 
> actually want something like that happening, then add the appropriate 
> port for that activity to the Safe_ports list. Do not drop the 
> protection completely.
>
>
>> # Deny CONNECT to other than secure SSL ports
>> #http_access deny CONNECT !SSL_ports
>>
>
> The same can be said about this. Except this line is arguably even 
> more important. CONNECT tunnels can literally contain anything. Let 
> clients do things by adding ports to SSL_Ports list as-needed.
>
> Please do some due-diligence checks before that to verify you are okay 
> with all the uses of that port. Even ones you think the client 
> themselves is unlikely to be doing. Once you open a port here *anyone* 
> with access to the proxy can do whatever they like on that port.
>
>
>
>> # Only allow cachemgr access from localhost
>> http_access allow localhost manager
>> http_access deny manager
>>
>> http_access allow localnet
>> http_access allow localhost
>>
>> auth_param basic program /usr/local/squid/libexec/basic_ncsa_auth 
>> /usr/local/squid/etc/passwd
>> auth_param basic realm proxy
>
> I notice you are missing a line setting the login TTL value.
>
> There is currently a potential problem in the default which means 
> Squid encounters situations where the credentials are seen as still 
> going to be valid for hours so do not get refreshed. But garbage 
> collection decides to throw them away.
>
> This may not be related to the complaints you reported getting. But 
> should be fixed to ensure the side effect of having to re-authenticate 
> users does not complicate your actual problem.
>
> "auth_param basic credentialsttl ..." sets how often Squid will 
> re-check your auth system to confirm the users is still allowed. 
> Default: 2 hr.
>
> "authenticate_ttl ..." sets how often Squid will try to throw away all 
> info about old clients being logged in. Default: 1 hr.
>
>
>> acl authenticated proxy_auth REQUIRED
>> http_access allow authenticated
>>
>
> I recommend a slightly different form of check for logins. It prevents 
> the situation where a user trying the wrong credentials gets a loop of 
> popups.
>
> Like so:
>  http_access deny !authenticated
>
&g

Re: [squid-users] Protecting squid

[Ben Goz]

On 12/03/2021 7:13, Amos Jeffries wrote:

On 12/03/21 3:56 am, Ben Goz wrote:


On 11/03/2021 16:44, Amos Jeffries wrote:

On 12/03/21 3:37 am, Ben Goz wrote:


On 11/03/2021 15:50, Antony Stone wrote:

On Thursday 11 March 2021 at 14:41:11, Ben Goz wrote:

Tell about your network setup and what you are trying to achieve - 
we might be

able to suggest solutions.


End users machine using some client application while their system 
proxy points to the above squid proxy server.




Please also provide your squid.conf settings so we can check they 
achieve your described need(s) properly. At least any lines starting 
with the http_access, auth_param, acl, or external_acl_type 
directives would be most useful.


Do not forget to anonymize sensitive details before posting. PLEASE 
do so in a way that we can tell whether a hidden value was correct 
for its usage, and whether any two hidden values are the same or 
different.



It's fork of default configuration with some changes.

# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
#http_access deny !Safe_ports




Please restore this security protection. It prevents malware abusing 
HTTP's similarity to certain other protocols to perform attacks 
*through* your proxy.


The default Safe_ports list allows all ports not known to be 
dangerous, and all ports above 1024. So it should not have any 
noticeable effect on to any legitimate HTTP proxy clients - unless 
there is something really dodgy happening on your network. If you 
actually want something like that happening, then add the appropriate 
port for that activity to the Safe_ports list. Do not drop the 
protection completely.




# Deny CONNECT to other than secure SSL ports
#http_access deny CONNECT !SSL_ports



The same can be said about this. Except this line is arguably even 
more important. CONNECT tunnels can literally contain anything. Let 
clients do things by adding ports to SSL_Ports list as-needed.


Please do some due-diligence checks before that to verify you are okay 
with all the uses of that port. Even ones you think the client 
themselves is unlikely to be doing. Once you open a port here *anyone* 
with access to the proxy can do whatever they like on that port.





# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

http_access allow localnet
http_access allow localhost

auth_param basic program /usr/local/squid/libexec/basic_ncsa_auth 
/usr/local/squid/etc/passwd

auth_param basic realm proxy


I notice you are missing a line setting the login TTL value.

There is currently a potential problem in the default which means 
Squid encounters situations where the credentials are seen as still 
going to be valid for hours so do not get refreshed. But garbage 
collection decides to throw them away.


This may not be related to the complaints you reported getting. But 
should be fixed to ensure the side effect of having to re-authenticate 
users does not complicate your actual problem.


"auth_param basic credentialsttl ..." sets how often Squid will 
re-check your auth system to confirm the users is still allowed. 
Default: 2 hr.


"authenticate_ttl ..." sets how often Squid will try to throw away all 
info about old clients being logged in. Default: 1 hr.




acl authenticated proxy_auth REQUIRED
http_access allow authenticated



I recommend a slightly different form of check for logins. It prevents 
the situation where a user trying the wrong credentials gets a loop of 
popups.


Like so:
 http_access deny !authenticated

That guarantees they are not asked to login again if their software 
agent (aka browser, or such) provided or can locate the proper 
credentials.


After that you can add other rules about what the logged in users can 
do. eg allow them to do whatever they want. Like so:

 http_access allow all


Can I configure squid authentication TTL per only source IP and ignores 
other parameters so authentication will be requested only once in TTL 
for all the sessions?





Amos
___
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] Protecting squid

[Amos Jeffries]

On 12/03/21 3:56 am, Ben Goz wrote:


On 11/03/2021 16:44, Amos Jeffries wrote:

On 12/03/21 3:37 am, Ben Goz wrote:


On 11/03/2021 15:50, Antony Stone wrote:

On Thursday 11 March 2021 at 14:41:11, Ben Goz wrote:

Tell about your network setup and what you are trying to achieve - 
we might be

able to suggest solutions.


End users machine using some client application while their system 
proxy points to the above squid proxy server.




Please also provide your squid.conf settings so we can check they 
achieve your described need(s) properly. At least any lines starting 
with the http_access, auth_param, acl, or external_acl_type directives 
would be most useful.


Do not forget to anonymize sensitive details before posting. PLEASE do 
so in a way that we can tell whether a hidden value was correct for 
its usage, and whether any two hidden values are the same or different.



It's fork of default configuration with some changes.

# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
#http_access deny !Safe_ports




Please restore this security protection. It prevents malware abusing 
HTTP's similarity to certain other protocols to perform attacks 
*through* your proxy.


The default Safe_ports list allows all ports not known to be dangerous, 
and all ports above 1024. So it should not have any noticeable effect on 
to any legitimate HTTP proxy clients - unless there is something really 
dodgy happening on your network. If you actually want something like 
that happening, then add the appropriate port for that activity to the 
Safe_ports list. Do not drop the protection completely.




# Deny CONNECT to other than secure SSL ports
#http_access deny CONNECT !SSL_ports



The same can be said about this. Except this line is arguably even more 
important. CONNECT tunnels can literally contain anything. Let clients 
do things by adding ports to SSL_Ports list as-needed.


Please do some due-diligence checks before that to verify you are okay 
with all the uses of that port. Even ones you think the client 
themselves is unlikely to be doing. Once you open a port here *anyone* 
with access to the proxy can do whatever they like on that port.





# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

http_access allow localnet
http_access allow localhost

auth_param basic program /usr/local/squid/libexec/basic_ncsa_auth 
/usr/local/squid/etc/passwd

auth_param basic realm proxy


I notice you are missing a line setting the login TTL value.

There is currently a potential problem in the default which means Squid 
encounters situations where the credentials are seen as still going to 
be valid for hours so do not get refreshed. But garbage collection 
decides to throw them away.


This may not be related to the complaints you reported getting. But 
should be fixed to ensure the side effect of having to re-authenticate 
users does not complicate your actual problem.


"auth_param basic credentialsttl ..." sets how often Squid will re-check 
your auth system to confirm the users is still allowed. Default: 2 hr.


"authenticate_ttl ..." sets how often Squid will try to throw away all 
info about old clients being logged in. Default: 1 hr.




acl authenticated proxy_auth REQUIRED
http_access allow authenticated



I recommend a slightly different form of check for logins. It prevents 
the situation where a user trying the wrong credentials gets a loop of 
popups.


Like so:
 http_access deny !authenticated

That guarantees they are not asked to login again if their software 
agent (aka browser, or such) provided or can locate the proper credentials.


After that you can add other rules about what the logged in users can 
do. eg allow them to do whatever they want. Like so:

 http_access allow all


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

Re: [squid-users] Protecting squid

[Alex Rousskov]

On 3/11/21 9:37 AM, Ben Goz wrote:
> End users machine using some client application while their system proxy
> points to the above squid proxy server.

Client certificate-based authentication may be the best option if their
system proxy supports it and you do not need to bump user traffic with
SslBump. Otherwise, what authentication options does their system proxy
support (as an HTTP proxy client)?

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

Re: [squid-users] Protecting squid

[Ben Goz]

On 11/03/2021 16:44, Amos Jeffries wrote:

On 12/03/21 3:37 am, Ben Goz wrote:


On 11/03/2021 15:50, Antony Stone wrote:

On Thursday 11 March 2021 at 14:41:11, Ben Goz wrote:

Tell about your network setup and what you are trying to achieve - 
we might be

able to suggest solutions.


End users machine using some client application while their system 
proxy points to the above squid proxy server.




Please also provide your squid.conf settings so we can check they 
achieve your described need(s) properly. At least any lines starting 
with the http_access, auth_param, acl, or external_acl_type directives 
would be most useful.


Do not forget to anonymize sensitive details before posting. PLEASE do 
so in a way that we can tell whether a hidden value was correct for 
its usage, and whether any two hidden values are the same or different.



It's fork of default configuration with some changes.

# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
#http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
#http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

http_access allow localnet
http_access allow localhost

auth_param basic program /usr/local/squid/libexec/basic_ncsa_auth 
/usr/local/squid/etc/passwd

auth_param basic realm proxy
acl authenticated proxy_auth REQUIRED
http_access allow authenticated




Amos
___
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] Protecting squid

[Amos Jeffries]

On 12/03/21 3:37 am, Ben Goz wrote:


On 11/03/2021 15:50, Antony Stone wrote:

On Thursday 11 March 2021 at 14:41:11, Ben Goz wrote:

Tell about your network setup and what you are trying to achieve - we 
might be

able to suggest solutions.


End users machine using some client application while their system proxy 
points to the above squid proxy server.




Please also provide your squid.conf settings so we can check they 
achieve your described need(s) properly. At least any lines starting 
with the http_access, auth_param, acl, or external_acl_type directives 
would be most useful.


Do not forget to anonymize sensitive details before posting. PLEASE do 
so in a way that we can tell whether a hidden value was correct for its 
usage, and whether any two hidden values are the same or different.



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

Re: [squid-users] Protecting squid

[Ben Goz]

On 11/03/2021 15:50, Antony Stone wrote:

On Thursday 11 March 2021 at 14:41:11, Ben Goz wrote:


I tried to open squid with some special port other than the default 3128
port.

Obscurity is not equivalent to security.


But after a while I saw that my squid was being abused by unknown IP
addresses

I'm assuming this means your Squid proxy is accessible from the Internet.

Why?

My users access squid via the internet.



so I decided to password protect my squid so that only authorized
users could use it.
But it's pretty annoying for the users to enter user/password repeatedly.

What authentication method are you using?  At the very least, a user should
not have to authenticate more than once per browser session - are they saying
that even that is excessive?

Yep.



Is there any other solution than password protection that only authorized
users can have access to my squid server?

Depends what "authorised" means.  Can you define the network range they are
expected to come from, and restrict access only to those IPs?
This solution is least preferred because IPs range can by dynamically 
change.


Tell about your network setup and what you are trying to achieve - we might be
able to suggest solutions.


End users machine using some client application while their system proxy 
points to the above squid proxy server.





Antony.


Regards,

Ben

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

Re: [squid-users] Protecting squid

[Antony Stone]

On Thursday 11 March 2021 at 14:41:11, Ben Goz wrote:

> I tried to open squid with some special port other than the default 3128
> port.

Obscurity is not equivalent to security.

> But after a while I saw that my squid was being abused by unknown IP
> addresses

I'm assuming this means your Squid proxy is accessible from the Internet.

Why?

> so I decided to password protect my squid so that only authorized
> users could use it.
> But it's pretty annoying for the users to enter user/password repeatedly.

What authentication method are you using?  At the very least, a user should 
not have to authenticate more than once per browser session - are they saying 
that even that is excessive?

> Is there any other solution than password protection that only authorized
> users can have access to my squid server?

Depends what "authorised" means.  Can you define the network range they are 
expected to come from, and restrict access only to those IPs?

Tell about your network setup and what you are trying to achieve - we might be 
able to suggest solutions.


Antony.

-- 
The best time to plant a tree is 20 years ago.
The second best time is now.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Protecting squid against ddos attacks

[Amos Jeffries]

On 23/09/19 1:59 am, Chirayu Patel wrote:
> Hi Amos,
> 
> Thanks a lot for giving some amazing insights..
> 
> So currently I am using Squid to achieve 2 things :
> a) Content Filtering - by checking the url against an external db and
> allow and block it accordingly. (using url_rewriter). 
> b) To popup captive portal
> 
> 1) Regarding the use of 4 ports
> Using iptables, I am redirecting the non authenticated users to
> ports 3132   & 3133. And then in squid i am checking the port on which I
> have received the request from. If its the above ports, then I run the
> captive portal flow
> 
> Once the user is authenticated , then I redirect their traffic to
> ports 3129 and 3131, and for those ports I run the content policy flow.
> 
> I am not sure if this is the right way of choosing the flow. Please
> advise if there is any other way to run two different flows with one squid.

TOS or NFMARK are designed for that type of traffic control. Squid
integrates with those system features.

The ports design works too though. It is just a matter of choice between
the three mechanisms, up to you.

> 
> 3) Right now I have configured firewall to only allow these 4 ports on
> the INPUT chain, so I am not expecting traffic to come from any other
> ports. In that case, is it okay if I have removed the default config and
> kept  "http_access allow all" ??
> The only issue is that the attacker now has 4 ports to run attacks on.
> 

I hope you restrict which clients are being NAT'ed into the proxy, *and*
prohibit clients connecting directly to the http(s)_port's (that mangle
rule in our wiki config example).
 That would restrict the 'from anywhere', issues somewhat.


The remaining problem is that clients can instruct the proxy to open
opaque TCP tunnels _to anywhere_. That is buried inside the HTTP syntax
and can occur any distance down the stream of HTTP messages clients
send. Also, some protocols (eg email spam delivery) can be passed
through an HTTP proxy as custom HTTP message headers.
 A firewall can only be used on the Squid<->server connections. Which
leaves DoS vulnerability from all the resource consumption by the proxy
handling those messages.


> 4) > on_unsupported_protocol tunnel all 
> 
> I had added this when I faced issue with one of the Apps, Whatsapp which
> send the http traffic on https port. If I replace that with *respond*, I
> guess Whatsapp will become unusable.. right ?
> 

Yes. The key thing here is being aware of the issue, and handling it as
best you can at the firewall as traffic goes in/out of the proxy.

> 
> 6) cache_mem 0 MB
> The default cache memory is quite huge (256 MB). That is approx the
> total usable memory I have on the AP. In that case, what do you think
> should be a good starting point in case I keep it to a non zero value ?

You can gain a fair amount of the benefits from just a few MB. You could
start with 1-2 MB and adjust from there.


> 
> 7) memory_pools off
> Again, I was too concerned about memory use and I got scared because of
> this comment 
> -- -- -- -- -- -- -- -- -- --
> -- -- -- --
> If set, Squid will keep pools of allocated (but unused) memory available
> for future use. If memory is a premium on your system and you believe
> your malloc library outperforms Squid  routines, disable this.
> - -- -- -- -- -- -- -- --
> -- -- --  
> But I believe some memory in exchange of performance is OK. So I am
> going to enable it.

You can use 
to restrict how much extra memory Squid holds onto in the pools. You
probably want to try that at 1 MB or 512 KB.


> 
> 9) max_filedesc 5120.
> I had kept this number bigger because we were getting "out of file
> descriptors error"

This is still quite small. The default should be 64KB on most systems
these days. The 1024 is used as an absolute minimal value when system
capability detection fails.


> 
> 10) Above all, the best thing would be a way to differentiate between a
> high traffic flow of http(s) requests coming in from legitimate users vs
> a high traffic flow generated by an attacker with a simple script. 
> 
Without knowing in advance what that "simple script" is going to send
that is a very hard problem. It could literally be anything.

You can possibly make an external ACL helper that takes details about
the HTTP request and does some ML processing to decide whether to block
it. But ironically the delays inherent in that processing make the proxy
more at risk for DoS until it detects the attack pattern.


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

Re: [squid-users] Protecting squid against ddos attacks

[Chirayu Patel]

Hi Amos,

Thanks a lot for giving some amazing insights..

So currently I am using Squid to achieve 2 things :
a) Content Filtering - by checking the url against an external db and allow
and block it accordingly. (using url_rewriter).
b) To popup captive portal

1) Regarding the use of 4 ports
Using iptables, I am redirecting the non authenticated users to ports  3132
 & 3133. And then in squid i am checking the port on which I have received
the request from. If its the above ports, then I run the captive portal flow

Once the user is authenticated , then I redirect their traffic to ports 3129
and 3131, and for those ports I run the content policy flow.

I am not sure if this is the right way of choosing the flow. Please advise
if there is any other way to run two different flows with one squid.

2) Actually 3128 port is there in the config.. missed to attach that..

3) Right now I have configured firewall to only allow these 4 ports on the
INPUT chain, so I am not expecting traffic to come from any other ports. In
that case, is it okay if I have removed the default config and kept
"http_access allow all" ??
The only issue is that the attacker now has 4 ports to run attacks on.

4) > on_unsupported_protocol tunnel all

I had added this when I faced issue with one of the Apps, Whatsapp which
send the http traffic on https port. If I replace that with *respond*, I
guess Whatsapp will become unusable.. right ?

5) ipcache_size & fqdncache_size.
I was too concerned about the memory usage but I believe it does more bad
than good.  I will increase them to their defaults.

6) cache_mem 0 MB
The default cache memory is quite huge (256 MB). That is approx the total
usable memory I have on the AP. In that case, what do you think should be a
good starting point in case I keep it to a non zero value ?

7) memory_pools off
Again, I was too concerned about memory use and I got scared because of
this comment
-- -- -- -- -- -- -- -- -- --
-- -- -- --
If set, Squid will keep pools of allocated (but unused) memory available
for future use. If memory is a premium on your system and you believe your
malloc library outperforms Squid  routines, disable this.
- -- -- -- -- -- -- -- --
-- -- --
But I believe some memory in exchange of performance is OK. So I am going
to enable it.

8) The reason for keeping a single url_rewrite process has got to do with
caching of the external content policy api replies which is mainly to avoid
making external calls if the cache is available. If I have multiple
processes, the cache will get divided amongst multiple processes depending
on which one has made the call.

9) max_filedesc 5120.
I had kept this number bigger because we were getting "out of file
descriptors error"

10) Above all, the best thing would be a way to differentiate between a
high traffic flow of http(s) requests coming in from legitimate users vs a
high traffic flow generated by an attacker with a simple script.

--
Thank You
Chirayu Patel
Truecom Telesoft
+91 8758484287




On Sat, 21 Sep 2019 at 17:33, 
wrote:

> Send squid-users mailing list submissions to
> squid-users@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-requ...@lists.squid-cache.org
>
> You can reach the person managing the list at
> squid-users-ow...@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. Re: Protecting squid against ddos attacks (Amos Jeffries)
>2. Re: Help with HTTPS SQUID 3.1.23 https proxy not  working
>   (KleinEdith)
>3. Re: Help with HTTPS SQUID 3.1.23 https proxy not working
>   (Matus UHLAR - fantomas)
>
>
> --
>
> Message: 1
> Date: Sat, 21 Sep 2019 12:19:18 +1200
> From: Amos Jeffries 
> To: squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] Protecting squid against ddos attacks
> Message-ID: <835c4d02-4246-8c65-f9ce-cf91c7dd9...@treenet.co.nz>
> Content-Type: text/plain; charset=utf-8
>
> On 21/09/19 1:03 am, Chirayu Patel wrote:
> > --> I have installed squid in a wifi access point which will in many
> > cases behave as an edge gateway as well.. So basically it itself is the
> > firewall. There is nothing in front to protect it.
> > --> There are 4 ports that are opened.. If someone decides to do a DDOS
> > attack on them, what options do I have to protect against them.
>
>
> Pretty much the exact opposite of what y

Re: [squid-users] Protecting squid against ddos attacks

[Amos Jeffries]

On 21/09/19 1:03 am, Chirayu Patel wrote:
> --> I have installed squid in a wifi access point which will in many
> cases behave as an edge gateway as well.. So basically it itself is the
> firewall. There is nothing in front to protect it.
> --> There are 4 ports that are opened.. If someone decides to do a DDOS
> attack on them, what options do I have to protect against them.


Pretty much the exact opposite of what you have this proxy configured to
be doing.

Right now you have it setup to allow all traffic *from* anywhere *to*
anywhere, with no controls, no logging, and no report to any backend
where the traffic originated.


Squid default configuration comes with some DoS protections as
recommended config, some are built-in and always working.

> This is my squid config file :
> 
> --
> http_port 3129 intercept
> https_port 3131 intercept ssl-bump cert=/etc/ray/certificates/myCA.pem \
>     generate-host-certificates=off dynamic_cert_mem_cache_size=2MB
> ## For Captive Portal    
> http_port 3132 intercept
> https_port 3133 intercept ssl-bump cert=/etc/ray/certificates/myCA.pem \
>     generate-host-certificates=off dynamic_cert_mem_cache_size=1MB
> 

That comment "For Captive Portal" is out of place. Interception *is*
captive portal, so all your ports above are captive portal ports.

Usually you would only need one port of each type. Including the
forward-proxy port (3128 with no mode flag, which you are missing).

For DoS and DDoS protection, having more ports receiving traffic does
help by allowing more TCP port numbers to be available for use. But you
need firewall rules to spread the traffic load across those ports. See
the "Frontend Alternative 1" section of
 

For the best DDoS protection Squid can offer you would have a
multi-machine setup like that config page is part of. The particular
Squid you have right now though can gain from just having the port load
balancing part. You can extend the backend part on other machines later
if you want / need.


> 
> # TLS/SSL bumping definitions
> acl tls_s1_connect at_step SslBump1
> acl tls_s2_client_hello at_step SslBump2
> acl tls_s3_server_hello at_step SslBump3
> 

Unusued ACLs still consume memory. Not much, but still thats memory.


> # TLS/SSL bumping steps
> ssl_bump peek tls_s1_connect all # peek at TLS/SSL connect data

The "all" on the above line is unnecessary and a waste of CPU cycles on
ever next connection. Remove it.

> ssl_bump splice all # splice: no active bumping
> on_unsupported_protocol tunnel all

The tunnel action causes Squid to setup a server connection. That costs
2x TCP ports, 2x FDs, client I/O, server I/O, CPU cycles to perform all
the I/O, and memory for all the state and I/O buffers

While this may give you good service for weird client traffic. If your
DDoS risk is high, it may be better to use "respond" instead and an ACL
with "deny_info TCP_RESET attached".


> 
> pinger_enable off
> digest_generation off
> netdb_filename none
> ipcache_size 128

ipcache being larger will help your high-traffic periods by helping
reduce delays on traffic you let through the proxy.

DDoS can reduce that benefit. But that is only a *visual* effect, there
is no more resource consumption than the DDoS would cause with a smaller
ipcache size.

So reducing this cache size only slows your normal peak traffic at times
when it needs fastest service. That is a tradeoff against your AP
machines memory available.


> fqdncache_size 128

Large fqdncache for intercept proxies helps retain valid Host header
records longer and reduce delays receiving new messages. So larger here
is better protection, against both normal traffic problems and DDoS.


> via off
> forwarded_for transparent
> httpd_suppress_version_string on
> cache deny all
> cache_mem 0 MB

Using memory to store objects recently used gives 100x speed increase
(aka DoS handling capacity).

This though is a tradeoff with the memory you have available. Whether
that speed gain is nanoseconds, milliseconds or whole seconds depends on
your network speeds.

FYI: The model of a frontend LB with backend cache machine (like that
CARP setup earlier) is designed to reduce that speed difference so both
the resource consumption and speed gain cache gives is primarily
happening at the backends - which are very close in the network so
minimal extra delay for the frontend LB.


> memory_pools off

Only if you have to. The memory usage patterns of high-traffic software
like Squid is quite different from what most OS malloc are optimized
for. The memory pools in Squid are optimized to reduce that to a number
of larger more consistently sized allocations.

Without these pools memory allocation cycles add a bit of speed
reduction to the proxy, and worse can easily lead to memory
fragmentation issues. Normal traffic speeds these effects are not easily
noticed, but under DoS or DDoS conditions they can