Abstract:
A client application server includes a client server, a proxy authentication server, and an authentication server. The proxy authentication server maintains a set of one or more authentication rules and an authentication request table. The client server is responsive to an authentication request from a user including a user identifier for directing the authentication request to the proxy authentication server for searching the authentication request table for entries for the client; responsive to finding one or more entries, applying the filter rules; responsive failing a filter rule, rejecting the authentication request in a response message to the client server; and responsive to passing all relevant filter rules, directing the authentication request to the authentication server for authenticating the user.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Technical Field of the Invention  
         [0002]     This invention relates to protecting a server against multiple login denial of service attacks.  
         [0003]     2. Background Art  
         [0004]     If a hosted web application allows multiple simultaneous logins under the same user&#39;s credentials, and the user session created upon login consumes considerable system resources, such as memory, a denial of service attack might be possible by running a simple script performing multiple user logins. The application can be brought to a non-responsive state for the duration of the session inactivity timeout, which is usually in the range from several minutes to several tens of minutes.  
         [0005]     Managers of information systems for public and private enterprises are required to provide ever increasing network access to their information systems. As business requirements for connection to the Internet grow, system security concerns increase in lock step.  
         [0006]     The current art for network and system security, which uses TCP/IP socket protocol and firewall technology does not provide complete protection for an organization&#39;s systems. Internet connected systems have an exposure to jamming by anyone with an Internet-connected computer. Some computer systems are designed for public access, and must be available to members of the public desiring and authorized to access them. This leaves the systems of Internet-connected organizations open for attacks, including jamming attacks known as denial of service (DOS) attacks or distributed denial of service (DDOS) attacks, in which streams of traffic are directed at an organization&#39;s Internet-connected systems.  
         [0007]     Initially, DOS attacks came from individual machines from which individual hackers streamed data (e.g., ping echo packets) to web-attached servers in an effort to flood the network and burden the server with the overhead of handling the stream of data.  
         [0008]     Today, hackers have learned how to take control of or “borrow” multiple web-attached computers in different organizations (“masters”), use these master machines to infiltrate many more computers in different organizations (“zombies”), embed DOS attack code scripts (or, “trojan-horses”) in the zombies through the masters, and then issue commands from the masters to the zombies to run the scripts directed at the server(s) of a targeted organization.  
         [0009]     The hackers, twice removed from the attacking zombie machines, are difficult to trace. The attacks coming from many different zombies in many different networks comprise DDOS attacks that are hard to detect and control. The scripts run by the zombies are a nasty assemblage of echo packet floods, status requests, incomplete logins, deliberate causes of connection error conditions, false reports of errors, and transmissions of packets requiring special handling. Many of these zombies may occur at and are received at the application level. These vicious scripts, run from hundreds or thousands of zombies, are designed to flood the network, tie up system control blocks, and siphon web server computing power to the point that the attacked webserver network and system can no longer provide service to legitimate users. All the while, the zombie computers causing the damage are owned by legitimate organizations which have no idea that their systems are being used in attacks on other organizations.  
       SUMMARY OF THE INVENTION  
       [0010]     A system, method and program storage device are provided for protecting a server against a multiple-login denial of service attack by providing a proxy authentication server having an authentication request history table; maintaining in the table recent authentication requests to a second server, including user ID and time of each of the recent authentication requests; receiving a subsequent authentication request at the proxy authentication server; and determining whether to forward the subsequent authentication request to the second server based on a pre-defined filtering rule(s) and the user ID and time of authentication request in the authentication request history table.  
         [0011]     In accordance with an aspect of the invention, there is provided a computer program product configured to be operable to protect a server against a multiple-login denial of service attack by providing a proxy authentication server having a authentication request history table; maintaining in the table recent authentication requests to a second server, including user ID and time of each of the recent authentication requests; receiving a subsequent authentication request at the proxy authentication server; and determining whether to forward the subsequent authentication request to the second server based on a pre-defined filtering rule and the user ID and time of authentication request in the authentication request history table.  
         [0012]     Other features and advantages of this invention will become apparent from the following detailed description of the presently preferred embodiment of the invention, taken in conjunction with the accompanying drawings.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0013]      FIG. 1  is a diagrammatic representation of the OSI architecture.  
         [0014]      FIG. 2  is a high level system diagram illustrating major components of the invention.  
         [0015]      FIG. 3  is a system diagram illustrating the proxy authentication server of a first preferred embodiment of the invention.  
         [0016]      FIG. 4  is a system diagram illustrating the proxy authentication server of a second preferred embodiment of the invention.  
         [0017]      FIG. 5  illustrates the format of an authentication (bind) request.  
         [0018]      FIG. 6  illustrates the format of an authentication (bind) response.  
         [0019]      FIG. 7  illustrates the format of a referral response, or result.  
         [0020]      FIG. 8  is flow chart representation of a first exemplary filtering rule.  
         [0021]      FIG. 9  is a flow chart representation of a second exemplary filtering rule.  
         [0022]      FIG. 10  is a flow diagram illustrating the operation of an exemplary embodiment of the proxy authentication server of the invention.  
         [0023]      FIG. 11  is a high level system diagram illustrating a program storage device readable by a machine, tangibly embodying a program of instructions executable by a machine to perform operations for protecting an application server against multiple login denial of service attacks.  
     
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS  
       [0024]     A system, method and program storage device are provided for protecting a server against a multiple-login denial of service attack by providing a proxy authentication server having an authentication request history table; maintaining in the table recent authentication requests to a second server, including user ID and time of each of the recent authentication requests; receiving a subsequent authentication request at the proxy authentication server; and determining whether to forward or redirect the subsequent authentication request to the second server based on a pre-defined filtering rule and the user ID and time of authentication request in the authentication request history table.  
         [0025]     The present invention is implemented in application layer. That is, the present invention limits the number of login attempts to a hosted application using legitimate user credentials, thus providing protection from application level denial of service attacks using a typical HTML browser and application level authentication and authorization.  
         [0026]     Referring to  FIG. 1 , the open system architecture (OSA) model represents a network as a hierarchical structure of layers of functions; each layer providing a set of functions that can be accessed and that can be used by the layer above it. Layers are independent in the sense that implementation of a layer can be changed without affecting other layers. According to the open systems interconnection standard of the International organization for Standardization (OSI), that network functions are divided into seven layers: application layer  202 ,  222 , presentation layer  204 ,  224 , session layer  206 ,  226 , transport layer  208 ,  228 , network layer  210 ,  230 , data link layer  212 ,  232 , and physical layer  214 ,  234 . It is a characteristic of systems architected to the OSI model that each layer of a server  200  logically communicates with, and only with, corresponding layers of client  220 . As represented by line  242 , application layer  202  is in logical connection to (only communicates with) application layer  222 . Similarly, lines  244 - 254  represent logical connection of layers  204 - 214  with respective layers  224 - 234 .  
         [0027]     Referring to  FIG. 2 , proxy authentication server  104  is placed on a machine on the network  103  where application server  100  and server  108  reside, or on another network interconnected with network  103 .  
         [0028]     Proxy authentication server  104  is a software module that intercepts communication between a application code  101  (or client module) and a server module  108 , and while being transparent to both client module  101  and server module  108 , is capable of either passing requests and response through, or performing additional processing and/or modifications of requests and/or responses.  
         [0029]     Referring to  FIGS. 3 and 4 , two preferred embodiments are illustrated. In these embodiments, application code  101  runs on server  100 . In situations when application code  101  cannot be changed to accommodate protective measures, or when such a change is undesirable for whatever the reason may be, an external protection mechanism is provided by proxy authentication server  104 , the purpose of which is to limit the number of login attempts for any given user ID within a specified time frame, thus preventing a malicious party possessing a valid user credential for application  101  from launching a multiple-login denial of service attack.  
         [0030]     A user credential is a &lt;username, password&gt; pair that is unique across a given domain, where domain can be a single application  101 , a group of applications, an organization, or a service provider.  
         [0031]     In an exemplary embodiment, authentication server  108  is an LDAP server, used by application server  100  to authenticate users. In this exemplary embodiment, server  108  functions in accordance with  Lightweight Directory Access Protocol  ( v 3):  Technical Specification. Request for Comments:  3377. The Internet Society. 2002. This RFC describes a directory access protocol that provides both read and update access. The LDAP model is one of clients performing protocol operations against servers. A client transmits a protocol request describing an operation to be performed to a server. The server is then responsible for performing the necessary operation(s) in a directory. Upon completion of the operation(s), the server returns a response containing any results or errors to the requesting client via protocol exchanges.  
         [0032]     In accordance with an exemplary embodiment of the invention based on LDAP technology, bind request, bind response, bind redirect responses are examples of LDAPMessages  111 ,  112 ,  113 ,  114 ,  121 ,  122 ,  123 ,  124  which are encapsulated in protocol data unit (PDU) exchanges or operations, as set forth in Table 1.  
                                                               TABLE 1                       LDAPMessage Protocol Data Unit (PDU)                                    LDAPMessage ::= SEQUENCE {                  messageID   MessageID,             protocolOp   CHOICE {                    bindRequest   BindRequest,               bindResponse   BindResponse,               unbindRequest   UnbindRequest,               searchRequest   SearchRequest,               searchResEntry   SearchResultEntry,               searchResDone   SearchResultDone,               searchResRef   SearchResultReference,               modifyRequest   ModifyRequest,               modifyResponse   ModifyResponse,               addRequest   AddRequest,               addResponse   AddResponse,               delRequest   DelRequest,               delResponse   DelResponse,               modDNRequest   ModifyDNRequest,               modDNResponse   ModifyDNResponse,               compareRequest   CompareRequest,               compareResponse   CompareResponse,               abandonRequest   AbandonRequest,               extendedReq   ExtendedRequest,               extendedResp   ExtendedResponse },                  controls    [0] Controls OPTIONAL }           MessageID ::= INTEGER (0 .. maxInt)           maxInt INTEGER ::= 2147483647 -- (2{circumflex over ( )}{circumflex over ( )}31 − 1) −                      
 
         [0033]     Table 2 shows the format of LDAPResult  123 , which is the response of LDAP server  108  to an LDAP client  104 . One of the possible responses is “referral” (code 10) which is a synonym for “redirect”. See RFC2251.  
                                                     TABLE 2                       LDAPResult Format                                    LDAPResult ::= SEQUENCE{ resultcode ENUMERATED {                  success    (0),             operationsError    (1),             protocolError    (2),             timeLimitExceeded    (3),             sizeLimitExceeded    (4),             compareFalse    (5),             compareTrue    (6),             authMethodNotSupported    (7),             strongAuthRequired    (8),             referral   (10),             adminLimitExceeded   (11),             unavailableCriticalExtension   (12),             confidentialityRequired   (13),             sslBindInProgress   (14),             noSuchAttribute   (16),             undefinedAttributeType   (17),             inappropriateMatching   (18),             constraintViolation   (19),             attributeOrValueExists   (20),             invalidAttributeSyntax   (21),             noSuchObject   (32),             aliasProblem   (33),             invalidDNSyntax   (34),             aliasDeferencingProblem   (36),             inappropriateAuthentication   (48),             invalidCredentials   (49),             insufficientAccessRights   (50),             busy   (51),             unavailable   (52),             unwillingToPerform   (53),             loopDetect   (54),             namingViolation   (64),             objectClassViolation   (65),             notAllowedOnNonLeaf   (66),             notAllowedOnRDN   (67),             entryAlreadyExists   (68),             objectClassModeProhibited   (69),             affectsMultipleDSAs   (71),             other   (80),                matchDN   LDAPDN,           errorMessage   LDAPString,           referral   (3) Referral OPTIONAL,}                      
 
         [0034]     Referring to  FIG. 5 , the format of envelope  300  of an authentication (bind) request  111 ,  121 ,  122  includes message ID  302 , message type  304  (which, for a bind request, is 0x00  305 ), message length  306 , version, distinguished name (DN)  310 , authentication type  312  and password  314  fields.  
         [0035]     Referring to  FIG. 6 , the format of envelope  320  of an authentication (bind) response  114 ,  123 ,  124  includes message ID  322 , message type  324  (0x01 for bind result), message length  326 , respond to  328 , time  330 , result code  332  (0x00 for success  333 ), matched distinguished name  334 , error message  336  (must be null  337 ) and server credentials  338  fields.  
         [0036]     Referring to  FIG. 6 , the format of envelope  340  of a referral response  112  includes message ID  342 , message type  344  (0x13 for search result reference) message length  346 , and reference URL  348 .  
         [0037]     References to “bind” are for an LDAP exemplary embodiment. “Authentication” is a generic term encompassing “bind”.  
         [0038]     The function of LDAPMessage envelopes  300 ,  320 ,  340  is to provide an envelope containing common fields required in all protocol exchanges.  
         [0039]     All LDAPMessage envelopes  320  encapsulating responses  114 ,  123 ,  124 ,  112  contain the messageID value of the corresponding request LDAPMessage  113 ,  122 ,  121 ,  111 , respectively.  
         [0040]     A client application server  100  must not send a second request with the same message ID  302  as an earlier request on the same connection if the client has not received the final response from the earlier request. Otherwise the behavior is undefined. Typical clients increment a counter for each request.  
         [0041]     Distinguished Name (LDAPDN) and Relative Distinguished Name (RelativeLDAPDN) are respectively defined to be the representation of a Distinguished Name and a Relative Distinguished Name after encoding such that  
                                                   &lt;distinguished-name&gt; ::= &lt;name&gt;           &lt;relative-distinguished-name&gt; ::= &lt;name-component&gt;           LDAPDN ::= LDAPString           RelativeLDAPDN ::= LDAPString                      
 
         [0042]     Proxy authentication server  104  maintains history table  106  to track recent Authentication requests  121  submitted to server  108  by application server  100 , which has been triggered by a login request  115  from client machine  110 . Table  106  includes for each authentication request  121  user ID  131  and time of authentication request  133 . Upon intercepting an authentication request  121 , (such as an LDAP BIND request, or equivalent), proxy authentication server  104  determines whether to forward authentication request  121  as an authentication request  122  to server  108  based on a pre-defined filter rule or set of filtering rules  135  and the contents of authentication requests history table  106 .  
         [0043]     The function of the authentication operation is to allow authentication information to be exchanged between a client and a server.  
         [0044]     Authentication Request  121 ,  122 , for example in an LDAP embodiment, is defined as follows:  
                                                                                                                           BindRequest ::= [APPLICATION 0] SEQUENCE {                  version   INTEGER (1 .. 127),             name   LDAPDN,             authentication   AuthenticationChoice }                AuthenticationChoice ::= CHOICE {                  simple   [0] OCTET STRING,               -- 1 and 2 reserved             sasl   [3] SaslCredentials }                SaslCredentials ::= SEQUENCE {                  mechanism   LDAPString,             credentials   OCTET STRING OPTIONAL }                (SASL refers to a simple authentication and security           layer, a method for adding authentication support to           connection-based protocols.)                      
 
         [0045]     Parameters of the Bind Request are:  
         [0046]     version  308 : A version number indicating the version of the protocol to be used in this protocol session, such as version 3 of the LDAP protocol.  
         [0047]     name  302 : The name of the directory object that the client wishes to authenticate (bind) as. This field may take on a null value (a zero length string) for the purposes of anonymous authentications, when authentication has been performed at a lower layer, or when using SASL credentials with a mechanism that includes the LDAPDN in the credentials.  
         [0048]     authentication  312 ,  314 : information used to authenticate the name, if any, provided in the authentication request.  
         [0049]     In accordance with the first exemplary embodiment, upon receipt of an authentication request  113 , authentication (aka protocol) server  102  will authenticate the requesting client  110 , if necessary. The server  102  will then return an authentication response  114  to client  100  indicating the status of the authentication.  
         [0050]     Authorization is the use of this authentication information when performing operations. Authorization MAY be affected by factors outside of the authentication (such as LDAP Bind) request  111 / 121 , such as lower layer security services. (See Lightweight Directory Access Protocol (v3). Request for Comments: 2251. The Internet Society (2002). At page 20.)  
         [0051]     A filtering rule  135  may instruct proxy  104  to limit the number of authentication requests  111  and, consequently, login attempts  115  from client machine  110  for any given user ID  131  within a time frame specified in filter rules  135  by a given number as, for example “any user may not be allowed to login more than 10 times within any given 10-minute period.” 
         [0052]     Referring to  FIGS. 8 and 9 , two exemplary filtering rules  135  are illustrated. The first filtering rule ( FIG. 8 ) is: for any userID, the number of login attempts within any given XX minutes should not exceed N. The second filtering rule ( FIG. 9 ) is: for any userID, the minimum time between two login attempts must be M seconds.  
         [0053]     Referring to  FIG. 8 , a new bind request from a userID is received, and in step  262  registered in temporary storage. In step  264 , the number of bind requests registered for this userID for the last XX minutes is counted, and in step  266  tested to see if a preset threshold has been exceeded. If so, in step  270  “bind unsuccessful” is returned to the client. If not, in step  268  in accordance with a first exemplary embodiment the request is forwarded to the LDAP server, and in accordance with a second exemplary embodiment “LDAPResult=referral” is returned to the client.  
         [0054]     Referring to  FIG. 9 , a new bind request is received in step  280  and in step  282  the timestamp of the last bind request is updated for the userID of this bind request in temporary storage. In step  284  it is determined if the time elapsed from the last bind request for same userID is greater than M seconds and, if so, in step  286  in accordance with a first exemplary embodiment the request is forwarded to the LDAP server, or in accordance with a second exemplary embodiment “LDAPResult=referral” is returned to the client.  
         [0055]     Referring further to  FIG. 4 , proxy authentication server  104  may forward requests  121  to authentication server  108  as a request  122  when timeout limiting the number of authentication requests by that user ID expires as is tracked in authentication request table  106 .  
         [0056]     If a new Authentication request  121  which satisfies filter rules  135  is received by proxy authentication server  104 , it is forwarded to authentication server  108  as authentication request  122 . Upon receiving authentication response  123  from authentication server  108 , proxy authentication server  104  returns authentication response  123  to server  100  as authentication response  124 .  
         [0057]     Proxy authentication server  104  does not change the content of requests  111 / 121  and responses  112 / 124 , and makes routing decisions only. Four situations are possible: 
    1. Send a given request  121  (as request  122 ) to authentication server  108  immediately ( FIG. 4 ).     2. Send a given request  121  (as request  122 ) to authentication server  108  upon a timeout expiration, so that the filtering rule(s)  135  will be satisfied.     3. Return a “bind unsuccessful” response  124  to client  100  immediately.     4. Return a “redirect” response  112  to client  100  immediately.    
 
         [0062]     Referring to  FIG. 5 , an authentication response  123 ,  124  (using LDAP bind as an example) may be structured as follows:  
                                                   BindResponse ::= [APPLICATION 1] SEQUENCE {             COMPONENTS OF LDAPResult,             serverSas1Creds [7] OCTET STRING OPTIONAL           }”                      
 
         [0063]     An authentication response  123 ,  124  (such as a BindResponse) comprises an indication from the server of the status of the client&#39;s request for authentication. If authentication was successful, the resultcode will be success, otherwise it will be one of: 
        operationsError: server encountered an internal error,     protocolError: unrecognized version number or incorrect PDU structure,     authMethodNotSupported: unrecognized SASL mechanism name,     strongAuthRequired: the server requires authentication be performed with a SASL mechanism,     referral: this server cannot accept this authentication request and the client should try another,     saslBindInProgress: the server requires the client to send a new authentication request, with the same sasl mechanism, to continue the authentication process,     inappropriateAuthentication: the server requires the client which had attempted to authenticate anonymously or without supplying credentials to provide some form of credentials,     invalidcredentials: the wrong password was supplied or the SASL credentials could not be processed,     unavailable: the server is shutting down.        
 
         [0073]     If the server does not support the client&#39;s requested protocol version, it sends the resultcode to protocolError.  
         [0074]     If client  100  receives an authentication response, for example, an LDAP BindResponse response, where the resultCode was protocolError, it will close the connection as the server will be unwilling to accept further operations.  
         [0075]     The serverSaslCreds are used as part of a SASL-defined bind mechanism to allow the client to authenticate the server to which it is communicating, or to perform “challenge-response” authentication. If the client bound with the password choice, or the SASL mechanism does not require the server to return information to the client, then this field is not included in the result.  
         [0000]     (See Lightweight Directory Access protocol (v3). Request for Comments: 2251. The Internet Society (2002), at pages 20, 23.)  
         [0076]     Referring to  FIG. 3 , proxy authentication server  104  will, upon determining that the filtering rule(s)  135  are immediately satisfied, or upon the expiration of the timeout limiting a number of authentication requests  111  by a given user ID  131  (also a rule in  135 ), return redirect response  112  to client application code  101 , instructing it to send the authentication request  113  to authentication server  102 , which will process the request and return authentication response  114 .  
         [0077]     Referring to  FIG. 10  in connection with  FIGS. 3 and 4 , DLAP proxy authentication server  104 , in step  160 , initializes filter rules table  135  (or, as represented in  FIGS. 8 and 9 , as processes). In step  162 , proxy authentication server  104  receives an authentication request  111 / 121  from client  110  application server  100 . In step  164  authentication request table  106  is accessed for user ID  131  corresponding to this client  110 . If in step  164  no entry for this user ID  131  is found, in step  172 , authentication request table  106  is updated for this request and in step  174  the request is forwarded  122  or redirected  112 / 113  to authentication server  102  (forwarded in the embodiment of  FIG. 4  and redirected in the embodiment of  FIG. 3 ) and proxy authentication server  104  returns to step  162  to await the next authentication request  111 / 121 .  
         [0078]     If, in step  164  it is determined that an entry for this client  100  exists in table  106 , in step  166  proxy authentication server  104  determines if this request passes all relevant filter rules and rule sets. If so, processing continues to step  172  as above. If not, in step  168  if relevant filter rules and rule sets allow time out or expiration, processing cycles through step  166  until time out, and thereupon executes steps  172  and  174  as above. If relevant filter rules and rule sets  135  do not allow time out, in step  170  the authentication request table is updated for this request, authentication unsuccessful  124 / 112  is returned to client  110 /application  100 , and proxy authentication server  104  returns to step  162  to await the next authentication request  111 .  
         [0079]     When a rule  135  is not satisfied, proxy authentication server  104  can hold on to the response  124  and return response after time expires. Secondly, proxy authentication server  104  could return a rejection message  124  (in both cases  FIG. 3  or  FIG. 4 : authentication unsuccessful.) A rule set is a number of such rules based on user primary group. For example, as in an LDAP model, every user has a primary group (such as, department).  
       ADVANTAGES OVER THE PRIOR ART  
       [0080]     It is an advantage of the invention that there is provided a system, method, or program storage device for protecting a server from denial of service attacks.  
       Alternative Embodiments  
       [0081]     It will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. Referring to  FIG. 11 , in particular, it is within the scope of the invention to provide a computer program product or program element, or a program storage or memory device  150  such as a solid or fluid transmission medium, magnetic or optical wire, tape or disc, or the like, for storing signals readable by a machine as is illustrated by line  154 , for controlling the operation of a computer  152  according to the method of the invention and/or to structure its components in accordance with the system of the invention.  
         [0082]     Further, each step of the method may be executed on any general purpose computer, such as IBM Systems designated as zSeries, iSeries, xSeries, and pSeries, or the like and pursuant to one or more, or a part of one or more, program elements, modules or objects generated from any programming language, such as C++, Java, Pl/1, Fortran or the like. And still further, each said step, or a file or object or the like implementing each said step, may be executed by special purpose hardware or a circuit module designed for that purpose.  
         [0083]     Accordingly, the scope of protection of this invention is limited only by the following claims and their equivalents.