Tag: .htaccess

  • How to block spambots by user agent using .htaccess

    How to block spambots by user agent using .htaccess .Originally published May 27, 2008, I’ve bumped this up a bit in the queue after some edits.

    Spambots and spiders that ignore robots exclusion file can kill your site both in bandwidth and by potentially exposing information you don’t want ‘harvested.’ With that in mind, here is a quick-n-dirty guide to blocking spambots and rogue search engine spiders by using .htaccess. First the essential example codeblock, followed by a working example:

    essential example codeblock

    # redirect spambots & rogue spiders to the end of the internet
    Options +FollowSymlinks
    RewriteEngine On
    RewriteBase /
    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} ^spambot
    RewriteRule ^(.*)$ http://www.shibumi.org/eoti.htm#$1 [R=301,L]

    Next is to read my article on how to quickly check your error logs for oddities … which should provide you with a list of all sorts of unusual user agents worth blocking.

    With said list, all that is left to do is create a working version that instead of sending people to the end of the internet, blocks them outright – which is probably a better move then sending the traffic elsewhere:

    real-world/working example

    # redirect spambots & rogue spiders to the end of the internet
    Options +FollowSymlinks
    RewriteEngine On
    RewriteBase /
    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
    RewriteCond %{HTTP_USER_AGENT} ^EmailSearch [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ URL [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector
    RewriteRule .* - [F,L]

    Note I provide 4 examples:

    1. ^$,
    2. ^EmailSearch
    3. ^Microsoft\ URL
    4. ^Web\ Image\ Collector

    All to demonstrate how to use perl-like regular expressions parse out the user agent. For example:

    1. ^ – identifies the beginning of the user agent string
    2. $ – identifies the end of the user agent string
    3. \ – that is a slash with a space afterwards tells the parser to include the space between words
    4. [OR] – is placed after each of the multiple entries, except the last
    5. [NC,…] – is sometimes placed after an entry to scan it w/out concern to upper or lower case

    In the process, I’m intentionally blocking empty user agents using .htaccess – “^$” – a search string that uses a regular express to test for nothing between the beginning “^” and end “$” of a user agent token. Sorry, but if you’re not willing to tell me who/what you are, I’m not willing to show you my content.

    Also, be aware the above requires that you have mod_rewrite installed on your Apache server, and that you have privileges to create your own rewrite rules in your own .htaccess file. If you’re not sure, check with your hosting service and/or system administrator.

    In most cases, such privs & access exists – but your mileage may vary – as they might in how your particular .htaccess file actually works in-the-wild.

    That said, more tomorrow or Thursday on how to create cron job to list those “unusual user agents” ‘automagically‘ for easy identification – and if needed -anti-spam remediation.

  • 5 things we can learn from my 7:40 AM Thanksgiving wake-up call

    I believe it was the slam of a large piece of plywood falling 2 some-odd stories onto other lumber that rudely awoke me at 7:40 AM this Thanksgiving morning.  An no, I couldn’t go back to sleep as the hum of a noisy air compressor placed precisely next to the property line driving the pneumatic hammers were equally annoying. That was the scene at my home this holiday.

    trash next door
    trash heap at 5244 levering mill rd, apex, nc

    D&G Builders of Fuquay Varina proceeded to work on a new house.

    A house next door being constructed on behalf of PenfieldHomes.com.

    And after a few emails and phone calls to a project manager of construction who informed me that “Mexicans don’t celebrate Thanksgiving like us …”

    So after telling said project manger that I didn’t want a feud, I apologized if anything we said or did offended (though I’m truly hard pressed to think of any such word or deed) – and he in turn called off the work squad – and I began to think of how similar situations can impact the peaceful operation of our church and charity websites.

    In other words, just as noisy neighbors and/or construction are a nuisance in the real world, so too can the virtual home of our organization’s web presence can be disrupted by inconsiderate acts.  Here are some analogies that come to mind:

    1. Noise
    I had an experience lately where some blogs I run on a shared server were inaccessible due to the incoming noise from a bunch of spammers and ‘bots. This was because a neighboring domain sharing the same IP had put up a BBS in an unsecured fashion.
    2. Obstructions
    It’s only happened once, but a truck was recently parked that partially blocked our driveway. In the same way, access to your site can be obstructed in part and/or in whole when those working on and/ror running the website ‘next door’ with an improperly parked modules and/or run-away program that consumes all the server’s memory and ports.
    3. Trash
    Nobody like’s picking up someone else’s garbage. My wife is no exception, as she recently found herself picking up unsecured McDonald’s bags that had blown into our yard. In the same way, neighboring website projects can also leave rubbish in the form of temporary files, no-longer used compiler settings and the like.
    4. Boundaries
    The Wake County, NC ‘UDO‘  defines a minimum number of feet in which a new home structure can be built next to another, how much noise is acceptable and other fun stuff like that. However, just because these rules are on the books doesn’t mean they’re going to be enforced. Meaning, it is going to be up to me to look out for instances of encroachment. In the same way, don’t expect or assume the host of your shared server is going to have your best interest in mind. They don’t and won’t. It is up to you to be diligent be on guard for those times neighboring websites and/or webmasters wander into your domain – and to work within the boundaries of good citizenship and the rules to resolve such issues.
    5. Communications
    If possible, establish one point of contact and a protocol for those situations where you feel you’re on the receiving end of some inconsiderate instances or situations. For example, know the correct channels of communications for your web host, and if feasible, for your IP Neighbor. Similarly, understand that email, though convenient, can lead to a breakdown that leads to unnecessary and unfortunate bad blood. Especially true when individuals on the other side are already having a bad day due to some other unrelated inconsideration. In all cases, keep track and logs of all such communiqués as you never know when you’ll need them.

    Anyway, those are my thoughts this Thanksgiving morning as I ignore the slam of pneumatic hammer guns and the humming whir of the air compressor and set my thoughts onto some delicious Greek Chopped Meat Stuffing and football.

    Well that and all the wonderful ways in which I’ve been blessed, including my family, my friends, my job, my church, and also the hundreds of visitors to this site – many of whom have sent me private messages of best wishes. Thank you all. I’m very grateful for every remembrance of you (Philippians 1:3).

    And with that, here are some links to some other related articles I’ve posted in the past. These include some practical advice on “how-to” implement some of the safeguards, countermeasures and logging I’ve mentioned above:

    Now if you don’t mind me, I’m off to E-Bay and/or Craigslist to find an affordable ANSI S1. 2-1962 sound level meter to leverage. I’m hoping I don’t need it but one never knows.

  • How to block a range of IPs from spamming your church website

    Using a blog to manage a website’s content is a flexible and affordable solution more and more churches are employing to effectively present their message online. There is however one drawback – in that some of the open source blogging solutions used as content management on the cheap also tend to attract attention from nere-do-wells who attack the comment and content functions of application such as WordPress and MovableType with robotic floods of advertisements offering anything from enlarging various appendages to curing male baldness all while losing your life’s saving playing poker online.

    What’s worse is that many of these attacks these days come from servers in countries where you have absolutely no legal, let alone social, recourse to stop said attacks. Take for example a recent slam of attacks on a new dedicated server I’ve been working on – all which failed due to recent preventative security endeavors – but all incoming from a block of related IP addresses from a server in China all of whose addresses had 218.25.161… in common.

    And while these unwanted advances were successfully thwarted by various server hardening practices implementations – the best way to avoid trouble from said attacker is to just deny access to anything on the server by denying the range of IP addresses indicated in my security logs.

    With that in mind, I thought I’d share two approaches to blocking a range of IP addresses. One solution at the firewall level – the path I prefer on dedicated servers, the other solution is blocking IP blocks via the .htaccess file, which are employed on sites hosted on a shared server.

    Using APF firewall, I simply create an entry that defines the block – in this case:

    218.25.161.0/24

    In the .htaccess file:

    <Limit GET HEAD POST>
    order allow,deny
    deny from 218.25.161
    allow from all
    </LIMIT>

    Both implementations block IP addresses from 218.25.161.0 through 218.25.161.255. But what happens if I only want to block addresses from a smaller set of addresses? Like those coming from someone abusing their DSL services whose range of dynamically assigned IPs may only be a range of 216.12.201.150 through 216.12.201.200.

    That becomes trickier as is requires both a knowledge of the ‘CIDR notation’ and the bit mapping that goes along with it. Which is why I recommend instead using this nifty little online tool from Mikero.com. An easy-to-use service which performs all the bit-blasting, while also “aligning” the range so it can be expressed in correct CIDR notation.

    Or in laymen’s terms, I add the following generated range to my firewall:

    216.12.201.128/25

    Or where no such firewall access is available, the following line in my .htaccess file:

    deny from 216.12.201.128/25

    Below are some tools and links on the topic of how to block a range of IP addresses if you want to dig into it a bit further.

    Online tools to calculate an IP address range (CIDR):

    Online tools to check/verify your CIDR notation:

    Tutorials on blocking IP addresses and CIDR subnet masks:

    Pre-fabricated blacklists to block IP addresses of entire countries:

    A bit more on .htaccess and mod_access:

    Just remember to keep good backups of whatever files you’re working on – and try not to lock yourself out while experimenting with changes!