Traffic Filter Plugin

[Adam]

Just released the traffic filter plugin today. Available to download from http://www.jamit.com/plugins/TrafficFilter.zip

Description: Filters (redirects, blocks) traffic depending on country, User-Agent, IP address, IP range, IP mask (CIDR), usage of proxy by redirection to customizable URL(s). Uses both blacklisting and whitelisting. This plugin can be used for improving security, filtering or blocking undesirable traffic, or just redirecting specific users to another localized job board. NOTE: After enabling this plugin, you must install database tables by selecting Configure->Install Tables.

See README.txt for installation details

[CompuDave]

Excellent idea for a plugin - this is going to make a huge difference - thanks!

[Peter]

This plugin was released as beta, although we have taken great care developing it. The version may soon be upped to full 1.0.

We hope that those of you who will install it and use it will give us some feedback!

Enjoy!

[dotmagic]

Excellent plugin and well done.

I see that u have added 239 country codes destinations and I have a list of 246 codes, should you need that for update plzz let me know I will send a copy of the codes.

Thanks.

[Peter]

Yes, I am aware of that. This may need to be "corrected" in the final release.

For example, the codes that are not listed in the pop-up window are: eu, uk. From my own experience, the code 'uk' does not occurr, although those IP ranges must be used somewhere. The code 'eu' is used for sure.

However, you are allowed to use these codes in the configuration and the plugin will work.

[Peter]

Do you know who "accesses" your website?

Notice that I used the word "accesses" and not "visits". That's because a website is being accessed by people and robots alike.

Best if you carefully study and analyze your access and error logs. Visitor analysis service such as "Google Analytics" are quite useless, although they provide visually attractive interface. What really needs to be done is analysis of every request, including IP address, host name, the requested URI, user-agent string, geographic location (country) and timing, among many.

If you do your job thoroughly, you will find that majority of requests (often as high as 99%) are by robots. These are not just your regular Googlebots and Yahoo! crawlers. Most of them are robots by some unknown company that collects data and resells it to others. Apparently, data mining is a big, big business.

"So what?", you may say. "These robots collect information about me and my customers." Another threat may be, that these rogue robots are trying to discover 'backdoors' and vulnerabilities of your system. They may be zombie computers, infected with a virus, and they try to find another victim to infect and turn your website into virus-spreading tool.

On daily basis, my own sites record visits by robots who try requesting URLs such as /login.php, /install.php, /readme.txt, /install.txt, /cgi-bin/, .... Yes, they are probing for weaknesses, a forgotten installation file. They are trying to detect which system my site is using, so they could explore a known vulnerability (if they know one).

I have also noticed that many robots switch their user-agent like a chameleon. I call that being dishonest (I am trying to not use expletives).

Rogue robots also consume your bandwidth, taking away resources from your legitimate users, and slowing down your server. You may also incur charges for excess bandwidth consumption.

This is where our TRAFFIC FILTER can help!

Blocking Countries
Let's say that your server is in the UK and your visitors are mostly in the UK. The employers are in the UK, and so are the job seekers. There may be few instances, when a legitimate user is on holidays somewhere overseas ..... But why should your site be accessible to visitors (and robots) in Russia, Ivory Coast, Brazil,....?

Yes, there are some basic security precautions you can take by blocking certain countries, which are likely to pose the highest threat. From my own experience, I could name these as being such countries: Ivory Coast, Niger, Russia, Brazil, China, Israel, Netherlands, Germany, and even the US. Simply because I have seen many malicious requests from these locations.

When your website is serving only a limited region, you should have a security policy, which denies access to users from outside of this region.

CAUTION: If you decide to block some countries, such as the US, beware that you will also be blocking legitimate search engine robots (Googlebot, MSN, Yahoo!), unless you make an exception in the whitelist.

Blocking User-Agent
The TRAFFIC FILTER has an option to redirect (block) users based on their user-agent string. Keep in mind that the user-agent string can easily be forged. However, it is just another usable identifier, and it can be used with some success to achieve your security policy's objectives.

I can recommend these few settings to block some obviously forged user-agents:

Code:

AGENT#^$#@DEF

......... empty (or none) user-agent

Code:

AGENT#^\.$#@DEF

....... only one dot (.)

Code:

AGENT#^\.+#@DEF

....... only one or more dots (.)

Code:

AGENT#^[a-z\ ]{1,}$#i@DEF

........ randon alpha-only string with white spaces

Code:

AGENT#^[0-9\ ]{1,}$#@DEF

........ random numeric-only with white spaces

Code:

AGENT#^[a-z0-9]{1,}$#i@DEF

...... random alpha-numeric without white spaces (most likely an MD5 hash etc.)

Code:

AGENT#^(Mozilla\ ?|Mozilla/[0-9]{1,}\.[0-9]{1,})$#i@DEF

......... user-agent like 'Mozilla/4.0' is very likely to be some rogue robot

Code:

AGENT#(Perl|curl|libwww)#i@DEF

....... this will stop many rogue robots

I often see the Googlebot user-agent string being used by robots that don't belong to Google. This is a common tactic for these rogue robots to gain unimpeded access to your site. Unfortunately, the present version of the TRAFFIC FILTER cannot distinguish when this happens.

I would be happy to answer anyone's questions regarding the use of this plugin. Having for feedback will help us make this plugin even better. I have developed this plugin based on my 1-year experience of using the same function on my own sites. I block over 200 IP ranges (could easily be millions of IP addresses), over 20 countries, many user-agent strings.

Additionally, the TRAFFIC FILTER keeps a log of all blocks/redirects, so you can see for yourself what exactly is happening.

Cheers!

[dotmagic]

Hmm sounds great,

Traffic filter is certainly good to restrict certain countries like Nigeria as u mentioned. Data mining is a big business indeed but when it comes to publishing information online we are bound to expose data to the users and only if the data reached as many targets as it can, we can expect a visitor to return and use the service.

Dont you feel it will affect the number of visitors to the site? Why not have such sensitive data for registered users only? and just block spammer IP's from the logs we find?

Does it just block IP's we specify or have u enabled any feature that prevents DDOS attacks? If it were to have a feature that prevents DDOS attacks, this would be the most advanced plugin that no other cms can match with it.

If you were to develop with DDOS protection, I would suggest/welcome/request you encrypt the script at that point and give it for users for security reasons.

To what I see, this plugin look the best and very well developed with lots of time, research and energy spent to bring it to a shape.

Keep it up.

Good luck and Thanks,
BV.

[Peter]

Whom and what you block is at the discretion of the user (admin). The plugin does not block anything on its own. It must be configured by the user.

Most likely, every user (admin) will have their own security policy and access policy.

Blocking a range of IP's is not necessarily a bad thing. Out there are plenty of businesses that will let you rent a server. They have many servers to rent, easily hundreds, thousands. They also have the same number of IP addresses. But these IP's are not the same IP's as that of your job seeker or employer. Job seeker and employer are on IP's that belong to Internet providers, or some corporate IP's. There are ways to identify one from the other.

DDoS prevention is a different subject altogether. Probably the best (or only) way to deal with DDoS attacks is on the Apache level through iptables. I believe that there are some adequate open-source solutions for DDoS available.

[dotmagic]

Sounds great.

As a developer you know better than us about the plugin, I did not have opportunity to use your plugin effectively in 2 days of its release, will use the plugin for sure and do my contribution if any I can.

Thanks.

[Peter]

Does it just block IP's we specify or have u enabled any feature that prevents DDOS attacks? If it were to have a feature that prevents DDOS attacks, this would be the most advanced plugin that no other cms can match with it.

Few hours ago, my own sites were out for few hours due to a DDoS attack. But all is fine now.

Actually, it was not my sites that were under attack, but my host, GODADDY.COM. My site's outage was a collateral damage. Perhaps GODADDY's DDoS outage has something to do with recent wave of attacks of Twitter?? So if you are using GODADDY as your hosting provider, your sites were out too! This just shows that having a protection against DDoS on your site may be useless, if you are not in full control of your servers (incl. DNS).

I am not a 'security expert' yet, and definitely not expert on DDoS, but what I gather, DDoS is the extreme attack and very difficult to fend off. The only way (that I know of) of defense is by not answering requests (no connection), which is pretty much like switching the server off, and that is the purpose of DDoS attacks. Even some of the large, famous and rich companies seem to have no defense for DDoS.

I am sure that most of you heard of the recent incident when a film festival site in Australia got hacked, most likely by Chinese hackers, and defaced with Chinese flags. This is probably because the hackers knew the backdoor or vulnerability.

Security is a difficult subject to understand to most users and webmasters, because they can't see the benefits of it, until it is too late. As children, most of us receive some kind of inoculation - tetanus, rubella, hepatitis, .... - but we never know if and when it saves our lives. Same with website security - it is a preventative effort.

Security always is an uphill battle. You can try to make your site secure, you can make it very secure. But the hackers will always be at least one step ahead. They can outsmart us, or they can hire a criminal gang who will.

I really have no material interest is selling you this plugin, but I believe that it is useful and it helps in terms of security.

As I said, anyone's feedback will be highly appreciated and having it will help us to make it even better.

[dotmagic]

I am sure that most of you heard of the recent incident when a film festival site in Australia got hacked, most likely by Chinese hackers, and defaced with Chinese flags. This is probably because the hackers knew the backdoor or vulnerability.

Is not just this, can u imagine UK Home Office website had a link to porn site? Yes it had, it was fixed later, just google it, you can get the news about it.  Was one of the shocking and funniest news I ever read a couple of months back.

Security always is an uphill battle. You can try to make your site secure, you can make it very secure. But the hackers will always be at least one step ahead. They can outsmart us, or they can hire a criminal gang who will.

Well that's why I just came up with an idea to give a secured solution at that point of release of your plugin, no need to be commercial if you dont like to (even if it were commercial I will buy for sure). Secured version just trims off a way for the hackers to study the system and bring an alternative to diffuse the hard work in micro seconds.  No need a security if there is no issue of theft.


To what I had come across, no CMS has a plugin or an inbuilt system to face DDoS. May be these is, but I am not aware of. A year back or so, I believe many many job sites were under attack, Even Australian websites were attacked n I remember reading such news before as serious security issue about the users DB in those employment sites.

Thats why, when you came up with this plugin I was very curious to study its efficiency with such attacks.

Thanks.

[Peter]

As far as the TRAFFIC FILTER plugin, the discussion about DDoS is off the subject. However, because there appears to be interest, I recommend this article:
http://en.wikipedia.org/wiki/Denial-of-service_attack

Following the above link will also give you links to other sites, including those with solution to fighting DDoS and open-source (free) solutions.

I'd say that JAMIT is unlikely to be developing any kind of DDoS related product and rather stay focused on the JOB BOARD and support of customers.

[Adam]

Perhaps you could look at getting a hardware based firewall, eg. Cisco ASA 5505 to guard against denial-of-service attacks and other unwanted traffic in conjunction with the traffic filter plugin.

[Peter]

Perhaps you could look at getting a hardware based firewall, eg. Cisco ASA 5505 to guard against denial-of-service attacks and other unwanted traffic in conjunction with the traffic filter plugin.

I don't have any experience with the Cisco ASA5505, but I am sure that is is a good solution, especially if one has the budget to buy it. I'd like to add that the TRAFFIC FILTER is a cheaper (free) alternative to the ASA5505. The TRAFFIC FILTER can achieve improvements in your site's security, including protection against botnets.

The Cisco ASA5505 and the TRAFFIC FILTER are very different animals, working on a different level. Good security system should also work on different levels and in parallel and in conjunction, as Adam already mentioned.

[Peter]

Just wanted to share with you all how I use the TRAFFIC FILTER to fend off a great number of attacks every day.

I run a few small sites. They don't have whole lot of traffic, but all of my sites are being scanned by ROGUE ROBOTS and SQL injection attempts are a daily occurrence. If this happens to my sites, I am certain that it happens to your sites as well. Who knows, you site may already be infected with a backdoor script and you are not aware of it.

The TRAFFIC FILTER plugin needs to be configured first. You need to define some conditions, which will make the TRAFFIC FILTER block undesirable traffic (requests). One place to start is by setting a country you want to block. If your Job Board is for example in the UK and serves mainly to UK (and Eropean) audience, there probably is no reason why you should allow requests from Africa. Especially Ivory Coast (Cote D'Ivoire) is famous for malicious attacks. So are China and all of the countries of the former Soviet Union.

Another condition for blocking should be the user-agent string. (Please refer to web resources to find out more about the user-agent string, such as http://en.wikipedia.org/wiki/List_of_HTTP_headers .)

The user-agent string can easily be spoofed, however, it is a wonderful means for hackers to initiate MySQL attacks, and for you, it is a way to detect ROGUE ROBOTS and fend off attacks.

I have already suggested some user-agent conditions in my earlier post. (Please scroll up.) I will list a few again:

Code:

AGENT/^$/@DEF ......... empty
AGENT/^\ +$/@DEF ....... 1 or more white spaces (only white spaces)
AGENT/^\.+$/@DEF ........ 1 or more dots (only dots)
AGENT/^Mozilla$/@DEF ....... string is only 'Mozilla' (definitely spoofed user-agent)
AGENT/^Mozzila$/@DEF ...... string is only 'Mozzila' and obviously misspelled (I had such request on my site!)
AGENT/^Mozilla/?[0-9]{1,}\.[0-9]{1,}$/@DEF ..... this is NOT a human visitor
AGENT/^Mozilla/?[0-9]{1,}\.[0-9]{1,}\ ?\(compatible;?\)$/@DEF ...... this is NOT a human visitor
AGENT/^[a-zA-Z0-9]{1,}$/@DEF ..... alphanumeric string, such as '7yT2gB1kcWiP2'
AGENT/^[a-zA-Z\ \.]{1,}$/@DEF ........ alphabetical string with optional spaces or dots, such as 'Morfeus strikes again.' (I had such requests on my site!)
AGENT/^[0-9\ ]{1,}$/@DEF ....... numeric string with optional spaces, such as '8346456 383 38 5494'
... and most important for last ....
AGENT/(\'|\"|\`)/@DEF ..... blocks MySQL injection attacks

Okay, once you enter these into your TRAFFIC FILTER plugin configuration, the plugin will start blocking malicious traffic. The wonderful thing about the plugin is that every single event is being logged in the database table named jb_log_redirects, and daily aggregate counts are in table named jb_log_redir_aggr. You should study these logs daily to see how effective the setting of your TRAFFIC FILTER are, whether the settings need any adjustments or corrections.

In my case, after I see some repeat offenders bombarding my site too much and stealing CPU resources, I write a line for the .htaccess file.

The .htaccess file is a better solution than TRAFFIC FILTER, with the only disadvantage that it doesn't log events, and therefore difficult to know what is going on. I use it as a last option, once I am sure that a rule (or regular expression) is correct and effectively blocks evil requests.

Here are a few lines from one of my own .htaccess files:

Code:

# Creates error 403 for unauthorized access to a directory
Options All -Indexes

# secure htaccess file
<Files .htaccess>
order allow,deny
deny from all
</Files>

<ifmodule mod_rewrite.c>
rewriteEngine On
rewriteBase /

### Hong Kong, FAKE Googlebot agent
RewriteCond %{REMOTE_HOST} ^118\.142\.36\.230$ [OR]
RewriteCond %{REMOTE_HOST} ^203\.218\.132\.103$ [OR]
RewriteCond %{REMOTE_HOST} ^203\.218\.122\.154$ [OR]
RewriteCond %{REMOTE_HOST} ^203\.210\.8\.4$ [OR]
RewriteCond %{REMOTE_HOST} ^203\.210\.8\.8$ [OR]
RewriteCond %{REMOTE_HOST} ^203\.210\.8\.16$ [OR]
RewriteCond %{REMOTE_HOST} ^203\.210\.8\.20$ [OR]
RewriteCond %{REMOTE_HOST} ^203\.210\.8\.31$ [OR]
RewriteCond %{REMOTE_HOST} ^210\.3\.52\.174$ [OR]
RewriteCond %{REMOTE_HOST} ^218\.188\.157\.166$ [OR]
RewriteCond %{REMOTE_HOST} ^218\.103\.164\.175$ [OR]
RewriteCond %{REMOTE_HOST} ^218\.250\.112\.57$ [OR]
RewriteCond %{REMOTE_HOST} ^219\.78\.50\.39$ [OR]
RewriteCond %{REMOTE_HOST} ^219\.77\.184\.10$ [OR]
RewriteCond %{REMOTE_HOST} ^219\.77\.188\.196$ [OR]
RewriteCond %{REMOTE_HOST} ^219\.77\.189\.154$ [OR]
RewriteCond %{REMOTE_HOST} ^219\.77\.189\.95$ [OR]
RewriteCond %{REMOTE_HOST} ^202\.155\.235\.126$ [OR]
RewriteCond %{REMOTE_HOST} ^59\.188\.229\.54$ [OR]

### UK, datamining
RewriteCond %{REMOTE_HOST} ^91\.209\.196\.70$ [OR]

### USA, IVE GOT A PHANG INC., 72.94.249.32 - 72.94.249.39 (72.94.249.32/29)
RewriteCond %{REMOTE_HOST} ^72\.94\.249\.(3[2-9])$ [OR]

### USA, Bluecoat Systems, 208.115.128.0 - 208.115.143.255 (208.115.128.0/20)
RewriteCond %{REMOTE_HOST} ^208\.115\.(1(2[8-9]|3[0-9]|4[0-3]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### USA, CYVEILLANCE, 38.0.0.0 - 38.255.255.255 (38.0.0.0/8)
RewriteCond %{REMOTE_HOST} ^38\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### USA, Websense Inc., 66.194.6.0/24 = 66.194.6.0 - 66.194.6.255
RewriteCond %{REMOTE_HOST} ^66\.194\.6\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
# 208.80.192.0/21 = 208.80.192.0 - 208.80.199.255
RewriteCond %{REMOTE_HOST} ^208\.80\.(1(9[2-9]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
# 204.15.64.0/21 = 204.15.64.0 - 204.15.71.255
RewriteCond %{REMOTE_HOST} ^204\.15\.(6[4-9]|7[0-1])\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### FDC Servers ###
### 66.90.64.0 - 66.90.127.255
RewriteCond %{REMOTE_HOST} ^66\.90\.(6[4-9]|[7-9][0-9]|1([0-1][0-9]|2[0-7]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
### 208.53.128.0 - 208.53.191.255
RewriteCond %{REMOTE_HOST} ^208\.53\.(1(2[8-9]|[3-8][0-9]|9[0-1]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
### 67.159.0.0 - 67.159.63.255
RewriteCond %{REMOTE_HOST} ^67\.159\.([0-9]|[1-5][0-9]|6[0-3])\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
### 74.63.64.0 - 74.63.127.255
RewriteCond %{REMOTE_HOST} ^74\.63\.(6[4-9]|[7-9][0-9]|1([0-1][0-9]|2[0-7]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### USA, Bluecoat Systems Inc., 65.46.48.192/30 = 65.44.0.0 - 65.47.255.255
RewriteCond %{REMOTE_HOST} ^65\.(4[4-7])\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
# 65.160.238.176/28 = 65.160.238.176 - 65.160.238.191
RewriteCond %{REMOTE_HOST} ^65\.160\.238\.(1(7[6-9]|8[0-9]|9[0-1]))$ [OR]
# 204.246.128.0/20 = 204.246.128.0 - 204.246.151.255
RewriteCond %{REMOTE_HOST} ^204\.246\.(1(2[8-9]|[3-4][0-9]|5[0-1]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
# 208.115.138.0/23 = 208.115.138.0 - 208.115.139.255
RewriteCond %{REMOTE_HOST} ^208\.115\.(1(3[8-9]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
# 217.169.46.96/28 = 217.169.46.96 - 217.169.46.111
RewriteCond %{REMOTE_HOST} ^217\.169\.46\.(9[6-9]|1(0[0-9]|1[0-1]))$ [OR]

### USA, Fremont, California, Hurricane Electric, datamining, 64.62.128.0 - 64.62.255.255
RewriteCond %{REMOTE_HOST} ^64\.62\.(1(2[8-9]|[3-9][0-9])|2([0-4][0-9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
### USA, Fremont, California, Hurricane Electric, datamining, 65.19.128.0 - 65.19.191.255
RewriteCond %{REMOTE_HOST} ^65\.19\.(1(2[8-9]|[3-8][0-9]|9[0-1]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
### USA, Fremont, California, Hurricane Electric, datamining, 65.19.154.160 - 65.19.154.191
RewriteCond %{REMOTE_HOST} ^65\.19\.154\.(1([6-8][0-9]|9[0-1]))$ [OR]

### USA, The Planet, 74.52.0.0 - 74.55.255.255 (74.52.0.0/14)
RewriteCond %{REMOTE_HOST} ^74\.(5[2-5])\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]
### USA, The Planet, 174.132.0.0 - 174.133.255.255 (174.132.0.0/15)
RewriteCond %{REMOTE_HOST} ^174\.(1(3[2-3]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### USA, Texas, VRT Servers, 64.56.64.0 - 64.56.79.255 (64.56.64.0/20)
RewriteCond %{REMOTE_HOST} ^64\.56\.(6[4-9]|7[0-9])\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### USA, Columbus Network Access Point, Inc., 209.190.0.0 - 209.190.127.255 (209.190.0.0/17)
RewriteCond %{REMOTE_HOST} ^209\.190\.([0-9]|[1-9][0-9]|1([0-1][0-9]|2[0-7]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### NETHERLANDS, LeaseWeb, 85.17.134.0 - 85.17.134.255
RewriteCond %{REMOTE_HOST} ^85\.17\.134\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### HUNGARY, Dreamshow Partnership, 212.52.164.0 - 212.52.167.255
RewriteCond %{REMOTE_HOST} ^212\.52\.(1(6[4-7]))\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### SWITZERLAND, Backslash AG, 193.135.56.0 - 193.135.58.255
RewriteCond %{REMOTE_HOST} ^193\.135\.(5[6-8])\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### SPAIN, Rango de IPs HOSTINGLMI, 213.194.149.0 - 213.194.149.255
RewriteCond %{REMOTE_HOST} ^213\.194\.149\.([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))$ [OR]

### robots, spiders ###
RewriteCond %{HTTP_USER_AGENT} "(screenshot|thumbnail|ia_archiver|Yandex|GingerCrawler|Plukkie|plukkie|nu_tch|princeton\ crawler|speedy_spider|entireweb\.com|SurveyBot|Whois|whois|who\ is|apnoti\.com|Baiduspider|baidu\.jp|Mail\.Ru|Netcraft\ SSL\ Server\ Survey|Ruky-Bot|ruky\.de|KaloogaBot|kalooga|Yeti|naver\.com|Trend\ Micro|Exabot|fisuna\.com|Fisuna-Bot|StackRambler|GrubNG|grub\.org|Huasai|Python-urllib|MLBot|metadatalabs\.com|FollowSite\ Bot|followsite\.com|Servage|servage\.net|psbot|picsearch\.com|my-robot|Nutch|mmonitor|dotnetdotcom|DotBot|Microsoft\ Data\ Access\ Internet\ Publishing\ Provider|Tagoobot|80legs\.com|parchmenthill\.com|eurosoftware|Eurosoft-Bot|yacybot|libwww|curl|perl|Plesk|larbin|User-Agent|core-project|panscient\.com|Morfeus\ Fucking\ Scanner|Comodo\ SSL\ Checker|Jakarta\ Commons|Windows\ 95|lwp-trivial)" [OR]

RewriteCond %{HTTP_USER_AGENT} "^$" [OR]

RewriteCond %{HTTP_USER_AGENT} "^\ +$" [OR]

RewriteCond %{HTTP_USER_AGENT} "^\.+$" [OR]

RewriteCond %{HTTP_USER_AGENT} "^Mozilla$" [OR]

RewriteCond %{HTTP_USER_AGENT} "Mozzila" [OR]

RewriteCond %{HTTP_USER_AGENT} "^Mozilla/?[0-9]{1,}\.[0-9]{1,}$" [OR]

RewriteCond %{HTTP_USER_AGENT} "^Mozilla/?[0-9]{1,}\.[0-9]{1,}\ ?\(compatible;?\)$" [OR]

RewriteCond %{HTTP_USER_AGENT} "^[a-zA-Z0-9]{1,}$" [OR]

RewriteCond %{HTTP_USER_AGENT} "^[a-zA-Z\ \.]{1,}$" [OR]

RewriteCond %{HTTP_USER_AGENT} "^[0-9\ ]{1,}$"

RewriteRule .* http://www.google.com/ [L,R=301]

</ifmodule>

PLEASE NOTE: This post should not focus too much on the .htaccess file, but only as much as it relates to the use of the TRAFFIC FILTER. We could probably start another discussion on that theme separately.

The TRAFFIC FILTER is now in beta stage and available for free download by existing Jamit customers. Future releases will include additional improvements and additional security plugins are being considered.

Happy jobboarding,
Peter