[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 <http://www.squid-cache.org/Doc/config/memory_pools_limit/>
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