Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without se

I started having this problem, too.

Public site is accessible, backend rejects my login with Error code: ERR_EMPTY_RESPONSE

It is a godaddy-hosted site. It is NOT ISP-related. It is NOT related to my current IP address; as this was also happening at my work location. It is NOT local hardware (router, switch, access point, etc). It is NOT .htaccess-moving it neither fixed; nor broke anything.

I must conclude that if the major hosts have begun to block BF attacks by blanket blacklisting IP addresses (a foolish idea, IMO), then I have gotten caught up in it.

I will contact them and let you know. Sorry for littering up your forum, AITpro, but I thought I’d reply.

Your not littering at all. This info is collectively valuable and could help someone else. So thanks for contributing. ??

And yes I have seen Hosts all around the World implementing preventative security measures to combat the massive amounts of traffic generated by these ongoing automated Brute Force attacks. I can only imagine what a pain in the neck this is for them. For us it is a nuisance on our websites so multiply that nuisance by 10,000, 100,000, 1,000,000, 1,000,000,000….. for web hosts and that has got to be a helluva mess for the Hosts to deal with.

So yep the next step is to contact your Host and have them do whatever is necessary.

There is another issue I have seen pop up here and there and it appears to be DNS related, but not at/with the Host’s DNS Servers if that makes any sense. The symptoms are exactly what is occurring for you. I mentioned the scenario earlier in this thread and have now seen/been contacted about this same issue/problem several more times. I really don’t understand enough of the problem to be able to offer a theory about it.

But I’ll take a wild laymans terms guess – some kind of routing issue with worldwide traffic is bottlenecking and screwing things up. Example of how this is logical: when you first buy a domain name it can take anywhere from 15 minutes to 48 hours to propogate to all DNS Servers. Those would be the DNS Servers where the bottleneck or whatever else is occuring. ??

It obviously seems more likely that the problem is occurring directly with your Host Server, but like I have mentioned earlier I am seeing some very strange DNS issues that I have never seen before. So I have no point of reference to compare them with anything else.

GD had to “whitelist” me. They spent over an hour today with the “upper level techs” looking at every line in the error logs. Concluded my IP was “Jinxed” so I may contact my ISP and ask for a new IP address. (If I can that is.) It’s a mess. I am p*ssed off to no end, GD has it on their “radar”. It’s a wait and see. They are giving me deals because of my “patience”…which I am “banking” for now. It still is upsetting though. Meanwhile, I thought WP 3.6 was supposed to be entirely different in the looks and use department. Wonder what 4.0 will bring.

AITpro: Godaddy has confirmed a “known issue”. It appears that it is not security, so much as it is a connectivity issue with one of their main mysql servers.

Also noticed this afternoon: all connections to their hosting domain (secureserver.net-where quite a few of their hosting tools reside) are timing out.

I am glad to hear that Go Daddy is acknowledging these issues. Nothing is more frustrating then hearing a corporate scripted response. Used to work in giant corporations myself for a couple of decades so I know the routine/script – You are instructed on what you can and cannot say to customers. ?? In defense of this corporate methodology, I have seen wide spread panic and an abandon ship epidemic by customers when the wrong message/status is stated to customers. ??

Yes, these ongoing automated Brute Force attacks are wreaking havoc all over the World. They are directed at any site type that has a login: WordPress, Joomla, Drupal, etc, etc, etc, etc…

We have been very lucky that our particular Go Daddy Host Server has been stable throughout the ongoing attacks. We are doing anything and everything we can to help the situation by getting out some additional Brute Force Login attack code and options out to folks ASAP. We cannot of course directly help Hosts with Server issues, but at least we can help individual website owners.
https://forum.ait-pro.com/forums/topic/protect-login-page-from-brute-force-login-attacks/

WP held off on the new media features in WP 3.6, but the new revision features are freakin amazin!

The issues that we were seeing are now resolved.

As for your plugin-I like it a lot. I have loaded it and created new .htaccess controls.

Can I tweak the .htaccess files to restrict access based on username, instead of IP? My partner has spotty/random internet access, so I can’t enable the bulletproof login .htaccess.

IP addresses are a Header field/Request to your website and can be filtered, but a username would be a form field POST or GET so that is a different thing that could not be filtered by Request.

Maybe what you are looking for is the Simple Query String Login Protection code in the Brute Force protection code that is posted in the link above? By adding that function to your Theme’s functions.php file you would ONLY be able to access the Login page if the “secret” Query String is used in the login page URL otherwise you would be redirected to your site’s home page or of course you could change the redirect URL to something like this: https://www.fbi.gov/about-us/investigate/cyber/cyber/. I’m sure the FBI would appreciate the visitor traffic. LOL

That was just a joke – DO NOT redirect bot traffic to the FBI site. They will NOT be happy about that at all.

Haha. Yes, I’m sure they’d appreciate it.

Yes, your secret string query is exactly what I’m looking for.

Thanks.

BTW, adding the secret string query didn’t seem to prevent login from the wp-login page. It threw a header error, but let me log in like normal. On the mysecretstring page, it acknowledged the string, and allowed login.

Meanwhile GODADDY told me at 04:00AM US Central that they have NO KNOWN ISSUES! I would say someone is lying and it’s not me!

Time for a hosting change I think!

I am unable to access my Dashboard but able to log in and get told that

Unable to load the webpage because the server sent no data.
Reload this webpage.
Press the reload button to resubmit the data needed to load the page.
Error code: ERR_EMPTY_RESPONSE

Joomla on GoDaddy is also handing me the same b.s.

Try a tracert on your blog page url and see how long it takes to time out.
I did 30 hops and I timed out after line 6 out 30! I had a friend use their ISP and do the same thing and their times per hop were 50-127 ms. Somebody has a problem and it is not my ISP! They checked their network two weeks ago. Something snapped from me on Thurs 2013 1 Aug.

I am conceding defeat!

Hey chew on this bunch of code from my .htacces for WP 3.6

Anything in here that should be removed? These are the “known” ip’s that have been blocked by WordPress so I am “told.” What does all this crap mean?

# BEGIN Better WP Security
Order Allow,Deny
Deny from env=DenyAccess
Allow from all
SetEnvIF REMOTE_ADDR “^144\.76\.95\.231$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^144\.76\.95\.231$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^144\.76\.95\.231$” DenyAccess
SetEnvIF REMOTE_ADDR “^144\.76\.95\.232$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^144\.76\.95\.232$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^144\.76\.95\.232$” DenyAccess
SetEnvIF REMOTE_ADDR “^157\.55\.32\.147$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^157\.55\.32\.147$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^157\.55\.32\.147$” DenyAccess
SetEnvIF REMOTE_ADDR “^157\.55\.32\.88$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^157\.55\.32\.88$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^157\.55\.32\.88$” DenyAccess
SetEnvIF REMOTE_ADDR “^157\.56\.92\.152$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^157\.56\.92\.152$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^157\.56\.92\.152$” DenyAccess
SetEnvIF REMOTE_ADDR “^173\.199\.114\.115$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^173\.199\.114\.115$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^173\.199\.114\.115$” DenyAccess
SetEnvIF REMOTE_ADDR “^199\.58\.86\.209$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^199\.58\.86\.209$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^199\.58\.86\.209$” DenyAccess
SetEnvIF REMOTE_ADDR “^24\.230\.50\.166$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^24\.230\.50\.166$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^24\.230\.50\.166$” DenyAccess
SetEnvIF REMOTE_ADDR “^62\.194\.71\.106$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^62\.194\.71\.106$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^62\.194\.71\.106$” DenyAccess
SetEnvIF REMOTE_ADDR “^62\.212\.73\.211$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^62\.212\.73\.211$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^62\.212\.73\.211$” DenyAccess
SetEnvIF REMOTE_ADDR “^83\.149\.126\.98$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^83\.149\.126\.98$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^83\.149\.126\.98$” DenyAccess
SetEnvIF REMOTE_ADDR “^69\.197\.129\.42$” DenyAccess
SetEnvIF X-FORWARDED-FOR “^69\.197\.129\.42$” DenyAccess
SetEnvIF X-CLUSTER-CLIENT-IP “^69\.197\.129\.42$” DenyAccess
# END Better WP Security

I am betting these are known server blocks!

@shamrock1961 – this is Better WP Security .htaccess code. it is possible that the Better WP Security plugin/code is causing the 324 error. Deactivate the Better WP Security plugin. Make a backup of your root .htaccess file and your wp-admin .htaccess file (if you have one) and then delete the .htaccess files from your website. Test everything.

@samroza – not completely following what you posted. Post the header error. Calling the login_head action from a theme’s functions.php file is not the ideal scenario and this action should really be performed from the BPS /bulletproof-security/includes/login-security.php file that contains the WP Authenticate code. In the next BPS release I will add this as a new option in BPS Login Security.