New caching functionality in Helicon Ape 1.2.0.21

Helicon Ape is in the limelight again. This time it's boasting two new increadibly important and useful modules - mod_disk_cache and mod_mem_cache extending it's caching capabilities to the next level.

These modules allow to cache dynamically generated content on the hard disk or in RAM respectively.
The article covering all aspects of new caching modules is coming soon.

We are really grateful to our clients who help us discover unobvious bugs which we attempt to fix in the shortest terms possible.

P.S. The next module to be introduced is mod_linkfreeze implementing LinkFreeze features for Windows Server 2008 bypassing ISAPI limitations.

Stay with us!

HeliconTech Team.

Prevent DoS attacks with Helicon Ape mod_evasive module

Hello, folks! Security is an important subject and we are trying to include some protection features into our software. Perhaps you have already heard about HotlinkBlocker and its reincarnation in Helicon Ape — mod_hotlink module. Cool stuff, but we want to give you more. Helicon Ape 1.2.0.20 brings us mod_evasive, the module destined to protect your web-server from DoS and brute-force attacks. Sounds vague, so we'll provide a little explanation.

DoS is not an Operating System:)

In the security circles, familiar acronym «DoS» has nothing to do with well-known operating system. It stands for «Denial-Of-Service» and means an attempt to make a computer resource unavailable to its intended users. Also there is another term - «Distributed Denial-Of-Service attack» (DDoS attack).

As opposed to DoS, brute-force attack is commonly aimed at getting some access to a protected resource. For example, a computer hacker is trying a large number of possible passwords to crack a needed user account. In fact, lots of users use very simple passwords and hackers are gathering these passwords in special databases to use during brute-force attack.
More information may be found here:

• Denial-of-service
• Brute force attack

mod_evasive

The module was originally written for Apache and we tried to support its syntax to the maximum extent. Moreover, Ape implementation has a potential for further development and we are waiting for your suggestions and criticism.

To enable the module you should open Helicon Ape server configuration (httpd.conf file) and comment out LoadModule directive corresponding to mod_evasive:

Now we are ready to write mod_evasive configuration. The module directives should be written only inside httpd.conf file (per VirtualHost configuration is also supported).

There are five directives which have to be configured, otherwise the module won't work. We haven't set any default values for these directives because their configuration is highly dependant on your server's characteristics. Here are the five required directives:

• DOSPageInterval —  Sets a minimum accessible interval between two requests to a page from the same IP.
• DOSSiteInterval —  Sets a minimum accessible interval between two requests to a site from the same IP.
• DOSPageCount —  Sets the limit for a number of too short requests to the same page
• DOSSiteCount —  Sets the limit for a number of too short requests to the same site
• DOSBlockingPeriod —  How much time bad IP should be blocked.

Now we need to explain you mod_evasive logic. The module counts how many «too short» requests are made from same IP to various URLs and to the whole site. «Too short» means less than accessible interval set by DOSPageInterval and DOSSiteInterval directives. When an IP exceeds the count threshold, it will be blocked during a period set by DOSBlockingPeriod directive. DOSPageInterval, DOSSiteInterval and DOSBlockingPeriod values should be specified in seconds (real numbers are also supported to define more accurate intervals.

Note! You should carefully set mod_evasive configuration according to your server load! In case of incorrect configuration, legal users might be blocked. Here is an example of a minimal possible mod_evasive configuration. Please don't use it without testing!

<IfModule evasive_module>
        DOSPageInterval 1
        DOSSiteInterval 1
        DOSPageCount 10
        DOSSiteCount 200
        DOSBlockingPeriod 60
</IfModule>

This configuration is enough to start blocking attackers. On the next step we will tell you about the blocking behavior.

What happens to bad guys

According to original mod_evasive behaviour, the module sends 403 (Forbidden) code. Actually the blocked response is faster than the common one, because Ape stops request at this point and IIS processes only BeginRequest and EndRequest notification event.

In addition we've invented DOSCloseSocket directive (not supported in Apache) which is disabled by default. If you enable this directive, mod_evasive will send 403 code and close connection socket. It means an attacker should create a new connection and it's pretty good for you as long as this process takes some time.

How to manage a hit list

There are two directives to manage hit list. The first one is DOSHashTableSize which allows you to set a maximum size of the list. Default value is 1024. Each item in the hit list corresponds to an IP address and you might dynamically change this value during DoS attack. Just modify DOSHashTableSize value in httpd.conf and Ape will automatically update mod_evasive configuration. Just FYI, the module is using special cleanup algorithm in case of overflow. Another way to manage hit list is DOSWhiteList directive. It allows to specify IPs which should never be blocked. Both IPv4 and IPv6 formats are supported, moreover, you may use wildcard to add a group of IP addresses into the list. Example:

DOSWhiteList 127.0.0.1 10.0.0.*

Connection with a system (for advanced users only)

There is one more useful feature in mod_evasive. It is DOSSystemCommand directive which gives you a chance to communicate with OS through command execution. You should be careful with this feature because it might be insecure and might cause NTFS permissions issue. So, a command delivered to mod_evasive through DOSSystemCommand directive, will execute each time the module decides that an IP is bad. So, the command will be executed not for all 403 responses, but only for those given in response to malicious requests.


We should notice again that the user running the Application pool should have sufficient rights to execute the command. In most cases it's pretty hard because web-services are run by non-previleged user with limited skills. In this case you should execute a command under another account (e.g. Administrator). Windows has runas command which provides needed functional with one disadvandage — it can't get password through arguments. But, there are a few solutions to this problem. For example, you may use the following script to run the command(s) on behalf of another user specifying his username and password:

' *********************************************************************************
' * THIS PROGRAM IS OFFERED AS IS AND MAY BE FREELY MODIFIED OR ALTERED AS *
' * NECESSARY TO MEET YOUR NEEDS. THE AUTHOR MAKES NO GUARANTEES OR WARRANTIES, *
' * EXPRESS, IMPLIED OR OF ANY OTHER KIND TO THIS CODE OR ANY USER MODIFICATIONS. *
' * DO NOT USE IN A PRODUCTION ENVIRONMENT UNTIL YOU HAVE TESTED IN A SECURED LAB *
' * ENVIRONMENT. USE AT YOUR OWN RISK. *
' *********************************************************************************

On Error Resume Next
dim WshShell,oArgs,FSO

set oArgs=wscript.Arguments

if InStr(oArgs(0),"?")<>0 then
wscript.echo VBCRLF & "? HELP ?" & VBCRLF
Usage
end if

if oArgs.Count <3 then
wscript.echo VBCRLF & "! Usage Error !" & VBCRLF
Usage
end if

sUser=oArgs(0)
sPass=oArgs(1)&VBCRLF
sCmd=oArgs(2)

set WshShell = CreateObject("WScript.Shell")
set WshEnv = WshShell.Environment("Process")
WinPath = WshEnv("SystemRoot")&"\System32\runas.exe"
set FSO = CreateObject("Scripting.FileSystemObject")

if FSO.FileExists(winpath) then
'wscript.echo winpath & " " & "verified"
else
wscript.echo "!! ERROR !!" & VBCRLF & "Can't find or verify " & winpath &"." & /
VBCRLF & "You must be running Windows 2000 for this script to work."
set WshShell=Nothing
set WshEnv=Nothing
set oArgs=Nothing
set FSO=Nothing
wscript.quit
end if

rc=WshShell.Run("runas /user:" & sUser & " " & CHR(34) & sCmd & CHR(34), 2, FALSE)
Wscript.Sleep 30 'need to give time for window to open.
WshShell.AppActivate(WinPath) 'make sure we grab the right window /
to send password to
WshShell.SendKeys sPass 'send the password to the waiting window.

set WshShell=Nothing
set oArgs=Nothing
set WshEnv=Nothing
set FSO=Nothing

wscript.quit

'************************
'* Usage Subroutine *
'************************
Sub Usage()
On Error Resume Next
msg="Usage: cscript|wscript vbrunas.vbs Username Password Command" /
& VBCRLF & VBCRLF & "You should use the full path /
where necessary and put long file names or commands" & VBCRLF & /
"with parameters in quotes" & VBCRLF & VBCRLF &/
"For example:" & VBCRLF &" cscript vbrunas.vbs /
quilogy\jhicks luckydog e:\scripts\admin.vbs" & VBCRLF & /
VBCRLF &" cscript vbrunas.vbs quilogy\jhicks luckydog " & /
CHR(34) &"e:\program files\scripts\admin.vbs 1stParameter 2ndParameter" & /
CHR(34)& VBCRLF & VBCRLF & VBCLRF & "cscript vbrunas.vbs/
 /?|-? will display this message."

wscript.echo msg

wscript.quit

end sub

With the above script being used, mod_evasive can be configured as follows:

DOSSystemCommand "cscript ra.vbs user password command"

It is considered good practice to add Windows firewall rule for bad IP addresses. Here is a possible solution:

DOSSystemCommand "cscript ra.vbs mod_evasive_user pwd \"netsh advfirewall firewall
add rule name=\"mod_evasive %s blocking\" dir=in protocol=TCP localport=80
remoteip=%s action=block\""

Please notice that %s variable contains a string representation of blocking IP.

That's all

We hope the article will help you create correct configuration and enjoy mod_evasive. But we wish your server never face the situations where mod_evasive is needed :)

Yours sincerely, 
HeliconTech Team

Web application debugging with mod_developer

Overview

Helicon Ape mod_developer is the module designed to debug web applications running on IIS. The module will be useful for developers who are actively using Helicon Ape (for example, mod_rewrite module), and all other IIS or ASP.NET developers.
mod_developer provides debug information about each HTTP-request: HTTP request and response headers, server variables, querystring and forms values, cookies and sessions data. The module can provide detailed information about other Helicon Ape modules operation, e.g. about mod_rewrite: involved maps, applied RewriteRule and RewriteCond directives.
mod_developer can work in two modes: as «embedded into html page» or as «request logger in frame».

Embedding into HTML page

This mode is useful if you need to debug HTML pages processing (i.e. HTTP responses from the server with Content-Type: text/html or text/xhtml). To enable mod_developer do not forget to uncomment the following lines in httpd.conf:

LoadModule env_module         modules/mod_env.so
LoadModule developer_module   modules/mod_developer.so

and put this line into .htaccess near debugging file:

SetEnv mod_developer_enable

or web site root .htaccess if you want to debug all site HTML pages.

Warning! mod_developer was designed to debug web applications and we strongly recommended not to enable it on production servers, as this may greatly affect the server performance and can corrupt HTML pages markup.

After enabling the module, go to some page on the site. In the upper left corner you'll see «show» button that toggles debug information toolbar.

 

  

Request Logger in Frame

This mode makes it possible to get debugging information not only for HTML pages, but also for any other requests (Content-Type should not necessarily be text/html). In this case the page is divided into two frames. The bottom frame shows the site and the top frame shows (and periodically updates) the log of all processed requests with corresponding debug information.
To enable this mode put this line into your .htaccess:

SetEnv mod_developer_enable_logger

Then you should point your browser to http://yoursite/_ape_embedded_/mod_developer/request_logger.html

Enter the URL you want to debug in the top frame and request it. In the bottom frame you'll get request resource, and the top frame will present all requests that are processed by the server.

Click on a specific request line to see debug information.

Limitations

Warning!

As we already noticed in «Embedding into HTML page» section, we do not recommend to enable mod_developer on production server. It may affect server performance; request log will grow up to enormous size and it will be kept up to date a large number of queries.

In «Embedding into HTML page» mode mod_developer will only work if html page has </body> closing tag as the module inserts its debugging data before this tag.

It is recommended to run only one instance of /_ape_embedded_/mod_developer/request_logger.html. It receives information about processed requests from the server, and if you have more than one such page, they will share debugging information among themselves in an unpredictable way.

Note! Request logger shows information only for requests processed in the same application pool where mod_developer_enable_logger environment variable was defined.

Helicon Ape 1.2.0.20 - 3 new modules and even more

We are here again to let you know of a new Helicon Ape build - 1.2.0.20.
This build is quite a big step forward compared to the previos one. So... what has changed:

• 3 new modules added:


• mod_mime destined to associate requested filename extensions with the file's behavior (handlers and filters) and content (mime-type, language, character set and encoding);
• mod_evasive is an efficient instrument to get rid of DoS/DDoS and brute force attacks;
• mod_developer is a perfect HTTP-level tool for web developers providing a bunch of all-round information for the HTTP request.



• and some improvements implemented:


• enhanced algorithm for generation of web sites tree in Helicon Ape manager (does not cause delays even with hundreds of sites on your server);
• sites list in Helicon Ape manager tree in now sorted alphabetically;
• new core level directive - StopOnError - makes it possible to tell Helicon Ape how to process unknown directives: when it's on, the browser will throw 500 error; when it's off (default), unknown directives are ignored.