On 21/11/17 23:06, Vieri wrote:
________________________________
From: Amos Jeffries
http_access allow goodAgents !baddomains (AND)
If the first line matches the allow happens.
otherwise deny happens
ie. goodAgents are only allowed to non-baddomains. All non-goodAgents
are denied to everything.
From this I deduce that in my case I cannot use "http_access allow goodAgents", but I need to go for "http_access deny !goodAgents" so I can continue on evaluating the rest of my http_access rules.
Allowing them all the way through Squid is bad. But that is not what is
needed here. ssl_bump rules get applied after the CONNECT is accepted
*in* for proxy processing and they decide what happens to the tunneled
data based on what is found there.
If bumping is decided the TLS gets removed and the messages inside
individually go through the http_access process.
You lost me there. Here's what I did today.
I took your advice (and Alex's), and renamed my ACL labels. Unfortunately, I'm still a little confused :-(.
[ snipping the log traces to keep the mail relatively small ]
It seems that Squid decides to ALLOW, right?
Look at the "markFinished" lines for the outcome of each set of access
controls outcomes. The lines leading up to those details which ACL tests
are performed and which *_access lines they were on.
Ignoring the first few quoted lines which are for some earlier
ssl-bumped transaction I see:
* http_access line #9 DENIED an HTTP request.
* access_log is ALLOWED to record something. Probably unrelated traffic.
* http_reply_access line #9 ALLOWED a reply to be delivered, then
* access_log is ALLOWED to log something.
Isn't the message "The request CONNECT 89.16.167.134:443 is DENIED" what I should be concentrating on?
Isn't that the root cause?
Yes, that line is the outcome. The cause of the denial is what ACL
check(s) led to it.
Specifically in these log lines:
matches: checked: interceptedssl = 1
match: aclIpMatchIp: '10.215.144.48' found
matches: checked: localnet = 1
matches: checked: !localnet = 0
matches: checked: http_access#8 = 0
matches: checked: good_useragents = 0
matches: checked: !good_useragents = 1
match: aclIpMatchIp: '10.215.144.48' NOT found
matches: checked: src_ips_with_any_useragent = 0
matches: checked: !src_ips_with_any_useragent = 1
matches: checked: http_access#9 = 1
matches: checked: http_access = 1
Which strangely do not seem to match your squid.conf details. These are
the 8th and 9th http_access lines in the squid.conf which is used by the
running proxy.
But in your quoted squid.conf they are lines #4 and #5.
http_access deny interceptedssl !localnet
- it was interceptedssl from localnet
- so not a match due to !localnet
http_access deny !good_useragents !src_ips_with_any_useragent
- it has no UA, and
- it is not listed n that IP whitelist.
- the NOT condition (!) on both of those make the whole line a match.
In another message, you mentioned that I should notice that Squid reports another ACL name (in this case, after the name change, it's "bad_replied_mimetypes").
In any case, the message "The reply for GET https://www.gentoo.org/ is ALLOWED" means that Squid should ALLOW, right?
No, it means that *reply* is allowed.
A reply *might* be from a server, or from cache, or a 403 denial error
page generated by Squid, or one of the deny_info redirects you have
configured to happen - like that one in the "HTTP Client REPLY" in the
second log trace.
However, why do I get a 307 redirect to a deny_info page (where incidentally the URL refers to bad_useragents, not bad_replied_mimetypes)?
Because the CONNECT _request_ was denied and that redirect _reply_ is
what a deny_info with a URL generates when its associated ACL causes a
denial.
bad_useragents was the ACL checking the *request* which triggered that
redirect to happen.
bad_replied_mimetypes was just the last ACL tested to see if that
redirect was allowed to be delivered to the client.
If we assume that the two log traces actually line up then
bad_replied_mimetypes is actually irrelevant because the
http_reply_access result is actually "NO match found, last action DENIED
so returning ALLOWED"
I can't seem to clear this out and make it work without adding "http_access allow CONNECT SSL_ports" right before checking for the useragent.
If you place that after the default "deny CONNECT !SSL_ports", and
before your UA checks, AND if you are using ssl_bump on the allowed
tunnels then you can relatively safely use "allow CONNECT".
Just be careful that the CONNECT allowed by that are always handled
safely by the ssl_bump rules you have.
Meaning that you either bump or terminate traffic you are not sure is
okay, splice if you are reasonably sure, etc. it is a balancing effort
between "splice as much as possible" and "terminate if unsure of the
traffic" advice.
Just FYI you would be a huge amount better off dropping the UA
fingerprinting. It's a _really_ simplistic idea about the HTTP world,
and it is partly because of that overly-simplistic nature and depending
on unreliable values that you are having so much more trouble than
normal admin face.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
