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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
