I'm having a small war with my webhost's support department. I'll be happy to be proven wrong, but proving is what is required here.
I'm hosted (web, email, etc) on a shared server running linux and managed using cpanel.
This weekend, I lost the ability to log into my email and my cpanel administrative console... but only when doing so from my home network via http, pop, and imap. Outside my network (from the office, from Mickey D's, from my iPhone, etc) all access is normal.
What does "lost the ability" mean here? When I try to access either the cpanel console or email via a web browser, I'm issued a Basic Authentication challenge for user ID and password. (imap and pop just fail.) I supply the credentials and am then issued the same challenge. This will repeat ad nauseam. When I finally relent and cancel the challenge prompt, the "normal" login page is display with a message stating "login invalid". I say "normal" in quotes because I don't usually see it... I normally bypass it when my credentials are accepted.
Support keeps claiming that this is a firewall issue OR that something is blocking or changing the traffic on a hop between my system or theirs. I disagree. I am able to get to the server, the web server issues the authentication request for the right Realm, my browser displays the authentication challenge dialog, the server appears to receive my response and then issues another http response code of 401.
The ONLY thing that changed this weekend is that my WAN IP address was changed. I confirmed this by checking my dyndns account logs and confirming that I updated the IP address there on Saturday (when this started) and that it had not been changed in quite some time befor that... definitely not in the prior 5 days according to logs, but probably much much longer.
I've included headers below (sanitized) that show I send a GET, receive a response denying access, send the GET again with a the normal authentication header, and then get another response denying access.
This tells me that I am getting through the firewall, getting through to the web server, processing responses from it, and being denied access by the AUTHENTICATION process. I'm assuming that their authentication method (which they won't reveal) includes something like a pam module similar to pam_abl which denies access based upon host or IP. I'm also assuming that the IP address I was just assigned was previously blacklisted.
So, for the reality check. Am I right in stating that this MUST be an authentication problem and not a firewall problem? Consider the headers below (sensitive data scrubbed).
I've asked them to verify that they are actually receiving what I am sending (as shown below). I've also asked them to verify that what I am receiving is actually what they are sending. I'm hoping that if I can get them to confirm that they actually are getting what I send and they actually are sending what I'm receiving AND denying access, that they will FINALLY turn their attention to their authentication mechanism.
I could call my ISP (separate entity) and ask them to force a new IP address for me, but I'm really more interested in solving the problem rather than dancing around it... and not knowing when/if it will bite me again with the next IP address I'm assigned.
So, any reason to believe that this is something other than an Authentication problem? Do you see anything that would support a possible firewall problem, some port blocking between my system and the webhost, or some modification of traffic between the two systems?
===Initial request:
GET / HTTP/1.1
Host: <valid host>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
===Initial response (with authentication request):
HTTP/1.1 401 Access Denied
WWW-Authenticate: Basic realm="WebMail"
Set-Cookie: webmailrelogin=no; HttpOnly; path=/; port=2095
Set-Cookie: webmailsession=%3aba4stZaMp44lJnAZy2mduGv_FOLtxArhLvTjrNX5xoqPa1A46MZrCmReAiJVr7bb; HttpOnly; path=/; port=2095
Server: cpsrvd/11.34.1.7
Content-type: text/html; charset="utf-8"
Connection: close
Date: Tue, 05 Feb 2013 05:07:29 GMT
Content-Length: 17936
===Request after authentication challenge (note the authorization header):
GET / HTTP/1.1
Host: <valid host>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Authorization: Basic <valid Base64-encoded user and password>
Cookie: webmailrelogin=no; webmailsession=%3aba4stZaMp44lJnAZy2mduGv_FOLtxArhLvTjrNX5xoqPa1A46MZrCmReAiJVr7bb
===Response after authentication attempt (note the denial response code):
HTTP/1.1 401 Access Denied
WWW-Authenticate: Basic realm="WebMail"
Set-Cookie: webmailrelogin=no; HttpOnly; path=/; port=2095
Set-Cookie: webmailsession=%3aH0zJdjlwPcMNkVig_qFIT3waIt_10_te52LjYx0n_SKSw6CLvFJJo04w6AML2fDh; HttpOnly; path=/; port=2095
Server: cpsrvd/11.34.1.7
Content-type: text/html; charset="utf-8"
Connection: close
Date: Tue, 05 Feb 2013 05:07:37 GMT
Content-Length: 17954
I'm hosted (web, email, etc) on a shared server running linux and managed using cpanel.
This weekend, I lost the ability to log into my email and my cpanel administrative console... but only when doing so from my home network via http, pop, and imap. Outside my network (from the office, from Mickey D's, from my iPhone, etc) all access is normal.
What does "lost the ability" mean here? When I try to access either the cpanel console or email via a web browser, I'm issued a Basic Authentication challenge for user ID and password. (imap and pop just fail.) I supply the credentials and am then issued the same challenge. This will repeat ad nauseam. When I finally relent and cancel the challenge prompt, the "normal" login page is display with a message stating "login invalid". I say "normal" in quotes because I don't usually see it... I normally bypass it when my credentials are accepted.
Support keeps claiming that this is a firewall issue OR that something is blocking or changing the traffic on a hop between my system or theirs. I disagree. I am able to get to the server, the web server issues the authentication request for the right Realm, my browser displays the authentication challenge dialog, the server appears to receive my response and then issues another http response code of 401.
The ONLY thing that changed this weekend is that my WAN IP address was changed. I confirmed this by checking my dyndns account logs and confirming that I updated the IP address there on Saturday (when this started) and that it had not been changed in quite some time befor that... definitely not in the prior 5 days according to logs, but probably much much longer.
I've included headers below (sanitized) that show I send a GET, receive a response denying access, send the GET again with a the normal authentication header, and then get another response denying access.
This tells me that I am getting through the firewall, getting through to the web server, processing responses from it, and being denied access by the AUTHENTICATION process. I'm assuming that their authentication method (which they won't reveal) includes something like a pam module similar to pam_abl which denies access based upon host or IP. I'm also assuming that the IP address I was just assigned was previously blacklisted.
So, for the reality check. Am I right in stating that this MUST be an authentication problem and not a firewall problem? Consider the headers below (sensitive data scrubbed).
I've asked them to verify that they are actually receiving what I am sending (as shown below). I've also asked them to verify that what I am receiving is actually what they are sending. I'm hoping that if I can get them to confirm that they actually are getting what I send and they actually are sending what I'm receiving AND denying access, that they will FINALLY turn their attention to their authentication mechanism.
I could call my ISP (separate entity) and ask them to force a new IP address for me, but I'm really more interested in solving the problem rather than dancing around it... and not knowing when/if it will bite me again with the next IP address I'm assigned.
So, any reason to believe that this is something other than an Authentication problem? Do you see anything that would support a possible firewall problem, some port blocking between my system and the webhost, or some modification of traffic between the two systems?
===Initial request:
GET / HTTP/1.1
Host: <valid host>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
===Initial response (with authentication request):
HTTP/1.1 401 Access Denied
WWW-Authenticate: Basic realm="WebMail"
Set-Cookie: webmailrelogin=no; HttpOnly; path=/; port=2095
Set-Cookie: webmailsession=%3aba4stZaMp44lJnAZy2mduGv_FOLtxArhLvTjrNX5xoqPa1A46MZrCmReAiJVr7bb; HttpOnly; path=/; port=2095
Server: cpsrvd/11.34.1.7
Content-type: text/html; charset="utf-8"
Connection: close
Date: Tue, 05 Feb 2013 05:07:29 GMT
Content-Length: 17936
===Request after authentication challenge (note the authorization header):
GET / HTTP/1.1
Host: <valid host>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Authorization: Basic <valid Base64-encoded user and password>
Cookie: webmailrelogin=no; webmailsession=%3aba4stZaMp44lJnAZy2mduGv_FOLtxArhLvTjrNX5xoqPa1A46MZrCmReAiJVr7bb
===Response after authentication attempt (note the denial response code):
HTTP/1.1 401 Access Denied
WWW-Authenticate: Basic realm="WebMail"
Set-Cookie: webmailrelogin=no; HttpOnly; path=/; port=2095
Set-Cookie: webmailsession=%3aH0zJdjlwPcMNkVig_qFIT3waIt_10_te52LjYx0n_SKSw6CLvFJJo04w6AML2fDh; HttpOnly; path=/; port=2095
Server: cpsrvd/11.34.1.7
Content-type: text/html; charset="utf-8"
Connection: close
Date: Tue, 05 Feb 2013 05:07:37 GMT
Content-Length: 17954
Facebook
Twitter