 |
|
|
Produced by Entercept Security Technologies (formerly ClickNet), Entercept is a host-based IDS, but with a difference. Entercept�s functionality is very different from traditional Host IDS systems, even though both reside on the host itself, because Entercept works at a much lower level than a normal HIDS system. Typically, a HIDS product reads events recorded in system or application log files, compares them to its rules, and takes action if entries match a rule. An example of a rule might be �Creation of a new user account�, or �Unsuccessful login attempt to the administrator account�. If a rule match occurs, the HIDS reaction can range from the traditional alert and alarm, to locking a user account or terminating a user session. However, in all cases it is important to realise that the remedial action can only occur after the attack has been detected, which will always provide a window of opportunity in which the attacker can ply his nefarious trade. In many cases, by the time the attack has been noticed, the damage has already been done. This is not a fault of either NIDS or HIDS products, they are simply reactive by nature. Entercept is different in that it monitors events at the operating system or Web server level. It sees the same events that may be used by the OS to create a log entry, but by seeing these events before they are processed by the OS or the Web server, Entercept can prevent them before any damage occurs. Since Entercept does not deal with network-based exploits, it is very complementary to existing solutions that deal with attacks on that level, such as firewalls and network-based Intrusion Detection Systems. Typical of its type, Entercept comprises a number of host Agents that are controlled by a single central Console. Agents are available for Windows NT 4.0 (Workstation or Server), Windows 2000 (Professional or Server), and Sun Solaris 2.6/7/8. In addition to standard Server Agents, there are also Web Server Agents available to provide protection for Microsoft IIS 4.0/5.0 or Apache. Each Agent has a minimal footprint (in the order of 3MB of RAM and less than 3 per cent CPU utilisation for most normal operations) and communicates with the Console via Triple DES-encrypted sessions. In all cases the Agent is the master, and the Console the slave � this means that it is the Agent that initiates the connection to the Console, and thus there are no open listening ports on the Agent hosts. The Agent contacts its designated Console at regular intervals controlled by a heartbeat parameter. This is initially set at 30 seconds, but we would recommend altering this on larger networks with many Agents, where chatter between Agent and Console could result in significant network traffic if left unchecked. If communication with the Console is interrupted for any reason, the Agent will show as �not connected� at the Console, but will continue to operate in a stand-alone manner. Security events will be stored locally until connection is re-established, though if the local storage capacity is exceeded new events will overwrite the oldest, perhaps providing the means for an attacker to erase evidence of the real purpose of his visit. Each Console is able to manage up to 1000 Agents in the current release - if more Agents are needed, additional Consoles will be required. Unfortunately, there is no easy way to move Agents between Consoles, which means that if you grow over time to 1100 Agents, there could be one Console managing 1000 and a second managing just 100 � hardly a fair distribution of workload. In addition, there is no means of consolidating reports across multiple Consoles in the current release. Entercept is a kernel-level security technology, although it does not actually modify the OS kernel in any way. Instead, the Agent installs itself just above the kernel, where it can intercept System and API calls, understand their parameters and context, evaluate them in real-time against malicious behaviour, and then allow them to be processed by the OS, or reject them.
As with normal applications, all exploits need to use OS resources in order to achieve anything. Therefore, the System Call/API Call interface is the logical place to reside in order to have a complete view and understanding of a machine�s processing environment. In order to be proactive, a protection system needs to reside at this level if it is to have the capability to prevent hacks in real-time. The context of System and API calls is well-defined - they are used in a well-documented way, with well-defined parameters, in order to achieve specific and identifiable results. Because of this, there is little ambiguity in determining whether a request for system resources can be termed �good behaviour�, or whether somebody is trying to exploit a known vulnerability. In addition, nothing is encrypted at this level, meaning that all parameters are passed in clear-text, making it easier to identify malicious intent and keeping false positives to a minimum. Entercept provides five layers of protection. Individual signatures: Point signatures deal with specific exploits, and every exploit has its own dedicated signature (similar in operation to the traditional pattern-matching Network IDS). This is very accurate, with almost no false positives, but suffers from the usual problems of requiring regular signature updates to catch new attacks. Generic Signatures: By identifying attack methodologies that a multitude of discrete exploits use, it is possible to determine a generic way to describe those exploits. Generic signatures prevent whole classes of exploits, without needing a dedicated signature for each one of them. For example, by understanding how buffer overflow exploits work, it is possible to catch (and prevent) all of them with one single signature. This is much easier to achieve when operating at the kernel level, since aberrant behaviour can be spotted before the buffer overflow is executed by the target application. Resource Protection: Signatures that prevent modifications to specific system resources, such as files, registry keys, user attributes, services, etc. This provides the means to �harden� the system by forbidding modifications that would lower the overall system security. HTTP Protection: The engine examines the incoming HTTP stream and determines whether requests try to exploit known vulnerabilities of the Web server (such as directory traversal, illegal code execution, etc). If a malicious request is encountered, it is discarded before it reaches the Web server for processing. This HTTP protection also works if the initial connection is encoded with SSL, since the Agent works on the decrypted SSL stream. Shielding: Specific resource and envelope protection technology that ensures that application resources cannot be tampered with (by modifying configuration files, stopping the service or daemon, etc), and that an application can not be misused to execute functions it should not be allowed to (i.e. executing code outside of the Web server environment). This level of application security is currently implemented for the Microsoft IIS Web server and Apache on Solaris. Two Agent types are provided: Server and Web Server. The Web Server Agent provides all of the above functionality, whereas the Server Agent omits the HTTP protection and shielding for hosts that do not have a Web server installed. The Web shielding technology is particularly interesting since it ensures the integrity of the Web server, its applications and files (including customer data), and enables Entercept to protect Web servers from both known and unknown attacks. The shielding concept is based on a simple yet powerful assumption that the Web server and Web application execution pattern is very specific and repeats itself. Thus, it is possible to accurately characterise the �normal� behaviour and the typical access patterns to resources of the Web server. The �normal behaviour� of the Web server is encoded as rule templates rather than fixed rules, allowing the Web server to be installed and configured in different ways for different installations. As the Agent starts up, the shielding mechanism initiates a scanning process that gathers a set of attributes reflecting the details of the installation and configuration of the Web server, including services, program files, data files, Web pages and Registry settings.
Next, an instantiation program is executed that derives the appropriate rules from the given rule template. The instantiation program uses the information gathered during the scanning phase to fill the missing information within the rule template and to generate the specific optimised rules. Once the set of rules is ready, they are loaded into the Agent. This procedure is executed whenever the Web server configuration is modified. Entercept's protection tightens the security of the Web server resources to the extent that even if an intruder gains administrative privileges, he still cannot access those resources. It accomplishes this in a number of ways: Program File Shielding: The shielding protects the Web server executables and configuration files from being modified or deleted. As an example, the �inetinfo.exe� file, which is the main IIS executable, will be located and an appropriate rule including its current directory will be generated. This rule will not allow any program other than the Windows Installer to modify this executable. Data File Shielding: Access to the Web server data files is restricted to the process running the �inetinfo.exe� executable. Since the executable is shielded, it is guaranteed that no other process will access the data files. In addition, the static Web pages are also shielded, and any attempt to either modify or delete these pages is prohibited. The only program that can modify these files is the predefined Web-authoring tool run only by the predetermined Web master. Registry Shielding: To function properly, the Web server relies on settings stored in the system Registry. If the intruder modifies the appropriate Registry entries, he can affect the operation of the Web server. The Registry shielding makes sure that the correct level of read/write access is granted only to the appropriate processes. Service Shielding: To prevent denial-of-service attacks, the Web server shield includes rules that prevent any attempt to stop the Web server service or change its start-up mode. User Shielding: The shield makes sure that the privileges of the users under which the Web server runs cannot be modified. This eliminates the possibility of escalating the privileges of the Web server user, a common goal of intruders. The shield also prevents changing the user under which the Web server is running. If, for example, the user was changed to Administrator, ensuing attacks could be harmful since the attacker could execute code with Administrator rights. Hackers often exploit Web server and application vulnerabilities in order to escalate privilege, execute malicious commands or access data. Since the normal behaviour of the Web server is well defined, most of these deviations can be identified and prevented. Web shielding ensures that nobody (process or person) can alter the configuration, layout, and operation of the Web site. Even if intruders gained administrative privileges on the server box, they still would be unable to deface or otherwise modify the content files (such as the corporate Home page). For example, even without the appropriate patches in place, hosts protected by the Entercept Web Server Agent would have been immune to the recently reported Lion Worm and IIS Unicode directory traversal vulnerability, as well as the recent spate of Web site defacements. One of the key advantages of Entercept is the fact that all activity on the host is seen, and is not impaired by encryption, switched data or reliance on system log information. Entercept functionality can be used to protect specific resources of the OS or applications (registry keys, accounts, files, processes, and so on), and from that point of view, it can be viewed as a means to harden both the OS and applications on a server. It is important to bear in mind, however, that Entercept cannot be customised by the end user with regards to the resources and applications it protects. This determination is currently done by the Entercept eKat group which designs and implements signatures. Installation is very straightforward, simply running the Windows Installer from the CD supplied. The Console is installed first, and the main prerequisite is that it has a static IP address. This is because the Console address needs to be known by all the Agents, since they initiate all communications between Agent and Console. During installation a public/private key pair is generated to enable Triple DES encryption between client and server. The Agent can also be installed from the CD or from a network share, and it must be pointed to the IP address of the Console (the Agent itself can either have a static or DHCP-allocated address). The Console public key must be provided to the Agent during installation, the safest means being via an out of band method such as floppy disk. Although the initial installation is performed manually, subsequent upgrades to the Agent are carried out automatically from the Console. Organisations with large numbers of Agents to roll out may want to consider the use of third party software distribution tools for the initial installation. Despite the low-level operation of the Agent software, no reboot is necessary after installation (or uninstallation), and the Agent immediately contacts the Console to determine its initial mode of operation. Parameters in the Console specify whether the Agent should be active by default following installation, and whether it should start up in �warning� or �protection� mode (see Configuration section for more details). All new Agents automatically join the �New Agents� group following installation, and have the Default security policy applied. This means that the host is protected as soon as the installation process is finished, and makes Entercept incredibly easy to have up and running quickly. Virtually no configuration is required to have Entercept up and running and protecting your network with a default policy. All the defaults are sensible, and a default policy is applied automatically to all new Agents. The Console is protected by a user name and password combination, and any number of users can be created, although there is no provision for user/role-based administration in the current release. All critical configuration files and databases are protected by the Entercept Agent itself, a copy of which is automatically installed on the host machine during installation of the Console software. The main Console screen is clear and easy to read, with a toolbar down the left hand side, menu bar and alert summary across the top, and the majority of the screen given over to the monitoring window. The Policy option determines how specific Agents or groups of Agents will react to security events, and which people will be notified of those reactions. Actually, there is very little work involved in creating a Policy at this level since, unlike most other IDS products, it is not necessary to specify which signatures are used in each Policy � because of the Entercept architecture, all signatures are always applied (and this does not appear to have any serious impact on the performance of the host machine). Instead, all that is required is to define the Agents and/or users to which the Policy applies. Policies can be as granular as they need to be � applying to a single host or user if required � since it is possible to apply multiple Policies to individual entities. Where conflicts occur (where a group-based Policy has different settings to an individual one, perhaps) they are resolved automatically by Entercept applying the highest security setting of those that are in conflict.
Each alert generated by an Entercept Agent has a severity level associated with it - high, medium, low or info � and this determines the action that is taken by the Agent when each alert is raised. Four direct actions are supported:
In addition to one of the four direct actions above, it is also possible to generate additional alerts via e-mail, pager, spawn process (which could also take additional corrective action via external programs, scripts or batch files), or SNMP trap. Log entries are always recorded to the Entercept database and reported directly to the Console screen.
The Agent Management screen provides a list of Agent groups down the left, and Agent details on the right. It is the Agent Groups that determine the security policy that is applied and, as mentioned previously, it is possible to allocate Agents to more than one group. All new Agents appear in the �New Agents� group by default, from where they can be moved into other groups as required. The default policy is always applied automatically from the moment the Agent is activated, however, thus ensuring that the host is always protected. Selecting any Agent Group brings up a list of Agents within that Group, with details of the Agent type (OS platform, and whether it is a Server or Web Server Agent), version, current state and requested state. The Console can check the Entercept Web site at regular, administrator-defined intervals and automatically download new versions of the Agent software. These are available via the Versions menu option, where it is possible to place new Agents into �test mode� on certain hosts only. Once correct operation has been verified, the new versions can be rolled out to all the hosts controlled by the Console automatically � no reboot or other intervention is required on any of the Agent hosts. The �state� of an Agent can be warning mode or protection mode, which are fairly self explanatory. Warning mode logs all suspected security violations but does not actually prevent them from happening. It is recommended that Agents be run in warning mode for a short period of time following installation to allow the administrator to get some idea of what could be considered �normal� behaviour. For example, Entercept will always log details of any attempt to add, delete or modify files in the protected Web directories. However, these are all normal activities for your Webmaster, and so you would want to define Exceptions to these events. An Exception allows the administrator to specify when a particular security event can be ignored in order to filter out false positives, and it can be applied on an individual Agent, user or process basis if required. This would allow a rule which says that files can be added to the Web root directory only if they are added by user Webmaster, using FrontPage on server WebServer. It is also possible to specify individual Security Level Modifiers for the signatures within Entercept. These are, in fact, the individual components of a security policy, and define how Entercept will respond to specific security alerts. Every signature has a detailed description and a default security level (high, medium, low or info) associated with it. When a signature is activated, the Policy is checked to determine what action is to be taken, as defined by the security level. For every signature, it is possible to override the default security level on a global basis (i.e. for all Policies) or on a per-Policy basis via the Security Level Modifiers. For example, if an attempted directory traversal is detected on an Internet-facing Web server, it could be designated as �High�, whereas on a purely internal server it would be �Medium�. Whereas �Medium� priority would ensure that the event is prevented and logged, �High� priority may also reprogram the firewall (via a spawned process) to prevent further traffic from the attacking host, as well as raising an SNMP trap to escalate the alert to a central network management console.
Security Level Modifiers provide an enormous amount of flexibility in how attacks are handled within Entercept, but once a large number of them have been defined it can be difficult to determine exactly what constitutes an individual Security Policy. Although each Modifier can be associated with one or more Policies, there is no �top down� view that will display all Modifiers that apply to a specific Policy. This seems a strange omission, though it is not as critical as in other IDS systems since the Modifiers merely change the default reaction of the Entercept Agent to a given attack. They do not determine which signatures are applied to an Agent since, as we have already said, all signatures are always active. It should also be noted that there is no means for the administrator to actually change the parameters of an attack signature or add new signatures to an Agent � this can only be done by the eKat team within Entercept. Once normal behaviour has been established for a particular Agent, and the appropriate Exceptions and Security Level Modifiers have been created, the Agent can be switched into protection mode via the Console. From that point onwards, all security events are enforced strictly. Those events which are marked as ignore or log are allowed to pass, whereas those marked as prevent will be stopped and logged immediately by the Agent.
Note that even in warning mode, there are some events � such as trying to delete the Entercept database � which will always be prevented. The Console provides two real-time monitoring screens which display events as they are transmitted from the Agents. There is also the Entercept Level Watch, which provides a quick event summary screen (event counts by security level) that can be accessed immediately via an icon in the system tray. The Security Event Monitor lists security events reported by the various agents that report to the Console. It provides a one line description of each event, and the list can be filtered by security level, Agent ID, event name, date, user name, or process ID. This makes tracking down similar or related groups of events very straightforward.More detailed information can be displayed for each event by viewing its properties, where the event and the actions that triggered it are described fully. If it is decided that a particular event is a false positive, a click of a button is all that is required to create an exception based on that event.
The System Event Monitor screen is very similar in appearance and operation to the Security Event Monitor. It�s job, however, is to monitor Entercept�s system activity, such as services starting/stopping, console administrators logging on/off, agents starting/stopping, and so on. Events can also be filtered in a similar manner to the Security Event Monitor screen. Finally, there are a number of pre-defined text and graphical reports available via the Reports menu. A number of useful reports are provided which simply document the system configuration, whilst others provide graphical analyses of security events and reactions. Most eventualities are covered (apart from the aforementioned �top down� Policy report), which is just as well since, although it is the ubiquitous Crystal Reports that provides the reporting engine, Entercept locks down the database and configuration as a security measure, thus preventing additional user-defined reports from being implemented. It is hard to be anything other than completely positive about Entercept, such is the ease of use and the power of the system.Disposing of the negative aspects first will not take long. Linux Agents are missing at present, but are currently under development, and we would like to see the inclusion of just one more report that provides the top down Policy view that we mentioned earlier. It would also be nice to see a �Master Console� providing an enterprise view of implementations with multiple Consoles, providing a simple means of effective load distribution between Agents and Consoles, together with alert and report consolidation across multiple Consoles. Note that this is not even likely to be an issue until you are deploying more than 1000 Agents, however. Finally, it would extend the usefulness of the product even further were it possible to add some simple custom signatures, even if they only provided the means to specify a list of files or directories that should be monitored and protected.
In all other respects, Entercept is superb. The host-based approach ensures that there are no issues with switched networks or encrypted traffic, and the insertion of the Agent software at kernel level means that the system is capable of protecting the host against both known and unknown attacks. In addition, unlike most other IDS systems, Entercept is proactive, providing real intrusion prevention rather than simply intrusion detection. The ability not only to detect and log attacks, but actually prevent them from happening by denying access to system resources at the kernel and API level helps to make systems that much more secure. Not only that, but the provision of Web Server Agents also secures Web server software within an almost impregnable vault where virtually all attacks will be prevented before hitting the server. Should an attack actually get through, it is then prevented from operating outside the scope of the Web server itself. The recent (at the time of writing) Code Red worm is one example. Entercept users were protected even without the IIS patch in place since the worm was rejected at the HTTP layer before it could deliver its payload. Whilst we would not recommend lazy behaviour when it comes to applying security patches, it is nice to know that Entercept provides a real safety net, whereby even if a vulnerability is discovered within IIS or Apache, it is likely that Entercept will prevent the exploit even before the server is patched. Indeed, we noted that in most cases Entercept dealt with an attack before the �official� patch was called into play. Configuration is straightforward, and there is very little to do to maintain the system on a daily basis. New Agent updates are retrieved automatically from the Entercept Web site, and can be deployed in a restricted �test mode� until proved effective. Deployment of new Agents to live hosts is transparent, not even requiring a reboot of the target hosts. This really is one of the few IDS systems we have seen that can be installed, deployed and managed by an administrator with little or no security experience. It performed flawlessly in all our tests, and is highly recommended as a host-based solution. Company: Entercept
Security Technologies
Click here
to return to the Entercept 2.01 Questionnaire |
Security Testing |
Send mail to webmaster
with questions or
|
