url_rewrite_program and ACLs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

url_rewrite_program and ACLs

Vieri
Hi,

I'm not sure I understand how url_rewrite_program works.

In the example below I'm trying to allow traffic from CLIENT_IP_ADDR to SERVER_DOMAIN_ADDR where CLIENT_IP_ADDR is in the allowed_ips ACL, and SERVER_DOMAIN_ADDR is in the allowed_domains ACL (I know it's redundant, but it's just an example).

http_access allow localnet !restricted_ips allowed_domains
http_access allow localnet !restricted_ips allowed_ips
http_reply_access allow localnet !restricted_ips allowed_ips
http_reply_access allow localnet !restricted_ips allowed_domains

[...]

url_rewrite_program /usr/bin/squidGuard
url_rewrite_children 80 startup=10 idle=3

http_access allow localnet

The problem is that the browser on the CLIENT_IP_ADDR displays the "redirect" page defined in squidGuard when trying to access SERVER_DOMAIN_ADDR.

I could configure the allowed_domains and allowed_ips ACLs within squidGuard itself, but shouldn't the Squid rule prevail anyway?
Is the redirection done regardless of what precedes in squid.conf?

Thanks,

Vieri
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: url_rewrite_program and ACLs

Amos Jeffries
Administrator
On 08/11/17 22:21, Vieri wrote:
> Hi,
>
> I'm not sure I understand how url_rewrite_program works.
>

Squid takes the URI from an HTTP request it is servicing and delivers it
to the helper. The helper delivers a new URI back to Squid (or not).
Squid then generates an entirely new HTTP request to use for server
contact instead of the client one. Squid delivers the server response to
that other request as the answer to the clients original request.

At no point is Squid doing any denial based on the URL-rewrite program.


> In the example below I'm trying to allow traffic from CLIENT_IP_ADDR to SERVER_DOMAIN_ADDR where CLIENT_IP_ADDR is in the allowed_ips ACL, and SERVER_DOMAIN_ADDR is in the allowed_domains ACL (I know it's redundant, but it's just an example).
>
> http_access allow localnet !restricted_ips allowed_domains
> http_access allow localnet !restricted_ips allowed_ips
> http_reply_access allow localnet !restricted_ips allowed_ips
> http_reply_access allow localnet !restricted_ips allowed_domains
>
> [...]
>
> url_rewrite_program /usr/bin/squidGuard
> url_rewrite_children 80 startup=10 idle=3
>
> http_access allow localnet


The http_access lines are checked to determine whether a client request
is allowed to be serviced. So the transaction can be allowed or denied here.

If allowed to process, eventually the transaction checks the
url_rewrite_access lines to determine whether the helper is involved
with adapting the transaction. Their default is "allow".

If the helper is used, the URL replacement may (or not) be given by SG
at that point. Its decisions are determined by its own config, not Squid.

The http_reply_access determines whether the server response is allowed
to be delivered. In this case the response is coming from your SG's
localhost server.

>
> The problem is that the browser on the CLIENT_IP_ADDR displays the "redirect" page defined in squidGuard when trying to access SERVER_DOMAIN_ADDR.
>  > I could configure the allowed_domains and allowed_ips ACLs within
squidGuard itself, but shouldn't the Squid rule prevail anyway?
> Is the redirection done regardless of what precedes in squid.conf?

The directive purposes matter. squid.conf url_rewrite_access determines
whether the helper is used. If those directives 'deny' the helper being
used, OR if the helper returns a no-change result (empty line or ERR)
there is no rewrite done.

PS. You do not need SG at all for access control and it is a lot simpler
and faster to drop the helper part of things entirely. Especially in
cases like this example.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users