 |
|
|
Access Denied Secure Server & Web Protect Table of Contents Introduction More and more organisations are looking beyond the physical boundaries of their own sites in the quest to make the best business use of new technology. Data communications between physically remote sites � perhaps for branch office to head office connectivity, or links between business partners � have become an essential part of modern business practice. In the past, such links have been forged using dedicated connections such as leased lines, but this approach � whilst certainly secure � can prove to be extremely expensive and inflexible. What if the sites are at opposite ends of the country, for example, or even on opposite sides of the globe? Imagine the costs involved in creating a dedicated network of such proportions. If such links are heavily used, it may be cost-effective to take such an approach, but there are many organisations who may only require those connections for a couple of hours a day, leaving a lot of unused bandwidth lying idle for the rest of the time. Lack of flexibility is another characteristic of private Wide Area Networks. Leased lines provide only fixed point-to-point network connections, which cannot be changed easily � certainly not without incurring additional cost. How, therefore, does one cope with network connections created to service transient business partnerships, which will no longer be required once the project is completed? And how does an organisation go about servicing its mobile users, each of which require a secure connection to the corporate network, but possibly from a different location every day? Internetworking is becoming the technology platform for a growing range of business uses: secure access to global resources on the Internet and other public networks; secure remote access to the enterprise network for remote users and branch offices; and compartmentalisation of the internal network for enterprise-wide connectivity and security. To meet the rapidly evolving connectivity needs of today's networks, corporations require an integrated network security solution that is flexible and extensible enough to meet their requirements now and in the future. Organisations with large populations of mobile workers also need to be able to provide flexible yet secure (preferably encrypted) remote access to business applications which are located behind firewalls. The same is true of any organisation wishing to implement electronic commerce systems, but the traditional firewall implementation is not designed to allow such free movement of traffic. With the advent of the Internet, the opportunity has arisen to provide temporary links across the public network between companies and sites. Instead of creating a true private network with all its attendant costs and management issues, we can make use of the Internet to provide a Virtual Private Network (VPN). Rather than maintaining an expensive point-to-point leased line, a company can connect each office or Local Area Network to a local Internet Service Provider (ISP) and route data through the Internet, thereby using shared, low-cost public bandwidth as the communications backbone. VPN's are not limited in the number of LAN�s or nodes that can be included in the virtual WAN. For a company that has numerous sites to link, this can result in significant savings when compared to maintaining a network of leased lines. This is technology that can be employed by companies of any size too. Not all companies require even as much as 64 Kbps for their Wide Area Network, and VPN�s can be set up to work at speeds slower than is possible with leased lines. A small company or branch office can use standard analogue modems and cheap Internet accounts to create a worldwide private network. Nor does a VPN need to be a permanent link. Dial-on-demand virtual networks can be created using analogue modems or ISDN for those sites that don�t require a full-time connection. When a user on the LAN needs to access the WAN, a modem or router automatically connects to a nearby ISP and starts sending data across the Internet. VPN links can be set up with little effort and removed just as easily. In addition, client-to-server VPN�s can be created on demand between remote user PC�s (using modems or mobile phones) and a firewall or VPN termination device at head office. This provides the means for roaming users to have access to corporate networks no matter where they may be located. Implementing a secure VPN to connect remote PC users to the local network results in significant cost savings for businesses. A VPN reduces the number of modems and telephone lines required centrally to support dial-in networking, and dramatically decreases long distance charges since remote PC users would connect to their local ISP instead of dialling direct to head office. Of course, with all this sensitive corporate data flying around the public network, security becomes a primary concern. Unprotected data sent across the public Internet is susceptible to being viewed, copied or modified by unintended individuals or organisations. Data can be tampered with en route and valuable systems can be sabotaged. Both ends of the tunnel must ensure beyond any measure of doubt that they are communicating with a valid host or client at the remote end of the link. Once the link has been established, data travelling within the tunnel must be encrypted to ensure that no one who may be eavesdropping the conversation can gain access to the raw data. The most important considerations for Internet security are: Authentication � verifying that the parties on each end of the link are who they claim to be Privacy � ensuring that transmitted content is not read or intercepted by unauthorised recipients Integrity � verifying that the transmitted data is received in an unchanged state The security risks involved in communicating over the Internet have deterred some enterprises from taking full advantage of Virtual Private Networks. Doing business over the Internet � including transferring funds, obtaining and verifying credit information, selling and even delivering products � requires a reliable and effective security solution. Current offerings in the VPN market place are more than capable of providing secure links between two locations. Some are only capable of establishing a link between two secure gateways, or firewalls, whilst others are designed to provide a client-server VPN, allowing individual remote and mobile users to establish secure links back to head office from their hotel room. High levels of authentication and encryption � using digital certificates and powerful encryption algorithms � ensure that sensitive corporate data remains private. But whilst the VPN provides secure site-to-site or client-to-site links, and the firewall (hopefully) stops all unwelcome visitors at the front door, this is not always what we want. Many companies today need to be able to provide access to sensitive information behind the firewall for users that are outside the perimeter security. Once you open holes through the firewall, however, how can you be sure that it is only the �right people� that exploit them. Or perhaps you move critical servers to the De-Militarised Zone (DMZ) of your firewall. Now at least the internal network is protected once again, but you still need to ensure that only authorised users are accessing your DMZ resources. The Application Gateway is installed on the application server itself (or directly in front of it), providing an additional level of protection as close to the source of the data as possible. Now, even if a user gets beyond the firewall (whether legitimately or not) he is still required to authenticate before being allowed access to the data held on the target server. Thus an attacker is now frustrated in his attempts to access confidential data even after going to all the trouble of breaking through the firewall, whilst a legitimate user can be provided with different levels of access to different hosts depending on his role in the company. In addition to fine-grained authentication, most Application Gateways also allow the VPN to be extended right from the client to the target server. Most VPN solutions only provide protection to the network perimeter, meaning that once the tunnel termination device is reached, data travelling beyond that will be in the clear. For many organisations, this is not a problem since they are not looking to secure data travelling across the internal network. But this is not always the case. For example, should an attacker breach the firewall and find his route to the critical hosts blocked, he may well simply set up sniffer programs to capture data travelling across the internal network. Given that most Internet protocols are inherently insecure, this could quite easily provide the attacker with a list of user name and passwords, or perhaps he might even be able to lift the data right off the wire without ever having to go near a protected host. Clearly, therefore, it would be beneficial to encrypt data as it travels across the internal network, thus rendering it immune to wire-tapping. This approach could also be beneficial to many organisations where it is necessary to keep some data secret to certain departments � personnel or research and development, for example. Obviously the hosts on which this data resides will be secured, but what happens when data is transferred from one authorised employee to another? From one PC to another. If it travels across the network in the clear, it can be accessed, and would thus be better encrypted. The Application Gateway typically provides a combination of firewall, authentication and encryption capabilities. With a server component located on the host and a client component installed on every end-user�s PC, the administrator can be sure that data communications are authenticated at the outset, and then securely encrypted all the way from the client to the server and back. Access Denied Secure Server & Web Protect Access Denied covers a suite of products that together provide a distributed security solution and Application Gateway. Access Denied Secure Server is designed to prevent the formation of a usable data channel until after positive authentication is achieved. Coupled with the Web Protect client � which is the focus of this report � it is possible to prevent unauthorised users from gaining access to Web servers until they have authenticated to the Secure Server. It goes much further than traditional user name and password combinations, however, since it also enforces access based on IP address and physical hardware characteristics. When used in conjunction with a firewall, Access Denied Secure Server (ADSS) and Web Protect provide a high level of protection for corporate Web servers, whether located on a DMZ or on an internal subne The Access Denied architecture is three-tier, which is accomplished using two pieces of software by virtue of the fact that the Web Protect client serves a dual purpose. The Access Denied Secure Server is the central policy server that determines access rights and authentication details for individual users and groups. The Secure Server is modular, and has a number of features that are only of use with other client components that were not made available for this test.
The Web Protect client serves two purposes, as mentioned above. The first is as a secure proxy server, which is usually located on a dual-homed host in front of the Web server to be protected. It is also possible to locate the Web Protect proxy on the Web server host itself, in which case the �real� Web server is moved to a different port so the Web Protect proxy can listen on port 80. As clients attempt to connect to the Web server, it is the job of the Web Protect proxy (�masquerading� as the Web server on port 80) to intercept those calls and communicate with the ADSS in order to retrieve the client profile. If the remote user is not running the Web Protect client, or if a client profile is not available, then the connection is refused immediately. If, however, a valid profile is retrieved, then its contents are compared with the authentication details provided by the user before an onward connection to the Web server is allowed. By default, therefore, the Web Protect proxy denies access to anyone who is not a valid client. In order to communicate with the Web server, through the proxy, it is therefore necessary for each user to be running the Web Protect client, this time operating in pure �client mode�. The job of the Web Protect client is to communicate with the Web Protect proxy in order to positively authenticate the end user. A combination of user name, password, IP address, electronic serial number (ESN � a form of �digital signature�) and unique hardware tag is transmitted to the Proxy where is can be compared with the user profile stored on the Secure Server. Only when the user�s identity is confirmed is an ongoing connection to the Web server allowed, and regular re-authentication throughout the session prevents session hijacking attacks. All communication between client and Proxy, and between Proxy and Secure Server, is fully encrypted using ART�s patent pending 2048 bit polymorphic (continuously changing) encryption technology. Since the Secure Server is modular, other encryption technologies can also be used if required, although there is no support for additional mutual authentication measures between the Proxy and Secure Server, such as X.509 digital signatures (which would be a useful capability). Clearly, because the Proxy is performing a significant amount of work for each connection (compared a Web server which is not running a Web Protect Proxy) it is possible to have multiple Proxies installed on separate hosts, each pointing to one or more Web servers. This provides an element of load balancing to restore performance on heavily loaded sites. Installation is very straightforward for both client and server, using the standard InstallShield Wizard. Unfortunately, there appears to be a problem under Windows 2000 Server in that none of the components run automatically on booting the host PC. Nor were there any program groups, Desktop icons or menu entries created to allow us to run the software easily. This does not appear to be a problem under Windows 2000 Professional or earlier versions of Windows or NT, but needs to be resolved under W2K Server in order to prevent potential Denial of Service situations following an unattended reboot of the host. Initial configuration was also very confusing, due mainly to the poor documentation which neither relates to the latest version of the software, nor provides enough explanation as to how the various components of the system interact together. This, coupled with the fact that the Web Protect client servers two purposes (both a client and a Proxy) makes it difficult to configure initially. It is necessary to enter sensible values in some of the dialogue boxes which relate only to the Proxy functionality, even if the software is to be used as a client only. It would be preferable to implement check boxes to determine the use of the client, at which point those configuration parameters which are not used could be greyed out and sensible values entered automatically. Once the initial configuration has been accomplished, however, ongoing maintenance is simple. All management tasks can be accomplished via the Secure Server console, which utilises a very straightforward tabbed interface. The first thing you notice, however, when starting up the program is that there is no login procedure, which means that you must rely only on the underlying OS security and directory permissions to protect the configuration databases. Anyone who can log into the Secure Server host with the appropriate permissions will be able to configure Secure Server � a strange situation for a security system of this nature.
As far as the server itself is concerned, all that is necessary is to enter the port number on which it will listen for authentication requests from clients, an IP address (which can be a network address to restrict which hosts can connect to the server, or 0.0.0.0 to accept requests from any Proxy), and a protocol (TCP is used at present, though others can be added in the future). Details of a SOCKS proxy can also be entered on the General Settings page before the Secure Server is started. From that point on, maintenance of the Secure Server is extremely simple. The system stores security profiles � one per user � that determine how authentication is performed. Each user who is registered with the system can have five values stored as part of their profile: User name Password IP address Electronic Serial Number (ESN) Hardware tag User name and password are the typical means to authenticate to a server, but Access Denied takes this further by providing the means to tie each user to a specific IP address, and even a specific computer if required by means of the remaining identifiers. The ESN and hardware tag, for example, are generated via algorithms in the Web Protect client that create unique values from various combinations of hardware and software settings on the host PC.
Thus, user authentication can be tied down very securely, and each Group within Secure Server specifies which of the above identifiers should be applied. A �Full Access� group, for example, might insist that all the above are verified before a connection is allowed. Conversely, if a hot desking capability is required � where users can move freely from PC to PC � then the �Hot Desk� group would only enforce user name and password checking, and none of the others. Each group can also have a set of �Functions� associated with it. These provide information to each remote client from the central server, including a common date and time, directory access details, whether FTP is available, and so on. Unfortunately, the Group Functions are not supported by the Web Protect client, so we were unable to test them. Finally, each Group can be enabled or disabled via the Secure Server. Disabling a Group ensures that all members of that group are denied access to the system in a single operation. Although it is possible to add users manually when you do not need to specify the ESN or hardware tag, most of the time it is more convenient to allow semi-automatic registration. Here, whenever a new WebProtect client is detected attempting to make a connection, rather than being rejected outright the client details are transmitted securely (encrypted) to the Secure Server and placed in the list of �Potential Users�. These users are classed as semi-authorised, and the Secure Server automatically records information on their user name, password, unique hardware tag, electronic serial number (ESN), time and date of connection. Note that a Potential User enters their own password into the Web Protect client program, which is considered more secure than using a password provided by the administrator which could be intercepted en route from the administrator to the client. However, there does not appear to be a means to enforce a particular password policy from the Secure Server - such as specifying minimum length, or a mix of alphabetic and numeric characters � and this could lead to weak passwords being chosen by the user.
The administrator can then use this screen to authorise or deny access to specific users. Once the identity of the user has been verified, he can be added to the list of valid users and placed in a specific Group to determine access rights. All the profile data is transferred automatically to the database of authorised users at this point. The system is designed primarily to accommodate an �accompanied registration� model. That is to say that when a potential user receives the �Access Denied� Web page, he will be instructed to contact the administrator in order to complete the registration. The administrator will then go through the process of verifying identity and authorising or denying access whilst in direct contact with the user. Some organisations might require more of an �off-line� approach, in which case it would be nice if there were an alert mechanism built in to inform the administrator each time a new user is detected. Even after the administrator has authorised the potential user, the user is not automatically granted access. It is still necessary to call up the �Users� tab - as an additional security precaution � in order to finally enable the account. All validated users are listed in the Users table, in alphabetical order, and via this screen the administrator can enable or disable them individually. Probably the most disturbing feature of the Access Denied Secure Server is evident in this screen, which displays the user name and password in clear text. Bear in mind that there is no login or other authentication capability to prevent non-administrators from accessing the Secure Server, so to display passwords in this manner is not a sensible option. Even if the password were masked here, it is still stored in plain text in the user database that resides under the Secure Server program. We found it a simple matter to subvert the system by copying the configuration databases to another PC and viewing their contents using a hex dump utility.
Other screens in the Secure Server administration utility provide the means to view log details and usage graphs, control clients remotely (not Web Protect clients), and perform port scans and traceroute operations. There is not much in the way of detailed reporting provided by Secure Server. But in truth, not much is needed. The Log screen in the Secure Server administration utility provides an entry for each request made by a Web Protect Proxy to retrieve authorisation profiles, and this can be sent to the printer or summarised in graphical form. In addition, there is an extremely detailed log which is maintained in real-time on the General tab of the Secure Server (see Figure 2). This provides full details of every client authentication request, including all the profile entries.
Unfortunately, once again, user name and password are displayed in clear text. Each time the Secure Server is shut down, or if the log file grows too large, these details are written to text-based log files on disk. This provides the simplest means for potential attackers to access supposedly confidential user name and password combinations � this aspect of the Access Denied system requires some changes to ensure that passwords are not made so freely available. The Web Protect client serves a dual purpose: as a Proxy server whose job it is to protect the �real� Web server behind it, and as a pure client whose job it is to facilitate end-user authentication via a Proxy and Secure Server. The Web Protect Proxy is usually installed on a dual-homed host which is installed � like a firewall � between the untrusted portion of the network and the protected Web server(s). The proxy client can also be installed directly onto the Web server which requires protection, if required (although this would lessen the level of protection available unless a full-blown firewall were also installed to ensure that the proxy host cannot be bypassed). In this case, the Web server is moved to an alternative port, and the Web Protect Proxy listens on port 80 for client connection requests.
For each request seen on the HTTP port, the proxy does one of three things, depending on how the client attempts to connect: Access Granted (private page): If a Web Protect client is detected, the Proxy will examine the client authentication details and pass these to the Secure Server to determine access rights. If a valid profile exists on the Secure Server and the authentication details match, then the Proxy simply passes the request to the Web server and the whole process is transparent to the end user. The client is also forced to re-authenticate at regular intervals with the Secure Server in order to prevent session hijacking attacks. Note that if the Secure Server is unavailable for any reason, the client is simply prevented from accessing the protected resource. All authentication communications between Web Protect client and Web Protect Proxy, and between the Proxy and the Secure Server, are fully encrypted using 2048 bit polymorphic encryption. Failed authentication page (private): If a Web Protect client is detected but the client details do not yet exist in the Secure Server valid user database, then the client details are added to the list of Potential Users on the Secure Server for examination and approval by the administrator. The Proxy returns an HTML page (which can be defined within Web Protect itself) to the client informing the user that the site is protected by Access Denied and that he does not have the required permissions. Once the profile details have been added to the user database, the client will be able to authenticate successfully at the next attempt. Access Denied (public page): If no Web Protect client is detected, then the user is prevented from gaining access to any protected resources. However, rather than return an �Access Denied� message � which is a red rag to a bull to most hackers � the Proxy returns a dummy Web page which makes it appear as though access has been granted. This Web page can be defined within the Web Protect proxy, and can obviously act as a home page to a complete �dummy� Web site hosted on a non-critical (and thus unprotected) Web server if required. Configuration of the Web Protect Proxy is simple enough, though it would be much better if there was a clearer distinction - perhaps enforced by check boxes and greyed-out options � between when the Web Protect is used as a pure client and when it is used as a Proxy.
When used as a Proxy, it clearly needs to be pointed at the Web server it is protecting, and the Secure Server that will provide the security profiles for authentication. It is also necessary to define the HTML pages for the Access Granted, Failed Authentication and Access Denied scenarios mentioned above. Thankfully, some sensible defaults are provided out of the box (and the Access Granted page can be ignored altogether if the Proxy simply passes authenticated users directly to the protected Web server). There is virtually no configuration to do at all when Web Protect is used as a pure client, though sensible values still need to be entered into the Proxy and Secure Server sections, otherwise the client will not run. These entries should be defaulted to something sensible when the client is installed. Once again, however, Access Denied commits the cardinal sin of displaying the user name and password combination in plain text on the configuration tab. Given that the client software will usually be left running all the time, it would be a simple matter for someone to acquire supposedly confidential user name and password details from a PC vacated temporarily by another user. Relying on users implementing password-protected screen savers to prevent this from happening is dangerous. Note that once a valid user is connected, there is no way to restrict access to certain portions of the protected Web site. Having authenticated the user, the Proxy then simply allows all subsequent communication unmolested (until it is time to re-authenticate), and so subsequent access control must be performed within the Web server itself. Access Denied does have some serious shortcomings in the way it handles user name and password combinations when they are outside the encrypted data channel used to communicate between client and server. The fact that all profile data can be viewed in plain text on the various configuration screens, is stored in plain text databases, and written as plain text to log files means that it is an almost trivial matter for an attacker to acquire a valid user name and password combination. From there, it is theoretically possible for him to reverse engineer the ESN and hardware tag algorithms and write a fake profile into the Secure Server databases. This would then allow the attacker to gain �legitimate� access to the supposedly protected resource. Note, however, that it would be necessary to gain access to the Secure Server host in order for the configuration files and logs to be accessed, and this machine would normally be installed on the subnet that is being protected by the WebProtect proxy. Additional protection could be afforded by third party security tools to lock down the Secure Server host and encrypt disk contents. It would also be wise to ensure that password protected screen savers are used on all WebProtect client machines, since user name and password combinations are also displayed on the client software in plain text. By and large, however, Access Denied Secure Server does the job it is intended to do. It provides a secure, distributed means of authentication in order to provide protection for Web servers via the Web Protect client. This protection goes well beyond traditional user name and password combinations, since it is also capable of applying other hardware-specific identifiers to the security profile in order to ensure that a user has not only provided the correct authentication details, but is also working at the correct PC. Access Denied thus provides the much needed missing element of individual user authentication that is often missing from off-the-shelf firewall systems. Where such authentication capabilities are included in a firewall product, it is rare that they will apply more than user name, password and maybe IP address to the authentication procedure. The Access Denied system also stood up to our best attempts to penetrate it (though we did not test it in a dual-homed host configuration). It was not possible to sniff data traffic to gain access to user names and passwords, nor was it possible to force access by using forged credentials or even valid user names and passwords from machines that were not identified in the user profile. Where we launched successful Denial of Service attacks against the underlying operating system, Access Denied also ensured that the requirement for authentication was not eliminated, although this did mean, of course, that the DoS attack affected all hosts protected by the Access Denied system.
Contact:
Access Research
Technologies Limited As part of this evaluation we performed a number of penetration tests against the Access Denied Secure Server and its protected resource. The test environment consisted of two distinct networks � Head Office network and Remote Office network: A Web server running IIS 5 was located on the Head Office network and a Web Protect Proxy client was installed on the same host (running Windows 2000 Server). The proxy was configured to listen on port 80, and the Web server was configured to listen on port 8080. The proxy was configured to pass all valid requests through to the Web server on port 8080 (NB: We did not test a dual-homed host configuration) A copy of Access Denied Secure Server was installed on a second host on the Head Office network (running Windows 2000 Server) A copy of Web Protect client was installed on a Windows 2000 Server host on the Head Office network Copies of Web Protect client were installed on a Windows 2000 Professional host and an NT4 Professional host on the Remote Office network. No firewalls or other security measures were deployed alongside the Access Denied products for these tests. No additional precautions were taken to secure the protected or ADSS hosts other than that which was performed by the software during installation. The following tests were performed:
|
Security Testing |
Send mail to webmaster
with questions or
|
