0

To protect my website on a shared hosting plan, I added this to my .htaccess file:

<Limit GET HEAD POST>
order deny,allow
deny from .ru
deny from .cn
deny from .in
deny from .de
deny from .cz
deny from .kp
deny from .kr
deny from .ng
deny from .pk
# other allows go here -- below is just a sample
allow from 10.10.10.
</Limit>

I ran like that for an entire year without issue. I also know that it worked because some guy from Germany said, "Hey, I heard about your website, but I can't connect to it." So, I got to trusting him and poked a hole through for him. He then said, "I can see your site. Thanks!" (The reason I block the above countries is two-fold -- one, they're not my target customers at all, and two, I was getting heavy spambot traffic from those countries.)

Within a week ago, however, the shared hosting plan server was upgraded to the latest CentOS and cPanel. Now all of a sudden I'm getting 13 to 15 second page loads. If I comment out the above block, then no slowdowns at all -- super fast page loads.

I tested from my Linux and Windows workstations at home testing with Opera, Safari, Chrome, Firefox, and IE. My neighbor, running Windows and Firefox, is on Frontier Communications DSL like me and she has the same latency.

My clients and the web hosting provider as well get instant page loads. It's only the connection with Frontier Communications DSL that's having the problem.

I replaced my DNS as a test. On Linux I can edit my /etc/resolv.conf and use Google DNS, and the web gets faster. However, again -- still latency to my website.

I know that if I call up Frontier, all they will say is they don't know why the problem is occurring and that the problem is the web hosting provider. When I called my web hosting provider (a2hosting.com), they told me that the problem was only with my ISP, Frontier Communications, and that I should call them.

What is the cause of this slowness only with Frontier Communications?

ServerChecker
  • 1,518
  • 2
  • 14
  • 35
  • Are you absolutely certain that the slowness is isolated to just your ISP? And would your hosting provider be willing to help you out with diagnostic information like logs or packet captures? – Shane Madden Apr 28 '12 at 06:53
  • Yes, just my ISP. See my answer below. Turns out there's a significant problem with Frontier Communications and Verizon DSL customers on how Reverse DNS is implemented. I emailed hostmaster at frontier dot com to request that they look into it. Then, I created a workaround, which is in my answer. No, my hosting provider won't give me access to logs or packet captures. However, I filed a ticket with them to inspect how their reverse dns works between the web server and frontier communications. – ServerChecker Apr 28 '12 at 08:57

3 Answers3

2

Restricting by domain means that for every request apache needs to do a reverse DNS lookup. This is where the slowdown comes from. There is no simple workaround for this.

Update: A workaround would be to implement geoip in your application in order to decide where a request comes from (see here). With this your site will be blazingly fast compared to what you have now.

Oliver
  • 5,973
  • 24
  • 33
0

you could block the ips directly: http://www.wizcrafts.net/chinese-blocklist.html

frugi
  • 101
-1

This was an answer I adapted from @Oliver.

He was right -- suddenly this web hosting provider was having major trouble with reverse DNS lookups, and Verizon (and therefore Frontier Communications, which bought out most rural Verizon DSL accounts) is notorious for being slow in providing all the necessary responses on reverse DNS calls. I mean, I've noticed that some SSH connections I do with various servers on the Internet are slow simply because my ISP doesn't do reverse DNS properly.

So, I needed a workaround. I implemented it like so:

# I HAVE NO FREAKING IDEA WHAT THIS DOES, BUT CPANEL AUTOMATICALLY CREATES IT
<Files 403.shtml>
order allow,deny
allow from all
</Files>

# THIS IS FOR FUTURE EXPANSION -- I CAN DENY BY INDIVIDUAL IP ADDRESSES HERE,
# OR I CAN ALLOW CERTAIN IP ADDRESS HERE. I CANNOT, HOWEVER, ADD DOMAIN TLDS LIKE
# .ru HERE BECAUSE OF THE REVERSE DNS SLOWDOWN WITH THIS WEB HOSTING PROVIDER.
# FOR THAT, I USE THE REWRITE RULES BELOW.
<Limit GET HEAD POST>
order deny,allow
</Limit>

# THIS IS IMPORTANT. WHAT IT DOES IS LOOK AT ALL THE OTHER HTTP TYPE OF ACTIVITIES
# LIKE WEBDAV (A SECURITY HOLE, POTENTIALLY) AND BLOCK THOSE, LEAVING ONLY NORMAL
# BROWSER STUFF WHICH IS ALWAYS POST, HEAD, AND GET.
<LimitExcept POST HEAD GET>
deny from all
</LimitExcept>

# TURN ON REWRITE RULES
RewriteEngine on

# CHECK THE HOST NAME SENT BY THE BROWSER AND BLOCK IT WITH 403 FORBIDDEN IF
# FROM PARTICULAR COUNTRIES.
RewriteCond %{REMOTE_HOST} \.ru [NC,OR]
RewriteCond %{REMOTE_HOST} \.cn [NC,OR]
RewriteCond %{REMOTE_HOST} \.in [NC,OR]
RewriteCond %{REMOTE_HOST} \.de [NC,OR]
RewriteCond %{REMOTE_HOST} \.cz [NC,OR]
RewriteCond %{REMOTE_HOST} \.kp [NC,OR]
RewriteCond %{REMOTE_HOST} \.kr [NC,OR]
RewriteCond %{REMOTE_HOST} \.ng [NC,OR]
RewriteCond %{REMOTE_HOST} \.pk [NC]
RewriteRule .* - [F]

# NOW PLACE YOUR OTHER REWRITE RULES YOU MAY HAVE HERE.
ServerChecker
  • 1,518
  • 2
  • 14
  • 35
  • 1
    This "workaround" eliminates the slowdowns simply because it doesn't do what you want. HTTP_HOST is not the host name of the client but the Host: header sent by the browser. Blocking access for whole countries using the domain name is a very **bad** idea: Not only does it slow down your site for everybody else, but it is also very easy to work around. – Oliver Apr 28 '12 at 09:06
  • It uses the 80/20 rule here. It's not perfect, it can be worked around, but blocks a lot. I can use IP blocking in the .htaccess for everything else. – ServerChecker Apr 28 '12 at 09:44
  • BTW, guess what happens when I go to the shared hosting provider and type "host " and "nslookup "? It reports connection timed out / no servers could be reached (SERVFAIL). But try another random IP and it works just fine. So, this tells me that Frontier Communications DSL has screwed up Reverse DNS. – ServerChecker Apr 28 '12 at 09:45
  • 1
    Your workaround is far from not perfect: HTTP_HOST doesn't contain the name of the client accessing the website, but the name of your website. Why should it end with .ru or .cn? It doesn't do anything, which is why it is so fast and which is why you think it solved the problem. – Oliver Apr 28 '12 at 10:51
  • Yeah, Oliver is right, the rules you've listed will effectively block no one. As he suggested, have a look at something like http://www.maxmind.com/app/mod_geoip – Shane Madden Apr 28 '12 at 16:21
  • Ah, you are right. It's not HTTP_HOST, but REMOTE_HOST. And even then -- it's not reliable. But, anyway, the GeoIP thing might be a solution, but my shared hosting provider won't install modules for me. – ServerChecker Apr 29 '12 at 05:52
  • I just ran a test and REMOTE_HOST is not enabled in the Apache on my shared hosting plan. – ServerChecker Apr 29 '12 at 06:04