On 20/11/17 21:45, Vieri wrote:
________________________________
From: Alex Rousskov
You may be conflating two very different goals:
A) Understanding why Squid does X.
B) Configuring Squid to do what you want.
My response was focused on the former. Once you understand, you can
probably accomplish the latter on your own.
You are absolutely right. I'd like to uderstand how Squid *access rules work.
To put it bluntly, http_access and http_reply_access rules are processed one after another as they appear in squid.conf. It "exits" the sequence (ie. stops going through each http_*access rule) as soon as it hits a match.
Not quite. The lines which start with the same directive name are
executed that way. Each directive has a different timing within the
transaction lifetime.
http_access allow foo
http_reply_access deny foo
http_access allow bar
Is the same as
http_access allow foo
http_access allow bar
http_reply_access deny foo
http_access lines are checked on a client HTTP request arriving.
http_reply_access on a server HTTP reply arriving.
The http_*access rules take on ACLs which can be AND'ed if the conditions are in one line, or OR'ed if they are on seperate lines.
That is binary, access control lines are trinary logic with short-cuts.
eg.
http_access allow goodAgents !baddomains (AND)
#--
http_access allow goodAgents
http_access deny baddomains (OR)
You also have to take action into account.
For this:
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.
For this:
http_access allow goodAgents
http_access deny baddomains (OR)
If the first line matches the allow happens,
If the second matches deny happens,
otherwise allow happens.
ie. goodAgents are allowed to do anything. All non-goodAgents are denied
only to baddomains.
My goal is to deny all client traffic from browsers that DO NOT have
a specific user-agent string. So this is a negated statement.
There is no need to use negation for that. If the goodAgents ACL matches
requests with "specific user-agent string", then you can do this:
http_access allow goodAgents
http_access deny all
As you can see, there is no ACL negation or negative ACLs.
I understand your example, but unfortunately, I was looking for something else. It's my mistake because I started this thread with basic, stripped-down examples without giving details on what I need to achieve. I wasn't doing ACL negation just for kicks. It's because I need to integrate it into a broader setup.
Your example "works", but Squid will match "goodAgent" in your first line, and exit without going on. I require to apply other rules afterwards. In other words, my intention was to first filter based on the UA string, and block all except eg. MyAllowedUAstring. From then on, I need to apply the rest of my rules.
clientAccessCheckDone: The request CONNECT 89.16.167.134:443 is DENIED; last ACL checked: allowed_useragent
As you can see, your CONNECT request was denied (because it lacks the
User-Agent header). The rest does not matter much (for now), but Squid
bumps the connection to serve the error page in response to the first
bumped HTTP request (regardless of what that first bumped HTTP request
looks like).
So... What is the security implication of allowing all CONNECT messages to port 443?
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.
...
I'd greatly appreciate your input on this.
Hoping to understand Squid logic someday.
To speed that up enable debug_options 28,3.
I second Alex's recommendation about removing the "denied_" and
"allowed_" bits of your ACL names. It will make what is going on a LOT
clearer to see and understand.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
