[squid-users] How to avoid Squid disclosing the origin server IP when there is an error

[Xen]

On Sun, 27 Sep 2015, Amos Jeffries wrote:

> On 26/09/2015 11:48 p.m., Manuel wrote:

>> When Squid -even as a reverse proxy (which is my concern)- can not 
>> retrieve the requested URL, it dicloses the IP address of the server 
>> trying to contact with. Is there any way to hide that IP address to the 
>> public for security reasons?

> This is not a security problem.

Actually it is an issue of security. Exposure is directly related to 
attacker interest. If you give out information for free you lower the 
amount of work any person needs to do, which means you may become a more 
likely target than some other equivalent system. Staying low and avoiding 
attention is a perfect measure as long as you complement it with actual 
"access control" security.

> 1) security by obscurity does not work.

Seriously, that is just dogma being repeated over and over by people who 
just heard it one time and accepted it as their own truth, without really 
thinking it over. Security by obscurity works very well, the error is 
believing that it can *replace* the other type of security. It is not a 
replacement, it is a complement. It is not either/or, it is both/and. Even 
if you are the strongest fighter in the world, you don't go into town 
square and yell "attack me!" because there might just be that bullet 
pointed for your head. Exposure is a really problematic thing, and I have 
used "obscurity" to my advantage for instance in trying to get rid of 
people who were trying to physically target me. In the real world, 
obscurity is used constantly and ignoring it means certain death.


> 2) "127.0.0.1" does not leak any information other than a CDN proxy is 
> being used. The existence of the error page itself and several other 
> mandatory details in the HTTP protocol provides the exact same 
> information.

I don't know about the http thing, but in a sense telling your 
user/attacker that the real website is hosted on the same machine is 
information that can be used.

It's a bit like Linux distro's telling any person trying to unlock a LUKS 
container what is the device name of that LUKS container. That's really 
cute if you have lots of those and you need to see which one you are 
unlocking (but that is stupid in any case really) (bad design) but I 
certainly don't want any user of my system to know the hard disk / 
partition of an encrypted thing. TrueCrypt by contrast doesn't show this 
information. It just gives a password prompt. Sure anyone could take your 
harddisk out and study the partition table and learn about it this way, 
but then they would first need to demontage your system. It requires more 
effort and the effort, or the combined effort of all the challenges you 
present to any person, might just be too much for that person to care 
doing it.

Obscurity relates to the amount of effort required to crack a system. It 
is just a usage thing. If your product has bad documentation, many users 
will give up trying to use a certain feature. If the documentation is good 
and rapidly accessible, more users will use the feature because it costs 
them less time/energy/money to find out how to use it, which means getting 
to use it is cheaper to them. Most of what a user does in a computer (and 
in real life) is a cost/benefit calculation.

The same applies to attacking a system. If the cost becomes too high for 
the benefit that can be gained, people will just leave a system alone.

It is important.


> 3) If 127.0.0.1 interface on your server is accessible from a remote 
> machine; then you have much, much worse security problems that need
> fixing.

It's not really about that, I believe. Of course if you want to 
protect/hide your webserver you must ensure that it only answers to 
127.0.0.1 itself (the CDN) (or proxy, whatever) but all the same giving 
out 127.0.0.1 reveales information about your network topology.


> This is a privacy related thing.

> I say thing specifically because "problem" and "issue" would imply
> actually being a problem. There is zero privacy loss from server IPs
> being known. It is required to inform the client to prevent it repeating
> this query via other routes which intersect or terminate at the same
> broken server IP.

Then it is not a privacy thing. But if supposedly the real web server 
would actually be accessible, then it would allow the client specifically 
to repeat the query via a direct route to the webserver (provided it was 
not 127.0.0.1, or the client would translate that into the IP for the 
advertised/published webserver address. But perhaps I know nothing about 
http in this case and I just don't know what you mean ;-). It seems like 
advertising some address does not prevent anything.

> Example of the error message I am referring to:
> "The requested URL could not be retrieved
> 
> While trying to retrieve the URL: http://www.domainame.com/
> 
> The following error was encountered:
> 
> * Connection to 127.0.0.1 Failed

Aye, it is prettier as well if this information is not shown/leaked.

I usually have no need, for instance, for detailed database connection 
failure reports. It is ugly and exposes a lot of internals to your user. A 
common user will also be thinking "what is this shit?". It is not tailored 
for the presentation that was created for the website proper. If anything, 
an error message like that would need to get a message page that is in 
line with the semantics/display/appearance of the page/site itself. Just 
to be consistent and keep the encapsulation intact.

It's just common design principle. You don't want to scare the user either 
with weird stuff. These pages (not this one, I guess) even often invite 
the user to start sending email to the system administrator, when most 
often the problem is always temporary and a reload 5 minutes later solves 
the problem. And it is incomprehensible to most.

Anyway. Just something I have thought about quite a bit. And something I 
have used to my advantage in terms of being or remaining in a position of 
plausible deniability in the context of being forced, more or less, to 
reveal secrets, as well.

Regards,

Bart