1) I pay you, not otherwise. I've been your customer for well over a decade, so I think that alone is enough for you to respect me, though it doesn't seem like it.
Respect is a two way street. You accused us of being useless when we replied to your
MISLEADING original information with a follow up question which would prove what we suspected, that HTTPS had nothing to do with your issue. When trying to extract relevant information not volunteered is met with sneer and derision we cannot possibly hold an intelligent conversation. Despite that, I gave you my professional opinion which you rebuke in your new ticket, despite also providing hard evidence of its veracity!
In his "Apology" Socrates said to his accusers that he considers himself a wise man because "I know what I know and what I know I don't think I know it either". This quote has been my motto throughout my professional life. When I speak of something with conviction I do so based on my knowledge and experience. When I am not sure I say so. When I am wrong I will be the first to apologize for my mistake.
I understand that you have a lot of confidence in your ability to configure a server. Unfortunately, for someone like me who has a deeper understanding of how servers work, it's pretty clear that this confidence is unwarranted. You reach arbitrary conclusions based on partial knowledge.
If you'd like to understand why you are mistaken please read on. I will give my best effort to ignore your arbitrary conclusions and rude remarks and educate you on the knowledge you are missing. This is important, basic knowledge that you MUST possess if you want to manage your own server. Doing otherwise is irresponsible. It's like setting off to drive in heavy snowfall without understanding the physics of tyre grip and differentials; you'll end up in a ditch (and I think this is something that you've seen so many times on the streets of your country).
4) You said that in your opinion the IP that had been banned wasn't my public one, but 127.0.0.1 But why on Earth Admin Tools would ban a localhost? What for?
This actually proves my point from the previous ticket and disproves item #3 on this ticket. This is also the basic knowledge of how servers work that you are missing.
Admin Tools, Joomla and any PHP script will read the remote client's IP address from the REMOTE_ADDR environment variable set by Apache. This normally contains the IP address of the person making the request. This, however, will NOT be the case if there is something else between your remote user and Apache including the following (by no means a complete list): a proxy such as NginX in reverse proxy mode; a caching proxy such as Varnish; an SSL termination proxy such as HAProxy; a third party web application firewall which effectively acts as a proxy; a CDN. They are collectively called "proxies" because they all
proxy the request, i.e. the intervene between the remote client and your actual web server. Depending on where these proxies are located the REMOTE_ADDR in Apache will be your localhost (if they run on the same box and environment as your web server), an IPv4/IPv6 private network address (if they run in a VM on the same or different box; or running on other infrastructure inside the hosting network, e.g. isolated from the Internet behind a proxy/firewall/other router hardware), or an Internet address other than your remote client's (when they run on a different data centre as is the case with CDNs and SaaS web application firewalls).
If the proxy is set up correctly it will be passing along the IP address of the remote client in the HTTP header X-Forwarded-For which is a
de facto standard. As explained in our documentation, there's an option in Admin Tools to use that header (or the equivalent headers set by CloudFlare and Sucuri which do not follow the
de facto standard for some very sound security reasons). I already told you that you can go to Admin Tools, Web Application Firewall, Configure WAF and set Enable IP Workarounds to Yes.
The reason this option is NOT selected by default is that most of the sites of our clients ARE NOT behind a proxy OR they are behind a proxy but are set up in a way that Apache's REMOTE_ADDR is correctly set. In this most common case respecting the X-Forwarded-For header (which can be set by the remote client) is a massive security issue as it allows an attacker to spoof their IP address. Respecting that header is only safe when your web server is behind a proxy in which case the inbound X-Forwarded-For HTTP header is either dropped at the entry (Internet-facing) node OR amended with the real IP address of the remote user.
And that's why you're paying us good money. Not only we understand why REMOTE_ADDR may lie but we also have the good sense to not enable by default a dangerous option which could result in IP spoofing that opens your site to security issues. You're welcome.
5) I didn't claim that Fail2ban and Admin Tools were the same technically. I just said that that free tool never mistakenly triggers IP ban whereas Admin Tools does.
I would like to point out once again that comparing Fail2Ban to Admin Tools, even in the context of which IP address is banned, is disingenuous.
Fail2Ban works
ex post facto, analyzing your logs. If I recall correctly (this is something I am not certain about), it will ignore IPv4 / IPv6 reserved internal network addresses. Basically, in your setup, it does nothing at all. Unless, of course, you've set it up to analyze the logs of whatever proxy you have in front of Apache, in which case it will in fact block the correct address. But that's if and only if you've configured it correctly.
Admin Tools, on the other hand, runs inside Joomla which runs inside PHP which runs inside Apache. Its view of the requests is tainted by what Apache, PHP and Joomla have done to the request before it executes.
Comparing two pieces of software that run at entirely different levels of your stack is what makes the comparison disingenuous and insulting. Of course they will not ban the same IP addresses. They have a different view of the request and they are looking for different things. The discrepancy is tautological!
6) Okay, let's say that for whatever reason I was banned by Admin Tools. But why then deleting the whole public html folder and the database and using a back-up to restore the site to its previous state doesn't lift a lockup?
No. No, it doesn't.
It doesn't because what you did is keep your entire server to the last known bad configuration state. Therefore any security exception triggered by Admin Tools, either by yours or someone else's requests, will lead to 127.0.0.1 being banned. This is not an Admin Tools failure. It's the failure of the configuration of the server machine.
That can only mean one simple thing. That Admin Tools screwed something up in the system somehow. And if my server was wrongly setup as you said, then why after rolling back in time with a Clonezilla image magically makes everything work as a Swiss clock? How do you explain that? Again, in my servers' settings I didn't change anything pretty much.
No, this is an arbitrary conclusion based on wishful thinking, not facts. In fact, the facts say the exact opposite!
If you restore the
entire server machine to a different configuration state and everything works it proves that your server configuration is at fault.
Moreover, the fact that Admin Tools CAN NOT misconfigure your server machine is tautological, owning to the very fact that not only Admin Tools lacks any code to configure your server machine, it also runs under an unprivileged user which cannot possibly modify your server configuration or restart system services. This means that your actions were at fault.
I do not have enough information to tell you within any degree of certainty exactly what you did wrong. The fact that you refuse having made any change to your server -- something I know is not true, but I'll come to that -- is not conducive to acquiring more information from you.
However, I can speculate. You said that once you enabled HTTPS on your server things started going wrong. This tells me that you didn't just install an SSL certificate on Apache. My educated guess is that you read a tutorial about enabling HTTPS on Apache written at least two to three years ago (or regurgitating material from years past). Back then, the only way to enable HTTP/2 or SPDY on Apache was to either proxy the requests through NginX or use an SSL termination proxy such as HAProxy. In other words, you'd have unwittingly enabled a proxy in front of Apache without fully realizing the implications. I know
for a fact that if you just put NginX in front of Apache you'll end up with the exact problem you described. Hosts that know what they're doing (like SiteGround, our host for this site) also use a third party Apache module such as mod_rpaf to have Apache "see" the IP address in the X-Forwarded-For header and pass it along to REMOTE_ADDR. That's why using Admin Tools on SiteGround, which uses NginX as a reverse proxy in front of Apache for SSL termination and caching, works out of the box but in some other hosts or self-managed servers it requires using the Enable IP Workarounds setting. I also know
for a fact that merely enabling SSL in Apache itself does not cause this problem since there's no proxying involved. In fact, that's the very same setup I use on my main development machine.
So, please, think hard about what changes you made to your site when you "just enabled HTTPS".
Please do not dispute these objective facts. I've configured and troubleshot far more servers than you have and I really know why things get wonky. I know what I know. You should stop thinking that you know what you don't know. That's not a swipe at you, it's a friendly advice that will primarily help you manage your servers more efficiently and stay out of harm's way. And for God's sake, stop throwing accusations around. It's tiresome, distracting, irritating and I'm under no obligation to take them in stride per our Terms of Service. Thank you for helping me help you.
