Front-ending with aiScaler, the additional benefits.
Posted by Max Robbins on October 25th, 2010With aiCache front-ending client requests – receiving and processing them before they ever get to your origin web server, Aicache is capable of providing even more benefits.
Enforcing time, size and sanity limits on requests.
Due to extremely efficient, non-blocking multiplexed IO model of aiScaler, it is ideally suited to front-end user traffic , while deflects a number of different DOS-type attacks with little or no overhead.
aiScaler enforces time-limits: a client is supposed to provide a complete, well-formed request within certain amount of time – it is configurable via maxclientidletime setting . It helps to protect against potential DOS attack where a number of connection keep being opened to a web site in hope of overwhelming it’s capacity to sustain large number of open connections.
Aicache enhances concept of protection by providing additional security features.
As you might know, sometimes hackers try to attack websites by feeding them URLs configured in certain way, most often to cause buffer overflows with resulting execution of carefully constructed code. When such malignant URLs are discovered, websites are often left at the mercy of their Web software providers to issue quick patch to address the problem. Often there’s no way to prevent this dangerous URLs from hitting the web servers, as there is nothing in front of the victimized web servers to filter out these dangerous URLs.
To protect against such malicious/malformed requests, you can specify maximum HTTP header size and body size, via max_header_size and max_body_size . You can also use URL blocking (see below) for DOS protection.
To protect against death-by-thousands-of-slow-connections attack, you can employ max_client_time setting: this is max amount of time to obtain a valid request’s header from client (default: 5 secs) and max_client_body_time – this is max amount of time to obtain a valid and complete request from client (default: 60 secs)
Request blocking and basic redirection.
You can also explicitly specify list of regular expression patterns that are blocked outright by the Aicache. To block a pattern, simply define it in the configuration file and add “block” directive below the pattern definition. For example:
pattern exploited.html simple 0
block
You can also opt to redirect requests matching certain pattern. Use redirect_location directive below the pattern definition. For example:
pattern nolongerhere.html simple 0
redirect_location http://aaa.bbb.ccc/newlocation.html
Typically you’d want to provide a complete URL for the new location, including the http:// portion.
User-Agent-based redirection.
You can also configure Aicache to redirect requests based on request’s User-Agent information, acting on the type of browser used to access the site. This is most commonly used to redirect mobile users to mobile version of the site.
For example, when a request to www.acmenews.com is a made from a device running Windows CE operation system, you can assume it is being made from a mobile device and want to redirect such request to mobile.acmenews.com . To accomplish that, create a pattern that matches the URL you want to redirect and add a ua_redirect directive below it.
For example:
pattern ^/$ regexp 1m # home page: “/” . Cache it for 1 minute but …
ua_redirect Windows\sCE http://mobile.acmenews.com # redirect for Windows CE devices
ua_redirect iPhone http://mobile.acmenews.com # and iPhone
ua_redirect Android http://mobile.acmenews.com # and Android etc etc