Re: [squid-users] Rewriting URL

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 17 Feb 2012 23:51:34 +1300

On 17/02/2012 10:57 p.m., Matus UHLAR - fantomas wrote:
>> On 17/02/2012 6:10 p.m., Roman Gelfand wrote:
>>> Consider the following configuration...
>>>
>>> acl host1 dst host1.dom.com
>
> On 17.02.12 19:26, Amos Jeffries wrote:
>> "dst" is not a good idea. Any phisher attacker who wants to make
>> their website resolve to your servers internal IP can do so and
>> connect through this proxy to it.
>
> but the phishing site must still run on the destination site, am I right?

Maybe. That is the problem. This allows 99% of the page resources to be
genuine, including Captcha etc. It is merely difficult to run elsewhere,
not impossible.

It can only be closed with a name-based check somewhere. dstdomain in
Squid, or with some equivalent in the origin only accepting its
particular domains. Less network bandwidth is wasted doing it in Squid,
and better reporting about what is being rejected up front.

>
>> "dstdomain" is the recomended ACL type. That way the domain is
>> accepted or denied. The client can only reach Squid by resolving the
>> domain IP as this Squid box, so no security worries there. It also
>> lets you scale out the backend with any number of servers or peers,
>> and swap them about without involving DNS alterations (think TTL lag
>> on every change).
>
> By using dstdomain you can allow (reverse) proxying to one website (or
> more within the same domain). By using dst you can (reverze) proxy
> more sites on the same host/network.
>
> I think that using "dst" here is not the issue if we are talking about
> reverse proxy.
> Is there any situation I have missed?

Neither of the two is more or less limited in the domains they can
handle. Just a matter of whether you manage the list in squid's
config+DNS or just DNS. And whether you are rejecting false domains at
the orgin or at the system gateway. It can be easily scripted so not
that much of an issue up to large amounts of domains.

Noting that it is only recommended as good practice. Not a strict rule.

Amos
Received on Fri Feb 17 2012 - 10:51:46 MST

This archive was generated by hypermail 2.2.0 : Fri Feb 17 2012 - 12:00:03 MST