Re: [squid-users] How to avoid Squid disclosing the origin server IP when there is an error
Hi again, Thank you for all the information regarding this matter. Anyhow, I must say that I changed in my message the origin server to 127.0.0.1 just to not make public the real address of the origin server but the address that was made public was the real IP of that origin server which was accesible from the Internet. Regards -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/How-to-avoid-Squid-disclosing-the-origin-server-IP-when-there-is-an-error-tp4673418p4673510.html Sent from the Squid - Users mailing list archive at Nabble.com. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] How to avoid Squid disclosing the origin server IP when there is an error
Hey Xen, I am not really a proxy expert and I am not really such a great security guy but both you and Amos are right. There are cases which revealing an internal IP address is a bad practice. Also there are other ways to identify the internal host which causes issues. In the specific case of 127.0.0.1 it really doesn't help a thing in most cases. Leaving aside horror stories from reality you might know much(as you declared) about proxies and I must invite you to the squid world of proxies. It's a great place to learn about http and many other things in general. The squid-uses is not a busy list but it is a great one. Take your time and ask or discuss, this is the place for that. There are sensitive systems that actually hides themselves behind a proxy since one of the names of a http proxy is "application layer firewall". It is a common usage of squid and other proxies. Do yourself a favor and leave books and movies on the desk for a second. please do that. I am not sure if you ever seen a room of jumpy IT managers that jumps because of some new bug but I have seen it couple times and it's amazing from what they jump. If you take some vulnerabilities and actually try to understand what and how they do what they do, you understand why some of them are not a real threat. Just back to the specific 127.0.0.1.. it's really nothing. it's like saying "I am a human I have a head". If you feel like it's something you don't want to give up on feel free to change the ERROR page, it is a common practice to replace them or use custom ones. If it what makes you sleep at night then be it. Leaving the 127.0.0.1 case aside banks do tend to not disclose internal IP addresses and it's a common sense if you have the right tools to give the user a nice and well formatted message that was audited by a security team. Is it security? definitely maybe! Just a sentence about the Internet, It's a nice and lovely place with lots of roses, wild animals and humans but squid is there to help all these who actually needs a http application level firewall system. So please leave jumpy IT managers and horror stories aside so you would just have enough memory and space for the reality. And I have a scene just for you to have some laugh time: https://www.youtube.com/watch?v=FW2Q0W2V4q0 The above video is a demonstration of what fiction does when a jumpy IT manager meets a security sales man. All The Bests, Eliezer On 27/09/2015 12:46, Xen wrote: Again, impressed by your knowledge. But I'm not really arguing against your knowledge. It is basically a principle choice to /call/ one thing security and the other privacy based on the impression or experience that the one thing provides actual defenses or benefits in certain common scenario's and the other doesn't. Perhaps that is pertinent to software security, but in that case it is a very specific field and you are going to define "security" in a very constrained way. Basically, it is then more of a normative statement "what do me and my buddies consider good enough" rather than a statement of definition. You are basically arguing that in (all) real world scenarios (of software/web/server security) the obscurity thing tends to converge on irrelevance. But even that is true, it is still not a defining characteristic, so to speak. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] How to avoid Squid disclosing the origin server IP when there is an error
Again, impressed by your knowledge. But I'm not really arguing against your knowledge. It is basically a principle choice to /call/ one thing security and the other privacy based on the impression or experience that the one thing provides actual defenses or benefits in certain common scenario's and the other doesn't. Perhaps that is pertinent to software security, but in that case it is a very specific field and you are going to define "security" in a very constrained way. Basically, it is then more of a normative statement "what do me and my buddies consider good enough" rather than a statement of definition. You are basically arguing that in (all) real world scenarios (of software/web/server security) the obscurity thing tends to converge on irrelevance. But even that is true, it is still not a defining characteristic, so to speak. And I am just not that experienced in securty. I barely know about side channel attacks because I did read one paper on a memory access (latency) "localhost" attack on I believe OpenSSH or something that required a local account to manipulate cache hits/misses. And my math was just not up to par to understand it :p. But I must say the way they narrowed down the possible set (or chains) of keys based on known information was very interesting. On Sun, 27 Sep 2015, Amos Jeffries wrote: 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, This tells me you dont have much actual experience with security, or not low-level enough. Real experience with attacks and working on 0-day tools is better than even just "thinking it over". Thats what I based my statement on. Though I do adopt the industry phrase to get the idea across clearly. But it's just not true. If all the world thinks that way and then devises systems and setups where it is practically useless, then it is still not true. Also, obscurity is not intended to defend against single-point-of-interest attacks. Or anything that makes you a really interesting target to those who already know you. The point and the problem is that this industry phrase is a judgement that really closes off thinking. You might even start missing out on opportunies that might help you. I mean, to give this example again. Perhaps it is not relevant when you have (or someone has) excellent scanning tools and all that. But usually, in the physical world, and in many many situations, thereof, there is certainly knowing or not knowing "the terrain". If you know where you are, for example, but your pursuer does not, it is obviously easier to escape. Now, if that pursuer was using helicopters, satellites, automatic camera surveillances and analysis, and tracking dogs to top it off :p, it would become a kind of different situation. So perhaps in (computer) security the status quo is that attackers and defenders both have access to that level of sophistication in every instance. And if information is almost never capable of being hidden, well, then perhaps you'd better become a brick wall, or better yet, a nuclear shelter. In lesser situations though it becomes perfectly clear that if you know how something works and someone else doesn't, you can use that to your advantage. You may not want to call that "security" but I would call it "escaping with my life". There is something about masculine 'security' and feminine 'security'. The one you are advocating is like masculine. Strong defenses. Not relying on luck, or surrendering to the flow of things. Certainty at every level. Guarantees. But often in life you also have to proceed based on confidence and intuition alone, and you may need to trust that conditions will meet where you want to be, when you get there. If you are exposed anyway because you are a big business and all that, there is already a design choice being made. Within certain choices already having been made, the resulting 'security landscape' is also informed by that choice or those choices. Then, given that practical reality, you end up in a status quo where some truths seem to hold. One of these conclusions may be "security by obscurity is not security". But that still doesn't make it true. It makes it dogma that is only true provided some well-established conditions remain in force. That means it is not universal but more of a "rule of fist" (Dutch phrase) -- a best practice or guideline you can always rely on. But it is actually a vulnerability. An attacker that is creative enough will see your (that) (not wanting to insult here) fixed mindset and know the blind spots that result from this fixation in thinking. This person would think "hey, that's curious". "They left this possibility open". "It just doesn't occur to them that anyone would do that". I'm sorry,
Re: [squid-users] How to avoid Squid disclosing the origin server IP when there is an error
On 27/09/2015 2:09 p.m., Xen wrote: > 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. > The server IPs are published in DNS. You had better remove those records since they are far more easily attacked than 127.0.0.1. I think you missed the point of my reply entirely. The security problem is the existence of the underlying error, not the message about it. >> 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, This tells me you dont have much actual experience with security, or not low-level enough. Real experience with attacks and working on 0-day tools is better than even just "thinking it over". Thats what I based my statement on. Though I do adopt the industry phrase to get the idea across clearly. > 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. Not for sane security. For privacy. The two are different, though complimentary. To take your analogy; walking into the town square keeping your mouth closed dressed in a cape and mask while someone is firing a machine gun all over the place will see you just as dead. They won't know who you are, but you'll still be dead. > >> 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. > But it does *not* tell that. HTTP is multi-hop. All the error message states is that 127.0.0.1 *somewhere* is unavailable. Good luck defining "somewhere". All it tells with certaintly is that there is at least one proxy operating. Attackers have zero information about whether that server is the origin server or just another proxy. They also dont have any info from that page about how many proxies down the chain the error was generated. Either way if erver X was the target they have to get to server X through the proxy they are already contacting and/or profiling, and cannot do so due to it being down and unavailable. It could as easily be one of these scenarios: CDN ISP node proxy -> CDN shard proxy -> ESI filter (127.0.0.1) -> origin CDN ISP node LB -> CDN node cache (127.0.0.1) -> CDN shard proxy -> origin CDN ISP node LB -> CDN node cache (127.0.0.1) -> CDN shard proxy -> ESI filter (127.0.0.1) -> origin ISP interception LB proxy -> ISP farm proxy (127.0.0.1) -> CDN -> origin Good luck if its the third one. Which is actually quite popular with all the major CDN. > > Obscurity relates to the amount of effort required to crack a system. It In a system relying on obscurity the effort required is near zero. System profiling takes under 10 HTTP messages and attack scan to find the obscured vulnerability takes however many needed to scan through CVE/0-day the attacker or their tools knows about for that combo of software. > 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. And what does published documentation have to do with proxy A failing to connect to some upstream server? This thread is not a
Re: [squid-users] How to avoid Squid disclosing the origin server IP when there is an error
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
Re: [squid-users] How to avoid Squid disclosing the origin server IP when there is an error
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. 1) security by obscurity does not work. 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. 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. 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. > > 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 > > The system returned: > > (110) Connection timed out > > The remote host or network may be down. Please try the request again. > > Your cache administrator is @ Thats a funky email address to have for administrative / webmaster contact. Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] How to avoid Squid disclosing the origin server IP when there is an error
Hey Manuel, The reason the client receives the destination IP or other details is due to the structure of the ERROR page. Depends on your OS you can find the ERROR page file and modify it so the format will meet your requirements. You can take a look at the wiki about custom error pages: http://wiki.squid-cache.org/Features/CustomErrors and specifically you will might need to change\remove the "%I" from the template. Or if you are willing to write a custom error page which is different from the squid defaults to meet your site visual structure. All The Bests, Eliezer On 26/09/2015 14:48, 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? 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 The system returned: (110) Connection timed out The remote host or network may be down. Please try the request again. Your cache administrator is @ Generated Sat, 26 Sep 2015 01:18:48 GMT" Cheers -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/How-to-avoid-Squid-disclosing-the-origin-server-IP-when-there-is-an-error-tp4673418.html Sent from the Squid - Users mailing list archive at Nabble.com. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
