Blue Plate Special WAF

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

At PCCS labs we have access to sophisticated machine learning and artificial intelligence based cybersecurity tools.  These tools are costly and the cyber risk may not warrant the cost of such tools for many small organizations. This blog details how to use Apache's .htaccess file to implement a low-cost Web Application Firewall (WAF) and is part of our effort to pass along cybersecurity knowledge to help secure the greater community.

Security is a unique challenge for cost-conscious websites that need to address a specific threat, spam annoyance, or risk but lack the resources to implement security tools such as a Web Application Firewall (WAF). Basic web hosting plans that many small organizations use typically do not include web security tools as the hosting company handles security.  Many of these basic web hosting plans focus on content management systems such as WordPress, Joomla, and Drupal.  One tool that most Apache-based web hosts do allow customers to use is the .htaccess file.

Using .htaccess does affect the performance of your Apache HTTP Server, and you should monitor response times when using this tool.  If your hosting plan allows access to the httpd config file or ModSecurity those are the preferred methods for these techniques but most basic web hosts do not authorize customers to access these tools.  The .htaccessfile can also be used in alongside content distribution network (CDN) web application firewalls (WAF) such as CloudFlare, Imperva, and Incapsula to further customize and strengthen your web security.

In this blog, we discuss methods that can be implemented using the .htaccess file to assist in the mitigation of troublesome web traffic.  When implementing and testing these methods, it is critically important to keep a backup of your .htaccess file before any modification, and you must have an understanding of how to revert to this backup in the event your modifications cause errors.

Keep in mind that this blog is only covering one web security tool and you should have a comprehensive defense in depth cybersecurity strategy based on risk to ensure your digital presence is secure.

 

Getting Started With .htaccess

 

The .htaccess file typically is located in the web root directory of your host file system.   Commonly the web root directory is named “www” or “public_html,” consult your hosting provider if you are not sure where to locate the file in your specific host configuration.  Most Apache web hosting plans include a tool called cPanel or Plesk in which you can access a file browser to find your .htaccess file and more advanced users may prefer to use SSH.

Some host configurations may not have a .htaccess file setup in the root web directory by default, in this case, create a text file named .htaccess and save it in your root web directory. 

Once you have found or created your .htaccess file, make two copies of this file, the first is a backup of the original unmodified file, this blog will use the name ”htaccess_backup_[date]” and the second is the version you are going to modify, this blog will use “htaccess_[date]_[version]”.  The next step is to open the second file version of the ”.htaccess” file in your favorite text editor, this blog will use Notepad++ as the text editor. 

To get started in using .htaccess, we first add comments in the .htaccess file. Comments are represented using “#” symbol.  It is a best practice to start a .htaccess file with a comments section, below is the comment header we will use to start our .htaccess file.

 

 

### ================ Blue-plate Special Firewall ======================

###

### !!!!!!!!!!!!!!!!!!!! Always Backup Your Previous Unmodified .htaccess File !!!!!!!!!!!!!!!!!!!!!!

### !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

###

### ================ Blue-plate Special Firewall ======================

 

 

Save your edited file after adding the above comments and upload it to your website’s web root directory. Don’t change the file name to .htaccess yet, keep it in your selected file name format (we are using “htaccess_[date]_[version]”).  After your upload is complete, you will activate the file on your server by replacing your current .htaccess with the newly uploaded version.  

Users have found the best way to do this is to use the copy command, by copying your new version (we are using "htaccess_[date]_[version]") to .htaccess and overwriting the current .htaccess file.  Alternately you can delete your current .htaccess and then rename your uploaded file to .htaccess but this will lead to a small point of time that your web server is left unprotected by .htaccess.  After replacing your previous .htaccess file, visit your website to ensure everything is working correctly.

The next couple of commends that we are going to add to the .htaccess file will turn on Apache features that will be used later on in this blog.

After your initial comment header, add the below commands to your modified .htaccess file (we are using “htaccess_[date]_[version]”).  To understand these Apache features further, read the Apache Web Server documentation, or google the command to read one of the many tutorials written about them.

 

 

#### RewriteEngine enabled - BEGIN

RewriteEngine On

##### RewriteEngine enabled - END

 

##### RewriteBase set - BEGIN

RewriteBase /

 ##### RewriteBase set – END

 

  

Finally, we will enable our first critical security feature using the .htacceess file, which will prevent file browsing from public web browsers of your web server directories. To accomplish this, add the following code to your file and follow the previous file copy process to enable it on your web server.

 

 

##### Block directory browsing -- BEGIN

IndexIgnore *

Options -Indexes

##### Block directory browsing  -- END

 

  

   

 

The working file is available for download here.  We welcome questions, comments, and thoughts on these techniques, reach out to the PCCS Labs Team at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Advance the spam detection capabilities of your low-cost web application firewall (WAF) by integrating Apache .htaccess with Project Honey Pot. This post describes a combination of techniques using both of these tools to reduce spam traffic hitting your website.

Project Honey Pot is a tool for identifying spammers and spambots targeting your website.  One off-label use for Project Honey Pot is integrating it with .htaccess to create a combined low cost web application firewall and honeypot solution.

Webmasters interested in participating in Project Honey Pot are required to register and then upload a Project Honey Pot provided spam trap webpage to their web server.  After installing the Project Honey Pot software, .htaccess is used to point spammers to your honeypot.  Additionally, many popular content management systems such as WordPress, Joomla, and Drupal have plug-ins that can be configured to use Project Honey Pot's spam blacklist.  Combining your honeypot with the blacklist will further enhance your ability to stop spammers and spambots visiting your website.

For websites that already have a Web Application Firewall through a Content Distribution Network, the .htaccess can be used to supplement or increase the level of security provided by the CND WAF.  The below diagram details the reference architecture.

 

 

Creating Your First Spam Trap With .htaccess

To get started, register and install the Project Honey Pot software on your website following their instructions. Once installed you will have a unique webpage file name that serves as your honeypot.

Creating your first spam trap using .htaccess is easy and we will start with the previous .htaccess file we created in the last blog.  Our previous file looks like this:

 

 

### =================== Blue-plate Special Firewall ===================

###

### !!!!!! Always Backup Your Previous Unmodified .htaccess File !!!!!!

### !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

###

### =================== Blue-plate Special Firewall ===================

 

##### RewriteEngine enabled - BEGIN

RewriteEngine On

##### RewriteEngine enabled - END

 

##### RewriteBase set - BEGIN

RewriteBase /

##### RewriteBase set - END

 

##### Block directory browsing -- BEGIN

IndexIgnore *

Options -Indexes

##### Block directory browsing  -- END

 

 

The code for your first spam trap starts after the last line of the previously created file.  For this blog, we will use the filename "honeypot.php" to refer to the honeypot file installed from Project Honey Pot.

To catch potential spammers, we are going to examine the USER_AGENT variable that HTTP traffic is sending your website. The command RewriteCond will be used in conjunction with RewriteRule to test a condition and execute an action on your web server using the .htaccesss file. 

We will test USER_AGENT using RewriteCond for common strings that spam bots have included in their USER_AGENT variable.  The strings to be tested include “Wget”, “curl”, and “apache”. If our test is positive, the command RewriteRule forwards the tested HTTP traffic to the honeypot for evaluation by Project Honey Pot. 

It is critical to ensure that the HTTP traffic is not the traffic that was already tested and redirected to the honeypot.  To test this, we will use the command RewriteRule on the REQUEST_URI variable. 

The .htaccess code to perform USER_AGENT string evaluations for “Wget”, “curl”, and “apache” and forward positive tests to the honeypot is listed below:

 

 

##### Redirect Linux Programs/Commands Used By Hackers and Spammers To Honeypot -- START

RewriteCond %{REQUEST_URI} ! honeypot.php/

RewriteCond %{HTTP_USER_AGENT} ^.*Wget* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*curl* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*apache* [NC]

RewriteRule ^(.*)$ /honeypot.php/ [NC,L]

##### Redirect Linux Programs/Commands Used By Hackers and Spammers To Honeypot -- END 

 

 

The working file is available for download here.  We welcome questions, comments, and thoughts on these techniques, reach out to the PCCS Labs Team at This email address is being protected from spambots. You need JavaScript enabled to view it..

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Introduction to SQL Injection, Code Injection, and Apache Input Fields

SQL injection and Code Injection are common hacking techniques used to maliciously harm websites and promote spam.  This post will describe methods for detecting SQL and Code Injection attempts using the Apache .htaccess file and detail how to forward traffic identified as suspicious to your honeypot.

Software bugs, poor programming practices, and outdated software have the potential to expose your website to SQL and Code Injection vulnerabilities. Injection attacks are performed by inserting malicious code into website input fields that are then processed and stored on your server.  Using .htaccess we can review these input fields for signs of malicious code and prevent that code from reaching your web application or database.

There are multiple HTTP server input fields that could be used to deliver a SQL Injection or Code Injection attack.  This post will cover the HTTP QUERY_STRING input field, and subsequent posts will cover additional fields including:

  • HTTP_USER_AGENT
  • HTTP_REFERER
  • HTTP_COOKIE
  • HTTP_FORWARDED
  • HTTP_PROXY_CONNECTION
  • HTTP_ACCEPT
  • HTTP:X-FORWARDED-FOR
  • HTTP:X-FORWARDED-HOST
  • HTTP:X-FORWARDED-SERVER

The above list is not comprehensive of all input fields that could potentially contain injection code.  It is important to keep in mind that there are multiple ways a SQL Injection or Code Injection attack can affect your website.  The configuration of your website will determine the different input fields that could be used to deliver an attack. 

The QUERY_STRING input field passes data to your web server through the Universal Resource Locator (URL).  The data this field contains begins after the ”?” in standard URL format.  For example, if the URL is www.mywesite.com/index.php?foo=foobar, the QUERY_STRING variable would contain “foo=foobar”.

We will use the Apache RewriteCond command to scan the QUERY_STRING variable for character strings that resemble SQL language commands.  A basic understanding of the SQL language is required to understand these commands and an advanced understanding is helpful in identifying advanced SQL Injection attack methods in the QUERY_STRING. 

The SQL language was designed to be easy to understand, and many of the commands resemble common English words.  Common language commands present a challenge in distinguishing between false positives and actual SQL Injection attacks.  Your specific website use cases and configuration will help you to determine if any SQL command character strings require exclusion from the SQL Injection scans because they potentially generate false positives.

 

.htaccess Code to Block SQL Injection Attacks in QUERY_STRING

 

We will start with the .htaccess file we created in the previous blog.  The new code we create uses the framework introduced in the previous post to send suspicious traffic to our honeypot webpage using the Project Honey Pot system.  

The code below uses the RewriteCond command to scan the QUERY_STRING variable for common SQL language commands including union select, cast, declare, drop, md5, benchmark, table, column, distinct, substr, concat, schema, hex, truncate, convert, exe, passthru, system, popoen, proc, load, between, null, delay, char, sleep, schema, and unhex.

The [NC] switch is used with RewriteCond to indicate that the string is not case sensitive.  If a positive match is found the command RewriteRule is used to direct suspicious traffic to your honeypot.  The [L] switch is used with RewriteRule to indicate that Apache should stop processing additional rule sets.

 

 

##### Redirect If QUERY_STRING Has SQL Injection To Honeypot -- START

#QUERY_STRING contains everything in the URL after the "?" ex.) mydomain.com/test.php?test=test

#Excluded the commands like, version, update, insert, and set because they are common words and have caused false positives

RewriteCond %{QUERY_STRING} !^$

RewriteCond %{REQUEST_URI} !honeypot.php/

RewriteCond %{QUERY_STRING} union [NC,OR]

RewriteCond %{QUERY_STRING} select [NC,OR]

RewriteCond %{QUERY_STRING} cast [NC,OR]

RewriteCond %{QUERY_STRING} declare [NC,OR]

RewriteCond %{QUERY_STRING} drop [NC,OR]

RewriteCond %{QUERY_STRING} md5 [NC,OR]

RewriteCond %{QUERY_STRING} benchmark [NC,OR]

RewriteCond %{QUERY_STRING} table [NC,OR]

RewriteCond %{QUERY_STRING} column [NC,OR]

RewriteCond %{QUERY_STRING} distinct [NC,OR]

RewriteCond %{QUERY_STRING} substr [NC,OR]

RewriteCond %{QUERY_STRING} concat [NC,OR]

RewriteCond %{QUERY_STRING} schema [NC,OR]

RewriteCond %{QUERY_STRING} hex [NC,OR]

RewriteCond %{QUERY_STRING} truncate [NC,OR]

RewriteCond %{QUERY_STRING} convert [NC,OR]

RewriteCond %{QUERY_STRING} exec [NC,OR]

RewriteCond %{QUERY_STRING} passthru [NC,OR]

RewriteCond %{QUERY_STRING} system [NC,OR]

RewriteCond %{QUERY_STRING} popen [NC,OR]

RewriteCond %{QUERY_STRING} proc [NC,OR]

RewriteCond %{QUERY_STRING} load [NC,OR]

RewriteCond %{QUERY_STRING} between [NC,OR]

RewriteCond %{QUERY_STRING} null [NC,OR]

RewriteCond %{QUERY_STRING} delay [NC,OR]

RewriteCond %{QUERY_STRING} char [NC,OR]

RewriteCond %{QUERY_STRING} sleep [NC,OR]

RewriteCond %{ QUERY_STRING } schema [NC,OR]

RewriteCond %{QUERY_STRING} unhex [NC]

RewriteRule ^(.*)$ /honeypot.php/ [NC,L]

##### Redirect If QUERY_STRING Has SQL Injection To Honeypot -- END

 

 

Hackers have adapted their methods to disguise or obfuscate SQL Injection and Code Injection commands from web application firewalls using character encoding.  The below code uses the same framework as above but tests for character encoding in the QUERY_STRING input variable and suspicious traffic is sent to the honeypot.

 

 

##### Redirect If QUERY_STRING Has Encoded Injection Characters To Honeypot -- START

#QUERY_STRING contains everyting in the URL after the "?" ex.) mydomain.com/test.php?test=test

#Excluded "%20", "%2F", "%26", "%3A", "%3D"  due to use in site URL variables

RewriteCond %{QUERY_STRING} !^$

RewriteCond %{REQUEST_URI} ! honeypot.php/

RewriteCond %{QUERY_STRING} %00 [OR]

RewriteCond %{QUERY_STRING} %0A [NC,OR]

RewriteCond %{QUERY_STRING} %0D [NC,OR]

RewriteCond %{QUERY_STRING} %21 [OR]

RewriteCond %{QUERY_STRING} %22 [OR]

RewriteCond %{QUERY_STRING} %23 [OR]

RewriteCond %{QUERY_STRING} %24 [OR]

RewriteCond %{QUERY_STRING} %25 [OR]

RewriteCond %{QUERY_STRING} %27 [OR]

RewriteCond %{QUERY_STRING} %28 [OR]

RewriteCond %{QUERY_STRING} %29 [OR]

RewriteCond %{QUERY_STRING} %40 [OR]

RewriteCond %{QUERY_STRING} %60 [OR]

RewriteCond %{QUERY_STRING} %2A [NC,OR]

RewriteCond %{QUERY_STRING} %2B [NC,OR]

RewriteCond %{QUERY_STRING} %2C [NC,OR]

RewriteCond %{QUERY_STRING} %2D [NC,OR]

RewriteCond %{QUERY_STRING} %3B [NC,OR]

RewriteCond %{QUERY_STRING} %3C [NC,OR]

RewriteCond %{QUERY_STRING} %3E [NC,OR]

RewriteCond %{QUERY_STRING} %5B [NC,OR]

RewriteCond %{QUERY_STRING} %5C [NC,OR]

RewriteCond %{QUERY_STRING} %5D [NC,OR]

RewriteCond %{QUERY_STRING} %5E [NC,OR]

RewriteCond %{QUERY_STRING} %5F [NC,OR]

RewriteCond %{QUERY_STRING} %7B [NC,OR]

RewriteCond %{QUERY_STRING} %7C [NC,OR]

RewriteCond %{QUERY_STRING} %7D [NC,OR]

RewriteCond %{QUERY_STRING} %7E [NC,OR]

RewriteCond %{QUERY_STRING} > [OR]

RewriteCond %{QUERY_STRING} < [OR]

RewriteCond %{QUERY_STRING} ;

RewriteRule ^(.*)$ / honeypot.php/ [NC,L]

 ##### Redirect If QUERY_STRING Has Encoded Injection Characters To Honeypot -- END

 

 

To block Code Injection attempts we will scan the QUERY_STRING variable for common programmatic commands that are not used in standard written English.  Unless your website is focused on programming, it would be highly suspicious to see these strings in normal a webform submission.  The below code uses the same framework as the previous two code snippets but tests for programmatic commands in the QUERY_STRING input variable and suspicious traffic is sent to the honeypot.

 

 

##### Redirect If HTTP_USER_AGENT Has Common Programatic Commands Potentially Injected To Honeypot -- START

RewriteCond %{QUERY_STRING} !^$

RewriteCond %{REQUEST_URI} !honeypot.php/

RewriteCond %{QUERY_STRING} sanitize [NC,OR]

RewriteCond %{QUERY_STRING} eval [NC,OR]

RewriteCond %{QUERY_STRING} base64 [NC,OR]

RewriteCond %{QUERY_STRING} echo [NC,OR]

RewriteCond %{QUERY_STRING} @set [NC,OR]

RewriteCond %{QUERY_STRING} @ini [NC,OR]

RewriteCond %{QUERY_STRING} dirname [NC,OR]

RewriteCond %{QUERY_STRING} decode [NC]

RewriteRule ^(.*)$ / honeypot.php/ [NC,L]

 ##### Redirect If HTTP_USER_AGENT Has Common Programatic Commands Potentially Injected To Honeypot -- END

 

  

 

The working file is available for download here.  We welcome questions, comments, and thoughts on these techniques, reach out to the PCCS Labs Team at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

 

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

This is the fourth post in a blog series describing how to build a Web Application Firewall (WAF) using the Apache .htaccess file and Project Honey Pot to help reduce spam traffic hitting your website. 

The Blue Plate WAF is for small websites on basic hosting plans that lack access to more sophisticated web security tools.  These basic plans are often used to host content management systems such as WordPress, Joomla, or Drupal which are ideal for small organizational websites.

Web browsers such as Chrome, Firefox, Internet Explorer, and Safari identify themselves by passing along their version information in the HTTP_USER_AGENT variable to the Apache HTTP Server.  By examining the HTTP_USER_AGENT variable, we can determine if a valid web browser version was submitted. 

PCCS Labs has observed that countless spam bots identify themselves as invalid or very out of date browser versions even though it is easy to spoof this information. Validating the browser version passed in HTTP_USER_AGENT filters out a significant amount of spam and bot traffic.

 

Getting Started with Browser Version Validation Using .htaccess

We will start with the previous .htaccess file we created in the previous blog.  The new code we create uses the framework introduced in previous blog posts to send suspicious traffic to our honeypot webpage using the Project Honey Pot system.

 

Legacy Browser Versions

The code below uses the RewriteCond command to scan the HTTP_USER_AGENT variable for web browser versions that are very out of date.  These versions are so out of date that an actual person would not be browsing with them.  If a real human were actually using these browser versions, you would not want them visiting your website because these browsers have significant security vulnerabilities.

The code below scans for the following legacy browser versions:

  •  Mozilla Code Base Versions 1-4
  • Chrome Versions 1-9
  • Firefox Versions 1-9
  • Internet Explorer Versions 1-6
  • Opera (Opera uses the string “OHR”)

The [NC] switch in the code below is used with RewriteCond to indicate that the string is not case sensitive.  If a string match is detected, the command RewriteRule is used to direct the suspicious traffic to the honeypot.  The [L] switch is used with RewriteRule to indicate that Apache should stop processing additional rule sets.

 

 

##### Redirect Really Old Web Browser and Therefore Probably Fake USER_AGENT Strings To Honeypot -- START

RewriteCond %{REQUEST_URI} !honeypot.php/

RewriteCond %{HTTP_USER_AGENT} ^.*Mozilla\/[1-4]\\.* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*Chrome\/[1-9]\\.* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*Firefox\/[1-9]\\.* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*MSIE\s[1-6]\\.* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*Opera* [NC]

RewriteRule ^(.*)$ /honeypot.php/ [NC,L]

 

##### Redirect Really Old Web Browser and Therefore Probably Fake USER_AGENT Strings To Honeypot --  -- END

 

  

Invalid Mozilla Code Base User Agents

The below code uses the same framework as above but tests for Mozilla code base strings in the User Agent that do not follow Mozilla’s standard format and therefore invalid.

 

 

##### Redirect Fake Mozilla USER_AGENT Missing "/[1-9][0-9.][0-9.]" To Honeypot -- START

RewriteCond %{REQUEST_URI} !honeypot.php/

RewriteCond %{HTTP_USER_AGENT} ^.*Mozilla* [NC]

RewriteCond %{HTTP_USER_AGENT} !^.*Mozilla\/[1-9][0-9.][0-9.]* [NC]

RewriteRule ^(.*)$ /honeypot.php/ [NC,L]

 

##### Redirect Fake Mozilla USER_AGENT Missing "/[1-9]" To Honeypot – END

 

  

Invalid Chrome User Agents

The below code uses the same framework as above but tests for Chrome User Agent strings that do not follow Google’s standard format and therefore invalid.

 

 

##### Redirect Fake Chrome USER_AGENT Missing "/[1-9][0-9.][0-9.]" To Honeypot -- START

RewriteCond %{REQUEST_URI} !honeypot.php/

RewriteCond %{HTTP_USER_AGENT} ^.*Chrome* [NC]

RewriteCond %{HTTP_USER_AGENT} !^.*Chrome\/[1-9][0-9.][0-9.]* [NC]

RewriteRule ^(.*)$ /honeypot.php/ [NC,L]

 

##### Redirect Fake Chrome USER_AGENT Missing "/[1-9]" To Honeypot – END

 

   

Invalid Firefox User Agents

The below code uses the same framework as above but tests for Firefox User Agent strings that do not follow Mozilla’s standard format and therefore invalid.

  

 

##### Redirect Fake Firefox USER_AGENT Missing "/[1-9][0-9.][0-9.]" To Honeypot -- START

RewriteCond %{REQUEST_URI} !honeypot.php/

RewriteCond %{HTTP_USER_AGENT} ^.*Firefox* [NC]

RewriteCond %{HTTP_USER_AGENT} !^.*Firefox\/[1-9][0-9.][0-9.]* [NC]

RewriteRule ^(.*)$ /honeypot.php/ [NC,L]

 

##### Redirect Fake Firefox USER_AGENT Missing "/[1-9]" To Honeypot – END

 

  

Invalid Internet Explorer User Agents

The below code uses the same framework as above but tests for Internet Explorer User Agent strings that do not follow Microsoft’s standard format and therefore invalid.

  

 

##### Redirect Fake Internet Explorer USER_AGENT To Honeypot -- START

###MSIE Has a Different Format Than Other Browsers Eg. "MSIE VERSION"

RewriteCond %{REQUEST_URI} !honeypot.php/

RewriteCond %{HTTP_USER_AGENT} ^.*MSIE* [NC]

RewriteCond %{HTTP_USER_AGENT} !^.*MSIE\s[1-9][0-9.][0-9.]* [NC]

RewriteRule ^(.*)$ /honeypot.php/ [NC,L]

 

##### Redirect Fake Internet Explorer USER_AGENT To Honeypot – END

 

  

 The working file is available for download here.  Send your questions, comments, and thoughts on these techniques to This email address is being protected from spambots. You need JavaScript enabled to view it..

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

This is the fifth post in a blog series describing how to build a Web Application Firewall (WAF) using the Apache .htaccess file and Project Honey Pot to help reduce spam traffic hitting your website. 

The Blue Plate WAF is for small websites on basic hosting plans that lack access to more sophisticated web security tools.  These basic plans are often used to host content management systems such as WordPress, Joomla, or Drupal which are ideal for small organizational websites.

Web browsers such as Chrome, Firefox, Internet Explorer, and Safari identify the operating system that they are running on by passing along their version information in the HTTP_USER_AGENT variable to the Apache HTTP Server.  By examining the HTTP_USER_AGENT variable, we can determine if a valid operating system version was submitted. 

PCCS Labs has observed that spam bots often identify themselves as invalid or very out of date operating system versions even though it is easy to correctly spoof this information. Validating the operating system version passed in HTTP_USER_AGENT helps to filters out spam and spam bot traffic.

 

Getting Started with Operating System Version Validation Using .htaccess

We will start with the previous .htaccess file we created in the previous blog.  The new code we create uses the framework introduced in previous blog posts to send suspicious traffic to our honeypot webpage using the Project Honey Pot system.

 

Legacy Operating System Versions

The code below uses the RewriteCond command to scan the HTTP_USER_AGENT variable for operating system versions that are very out of date.  These versions are so out of date that an actual person would not be browsing with them.  If a real human were actually using this operating system version, you would not want them visiting your website because these OS versions have significant security vulnerabilities.

Wikipedia maintains a history of Windows versions which can be used to determine which operating system version to block based on the version age or improper version string. The code below scans for legacy Windows NT release version numbers NT 1.0 through NT 4.0 and sends traffic identifying as those versions to the honeypot:

 

 

##### Redirect Really Old and Therefore Probably Fake or Compromised Windows NT Versions In The USER_AGENT String To The Honeypot -- START

RewriteCond %{REQUEST_URI} !honeypot.php/

RewriteCond %{HTTP_USER_AGENT} ^.*Windows\sNT\s[0-4]\\.* [NC]

RewriteRule ^(.*)$ /honeypot.php/ [NC,L]

 ##### Redirect Really Old and Therefore Probably Fake or Compromised Windows NT Versions In The USER_AGENT String To The Honeypot – END

 

 

Invalid Operating System Versions

The code below scans for non-existent Windows release version numbers and sends traffic identifying as those versions to the honeypot:

 

 

 ##### Redirect Non-Existent and Therefore Probably Fake Windows Versions In USER_AGENT String To The Honeypot -- START

RewriteCond %{REQUEST_URI} !honeypot.php

RewriteCond %{HTTP_USER_AGENT} ^.*Windows\sNT* [NC]

RewriteCond %{HTTP_USER_AGENT} ^.*Windows\sNT\s5\\.[3-9]* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*Windows\sNT\s6\\.[4-9]* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*Windows\sNT\s7\\.* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*Windows\sNT\s8\\.* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*Windows\sNT\s9\\.* [NC]

RewriteRule ^.* honeypot.php/ [NC,L]

  ##### Redirect Non-Existent and Therefore Probably Fake Windows Versions In USER_AGENT String To The Honeypot – END

  

 

The code below scans for two digit or more non-existent Windows release version numbers and sends traffic identifying as those versions to the honeypot:

 

  

##### Redirect Non-Existent and Therefore Probably Fake Windows Versions In USER_AGENT String To The Honeypot -- START

RewriteCond %{REQUEST_URI} !honeypot.php/

RewriteCond %{HTTP_USER_AGENT} ^.*Windows\sNT* [NC]

RewriteCond %{HTTP_USER_AGENT} !^.*Windows\sNT\s[1-9][0-9.][0-9.]* [NC]

RewriteRule ^(.*)$ /honeypot.php/ [NC,L]

 

##### Redirect Non-Existent and Therefore Probably Fake Windows Versions In USER_AGENT String To The Honeypot -- END

  

 

The working file is available for download here.  We welcome questions, comments, and thoughts on these techniques, reach out to the PCCS Labs Team at This email address is being protected from spambots. You need JavaScript enabled to view it..

About Private Client Cyber Security

Former U.S. defense industry cybersecurity executives founded PCCS after struggling to convince large cybersecurity companies to address the cyber risks of public persons and small sized business. 

PCCS provides enterprise-grade cybersecurity consulting and services to professional practices, executives, athletes, and high net worth families.

We strive to provide a personal, professional and a next-generation technology level of cyber protection to our clients. 

 

Twitter @PCCyberSecurity


El Chapo got wiretapped because the cartel’s IT guy screwed up https://t.co/KCopkMVUsd

RT @malware_traffic: 2018-12-13 - Recent #bombthreat extortion ( #bombstortion) #spam - 1 email example and a quick narrative about it avail…
Follow Private Client Cyber Security on Twitter

New York NY | Washington DC | Bethesda MD | Chicago IL | Los Angeles CA
© 2015 Private Client Cyber Security. All Rights Reserved.

Search