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 <https://wiki.squid-cache.org/ConfigExamples/ExtremeCarpFrontend> 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 drag the entire machine to a crawl if not a complete halt on low-memory systems (like yours?). > shutdown_lifetime 0 seconds > > #logfile_daemon /dev/null > access_log none A bit part of DoS or DDoS protection is identifying the attack as it starts. That requires the information about what traffic is happening to go somewhere for processing. Even if you have something else doing deep packet inspection I would enable logs. Use one of the network logging modules to send them to another machine if necessary for processing. > > #acl good_url dstdomain .yahoo.com <http://yahoo.com> > http_access allow all > See the "default config" section of <https://wiki.squid-cache.org/Squid-3.5>. The default rules are primarily DoS protections these days, with some other nasty attacks (potentially leading to DDoS indirectly) as well. You need those rules, and you need a clear policy on what traffic you allow through the proxy (from where, to where). Once you have that in place you can reasonably consider what DoS/DDoS risk is left to deal with. So long as your policy and rule is "http_access allow all" you can be DoS'ed by a single 38 byte HTTP request message - at least the proxy killed completely, possibly the whole machine. (FYI the other protection against this attack is the Via header, which you have disabled). > url_rewrite_program /tmp/squid/urlcat_server_start.sh > #url_rewrite_bypass on > url_rewrite_children 1 startup=1 idle=1 concurrency=30 queue-size=10000 > on-persistent-overload=ERR Having only one helper may be a source of problems under any conditions. The ERR will help, but ideally you don't want to reach that state. Consider whether the thing this helper is doing can be done by ACLs and deny_info instead. That would avoid all the helper delays or I/O resource needs, and any clients getting those ERR error pages. > #url_rewrite_access allow all > #url_rewrite_extras "%>a/%>A %un %>rm bump_mode=%ssl::bump_mode > sni=\"%ssl::>sni\" referer=\"%{Referer}>h\"" > url_rewrite_extras "%>a %lp %ssl::>sni" > > max_filedesc 5120 This is the most direct measure of how large a DoS has to be to kill your traffic. The smaller it is the fewer connections the DoS needs to open. There is a tradeoff though between the memory each of these needs to allocate (~500 bytes just to exist, up to 256KB when in use) vs the memory your machine has available. The reduction of that "in use" time also matters as one might expect. Which is where the cache_mem speedup comes in, to answer repeat queries (eg those seen in a classical DoS) at orders of magnitude higher speed than the backend network can provide the same answer. > coredump_dir /tmp > client_lifetime 30 minutes > read_ahead_gap 8 KB > Additional to all the above, you can setup a "deny_info TCP_RESET ..." for any ACLs which does a deny action in your rules. That will prevent Squid generating an error page and consuming bandwidth to deliver it when that ACL blocks access. There is a tradeoff between annoying clients who no longer know why their connection ended, but under DoS or DDoS it is a huge bandwidth saver. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
