<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small">Hi Amos,</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small">Thanks a lot for giving some amazing insights..</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small">So currently I am using Squid to achieve 2 things :</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small">a) Content Filtering - by checking the url against an external db and allow and block it accordingly. (using url_rewriter). </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small">b) To popup captive portal</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small">1) Regarding the use of 4 ports</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small">Using iptables, I am redirecting the non authenticated users to ports <span class="gmail_default"></span>
<span class="gmail_default"></span>3132 & <span class="gmail_default"></span><span class="gmail_default"></span><span style="font-family:Arial,Helvetica,sans-serif;font-size:small">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</span></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small">Once the user is authenticated , then I redirect their traffic to ports </span><span class="gmail_default"></span><span style="font-family:Arial,Helvetica,sans-serif;font-size:small">3129 and 3131, and for those ports I run the content policy flow.</span></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small">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.</span></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small">2) Actually 3128 port is there in the config.. missed to attach that.. </span></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"><span style="font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span></div><div class="gmail_default" style="">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" ??</div><div class="gmail_default" style="">The only issue is that the attacker now has 4 ports to run attacks on.</div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">4) <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>> on_unsupported_protocol tunnel all </div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">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 <b>respond</b>, I guess Whatsapp will become unusable.. right ?</div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">5) <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>ipcache_size & <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>fqdncache_size. </div><div class="gmail_default" style="">I was too concerned about the memory usage but I believe it does more bad than good. I will increase them to their defaults. </div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">6) <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>cache_mem 0 MB</div><div class="gmail_default" style="">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 ?<br></div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">7) memory_pools off</div><div class="gmail_default" style="">Again, I was too concerned about memory use and I got scared because of this comment </div><div class="gmail_default" style="">------
------
------
------
------
------
------
------
------
------
------
------
------
------
</div><div class="gmail_default" style=""><span style="color:rgb(30,30,30);font-family:courier;font-size:12px">If set, Squid will keep pools of allocated (but unused) memory</span><span style="color:rgb(30,30,30);font-family:courier;font-size:12px"> available for future use. If memory is a premium on your</span><span style="color:rgb(30,30,30);font-family:courier;font-size:12px"> system and you believe your malloc library outperforms Squid </span><span style="color:rgb(30,30,30);font-family:courier;font-size:12px"> routines, disable this.</span></div><div class="gmail_default" style=""><span style="color:rgb(30,30,30);font-family:courier;font-size:12px">-------</span>------
------
------
------
------
------
------
------
------
------
------
------
</div><div class="gmail_default" style="">But I believe some memory in exchange of performance is OK. So I am going to enable it.</div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">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.</div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">9) <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>max_filedesc 5120.</div><div class="gmail_default" style="">I had kept this number bigger because we were getting "out of file descriptors error"</div><div class="gmail_default" style=""><br></div><div class="gmail_default" style="">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. </div><div class="gmail_default" style=""><br></div><div class="gmail_default"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--<div>Thank You</div><div>Chirayu Patel</div><div>Truecom Telesoft </div><div>+91 8758484287</div><div><br></div><div><br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 21 Sep 2019 at 17:33, <<a href="mailto:squid-users-request@lists.squid-cache.org">squid-users-request@lists.squid-cache.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send squid-users mailing list submissions to<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:squid-users-request@lists.squid-cache.org" target="_blank">squid-users-request@lists.squid-cache.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:squid-users-owner@lists.squid-cache.org" target="_blank">squid-users-owner@lists.squid-cache.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of squid-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>Protecting squid against ddos attacks (Amos Jeffries)<br>
2. Re: Help with HTTPS SQUID 3.1.23 https proxy not working<br>
(KleinEdith)<br>
3. Re: Help with HTTPS SQUID 3.1.23 https proxy not working<br>
(Matus UHLAR - fantomas)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sat, 21 Sep 2019 12:19:18 +1200<br>
From: Amos Jeffries <<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
Subject: Re: [squid-users] Protecting squid against ddos attacks<br>
Message-ID: <<a href="mailto:835c4d02-4246-8c65-f9ce-cf91c7dd9e92@treenet.co.nz" target="_blank">835c4d02-4246-8c65-f9ce-cf91c7dd9e92@treenet.co.nz</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 21/09/19 1:03 am, Chirayu Patel wrote:<br>
> --> I have installed squid in a wifi access point which will in many<br>
> cases behave as an edge gateway as well.. So basically it itself is the<br>
> firewall. There is nothing in front to protect it.<br>
> --> There are 4 ports that are opened.. If someone decides to do a DDOS<br>
> attack on them, what options do I have to protect against them.<br>
<br>
<br>
Pretty much the exact opposite of what you have this proxy configured to<br>
be doing.<br>
<br>
Right now you have it setup to allow all traffic *from* anywhere *to*<br>
anywhere, with no controls, no logging, and no report to any backend<br>
where the traffic originated.<br>
<br>
<br>
Squid default configuration comes with some DoS protections as<br>
recommended config, some are built-in and always working.<br>
<br>
> This is my squid config file :<br>
> <br>
> ------------------------------------------<br>
> http_port <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span><span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>3129 intercept<br>
> https_port 3131 intercept ssl-bump cert=/etc/ray/certificates/myCA.pem \<br>
> generate-host-certificates=off dynamic_cert_mem_cache_size=2MB<br>
> ## For Captive Portal <br>
> http_port <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>3132 intercept<br>
> https_port <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>3133 intercept ssl-bump cert=/etc/ray/certificates/myCA.pem \<br>
> generate-host-certificates=off dynamic_cert_mem_cache_size=1MB<br>
> <br>
<br>
That comment "For Captive Portal" is out of place. Interception *is*<br>
captive portal, so all your ports above are captive portal ports.<br>
<br>
Usually you would only need one port of each type. Including the<br>
forward-proxy port (3128 with no mode flag, which you are missing).<br>
<br>
For DoS and DDoS protection, having more ports receiving traffic does<br>
help by allowing more TCP port numbers to be available for use. But you<br>
need firewall rules to spread the traffic load across those ports. See<br>
the "Frontend Alternative 1" section of<br>
<<a href="https://wiki.squid-cache.org/ConfigExamples/ExtremeCarpFrontend" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/ConfigExamples/ExtremeCarpFrontend</a>><br>
<br>
For the best DDoS protection Squid can offer you would have a<br>
multi-machine setup like that config page is part of. The particular<br>
Squid you have right now though can gain from just having the port load<br>
balancing part. You can extend the backend part on other machines later<br>
if you want / need.<br>
<br>
<br>
> <br>
> # TLS/SSL bumping definitions<br>
> acl tls_s1_connect at_step SslBump1<br>
<span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>> acl tls_s2_client_hello at_step SslBump2<br>
> acl tls_s3_server_hello at_step SslBump3<br>
> <br>
<br>
Unusued ACLs still consume memory. Not much, but still thats memory.<br>
<br>
<br>
> # TLS/SSL bumping steps<br>
> ssl_bump peek tls_s1_connect all # peek at TLS/SSL connect data<br>
<br>
The "all" on the above line is unnecessary and a waste of CPU cycles on<br>
ever next connection. Remove it.<br>
<br>
> ssl_bump splice all # splice: no active bumping<br>
<span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>> on_unsupported_protocol tunnel all<br>
<br>
The tunnel action causes Squid to setup a server connection. That costs<br>
2x TCP ports, 2x FDs, client I/O, server I/O, CPU cycles to perform all<br>
the I/O, and memory for all the state and I/O buffers<br>
<br>
While this may give you good service for weird client traffic. If your<br>
DDoS risk is high, it may be better to use "respond" instead and an ACL<br>
with "deny_info TCP_RESET attached".<br>
<br>
<br>
> <br>
> pinger_enable off<br>
> digest_generation off<br>
> netdb_filename none<br>
> <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>ipcache_size 128<br>
<br>
ipcache being larger will help your high-traffic periods by helping<br>
reduce delays on traffic you let through the proxy.<br>
<br>
DDoS can reduce that benefit. But that is only a *visual* effect, there<br>
is no more resource consumption than the DDoS would cause with a smaller<br>
ipcache size.<br>
<br>
So reducing this cache size only slows your normal peak traffic at times<br>
when it needs fastest service. That is a tradeoff against your AP<br>
machines memory available.<br>
<br>
<br>
> <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>fqdncache_size 128<br>
<br>
Large fqdncache for intercept proxies helps retain valid Host header<br>
records longer and reduce delays receiving new messages. So larger here<br>
is better protection, against both normal traffic problems and DDoS.<br>
<br>
<br>
> via off<br>
> forwarded_for transparent<br>
> httpd_suppress_version_string on<br>
> cache deny all<br>
> <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>cache_mem 0 MB<br>
<br>
Using memory to store objects recently used gives 100x speed increase<br>
(aka DoS handling capacity).<br>
<br>
This though is a tradeoff with the memory you have available. Whether<br>
that speed gain is nanoseconds, milliseconds or whole seconds depends on<br>
your network speeds.<br>
<br>
FYI: The model of a frontend LB with backend cache machine (like that<br>
CARP setup earlier) is designed to reduce that speed difference so both<br>
the resource consumption and speed gain cache gives is primarily<br>
happening at the backends - which are very close in the network so<br>
minimal extra delay for the frontend LB.<br>
<br>
<br>
> <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>memory_pools off<br>
<br>
Only if you have to. The memory usage patterns of high-traffic software<br>
like Squid is quite different from what most OS malloc are optimized<br>
for. The memory pools in Squid are optimized to reduce that to a number<br>
of larger more consistently sized allocations.<br>
<br>
Without these pools memory allocation cycles add a bit of speed<br>
reduction to the proxy, and worse can easily lead to memory<br>
fragmentation issues. Normal traffic speeds these effects are not easily<br>
noticed, but under DoS or DDoS conditions they can drag the entire<br>
machine to a crawl if not a complete halt on low-memory systems (like<br>
yours?).<br>
<br>
<br>
> shutdown_lifetime 0 seconds<br>
> <br>
> #logfile_daemon /dev/null<br>
> access_log none<br>
<br>
A bit part of DoS or DDoS protection is identifying the attack as it<br>
starts. That requires the information about what traffic is happening to<br>
go somewhere for processing.<br>
<br>
Even if you have something else doing deep packet inspection I would<br>
enable logs. Use one of the network logging modules to send them to<br>
another machine if necessary for processing.<br>
<br>
<br>
> <br>
> #acl good_url dstdomain .<a href="http://yahoo.com" rel="noreferrer" target="_blank">yahoo.com</a> <<a href="http://yahoo.com" rel="noreferrer" target="_blank">http://yahoo.com</a>><br>
> http_access allow all<br>
> <br>
<br>
See the "default config" section of<br>
<<a href="https://wiki.squid-cache.org/Squid-3.5" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Squid-3.5</a>>. The default rules are<br>
primarily DoS protections these days, with some other nasty attacks<br>
(potentially leading to DDoS indirectly) as well.<br>
<br>
You need those rules, and you need a clear policy on what traffic you<br>
allow through the proxy (from where, to where). Once you have that in<br>
place you can reasonably consider what DoS/DDoS risk is left to deal<br>
with. So long as your policy and rule is "http_access allow all" you can<br>
be DoS'ed by a <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>single 38 byte HTTP request message - at least the proxy<br>
killed completely, possibly the whole machine.<br>
(FYI the other protection against this attack is the Via header, which<br>
you have disabled).<span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span><br>
<br>
<br>
> url_rewrite_program /tmp/squid/urlcat_server_start.sh<br>
> #url_rewrite_bypass on<br>
> url_rewrite_children 1 startup=1 idle=1 concurrency=30 queue-size=10000<br>
> on-persistent-overload=ERR<br>
<br>
Having only one helper may be a source of problems under any conditions.<br>
The ERR will help, but ideally you don't want to reach that state.<br>
<br>
Consider whether the thing this helper is doing can be done by ACLs and<br>
deny_info instead. That would avoid all the helper delays or I/O<br>
resource needs, and any clients getting those ERR error pages.<br>
<br>
<br>
> #url_rewrite_access allow all<br>
> #url_rewrite_extras "%>a/%>A %un %>rm bump_mode=%ssl::bump_mode<br>
> sni=\"%ssl::>sni\" referer=\"%{Referer}>h\""<br>
> url_rewrite_extras "%>a %lp %ssl::>sni"<br>
> <br>
> <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>max_filedesc 5120<br>
<br>
This is the most direct measure of how large a DoS has to be to kill<br>
your traffic. The smaller it is the fewer connections the DoS needs to open.<br>
<br>
There is a tradeoff though between the memory each of these needs to<br>
allocate (~500 bytes just to exist, up to 256KB when in use) vs the<br>
memory your machine has available.<br>
<br>
The reduction of that "in use" time also matters as one might expect.<br>
Which is where the cache_mem speedup comes in, to answer repeat queries<br>
(eg those seen in a classical DoS) at orders of magnitude higher speed<br>
than the backend network can provide the same answer.<br>
<br>
<br>
> coredump_dir /tmp<br>
> client_lifetime 30 minutes<br>
> read_ahead_gap 8 KB<br>
> <br>
<br>
<br>
Additional to all the above, you can setup a "<span class="gmail_default" style="font-family:verdana,sans-serif;font-size:x-small"></span>deny_info TCP_RESET ..."<br>
for any ACLs which does a deny action in your rules. That will prevent<br>
Squid generating an error page and consuming bandwidth to deliver it<br>
when that ACL blocks access.<br>
<br>
There is a tradeoff between annoying clients who no longer know why<br>
their connection ended, but under DoS or DDoS it is a huge bandwidth saver.<br>
<br>
<br>
Amos<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sat, 21 Sep 2019 02:51:05 -0500 (CDT)<br>
From: KleinEdith <<a href="mailto:SEO.Workwide@gmail.com" target="_blank">SEO.Workwide@gmail.com</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
Subject: Re: [squid-users] Help with HTTPS SQUID 3.1.23 https proxy<br>
not working<br>
Message-ID: <<a href="mailto:1569052265880-0.post@n4.nabble.com" target="_blank">1569052265880-0.post@n4.nabble.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Squid as the https proxy not working<br>
<br>
# Example rule allowing access from your local networks.<br>
# Adapt to list your (internal) IP networks from where browsing<br>
# should be allowed<br>
acl localnet src <a href="http://10.0.0.0/8" rel="noreferrer" target="_blank">10.0.0.0/8</a> # RFC1918 possible internal network<br>
acl localnet src <a href="http://172.16.0.0/12" rel="noreferrer" target="_blank">172.16.0.0/12</a> # RFC1918 possible internal network<br>
acl localnet src <a href="http://192.168.0.0/16" rel="noreferrer" target="_blank">192.168.0.0/16</a> # RFC1918 possible internal network<br>
#acl localnet src fc00::/7 # RFC 4193 local private network range<br>
#acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged)<br>
machines<br>
acl localnet src 10.0.0.188 # David Computer<br>
acl SSL_ports port 443<br>
acl Safe_ports port 80 # http<br>
acl Safe_ports port 21 # ftp<br>
acl Safe_ports port 443 # https<br>
acl Safe_ports port 70 # gopher<br>
acl Safe_ports port 210 # wais<br>
acl Safe_ports port 1025-65535 # unregistered ports<br>
acl Safe_ports port 280 # http-mgmt<br>
acl Safe_ports port 488 # gss-http<br>
acl Safe_ports port 591 # filemaker<br>
acl Safe_ports port 777 # multiling http<br>
acl CONNECT method CONNECT<br>
<br>
acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl"<br>
acl good_url dstdomain "/etc/squid/good_sites.acl"<br>
#http_access deny bad_url<br>
<br>
I can´t connect to:<br>
<br>
Outlook.com <<a href="https://outlook.live.com" rel="noreferrer" target="_blank">https://outlook.live.com</a>> <br>
Yahoo.com <<a href="https://www.yahoo.com/" rel="noreferrer" target="_blank">https://www.yahoo.com/</a>> <br>
SuCarroRD.com <<a href="https://sucarrord.com/" rel="noreferrer" target="_blank">https://sucarrord.com/</a>> <br>
Gmail.com <<a href="http://gmail.com/" rel="noreferrer" target="_blank">http://gmail.com/</a>> <br>
Bing <<a href="https://www.bing.com/" rel="noreferrer" target="_blank">https://www.bing.com/</a>> <br>
<br>
And more. I need help please to fix this problem <br>
<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html" rel="noreferrer" target="_blank">http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Sat, 21 Sep 2019 10:07:31 +0200<br>
From: Matus UHLAR - fantomas <<a href="mailto:uhlar@fantomas.sk" target="_blank">uhlar@fantomas.sk</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
Subject: Re: [squid-users] Help with HTTPS SQUID 3.1.23 https proxy<br>
not working<br>
Message-ID: <<a href="mailto:20190921080731.GB29045@fantomas.sk" target="_blank">20190921080731.GB29045@fantomas.sk</a>><br>
Content-Type: text/plain; charset=iso-8859-2; format=flowed<br>
<br>
On 21.09.19 02:51, KleinEdith wrote:<br>
>Squid as the https proxy not working<br>
><br>
># Example rule allowing access from your local networks.<br>
># Adapt to list your (internal) IP networks from where browsing<br>
># should be allowed<br>
>acl localnet src <a href="http://10.0.0.0/8" rel="noreferrer" target="_blank">10.0.0.0/8</a> # RFC1918 possible internal network<br>
>acl localnet src <a href="http://172.16.0.0/12" rel="noreferrer" target="_blank">172.16.0.0/12</a> # RFC1918 possible internal network<br>
>acl localnet src <a href="http://192.168.0.0/16" rel="noreferrer" target="_blank">192.168.0.0/16</a> # RFC1918 possible internal network<br>
>#acl localnet src fc00::/7 # RFC 4193 local private network range<br>
>#acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged)<br>
>machines<br>
>acl localnet src 10.0.0.188 # David Computer<br>
>acl SSL_ports port 443<br>
>acl Safe_ports port 80 # http<br>
>acl Safe_ports port 21 # ftp<br>
>acl Safe_ports port 443 # https<br>
>acl Safe_ports port 70 # gopher<br>
>acl Safe_ports port 210 # wais<br>
>acl Safe_ports port 1025-65535 # unregistered ports<br>
>acl Safe_ports port 280 # http-mgmt<br>
>acl Safe_ports port 488 # gss-http<br>
>acl Safe_ports port 591 # filemaker<br>
>acl Safe_ports port 777 # multiling http<br>
>acl CONNECT method CONNECT<br>
><br>
>acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl"<br>
>acl good_url dstdomain "/etc/squid/good_sites.acl"<br>
>#http_access deny bad_url<br>
><br>
>I can´t connect to:<br>
><br>
>Outlook.com <<a href="https://outlook.live.com" rel="noreferrer" target="_blank">https://outlook.live.com</a>><br>
>Yahoo.com <<a href="https://www.yahoo.com/" rel="noreferrer" target="_blank">https://www.yahoo.com/</a>><br>
>SuCarroRD.com <<a href="https://sucarrord.com/" rel="noreferrer" target="_blank">https://sucarrord.com/</a>><br>
>Gmail.com <<a href="http://gmail.com/" rel="noreferrer" target="_blank">http://gmail.com/</a>><br>
>Bing <<a href="https://www.bing.com/" rel="noreferrer" target="_blank">https://www.bing.com/</a>><br>
<br>
You haven't post whole squid config, did you?<br>
If you did, you definitely need to llow some access (for limited set of<br>
IPs), because the default is deny.<br>
<br>
<br>
<br>
-- <br>
Matus UHLAR - fantomas, <a href="mailto:uhlar@fantomas.sk" target="_blank">uhlar@fantomas.sk</a> ; <a href="http://www.fantomas.sk/" rel="noreferrer" target="_blank">http://www.fantomas.sk/</a><br>
Warning: I wish NOT to receive e-mail advertising to this address.<br>
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.<br>
The early bird may get the worm, but the second mouse gets the cheese.<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
<br>
<br>
------------------------------<br>
<br>
End of squid-users Digest, Vol 61, Issue 28<br>
*******************************************<br>
</blockquote></div></div>