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
