 |
|
|
HIVE is an HTTP firewall. It provides security for applications hosted on a content server, connected to a network via HTTP. These include Web applications, WAP applications, XML applications, and so on. HIVE reinforces the HTTP protocol as defined in the Internet standards, cancelling any attempt to defeat application security via incorrect requests or modifications to legitimate requests. HIVE is provided as a 1U appliance with two copper Gigabit ports, and is positioned between the client and the server to intercept the HTTP traffic between them, verifying that the content is not malicious. The verification is based on information derived from the page contents - from a hidden field or form defined within the HTML code, for example - and no modifications to existing applications are necessary for HIVE to operate. Out of the box, HIVE takes only minutes to install, though configuration can take longer depending on the complexity of the application(s) to be protected. Protection for simple Web sites can be implemented within a matter of minutes, however. Performance is limited, as with all devices of this type, and the capacity of HIVE needs to be carefully matched to the capacity of the device(s) it is protecting and the Internet “pipe” to which it is attached. Overall, the level of protection offered is excellent, especially give the often minimal amount of configuration required. We found the device to be very stable and reliable throughout our tests. The HIVE appliance-based Web Application Firewall consists of the following components: HIVE is based on the IBM x306 series server platform, and is thus provided as a 1U appliance with two copper Gigabit ports, which are used both for passing traffic (internal and external interfaces) and management. Although only one in-line connection is supported, it is possible to place more than one Web server behind HIVE depending on processing requirements. It is equally possible to connect HIVE directly in-line with a single Web server for maximum performance. Given the way HIVE operates, it has no trouble interacting with load balancers if further scalability is required. The device is positioned between the client and the server to intercept the HTTP traffic between them, and can operate either in transparent bridge mode or as a reverse proxy. HIVE filters all IP traffic, and ignores traffic destined for the servers that it is not configured to protect. It is also possible to configure HIVE to permit only HTTP traffic that is directed towards the domains it is configured to protect. In this mode HIVE, in addition to being a Layer Seven firewall, acts a firewall to block lower layer traffic. For all domains it is configured to protect, HIVE intercepts the response from the content server and locates the input fields of the HTTP application (forms, fields for data entry, and so on) and signs them. This is done by appending AES (Advanced Encryption Standard) cryptographic “tokens” to each modifiable element in the response of the content server. It is guaranteed that these tokens cannot be modified or decrypted before they are included into the content. The signed data is then transmitted to the client. Sentryware calls the process of analysis, encryption, parsing and validation Context Authentication (CA). Context Authentication is performed on the fly as the page is passed to the user by HIVE, and does not in any way affect the HTML content of the page, which looks exactly the same to the end user on the screen. Only by inspecting the source code of the signed page can the cryptographic tokens be viewed. This also means that when creating the page, the designer does not have to modify the content to accommodate HIVE. HIVE does not use cookies to track users - all the information necessary is included in the page sent to the client. This means that no special configuration is needed for load balancers to function with HIVE and prevents the subversion of HIVE itself via cookie tampering. The Context Authentication process consists of the following steps:
Once the client decides to submit a request which has been previously “signed” to the server, the request is intercepted by HIVE and the token is processed as follows:
HIVE validates input data based on the original information of the contents:
This technology permits the authentication of the information to be included in each web page, thus removing the need to store such data externally (such as within the HIVE appliance), or to synchronise user information, authentication details, or session/state data between multiple nodes. HIVE does more than protect the plain HTML. When an HTTP application establishes a cookie with the end user, HIVE intercepts the corresponding HTTP section and signs it. Thus it is possible to check the integrity of the cookie if it is sent once again to the server in future requests. This prevents a user from modifying the contents of the cookie, preventing any kind of cookie poisoning attack. If any of the cryptographic tokens or cookies have been tampered with, or any of the items protected by those tokens have been tampered with (i.e. by amending a hidden price field from $4999.00 to $4.99) then HIVE blocks the request. Should a user attempt to inject plainly malicious data - such as binary data or shell code - within a request, or execute a Cross Site Scripting or SQL injection attack, this is detected and blocked via optional rules-based protection mechanisms that can be enabled or disabled via a single check box for each. Whenever a request is blocked, HIVE generates an error message in the log, with the option of sending a real-time alert to the administrator. The user will either see a HIVE-generated error message or will be redirected transparently to another page (depending on how the system has been configured). Naturally there is a significant processing overhead to the Context Authentication procedure, but the biggest advantage of this method is that there is no requirement to make any changes to the back-end application - HIVE will work with almost any existing application right out of the box (some very poorly written applications may require minor modifications to allow HIVE to function correctly, but these will be few and far between). At its most basic level, HIVE works on the concept of “start pages”, legal entry points in an application - the most secure application will have only one start page. From that point on, every page and object access will require a HIVE signature in order to be completed - thus, changing a URL or attempting to bypass the application’s logical flow by directly accessing another Web page (or an operating system resource such as CMD.EXE or /etc/passwd) will also generate an error condition. Bear in mind that HTTP was defined as a document retrieval standard, not as an application language. Therefore the combination of requests and responses that make up an application cannot be defined in any sort of generic “signature”, in the same way we might define a signature against the Code Red exploit in a network-level IDS/IPS system. This makes Web application protection very much more difficult. Sentryware likens this protection to a game of chess. The form of the game (the application behaviour) cannot be known in advance, and neither can your opponent’s (the client’s) behaviour. However, all the rules, playing conventions, pieces, board layout, and playing tendencies of the game of chess are known. The same is usually true of even the most complex Web application and the underlying protocols which support it. HIVE is thus focused on enforcing the knowable rules. Only “legal” moves are permitted, and control over play is transparent, having little or no effect on the participants. HIVE strictly enforces HTTP rules (RFC 2616), performs analysis and interpretation of outbound responses, interprets and validates inbound data and requests based on the above, and tracks and interprets recent communication flow. This not only allows it to protect the application as it stands today, but will also allow it to handle changes in the application transparently, unless the new sections of the application have their own set of logic rules which must be enforced. Certainly changes that do not alter the logic flow of the application - cosmetic changes such as page layout, and so on - will have no affect on HIVE’s operation. Ultimately, this also provides security for attacks that are not yet known. Using multiple HIVE appliances in a load-balanced or fault-tolerant deployment is reasonably straightforward because there is no state information which needs to be maintained across devices. It is also worth noting that in reverse proxy mode the device can perform Network Address Translation (NAT) on traffic passing through it, translating from an external IP address and port to an internal IP address and port, thus facilitating the external publication of internal applications. HTTPS access is provided to the HIVE appliance in order to use the browser-based configuration and management utility. The Web interface provides the means to configure all of the parameters used to manage HIVE, though not always in the most intuitive manner. A simple two-tier architecture is employed, and policies are stored directly on the appliance - there is no separate management server available for HIVE (although HIVE is capable of logging to syslog or any SNMP platform). This means that by default, the Web GUI is intended to manage single devices, or small numbers of devices, and thus might not scale well in larger deployments. Note that, unusually, there is no dedicated management port on the HIVE appliances. Instead, it is necessary to either manage over one of the active ports. We would prefer to see a dedicated management port on the device to ensure that congestion on the detection interfaces does not affect the management process. The aim of this section is to verify that the device is capable of effectively supporting legitimate traffic, as well as detecting and blocking attacks, when subjected to increasing loads of traffic with varying packet sizes and HTTP response sizes. UDP performance with a variety of packet sizes was poor with smaller packets (less than 512 bytes) and barely acceptable at larger packet sizes. However, since this type of device is intended to sit in front of a single Web server, or small group of Web servers, its overall packet processing performance should be considered acceptable. The bottleneck with this type of device is always likely to be the CPU rather than the network performance. With pure HTTP traffic, and no security policies applied, the device could handle a maximum of 2000 new connections per second. Whilst this is hardly blistering performance, it is adequate for the overall performance levels of the device once security policies are applied. Clearly, however, an administrator would need to consider this overall limit when deciding how many Web servers to place behind a single HIVE appliance. HTTP performance with security policies enabled were felt to be within acceptable limits for a device of this type, ranging from 84cps to 500cps depending on the packet and HTTP response sizes. Note, however, that performance takes a further hit when HIVE is forced to sign objects on a page - maximum transactions per second falls from 260 to 24 for the equivalent HTTP response size, whilst response time increases 3 or 4-fold depending on network load. In our “real world” tests, where genuine Web pages were mixed with associated GIF/JPG images to increase the overall response size, HIVE performs much better, achieving 192 transactions per second before response times become excessive and performance becomes erratic. Note that we found the device could cope with short bursts of traffic well in excess of these figures - the only effect being a temporary increase in HTTP response times. Basic latency figures were just about within acceptable limits for a pure networking device with all packet sizes at traffic loads up to 250Mbps, ranging from 220�s with 250Mbps of 256 byte packets, to 303�s with 250Mbps of 1000 byte packets. With more typical (larger) packet sizes, latency remained acceptable up to 500Mbps (260�s with 550 byte packets and 318�s with 1000 byte packets), and it was around 800Mbps before the device began to drop packets and latency increased to unacceptable levels. With layer 7 devices such as HIVE, microsecond latency is less of an issue than with network-level in-line devices such as Intrusion Prevention Systems. Thus the latency figures seen here are well within acceptable limits for a device of this type. Of more relevance are the HTTP response times, which were acceptable across all tests up to 75-80 per cent of the maximum load (as determined in our tests). Exposing the sensor interface to an extended run of ISIC-generated traffic had no adverse effect, and the device continued to detect and block all other exploits throughout and following the ISIC attack. Please refer to the Testing Methodology section for full details of the methodology used and performance results. We installed one sensor in-line between our “internal” and “external” networks. This device was initially configured to protect all our “internal” Web servers in the following way:
Most of our attempted attacks were blocked successfully with no further configuration. One of the most striking benefits of HIVE was that there was no need to perform any changes on any of our applications in order for it to function, and a high degree of protection was provided with a minimal amount of configuration of the product. Additional configuration was required to enforce the client-side validation of our forms (to be expected), and to detect directory traversal and OS command concatenation attempts (which we would have expected to be covered by the default configuration). Buffer overflow protection, shell code detection, Cross Site Scripting protection and Cookie Poisoning prevention all worked well. We noted that Cross Site Scripting detection on POST requests concentrated on detecting the <script> tag in one of the fields posted - we would like to see that extended to check for other tags which can be used maliciously. Interestingly although HIVE does not contain signatures or a detection engine for common HTTP vulnerabilities, it still managed to detect and block all of the exploits we attempted either via the ability to detect shell code, or via the ability to block direct access to disallowed pages (including CMD.EXE and other critical system files). Overall, we were very impressed with the high level of protection provided for such a minimum amount of configuration. Resistance to HTTP evasion/obfuscation techniques was excellent, with HIVE achieving a clean sweep across the board in our evasion tests. Every technique was detected and blocked effectively, and only one was not successfully decoded. This part of the test procedure consists of a subjective evaluation of the features and capabilities of the product, and covers installation, configuration, policy editing, alert handling, and reporting and analysis. When installing HIVE for the first time in the network, it is necessary to configure a series of parameters for the product to function correctly. This configuration is carried out using the serial port of the HIVE, connected to the PC of the administrator via a null-modem cable. The console can also be accessed directly by connecting a monitor and keyboard to HIVE. Initial installation of the appliance consists of little more than connecting the network cables and powering on the device, at which point a simple text-based wizard steps the administrator through the basic device-level configuration. The first time this is run, it prompts for an administrator user name and password before entering the Rapid Configuration mode, where the basic configuration parameters are entered. These include IP address, subnet mask, the TCP port for the web interface, routes and DNS servers. When the Rapid Configuration has been completed, a menu appears from which it is possible to verify or modify these same parameters, as well as upgrade the firmware, set date and time, re-load the default system configuration file and view the system status screen. The information available on the Status screen includes:
HIVE has an IP address purely to provide access to the web interface from the network. However, functioning as a bridge, HIVE acts transparently and forwards packets without any type of modification, encapsulation or translation, and thus IP addresses are not applied to the main interfaces. We would prefer to see a separate dedicated management port, however, rather than use the detection ports. For additional security, it is possible to control access to the Web configuration interface. This is done by filtering the IP addresses that are permitted to access the management IP address, thus preventing unauthorised connections. The permitted IP addresses can be defined in a list only from the Web interface, but the ACL feature can be activated or deactivated from the administrative console. Although the HIVE software arrives pre-installed on the appliance, we did attempt to re-load the software during the test. After backing up the configuration, we inserted the CD-ROM and rebooted the appliance. The automated install commenced (following confirmation from us) and once it had completed we re-loaded the configuration file - the appliance was ready to go in less than ten minutes from the point of power cycling the device. Very impressive. Documentation is restricted to just two manuals - an Installation Guide and an Administrator’s Guide. They are provided in both electronic (PDF) and hard copy versions, and are amongst the best documentation we have seen in our labs. The Installation Guide is very extensive for a device that is so simple to install. It goes into great detail on general networking, IP addressing and routing concepts and we think this is to be commended. Whilst it is clear that no one who does not already have a clear grasp of these concepts should be installing and configuring a device such as this, that is - sadly - not always the case. It is nice to see an installation guide hand-hold the administrator from the very basic steps through to getting the product up and running. Once it is running, the Administrator’s Guide will provide all the information required to configure and maintain it. It provides much more than the usual “click here, this happens” type of “instruction” that we have come to expect, instead providing a wealth of information on why a particular parameter has been provided and what happens when it is used. The only thing missing was a reference section on the use of regular expressions. Overall, the level of detail was excellent, and we found coverage of all the main features to be extremely comprehensive and very clear. Top marks for documentation. Configuration of the HIVE appliance is performed via the Web interface over a secure HTTPS connection. The administrator logs in using either the main admin ID and password, or a lower-level user name and password, and it is possible to log in to only one HIVE device at a time. All configuration information is stored directly on the device being managed - there is no “middle tier” centralised management server involved. This can work well with only a small number of devices to manage, but will not scale well in larger deployments. Each “configuration” (akin to a security policy for a particular application) within HIVE can have a unique user name associated with it, and that user will only be presented with his own configuration (and none of the administrative functions) when logging in. However, if one user requires access to several different configurations (perhaps in a managed service environment) he would require several different login identities - one for each. We would like to see this extended to more of a role-based user access model, with different levels of access within each configuration (read only, log access only, full configuration rights, etc.), as well as the ability to define users independently of configurations and assign multiple configurations to each user. Four main menu entries along the top of the screen provide access to the Administration, Units, Configuration and Logs sections of HIVE. The Administration menu contains high-level options for enabling/disabling the ACL list (restricting access to the management interface to specified hosts), importing and managing digital certificates and certificate requests (for SSL support), managing licenses, backing up and restoring the global configuration file for the device, changing the admin user name and password, and viewing some basic HIVE statistics (number of packets processed, number of legitimate requests, number of attacks blocked, and so on). This menu option is available only to the main administrator.
The Units menu is to configure settings for individual HIVE appliances. The IP address, DNS servers and routing information that were created during the initial appliance installation are mirrored - and can be further modified - here. The NAT option allows the creation of a Network Address Translation table, which is used to publish internal servers external IP addresses. This takes requests made to a public IP address and maps them to a different IP address and port on the internal system. For those who do not wish to rely solely on checking the HIVE logs via the console, it is possible to use the Alerts menu to configure external syslog and SMTP servers (the latter to enable transmission of alert e-mails). HIVE is designed to handle the following types of attack:
There is only a single policy on each device, and this takes the form of the global HIVE configuration file. This file can be backed up to a local or network hard drive remote from the appliance, and can later be reloaded to the appliance to restore a previous HIVE configuration.
The Configuration menu provides access to the application Configurations. Each Web application can have its own Configuration, and multiple application Configurations are stored within the global HIVE configuration. This overlap in terminology is confusing - we will refer to the application Configurations with a capital “C” throughout this report. It is not possible to save and load individual application Configurations - the entire HIVE configuration for a device is saved in a single file. This file also contains the network addressing information for an appliance, so it is not possible to create a single policy for distribution to multiple appliances (at least not without some manual editing of the XML file). When the system is first installed, only the Default Configuration exists. The Default Configuration defines various items that are copied automatically each time a new Configuration is created (such as whether cookie poisoning protection, shell code protection and SQL injection detection are enabled), or whenever the default values are loaded. The Default Configuration can therefore be thought of as a global “template” and can not be deleted. Each new Configuration created defines all the features of a specific Web application required for HIVE to protect it, and each is assigned a unique user name and password. When a particular user logs in, that user will only be able to access his own Configuration and will only be able to see the log entries raised via that Configuration. As mentioned before, the user name is superfluous in anything but a very basic service provider environment. If there is only one administrator to the system, the requirement to allocate a separate and unique user for every Configuration is annoying - in most environments where multiple administrators are required, it would be more useful to be able to assign multiple Configurations to each user. Creating new Configurations is far from intuitive. There is a set sequence of events that must be completed in order to finalise a Configuration, and the only way to step through this sequence at present is to attempt to save the Configuration at various points and allow the subsequent error message to inform you which steps have not yet been completed. This process is crying out for a Wizard feature that will take the administrator through the procedure in the required order. One feature we liked here was the EZ HIVE option. This provides an almost “plug and play” element to the otherwise complex HIVE configuration that allows an inexperienced user to enjoy a high level of web security without the need for programming more options. EZ HIVE is ideal for protecting multiple domains with HIVE, for example in a hosting (or ISP) environment, or where it is more important to provide broad coverage in the quickest amount of time rather than go for the highest levels of security. The main features of the EZ HIVE mode are :
All Configurations are split broadly into two areas - the general parameters which apply to the entire application, and the lower level parameters that apply to individual pages and fields. Each Configuration is tied to one or more domains (or IP addresses) in order to indicate to HIVE which HTTP traffic is to be protected. Note that all HTTP traffic for unprotected domains is allowed through HIVE untouched and uninspected, as is all non-HTTP traffic by default. It is, however, possible to have HIVE block all non-HTTP traffic, a sensible setting when there is only a Web server behind the HIVE appliance.
At the global level, the administrator can enable or disable various “sanity checks”, including:
Other options, which are intended to counter reconnaissance attempts, are Display Date, which allows the administrator to choose whether the Web server sends the Date header or not, and Display Banner, which allows the administrator to substitute the default server banner with a customised one to hide the identity of the Web server. HTTP methods can also be restricted (GET and POST are the only ones set by default), and HTTP header sizes can be restricted to specified limits in an attempt to frustrate buffer overflow attempts. One other feature we would like to see here is the ability to strip out all source code comments, the source of a great deal of free information for the resourceful hacker. Normally, the user who violates HIVE rules is presented with a HIVE error page instead of their expected results. However, it may not always be politic to make the hacker aware of the protection method being used, and so HIVE also provides the means to replace the default error messages with custom text, or to redirect the user to a different Web page (or site!) transparently. Once the global parameters have been set, the administrator needs to define the lower-level elements of the application. Each application is effectively defined by its legitimate entry points - known as Start Pages.
Start Pages do not require a signed request to access them, and there must always be at least one Start Page, from which it is possible to access the rest of the Web application. The pages which a user typically accesses directly (by entering the URL into the address bar of their browser) need to be configured as Start Pages - this may often be restricted to the home page of the Web site, or the main menu page of the application itself. It is possible to define Start Pages explicitly (using a complete URL) or via regular expressions (which allows a group of pages to be specified with a single setting). Once a user has accessed a Start Page, HIVE will kick in with its Context Authentication process and everything from that point on is fully protected. The user will only be able to follow authenticated links from the Start Page to subsequent pages within the application, and any attempt to access a non-Start Page directly will be rebuffed. Defining additional Start Pages at deeper levels of the application is thus to be discouraged, since that could provide “back doors” allowing a user to bypass application logic on pages above them. It is also important to note that Start Pages are the only pages where access is not restricted by HIVE, and therefore it is not recommended to install an application as a Start Page as it would not be protected against attack. In some cases, a single Start Page may be all that is required to define a Configuration. Although this concept seems simple, it is made possible only by the Context Authentication capabilities of HIVE - once one entry point has been defined, the transparent protection is applied to every object which can be accessed from that point onwards. It is worth taking a moment to consider the ramifications of this particular protection model. Not only is it impossible to access an unauthorised Web page directly, but it is impossible to access any Web resource directly when it is a part of the protected application. For example, a typical directory traversal attempt followed by running CMD.EXE to subvert the OS would also be prevented, since \windows\system32\cmd.exe is not defined as a Start Page. This is how - despite the lack of typical IPS-style HTTP exploit signatures - HIVE was able to achieve a PASS in all our Common Exploits tests (Test 1.1.31).
Of course, not every Web application can be defined via a single Start Page, and the problems that can ensue should the administrator make a mistake in defining an application could have serious financial repercussions in some cases, should prospective customers be denied access to an important application. Thus it is possible to put HIVE into Learning Mode, where HIVE performs all its normal Content Authentication functions but does not actually block any malformed requests. Instead, it simply creates log entries for each of them, allowing the administrator to use the information contained within logs to configure HIVE in a more secure and efficient way. If Start Pages define the broad circle of application protection, HTAGs provide the administrator with the means to get down to the real detail. Most applications will, at some point, ask the user to enter information with complex values (such as e-mail address, telephone numbers, social security ID numbers, and so on) which HIVE cannot predict until the client sends the request to the server.
HTAGs permit the administrator to define the format of these values using regular expressions. Those HTAGs can then be applied to individual fields on a form (or to a cookie), for example, allowing HIVE to enforce those values before the request is passed. This means that applications that rely on client-side field validation (which can be subverted using Web proxy tools) can have that validation reinforced and re-applied once the request has left the client (and once it is beyond the influence of the hacker’s tools). One shortcoming we noted here was an inability to negate an entire regular expression (i.e. to specify that a particular value is not found in a data field). A “negate” checkbox for each HTAG is to be included in a future release. HIVE also allows applications to interact directly with HTAGs. For this the designer of the page only needs to know the HTAGs that have been defined within HIVE, and he can then include in the INPUT field of the form HIVETAG=”PHONE-NUMBER”. HIVE then captures this and knows that the input to this form should be protected by the HTAG that enforces a telephone number format. However, in this case HIVE can carry out this check prior to the request reaching the application, freeing the designer from having to worry about security within the application itself. HIVE has a monitoring system, which displays the errors that are produced during the communication between the Web client and the HTTP server. Providing the application has been defined correctly by the administrator in the first place, it is important to note that illegal access attempts blocked by HIVE are real attempts - genuine modifications of requests requiring an effort on the part of a malicious user. Unlike generic network level signature patterns which can be triggered by innocent network traffic, once an application has been defined accurately, HIVE is incapable of producing false positives. There are three different ways to access the HIVE log information:
Within the Web interface, the log entries are displayed on a page where the administrator can elect to view the last 25, 50, 100 or All alerts. The log entries are displayed in a simple HTML table with the following columns:
Because the alerts are displayed in a simple table, there is no way to sort the entries by a different column, nor to filter them to display, for example, all the alerts for a particular Configuration. Neither is it possible to acknowledge individual alerts and clear them from the list - it is only possible to clear the entire list or nothing at all. It is thus not as easy as it should be for the administrator to process the log entries. The only nod towards allowing further analysis to take place is the ability to download the current log as a text file, which could then be read in to another application perhaps. The one convenience feature which is supplied via the logs is the ability to define the URL mentioned in the alert as a Start Page with a single mouse click. This works well when HIVE is in Learning Mode, where it will generate a large list of “suspicious” URLs, allowing the administrator to choose those which are legitimate Start Pages and add them to the Configuration relatively quickly. Each alert modified in this way turns green on-screen, but it is not possible to filter those out of the log display, once again making it more difficult than it should be to process a large block of log entries in Learning Mode. This is one area of the product which would benefit from further development.
Within the HIVE Administration menu there is a Statistics option which provides a summary screen containing the following information:
Below this are two pie charts which display the percentage of attacks blocked and the total traffic passing through each Ethernet interface. Apart from this display, there are no reporting or analysis features built in to HIVE. Performance HTTP performance with security policies enabled were felt to be within acceptable limits for a device of this type. Note, however, that performance takes a further hit when HIVE is forced to sign objects on a page. In our “real world” tests, where genuine Web pages were mixed with associated GIF/JPG images to increase the overall response size, HIVE performs much better. Basic latency figures were acceptable for a device of this type with all packet sizes at traffic loads up to 250Mbps. With more typical (larger) packet sizes, latency remained acceptable up to 500Mbps, and it was around 800Mbps before the device began to drop packets and latency increased to unacceptable levels. HTTP response times were acceptable across all tests up to 75-80 per cent of the maximum load (as determined in our tests). Exposing the sensor interface to an extended run of ISIC-generated traffic had no adverse effect, and the device continued to detect and block all other exploits throughout and following the ISIC attack. Some people reading this report may be alarmed at the apparently low figures reported during these tests. However, it is worth reiterating that this is NOT a network-level device, and its only requirement is to be able to outperform the Web server it protects and the Internet pipe to which it is protected. Whereas HIVE would act as a bottleneck in front of a heavily-used quad-Pentium server installed on a Gigabit LAN, it should be perfectly capable of handling a typical Web server on a typical high-speed Internet connection. Careful capacity planning is required on the part of the administrator, however, particularly in view of the overall limit on HTTP connections per second. Security Effectiveness Most of our attempted attacks were blocked successfully with very little configuration required. One of the most striking benefits of HIVE was that there was no need to perform any changes on any of our applications in order for it to function, and a high degree of protection was provided with a minimal amount of configuration of the product. Buffer overflow protection, shell code detection, Cross Site Scripting protection and Cookie Poisoning prevention all worked well. Interestingly although HIVE does not contain signatures or a detection engine for common HTTP vulnerabilities, it still managed to detect and block all of the exploits we attempted either via the ability to detect shell code, or via the ability to block direct access to disallowed pages (including CMD.EXE and other critical system files). Overall, we were very impressed with the high level of protection provided for such a minimum amount of configuration. Usability The HIVE Web interface is something of a mixed bag. Once the administrator is familiar with its operation then it is certainly very responsive and quick to use. Day to day operations can be performed very quickly, despite the overall complexity of the product (Web Application Firewalls in general are not tools which are suitable for the beginner). However, we found it to be very counter-intuitive in several places, particularly when first creating a Configuration - a process which in our opinion is crying out for a hand-holding “Wizard” capability to make life easier for the administrator. There is no central management server, and no easy way to create multiple policies for separate devices and deploy them from a single console. Alert handling capabilities are extremely basic, and there is virtually nothing in the way of management reporting and analysis. It could be argued that the Web interface currently does everything that it needs to in order to make HIVE an effective security tool, but there is definitely considerable room for improvement. None of this affects the overall ability of HIVE to perform its allotted tasks, however - as a Web Application Firewall, HIVE does an excellent job. Company
name: Sentryware Click here to return to Web App Index Section |
Security Testing |
Send mail to webmaster
with questions or
|
